<marcan>
so each PLL has two outputs, and depending on the PLL mode it either uses one or two. and an in-use PLL output eats the pin's *input* buffer, right?
<marcan>
(because I'm guessing it uses that path to get into a gbuf?)
<marcan>
what about the PLL *input*? I see REFERENCECLK comes from `fabout` on some other IO tile, but the SB_PLL40_*_PAD primitives seem to have a PACKAGEPIN input instead and I don't really understand where that comes from (fixed pin? something else?)
<marcan>
it seems one PLL maps PLLOUT_A to the GBIN5 pin, and PLLOUT_B to the GBIN4 pin
<marcan>
and the other maps to GBIN0 and GBIN1 respectively
<marcan>
so using one PLL eats GBIN0's input buffer (and possibly GBIN1 in dual modes) but those pins can still be used as outputs (including tristate), right?
<marcan>
and smae for the other PLL of course
<marcan>
*same
<marcan>
and the _PAD variants will take over the pins entirely, using them as outputs, right?
<marcan>
or is that for inputs?
<_whitenotifier>
[whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fpiS7
<daveshah>
I think you've worked this bit out already but each PLL makes two IO pins output only; and one of those becomes a dedicated PLL input with a PAD PLL
<daveshah>
The Lattice docs really don't describe that anywhere though
<marcan>
yeah, that's what I basically arrived at
<marcan>
but just haven't been able to find anything to confirm it
<marcan>
specifically, it seems PLLOUT_A is PACKAGEPIN, right?
<daveshah>
Yes
<marcan>
and then I assume the PLL outputs go on to drive the associated GBINs
<marcan>
so effectively PAD PLLs insert themselves between a GBIN and its GBUF
<marcan>
(and optionally drive a second output to the neighboring GBUF)
<swetland>
yup
<daveshah>
The PLL outputs don't have to drive a global buffer
<marcan>
right, they have two outputs
<marcan>
one for GBIN and one for random logic
<daveshah>
They can also drive fabric, then the associated GB can still be driven by fabric
<marcan>
(per _A/_B)
<marcan>
ah
<marcan>
so the GB is still usable in that case
<daveshah>
BTW I wouldn't worry too much about using GBIN pins overall
<marcan>
(just not the pin)
<daveshah>
Yes
<daveshah>
Routing globals through a small amount of fabric on the ice40 has never been a problem
<daveshah>
When you don't use the global output of the PLL, the PLL output is treated the same as an input buffer output fwiw
<marcan>
oh also just to confirm, "output-only" pins doesn't mean they always drive, right?
<daveshah>
The PLL is really in the input path
<marcan>
so it can still be tristated
<marcan>
(just not read)
<daveshah>
I've never actually tested that
<marcan>
hm, ok
<daveshah>
But from the PnR stuff I've done there's no reason it shouldn't work
<daveshah>
I'm certain the tristating itself would work
<daveshah>
Can't guarantee it doesn't break the PLL in some weird way
<marcan>
hm
<marcan>
I mean the question is basically can I drive a pin externally and if I need the PLL just not use that pin (but without causing a bus conflict)
<daveshah>
Yes, sufe
<daveshah>
*sure
<daveshah>
You don't have to have an output IO there at all
<daveshah>
What you really can't do is use the input buffer
<marcan>
cool
<daveshah>
The only thing not tested, but certainly should work, is on the fly tristating
<marcan>
yeah we don't need that
<daveshah>
The _2_PAD variant, unlike the _2F_PAD variant, passes through the PLL input to one PLL output
<daveshah>
That is the only way to use the original input
<marcan>
yeah, I saw that
<daveshah>
But it has to also be used as the PLL input in this case
<whitequark>
daveshah: is it me or does yosys 'kind of' suck at synthesis optimization
<whitequark>
like
<whitequark>
i'm tweaking the design and yosys appears to miss completely obvious optimization opportunities...
<whitequark>
unless i'm missing something or migen generates bad verilog
<whitequark>
by kind of i mean it seems to do onl ywhat i'd call "peephole optimization" in synthesis
<daveshah>
Yosys' QoR is quite poor, yes
<whitequark>
ok, thanks
<whitequark>
not just me
<daveshah>
I have seen around ~30% worse than Vivado in synthesis alone in one paper, although that was a while ago
<daveshah>
We are hoping to get some help from Alan in making better use of ABC in the near future
<whitequark>
more ABC?!
<whitequark>
that sounds horrifying
<whitequark>
ABC is bad enough as it is
<daveshah>
Write your own logic optimisation tool then
<whitequark>
ABC is the single worst usability issue with Yosys and you can't deny that
<whitequark>
you can ignore that but it's user hostile
<swetland>
yeah I'm seeing 62% more LUTs, 36% more CARRYs, 6% more DFFs in my project vs icecube/synplify
<daveshah>
whitequark: sure, a much simpler optimisation pass that preserved way more names might be possible
<daveshah>
but your QoR is going to collapse even further
<whitequark>
daveshah: well... synplify seems to not be as bad with names as abc, doesn't it?
<whitequark>
and it has a better QoR at the same time
<whitequark>
so it's clearly possible in theory
<swetland>
ideally we'd optimize and keep track of where everything came from, but one thing at a time, I suppose. even many of the vendor tools leave you wondering what went where after they chew on your design enough
<daveshah>
Yes, if we were a billion dollar company I'm sure we could get all this stuff working
<daveshah>
But we're not
<daveshah>
So you've got to pick and choose
<whitequark>
I'm wondering if there are missed opportunities *before* abc
<daveshah>
Definitely
<whitequark>
because I would probably not work on abc but I would probably write a Yosys pass
<daveshah>
After ABC too
<whitequark>
right, I might look into it some time later
<swetland>
may well be. I get the impression the vendor tools use a lot of really high level heuristics to map common patterns to part-specific layouts and/or hard blocks
<daveshah>
Sometimes they even do heuristics at the AST level, particularly for BRAM inference
<swetland>
the rtl elaboration schematic view in vivado kinda gives some hints about what it's thinking
<daveshah>
I'm not convinced this is the best solution though
<whitequark>
daveshah: let's say I have a mux
<whitequark>
n:1 mux specifically
<whitequark>
is it better to control it with one-hots or is it better to control it with an encoded signal?
<whitequark>
it looks like yosys cannot convert between those representations
<whitequark>
this specific mux is 5:1. do you have any advice on what's the best way to lay out verilog for it for LUT4s?
<daveshah>
I don't know
<daveshah>
Depends where your control signals come from partly
<whitequark>
an FSM
<whitequark>
Yosys refuses to optimize the FSM for two reasons
<whitequark>
one, it doesn't think it's efficient
<whitequark>
second, there's an issue (bug, imo) in Yosys where it cannot handle FSMs that use reg init values
<swetland>
I need to do some experiments. curious where the various tools infer muxes vs enables, etc
<whitequark>
which I keep meaning to fix
<swetland>
ah I see that everywhere.
<swetland>
I am naughty and like to have my initial state by 0 (conveniently the initial state of lattice DFFs)
<whitequark>
swetland: yes
<whitequark>
that's what migen sets it to in this case
<whitequark>
and at *least* i think yosys should recognize that...
<daveshah>
I doubt there's that much difference either way for only 5 inputs
<swetland>
there's a lot of "thou shalt always use resets" in various style guides
<swetland>
but if you're specifically targeting an fpga it seems odd not to play to its advantages
<whitequark>
swetland: yyyyyep
<swetland>
provided you know that you're doing so
<daveshah>
whitequark: fwiw both onehot and encoded mux5s end up as 3 LUT4s for me
<daveshah>
with Yosys
<whitequark>
per bit?
<daveshah>
In total
<whitequark>
mmm, okay, thanks
<whitequark>
daveshah: onehot seems marginally more efficient in my case
<daveshah>
Yes, seems quite possible with an FSM
<whitequark>
but it's also a weird mux
<whitequark>
it's 16 bit, and the bottom 3 bits are more muxed than top 13 bits
<whitequark>
let me try and write that down explicitly
<whitequark>
hrm
<whitequark>
that... made it worse
<whitequark>
but also, at best... my microoptimizations saved 2 LUTs
<whitequark>
and made code way more gross
<_whitenotifier>
[whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fpid7
<whitequark>
this is without any sensible program in it, I could put a blinky there if you wanted
<daveshah>
Doesn't matter
<swetland>
is there a reliable directive for yosys to ask it to assume all IOs from a module are actually used
<swetland>
(eg so if won't trim out high address bits, etc, if I don't have a full memory bus wired up)
<cr1901_modern>
(* keep = 1 *) ?
<daveshah>
whitequark:
<daveshah>
master: min = 22.39 MHz, avg = 23.24 MHz, max = 24.73 MHz
<daveshah>
carry improvements: min = 23.16 MHz, avg = 24.47 MHz, max = 25.97 MHz
<daveshah>
carry improvements & opt-timing pass: min = 23.95 MHz, avg = 25.73 MHz, max = 28.00 MHz
<daveshah>
16 runs of nextpnr in each case
<marcan>
nice.
<cr1901_modern>
daveshah: cr1901cc -pedantic, should you provide stddev?
<daveshah>
probably
<whitequark>
daveshah: that's quite nice
<whitequark>
daveshah: how would you try to optimize this design, assuming free tools?
<daveshah>
Can't offer more advice than just trying to keep the critical path as short as possible
<whitequark>
what about size?
<whitequark>
frequency is easier
<whitequark>
I think I know how to make it faster, already
<daveshah>
No idea, I'm not really an FPGA developer remember
<whitequark>
right, sure
<cr1901_modern>
whitequark: Are you using sync reset?
<daveshah>
I've never optimised something for size before...
rohitksingh_work has quit [Read error: Connection reset by peer]
<whitequark>
cr1901_modern: yes
<cr1901_modern>
I wonder how many LUTs are being used just for resetting all the signals (since a MUX will need to choose between reset and new value for sync reset)?
<whitequark>
hrmmm
<daveshah>
ice40 has sync reset in hw
<whitequark>
yeah, it makes no difference
<cr1901_modern>
well that's my contribution :P. I'm all out of ideas.
<daveshah>
whitequark: Tried building boneless myself (I think I'm doing it correctly)
<daveshah>
with tnt's dffe_min_ce_use = 4
<daveshah>
min = 26.74 MHz, avg = 27.82 MHz, max = 29.35 MHz
<daveshah>
(plus the other nextpnr improvements as before)
<tnt>
daveshah: ice40 as sync reset in HW but it doesn't override the CE pin ... so if you use sync reset, it sometimes needs to combine the reset signal with the ce signal :/ Using async reset solves that.
<daveshah>
tnt: interestingly, ecp5 is the opposite here
<tnt>
yeah, xilinx as well ... that really surprised me when I found out ...
<daveshah>
🚨 yosys bug 🚨 running boneless with -retime seems to cause it to dispose of the entire design
<tnt>
at first I thought that yosys was doing something wrong ... but re-checking the lattice docs ... nope, ce has precedence.
<tnt>
lol
<whitequark>
daveshah: niiiiice
<whitequark>
regarding -retime
<whitequark>
yes, I have hit that
<daveshah>
I don't think it would make a difference on this kind of design anyway
<tnt>
it moved all the registers ... out of the fpga :P
<whitequark>
daveshah: also I tried synplify and synplify seems to consistently discard the entire design
<whitequark>
no matter what I'm trying to do
<whitequark>
it thinks sys_clk is unused.
<whitequark>
this.... makes no sense
<daveshah>
lol
<whitequark>
see, i might dislike yosys at times, but i really, really hate opaque vendor tools all the fucking time
<daveshah>
Now I know nextpnr assertion failures are shit
<daveshah>
But synplify assertion failures are 100 times worse
<whitequark>
nextpnr gave me very little trouble fwiw
<daveshah>
and I've hit them before now
<q3k>
yeah, i was doing some synthesis with xst recently
<whitequark>
most of my complaints with yosys boil down to "no systemverilog" (and even barely a complaint) and "fucking abc"
<q3k>
it also removed nearly all of my design
<whitequark>
is there really no alternative to abc? at all? anywhere?
<q3k>
although that was a pebkac, i wasn't driving ODDR2 correctly
<q3k>
whitequark: not really no
<daveshah>
I had LSE once remove *just the deceleration* part of a motor controller state machine
<whitequark>
so it's like opencascade ;_;
<whitequark>
daveshah: incredible
<daveshah>
That could have killed someone or destroyed millions of pounds of machinery lol
<daveshah>
Yeah ABC is sadly irreplaceable rn
<q3k>
that's somewhat terrifying
<daveshah>
I did test that code in several sims and other synth tools and nothing else had any issues
<daveshah>
So I'm pretty sure it was an LSE bug
<daveshah>
Then again, Yosys removing one read port of a TLB wasn't fun either
<q3k>
Final remarks:
<q3k>
Unfortunately, there is no comprehensive regression test. Good luck!
<q3k>
every fucking time
<daveshah>
ad net naming - I think there might be some functionality in ABC that we are not taking full advantage of
<whitequark>
daveshah: also... yosys does -flatten right?
<daveshah>
Yes, pretty much straight away in the ice40 flow I think
<whitequark>
so evne if I had a hierarchical design like azonenberg told me
<whitequark>
it would not have helped me here at all
<daveshah>
You can run without flattenning
<whitequark>
but it breaks somehow, right?
<daveshah>
You need a flatten after synthesis
<whitequark>
I remember trying it some time ago
<daveshah>
nextpnr doesn't support hierarchy yet
<whitequark>
and it broke in bizarre, impossible to debug ways
<whitequark>
something about tristates? I think?
<q3k>
daveshah: what does yosys use abc for right now? only techmapping?
<daveshah>
LUT techmapping and optimisation
<daveshah>
plus ASIC techmapping
<q3k>
so does the 'abc' command do both the techamp and an optimization pass by abc?
<daveshah>
Yes
<daveshah>
by default
<whitequark>
can I tell abc to only techmap?
<daveshah>
Maybe, I don't really understand ABC well enough
<daveshah>
I suspect that techmapping is also optimisation to some extent
<swetland>
I wish I could remember which toolchain it was (quartus or vivado), but long ago I had a small cpu design running out of rom that was readmemh'd in, and it optimized away parts of the cpu that executed instructions that did not exist in the rom
<swetland>
which I found simultaneously quite impressive and really annoying
<whitequark>
ha
<whitequark>
compilers dot jpeg
<whitequark>
simultaneously quite impressive and really annoying
<swetland>
the solution to and cause of all our problems...
<q3k>
dress – This command transfers the node names from an external network to the current network. For this purpose FRAIG package is used to detect functional equivalences between the nodes of the two networks. If a node in the current network has the same functionality as a node in the external network, the name is transferred. If the nodes are equivalent up to complementation, the name is transferred and
<q3k>
suffix _inv is appended to it. This is useful because ABC (while preserving PI, PO, and latch output names) does not preserve the internal node names when processing logic networks and AIGs. Using this command, if the internal names are needed, they can be restored after the network processing is over, just before writing the resulting network into a file. Note that if, after calling command dress, the
<q3k>
network is not immediately written into a file, the internal node names may be lost again.
<q3k>
whitequark, daveshah ^
<q3k>
seems yosys is not calling that.
<daveshah>
whitequark: didn't we discuss this ~6months ago
<daveshah>
or was it with rqou
<whitequark>
daveshah: which part?
<whitequark>
abc? not with me
<daveshah>
there's definitely some deja vu here
<daveshah>
must have been rqou
<daveshah>
lemme check the logs. I'm sure there was something nasty here
<q3k>
i'm sorry if i'm rehashing some old discussion, this is all new to me :)
<daveshah>
no problem
<whitequark>
I've never heard of dress
<q3k>
i just saw it in some random introductory paper to abc
<daveshah>
Hmm, seemed that previous discussion was pretty much just "abc is a mess"
rohitksingh has joined ##openfpga
<_whitenotifier>
[whitequark/Glasgow] whitequark pushed 3 commits to master [+0/-0/±3] https://git.io/fpPJW
<_whitenotifier>
[whitequark/Glasgow] whitequark 2d0123c - gateware.boneless: split JAL and JR handling (-1 LUT).
<RaYmAn>
hm, my Glasgow rev B has some issues (think one of the level shifters is dead), and I'm trying to run the selftest. It seems to fail here because it generates ".PACKAGE_PIN(io[0][0])," for the io SB_IO definitions. I have latest yosys/migen (from master). Any ideas?
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
rohitksingh has joined ##openfpga
<_whitenotifier>
[whitequark/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fpP3z
<_whitenotifier>
[whitequark/Glasgow] marcan 3533e74 - revC: reposition fiducials, add a third corner, add more for FX2, FPGA
<tnt>
I never tried radiant because you can't even instanciate the SB_xxx primitives ... they cahnged all that stuff which means most of my design don't work out of the box :/
<whitequark>
tnt: riiiight.
<_whitenotifier>
[whitequark/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fpPlg
<_whitenotifier>
[whitequark/Glasgow] marcan ecd4f6a - revC: another silkscreen tweak near USB connector
<whitequark>
can I teach yosys to fold muxes into ALUs?
<daveshah>
I see no reason why not
<daveshah>
But I have never touched that code either
<whitequark>
ok sure
<q3k>
mwk: are other old spartans just as cursed when it comes to clock output as S6?
<mwk>
... clock output?
<q3k>
mwk: in the S6 you basically have to hack around an ODDR2 if you want to output a clock buffer to a pin
<q3k>
mwk: there is no dedicated global-clock-buffer-to-io structure from what I can tell
<mwk>
as in, route BUFGMUX out?
<q3k>
yes
<mwk>
yeah, no such thing
<q3k>
mwk: so you just do ODDR2(.CLK(clk),.CCLK(~clk),.O1(1),.O2(0))
<q3k>
absolute garbage
<q3k>
i mean, at least XST could insert those fuckers
<mwk>
well
<q3k>
instead the warning that comes up is 'lol demote your clock to not be globally routerd'
<q3k>
*routed
<RaYmAn>
whitequark: hm, is glasgow revB actually supposed to be able to go > 3.3v VIO?
<mwk>
yeah
<RaYmAn>
whitequark: also, your selftest is amazing :D
<mwk>
you can also just fabric-route it from BUFGMUX to io pin
<mwk>
but that's... not exactly pretty
<whitequark>
RaYmAn: yes, definitely
<RaYmAn>
mine seems to fail at > 3.3v VIO
<RaYmAn>
well, that gets me closer to figuring out hte issue at least :)
<mwk>
q3k: do any Xilinx FPGAs even have dedicated clock output pins?
<q3k>
mwk: i have no idea
<whitequark>
RaYmAn: fascinating, I have never seen this fail
<mwk>
AFAICT that was never a thing
<RaYmAn>
whitequark: bizarely, it seems to be _status() returning ST_ERROR when doing the write_voltage with value over 3.3. Probably something with my board though :(
<whitequark>
RaYmAn: hm
<whitequark>
what are you doing exactly? can you post a log with `glasgow -vv` ?
<daveshah>
whitequark: I think a generic solution after mapping in ice40_opt might be another option
<daveshah>
Basically trying to merge another LUT into the carry LUT
<daveshah>
Any LUT2 on the output or any LUT3 on the output sharing a LUT input can be merged in
<whitequark>
hmmmm
<whitequark>
what about constants?
<whitequark>
oh, nvm
<whitequark>
figured it out
<daveshah>
That is the LUT2 case
<whitequark>
good point
<daveshah>
Yes, just checked and that's exactly how it ends up
<whitequark>
ok this definitely seems nicer *and* more generic
<daveshah>
hmm, I remember I wrote a somewhat embarassing techmapper-type-thing about 3 years ago and had a function that did something like this
<whitequark>
actually, is this really ice40 specific?
<whitequark>
well, I guess it sort of is
<RaYmAn>
whitequark: with -vv, it seems to claim to succeed flashing, but fail during verification
<whitequark>
RaYmAn: ok yeah your board's fucked alright
<whitequark>
check powr
<daveshah>
whitequark: it could well be generic, you'd just have to tell it what your LUT primitive was
<whitequark>
with a multimeter
<whitequark>
daveshah: hmmm
<whitequark>
I take it this could be the beginning of a Yosys techmapper... right?
<whitequark>
then I can write it, I think.
<daveshah>
Yes
<whitequark>
sweet.
<RaYmAn>
I checked 3.3v on the eeproms and some other power points. looked good. I'll try flashing the eeprom externally with another Glasgow on Thursday
<daveshah>
whitequark: Only possible issue is making sure you preserve the "carry" LUT
<tnt>
daveshah: LUT4 that share both inputs should also be mergeable right ?
<daveshah>
Yes, that case works too
<whitequark>
daveshah: so I'd just need to merge into the larger one.
<whitequark>
which seems like a good idea in general.
<daveshah>
whitequark: tnt's case breaks that (and you have two LUT3s in the a/a+b mux case too)
<daveshah>
Setting an attribute on the LUT during arith_map might be an option
<daveshah>
to keep the optimisation pass generic
<whitequark>
mm, okay
<daveshah>
The (not Yosys) LUT merge code I wrote a while ago is intended to merge a LUT connected to the input of the "anchor" LUT, not the output as wanted here
<RaYmAn>
whitequark: is there any way to get glasgow to totally wipe the eeproms? If I try to run factory programming while it's in the ezusb dev mode, it says it's already programmed.
<daveshah>
Heh, might as well put the whole project on GitHub
<daveshah>
This was written in a couple of weeks when I was still pretty inexperienced with this stuff (and used VHDL :P) but is probably as simple as techmapping gets
<whitequark>
RaYmAn: uh, not exactly
<whitequark>
RaYmAn: there is now, pass --force
<_whitenotifier>
[whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fpPD9
<whitequark>
exisitng one would vomit muxes and gates all over the design
<tnt>
daveshah: I wish your opt pass stuff had an 'effort level'. Because I always get beter timing when asking for unrealistically high frequencies :p
<zkms>
wait is that in nextpnr?
<tnt>
yes.
<daveshah>
tnt: interesting
<zkms>
nice
<daveshah>
It doesn't really work harder if it fails timing
<daveshah>
It will just change some of the numbers around a bit
<tnt>
Like I ask for 58 Mhz ... it fails at 56 MHz. I ask for 100 MHz, it will give me a 59 MHz one :p
<daveshah>
How many seeds are you running it across?
<daveshah>
That is still within randomness bounds.
<daveshah>
I have tended to see slightly worse results with vastly high frequency targets
<whitequark>
daveshah: I've also observed that
<whitequark>
but it could be randomness
<daveshah>
The timing heuristic in the current placer isn't great
<daveshah>
I plan to use the criticality stuff developed in the opt pass to improve the main placer too
<tnt>
MM, let me run that on 10 seeds.
catplant has quit [Ping timeout: 252 seconds]
<tnt>
Mmm, yeah, you might be right that this was just randomness on both the designs I tested with. Trying on more seed doesn't see to show much difference.
<daveshah>
It would be great to have this built in to nextpnr
<daveshah>
Just running 8 threads and picking the best should give a 10% improvement in QoR
<daveshah>
Although defining best becomes harder once you have multiple clock domains...
<whitequark>
daveshah: ok, so, thinking out loud
<whitequark>
for any pair of n-LUT and k-LUT sharing m inputs, they can be re-encoded into a (n+k-m)-LUT
<whitequark>
right?
<whitequark>
*where n-LUT feeds k-LUT.
<tnt>
looks right
<daveshah>
I think there should be a -1 there too?
<whitequark>
right
<tnt>
ah yeah, one input of k-lut is the n-LUT out ...
<daveshah>
Yeap
<sorear>
maybe I can motivate myself to try to do a better logic optimizer at some point
<whitequark>
i wish rtlil was... documented
<whitequark>
at all
<whitequark>
how the hell do i find out what a port is connected to?..
<tnt>
whitequark: I ended up doing a SigMap sigmap(mod); to create a map of all connections.
<tnt>
Then sigmap(cell->getPort("\\EN")) == sigmap(cell_other->getPort("\\EN")) to test if ports are connected.
<whitequark>
hm
<daveshah>
This is somewhat briefly documented in CodingReadme
<tnt>
whitequark: apparently nets can be connected and have plenty of names ... this maps all the names to some unique id to be able to track what's connected to what.
<daveshah>
Yes, unfortunately netlists in Yosys are (and probably have to be) much more complicated than in nextpnr
<daveshah>
This is also because Yosys supports coarse grain synthesis and thus word wide ports and nets
<tnt>
daveshah: yeah, I can understand that. What surprised me a bit was that yosys wasn't keeping such a "map" up-to-date permanently and you have to build it each time.
<daveshah>
Yeah, I'm not sure for the reason behind that either
<sorear>
the polarfire soc thing is A Development, no idea what the GA timeline is
<daveshah>
Guess a year or so?
<daveshah>
That's the usual timescale for FPGAs
<daveshah>
Xilinx it's often near enough a year to dev kits, two years to actually regularly stocking at Digikey
<sorear>
starting from "email us for limited availability dev kit"?
<daveshah>
More like if you're important enough for a dev kit your FAE will drive round with one...
<daveshah>
Incidentally, I'm curious if Lattice will release FPGAs with hard RISC-Vs at some point
<daveshah>
I think they joined a while ago
Hamilton2 has joined ##openfpga
catplant has joined ##openfpga
Hamilton2 has quit [Client Quit]
Hamilton2 has joined ##openfpga
Hamilton2 has quit [Remote host closed the connection]
Hamilton has quit [Ping timeout: 252 seconds]
Hamilton has joined ##openfpga
catplant has quit [Ping timeout: 250 seconds]
Hamilton has quit [Quit: Leaving]
pie___ has quit [Remote host closed the connection]
pie___ has joined ##openfpga
<whitequark>
Found top.$auto$alumacc.cc:474:replace_alu$6.slice[0].adder (cell A) feeding top.$abc$102$auto$blifparse.cc:492:parse_blif$103 (cell B).
<whitequark>
Cell A is a 2-LUT. Cell B is a 2-LUT. Cells share 0 inputs and can be merged into one 3-LUT.
<whitequark>
Found top.$auto$alumacc.cc:474:replace_alu$9.slice[2].adder (cell A) feeding top.$abc$102$auto$blifparse.cc:492:parse_blif$108 (cell B).
<whitequark>
Cell A is a 3-LUT. Cell B is a 3-LUT. Cells share 1 inputs and can be merged into one 4-LUT.
<whitequark>
daveshah: ^
<daveshah>
oooh
<daveshah>
Nice
<tnt>
Looking fwd to trying that :)
<zkms>
nice
<tnt>
So much improvements on the ice40 chain lately, nice to see !
catplant has joined ##openfpga
<whitequark>
daveshah: doesn't merge yet
<whitequark>
working on that
<whitequark>
RTLIL is kind of a pain, though I am warming up to it
catplant has quit [Ping timeout: 250 seconds]
<whitequark>
well... it matches my experience from clifford's awesome ehsm talk exactly
<whitequark>
it is a good IR, and a pain
<whitequark>
like most IRs
<daveshah>
Overall I think Yosys as a framework is fine
<whitequark>
yeah
<daveshah>
It's just the passes need a lot of work
<whitequark>
it's not perfect, but it has an immense amount of good stuff in it
<daveshah>
I dare say new fpga re has exposed weaknesses
<daveshah>
Lack of true dp ram inference and dsp inference
<whitequark>
I wouldn't make Yosys as it is currently done, but I can definitely work with it
<whitequark>
reminds me of LLVM to an extent
<daveshah>
I did speak to Eddie (who has worked with abc a lot) about replacing abc
<daveshah>
He suggested that using it better would be a better approach
<daveshah>
Apparently even Vivado uses it...
<whitequark>
what.
<whitequark>
Vivado?!
<daveshah>
Verified too
<daveshah>
with strings
<daveshah>
That certainly suggests we could be using ABC a lot better than we do at the moment
<daveshah>
I think the net naming is definitely fixable
<whitequark>
I'll keep working on getting non-fucked logic optimization support in yosys though
Flea86 has joined ##openfpga
<daveshah>
Definitely
<whitequark>
daveshah: think someone will optimize the lut pass?
<whitequark>
I'm coding it in uhhhhhh pythonic way
<whitequark>
lots of dicts
<whitequark>
temporary anyway
<whitequark>
someone who isn't me can make bit fuckery out of that but I *loathe* this
<whitequark>
I just want maps
<daveshah>
Yeah don't worry
<daveshah>
I believe dicts are Clifford's magic fast implementation anyway
<daveshah>
Chances are for ice40 it will be more than fast enough
<whitequark>
I mean my evaluate_lut function takes a dict from SigBit to int
<whitequark>
tnt: btw this isn't just for ice40
<whitequark>
ecp5 should be able to do this with minor changes
<daveshah>
It won't because ecp5 carries are fucky
<daveshah>
You have a special primitive that combines 2 bit carry and 2 LUTs
<whitequark>
oh.
<daveshah>
And an XOR between the LUT and the sum output too
<tnt>
whitequark: yeah, I know, I was just speaking in general :P
<whitequark>
daveshah: but it could still help if there are no carries?
<tnt>
I know some of the improvements that happenned were more generic as wel.=l.
<daveshah>
whitequark: that is probably only a transient issue while we sort out how we call abc
<daveshah>
I think optimising around carry is the only thing that can't be fixed easily with the current state of abc
<whitequark>
hrm, okay
<daveshah>
There are some other passes that might be interesting for ECP5
<daveshah>
Like trying to make better use of the MUX2s in the logic cell
<daveshah>
Right now we only use them to build large LUTs (by mapping up to LUT7s in ABC with increasing cost)
<daveshah>
But some structures like large muxes probably have a better implementation
<zkms>
i dont know what exactly is going on but anything that makes yosys/nextpnr give better results makes me happy!
grantsmith has joined ##openfpga
grantsmith has quit [Changing host]
grantsmith has joined ##openfpga
<mithro>
whitequark: In your comments on https://github.com/YosysHQ/yosys/issues/715 -- Your suggestion was that input I0 could be a MUX select for overriding the output of the ALU with one of the inputs?
<whitequark>
yes
<whitequark>
or a constant
<mithro>
whitequark: Okay, great I understood what you were asking for then :-)
<mithro>
whitequark: What was the conclusion you came to with daveshah?
<daveshah>
That a generic LUT merge pass was more useful than something mux specific
<daveshah>
This is really just merging a LUT3 (mux with input) or LUT2 (mux with const) into a LUT3 (alu out)
<daveshah>
*alu lut
<mithro>
daveshah: It is unclear to me if this should be done at techmap or pnr time?
<whitequark>
techmap, definitely
<whitequark>
PNR might do lut *re*coding but for other reasons
<whitequark>
such as avoiding the need for a VCC net
<mithro>
whitequark: I definitely think it needs to be done at techmap with nextpnr but I think with vpr it could be pretty easily done at the clustering/packing stage?
<whitequark>
huh?
<whitequark>
but this means less accurate synthesis results
<whitequark>
and this also means that other backends will not benefit
<whitequark>
like e.g. greenpak...
<daveshah>
Can VPR really merge two LUTs?
<daveshah>
Into a single LUT4
<mithro>
I'm very open to the idea that synthesis is the right place
<daveshah>
We already do too much at PnR, imo
<mithro>
daveshah: I know it can do /some/ transforms like that - but I can also see how I could write an arch model which would enable vpr to do that
<daveshah>
I'm of the opinion that IO buffer insertion should be synthesis
<whitequark>
yes.
<whitequark>
definitely.
<daveshah>
mithro: that sounds very fragile and design specific
<daveshah>
Compared to a generic LUT merge optimisation at synth time
<daveshah>
There's no reason you couldn't do such a thing in nextpnr either
<daveshah>
It's just much nicer and more generic in Yosys
<daveshah>
Ironically, it would probably be easier to implement in nextpnr than Yosys
<daveshah>
Because nextpnr has a much simpler netlist representation due to not needing to support coarse grain or hierarchical netlists unlike Yosys
<mithro>
daveshah: I don't think I have enough information to make such a definite claim
<mithro>
daveshah: I do think I agree that iobuf insertion should probably be a synthesis
<daveshah>
This should be doable already with iopadmap
<daveshah>
Although I think that might have some tristate bugs
<tnt>
\o/ clifford merged the min_ce_use stuff :)
<whitequark>
daveshah: yes
<whitequark>
I hit them
<whitequark>
and I had to work around them in arachne, iirc
<daveshah>
Although tristate is somewhat horrible overall I think we're still behind the vendor tools
<whitequark>
yes
<whitequark>
quite a bit behind
<whitequark>
though, not all that behind the synthesizable verilog spec
<whitequark>
synopsys goes above and beyond what I would consider sane
<whitequark>
propagating tristate through hierarchy is nice though...
<daveshah>
Yes, definitely
<whitequark>
oh right
<daveshah>
At least tristate buffers inside fpga died a death
<whitequark>
*that* was what prevented me from using -noflatten
<whitequark>
wait what?
<whitequark>
this was a thing?
<daveshah>
Virtex II was the last part to have them I think
<whitequark>
huh.
<daveshah>
Lattice ORCA parts definitely had them
<tnt>
ah yeah, good old days :)
<whitequark>
what is the reason they are killed?
<whitequark>
not that I think they're a good idea, just wondering what was the final nail
<daveshah>
Timing I think
<whitequark>
ah
<daveshah>
Things moved to internally unidirectional buffers
<daveshah>
These have the big benefit of redriving the signal and work against capacitance
<whitequark>
oh I see
<whitequark>
it had bidirectional buffers
<whitequark>
yeah... good riddance
<daveshah>
And tristate buffers
<whitequark>
yeah
<daveshah>
I guess the possibility of internal shorts wasn't great either
<whitequark>
Found top._27_ (cell A) feeding top._15_ (cell B).
<whitequark>
Cell A is a 3-LUT. Cell B is a 3-LUT. Cells share 1 input(s) and can be merged into one 4-LUT.
<whitequark>
Combining LUTs into cell A.
<whitequark>
Connecting input 0 as top.\c
<whitequark>
Leaving input 1 as top.\a [1].
<whitequark>
Leaving input 2 as top.\_4_.
<whitequark>
Leaving input 3 as top.\_10_ [1].
<whitequark>
that seems to do exactly what I want
<daveshah>
Looks good!
<whitequark>
now, actually reencoding them...
<tnt>
You need to check that the Cell B is not a carry chain as well.
<whitequark>
that'll be an attribute
<q3k>
daveshah: hm, replaying an ecppack svf on the versa-5g using openocd doesn't seem to trigger a reset after it's done
<q3k>
daveshah: ie i have to manually press the FPGA GSRN button to get my design to run
<daveshah>
This is because initial values are broken in ecp5 synthesis at the moment
<daveshah>
I'm working on a fix, but it's a bit ugly
<q3k>
i'm actually not using trellis/nextpnr :P
<q3k>
i mean, i want to program a diamond .bit using openocd
<q3k>
so i am doing uh ecpunpack -> ecppack -svf
<daveshah>
Does a Diamond svf trigger a reset?
<q3k>
not surea bout an svf, but pgrcmd certainly does
<q3k>
i'll generate an svf from diamond and see
<daveshah>
I followed the template that Diamond generates
<q3k>
hmhm
<q3k>
nope, the lattice deployment tool generated svf has the same issue
* whitequark
sighs
<whitequark>
ok whatever, you get your optimized evaluate_lut
<whitequark>
easier to write that way anyway
<daveshah>
q3k: guess it is a case of sniffing the pgrcmd jtag then
<whitequark>
i... think?
<q3k>
daveshah: although hm
<q3k>
daveshah: it might not be due to an svf difference
<q3k>
daveshah: but maybe the difference between touching the ispclock and bypassing it in the chain?
<q3k>
daveshah: can the ispclock reset the ecp5?
<daveshah>
The ecp5 has no general external reset pin
<daveshah>
Any ispclock reset would be design specific
<daveshah>
I'm not even sure if that's hooked up
<q3k>
right, but diamond has magic to automatically detect the largest fanout reset net and connect that to GSR
<q3k>
and that's what the button on the ecp5 is connected to
<daveshah>
No it's not
<daveshah>
There is no GSR pin!
<daveshah>
There is a GSR primitive internally that can be connected to anything
<q3k>
oh no wait.
<daveshah>
GSR doesn't even have to be on a pin
<q3k>
my design does actually have a normal reset, i forgot this migen target/platform does that.
<q3k>
i guess i'll just fix my reset then.
<q3k>
still, i was running this earlier and somehow it didn't need a button press.
<q3k>
i am slightly confused.
<whitequark>
yeah that sounds hella weird
<daveshah>
Is there a PLL in there?
pie__ has joined ##openfpga
Maylay has quit [Quit: Pipe Terminated]
pie___ has quit [Remote host closed the connection]
<q3k>
daveshah: yes, although its' lock output is not used
<daveshah>
Could just be issues with glitching during PLL startup