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;
endmoduleChanging 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: