Running a simple test

[janhoogerbrugge]

Hi,

After building the test programs I do this:

% fusesoc --cores-root=. run --target=synth --setup --build lowrisc:sonata:system --SRAMInitFile=sw/cheri/build/tests/gpio_check.vmem

Followed by this:

% fusesoc --cores-root=. run --target=synth --setup --build lowrisc:sonata:system --SRAMInitFile=sw/cheri/build/tests/gpio_check.vmem

This gives me this output:

empty Jtag frequency : requested 6.00MHz -> real 6.00MHz
found 1 devices index 0: idcode 0x362c093 manufacturer xilinx family artix a7 50t model xc7a50t irlength 6 File type : bit Open file DONE Parse file DONE bitstream header infos date: 2024/05/28 design_name: top_sonata hour: 10:53:14 part_name: 7a50tcsg324 toolVersion: 0XFFFFFFFF;Version=2022.2 userID: TRUE load program Load SRAM: [==================================================] 100.00% Done Shift IR 35 ir: 1 isc_done 1 isc_ena 0 init 1 done 1

On the board I see that the FPGA config and CHERI LEDs are on. So that looks good.

I expect action on the 8 user LEDS. That is not happening. Instead I see that LED2 is on.

What could be wrong?

[marnovandermaas]

Did you build the software before building the bitstream? If Vivado cannot find the SRAM init file it will generate a critical warning in a log in the build directory. This doesn't currently get printed by the build system at the end.

[janhoogerbrugge]

Yes. I did. I checked that the .vmem file exists. I repeated the procedure this time with an absolute path to the .vmem file. The result is the same.

Vivado only complains a couple of times about this:

Inspecting generic module /home/jan/sonata/sonata-system/vendor/lowrisc_ibex/vendor/lowrisc_ip/ip/prim_generic/rtl/prim_generic_clock_inv.sv [Errno 2] No such file or directory: 'verible-verilog-syntax' Verible parser failed, using regex fallback instead.

I use Vivadio v2022.2.

The openFPGALoader command takes about 2.2 seconds to download the bitfile (1604716 bytes). That is fast. Is this expected?

PS. I had some trouble with building sw/cheri. It turned out that my cmake version was too old. You might want to document the required cmake version.

[janhoogerbrugge]

Some more information:

I use openFPGALoader v0.12.1.

I did not change the dipswitch settings.

[marnovandermaas]

I'm not exactly sure what the issue is here. As a sanity test, can you run through the instructions on our release: https://github.com/lowRISC/sonata-system/releases/tag/v0.2

[janhoogerbrugge]

I suspect that it has to do with the power that my USB port is able to provide. The bit and uf2 files work from my home PC but not from my office PC. I will look for a solution for the power but I guess that this is the problem.

[marnovandermaas]

Ah, that could be it. One thing you can try in that case is to look for the SW6 dip switches next to the LCD and turn on number 1 and 2 which are labelled TURBO.

You can also use the upstream version of openFPGALoader to confirm that the minvccint value is dipping below the 0.95V: https://lowrisc.org/sonata-system/doc/guide/fpga-update.html#device-rebooting-duringafter-programming-no-serial-activity

[janhoogerbrugge]

The two dipswitches did not improve the situation.

minvccint seems to be ok:

{"temp": 34.5, "maxtemp": 35.1056, "mintemp": 33.7906, "raw": {"0": 39990, "1": 21959, "2": 39282, "3": 0, "4": 0, "5": 0, "6": 21955, "7": 0}, "vccint": 1.00415, "maxvccint": 1.00635, "minvccint": 1.00269, "vccaux": 1.7981, "maxvccaux": 1.80029, "minvccaux": 1.79663, }

I ordered a the cable below. Once it arrives I can see whether it solves my problem. I will let you know.

https://www.amazon.nl/dp/B01LAV03KE/ref=pe_28126711_487102941_TE_SCE_dp_1

[marnovandermaas]

Ok, thanks for trying these things. When you program the bitstream via openFPGALoader it can read the STAT register to see if there was a CRC or ID error during programming. Would you mind trying that? https://lowrisc.org/sonata-system/doc/guide/fpga-update.html#fpga-programming-via-usbjtag

[janhoogerbrugge]

This is what I get (SW6 switches back in original position):

Jtag frequency : requested 6.00MHz -> real 6.00MHz
Open file DONE Parse file DONE load program Load SRAM: [==================================================] 100.00% Done Shift IR 35 ir: 1 isc_done 1 isc_ena 0 init 1 done 1 Register raw value: 0x40107ffc CRC Error No CRC error Part Secured 0x0 MMCM lock 0x1 DCI match 0x1 EOS 0x1 GTS CFG B 0x1 GWE 0x1 GHIGH B 0x1 MODE 0x7 INIT Complete 0x1 INIT B 0x1 Release Done 0x1 Done 0x1 ID Error No ID error DEC Error 0x0 XADC Over temp 0x0 STARTUP State 0x4 Reserved 0x0 BUS Width x1 Reserved 0x8

So no errors reported.

[janhoogerbrugge]

It's now working. I can run code via copying the bit file and uf2 file to flash and I can do it via openFPGALoader.

[marnovandermaas]

Oh, that's great! Do you know what you did that might have fixed it?

[janhoogerbrugge]

It is still a bit of a mystery to me. I thought it was the usb power. So I used a Y shape usb cable where one input provides power and the other input provides data to the board. That did not help much. But then I discovered that when I used this cable with only the power input connected to my pc to power the board that the uf2 demo code started to run. When I use a normal cable for both power and data the uf2 demo does not work. After that I decided to reboot my pc because something might be interfering. After that it worked. A normal cable works to run the uf2 demo from flash and with the normal cable I can also download a new bit file and uf2 file in flash and I can use openFPGALoader. So the Y shape usb cable is no longer needed. All that was needed was a reboot ;-).

[marnovandermaas]

Great well thanks for feeding this back to us. I'll close this issue but feel free to open another issue if you have any other problems.