-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial Ti180 dev kit support #312
Conversation
I'm not aware of any check possible. |
Hm... make sense.
|
@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 litex-hub/litex-boards#441 to be fixed; With Florent's patch Naxriscv and Rocket will now build against Ti180, but the resulting bitstream show nothing on uart for boot loading. |
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.
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. Can you point to me name of some example ram modules that's experiencing such cases? (* 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? |
(@samh-efx and me had a call concerning the synthesis issue) |
Closing since we should first have good initial Ti180 support in LiteX-Boards and issue has been been updated recently. |
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 ofgenerate_dts
to top.BTW any ways to guard such cases? Any checking possible in bootloader code?