Briey Soc: Framebuffer display flickered

[jmio]

Hi.

I am using the Briey SoC included in the demo with an Anlogic EG4S20 (Sipeed Tang Primer board), clocked at 50MHz. Briey SoC on Sipeed Tang Primer

With the 2de35e6 version, the FPGA's internal SDRAM could be assigned to the frame buffer (16bpp, 800x480pixel), which was displayed on the LCD without any problem.

However, when I updated VexRiscv to version 68e704f and regenerated Briey.v, the CPU seemed to be working fine, but the framebuffer display flickered. Also, in Anlogic TD5.0.3, the "Max Freq" after logic synthesis dropped from about 70MHz to about 51MHz.

Are there any changes you made?

[Dolu1990]

Hi,

There is quite a few changes in the SpinalHDL lib. For the VGA, especialy https://github.com/SpinalHDL/SpinalHDL/commit/c95d5d6bafa78b07341fd9063eb6c12be36e8f17#diff-4b37574d763dc49d38cf1a8f5a403ab2b920361069d8105468e3c0fb10c1385d

which ensure that the frame buffer is properly aligned to the vertical sync. So far i didn't had issue with it, but it is possible that in your case it trip on something

Can you give a try with that commit reversed ?

Else, it maybe due to a lack of memory bandwidth (due to some interconnect update in the AXI stuff)

about 70MHz to about 51MHz.

This maybe due to a change of the AXI interconnect default pipelining.

Can you send me the timing analysis report from the place and route flow ? Then i can check out where the issue is.

[Dolu1990]

I may have reproduce you flikering issue in simulation ^^ I'm checking it now

[Dolu1990]

The VGA issue is now fixed ^^ You need to use SpinalHDL dev with Vexriscv dev for it to work.

Still, let's me know the timings issues you had.

[jmio]

Hello.

Thank you for your answer. I have uploaded two timing reports. with 2de35e6 71MHz with 68e704f 51MHz Is this file correct?

Thank you for finding the problem while I was writing my reply.

I'll try the dev build now.

[Dolu1990]

I just pushed one fix in dev, i had some debug stuff in the briey config that i comited by accident. So, if you was trying the new dev, you need to pull it again XD

Sorry (This isn't related to your initial issue)

About your configuration, you enabled compressed instruction right ?

If so, one good thing to improve timings is to turn on the IBusCachedPlugin injectorStage to true.

I'm currently running some synthesis FMax regressions to see if i can see some patterns there XD

[jmio]

Please tell me. How do I change the Spinal HDL used by VexRiscv to a dev branch?

[Dolu1990]

Ahhh so basicaly, if you want to use VexRiscv / SpinalHDL dev, you need to clone them both in a directory.

Then VexRiscv will implicitly use ../SpinalHDL (https://github.com/SpinalHDL/VexRiscv/blob/dev/build.sbt#L20)

So nothing to change on your side, just getting the right branches

[jmio]

Thank you. I did not know how it worked.

[Dolu1990]

no worries ^^

[jmio]

I tried a dev build. I tried both without and with "injectorStage = true", and in both cases, TD stopped with an error. ErrorLog

[Dolu1990]

Ahhh damned, seems like there is some inferation issues ?

+-------------------------------------------------------------------------------+
|Instance          |Module              |lut    |ripple |seq    |bram   |dsp    |
+-------------------------------------------------------------------------------+
|top               |top                 |26252  |964    |3720   |11     |4      |
|  u_briey         |Briey               |25625  |830    |3370   |8      |4      |
|    axi_core_cpu  |VexRiscv            |4393   |426    |1189   |4      |4      |
|    axi_sdramCtrl |Axi4SharedSdramCtrl |245    |47     |292    |0      |0      |
|      ctrl        |SdramCtrl           |197    |27     |258    |0      |0      |
|    jtagBridge_1  |JtagBridge          |59     |0      |123    |0      |0      |
+-------------------------------------------------------------------------------+

There is a lot of LUT used somewere, probably some ram not being infered as fpga ram block ? There was a little change in the way ram were emited by SpinalHDL it maybe that

[Dolu1990]

Do you have a more detailed hearchy report ? seems like it is missing quite a few components.

[Dolu1990]

Ahhh seems like many ram are infered as distributed ram :

SYN-1027 : Infer Logic DRAM(al_ram_ways_0_tags) read 128x22, write 128x22 SYN-1023 : Infer 1 Logic DRAMs, 1 Logic BRAMs. SYN-1016 : Merged 2 instances. SYN-1025 : Merged 1 RAM ports. SYN-1027 : Infer Logic DRAM(al_ram_ways_0_data_symbol0) read 1024x8, write 1024x8 SYN-1027 : Infer Logic DRAM(al_ram_ways_0_data_symbol1) read 1024x8, write 1024x8 SYN-1027 : Infer Logic DRAM(al_ram_ways_0_data_symbol2) read 1024x8, write 1024x8 SYN-1027 : Infer Logic DRAM(al_ram_ways_0_data_symbol3) read 1024x8, write 1024x8 SYN-1027 : Infer Logic DRAM(al_ram_ways_0_tags) read 128x22, write 128x22 SYN-1023 : Infer 5 Logic DRAMs, 0 Logic BRAMs. SYN-1016 : Merged 23 instances. SYN-1027 : Infer Logic DRAM(al_ram_ram_symbol0) read 8192x8, write 8192x8 SYN-1027 : Infer Logic DRAM(al_ram_ram_symbol1) read 8192x8, write 8192x8 SYN-1027 : Infer Logic DRAM(al_ram_ram_symbol2) read 8192x8, write 8192x8 SYN-1027 : Infer Logic DRAM(al_ram_ram_symbol3) read 8192x8, write 8192x8 SYN-1023 : Infer 4 Logic DRAMs, 0 Logic BRAMs. SYN-1016 : Merged 9 instances. SYN-1027 : Infer Logic DRAM(al_ram_ram_symbol0) read 4096x8, write 4096x8 SYN-1027 : Infer Logic DRAM(al_ram_ram_symbol1) read 4096x8, write 4096x8 SYN-1027 : Infer Logic DRAM(al_ram_ram_symbol2) read 4096x8, write 4096x8 SYN-1027 : Infer Logic DRAM(al_ram_ram_symbol3) read 4096x8, write 4096x8 SYN-1023 : Infer 4 Logic DRAMs, 0 Logic BRAMs.

that's likely part of the issue.

[jmio]

Thank you for your answer. It has stopped with an error, so this is all the log I have.

[jmio]

If there is anything I can try, please let me know.

[Dolu1990]

Could you try with keep_hierarchy enabled ? This may preserve a better hearchical report, which would point out the issue more accuratly.

[Dolu1990]

I suspect that if you replace https://github.com/SpinalHDL/SpinalHDL/blob/dev/core/src/main/scala/spinal/core/internals/ComponentEmitterVerilog.scala#L1197 to https://github.com/SpinalHDL/SpinalHDL/blob/dev/core/src/main/scala/spinal/core/internals/ComponentEmitterVerilog.scala#L1203 by

                emitClockedProcess((tab, b) => {
                  val symbolCount = memReadWrite.mem.getMemSymbolCount()
                  b ++= s"${tab}if(${emitExpression(memReadWrite.chipSelect)}) begin\n"
                  emitRead(b, memReadWrite.mem, memReadWrite.address, memReadWrite, tab + "  ")
                  b ++= s"${tab}end\n"
                }, null, tmpBuilder, memReadWrite.clockDomain, false)

                emitClockedProcess((tab, b) => {
                  val symbolCount = memReadWrite.mem.getMemSymbolCount()
                  emitWrite(b, memReadWrite.mem,s"${emitExpression(memReadWrite.chipSelect)} && ${emitExpression(memReadWrite.writeEnable)} ", memReadWrite.address, memReadWrite.data, memReadWrite.mask, memReadWrite.mem.getMemSymbolCount(), memReadWrite.mem.getMemSymbolWidth(),tab)
                }, null, tmpBuilder, memReadWrite.clockDomain, false)

it may avoid the issue.

let's me know :)

[jmio]

keep_hierarchy option is now "AUTO".The options are AUTO,FLATTEN, MANUAL, and ALL, which one is better?

[jmio]

OK, I'll try the two comments above.

[Dolu1990]

ALL will preserve everything. (will increase a bit the area and make timing a bit worst)

[jmio]

ErrorLog_KeepAll Uploaded.

[jmio]

The TD is still running, but the emitClockedProcess patch above has eliminated the error.

[jmio]

The error is gone, but when I load the bit file, the SoC bricks (^^;

[jmio]

Thank you for all your support. I'll upload the current log for now and go to bed today :-) SynthLog Timing

[Dolu1990]

Good night ^^

[jmio]

Good morning.

I've added only VgaCtrl.scala(https://github.com/SpinalHDL/SpinalHDL/commit/2224b2599ecd468decf635125dfa1ee2ecd940a8) to version 68e704f. It is now flicker-free. Thanks.

The MaxFreq thing is beyond my understanding (^^;

[jmio]

I tried to create a system with almost the same configuration in ECP5 (yosys + nextpnr), and created a dev-dev combination of Spinal/VexRiscv. Briey SoC on ICESugar Pro#dev However, the system stopped without starting as well...

yosys_report nextpnr_report

[Dolu1990]

Hi ^^

So if i understand well, now the dev-dev soc do not boot on your Sipeed Tang Primer, nor on your icesugar right ?

Does the soc work in simulation ?

[jmio]

So if i understand well, now the dev-dev soc do not boot on your Sipeed Tang Primer, nor on your icesugar right ?

Yes. looks like freeze. There is no boot message from the UART (in my firmware).

Does the soc work in simulation ?

I'm actually new to trying simulations, am I right?

Attached is a screenshot of what I ran in WSL2. On the top left is the VGA (X410 XServer Window) and on the right is the console resulting from running "make clean run".

[Dolu1990]

One thing, is that i have seen that you enabled risc-v compressed instruciton set right ?

[jmio]

One thing, is that i have seen that you enabled risc-v compressed instruciton set right ?

Yes, I did. I forgot about it. I put the Briey.scala file back in and ran it again. The console message is different, is this normal? The VGA was still black.

[Dolu1990]

Yes, that's normal, there is some reset glitchies with the sdram model ^^ nothing bad.

So then what you can try, is to connect it with openocd and load some binaries in it ^^ :

Simulation shell

VexRiscv/src/test/cpp/briey$ make clean run

Openocd shell

openocd_riscv$ src/openocd -f tcl/interface/jtag_tcp.cfg -c "set BRIEY_CPU0_YAML ????/cpu0.yaml" -f tcl/target/briey.cfg

GDB shell

riscv??-??-??-gdb dhrystone.elf
target remote localhost:3333
set remotetimeout 60
set arch riscv:rv32
monitor reset halt
load
continue

There is the dhrystone.elf :

dhrystone.elf.zip

You should get in the simulation shell

BOOT
SDRAM : READ Wrong DQ direction
SDRAM : write in closed bank
SDRAM : write in closed bank
SDRAM : MODE REGISTER DEFINITION CAS=3 burstLength=0
CONNECTED
SDRAM : MODE REGISTER DEFINITION CAS=3 burstLength=0
SDRAM : MODE REGISTER DEFINITION CAS=3 burstLength=0
SDRAM : MODE REGISTER DEFINITION CAS=3 burstLength=0

Dhrystone Benchmark, Version 2.1 (Language: C)

Program compiled without 'register' attribute

Please give the number of runs through the benchmark: 
Execution starts, 200 runs through Dhrystone
Execution ends

Final values of the variables used in the benchmark:

Int_Glob:            5
        should be:   5
Bool_Glob:           1
        should be:   1
Ch_1_Glob:           A
        should be:   A
Ch_2_Glob:           B
        should be:   B
Arr_1_Glob[8]:       7
        should be:   7
Arr_2_Glob[8][7]:    210
        should be:   Number_Of_Runs + 10
Ptr_Glob->
  Ptr_Comp:          1073765228
        should be:   (implementation-dependent)
  Discr:             0
        should be:   0
  Enum_Comp:         2
        should be:   2
  Int_Comp:          17
        should be:   17
  Str_Comp:          DHRYSTONE PROGRAM, SOME STRING
        should be:   DHRYSTONE PROGRAM, SOME STRING
Next_Ptr_Glob->
  Ptr_Comp:          1073765228
        should be:   (implementation-dependent), same as above
  Discr:             0
        should be:   0
  Enum_Comp:         1
        should be:   1
  Int_Comp:          18
        should be:   18
  Str_Comp:          DHRYSTONE PROGRAM, SOME STRING
        should be:   DHRYSTONE PROGRAM, SOME STRING
Int_1_Loc:           5
        should be:   5
Int_2_Loc:           13
        should be:   13
Int_3_Loc:           7
        should be:   7
Enum_Loc:            1
        should be:   1
Str_1_Loc:           DHRYSTONE PROGRAM, 1'ST STRING
        should be:   DHRYSTONE PROGRAM, 1'ST STRING
Str_2_Loc:           DHRYSTONE PROGRAM, 2'ND STRING
        should be:   DHRYSTONE PROGRAM, 2'ND STRING

Clock cycles=101523 
DMIPS per Mhz:                              1.12

let's me know how it goes ^^

[Dolu1990]

Note that by default, Briey do not implement RVC

[jmio]

Hello.

I followed the steps and the simulation is working in dev-dev version.

The circuit I added may be bad. I have added 2 channels of APB, does it have any effect?

Also, RVC seems to have an effect. I'll try it out.

[jmio]

Hmm, I still can't get the modified version to start in the simulator.

Even with the version I modified. If I set "compressedGen = false", it starts.

It seems that RVC is the cause.....

[jmio]

I have only a small amount of BRAM (for monitor program) and I want to run it with RVC enabled. Is there a good way to do this?

My Modified Briey.scala

[Dolu1990]

I can see that in your configs you change the sdram configuration

ex : def layout = SdramLayout( generation = SDR, bankWidth = 2, columnWidth = 8, rowWidth = 11, dataWidth = 32 )

This will not work well with the simulation model of the sdram.

Did you adapted the

    SdramConfig *sdramConfig = new SdramConfig(
        2,  //byteCount
        4,  //bankCount
        1 << 13, //rowSize
        1 << 10  //colSize
    );

of main.cpp ? Else the sdram read / write will get corrupted :)

[Dolu1990]

One thing i noticed, is that your My Modified Briey.scala wasn't based on SpinalHDL 1.6.1 right ? but a older version ?

[jmio]

Thanks for the advice.

I use sbt "runMain vexriscv.demo.Briey" (not "BrieyTangPrimer") command for create "Briey.v" for simulation, So,I think the simulation is done with the default SDRAM setting (IS42x320D).

I would like to find out why the simulation fails to start, since it can be successfully started with this configuration if RVC is not enabled.

One thing i noticed, is that your My Modified Briey.scala wasn't based on SpinalHDL 1.6.1 right ? but a older version ?

Sorry for the confusion. I couldn't attach the ".scala" or ".v" files to this field, so I posted a link to the repository. The header of the dev-dev "Briey.v" that I'm using for the simulation looks like this

// Generator : SpinalHDL v1.6.1 git head : 8addf7fa9969a9cb92e967e4bc42178878175609 // Component : Briey // Git hash : 5f5f4afbf2594cf95d9c1e0c71880dea83828a34

[Dolu1990]

Ahhh So, i tried your Briey.scala, and it worked in simulation for me.

One thing, is that if you just run the simulation, it will not run any binary, you realy need to load stuff into it via openocd / gdb. Have you done that ?

Can you tell me more about what it mean to fail to start ?

One thing, currently, if you access one of your two external apb bus this will freeze the CPU, as their PREADY isn't set.

You can run the sim as : make clean run VGA=yes TRACE=yes

To generate a Briey.fst file which will show you everything, but be aware, it slow down the sim and take space on the harddrive.

Also, can you send me the xxx.elf you are using ?

[jmio]

So, i tried your Briey.scala, and it worked in simulation for me.

Thank you for testing my Briey.scala.

One thing, is that if you just run the simulation, it will not run any binary, you realy need to load stuff into it via openocd / gdb. Have you done that ?

I ran the following command (almost identical to the one you gave me)

Create Verilog & Simurator

VexRiscvDev$ sbt "runMain vexriscv.demo.Briey"
VexRiscvDev$ cd src/test/cpp/briey
VexRiscvDev/src/test/cpp/briey$ make clean run

Openocd Shell

openocd_vexriscv$ src/openocd -f tcl/interface/jtag_tcp.cfg -c "set BRIEY_CPU0_YAML /home/mio/VexRiscv/cpu0.yaml" -f tcl/target/briey.cfg

GDB Shell

export PATH=$PATH:$(echo ~/litex/riscv64-*/bin/)
riscv64-unknown-elf-gdb dhrystone.elf
--
(gdb)target remote localhost:3333
(gdb)set remotetimeout 60
(gdb)set arch riscv:rv32
(gdb)monitor reset halt
(gdb)load
(gdb)continue

As you can see, the toolchain is the one we use in litex. For elf, I used the one from the Dhrystone benchmark that was sent to me.

As for the phrase "won't start". When I run the above procedure with Briey.v created with RVC enabled, Dhrystone does not run and the screen stops in the following state.

You can run the sim as : make clean run VGA=yes TRACE=yes

To generate a Briey.fst file which will show you everything, but be aware, it slow down the sim and take space on the harddrive.

I'm going to try this now.

[jmio]

Very interesting, but I changed "make clean run" to "make clean run VGA=yes TRACE=yes" and Dhrystone worked (although very slow as you said).

A very large file "Briey.fst" was generated.

[Dolu1990]

hmmm, i guess there may be some reset issue which randomly pop up in the sim

[jmio]

Incidentally, gdb when "not starting" seemed to stop at the following location when I stopped it with Ctrl+C. I'm not sure why, but is the CPU working?

crtStart () at src/../../../../resources/crt.S:6
6       src/../../../../resources/crt.S: そのようなファイルやディレクトリはありません.
The target architecture is assumed to be riscv:rv32
JTAG tap: fpga_spinal.bridge tap/device found: 0x10001fff (mfg: 0x7ff (<invalid>), part: 0x0001, ver: 0x1)
Loading section .memory, size 0x2b34 lma 0x40000000
Loading section .text.startup, size 0x5c lma 0x40002b34
Loading section .rodata, size 0x7b8 lma 0x40002b90
Loading section .data, size 0x1c lma 0x40003348
Loading section .vector, size 0x138 lma 0x80000000
Start address 0x80000000, load size 13468
Transfer rate: 4 KB/sec, 2693 bytes/write.
^C
Program received signal SIGINT, Interrupt.
infinitLoop () at src/../../../../resources/crt.S:96              <============
96      in src/../../../../resources/crt.S
(gdb) quit
A debugging session is active.

        Inferior 1 [Remote target] will be detached.

Quit anyway? (y or n) y

[Dolu1990]

Hmm i have the same issue now with TRACE=no. i'm on it.

About crts.S line 96, this seems good, it is when the programm returned from main.

infinitLoop: j infinitLoop

It maybe a issue with the serial stuff

[Dolu1990]

So, that's weird, seems like it is either a verilator testbench issue, either a uart peripheral issue in the sim, that depending the initial state of the sim, isn't getting the uart stuff right.

[Dolu1990]

What is happening if you use your executable in the sim with trace=yes ? Is it booting ?

[jmio]

Yes. A message is displayed on the screen and Dhrystone has been successfully executed until the end.

[jmio]

The problem of no message with TRACE=no seems to occur not only with dev-dev, but also with 2de35e6 (the version I mentioned as working fine at the top of the topic).

So it doesn't seem to be related to my problem with "BrieyTangPrimer" not working.

The flickering has been resolved.

Should I close this "Issue" for now?

[jmio]

I'll write another topic when I've sorted out the issues and have something to ask. OK?