<tnt>
pepijndevos_: yeah. "assign data = states!=3'b001 ? 8'bZZZZZZZZ : accumulator[7:0]; " needs some change.
<tnt>
Also, is that supposed to be a top level ? I mean tristate really only makes sense for IOs. No modern fpga has internal tristates.
<corecode>
yea too bad that there is no easy way to communicate an output enable other than explicit second line
<corecode>
but i guess it makes it more explicit
<pepijndevos_>
tnt, not totaly sure tbh, just some core I snatched from the web.
<corecode>
tnt: do you think it would make sense to automatically convert tristates to (hidden) enable signals and then connect to buffer OE?
<corecode>
seems messy and too implicit
<corecode>
very behavioral, not RTL
adjtm has joined #yosys
_whitelogger has joined #yosys
Jybz has quit [Remote host closed the connection]
Jybz has joined #yosys
dys has quit [Ping timeout: 268 seconds]
adjtm has quit [Ping timeout: 244 seconds]
maikmerten has joined #yosys
<maikmerten>
with latest yosys master LUT usage is back to normal (nextpnr can pack things together nicely again)
<maikmerten>
so thanks a lot! :-)
<maikmerten>
with relut being at work and nextpnr being able to pack things again, LUT-usage overall is now lower than ever
rrika has quit [Ping timeout: 245 seconds]
<maikmerten>
f_max is also back to normal, which means ~35 MHz (which I'm used to, caused by a carry chain) vs. ~45 MHz (with the original relut branch merged, with the carry chain no longer being the critial path). I wonder how the pre-fix yosys/nextpnr flow managed that.
rrika has joined #yosys
cr1901 has quit [Quit: Leaving.]
cr1901 has joined #yosys
dys has joined #yosys
adjtm has joined #yosys
Jybz has quit [Quit: Konversation terminated!]
<pepijndevos_>
Huh, I'm confused. Looking at rtlil.h I swear I saw the actual implementations of add* functions, but I can't find them. I guess I'm being thick.
<pepijndevos_>
git grep addAdd does not seem to find any actual implementation.
<pepijndevos_>
oh, addAdff is there alright... but where are the others...
<pepijndevos_>
ah... DEF_METHOD
<pepijndevos_>
Is $mux always two-way? Because there is a $_MUX4_ but I've never seen $mux4, yet in rtlil.h it seems only two-way.
<daveshah>
Larger muxes would end up either as $pmux or $shiftx depending on coding style
<daveshah>
Or perhaps even a tree of $mux if coded using a tree of ?:
<pepijndevos_>
For a mux4 it indeed creates a tree of muxes, and was curious if that's the correct way to do it.
<daveshah>
It's as good as any
<pepijndevos_>
Cool
<daveshah>
I'm not sure why ghdl has a mux4 cell in the first place...
<pepijndevos_>
I'm going to try to add module instatiations. We'll see if just adding it as a cell and connecting wires does the job.
<daveshah>
Yes, modulo parameterisation
<pepijndevos_>
I think that's handled on the ghdl side, but not totally sure. Tristan mentioned he implemented modules in synthization but not on the yosys side, so I thought I'd try doing something useful.
<daveshah>
For anything that isn't a blackbox leaf cell, you'll probably want to strip parameters from the instance and give each parameterised variant a unique name
<pepijndevos_>
right
<maikmerten>
is there a list of nextpnr python console commands?