az0re has quit [Remote host closed the connection]
Degi has joined #yosys
emeb has quit [Read error: Connection reset by peer]
kristianpaul has quit [Ping timeout: 265 seconds]
kristianpaul has joined #yosys
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #yosys
az0re has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
citypw has joined #yosys
kristianpaul has quit [Ping timeout: 260 seconds]
anticw has quit [Remote host closed the connection]
xtro has joined #yosys
anticw has joined #yosys
kristianpaul has joined #yosys
kristianpaul has quit [Ping timeout: 240 seconds]
kristianpaul has joined #yosys
maartenBE has quit [Ping timeout: 240 seconds]
kristianpaul has quit [Ping timeout: 256 seconds]
maartenBE has joined #yosys
kristianpaul has joined #yosys
kristianpaul has quit [Read error: Connection reset by peer]
ayazar1 has joined #yosys
kristianpaul has joined #yosys
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined #yosys
emeb_mac has quit [Quit: Leaving.]
jordigw has joined #yosys
kraiskil has joined #yosys
jakobwenzel has joined #yosys
ayazar1 has quit [Quit: ayazar1]
Asu has joined #yosys
xtro has quit [Ping timeout: 240 seconds]
flaviusb has joined #yosys
proteusguy has quit [Ping timeout: 256 seconds]
proteusguy has joined #yosys
proteusguy has quit [Ping timeout: 265 seconds]
<pepijndevos>
How well does Yosys support division?
sorear has quit [Ping timeout: 244 seconds]
svenn has quit [Read error: Connection reset by peer]
svenn has joined #yosys
sorear has joined #yosys
proteusguy has joined #yosys
Asuu has joined #yosys
Asu has quit [Ping timeout: 260 seconds]
<daveshah>
My experience is that anything other than a power of two ends up with a massive circuit
<daveshah>
Sometimes abc9 does clean things up a bit
<pepijndevos>
daveshah, yea I guess that is to be expected. But from what I read some synthesis tools outright don't support anything other than powers of two, or maybe constants only or stuff like that.
<daveshah>
Yosys will bravely try and synthesis any divide
<pepijndevos>
Cool
<pepijndevos>
Maybe in the end I will implement a sequential division if it turns out to be too unreasonable.
<Lofty>
It'll also attempt combinational modulus too, I think
<daveshah>
Yep
<daveshah>
I suspect there are much better combinational algorithms than the one Yosys uses
<daveshah>
But I haven't looked into it in detail
<daveshah>
Even if you do want single cycle divide, often it needs to be pipelined so you wouldn't infer it anyway
<pepijndevos>
Just because it's so unwieldy it drives fmax down the drain?
<Lofty>
Pretty much
<pepijndevos>
Hm, pipelining only gets you more throughput, not more latency, right...
<pepijndevos>
(compared to normal clocked)
<Lofty>
pepijndevos: for the specific path, latency generally goes up. But because your division is no longer part of the critical path, effective latency everywhere else goes down :P
<pepijndevos>
I mean latency in "number of clock cycles to complete calculation" not in the timing sense, but yea
DaKnig has quit [Ping timeout: 265 seconds]
DaKnig has joined #yosys
Asuu has quit [Ping timeout: 256 seconds]
Asu has joined #yosys
kraiskil has quit [Ping timeout: 260 seconds]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 240 seconds]
indy has quit [Read error: Connection reset by peer]
<tpb>
Title: How can I assign a "dont care" value to an output in a combinational module in Verilog - Stack Overflow (at stackoverflow.com)
<Forty-Bot>
one answer is for quartus, however when I try the same thing in yosys the "don't cares" get interpreted as zeros
<mwk>
just use x bits, they are supported
<mwk>
(yosys might miss some optimization opportunities though)
<Forty-Bot>
ok, so for that example, bit 0 synthesizes as an and gate
<Forty-Bot>
but since it is don't-care, it should synthesize as a constant 1
<Forty-Bot>
which to me means that the Xs are interpreted as 0s and not "don't care"s
<mwk>
look
<mwk>
"don't care" means that synthesis can pick any bit it wants
<mwk>
it picked 0 in this case, this is not an error
<Forty-Bot>
right, and I want it to pick a bit which minimizes the amount of area
<Forty-Bot>
instead of picking any bit it wants
<mwk>
yeah, it seems yosys has no optimization pass that'd be able to figure this out
<Forty-Bot>
:l
emeb_mac has joined #yosys
<mwk>
it is an interesting case though
<mwk>
I think whitequark had a draft pass (opt_match?) that would solve it nicely
<whitequark>
yes
<whitequark>
and i actually know how to properly put it into yosys now
<whitequark>
like, in a way that would get it merged and nicely intregrated with the existing passes, rather than a total rewrite of proc i initially planned (which is unnecessary anyway, at least for the reasons i wanted it)
<mwk>
do you want it as an extra opt pass, or an extra proc pass?
<whitequark>
extra proc pass
<mwk>
huh.
<whitequark>
either that or mmm
<whitequark>
i think it would actually be a new mode for proc_mux
<mwk>
right, proc_mux replacement
<whitequark>
the idea is to ditch everything i wrote for proc_match except for the, well, match-related parts
<whitequark>
all the stuff i did for mux insertion was really clever... clever enough i never figured out how to make it work
<whitequark>
and tbh
<whitequark>
it's possible that with better column order selection the rest of yosys will cope just fine
<whitequark>
possibly not but i don't want to prematurely rewrite it
<mwk>
(I might have a refactor of proc incoming for unrelated reasons though — better async reset support)
<mwk>
(the main idea being that proc_dff / proc_dlatch should run *before* proc_mux and be merged with proc_arst, to remove some current weirdness with async resets in DFFs and support resets in dlatches)
<whitequark>
uh, that might actually break nmigen
<whitequark>
i'm not saying you shouldn't
<mwk>
huh, why?
<whitequark>
i'm saying you might
<whitequark>
wait
<whitequark>
nevermind, i misremembered
<whitequark>
(because nmigen uses proc_arst;proc_dff, but i misremembered that it just uses proc_arst alone)
<mwk>
oh, you're actually using proc_* subpasses on their own, without the proc wrapper?
<whitequark>
yes
<mwk>
... okay, that has a good chance of breaking
<whitequark>
yes
<whitequark>
the reason i do that is because i want write_verilog to get a netlist it can actually process
<whitequark>
but i don't want processes to be bitblasted away
<whitequark>
tbh
<whitequark>
if there was a `proc -nomux` it's likely i could just use that
<mwk>
hmmmm, that sounds good
<Forty-Bot>
so is there any other approach to doing this other than hand-optimization?