| *** tpb has joined #yosys | 00:00 | |
| *** Degi has quit IRC | 00:28 | |
| *** Degi_ has joined #yosys | 00:28 | |
| *** Degi_ is now known as Degi | 00:28 | |
| *** kristianpaul has quit IRC | 00:33 | |
| *** kristianpaul has joined #yosys | 00:34 | |
| *** cr1901_modern has joined #yosys | 01:04 | |
| *** emeb_mac has quit IRC | 01:23 | |
| *** emeb_mac has joined #yosys | 01:26 | |
| *** Forty-Bot has quit IRC | 02:20 | |
| *** tux3 has quit IRC | 03:03 | |
| *** nmz787 has quit IRC | 03:04 | |
| *** xtro has quit IRC | 03:04 | |
| *** FL4SHK has quit IRC | 03:04 | |
| *** FL4SHK has joined #yosys | 03:06 | |
| *** citypw has joined #yosys | 03:08 | |
| *** xtro has joined #yosys | 03:11 | |
| awygle | i swear i've hit this error before, but can somebody suggest a cause for "Assertion failure: it != port_fanin.end()" | 03:46 |
|---|---|---|
| awygle | in nextpnr-ecp5? | 03:46 |
| *** _whitelogger has quit IRC | 03:54 | |
| *** _whitelogger has joined #yosys | 03:56 | |
| awygle | it seems to be related to the --out-of-context argument | 04:32 |
| awygle | (or alternately, something which is only not optimized out because of the --out-of-context argument, i suppose) | 04:32 |
| *** emeb_mac has quit IRC | 06:28 | |
| *** kraiskil has joined #yosys | 06:31 | |
| *** xtro has quit IRC | 06:36 | |
| *** Cerpin has quit IRC | 07:18 | |
| *** Asu has joined #yosys | 07:41 | |
| *** Asu has left #yosys | 07:42 | |
| *** jakobwenzel1 has joined #yosys | 07:44 | |
| *** FireFox317 has joined #yosys | 08:02 | |
| *** proteusguy has quit IRC | 08:03 | |
| *** somlo has quit IRC | 08:04 | |
| *** kraiskil has quit IRC | 08:05 | |
| *** kraiskil has joined #yosys | 08:07 | |
| *** kraiskil has quit IRC | 08:39 | |
| *** kraiskil has joined #yosys | 08:43 | |
| *** kraiskil has quit IRC | 09:07 | |
| *** jakobwenzel1 has quit IRC | 09:42 | |
| *** jakobwenzel1 has joined #yosys | 10:19 | |
| *** kraiskil has joined #yosys | 10:31 | |
| *** FireFox317 has quit IRC | 10:33 | |
| *** FireFox317 has joined #yosys | 10:52 | |
| *** kraiskil has quit IRC | 11:10 | |
| *** kraiskil has joined #yosys | 11:23 | |
| whitequark | awygle: seems like a reportable bug if nothing else | 11:33 |
| daveshah | Just saw this in the backlog | 11:33 |
| daveshah | Feel free to report it, but the core problem is the current timing analysis code is terrible | 11:33 |
| *** somlo has joined #yosys | 11:41 | |
| *** FireFox317 has quit IRC | 11:41 | |
| *** FireFox317 has joined #yosys | 11:49 | |
| *** kraiskil has quit IRC | 12:53 | |
| *** kristianpaul has quit IRC | 12:56 | |
| *** kristianpaul has joined #yosys | 12:57 | |
| *** Thorn has quit IRC | 13:40 | |
| *** Cerpin has joined #yosys | 13:53 | |
| *** emeb has joined #yosys | 13:58 | |
| *** jakobwenzel1 has quit IRC | 13:59 | |
| *** jakobwenzel1 has joined #yosys | 14:03 | |
| *** citypw has quit IRC | 14:10 | |
| *** citypw has joined #yosys | 14:21 | |
| *** ayazar1 has joined #yosys | 14:28 | |
| *** proteusguy has joined #yosys | 14:29 | |
| *** jakobwenzel1 has quit IRC | 14:33 | |
| *** ayazar1 has quit IRC | 14:37 | |
| *** Thorn has joined #yosys | 15:04 | |
| knielsen | set_dont_touch [get_nets -of_objects [get_cells -hierarchical -filter {@ref_name =~ "xaui6g_pads_x1"}]] | 15:23 |
| knielsen | oops, sorry about that mis-paste :-/ | 15:23 |
| *** xtro has joined #yosys | 15:26 | |
| *** az0re has quit IRC | 15:36 | |
| *** FireFox317 has quit IRC | 15:39 | |
| *** citypw has quit IRC | 16:02 | |
| *** az0re has joined #yosys | 16:36 | |
| *** FireFox317 has joined #yosys | 16:39 | |
| whitequark | mwk: daveshah: so i finally completely reversed the very last macrocell bits of ATF15xx | 17:12 |
| whitequark | and i discovered that it has a single bit that controls three things at once | 17:12 |
| whitequark | 1) ff init value 2) inverter between xor.o and ff.d 3) part of a priority encoder routing two product terms | 17:13 |
| mwk | what | 17:16 |
| mwk | like.... why | 17:17 |
| Lofty | That's um. | 17:17 |
| Lofty | Gonna be fun to route | 17:17 |
| whitequark | i spent more than a week just reverse engineering this | 17:17 |
| 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 | 17:18 |
| mwk | wtf | 17:18 |
| whitequark | their datasheet is not just completely wrong about that part of the macrocell but also incredibly misleading | 17:19 |
| whitequark | it has basically nothing to do with reality | 17:19 |
| whitequark | i wish i never even looked at it | 17:19 |
| daveshah | This is not the first time this thing happens | 17:20 |
| daveshah | The iCE40 datasheet is very confusing about global buffer numbering | 17:21 |
| emeb | Atmel datasheets have always been... "interesting". And being acquired by MCHP isn't going to make them less interesting. | 17:21 |
| daveshah | Cost me a few days when I was doing the up5k re | 17:21 |
| *** m4ssi has joined #yosys | 17:27 | |
| *** emeb_mac has joined #yosys | 17:31 | |
| awygle | tbf the internals of the ice40 are also very confusing about global buffer numbering | 17:36 |
| awygle | whitequark: daveshah: ok i'll try to reduce it then, thanks | 17:48 |
| daveshah | Don't worry if you don't get round to it, hopefully that whole file will be significantly rewritten in a few months | 17:49 |
| daveshah | unless you need an interim fix | 17:49 |
| awygle | one would be helpful but it's not required | 17:51 |
| 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 | 17:52 |
| 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 | 17:52 |
| *** kraiskil has joined #yosys | 17:58 | |
| *** kraiskil has quit IRC | 18:15 | |
| *** m4ssi has quit IRC | 18:17 | |
| *** Asu has joined #yosys | 19:03 | |
| whitequark | daveshah: mwk: any ideas for making a model / black box of a macrocell? | 19:54 |
| whitequark | unlike something like an FF the macrocell i have has a *ton* of options | 19:54 |
| *** Asu has quit IRC | 20:08 | |
| *** Asu has joined #yosys | 20:08 | |
| *** FireFox317 has quit IRC | 20:37 | |
| *** m4ssi has joined #yosys | 20:45 | |
| *** m4ssi has quit IRC | 20:53 | |
| *** Asu has quit IRC | 20:59 | |
| *** kristianpaul has quit IRC | 21:24 | |
| *** kristianpaul has joined #yosys | 21:29 | |
| Lofty | whitequark: you could always try a very high-level model and then gradually lower it, I guess | 21:31 |
| Lofty | Do you have plans for the prjbureau stuff to make it into Yosys? | 21:32 |
| whitequark | Lofty: sure | 21:33 |
| whitequark | i mean, i already use yosys. it is an integral part of the fuzzer itself | 21:34 |
| Lofty | I haven't looked at the internals of it other than the published HTML docs, so I'm fairly naive in that area | 21:34 |
| whitequark | because my other three options are: manually construct EDIF netlists, manually construct TT2 files, or pulling in the entirety of WinCUPL | 21:34 |
| 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) | 21:35 |
| whitequark | (yes, it's exactly as insane as it sounds) | 21:35 |
| whitequark | there's a cells.v with behavioral models of all primitives accepted in EDIF | 21:36 |
| whitequark | uh, except LATCH and JKFFEARS | 21:36 |
| whitequark | former because lazy, latter because i don't think you can actually model that in synthesizable verilog | 21:37 |
| whitequark | ... or in this CPLD for that matter | 21:37 |
| mwk | ... wtf is JKFFEARS | 21:37 |
| Lofty | That's a terrifying primitive name | 21:37 |
| mwk | yes | 21:37 |
| whitequark | mwk: JK flip-flop with enable, async reset and async set. | 21:38 |
| whitequark | (async preset?) | 21:38 |
| mwk | ah | 21:38 |
| whitequark | as far as i know (i never tried) it works like this | 21:39 |
| whitequark | ... | 21:39 |
| whitequark | okay i actually don't know how it works for sure | 21:39 |
| Lofty | It'll be nice to have a documented CPLD in Yosys | 21:39 |
| whitequark | i'm pretty sure the vendor docs tell you to not touch the JK flops | 21:40 |
| whitequark | i'm not really sure why it exists in first place or how you'd fit it into the CPLD | 21:40 |
| whitequark | like, | 21:40 |
| whitequark | it would maybe configure the FF as a latch with the J&K inputs feeding an inverse of the Q into D? | 21:41 |
| whitequark | and the J-only/K-only states would be OR'd with user-provided async reset/set? | 21:41 |
| whitequark | ok yeah i can see it working that way. but ... why would you do that | 21:41 |
| mwk | wouldn't J/K inputs be synchronous? | 21:42 |
| whitequark | hence, configure it as a latch | 21:42 |
| whitequark | hm | 21:42 |
| whitequark | wait, you're right | 21:42 |
| mwk | ... or is it literally a J/K latch, as... discussed earlier | 21:42 |
| 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 | 21:42 |
| whitequark | module JKFFEARS(input CLK | 21:42 |
| whitequark | it's synchronous | 21:42 |
| Lofty | So it's a JK *flop*? | 21:43 |
| whitequark | apparently | 21:43 |
| whitequark | module JKFFEARS(input CLK, /*!*/AR, /*!*/AS, CE, J, K, output reg Q); | 21:43 |
| whitequark | here's the full signature | 21:43 |
| Lofty | mwk: dfflegalize, now with support for things that are not D flip-flops | 21:43 |
| Lofty | :P | 21:43 |
| Lofty | Are the !s for negative true? | 21:44 |
| mwk | Lofty: it's never been limitted to D flip-flops | 21:44 |
| whitequark | Lofty: i don't remember | 21:44 |
| mwk | (it also does D latches and SR latches) | 21:44 |
| Lofty | mwk: I am aware, but was joking about the name | 21:44 |
| mwk | yeah, it's misnamed as is customary for yosys stuff dealing with FFs | 21:45 |
| Lofty | [22:45:42] mwk: yeah, it's misnamed as is customary for yosys stuff <--- FTFY | 21:46 |
| whitequark | anyway, i'm still not sure what to do with the macrocell | 21:46 |
| whitequark | it has 24 configuration bits | 21:47 |
| mwk | well | 21:47 |
| whitequark | some of those are trivially easy, just make a parameter that's 0/1 | 21:47 |
| whitequark | some of the others are enumerations or have multiple functions | 21:47 |
| Lofty | I think it depends on what your goal is: reimplement it, or abstract over it | 21:47 |
| whitequark | "something that nextpnr can place" and "something i can expand the bitstream back into" | 21:48 |
| whitequark | these need not be the same representation | 21:48 |
| daveshah | I'm really not sure that nextpnr is the right tool here | 21:48 |
| daveshah | It feels a bit like using gcc on a pic12f | 21:48 |
| daveshah | *for | 21:48 |
| mwk | ... we have one (1) cpld target in yosys right now, and it's uhh a mess I don't quite understand | 21:48 |
| daveshah | My gut feeling is that something custom and heavily SAT based would give much better results for not much more effort | 21:49 |
| 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 | 21:49 |
| whitequark | i can more or less how the nextpnr models programmable logic internally so i thought i could probably hack something together | 21:50 |
| whitequark | if that's a bad idea i might just leave pnr to someone else? | 21:50 |
| whitequark | i did work on gp4par but i did not enjoy working on gp4par | 21:50 |
| daveshah | I mean hacking something together would be fine | 21:50 |
| daveshah | with nextpnr | 21:50 |
| whitequark | one significant issue is that i think yosys' $sop cell is a bad fit for this cPLD | 21:51 |
| whitequark | because it treats product terms quite fluidly | 21:51 |
| whitequark | yosys should probably just synthesize an AIG and leave it to the PNR tool to turn it into SOP as appropriate | 21:52 |
| whitequark | because that's the only way to support cascade, foldback, and variable PTs available depending on FF options | 21:52 |
| whitequark | well either that or group $sop with flops, like a LUTFF primitive, but that seems like too much effort in a wrong place | 21:53 |
| daveshah | Yeah definitely seems like better placed in PnR | 21:53 |
| whitequark | tbh, even AIGs are not ideal | 21:53 |
| mwk | huh, aig-to-sop(ish) in p&r | 21:53 |
| mwk | interesting | 21:54 |
| daveshah | I have no real idea about CPLd details though | 21:54 |
| whitequark | because there's the hard XOR gate stuck between the SOP and the FF/OB | 21:54 |
| whitequark | so if you turn *all* user logic into AIG, you have to re-extract XOR | 21:54 |
| whitequark | the vendor fitter seems to do something (not sure if AIG, though strongly suspect it, but it does strongly normalize) | 21:54 |
| whitequark | it works badly. | 21:55 |
| Lofty | whitequark: for your consideration: full adders are essentially majority-of-3 gates, so you can use them in a MIG flow | 21:57 |
| 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 | 21:57 |
| 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 | 21:58 |
| mwk | right, sounds like a lot of cplds | 21:58 |
| whitequark | and there's the foldback thin | 21:58 |
| whitequark | this, to me, means that you want to synthesize at PT granularity, not SOP granularity | 21:58 |
| whitequark | i'm actually not sure how to synthesize PTs, it's a 40-input-wide AND gate | 22:00 |
| whitequark | with optional inverters on each input | 22:00 |
| Lofty | Is that frangible, or do you have exactly one output? | 22:00 |
| whitequark | *up-to-40-input wide | 22:01 |
| whitequark | Lofty: exactly one | 22:01 |
| whitequark | well | 22:01 |
| whitequark | "frangible" doesn't make sense in a CPLD context | 22:01 |
| 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 | 22:02 |
| whitequark | each MC has 5 PTs, where each PT picks any of those 40 inputs | 22:02 |
| whitequark | frangibility is a way around a limitation of LUT arches, but CPLDs have different limitations in first place | 22:03 |
| *** awordnot has quit IRC | 22:05 | |
| *** awordnot has joined #yosys | 22:05 | |
| Lofty | Hmm. That's useful to know | 22:08 |
| awygle | whitequark: "i did work on gp4par but i did not enjoy working on gp4par" any particular reason? or just greenpaks are weird? | 22:09 |
| 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 | 22:11 |
| awygle | ah | 22:11 |
| 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 | 22:11 |
| whitequark | well on top of the library | 22:11 |
| awygle | "xbpar" iirc yeah | 22:11 |
| whitequark | i'm not even sure if xbpar is the right fit for the task | 22:11 |
| whitequark | what daveshah talked about sounds much more sensible | 22:12 |
| whitequark | gp4 is a LUT arch, too | 22:12 |
| awygle | rqou did some tests on sat-based stuff for the coolrunner-ii i believe | 22:12 |
| whitequark | where? | 22:12 |
| awygle | good question. i'll try to dig it up | 22:12 |
| awygle | hm can't find it. rqou, did i remember this wrong? | 22:17 |
| awygle | oh, here https://github.com/rqou/openfpga/tree/ng-par/src/xbpar | 22:30 |
| tpb | Title: openfpga/src/xbpar at ng-par · rqou/openfpga · GitHub (at github.com) | 22:30 |
| awygle | dunno if that's everything tho :shrug: i'm done hunting in any case | 22:31 |
| *** lf has quit IRC | 23:13 | |
| *** lf has joined #yosys | 23:14 | |
| *** dxld has quit IRC | 23:16 | |
| *** dxld has joined #yosys | 23:18 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!