<tpb>
Title: Min Avg Max abc-nomince clk_30m72: 23.460000 26.6 - Pastebin.com (at pastebin.com)
<ZirconiumX>
tnt: it's ABC9 *and* dff which is the new bit
<tnt>
(comparing abc / abc9 / abc9+dff each with dffe_min_ce and without. 64 PNR runs)
<tnt>
I know.
<ZirconiumX>
It wasn't clear from your pastebin, sorry
<ZirconiumX>
Is clk_30m72 meant to be 30.72 MHz?
<tnt>
yup
<tnt>
It did meet it at some point in the past :/
<ZirconiumX>
So dff seems to help a reasonable amount there actually
<ZirconiumX>
Not so much for the 30.72 MHz path, but
<tnt>
huh ? Where do you see thast it helps ?
<ZirconiumX>
I'm looking mostly at worst-case numbers here.
<ZirconiumX>
Okay, maybe I'm struggling to parse the numbers here
<ZirconiumX>
This probably wants like a candle chart or something
<ZirconiumX>
I'm presuming this is iCE40
<ZirconiumX>
Hmm...
<tnt>
UP5k yes.
<tnt>
args to yosys were -abc9 -device u -dff
<tnt>
something to compare the histograms would be useful but ... I don't have anything like that.
<tnt>
it might just be that the critical path really can't be helped much.
<ZirconiumX>
tnt: matplotlib
<tnt>
I meant, I have nothing already written that takes a bunch of .log from nextpnr and extracts / aggregates / display the interesting bits :p
<ZirconiumX>
Y'know, I wrote a script to statistically test two builds of *something*
<ZirconiumX>
Maybe I should put it to work
rlee287 has joined #yosys
<rlee287>
Is there an explanation in the Yosys manual or elsewhere as to why RTLIL::Process objects cannot always be mapped to Verilog always blocks?
<rlee287>
(Asking because I would like to check if similar limitations exist for VHDL processes)
<ZirconiumX>
rlee287: simply because they're not implemented
<ZirconiumX>
VHDL isn't even *relevant*, because Yosys doesn't speak VHDL
<rlee287>
I'm writing a VHDL backend right now to put it into the GHDL Yosys plugin
<rlee287>
This would inform my decision on how to handle RTLIL Processes in this backend
<ZirconiumX>
whitequark is probably a good person to ask
<whitequark>
rlee287: there is no such clear explanation unfortunately
<whitequark>
and I don't fully understand it myself, but I did investigate this for a small amount of time
<whitequark>
(ideally there wouldn't be such a warning, it would just be a hard error on specifically the kinds of processes that aren't valid)
<whitequark>
ZirconiumX: I think that's not a matter of implementation
<whitequark>
or well, not just that
<rlee287>
Thanks (which means I will need to run experiments on my own end to see what happens)
<whitequark>
rlee287: so the `case` part of a process can always be mapped to Verilog because it's just a combinatorial always @* block
<whitequark>
you could even say always_comb, since it is illegal to have a latch in that part
<whitequark>
the `sync` part is more troublesome though because there are some patterns that I think are not expressible in Verilog
<whitequark>
it's... somewhat hard to say which precisely, because, strictly speaking, Verilog contradicts itself here
<whitequark>
1164.1 requires you to use some constructs that would always result in a significant sim/synth mismatch
<whitequark>
so the answer to "is this transformation of an RTLIL::Process to Verilog valid?" is "who the hell knows"
<rlee287>
1164 is referring to the IEEE standard 1164 about "STD_LOGIC" (or the Verilog equivalent of it)?
<whitequark>
err
<ZirconiumX>
1364
<whitequark>
1364.1, sorry, I typoed
<rlee287>
OK
<whitequark>
1364 describes Verilog (the simulation language), 1364.1 describes Verilog (the synthesis language)
<whitequark>
it was supposed to be a synthesis subset but it clearly isn't
<awygle>
does vhdl have a synthesis subset?
<awygle>
(also hi rlee)
<rlee287>
Hi awygle
<rlee287>
Not that I am aware of (I vaguely recall people in the Discord saying that VHDL was slightly more problematic(?) because it did not define a synthesis subset)
<rlee287>
It seems though based on whitequark's remakrs that Verilog's synthesis subset has problems as well
<awygle>
that is correct if not understated
<awygle>
and SV has no synthesis subset at all
<awygle>
(no formal one that is)
<whitequark>
^
<whitequark>
neither SV nor VHDL are strictly speaking suitable for synthesis as-is
<whitequark>
they're both event-driven simulation languages. at least VHDL has an actually nice and deterministic simulation model
jakobwenzel has quit [Quit: jakobwenzel]
Asuu has joined #yosys
Asu has quit [Ping timeout: 240 seconds]
kraiskil has joined #yosys
Laksen has joined #yosys
Laksen has quit [Read error: Connection reset by peer]
BinaryLust has quit [Ping timeout: 256 seconds]
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #yosys
Laksen has joined #yosys
Laksen has quit [Read error: Connection reset by peer]