s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
citypw has quit [Ping timeout: 245 seconds]
Jybz has joined #yosys
adjtm has joined #yosys
citypw has joined #yosys
_whitelogger has joined #yosys
m4ssi has joined #yosys
rohitksingh has quit [Ping timeout: 246 seconds]
citypw has quit [Ping timeout: 245 seconds]
rohitksingh has joined #yosys
Jybz has quit [Ping timeout: 252 seconds]
rrika has quit [Ping timeout: 272 seconds]
rrika has joined #yosys
<pepijndevos>
Welp... voodoo ahoy
<pepijndevos>
When I simulate my cpu in ghdl with a vhdl testbench it works perfectly
rohitksingh has quit [Read error: Connection reset by peer]
<pepijndevos>
When I read it with verific/ghdl and convert to verilog and run it in ikarus, I get all sorts of borkennes
<pepijndevos>
Interestingly, different types of brokenness if I synthesize first or not.
<pepijndevos>
Odly synthesized seems less broken than not. The direct verilog output is just straigt away xxxxxxx
<tnt>
Do you have an explicit reset ?
<pepijndevos>
Yyyyyes? I don't reset all the signals though, only the ones I care about.
<tnt>
And you're sure you haven't "forgotten" one ? :)
<tnt>
Although sometime the 'x' propagation is a little agressive and doesn't detect that a result will always be deterministic no matter what the input is.
<pepijndevos>
Ehhh, possible. I'll try if resetting all the things helps.
<pepijndevos>
But why is this only an issue when converting to verilog?
<tnt>
Else you need to actually look at the first 'x' that happens where it shouldn't and see why it's there.
<pepijndevos>
Yea I guess
<tnt>
pepijndevos: I have no idea how the conversion is done so I'm not sure if it's supposed to map to equivalent 'x' semantics or not ...
<pepijndevos>
hm ok
<pepijndevos>
Ah it seems not so happy about metavalues. Understandable. I thought I'd let the compiler do its thing and output some don't cares.
emeb has joined #yosys
s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
<pepijndevos>
daveshah, I have an extremely weird issue, and could use some advice on ruling out a compiler bug if you have time. Basically my code breaks after doing techmap -map +/techmap.v; opt; but doing (n)one of the two is fine.
<daveshah>
pepijndevos: is this still involving x?
<pepijndevos>
nope
<daveshah>
anything else unusual?
<pepijndevos>
Well, it gives xxx after it optimizes away my design, but generally it's working without those two commands
<daveshah>
can you post the ilang before techmap/opt?
<pepijndevos>
Other than that the target is 74xx logic, not really :)
<daveshah>
Out of curiosity, what is getting optimised away
<pepijndevos>
Hold on... some bits of the opcode... but at this point it's not actually broken yet... sorry, I was looking at the wrong thing to deretmine breakage
<pepijndevos>
So it's breaking at a later stage, brb
<pepijndevos>
ah, got it... more or less... it's something with muxes... will try to narrow it down
<pepijndevos>
But in that case it's probably simply a bug in our mux techmap...
<pepijndevos>
I would like to do something like equiv_opt techmap -map ../74_mux.v, but first it gives me warnings about not having SAT models for all the things, and then it gives a lot of unproven $equiv. What's a good way to test this techmap is correct?
<daveshah>
Simulation before and after mapping?
<daveshah>
Or loading in models for all cells
<pepijndevos>
What do you mean?
<pepijndevos>
Well, pretty much I know it is *not* correct
<daveshah>
Immediately before equiv_opt, do `read_verilog` or `read_liberty` *without* -lib (unlike in normal synthesis) to load in models
<daveshah>
Then simulation of a simple design (just a mux on its own) is probably your best bet
<pepijndevos>
Oh I see
<daveshah>
Just running synthesis of a mux on its own might be enough to highlight the problem
<pepijndevos>
Thanks, I'll give it a go :)
<pepijndevos>
Ehhh, I get that I can use whitebox models for my techmap, but it'll probably still complain about $_MUX8_