| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** emeb_mac <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 01:08 | |
| *** emeb_mac <[email protected]> has joined #yosys | 01:10 | |
| *** emeb_mac <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 01:21 | |
| *** emeb_mac <[email protected]> has joined #yosys | 01:23 | |
| *** emeb_mac <[email protected]> has quit IRC (*.net *.split) | 04:58 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has quit IRC (*.net *.split) | 04:58 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:b49d:fc45:e620:8cca> has quit IRC (*.net *.split) | 04:58 | |
| *** lambda <[email protected]> has quit IRC (*.net *.split) | 04:58 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC (*.net *.split) | 04:58 | |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has quit IRC (*.net *.split) | 04:58 | |
| *** cyrozap <cyrozap!~cyrozap@2604:180:2:69f::45de> has quit IRC (*.net *.split) | 04:58 | |
| *** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has quit IRC (*.net *.split) | 04:58 | |
| *** emeb_mac <[email protected]> has joined #yosys | 04:59 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has joined #yosys | 04:59 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:b49d:fc45:e620:8cca> has joined #yosys | 04:59 | |
| *** lambda <[email protected]> has joined #yosys | 04:59 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #yosys | 04:59 | |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has joined #yosys | 04:59 | |
| *** cyrozap <cyrozap!~cyrozap@2604:180:2:69f::45de> has joined #yosys | 04:59 | |
| *** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has joined #yosys | 04:59 | |
| *** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has quit IRC (Max SendQ exceeded) | 04:59 | |
| *** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has joined #yosys | 04:59 | |
| *** Xark <[email protected]> has quit IRC (*.net *.split) | 05:01 | |
| *** agg <[email protected]> has quit IRC (*.net *.split) | 05:01 | |
| *** stefanct <stefanct!ameno@user/stefanct> has quit IRC (*.net *.split) | 05:01 | |
| *** stefanct__ <stefanct__!ameno@user/stefanct> has joined #yosys | 05:01 | |
| *** stefanct__ is now known as stefanct | 05:01 | |
| *** agg <[email protected]> has joined #yosys | 05:01 | |
| *** Xark <[email protected]> has joined #yosys | 05:02 | |
| *** agg is now known as Guest9521 | 05:02 | |
| *** emilazy <emilazy!~emilazy@user/emilazy> has quit IRC (Ping timeout: 252 seconds) | 05:02 | |
| *** promach[m] <promach[m]!~promach@2001:470:69fc:105::ca1> has quit IRC (Ping timeout: 252 seconds) | 05:02 | |
| *** xiretza[m] <xiretza[m]!~xiretzaxi@2001:470:69fc:105::9b1> has quit IRC (Ping timeout: 256 seconds) | 05:02 | |
| *** kaji <kaji!~kajiryoji@2001:470:69fc:105::405b> has quit IRC (Ping timeout: 272 seconds) | 05:02 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC (Ping timeout: 272 seconds) | 05:03 | |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has quit IRC (Ping timeout: 272 seconds) | 05:03 | |
| *** oldtopman <[email protected]> has quit IRC (*.net *.split) | 05:04 | |
| *** Ekho <Ekho!~Ekho@user/ekho> has quit IRC (*.net *.split) | 05:04 | |
| *** mewt <[email protected]> has quit IRC (*.net *.split) | 05:04 | |
| *** dys <dys!~dys@user/dys> has quit IRC (*.net *.split) | 05:04 | |
| *** mwk <mwk!~mwk@yosys/mwk> has quit IRC (*.net *.split) | 05:04 | |
| *** trabucayre <[email protected]> has quit IRC (*.net *.split) | 05:04 | |
| *** srk <srk!~sorki@user/srk> has quit IRC (*.net *.split) | 05:04 | |
| *** trabucay1e <[email protected]> has joined #yosys | 05:04 | |
| *** mewt_ <[email protected]> has joined #yosys | 05:04 | |
| *** mwk_ <mwk_!~mwk@yosys/mwk> has joined #yosys | 05:05 | |
| *** oldtopman <[email protected]> has joined #yosys | 05:05 | |
| *** whitequark <whitequark!~whitequar@2001:470:69fc:105::37> has quit IRC (Ping timeout: 250 seconds) | 05:06 | |
| *** Niklas[m]1 <Niklas[m]1!~nsmlzlmat@2001:470:69fc:105::c93a> has quit IRC (Ping timeout: 252 seconds) | 05:06 | |
| *** CarlosEDP <CarlosEDP!~carlosedp@2001:470:69fc:105::218e> has quit IRC (Ping timeout: 252 seconds) | 05:06 | |
| *** diadatp <diadatp!~diadatp@2001:470:69fc:105::c603> has quit IRC (Ping timeout: 272 seconds) | 05:06 | |
| *** srk <srk!~sorki@user/srk> has joined #yosys | 05:07 | |
| *** Ekho <Ekho!~Ekho@user/ekho> has joined #yosys | 05:10 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:504c:df67:1261:2c14> has joined #yosys | 05:12 | |
| *** emeb_mac <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 05:18 | |
| *** emeb_mac <[email protected]> has joined #yosys | 05:22 | |
| *** jeanthom <[email protected]> has joined #yosys | 05:25 | |
| *** diadatp <diadatp!~diadatp@2001:470:69fc:105::c603> has joined #yosys | 05:34 | |
| *** xiretza[m] <xiretza[m]!~xiretzaxi@2001:470:69fc:105::9b1> has joined #yosys | 05:58 | |
| *** kaji <kaji!~kajiryoji@2001:470:69fc:105::405b> has joined #yosys | 06:00 | |
| *** promach[m] <promach[m]!~promach@2001:470:69fc:105::ca1> has joined #yosys | 06:04 | |
| *** whitequark <whitequark!~whitequar@2001:470:69fc:105::37> has joined #yosys | 06:04 | |
| *** Niklas[m]1 <Niklas[m]1!~nsmlzlmat@2001:470:69fc:105::c93a> has joined #yosys | 06:14 | |
| *** CarlosEDP <CarlosEDP!~carlosedp@2001:470:69fc:105::218e> has joined #yosys | 06:17 | |
| *** jeanthom <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 06:25 | |
| *** emilazy <emilazy!~emilazy@user/emilazy> has joined #yosys | 06:31 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #yosys | 06:32 | |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has joined #yosys | 06:34 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Ping timeout: 240 seconds) | 06:37 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 06:42 | |
| *** emeb_mac <[email protected]> has quit IRC (Quit: Leaving.) | 06:59 | |
| whitequark | mwk_: https://github.com/nmigen/nmigen/issues/270#issuecomment-578783370 | 09:30 |
|---|---|---|
| whitequark | that's the closest thing I have to having it written down | 09:31 |
| whitequark | let's have a meeting on that topic and then I could prepare something more Yosys-oriented, maybe a few slides and a small proposal? | 09:31 |
| *** Guest9521 is now known as agg | 09:40 | |
| *** mwk_ is now known as mwk | 11:28 | |
| *** dormito <dormito!~dullfire@user/dormito> has joined #yosys | 12:00 | |
| dormito | out of curiosity: anyone know if there's a technical reason (like mandatory encrypted bitstreams) that polarfire support can't be added(to yosys & nextpnr)? | 12:04 |
| mwk | *shrug* it's an FPGA, it should be doable | 12:06 |
| mwk | but making a nextpnr target takes a *lot* of work, especially with uncooperative vendor that needs reverse engineering (which is all of them) | 12:06 |
| dormito | lol, yeah. though I've no motivation to mess with porting to new targets. | 12:08 |
| sorear | Not sure I understood the question correctly but I believe polarfire does have mandatory encrypted bitstreams | 12:25 |
| cr1901 | nextpnr can emit something that a downstream tool can encrypt | 12:26 |
| mwk | encrypted *with what* is the question | 12:27 |
| mwk | if this is a Xilinx-like arrangement where the user chooses the key and burns it to the fuses / uploads to eeprom — not a problem, we can do the encryption in nextpnr | 12:27 |
| mwk | (or whatever hypothetical downstream tool ends up being written for bitstream assembly purposes) | 12:28 |
| dormito | I spoke badly | 12:28 |
| dormito | I should have said "mandatory microsemi signinng" or similar. that is the bitstream needs a license(which I guess could come with a microsemi signed key) to be usable. I'm sure there are other ways as well to completely block a libre toolchain from existing | 12:29 |
| mwk | if it's some sort of static vendor encryption key used for all bitstreams that the user does not know... wellll then it has to be *somewhere* in the vendor binary and, while extracting it may ruffle a few feathers, it's perfectly doable | 12:29 |
| dormito | anyhow. I was just curious, since I couldn't fine anything about a project for it (even though xillinx and intel have projets for their fpga). maybe polarfires just aren't as popular | 12:31 |
| mwk | dormito: there are two big potential threats to any given libre tool's existence | 12:31 |
| mwk | one is lack of people willing to do it, the other is lawyers | 12:31 |
| mwk | technical limitations are secondary | 12:32 |
| dormito | lol, I think some lawyers are a threat to everything | 12:32 |
| mwk | the question is: is the vendor willing to spend the time on lawyers to fuck up whatever open source project springs up | 12:32 |
| sorear | i've seen some interest in pfsoc because of the riscv angle | 12:33 |
| mwk | in many cases this cannot be answered without trying | 12:33 |
| sorear | note that even with a libre toolchain the polarfire platform is much worse for tinkering because it's only rated for 50 programs | 12:33 |
| mwk | "rated"? | 12:33 |
| mwk | ... oh wait, it's NVM? | 12:34 |
| sorear | it's NVM | 12:34 |
| dormito | yeah. I have a hifive unlead+expansion board. fooling around with the polarfire fpga would be kind of need... but I'm not going to use a non-floss toolchain to do it. | 12:34 |
| dormito | *hifive unleashed | 12:34 |
| sorear | it's NVM with flash cells in the actual fabric, which gives you much faster startup but cannot tolerate *any* worn-out bit cells | 12:34 |
| dormito | someone recently linked me the icicle key, which seems to be the evolution of that, it looks pretty neat | 12:34 |
| dormito | interesting about the write endurance. I didn't know that at all | 12:36 |
| dormito | sounds pretty terrible for designing a system :/ | 12:36 |
| cr1901 | >the bitstream needs a license | 12:55 |
| cr1901 | Why does Microchip keep doing this shit? I want to like their products, even PIC. But they make it so damn hard. | 12:55 |
| mwk | cr1901: I think that was a hypothetical that was asked about | 12:57 |
| mwk | not something that was actually asserted | 12:57 |
| cr1901 | Ahhh | 12:58 |
| dormito | cr1901: yeah I was just hypothizing on technical reasons that could prevent a floss implementation (I have no technical knowledge of how microsemi's polarfire toolchain works) | 13:29 |
| cr1901 | If Microchip/Microsemi did something like that... I would not be surprised. They do some crappy things to encourage lock in | 13:30 |
| cr1901 | like refusing to upstream their LLVM changes (which ticks me off considering that reg/stack-starved PIC isn't a good fit for LLVM in the first place and yet they made it work) | 13:31 |
| sorear | those were two unrelated companies at the time | 13:34 |
| *** emeb <[email protected]> has joined #yosys | 13:52 | |
| whitequark | cr1901: if the changes required to make LLVM work with PICs are too invasive it's possible they're not worth attempting to upstream anyway | 14:00 |
| cr1901 | upstream isn't the right word... their changes aren't open source period | 14:02 |
| whitequark | ah, that's different | 14:07 |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Ping timeout: 256 seconds) | 14:13 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 14:15 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Excess Flood) | 14:17 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 14:17 | |
| *** trabucay1e is now known as trabucayre | 14:19 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Ping timeout: 272 seconds) | 14:25 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 14:28 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Ping timeout: 256 seconds) | 14:40 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 14:45 | |
| *** emeb_mac <[email protected]> has joined #yosys | 14:52 | |
| *** emeb <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 14:53 | |
| *** emeb <[email protected]> has joined #yosys | 14:54 | |
| *** gsmecher <[email protected]> has joined #yosys | 15:48 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 16:31 | |
| *** jeanthom <[email protected]> has joined #yosys | 16:36 | |
| *** jeanthom <[email protected]> has quit IRC (Ping timeout: 248 seconds) | 16:46 | |
| *** jeanthom <[email protected]> has joined #yosys | 17:16 | |
| xiretza[m] | well, that's what permissive licenses are for | 17:25 |
| *** jeanthom <[email protected]> has quit IRC (Remote host closed the connection) | 17:48 | |
| *** tlwoerner_ is now known as tlwoerner | 18:29 | |
| mwk | whitequark: wrt your undefinedness proposal: having (Undefined & 0) === Undefined, but (0 ? Undefined : 0) === 0 kind of worries me because it disallows the A ? B : 0 -> A & B transformation (at least without adding freezes) | 19:01 |
| mwk | but then I guess I shouldn't criticize an incomplete proposal in the first place | 19:03 |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Ping timeout: 258 seconds) | 19:14 | |
| whitequark | mwk: oh, that comment has an important typo | 19:16 |
| whitequark | should be Uninitialized, not Undefined, because it's not intended for transformations | 19:17 |
| whitequark | it's only for approximating nondeterminism in simulations | 19:17 |
| mwk | ... so we'd have overeager Uninitialized in sim, that deterministically turns into 0 in synth here? | 19:18 |
| mwk | that's... kind of weird, but not unsound | 19:18 |
| whitequark | Uninitialized is "a specific value, either 0 or 1, but you don't know which" | 19:19 |
| whitequark | specific in the sense that you can sample it as many times as you want and it's always the same | 19:19 |
| mwk | I mean, it turns into 0 because of the "& 0" | 19:19 |
| whitequark | oh, sorry, I misread | 19:20 |
| whitequark | there's no Uninitialized in synthesis, well, not directly | 19:20 |
| whitequark | reset_less registers and memories are Uninitialized in sim | 19:20 |
| mwk | is it like LLVM "freeze poison"? | 19:20 |
| whitequark | in synthesis they just... don't have an init value | 19:20 |
| whitequark | you can think of Uninitialized as Verilog's X constrained to this one specific and very limited case of nondeterminism | 19:21 |
| whitequark | constrained so hard that it no longer propagates | 19:21 |
| mwk | that does sound like `freeze poison` | 19:21 |
| whitequark | kind of | 19:21 |
| whitequark | okay, "no longer propagates" is inaccurate | 19:22 |
| whitequark | what I mean is that you're not allowed to take two signals assigned from the same Uninitialized value and assume they have different values | 19:22 |
| mwk | hm | 19:22 |
| mwk | now about the hypothetical $freeze cell | 19:23 |
| mwk | I just had a realization | 19:23 |
| mwk | it has to be a synchronous cell that applies to a given domain, right? | 19:23 |
| whitequark | has it? | 19:23 |
| mwk | like what is $freeze(1'bX)? | 19:23 |
| mwk | is it a constant signal? | 19:23 |
| mwk | or, if used within sync domain, can it chance every clock cycle, or is it stable within the clock cycle? | 19:24 |
| whitequark | hmm | 19:24 |
| whitequark | the one constraint here is that if you do `wire x = $freeze(1'bX); wire a = x; wire b = x;`, then always `a === b` | 19:24 |
| mwk | always? | 19:25 |
| mwk | what does it mean? | 19:25 |
| jix | IMO it can help to specify undef/x/etc. by a mapping between abstract states (that can contain such values) and sets of corresponding concrete states represented by that... instead of trying to specify it for every operation or via allowed transformations | 19:25 |
| mwk | you cannot assume (a & b) === (a & b) when synthesis is involved, unless you only sample the === at clock edges | 19:25 |
| whitequark | hmm | 19:26 |
| mwk | because these two gates won't come up with the result at the same time, necessarily | 19:26 |
| whitequark | I'm thinking of netlist-level equivalence here | 19:27 |
| whitequark | the idea behind the freeze cell is that it stops X-propagation in the optimizer itself | 19:28 |
| mwk | I'm still strongly in favor of having some kind of concrete model of what the freeze cell returns in terms of 1/0/x/... values | 19:29 |
| mwk | it may be that we need to tie all cells, combinatorial or not, to a clock domain and think in terms of that | 19:30 |
| mwk | then $freeze does its work on every cycle | 19:31 |
| mwk | kind of like LLVM on every execution | 19:31 |
| whitequark | I think I see what you mean | 19:31 |
| mwk | and if you have loose asynchronous combinatorial cells... well that's danger territory and we may want to inhibit optimizations here | 19:32 |
| mwk | (yosys does not handle that well atm, by the way) | 19:32 |
| whitequark | if 'x means "you can replace any instances of 'x with any circuit you have around", then $freeze('x) means "you can replace all instances of this specific $freeze cell with any single circuit you have around" | 19:32 |
| *** GenTooMan <[email protected]> has joined #yosys | 19:33 | |
| mwk | ... but that produces a non-'x value | 19:33 |
| mwk | (as in, the circuit needs to produce a non-'x value) | 19:33 |
| whitequark | that's the interesting part | 19:34 |
| whitequark | during synthesis, you cannot know whether a certain wire produces a non-x value, right? | 19:35 |
| mwk | hmm | 19:36 |
| whitequark | you know which wires are definitely 'x, but any inputs can be potentially 'x | 19:36 |
| mwk | well, given some freezes, you can | 19:36 |
| mwk | but absent a freeze, any non-constant can potentially be 'x, right | 19:36 |
| whitequark | the only definitely non-'x values around are constants, yeah | 19:36 |
| whitequark | now, you could certainly freeze all inputs to the module being synthesized | 19:37 |
| mwk | right | 19:38 |
| whitequark | and that was the original intended application: insert freezes at module boundaries, so that a stray 'x in one part of your massive SoC doesn't break something in a completely unrelated IP core from another vendor | 19:38 |
| mwk | heh | 19:38 |
| mwk | yeah, reasonable | 19:39 |
| *** GenTooMan <[email protected]> has quit IRC (Ping timeout: 248 seconds) | 19:39 | |
| mwk | (I mean you can still get hit by metastability given shitty enough IP, but other than that, yes) | 19:39 |
| whitequark | one major toolchain design issue at a time, mwk! | 19:40 |
| whitequark | ... not that i have a right to complain (looks at the HDL she maintains) | 19:41 |
| mwk | I kind of see them as related | 19:41 |
| mwk | I mean, freeze can only do its job properly if it has no metastability on input | 19:41 |
| whitequark | soooort of | 19:42 |
| mwk | so while the optimizer on the shit module is allowed to do any kinds of logic shenanigans, it's not allowed to just optimize away a synchronizer and connect a signal from an async clock domain | 19:42 |
| whitequark | this all ties back to 'x meaning three completely unrelated things in Verilog | 19:42 |
| whitequark | if we had separate 'u(ninitialized), 'm(etastable), and 'd(ontcare), then $freeze would turn 'u and 'd into "some constant", and pass through 'm | 19:43 |
| mwk | mhm | 19:43 |
| killjoy | <comment without reading backscroll> Unless that syncronizer doesn't have an effect on the output of the shit module. | 19:43 |
| whitequark | this would be really useful in simulations with timing data | 19:44 |
| mwk | and we'd need a different mechanism for avoiding 'm, got it | 19:44 |
| whitequark | yes | 19:44 |
| mwk | which would involve guarantees in optimizer to only make a 'm for actual metastability problems and never for just an 'x | 19:44 |
| mwk | reasonable | 19:45 |
| mwk | and you could statically prove there can never be 'm by showing that every CDC involves synchronizers | 19:45 |
| whitequark | well | 19:46 |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 19:46 | |
| whitequark | there's plenty of CDC that doesn't need synchronizers | 19:46 |
| whitequark | where you cross between related clocks | 19:46 |
| mwk | right, that | 19:46 |
| mwk | but related domains also cannot result in 'm | 19:46 |
| mwk | (at least the right kind of related) | 19:46 |
| whitequark | (I've spent a lot of time thinking about that for CXXRTL; it's a really tricky problem!!) | 19:47 |
| mwk | oh it sure is | 19:47 |
| whitequark | which neither Verilog nor VHDL actually solve in any meaningful way, so it's -also- novel research | 19:47 |
| mwk | ... I consider special-casing "same clock signal" vs "different clock signals" in my memory inference code like the biggest wart in it | 19:48 |
| mwk | because there are meaningfully different inference options between truly async domains and related domains | 19:48 |
| whitequark | "are these clocks the same" currently makes a lot of possible CXXRTL outputs unsound | 19:48 |
| whitequark | yes | 19:48 |
| mwk | but there's no way I can learn this information given our current netlist format | 19:49 |
| mwk | (it may even differ between instances of a given module) | 19:49 |
| whitequark | anything hierarchical in CXXRTL, even with a single clock domain, currently produces unsound simulation code | 19:49 |
| whitequark | which normally doesn't come up because of flatten, but... blackboxes | 19:49 |
| whitequark | I've considered adding clock tree analysis as a core pass just for this | 19:50 |
| whitequark | to sidestep the problem a bit, at least | 19:50 |
| whitequark | it's kind of a nightmare | 19:50 |
| mwk | I feel at some point we need a discussion about coming up with a language / set of attributs / whatever to describe interface properties of modules, blackboxes in particular | 19:50 |
| whitequark | yes please | 19:50 |
| mwk | ... and yes, that | 19:50 |
| whitequark | CXXRTL has a poor approximation of it, the cxxrtl_comb and cxxrtl_sync attributes | 19:51 |
| mwk | arguably Verilog's specify could be this kind of language, but... I'm wary of it | 19:51 |
| whitequark | there's no domain attached to cxxrtl_sync so it has limited usefulness | 19:51 |
| mwk | (and it still cannot know about "this clk is twice the frequency of that and phase aligned") | 19:51 |
| whitequark | ... it's so frustrating trying to write a decent simulator for once and then finding out you have to design entire aspects of core semantics | 19:51 |
| whitequark | which as far as i know no one tried to systematically address in a production compiler before | 19:52 |
| mwk | ... see also my rant about EDA tools in general | 19:52 |
| mwk | yes | 19:52 |
| mwk | and the ugly part is that there's a pull in the other direction, too | 19:54 |
| mwk | of the "just make it work with this output of that other shitty EDA tool that uses blackboxes with completely unknown semantics" kind | 19:54 |
| whitequark | yep | 19:54 |
| mwk | ... I mean, yosys even supports using undefined cells | 19:55 |
| mwk | and I'm pretty sure a lot of people would yell at me if I disallowed that | 19:55 |
| whitequark | there's nothing wrong with it, is there? | 19:55 |
| whitequark | it's morally equivalent to having toplevel inputs and outputs | 19:55 |
| whitequark | a blackbox and a toplevel IO are duals | 19:56 |
| mwk | it's morally equivalent to having toplevel inouts | 19:56 |
| whitequark | * a blackbox and a few toplevel IOs are duals | 19:56 |
| whitequark | ohh, sorry | 19:56 |
| whitequark | yes, that's cursed | 19:56 |
| whitequark | and i'm pretty sure it doesn't actually work as it should a lot of the time? | 19:57 |
| mwk | we regularly get bug reports about it, yes | 19:57 |
| mwk | also to actually disallow them I'd have to fix yosys itself to not rely on it first | 19:57 |
| whitequark | i remember that bug with inouts i fixed in flatten | 19:58 |
| mwk | eg. the way memory_bram works is that for a short moment you have a $__XILINX_RAMB36 temporary cell that is never defined even as a blackbox, which is then techmapped | 19:58 |
| whitequark | that was really bad | 19:58 |
| whitequark | https://github.com/YosysHQ/yosys/pull/2356 this one | 20:00 |
| whitequark | inouts are cursed in general | 20:00 |
| whitequark | I feel like maybe they shouldn't survive past the frontend | 20:00 |
| mwk | well | 20:00 |
| mwk | there is the issue of toplevel inouts which have to exist | 20:00 |
| mwk | anyway, I have a proposal for them in the wednesday slides | 20:01 |
| whitequark | alright | 20:01 |
| mwk | I am still not sure whether I actually want this proposal to happen or to disallow them outright | 20:01 |
| whitequark | the way I'd do it is by making it a constraint violation to connect a toplevel inout to anything other than an inout cell port | 20:02 |
| whitequark | in general, make it legal to connect inout ports only to other inout ports | 20:03 |
| whitequark | exactly once | 20:03 |
| mwk | ... that breaks synthesis for FPGAs where tristate OBUF and IBUF are separate primitives and you have to instantiate both for IO port | 20:04 |
| whitequark | okay, scratch the "exactly once" part | 20:04 |
| mwk | and IBUF input is not an inout | 20:04 |
| whitequark | if the synthesizer never tries to interpret wires connected to inout ports it still works out fine | 20:04 |
| mwk | well | 20:04 |
| whitequark | hm | 20:04 |
| whitequark | okay, I hate it | 20:04 |
| whitequark | we all know what inout is supposed to mean, which is more or less an analog connection | 20:05 |
| mwk | my proposal is to basically have multi-driver/tristate nets as second-class citizens in the IR | 20:05 |
| whitequark | but it's weirdly integrated with the rest of semantics | 20:05 |
| whitequark | yeah | 20:06 |
| mwk | and while all other wires would have LLVM-like SSA behavior (wire and the cell driving it are one and the same), this kind of wires would be explicitely cursed by design and avoided by all the optimization passes | 20:06 |
| whitequark | making it a net property rather than a port property is more reasonable in light of IBUF/OBUF | 20:06 |
| whitequark | I like that approach a lot | 20:06 |
| mwk | also connectable only to special cells that have special port type | 20:06 |
| whitequark | that still screws IBUF, no? | 20:06 |
| mwk | not necessarily | 20:07 |
| mwk | my plan involves adapters in both directions | 20:07 |
| mwk | a "wire observer" that gives you a SSA value out of a cursed wire | 20:07 |
| mwk | which you then connect to IBUF | 20:07 |
| mwk | and, if directly driven by non-cursed logic, you insert a "wire driver" cell | 20:08 |
| mwk | (which is a TBUF that may or may not have output enable tied to 1) | 20:08 |
| whitequark | this is a really contrived way to do it but I see why you're going for it | 20:08 |
| mwk | also the cell port type does not need to be the same as Verilog input/inout/output | 20:09 |
| mwk | consider a TBUF cell; it may have an output port type, but it's pretty obvious it's a different kind of output than an AND cell | 20:09 |
| mwk | and we'd want them as separate kinds in the IR | 20:09 |
| whitequark | reasonable | 20:09 |
| mwk | and yes, this requires having that information in the cell library | 20:10 |
| mwk | we might reuse (* iopad_external_pin *) for that | 20:10 |
| whitequark | I wanted to say "if you annotate cells you might as well switch buffers to use inouts" but an attribute like that is less invasive and, yeah, the kind is different anyhow | 20:11 |
| mwk | the thing is, there are 4 kinds of ports really | 20:12 |
| mwk | input, inout, output that may be 'z, output that cannot be 'z | 20:13 |
| mwk | anyway... yeah, lots of things to design in the IR | 20:18 |
| mwk | now I'm wondering if we need first-class clock domain support in that | 20:18 |
| mwk | there's a good argument for "YES PLEASE", and also the counter-argument of "but what to do with non-annotated blackboxes" | 20:20 |
| mwk | (at the very least I believe our IR needs to have a definite "THIS IS A SYNCHRONIZER DON'T TOUCH" marking for FFs) | 20:24 |
| killjoy | I would second that. You always need stuff like that. | 20:25 |
| mwk | well | 20:30 |
| mwk | ... I guess I'll need to make more slides | 20:30 |
| whitequark | yes, definitely need the ability to mark synchronizers | 20:30 |
| whitequark | you need it anyway if you do retiming | 20:31 |
| mwk | we already need it | 20:31 |
| mwk | right now a synchronizer FF can end up merged into a memory or a DSP | 20:31 |
| mwk | nothing prevents that | 20:31 |
| killjoy | That's bad, m'kay. | 20:33 |
| *** dormito <dormito!~dullfire@user/dormito> has quit IRC (Ping timeout: 272 seconds) | 20:35 | |
| mwk | well I'll gladly fix it as soon as we have an IR where the concept of a synchronizer is actually defined | 20:35 |
| cr1901 | I'm kinda OOTL... is the above discussion for a new yosys IR or new additions to the existing IR? | 21:12 |
| mwk | the synchronizer part should go in ASAP; other than that, we're thinking of having a new IR, but this is not something we're actually commited to any time soon | 21:15 |
| *** dormito <dormito!~dullfire@user/dormito> has joined #yosys | 21:37 | |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Read error: Connection reset by peer) | 22:09 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #yosys | 22:12 | |
| *** killjoy <killjoy!~nameless@user/killjoy> has quit IRC (Ping timeout: 258 seconds) | 23:20 | |
| *** emeb <[email protected]> has quit IRC (Quit: Leaving.) | 23:20 | |
| *** killjoy <[email protected]> has joined #yosys | 23:23 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!