BrieySoC：Can't Start "modified" SoC

[jmio]

Hi,

I found out a few things about "modified" Briey SoC not working on the actual device (ECP5, ICESugarPro).

For "non-booting" FPGAs with dev-dev bit files wrote:

• OpenOCD can be connected to JTAG of SoC.
• When I connect with gdb (via OpenOCD) and transfer my program as in the simulator, it works fine.

So, I think that some kind of initialization is not working.

As I have discussed with you at https://github.com/SpinalHDL/VexRiscv/issues/198, "modified" Briey SoC which use the master branch (68e704f) with SpinalHDL1.6.0 starts program without any problem, so I think there was some kind of change before it became dev branch now.

Is there any way to find out?

[jmio]

Hello.

As it turns out, we're up and running!

However, I don't know myself why it started to work. What I did was.

First of all, in order to make sure that the SoC was booting from BRAM and not from the debugger, I embedded the "muraxDemo.hex" that comes with the Briey demo, tied the LSB of the gpio to the led, and burned it to the actual device. When I did this, the LED flashed, so I was able to confirm that the SoC was booting.

Next, I thought it might be wrong to manually replace the firmware (replace $readmem after the Verilog file is generated), so I changed the "muraxDemo.hex" to my own HEX, synthesized Verilog with sbt, and ran it on the actual device. It worked.

Finally, I tried to replace $readmem after the Verilog file was generated, which I couldn't do yesterday, and to my surprise, it worked!

Anyway, thank you very much.

I'm afraid this is not related to SoC, but can you tell me about it?

How can I check the BRAM memory without loading the elf file on the simulator or actual device? I tried to run the x command with gdb on the actual device, but I got the following error.

(gdb) x 0x80000000
0x80000000: Cannot access memory at address 0x80000000
(gdb) quit

When xxx.elf is loaded, the it will display correctly as

(gdb) x 0x80000000
0x80000000 <crtStart>: 0x80000137

[jmio]

Since ECP5 worked so well, I thought I'd try it on EG4S20, so I generated Briey.v from the same dev-dev version and tried it. When I tried to generate from the same dev-dev version, I got the following error, which seems to be a failure of the BRAM inference that I have seen before.

PHY-9009 ERROR: Design's mslice number = 13770, exceeds the limit 4900.

ErrorLog

This has been taken care of .... (https://github.com/SpinalHDL/SpinalHDL/commit/8addf7fa9969a9cb92e967e4bc42178878175609)

I had no problem with yosys + nextpnr for ECP5. I think it's a TD problem, is there any way to improve it?

The environment that generated Briey.v is

// Generator : SpinalHDL v1.6.1 git head : 3100c81b37a04715d05d9b9873c3df07a0786a9b
// Component : Briey
// Git hash : 35754a070963a216a6673e454f0db4565ba8d993

[Dolu1990]

Cool ^^

How can I check the BRAM memory without loading the elf file on the simulator or actual device?

I would say, do not use GDB, but openocd instead, via a script, or via the telnet.

For instance, telnet localhost 4444 mdw 0x80000000 16

I'm not exactly sure about how to do it with gdb.

EG4S20

So, you are right, sems like it do not inver the following code in a block ram :

  always @(posedge io_axiClk) begin
    if(stage0_fire) begin
      _zz_ram_port0[7:0] <= ram_symbol0[_zz_io_axi_r_payload_data];
      _zz_ram_port0[15:8] <= ram_symbol1[_zz_io_axi_r_payload_data];
      _zz_ram_port0[23:16] <= ram_symbol2[_zz_io_axi_r_payload_data];
      _zz_ram_port0[31:24] <= ram_symbol3[_zz_io_axi_r_payload_data];
    end
  end

  always @(posedge io_axiClk) begin
    if(io_axi_w_payload_strb[0] && stage0_fire && stage0_payload_fragment_write ) begin
      ram_symbol0[_zz_io_axi_r_payload_data] <= _zz_io_axi_r_payload_data_1[7 : 0];
    end
    if(io_axi_w_payload_strb[1] && stage0_fire && stage0_payload_fragment_write ) begin
      ram_symbol1[_zz_io_axi_r_payload_data] <= _zz_io_axi_r_payload_data_1[15 : 8];
    end
    if(io_axi_w_payload_strb[2] && stage0_fire && stage0_payload_fragment_write ) begin
      ram_symbol2[_zz_io_axi_r_payload_data] <= _zz_io_axi_r_payload_data_1[23 : 16];
    end
    if(io_axi_w_payload_strb[3] && stage0_fire && stage0_payload_fragment_write ) begin
      ram_symbol3[_zz_io_axi_r_payload_data] <= _zz_io_axi_r_payload_data_1[31 : 24];
    end
  end

Does EG4S20 has simple dual port block ram ? If yes, then maybe we can help him infer it by synmplifying some if statements :

  wire a = io_axi_w_payload_strb[0] && stage0_fire && stage0_payload_fragment_write;
  wire b = io_axi_w_payload_strb[1] && stage0_fire && stage0_payload_fragment_write;
  wire c = io_axi_w_payload_strb[2] && stage0_fire && stage0_payload_fragment_write;
  wire d = io_axi_w_payload_strb[3] && stage0_fire && stage0_payload_fragment_write;
  always @(posedge io_axiClk) begin
    if(a) begin
      ram_symbol0[_zz_io_axi_r_payload_data] <= _zz_io_axi_r_payload_data_1[7 : 0];
    end
    if(b) begin
      ram_symbol1[_zz_io_axi_r_payload_data] <= _zz_io_axi_r_payload_data_1[15 : 8];
    end
    if(c ) begin
      ram_symbol2[_zz_io_axi_r_payload_data] <= _zz_io_axi_r_payload_data_1[23 : 16];
    end
    if(d ) begin
      ram_symbol3[_zz_io_axi_r_payload_data] <= _zz_io_axi_r_payload_data_1[31 : 24];
    end
  end

Could you give a try ? It may reduce the area for | axi_ram |Axi4SharedOnChipRam |12899 |22 |69 |0 |0 | | axi_ram2 |Axi4SharedOnChipRam_1 |6586 |22 |68 |0 |0 |

[jmio]

Hi,

Thanks for the advice on the memory read, I can just send the command directly to OpenOCD.

Regarding the BRAM memory inference.

Based on your advice I tried to rewrite the above block in Briey.v based on your advice. However, the result did not change.

‘‘‘ PHY-9009 ERROR: Design's mslice number = 13770, exceeds the limit 4900.

| axi_ram |Axi4SharedOnChipRam |12899 |22 |69 |0 |0 | | axi_ram2 |Axi4SharedOnChipRam_1 |6586 |22 |68 |0 |0 | ‘‘‘

I have committed the updated results to my repository.

[jmio]

This is a bit off topic, but...

I've been using BrieySoc with EG4S20 (TangPrimer) and ECP5 (ICE SugarPro) for a while now, for getting a portable FPGA computer toy.

I prefer to use it on bare metal rather than booting Linux, so MuraxSoc is attractive for its simplicity.

But I need SDRAM to load large applications and a frame buffer to connect an LCD. For expansion, I would like to be able to connect to the Wishbone bus and Avalon bus.

Looking at the SpinalHDL library, it seems to have a lot of parts for the bmb bus. Would SaxonSoc be suitable to achieve the above?

Looking at the "depricated" folder, there is a keyword for EG4S20, has it been ported in the past?

[jmio]

Hi,

As for the BRAM inference part, I was successful when I did the following. I just imitated SpinalHDL1.6.0...

  reg [7:0] _zz_ramsymbol_read;
  reg [7:0] _zz_ramsymbol_read_1;
  reg [7:0] _zz_ramsymbol_read_2;
  reg [7:0] _zz_ramsymbol_read_3;

and

always @(*) begin
    _zz_ram_port0 = {_zz_ramsymbol_read_3, _zz_ramsymbol_read_2, _zz_ramsymbol_read_1, _zz_ramsymbol_read};
  end
  always @(posedge io_axiClk) begin
    if(stage0_fire) begin
      _zz_ramsymbol_read <= ram_symbol0[_zz_io_axi_r_payload_data];
      _zz_ramsymbol_read_1 <= ram_symbol1[_zz_io_axi_r_payload_data];
      _zz_ramsymbol_read_2 <= ram_symbol2[_zz_io_axi_r_payload_data];
      _zz_ramsymbol_read_3 <= ram_symbol3[_zz_io_axi_r_payload_data];
    end
  end

Result

|    axi_ram                                                         |Axi4SharedOnChipRam      |77     |22     |37     |32     |0      |
|    axi_ram2                                                        |Axi4SharedOnChipRam_1    |76     |22     |36     |16     |0      |

Is it difficult to get the dev version to synthesize like this?

[Dolu1990]

Looking at the SpinalHDL library, it seems to have a lot of parts for the bmb bus. Would SaxonSoc be suitable to achieve the above?

Yes, SaxonSoc could be used for small baremetal SoC. but most of its usage was for big SoC.

I would say if you want to go the SaxonSoc way, start with https://github.com/SpinalHDL/SaxonSoc/blob/dev-0.3/hardware/scala/saxon/board/radiona/ulx3s/Ulx3sMinimal.scala as reference.

Quite a few soc were deprected following a big update. it was too much to carry on XD

But be aware, the SaxonSoc framework is a special kind of beast which is a aditional paradigm on the top of SpinalHDL

I would like to be able to connect to the Wishbone bus and Avalon bus.

bridges aren't hard to do, and for instance, there is wishbone to bmb bridge already in the lib :)

As for the BRAM inference part, I was successful when I did the following. I just imitated SpinalHDL1.6.0...

Hooooo nice, thanks :D So i wasn't aware of that change from 1.6.1. That was merged from a bigger pull request. I'm reverting back now (fix pushed with : https://github.com/SpinalHDL/SpinalHDL/commit/f6915910fa9fa690f7cec1332af67db753dc2a17)

[jmio]

Yes, SaxonSoc could be used for small baremetal SoC. but most of its usage was for big SoC. I would say if you want to go the SaxonSoc way, start with https://github.com/SpinalHDL/SaxonSoc/blob/dev-0.3/hardware/scala/saxon/board/radiona/ulx3s/Ulx3sMinimal.scala as reference.

Thanks for the advice. I have an ECP5 (ICESugarPro) on hand, so I can use it as is. I also ordered the ULX3S, but it has been greatly delayed due to the recent parts shortage, and I haven't received it yet (><).

But be aware, the SaxonSoc framework is a special kind of beast which is a aditional paradigm on the top of SpinalHDL

A special kind of beast? Oh... I'm getting more and more curious!

bridges aren't hard to do, and for instance, there is wishbone to bmb bridge already in the lib :)

Yes, I saw that and I would love to use it.

I'm reverting back now (fix pushed with : https://github.com/SpinalHDL/SpinalHDL/commit/f6915910fa9fa690f7cec1332af67db753dc2a17)

I tried to use it immediately. It's working well (^^)

Thank you very much!

[jmio]

For those of you using ICESugarPro, I would like to add that drag-and-drop writing using the JTAG chip (iCELink) may fail.

The title of this topic was mistakenly assumed to not work by me because of the above.

[Dolu1990]

A special kind of beast? Oh... I'm getting more and more curious!

Basicaly, saxonsoc was going through a long and sometime painefull road of trying new paradigmes XD Quite clunky in the first version, it is now much better.

Mostly in order to have automatic negotiations of slaves / master requirements / capabilities.

it is based on a similar concept than Scala Await / Async / Future, where you can define behaviour in advance which will then automaticaly wait on input parameters to be set. It is kind of a distributed way of specifying things.

it is based on : https://spinalhdl.github.io/SpinalDoc-RTD/master/SpinalHDL/Libraries/fiber.html

That is used as a toplevel SoC integration tool.

[jmio]

It looks like I have a long way to go to understand SaxonSoc, but I think it is worth a try.

I'm going to try the simplest example first (^^: