<Myrl-saki>
Is there a way to tell Yosys to not assume anything about the values?
<Myrl-saki>
Or rather, assume that all bit representations are valid or something.
<Myrl-saki>
Specifically, I have a rom which is populated by readmemh, and Yosys is apparently smart enough to dead code eliminate everything else based on the contents of the ROM.
cybernaut has joined #yosys
chaoticryptidz has quit [Ping timeout: 264 seconds]
chaoticryptidz has joined #yosys
cybernaut has quit [Ping timeout: 272 seconds]
<lofty>
Myrl-saki: invariably the answer is "fix the bug in your code" :p
cybernaut has joined #yosys
<tnt>
lofty: Not sure there is a bug in the code ...
<lofty>
tnt: Yosys should not be able to optimise out an entire design if there isn't
<tnt>
lofty: not entire design ... but possibly some path because it sees the rom content never has that bit at 1 for instance. But maybe that rom content is meant to be replaced dynamically post PNR.
<tnt>
so it'd be nice if you could tell it "don't optimize anything based on the content of the ROM".
<lofty>
Yosys will pretty much always want to map a ROM to LUTs
<tnt>
yeah, which is another problem in itself ...
<tnt>
but maybe it accepts ram_style
<tnt>
Ideally for postpnr replace the content would be filled with random so it's "unlikely" that it find any content dependent optimization, but still would be nice to be sure.
<jix>
I'm not sure what optimizations in which passes are the issue here, but what should work in any case is to keep the rom in a separate module that's loaded as a blackbox during synth and then only afterwards you read the module contents with the rom in it
cybernaut has quit [Quit: Leaving]
cybernaut has joined #yosys
cybernaut has quit [Read error: Connection reset by peer]
chaoticryptidz has quit [Ping timeout: 255 seconds]
GenTooMan has joined #yosys
chaoticryptidz has joined #yosys
chaoticryptidz has quit [Read error: Connection reset by peer]
chaoticryptidz has joined #yosys
schaeg has joined #yosys
schaeg_ has quit [Ping timeout: 260 seconds]
<Myrl-saki>
Yosys is making ALUs for this: wire ram_select = addr - 256 < 256; // 256 <= addr && addr < 256 + 256;
<Myrl-saki>
Ah wait.
<lofty>
Comparisons are implemented in terms of ALUs
<lofty>
(with some exceptions for very small comparisons)
<Myrl-saki>
I think it's because I'm calling alumacc too early.
<Myrl-saki>
Mhm, though isn't this faster with just a bunch of LUTs?
<lofty>
With interconnect delay for LUTs compared to fast carry chain? hard to say.
<Myrl-saki>
Okay, I called alumacc later, after opt -fine -full, and with the commented version as the expression, and it now no longer uses ALUs.
<Myrl-saki>
Though, that's interesting though.
<Myrl-saki>
I think I see what you mean. A comparison would be both wide and deep, since it has to generate partials for each bits, and then it gets collected after. A dedicated carry chain could actually be faster.
<Myrl-saki>
I think?
icee has joined #yosys
<icee>
I'm trying to make a workflow with yosys on edaplayground for my students to see decent diagrams of trivial multi-module things
<icee>
I'm using flatten in my .ys file; but I get bufs going to names of internal signals
<icee>
How can i get it to actually eliminate these internal wire names etc
<icee>
i've tried making sure keep attributes are unset (but could be screwing this up); i've tried clean
<lofty>
icee: opt_clean -purge
<lofty>
At least, if I'm remembering correctly
<lofty>
Myrl-saki: depending on the architecture you can also break down comparisons to be even more efficient than naive subtraction while still using the carry chain