Closed m-chabot closed 6 years ago
Hi,
You are right, something is going wrong, apparently it doesn't pass the dhrystone benchmark, anymore, i will check it more in depth this evening, anyway thanks for the report : D I will let's you know when i have news.
So, i spotted the issue, and it is very likely a Verilator bug, when i disable Verilator optimisation (-O0) or enable the Verilator VCD generation everything is fine. I also tried to catch the bug by adding some assert and it show some impossible conditions.
I will do some additional checks.
Ok no, finaly i got it, the io_externalInterrupt of the top level wasn't set to zero in the testbench boot, so its value was randomly set by Verilator, but it look like he was always setting it to zero, until i changed the code base, which changed the moment were the random is applied to the pin, and conssecantly changed its initial value.
I submited a fix, it should be fine now. I can load/debug code with the Verilator Briey simulation. I hadn't exactly the same symptoms than you, so let's me know if the issue perssiste.
Hooo not only that but some weeks ago, the memory mapping of briey changed, have you seen it ?
Yes I have been bitten by it some times ago ;) Simulation is fine on my side. Briey is running on my fpga board also (only tested basic uart). I have ported it to this board: https://github.com/ChinaQMTECH/QM_XC7A35T_SDRAM , nice cheap one with vga/usb daughter board.
Hoo great : D
Hi,
I am working on porting Briey soc to Xilinx fpga board and have issue with sdram so I use simulator to extract reference waveform. I noticed a regression in briey soc simulation with https://github.com/SpinalHDL/VexRiscv/commit/d95793494942e334f9c643d2b61f231218714cc7
When using simulator it's no longer possible to load/execute code in sdram. Internal ram load/exec is fine. Tested with latest SpinalHDL, VexRiscSoftware (uart example) and gcc 6.1.0 (self build rv32i toolchain).