-
Notifications
You must be signed in to change notification settings - Fork 223
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
icetime - 1000020.4ns with UP5k #114
Comments
The problem is an inferred latch in your ram_test.v, because the decoder doesn't cover all possibilities. Without totally rewriting the decoder, the simplest fix I see is to add an "else" clause as follows (choose your own default value) :
With the fix you get a timing estimate of 37.25MHz. |
I will keep the issue open however, as a reminder to myself to add a nicer error message in icetime in this situation. |
I'd personally prefer a default assignment in the beginning of the block. something like this:
|
OMG, a freshman's mistake :) Thanks! |
I get a similar report from icetime (with loop-start, the time starting from ~1000000 ns, etc.) with the following Verilog module: module repro(clk, out);
input clk;
output out;
reg [8:0] data;
always @(posedge clk) begin
if (data == 9'd 10)
data <= 9'b 0;
else
data <= data + 1;
end
assign out = data < 9'd 8;
endmodule Changing the register width from Putting aside the question of whether this is good Verilog, I'd really like to figure out why the icetime report looks the way it does. Yosys/Nextpnr/icetime output: yosys-nextpnr-icetime.log |
Does the 10000XX.XX indicate a design issue here (yesterday's icestorm/arachne/yosys pull from github and reinstall), chip ice40UP5k?
Sources: https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB/tree/master/icestorm%20version
The text was updated successfully, but these errors were encountered: