Real Trouble Firmware for 3.3 V

[yunusdawji]

Hi Prof Taylor,

We have received our real trouble and packaged chips. I was wondering which firmware do I have to load for 3.3V I/Os for real trouble? We are using BGA 332 package.

Yunus

[taylor-bsg]

@gaozihou

[gaozihou]

Hi @yunusdawji,

Thanks for your question. Indeed I/O and CORE voltages are programmed by software, voltage values can be stored in NVMs on board so that you only need to program once. Here is the link to the example software: https://github.com/bespoke-silicon-group/bsg_motherboards/tree/master/bsg_trouble/real_trouble/software/trouble_master

I'd suggest programming the voltages without packaged chip installed, in case the output voltages are higher than expected.

[yunusdawji]

Hi Paul,

Thanks for the reply. I want firmware for LVCMOS33 version gateway. Currently the fdc under firmware for realtrouble folder has LVCMOS18.

I want something like this firmware for gateway but that was configured to provide io and core clock from gateway.

https://bitbucket.org/taylor-bsg/bsg_fpga/src/Real_Trouble_Working/

We tried to use the firmware under https://github.com/bespoke-silicon-group/bsg_motherboards/tree/master/bsg_trouble/real_trouble/firmware/common/bsg_gateway_outerspace with this fdc https://bitbucket.org/taylor-bsg/bsg_fpga/src/Real_Trouble_Working/ip/bsg_gateway/bsg_two_real_trouble_gateway/fdc/bsg_gateway.fdc.
We did this as the firmware in github repo provides clock from gateway to asic.

But so far we have had no luck with running helloworld on our ASIC

Anytips on how we can debug? Currently our chip is consuming about 2mA for core and 350mA for IO.

Yunus

[gaozihou]

Hi @yunusdawji, thanks for your detailed explanation!

Some debug tips:

1. Your core consumption is 2mA, which means the core clock is not oscillating or the ASIC is not configured to use the external clock. (most likely the latter reason)
2. Your IO consumption is 350mA, which is lower than normal. There are about 128 termination resistors on board, each of them has 100+100=200 ohm. Currently each one consume 350/128=2.734mA, by Ohm's law the IO voltage is 546mV. I'd suggest double check the IO voltage output (maybe also core voltage) before proceeding to the FPGA firmware.

[gaozihou]

@yunusdawji In terms of the FPGA firmware:

1. In general, we need FPGA firmware that is compatible with the specific ASIC, not only LVCMOS33, but also the internal logic. For example, bsg_gateway_outerspace firmware enables 1x comm-link channels, while the fdc file you grabbed from Bitbucket assumes 4x comm-link channels, so I think it will not work. I guess the high-level question is, what kind of IO communication channels do you have on the ASIC? Did you use bsg_tag on-chip? Which version (commit) of basejump_stl library did you use on the ASIC?
2. After figuring out what we are communicating with, we could modify one of the current firmware to be compatible with the ASIC. We could slow down the IO/Core clock speed, reconfigure the IO interface, setting up bsg_tag... I guess bsg_gateway_outerspace may or may not be a good baseline, depending on the actual ASIC design.
3. If you have on-ASIC clock generator(s), the clocks are configured by the trace file. We could also configure it to bypass the on-chip clock and use the external clock (from gateway FPGA).
4. After all the modifications we could update the FDC constraints accordingly.

Let me know if you have more questions!

[yunusdawji]

Hi Paul,

Sorry for late reply. I have been tied with my internship

Question: Your core consumption is 2mA, which means the core clock is not oscillating or the ASIC is not configured to use the external clock. (most likely the latter reason)

Answer: To give you some background, we have implement bsg bison with our bioinformatics accelerator. The clock is external only. So far from the FDC it looks like clock is configured properly on gateway. I think this 2mA because the reset to the core is not asserted until the bsg comm link is not calibrated. We were using the SERDES version of firmware which might not be matching the bsg comm link on chip. What do you think of this?

Question: Your IO consumption is 350mA, which is lower than normal. There are about 128 termination resistors on board, each of them has 100+100=200 ohm. Currently each one consume 350/128=2.734mA, by Ohm's law the IO voltage is 546mV. I'd suggest double check the IO voltage output (maybe also core voltage) before proceeding to the FPGA firmware.

Answer: This was the measurement from the troublemaster. The actual power consumption is about 12W (1A from 12V power supply). This is very similar to what we see in doubletrouble.

Question: In general, we need FPGA firmware that is compatible with the specific ASIC, not only LVCMOS33, but also the internal logic. For example, bsg_gateway_outerspace firmware enables 1x comm-link channels, while the fdc file you grabbed from Bitbucket assumes 4x comm-link channels, so I think it will not work. I guess the high-level question is, what kind of IO communication channels do you have on the ASIC? Did you use bsg_tag on-chip? Which version (commit) of basejump_stl library did you use on the ASIC? After figuring out what we are communicating with, we could modify one of the current firmware to be compatible with the ASIC. We could slow down the IO/Core clock speed, reconfigure the IO interface, setting up bsg_tag... I guess bsg_gateway_outerspace may or may not be a good baseline, depending on the actual ASIC design.

Answer: We have use this version of bsg_chip. I dont think it has bsg_tag but the chip is using external clock. As u can see the reset to most of the core logic comes from core_calib_done_r_lo
https://bitbucket.org/taylor-bsg/bsg_designs/src/master/toplevels/bsg_two_bison_accum/v/bsg_chip.v

Also in bsg_chip this is flipped ACBD, do you know why? Will I have to make the corresponding changes to bsg_comm_link on gateway side?
assign sdi_data_i_int_packed = {sdi_D_data_i_int, sdi_B_data_i_int, sdi_C_data_i_int, sdi_A_data_i_int};

I think bsg_two_gateway ip here will be a good match for our ASIC. Do you think it can work with bsg_bison?
https://bitbucket.org/taylor-bsg/bsg_fpga/src/Real_Trouble_Working/ip/bsg_gateway/bsg_two_gateway/

Thanks for all your help

Yunus

[yunusdawji]

Hi

@gaozihou @taylor-bsg Thanks a lot for the help through out the process. Our chip works, I had to change the firmware somewhat to get it to work. Here are the pics of board and the chip

[taylor-bsg]

Wow!!!!!! Nice job Yunus! Congratulations :-) 🎉🎊🍾

…

On Fri, Apr 15, 2022 at 7:29 PM Yunus Dawji ***@***.***> wrote: Hi @gaozihou <https://github.com/gaozihou> @taylor-bsg <https://github.com/taylor-bsg> Thanks a lot for the help through out the process. Our chip works, I had to change the firmware somewhat to get it to work. Here are the pics of board and the chip [image: image_67156737] <https://user-images.githubusercontent.com/4324036/163658062-74ed2036-2e27-4449-82bf-7842343b66c6.JPG> [image: image_67224833] <https://user-images.githubusercontent.com/4324036/163658064-66124927-749c-45b6-b375-d9dafc1097f7.JPG> — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEFG5AA6V3O3ISWZZ3NIDNLVFIQXPANCNFSM5SLCH5KQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>