Testing Double Trouble Board using Zedboard Zynq-7000

[KarimHammad]

Hi,

I am creating this issue to discuss questions related to testing the double trouble after its successful assembly at Sierra Circuits.

I am currently at testing stage 1 that is powering up the board.

The board I am having is V1.2, and the document found here https://docs.google.com/document/d/1RrP9torYVqvp9zgF8nX2fYvYWnBSqGglMHzzH0_2e-s/edit#heading=h.7lagbxxd2hqg is for bootstrapping Double Trouble V1.

Is there another similar document for V1.2 or should I use the same document?

Thanks.

Karim

[taylor-bsg]

@gaozihou

[gaozihou]

Hi Karim,

Here is the link to v1.2 doc: https://docs.google.com/document/d/1HLAzLbiut6ybPWQin3k_HY79FDgIf_2cI6SUBNwltZw. It needs some lab equipment to bootstrap the board (mentioned in the v1.2 doc), all of them can be purchased online.

[KarimHammad]

Hi Michael and Paul,

Thanks a lot for sharing this document, appreciate it a lot!

Karim

[KarimHammad]

Quick question, for the external 12V input supply that drives the board, could you please recommend a specific power supply (with Molex connector) device to get for my test? It will be great if you can share the one you used in your test.

Also, what is current value that we should set the supply at?

Thanks.

Karim

[gaozihou]

Hi Karim, Power supply requirement has been added to the doc.

We are using generic lab power supply (it is safer to use lab power supply because it has current limit). 4-pin Molex female cable is bought separately, which connects board to the power supply.

[taylor-bsg]

Hi Paul,

Perhaps you can send the model # of the supply we are using? Is there anything we do to ensure good responsiveness to changes in current; i.e. sense leads, short wires, etc?

M

On Tue, Jul 13, 2021 at 12:37 PM Paul Gao @.***> wrote:

Hi Karim, Power supply requirement has been added to the doc.

We are using generic lab power supply (it is safer to use lab power supply because it has current limit). 4-pin Molex female cable is bought separately, which connects board to the power supply.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bespoke-silicon-group/basejump_stl/issues/458#issuecomment-879348278, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFG5ACTJWL7SYBZZ22VVHLTXSIWLANCNFSM5AHNIYQA .

[gaozihou]

Yeah, we are using HMP4040 (https://www.tequipment.net/Rohde-&-Schwarz/HMP4040/DC-Power-Supplies/Lab-Power-Supplies-1/ ), other power supplies should also work for 12V input.

For now we are not using sense leads for 12V input, because current is small and 12V does not drive components directly (except for cooling fan). I think sense leads are very useful when driving Core / IO power directly, because lower voltage -> larger current -> larger voltage drop and we need a stable Core / IO supply.

[yunusdawji]

Hi Paul,

Any rough idea of how much power the board was consuming?

Yunus

[gaozihou]

Hi Yunus, the power-on current consumption is about 0.85A. This is after bootstrapping process, when you plug it in for the first time current consumption should be lower than that. The number is measured without a cooling fan.

I also added these info to the v1.2 google doc: https://docs.google.com/document/d/1HLAzLbiut6ybPWQin3k_HY79FDgIf_2cI6SUBNwltZw

[KarimHammad]

Yeah, we are using HMP4040 (https://www.tequipment.net/Rohde-&-Schwarz/HMP4040/DC-Power-Supplies/Lab-Power-Supplies-1/ ), other power supplies should also work for 12V input.

For now we are not using sense leads for 12V input, because current is small and 12V does not drive components directly (except for cooling fan). I think sense leads are very useful when driving Core / IO power directly, because lower voltage -> larger current -> larger voltage drop and we need a stable Core / IO supply.

Many thanks Michael and Paul! This is very helpful.

Karim

[yunusdawji]

Hi Yunus, the power-on current consumption is about 0.85A. This is after bootstrapping process, when you plug it in for the first time current consumption should be lower than that. The number is measured without a cooling fan.

I also added these info to the v1.2 google doc: https://docs.google.com/document/d/1HLAzLbiut6ybPWQin3k_HY79FDgIf_2cI6SUBNwltZw

Thanks! This will help us with finding a power supply.

[KarimHammad]

Hi Michael and Paul,

Could you please provide the Digikey part number for the cable that we should use to monitor the voltage on J26?

Thanks.

Karim

[gaozihou]

Hi Karim, the Digikey part number for assembled cable is WM17888-ND (https://www.digikey.com/en/products/detail/molex/0451360410/8573187). It is called Molex Mega-fit series.

Connectors (WM10386-ND) and cords (WM16040-ND) can be purchased separately (not recommended).

[KarimHammad]

Many thanks, Paul!

Best, Karim

[KarimHammad]

Hi Michael and Paul,

We are trying to program the Gateway FPGA's flash. The one we have on our board is MT25QL128ABA1EW9-0SIT ( https://www.avnet.com/shop/us/products/micron/mt25ql128aba1ew9-0sit-3074457345645004448/) as a replacement to the original M25P128-VME6TGB flash which was out-of-stock during the assembly time.

The ISE iMPACT is showing us "program failed" when we try to program the flash (with GatewayFlash.mcs) while choosing the N25Q128 (as suggested in here https://www.xilinx.com/support/answers/68677.html) from the device list.

On the other hand, if we choose M25P128 (i.e., the original out-of-stock flash chip) from the list the flash got programmed successfully. However, when we try to query the device's version and description using the Trouble Master software it returned "Failed".

I am wondering if the GatewayFlash.mcs (which was supposed to be used with the original flash device) matches the replacement flash device we are having on our board?

Could you please advise?

Thanks for your help.

Karim

[KarimHammad]

Hi Michael and Paul,

We are trying to program the Gateway FPGA's flash. The one we have on our board is MT25QL128ABA1EW9-0SIT ( https://www.avnet.com/shop/us/products/micron/mt25ql128aba1ew9-0sit-3074457345645004448/) as a replacement to the original M25P128-VME6TGB flash which was out-of-stock during the assembly time.

The ISE iMPACT is showing us "program failed" when we try to program the flash (with GatewayFlash.mcs) while choosing the N25Q128 (as suggested in here https://www.xilinx.com/support/answers/68677.html) from the device list.

On the other hand, if we choose M25P128 (i.e., the original out-of-stock flash chip) from the list the flash got programmed successfully. However, when we try to query the device's version and description using the Trouble Master software it returned "Failed".

I am wondering if the GatewayFlash.mcs (which was supposed to be used with the original flash device) matches the replacement flash device we are having on our board?

Could you please advise?

Thanks for your help.

Karim

Hi Michael and Paul,

We have successfully figured out the problem of programming the gateway flash. We just have re-generated the GatewayFlash.mcs and it worked! The Trouble Master Software was successfully query all the board info as expected.

Thanks.

Karim

[KarimHammad]

Hi Michael and Paul,

We have successfully generated the bitstream for the Zedboard for testing the DT board. We are currently trying to generate bitstream for the Gateway FPGA. We still have some issues that we need your help with as follows: 1- We are not sure about which project we should use (to test our design) from those available in https://bitbucket.org/taylor-bsg/bsg_fpga/src/master/project/bsg_zedboard/. We assumed bsg_one_loopback would fit our needs. However, we are not sure how to run it. In particular, there is no README.md provided for this particular project like other projects (e.g., bsg_two_rocket and big_rocket_baseline).

2- Also, the makefile (i.e., available here: https://bitbucket.org/taylor-bsg/bsg_fpga/src/master/project/bsg_zedboard/bsg_one_loopback/bsg_gateway/Makefile) has probably a bug in line 18 (include $(BSG_FPGA_IP_DIR)/bsg_gateway/bsg_gateway/mk/Makefile.flow) since the path provided in not existing! is the path supposed to be /bsg_gateway/bsg_one_gateway/mk/Makefile.flow to point to the make file available here: https://bitbucket.org/taylor-bsg/bsg_fpga/src/master/ip/bsg_gateway/bsg_one_gateway/mk/Makefile.flow ?

3- Line 114 in https://bitbucket.org/taylor-bsg/bsg_fpga/src/master/ip/bsg_gateway/bsg_one_gateway/mk/Makefile.flow generates error we try to compile it since the environment variable BSG_BASE_DIR is not defined. We have tried defining it as "export BSG_BASE_DIR:=$(shell dirname $(abspath $(lastword $(MAKEFILE_LIST))))" but it did not work! Could you please advise?

4- Like the case in 3-, we have added the following lines for other two variables export BSG_WORK_DIR=$(abspath ./) export BSG_OUT_DIR=$(BSG_WORK_DIR)/out is that correct?

Your insigths about the above issues will be much appreciated!

Karim

[taylor-bsg]

Hi all, any follow up on this?

On Fri, Aug 20, 2021 at 10:38 AM KarimHammad @.***> wrote:

Hi Michael and Paul,

We have successfully generated the bitstream for the Zedboard for testing the DT board. We are currently trying to generate bitstream for the Gateway FPGA. We still have some issues that we need your help with as follows: 1- We are not sure about which project we should use (to test our design) from those available in https://bitbucket.org/taylor-bsg/bsg_fpga/src/master/project/bsg_zedboard/. We assumed bsg_one_loopback would fit our needs. However, we are not sure how to run it. In particular, there is no README.md provided for this particular project like other projects (e.g., bsg_two_rocket and big_rocket_baseline).

2- Also, the makefile (i.e., available here: https://bitbucket.org/taylor-bsg/bsg_fpga/src/master/project/bsg_zedboard/bsg_one_loopback/bsg_gateway/Makefile) has probably a bug in line 18 (include $(BSG_FPGA_IP_DIR)/bsg_gateway/bsg_gateway/mk/Makefile.flow) since the path provided in not existing! is the path supposed to be /bsg_gateway/bsg_one_gateway/mk/Makefile.flow to point to the make file available here: https://bitbucket.org/taylor-bsg/bsg_fpga/src/master/ip/bsg_gateway/bsg_one_gateway/mk/Makefile.flow ?

3- Line 114 in https://bitbucket.org/taylor-bsg/bsg_fpga/src/master/ip/bsg_gateway/bsg_one_gateway/mk/Makefile.flow generates error we try to compile it since the environment variable BSG_BASE_DIR is not defined. We have tried defining it as "export BSG_BASE_DIR:=$(shell dirname $(abspath $(lastword $(MAKEFILE_LIST))))" but it did not work! Could you please advise?

4- Like the case in 3-, we have added the following lines for other two variables export BSG_WORK_DIR=$(abspath ./) export BSG_OUT_DIR=$(BSG_WORK_DIR)/out is that correct?

Your insigths about the above issues will be much appreciated!

Karim

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bespoke-silicon-group/basejump_stl/issues/458#issuecomment-902851199, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFG5AE7PK6NW23HAZFKNLDT52HJXANCNFSM5AHNIYQA .

[zhongpanwu]

Hello, we have tested the hello program that is already given in SD card's image on the double-trouble board successfully. However, we failed to run the other programs that are compiled by the "riscv64-unknown-linux-gnu-gcc" or "riscv64-unknown-elf-gcc". The problem popped up shows "Misaligned instruction access!". I just wonder is there any specific argument you use to install the riscv-tools in order to make it work on the double-trouble board? How should I properly compile the code to run? please let me know, thank you.

[taylor-bsg]

Hi can you provide more details about what you built to run on the FPGAs?

[zhongpanwu]

Yes. For testing, I just wrote a simple adder in C, it is able to print out the result.

[taylor-bsg]

DoubleTrouble is an FPGA board — it does whatever bitstream you download into it. What did you use to build the bitstream?

On Thu, Sep 9, 2021 at 9:38 PM zhongpanwu @.***> wrote:

Yes. For testing, I just wrote a simple adder in C, it is able to print out the result.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/bespoke-silicon-group/basejump_stl/issues/458#issuecomment-916625337, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFG5AHSWQHUK257SNNMHJDUBGDVBANCNFSM5AHNIYQA .

[zhongpanwu]

Sorry, the ASIC FPGA's bitstream is the "rocket-baseline" that defines in the project "bsg_two_rocket" (in bsg_fpga repo). Both the gateway FPGA and Zedboard's bitstreams are also from here.

[taylor-bsg]

I see. If I were to guess, you are using a current version of the tool chain, and using a flag that indicates supported for compressed mode instructions. This feature was added to rocket in late July 2016, and this version of rocket is based on https://github.com/chipsalliance/rocket-chip/commit/ba96ad2b383a97a15b2d95b1acfd551f576c8faa .

On Thu, Sep 9, 2021 at 9:59 PM zhongpanwu @.***> wrote:

Sorry, the ASIC FPGA's bitstream is the "rocket-baseline" that defines in the project "bsg_two_rocket" (in bsg_fpga repo). Both the gateway FPGA and Zedboard's bitstreams are also from here.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bespoke-silicon-group/basejump_stl/issues/458#issuecomment-916631447, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFG5AEHBLRPDDPPBPX3ITLUBGGBXANCNFSM5AHNIYQA .

[zhongpanwu]

Yes, after reinstall the older version of the toolchain(v5.3), the problem is solved. Thank you very much.

[zhongpanwu]

Hello. I have successfully tested the "DefaultFPGAConfig" Verilog code on our double trouble board, and it was able to run the C program by command "./fesvr_zynq pk hello". However, when I tried to program the double trouble board with another Configration setting called "DefaultFPGASmallConfig", which seems has a smaller cache, buffer settings (e.g TLB, BTB) and without FPU. I could not run "hello" after programing the bsg_asic FPGA. There was nothing printed out, and just created a new bash line. Do you have any idea how I solve this problem? Thank you very much.

[taylor-bsg]

Usually we would try to simulate it in RTL to confirm it works. If it works in simulation, then the next step is to use Chipscope and inspect the state. In terms of changing parameters, make sure not to change the cache block size.

On Thu, Sep 23, 2021 at 12:24 PM zhongpanwu @.***> wrote:

Hello. I have successfully tested the "DefaultFPGAConfig" Verilog code on our double trouble board, and it was able to run the C program by command "./fesvr_zynq pk hello". However, when I tried to program the double trouble board with another Configration setting called "DefaultFPGASmallConfig", which seems has a smaller cache, buffer settings (e.g TLB, BTB) and without FPU. I could not run "hello" after programing the bsg_asic FPGA. There was nothing printed out, and just created a new bash line. Do you have any idea how I solve this problem? Thank you very much.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/bespoke-silicon-group/basejump_stl/issues/458#issuecomment-926090955, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFG5AGFDGGZ6HNVH6TZWNLUDN5HRANCNFSM5AHNIYQA .

[zhongpanwu]

Thanks for your previous reply. Now, I am trying "DefaultFPGASmallConfig" in Config.scala on the double trouble board. In this configuration, the FPU is removed by setting "useFPU=false" and the simulation is done in VCS. However, after I programmed the ASIC FPGA, HelloWorld does not work. The terminal does not show anything, it just creates a new line for the next input. I have tried several manners such as add specific arguments to compile the program with riscv64-unknown-elf tools but without FPU involved (-march=RV64I,IM,IMA) , I event reinstalled the toolchain by adding new lines in bsg_riscv/riscv-tools/build.sh file:--disable-float,--with-arch=RV64IMA(also I, IM), but none of them worked. Could you help me out how can I run programs on this specific configured RISC-V rocket processor? Thank you again.

[taylor-bsg]

Hi,

A few suggestions:

• getting things working in simulation often pays dividends many times over in terms of debuggability. This is what we do.

• if the problem is FPGA specific, then using Chipscope can be helpful

• you should disassemble your binaries to confirm they have no FP ops

M

On Fri, Oct 15, 2021 at 10:11 PM zhongpanwu @.***> wrote:

Thanks for your previous reply. Now, I am trying "DefaultFPGASmallConfig" in Config.scala on the double trouble board. In this configuration, the FPU is removed by setting "useFPU=false" and the simulation is done in VCS. However, after I programmed the ASIC FPGA, HelloWorld does not work. The terminal does not show anything, it just creates a new line for the next input. I have tried several manners such as add specific arguments to compile the program with riscv64-unknown-elf tools but without FPU involved (-march=RV64I,IM,IMA) , I event reinstalled the toolchain by adding new lines in bsg_riscv/riscv-tools/build.sh file:--disable-float,--with-arch=RV64IMA(also I, IM), but none of them worked. Could you help me out how can I run programs on this specific configured RISC-V rocket processor? Thank you again.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/bespoke-silicon-group/basejump_stl/issues/458#issuecomment-944858432, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFG5AABNQXFPT43RVV67DLUHECPZANCNFSM5AHNIYQA .

[zhongpanwu]

Hi, I am trying to run the linux on the Double Trouble (D-T) developing board. The command I typed is :./fesvr-zynq +disk=original_root.bin bbl vmlinux. Both original_root.bin and vmlinux are found in /bsg_riscv/bsg_addons. I also tried to regenerate them, and the Linux kernel I am testing now is 4.1.15 instead of 3.14.33. However I always got stuck after "freeing unused kernel memory" and I don't why. In contrast, I am able to use the same files to run the linux on spike without any issue. On spike, only one line showing more than on D-T, and it says the "EXT2-fs(htifblk0):warnnig:mounting unchecked fs, running e2fsck is recommended" (D-T is not showing this and gets stuck here), then the command prompt popped up. Could you guide me how I should run Linux properly on D-T? Many thanks in advance.

[taylor-bsg]

Hi,

This is a tough question -- we are not the maintainers of Rocket, so it is hard to say what versions of Linux are compatible with that specific git tag of Rocket...

M

On Wed, Mar 9, 2022 at 12:51 PM zhongpanwu @.***> wrote:

Hi, I am trying to run the linux on the Double Trouble (D-T) developing board. The command I typed is :./fesvr-zynq +disk=original_root.bin bbl vmlinux. Both original_root.bin and vmlinux are found in /bsg_riscv/bsg_addons. I also tried to regenerate them, and the Linux kernel I am testing now is 4.1.15 instead of 3.14.33. However I always got stuck after "freeing unused kernel memory" and I don't why. In contrast, I am able to use the same files to run the linux on spike without any issue. On spike, only one line showing more than on D-T, and it says the "EXT2-fs(htifblk0):warnnig:mounting unchecked fs, running e2fsck is recommended" (D-T is not showing this and gets stuck here), then the command prompt popped up. Could you guide me how I should run Linux properly on D-T? Many thanks in advance.

— Reply to this email directly, view it on GitHub https://github.com/bespoke-silicon-group/basejump_stl/issues/458#issuecomment-1063359715, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFG5ADSWYZTPVUJYANVIDDU7EFNZANCNFSM5AHNIYQA . You are receiving this because you commented.Message ID: @.***>