tommythorn
commented
1 year ago (Ah, I spot a typo; it should have been q[i] = !q[(i + 1) % W] ^ lfsr[i]; but that doesn't change the fact that it shouldn't crash)
Closed tommythorn closed 1 year ago
tommythorn
commented
1 year ago (Ah, I spot a typo; it should have been q[i] = !q[(i + 1) % W] ^ lfsr[i]; but that doesn't change the fact that it shouldn't crash)
tommythorn
commented
1 year ago Ha, it seems it's the wire [999:0] q; that is the issue.
rowanG077
commented
1 year ago I cannot duplicate this crash on current nextpnr master branch state.
Thinking it may be a hidden issue which WASM triggers I ran PnR of this design under valgrind. Except for some python interpreter invalid memory accesses it comes back clean. This might be an issue with the WASM version itself.
tommythorn
commented
1 year ago Sorry, it took me a good while to sort out how to build nextpnr-ecp5, again.
Indeed, it doesn't crash with a native build. Note, I was using a different test case that also crashed yowasp-nextpnr_ecp5:
module top(input [6:0] btn,
output wire [7:0] led);
wire ro1;
wire ro2;
wire ro3;
(* keep *) LUT4 #(.INIT(16'd1)) i_inv1 (.Z(ro2), .A(ro1), .B(1'b0), .C(1'b0), .D(1'b0));
(* keep *) LUT4 #(.INIT(16'd1)) i_inv2 (.Z(ro3), .A(ro2), .B(1'b0), .C(1'b0), .D(1'b0));
(* keep *) LUT4 #(.INIT(16'd1)) i_inv3 (.Z(ro1), .A(ro3), .B(1'b0), .C(1'b0), .D(1'b0));
reg flop;
wire dclk_o = flop;
always @(posedge ro3) begin
flop <= ~flop;
end
reg [26:0] cntr = 0;
always @(posedge flop) cntr <= cntr + 1;
assign led = btn[0] ? cntr[26:26-7] : cntr[26-8:26-7-8];
endmoduleThe wasm version is not maintained here. I guess you'd best ask the maintainers of that version. I'm not convinced this is an actual nextpnr issue.
whitequark
commented
1 year ago @rowanG077 I am the maintainer of the Wasm version and I am also a YosysHQ member, so it is effectively maintained here.
The only way to crash the Wasm runtime, besides an explicit abort, is a write to unallocated memory. If this is not an abort then this is a bug in nextpnr.
@tommythorn Please attach a script that reproduces this issue, or at least a nextpnr command line.
whitequark
commented
1 year ago @tommythorn Nevermind, I reproduced this. The backtrace is:
wasmtime._trap.Trap: error while executing at wasm backtrace:
0: 0x97cd3 - <unknown>!<wasm function 2312>
1: 0x8f09a - <unknown>!<wasm function 2187>
2: 0x8f0c7 - <unknown>!<wasm function 2188>
3: 0xa4713 - <unknown>!<wasm function 2495>
4: 0xed1a0 - <unknown>!<wasm function 2811>
5: 0xa621a - <unknown>!<wasm function 2508>
6: 0xb5c55 - <unknown>!<wasm function 2609>
7: 0xb09cc - <unknown>!<wasm function 2590>
8: 0x327fb5 - <unknown>!<wasm function 3959>
9: 0x97ad5 - <unknown>!<wasm function 2291>
10: 0x2024 - <unknown>!<wasm function 23>
Caused by:
wasm trap: wasm `unreachable` instruction executedThis is an explicit abort I've referred to earlier, which can have many different causes. I'll take a look.
tommythorn
commented
1 year ago the attached zip has a Makefile, isn’t that sufficient?TommyOn Aug 18, 2023, at 20:55, Catherine @.***> wrote: @rowanG077 I am the maintainer of the Wasm version and I am also a YosysHQ member, so it is effectively maintained here. The only way to crash the Wasm runtime, besides an explicit abort, is a write to an unallocated memory. If this is not an abort then this is a bug in nextpnr. @tommythorn Please attach a script that reproduces this issue, or at least a nextpnr command line.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
rowanG077
commented
1 year ago @whitequark I see. I thought the WASM was an unofficial/unaffiliated project I guess I was wrong. Of course if nextpnr itself is really the issue it will be fixed here.
tommythorn
commented
1 year ago The YOWASP binaries are actually pretty awesome for me as I frequently switch between many hosts and platforms (I would love it if they supported the Artix/Kintex 7 work too).
whitequark
commented
1 year ago I see. I thought the WASM was an unofficial/unaffiliated project I guess I was wrong. Of course if nextpnr itself is really the issue it will be fixed here.
It is unofficial in the sense that it is not released by the YosysHQ organization. However it is maintained by someone who is a part of the Yosys project, so it is maintained here even if it is unofficial. Which is a little confusing, but such is life!
whitequark
commented
1 year ago I would love it if they supported the Artix/Kintex 7 work too
I am only building upstream nextpnr so as soon as that ends up in upstream nextpnr I am happy to build it.
whitequark
commented
1 year ago @tommythorn Okay, I've triaged this. yowasp-nextpnr-ecp5 version 0.6 crashes with a stack overflow:
(Wasm does not provide stack overflow protection.) I would consider this a nextpnr bug.
However, commit 053dfc98 that I built with more debug information locally does not:
So this can probably be closed.
gatecat
commented
1 year ago Thinking about it it was probably fixed in https://github.com/YosysHQ/nextpnr/pull/1160.
whitequark
commented
1 year ago @tommythorn You can install nightly builds of YoWASP tools from Test PyPI:
pip install --pre -i https://test.pypi.org/simple/ yowasp-nextpnr-ecp5Sorry to keep going @whitequark -- let me know where to direct these details.
~On my MacBook Pro I got~ Fixed by installing the official yowasp-yosys first.
(pip install doesn't work directly on Ubuntu; something about externally managed environments and virtual environments -- Python is a massive headache)
The design below crashed both my old, self-built, nextpnr-ecp5 and the current version from https://yowasp.org/ (I apologize for my contorted attempt at forcing yosys to keep my ring oscillator -- improvements welcome).
I've attached the relevant files:
files.zip