Initial Ti180 dev kit support

[samh-efx]

Also solves the missing file problem, which was due to initrd size being default at 8MB, while user can have a larger rootfs.cpio. So solution is to expose the initrd-size param of generate_dts to top.

BTW any ways to guard such cases? Any checking possible in bootloader code?

[Dolu1990]

I'm not aware of any check possible. I would say, this kind of things should be checked by the linux kernel, as the CPIO file format do say the file length, so linux itself would have all the require information. Maybe there is a warning message durring boot ?

[samh-efx]

I'm not aware of any check possible. I would say, this kind of things should be checked by the linux kernel, as the CPIO file format do say the file length, so linux itself would have all the require information. Maybe there is a warning message durring boot ?

Hm... make sense. The related message in dmesg below, too bad kernel didn't warn anything:

[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x000000007fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff]
...
[    0.000000] Kernel command line: console=liteuart earlycon=liteuart,0xf0001000 rootwait root=/dev/ram0

[Dolu1990]

@samh-efx The regression tests are failing, is it because this PR is waiting on something else to be merged in litex ?

[sammhho]

@samh-efx The regression tests are failing, is it because this PR is waiting on something else to be merged in litex ?

For the Ti180 target it definitely needs https://github.com/litex-hub/litex-boards/pull/441 to be fixed; But I'm not sure why it seems to be breaking the build against stlv7325 board as well...

With Florent's patch Naxriscv and Rocket will now build against Ti180, but the resulting bitstream show nothing on uart for boot loading.

[Dolu1990]

@samh-efx

NaxRiscv will not work on Efinix, because of the following issue (as far my understanding goes):

NaxRiscv define many memories with asycronus read (to be inferred as distributed ram in Xilinx FPGA for instance). And so it assume that when there is a write on address A at cycle 0, you can asycronously read the value written at that same address on the next cycle.

| W |   |
|   | R |

The issue is that the Efinity tool will infer some of the memores as block ram without the proper read after write policy on Titanium as the block ram do not support write first policy (unlike Trion), and do not add bypass logic either.

On my tests, that was corrupting the state of the CPU after 32 instructions.

When i added by hand the write to read bypass logic on all asyncronus memory read the CPU was working.

It is possible that rocket hit the same kind of issues ?

[sammhho]

@samh-efx

NaxRiscv will not work on Efinix, because of the following issue (as far my understanding goes):

NaxRiscv define many memories with asycronus read (to be inferred as distributed ram in Xilinx FPGA for instance). And so it assume that when there is a write on address A at cycle 0, you can asycronously read the value written at that same address on the next cycle.

| W |   |
|   | R |

The issue is that the Efinity tool will infer some of the memores as block ram without the proper read after write policy on Titanium as the block ram do not support write first policy (unlike Trion), and do not add bypass logic either.

On my tests, that was corrupting the state of the CPU after 32 instructions.

When i added by hand the write to read bypass logic on all asyncronus memory read the CPU was working.

It is possible that rocket hit the same kind of issues ?

@Dolu1990 Thanks for letting me know, that's news to me. Our synthesis team should take a look at what's the problem.

Can you point to me name of some example ram modules that's experiencing such cases? Say are RamAsyncMwXor_*, RamAsyncMwMux some of them, or just any ram that contains the (* ram_style = "distributed" *) pragma would be the case? Or if different rams would go by the same name prefix, can you paste an example code of such ram module here? Is it anything like this?

  (* ram_style = "distributed" *) reg [0:0] ram_0 [0:63];
  (* ram_style = "distributed" *) reg [0:0] ram_1 [0:63];

  always @(posedge clk) begin
    if(io_writes_0_valid) begin
      ram_0[io_writes_0_payload_address] <= writes_0_xored;
    end
  end

  assign _zz_ram_0_port1 = ram_0[io_writes_1_payload_address];
  assign _zz_ram_0_port2 = ram_0[io_read_0_cmd_payload];
  assign _zz_ram_0_port3 = ram_0[io_read_1_cmd_payload];
  assign _zz_ram_0_port4 = ram_0[io_read_2_cmd_payload];
  assign _zz_ram_1_port0 = ram_1[io_writes_0_payload_address];
  always @(posedge clk) begin
    if(io_writes_1_valid) begin
      ram_1[io_writes_1_payload_address] <= writes_1_xored;
    end
  end

  assign _zz_ram_1_port2 = ram_1[io_read_0_cmd_payload];
  assign _zz_ram_1_port3 = ram_1[io_read_1_cmd_payload];
  assign _zz_ram_1_port4 = ram_1[io_read_2_cmd_payload];

Does simulation results in the same error you see?

[Dolu1990]

(@samh-efx and me had a call concerning the synthesis issue)