az0re has quit [Remote host closed the connection]
FireFox317 has quit [Ping timeout: 240 seconds]
citypw has quit [Ping timeout: 240 seconds]
az0re has joined #yosys
FireFox317 has joined #yosys
<whitequark>
mwk: daveshah: so i finally completely reversed the very last macrocell bits of ATF15xx
<whitequark>
and i discovered that it has a single bit that controls three things at once
<whitequark>
1) ff init value 2) inverter between xor.o and ff.d 3) part of a priority encoder routing two product terms
<mwk>
what
<mwk>
like.... why
<Lofty>
That's um.
<Lofty>
Gonna be fun to route
<whitequark>
i spent more than a week just reverse engineering this
<whitequark>
in the end i had to generate 32 bitstreams, use BSCAN to apply test vectors, build truth tables, use an SMT solver to minimize those, and then hand-minimize the 32 controlling expressions into something resembling 1
<mwk>
wtf
<whitequark>
their datasheet is not just completely wrong about that part of the macrocell but also incredibly misleading
<whitequark>
it has basically nothing to do with reality
<whitequark>
i wish i never even looked at it
<daveshah>
This is not the first time this thing happens
<daveshah>
The iCE40 datasheet is very confusing about global buffer numbering
<emeb>
Atmel datasheets have always been... "interesting". And being acquired by MCHP isn't going to make them less interesting.
<daveshah>
Cost me a few days when I was doing the up5k re
m4ssi has joined #yosys
emeb_mac has joined #yosys
<awygle>
tbf the internals of the ice40 are also very confusing about global buffer numbering
<awygle>
whitequark: daveshah: ok i'll try to reduce it then, thanks
<daveshah>
Don't worry if you don't get round to it, hopefully that whole file will be significantly rewritten in a few months
<daveshah>
unless you need an interim fix
<awygle>
one would be helpful but it's not required
<awygle>
this came up in the context that i have a module that needs to be able to run at 266.67 MHz, so i wanted to set up an nmigen unit test that made sure i didn't break that constraint
<awygle>
obviously i need to test it in the full system but if it doesn't run that fast out-of-context then it's already game over
kraiskil has joined #yosys
kraiskil has quit [Read error: No route to host]
m4ssi has quit [Remote host closed the connection]
Asu has joined #yosys
<whitequark>
daveshah: mwk: any ideas for making a model / black box of a macrocell?
<whitequark>
unlike something like an FF the macrocell i have has a *ton* of options
Asu has quit [Quit: Konversation terminated!]
Asu has joined #yosys
FireFox317 has quit [Ping timeout: 246 seconds]
m4ssi has joined #yosys
m4ssi has quit [Remote host closed the connection]
Asu has quit [Quit: Konversation terminated!]
kristianpaul has quit [Quit: WeeChat 2.3]
kristianpaul has joined #yosys
<Lofty>
whitequark: you could always try a very high-level model and then gradually lower it, I guess
<Lofty>
Do you have plans for the prjbureau stuff to make it into Yosys?
<whitequark>
Lofty: sure
<whitequark>
i mean, i already use yosys. it is an integral part of the fuzzer itself
<Lofty>
I haven't looked at the internals of it other than the published HTML docs, so I'm fairly naive in that area
<whitequark>
because my other three options are: manually construct EDIF netlists, manually construct TT2 files, or pulling in the entirety of WinCUPL
<whitequark>
well, i had to do the second option for a few cases anyway, because there are CPLD features that can't be exploited from just EDIF (yes, really)
<whitequark>
(yes, it's exactly as insane as it sounds)
<whitequark>
there's a cells.v with behavioral models of all primitives accepted in EDIF
<whitequark>
uh, except LATCH and JKFFEARS
<whitequark>
former because lazy, latter because i don't think you can actually model that in synthesizable verilog
<whitequark>
... or in this CPLD for that matter
<mwk>
... wtf is JKFFEARS
<Lofty>
That's a terrifying primitive name
<mwk>
yes
<whitequark>
mwk: JK flip-flop with enable, async reset and async set.
<whitequark>
(async preset?)
<mwk>
ah
<whitequark>
as far as i know (i never tried) it works like this
<whitequark>
...
<whitequark>
okay i actually don't know how it works for sure
<Lofty>
It'll be nice to have a documented CPLD in Yosys
<whitequark>
i'm pretty sure the vendor docs tell you to not touch the JK flops
<whitequark>
i'm not really sure why it exists in first place or how you'd fit it into the CPLD
<whitequark>
like,
<whitequark>
it would maybe configure the FF as a latch with the J&K inputs feeding an inverse of the Q into D?
<whitequark>
and the J-only/K-only states would be OR'd with user-provided async reset/set?
<whitequark>
ok yeah i can see it working that way. but ... why would you do that
<mwk>
wouldn't J/K inputs be synchronous?
<whitequark>
hence, configure it as a latch
<whitequark>
hm
<whitequark>
wait, you're right
<mwk>
... or is it literally a J/K latch, as... discussed earlier
<Lofty>
[22:41:54] whitequark: ok yeah i can see it working that way. but ... why would you do that <-- I find myself asking this question a lot in FPGA architecture
<Lofty>
mwk: dfflegalize, now with support for things that are not D flip-flops
<Lofty>
:P
<Lofty>
Are the !s for negative true?
<mwk>
Lofty: it's never been limitted to D flip-flops
<whitequark>
Lofty: i don't remember
<mwk>
(it also does D latches and SR latches)
<Lofty>
mwk: I am aware, but was joking about the name
<mwk>
yeah, it's misnamed as is customary for yosys stuff dealing with FFs
<Lofty>
[22:45:42] mwk: yeah, it's misnamed as is customary for yosys stuff <--- FTFY
<whitequark>
anyway, i'm still not sure what to do with the macrocell
<whitequark>
it has 24 configuration bits
<mwk>
well
<whitequark>
some of those are trivially easy, just make a parameter that's 0/1
<whitequark>
some of the others are enumerations or have multiple functions
<Lofty>
I think it depends on what your goal is: reimplement it, or abstract over it
<whitequark>
"something that nextpnr can place" and "something i can expand the bitstream back into"
<whitequark>
these need not be the same representation
<daveshah>
I'm really not sure that nextpnr is the right tool here
<daveshah>
It feels a bit like using gcc on a pic12f
<daveshah>
*for
<mwk>
... we have one (1) cpld target in yosys right now, and it's uhh a mess I don't quite understand
<daveshah>
My gut feeling is that something custom and heavily SAT based would give much better results for not much more effort
<whitequark>
daveshah: the problem is that i'm not familiar with SAT solvers and i don't really know how to write a PNR tool from scratch
<whitequark>
i can more or less how the nextpnr models programmable logic internally so i thought i could probably hack something together
<whitequark>
if that's a bad idea i might just leave pnr to someone else?
<whitequark>
i did work on gp4par but i did not enjoy working on gp4par
<daveshah>
I mean hacking something together would be fine
<daveshah>
with nextpnr
<whitequark>
one significant issue is that i think yosys' $sop cell is a bad fit for this cPLD
<whitequark>
because it treats product terms quite fluidly
<whitequark>
yosys should probably just synthesize an AIG and leave it to the PNR tool to turn it into SOP as appropriate
<whitequark>
because that's the only way to support cascade, foldback, and variable PTs available depending on FF options
<whitequark>
well either that or group $sop with flops, like a LUTFF primitive, but that seems like too much effort in a wrong place
<daveshah>
Yeah definitely seems like better placed in PnR
<whitequark>
tbh, even AIGs are not ideal
<mwk>
huh, aig-to-sop(ish) in p&r
<mwk>
interesting
<daveshah>
I have no real idea about CPLd details though
<whitequark>
because there's the hard XOR gate stuck between the SOP and the FF/OB
<whitequark>
so if you turn *all* user logic into AIG, you have to re-extract XOR
<whitequark>
the vendor fitter seems to do something (not sure if AIG, though strongly suspect it, but it does strongly normalize)
<whitequark>
it works badly.
<Lofty>
whitequark: for your consideration: full adders are essentially majority-of-3 gates, so you can use them in a MIG flow
<whitequark>
mwk: daveshah: so the idea is that you can borrow some PTs from the ST to use: custom OE rather than GOEn, custom CLK rather than GCLKn, custom AR/AS
<whitequark>
you can also forward the ST to the next macrocell's ST while (if you want) borrowing PT2 to drive FF or OB of this macrocell
<mwk>
right, sounds like a lot of cplds
<whitequark>
and there's the foldback thin
<whitequark>
this, to me, means that you want to synthesize at PT granularity, not SOP granularity
<whitequark>
i'm actually not sure how to synthesize PTs, it's a 40-input-wide AND gate
<whitequark>
with optional inverters on each input
<Lofty>
Is that frangible, or do you have exactly one output?
<whitequark>
*up-to-40-input wide
<whitequark>
Lofty: exactly one
<whitequark>
well
<whitequark>
"frangible" doesn't make sense in a CPLD context
<whitequark>
it works like this. each logic block (16 macrocells) chooses which 40 inputs it wants to have, picked out of the global bus where every pin and FF Q signal on chip goes
<whitequark>
each MC has 5 PTs, where each PT picks any of those 40 inputs
<whitequark>
frangibility is a way around a limitation of LUT arches, but CPLDs have different limitations in first place
awordnot has quit [Read error: Connection reset by peer]
awordnot has joined #yosys
<Lofty>
Hmm. That's useful to know
<awygle>
whitequark: "i did work on gp4par but i did not enjoy working on gp4par" any particular reason? or just greenpaks are weird?
<whitequark>
awygle: it's written in azonenberg's dialect of C++ and not only i do not like C++, we also prefer different subsets of C++ too
<awygle>
ah
<whitequark>
i'm fine with contributing to it (and might do more of that in the future), but i don't wanna do my PAR on top of it
<whitequark>
well on top of the library
<awygle>
"xbpar" iirc yeah
<whitequark>
i'm not even sure if xbpar is the right fit for the task
<whitequark>
what daveshah talked about sounds much more sensible
<whitequark>
gp4 is a LUT arch, too
<awygle>
rqou did some tests on sat-based stuff for the coolrunner-ii i believe
<whitequark>
where?
<awygle>
good question. i'll try to dig it up
<awygle>
hm can't find it. rqou, did i remember this wrong?