<daveshah>
I'm not convinced that initial on a wire is legal at all
<mwk>
I'm tempted to just revert the damn PR
<mwk>
whatever this is supposed to do, the result is that yosys treats the 'wire ... = const' line as a continuous assignment (reasonable), and the 'initial' block as if it was a combinatorial always block (not reasonable), resulting in multiple-drivers situation
<daveshah>
I think it would be valid if it was reg instead of wire
<daveshah>
and always instead of initial
<mwk>
yes, because then the line would just set the *initial* value
<mwk>
... except then it'd be a latch
<daveshah>
Yeah for some reason I thought i and j were constants
<daveshah>
then initial might have made sense
<daveshah>
Yeah its just nonsense
kraiskil has quit [Ping timeout: 256 seconds]
citypw has quit [Ping timeout: 240 seconds]
kraiskil has joined #yosys
citypw has joined #yosys
emeb has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
Forty-Bot has joined #yosys
evil_chuck has joined #yosys
<evil_chuck>
Hi all, I'm working on a basic PS/2 mouse design for ice40 FPGA. icetime gives me a timing estimate of 1000006.33 ns. How can I fix this?
<Lofty>
Trust the timing estimates from nextpnr, I think
<Lofty>
That will give the longest combinational path for your design anyway
<evil_chuck>
The default makefile uses arache-pnr, should I switch to nextpnr?
<Lofty>
Yes, arachne-pnr has been dead for a while
<Lofty>
Yeah, for about a year arachne-pnr has been replaced by nextpnr-ice40
<evil_chuck>
Ok, nextpnr gives me the following: ERROR: timing analysis failed due to presence of combinatorial loops, incomplete specification of timing ports, etc.
<Lofty>
Do you have latches in your design? That would probably break icetime too
<evil_chuck>
How do I tell? I don't have much experience.
<Lofty>
Can you upload the log somewhere? I can't remember exactly what it is, but Yosys will probably warn on it
<Lofty>
Since latches are something to be avoided as much as possible
<Lofty>
You most often get them from an incomplete case specification
<Lofty>
In that situation it needs to preserve the original value, since reaching an unspecified case is a no-op
<Lofty>
ps2_byte_writer.v:37: Warning: Identifier `\parity' is implicitly declared.
<Lofty>
ps2_byte_writer.v:52: Warning: Identifier `\done_bit' is implicitly declared.
<Lofty>
Even ignoring the possible presence of latches, this is something you need to fix
<Lofty>
If you add "`default_nettype none" to the top of your source files, Yosys will error if you implicitly declare a variable
dys has quit [Remote host closed the connection]
<evil_chuck>
by default they are wires though, which is fine
dys has joined #yosys
<Lofty>
Correct, but it's a bad habit to rely on implicit declaration of wires
<Lofty>
Warning: multiple conflicting drivers for top.\DUT.write_count [3]:
<Lofty>
port Q[3] of cell $techmap\DUT.$auto$proc_dlatch.cc:417:proc_dlatch$598 ($dlatch)
<Lofty>
port Q[3] of cell $techmap\DUT.$auto$proc_dlatch.cc:417:proc_dlatch$627 ($dlatch)
<Lofty>
Yes, you have latches
<Lofty>
And multiple signal drivers
<Lofty>
Latch inferred for signal `$paramod\ps2_bit_writer\clock_divider=10.\read_bit' from process `$paramod\ps2_bit_writer\clock_divider=10.$proc$ps2_bit_writer.v:57$427': $auto$proc_dlatch.cc:417:proc_dlatch$581
<evil_chuck>
I see. I think I know where the issue is. I'm setting that net from two combinational processes
<Lofty>
Anyway, here's the direct answer to your question: you have latches in your design, and timing analysis on latches is really difficult
<evil_chuck>
I should be incrementing in a sequential block
<evil_chuck>
Thanks, I'll try fixing that.
<evil_chuck>
The simulator (iverilog) doesn't care about it at all. Should I be running synthesis alongside simulation all the time?
<Lofty>
It is *valid* to have latches in your design
<Lofty>
That doesn't make it a good idea
<Lofty>
So, as far as iverilog is concerned, your design is valid, and its job is to simulate that
<Lofty>
I'm not sure how Verilator handles latches, but it probably lints them at least
xtro has joined #yosys
Jybz has quit [Excess Flood]
Jybz has joined #yosys
qu1j0t3 has quit [Quit: WeeChat 0.4.3]
Jybz has quit [Remote host closed the connection]
Jybz has joined #yosys
qu1j0t3 has joined #yosys
Jybz has quit [Ping timeout: 272 seconds]
kraiskil has quit [Read error: Connection reset by peer]
xtro has quit [Ping timeout: 264 seconds]
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
Asuu has joined #yosys
Asu has quit [Ping timeout: 272 seconds]
xtro has joined #yosys
Asuu has quit [Remote host closed the connection]
evil_chuck has left #yosys [#yosys]
Cerpin has quit [Remote host closed the connection]