Sunday, 2020-05-03

*** tpb has joined #yosys		00:00
az0re	Hey, I'm not saying it's easy, just that it would be cool :)	00:03
*** bwidawsk has quit IRC		00:28
*** alexhw has quit IRC		00:31
*** alexhw has joined #yosys		00:36
*** emeb has quit IRC		00:44
*** bwidawsk has joined #yosys		00:44
*** emeb_mac has joined #yosys		00:46
*** daknig has joined #yosys		00:53
*** X-Scale` has joined #yosys		01:11
*** X-Scale has quit IRC		01:12
*** X-Scale` is now known as X-Scale		01:12
*** citypw has joined #yosys		01:16
*** citypw_ has joined #yosys		01:28
*** citypw has quit IRC		01:29
*** strobokopp has quit IRC		01:56
*** Degi_ has joined #yosys		03:50
*** Degi has quit IRC		03:50
*** Degi_ is now known as Degi		03:50
*** BinaryLust has quit IRC		05:29
*** BinaryLust has joined #yosys		06:26
*** _whitelogger has quit IRC		06:39
*** _whitelogger has joined #yosys		06:41
*** emeb_mac has quit IRC		06:55
*** voxadam_ has quit IRC		07:19
*** voxadam has joined #yosys		07:23
*** vidbina has joined #yosys		07:45
*** Asu has joined #yosys		09:02
*** vidbina has quit IRC		09:40
*** _whitelogger has quit IRC		10:36
*** _whitelogger has joined #yosys		10:38
*** voxadam has quit IRC		11:44
*** Ristovski has quit IRC		12:07
*** voxadam has joined #yosys		12:09
*** [Ristovski] has joined #yosys		12:10
*** vidbina has joined #yosys		12:12
*** daknig has quit IRC		12:17
*** Asu has quit IRC		12:28
*** Asu has joined #yosys		12:28
*** Asu has quit IRC		12:32
*** [Ristovski] is now known as Ristovski		12:40
*** Asu has joined #yosys		12:41
*** daknig has joined #yosys		13:11
*** daknig has quit IRC		13:24
*** vidbina has quit IRC		13:56
*** voxadam has quit IRC		14:24
*** voxadam has joined #yosys		14:33
*** daknig has joined #yosys		14:34
*** adjtm has quit IRC		14:39
*** adjtm has joined #yosys		14:39
*** voxadam has quit IRC		14:50
*** vidbina has joined #yosys		14:54
*** craigo_ has quit IRC		15:02
*** voxadam has joined #yosys		15:10
*** BinaryLust has quit IRC		15:33
*** emeb has joined #yosys		15:42
*** citypw_ has quit IRC		16:27
FL4SHK	az0re: I use different syntax for Verilog constructs that end up exactly the same as in Verilog	16:35
FL4SHK	I don't plan on letting you use Verilog syntax directly	16:37
whitequark	az0re: re undecidability: the Verilog simulation semantics are nondeterministic by design, aren't they?	16:37
FL4SHK	but I do plan on it being possible to use Verilog modules that are external to what's been written in my language	16:38
FL4SHK	oh, but the generated Verilog produced by my HDL won't include the parameterization	16:39
FL4SHK	That stuff has to be flattened	16:39
whitequark	FL4SHK: have you seen the connect_rpc Yosys command?	16:39
FL4SHK	I haven't	16:39
FL4SHK	What does that command do?	16:39
whitequark	lets you instantiate parametric modules in your HDL from any other HDL supported by Yosys	16:41
whitequark	e.g. you can take a parametric nMigen design and instantiate it from Verilog	16:42
FL4SHK	I see.	16:42
FL4SHK	I've peeked at nMigen before.	16:42
FL4SHK	It seems nice.	16:42
whitequark	thanks!	16:44
whitequark	I've been trying to improve the state of HDL interop in Yosys while working on it, too.	16:44
FL4SHK	My language is intended to be compiled into behavioral Verilog, btw	16:45
FL4SHK	but I can probably just make that only one of the output modes	16:45
FL4SHK	and have... was it RTLIL?	16:45
FL4SHK	Could just support outputing that.	16:45
FL4SHK	Right now I'm just trying to get a minimum viable product built.	16:46
FL4SHK	code is here: https://github.com/fl4shk/fling_hdl	16:47
tpb	Title: GitHub - fl4shk/fling_hdl: A Hardware Description Language with features similar to my custom programming language, Fling (at github.com)	16:47
FL4SHK	Fling the programming language is on hold, haha	16:47
whitequark	yeah, RTLIL	16:50
whitequark	RTLIL is a lot easier to emit correctly than Verilog	16:50
whitequark	so much so that nMigen doesn't bother with the latter	16:50
FL4SHK	There are certain advantages to spitting out behavioral Verilog	16:50
whitequark	yeah?	16:51
FL4SHK	One of them is that it's perhaps easier to debug the compiler :P	16:51
FL4SHK	I plan on using the \identifier feature of Verilog	16:51
whitequark	oh, nMigen does output a .debug.v file next to every .il file	16:51
whitequark	since in most cases the converted Verilog is enough	16:51
whitequark	it's just that it "outsources" the complexity of writing correct Verilog to Yosys	16:52
FL4SHK	My language is actually defined in terms of Verilog	16:52
FL4SHK	i.e. simulation, for example, uses Verilog semantics	16:52
FL4SHK	the `module` keyword, in my language, is equivalent to a single `module` in Verilog	16:53
whitequark	full disclosure: I think just about everything about Verilog is awfully designed	16:53
FL4SHK	I think it's fine as a compilation target.	16:53
whitequark	so in my eyes, that's a strict downside of your language, though there could be reasons why it's necessary	16:53
FL4SHK	It's pretty terrible for actually developing stuff in	16:53
whitequark	I think it's even worse as a compilation target than for developing things in	16:53
FL4SHK	Maybe our viewpoints are different	16:54
whitequark	it is unable to represent most of the interesting semantics while having so much nonessential complexity that tooling is nearly always incorrect	16:54
FL4SHK	It's pretty terrible	16:54
FL4SHK	I see	16:54
whitequark	I think the way 1364.1 defines a DFF with async set and reset is very enlightening	16:54
whitequark	it requires you to write a code with sim/synth mismatch	16:54
whitequark	*write a code pattern	16:55
FL4SHK	That's uh	16:55
FL4SHK	That's unfortunate	16:55
whitequark	meanwhile there's no well-defined "compilation target" subset at all with SystemVerilog, which is even worse than the poorly defined compilation target defined in 1364.1	16:55
FL4SHK	I've never really run into simulation/synthesis mismatches	16:56
whitequark	which SV constructs do I have to implement to ingest the output of your HDL? well, the only way is to look at the sources of your tool	16:56
whitequark	multiply by the number of tools.	16:56
whitequark	there are tools that supposedly ingest Verilog that can't cope with concatenations on assign LHS	16:56
FL4SHK	what	16:56
FL4SHK	I use that too frequently	16:56
whitequark	there's a yosys issue, moment	16:56
FL4SHK	yosys doesn't support that?!	16:57
whitequark	https://github.com/YosysHQ/yosys/issues/1286	16:57
tpb	Title: Yosys emits assigns with a concatenated expression on the LHS · Issue #1286 · YosysHQ/yosys · GitHub (at github.com)	16:57
whitequark	yosys does	16:57
whitequark	other tools don't	16:57
FL4SHK	ah	16:57
FL4SHK	Icarus Verilog supports it just fine	16:57
FL4SHK	assigning to a concatenation isn't even difficult, though, tbh	16:57
whitequark	Icarus supports nearly all of 1364, I think	16:57
whitequark	I'm talking about using Verilog as a compilation target	16:57
FL4SHK	I always miss that feature of Verilog when I write VHDL	16:57
whitequark	it requires you to emit code readable by the lowest common denominator of every possible tool	16:58
FL4SHK	Quartus supports it just fine	16:58
whitequark	since there's no actual spec for "structural Verilog"	16:58
FL4SHK	I wonder how well Verilator does	16:58
whitequark	it does support that	16:58
FL4SHK	What about Vivado?	16:58
whitequark	the tool from #1286 is OpenSTA	16:58
whitequark	https://github.com/The-OpenROAD-Project/OpenSTA this one I think	16:59
tpb	Title: GitHub - The-OpenROAD-Project/OpenSTA: OpenSTA engine (at github.com)	16:59
FL4SHK	I'll make RTLIL a primary goal	16:59
whitequark	RTLIL is much better than Verilog as a compilation target, though still imperfect because its semantics are pretty much just "what Yosys does"	17:00
whitequark	I've spent quite a while nailing it down in the manual and tightening the verifier in Yosys, but there are still parts left that are underdefined	17:00
FL4SHK	I didn't know that concatenations being assigned to was so poorly supported.	17:00
FL4SHK	That strikes me as very unfortunate because it's such a nice thing	17:00
whitequark	I think it's supported in most tools you might encounter	17:00
daveshah	This isn't a problem with synrhesis tools	17:00
whitequark	that's not the problem I'm talking about	17:00
daveshah	It's a problem with the undefined nature of "structural Verilog"	17:01
whitequark	^	17:01
FL4SHK	Maybe I'll add in support for spitting out VHDL	17:01
whitequark	personally I'm looking forward to better support of FIRRTL across the board, because it has well-defined semantics, a spec you can verify conformance to, and a specific compilation target subset	17:02
whitequark	but... it's just not there yet	17:02
FL4SHK	I'll have to give that a try, too.	17:07
*** vidbina has quit IRC		17:13
*** Cerpin has quit IRC		17:19
*** emeb_mac has joined #yosys		17:19
*** dys has joined #yosys		17:29
*** emeb_mac has quit IRC		17:37
az0re	whitequark: I think some of what you just wrote should be pasted into issue #2004, especially the part about 1364.1 requiring a code pattern that guarantees sim/synth mistmatch	17:43
whitequark	I assumed this all is well-known among tooling developers, I think, but you have my permission to paste as you see fit	17:46
*** Cerpin has joined #yosys		18:03
ZirconiumX	[17:56:46] whitequark: there are tools that supposedly ingest Verilog that can't cope with concatenations on assign LHS <--- Quartus in VQM (Verilog Quartus Mapping) mode won't accept it either	18:03
ZirconiumX	VQM looks a lot like Verilog '95 except incredibly sucky.	18:03
ZirconiumX	Or maybe that's just an inherited property of Verilog '95	18:05
whitequark	FL4SHK: ^	18:07
ZirconiumX	It's not even much faster to parse than using the full SV parser that Quartus has.	18:10
ZirconiumX	The speed gain - as far as I can tell - comes from avoiding megafunctions	18:11
awygle	whitequark: "but [FIRRTL]'s just not there yet" can you elaborate on what you feel is missing?	18:46
FL4SHK	awygle: wait, you're on IRC now?	18:52
awygle	FL4SHK: i've been on IRC longer than discord :p	18:52
FL4SHK	same	18:53
FL4SHK	big same	18:53
whitequark	awygle: tooling support	18:53
whitequark	yosys doesn't have a firrtl frontend.	18:53
FL4SHK	so, not a problem with FIRRTL itself	18:53
FL4SHK	frontend? why not a backend?	18:53
FL4SHK	oh wait	18:53
FL4SHK	derp, derp	18:53
whitequark	both frontend and backend	18:53
whitequark	the backend exists	18:53
whitequark	the frontend does not	18:53
FL4SHK	I see.	18:53
FL4SHK	I'll probably jump straight into FIRRTL, then, when I decide to output not-Verilog	18:54
FL4SHK	...though perhaps I'll switch to outputing a non-optimized netlist	18:54
FL4SHK	netlist Verilog is hopefully well-supported, eh?	18:55
FL4SHK	Oh well	18:55
whitequark	structural Verilog is what i think i'm calling what you call netlist Verilog	18:56
FL4SHK	I see.	18:56
awygle	anything besides the missing yosys frontend? (i am sad that "yosys frontend missing" == "bad tooling support" but i can't argue with its accuracy)	18:56
whitequark	awygle: sure	18:56
whitequark	nextpnr doesn't take LoFIRRTL either, though it morally ought to	18:56
whitequark	can I simulate FIRRTL?	18:56
whitequark	can I feed it to basically any extant tool that takes structural Verilog currently?	18:57
whitequark	Verilator?	18:57
whitequark	(Verilator equivalent, anything)	18:57
whitequark	analyzers? generators? anything?	18:57
whitequark	my impression of FIRRTL is that at the moment it's a (good!) spec that exists in a near vacuum	18:57
awygle	all fair points. all of this besides the nextpnr bit applies just as well to RTLIL, which is what i was implicitly contrasting it with	18:58
awygle	should have been more explicit	18:58
whitequark	right, so the main difference with RTLIL is that RTLIL isn't really trying to be an interchange format	18:58
awygle	RTLIL can be converted to inputs for all of those tools of course but if you assume a yosys frontend then so can firrtl	18:58
awygle	mhm	18:58
awygle	i getcha	18:58
whitequark	hm, ok, so there's an interpreter for FIRRTL, in Scala	18:59
awygle	i think we agree on our assessments of FIRRTL which is all i really wanted to confirm. you have a lot more experience wrt language stuff than me, so i wanted to see if there were deficiencies i was missing.	18:59
whitequark	nope, actually FIRRTL has a few things that gave me inspiration for improvements in nMigen	19:00
FL4SHK	Is there anything really wrong with me using an existing HDL in place of my own until my own is done?	19:01
FL4SHK	For some reason it makes me uncomfortable to just start using another HDL, like it's morally wrong or something	19:01
whitequark	absolutely nothing wrong	19:01
FL4SHK	I honestly really want to start doing some HDL work	19:01
FL4SHK	I've got my job, sure	19:02
FL4SHK	but I don't really get to pick what I work on there	19:02
whitequark	in fact, using other languages daily makes you better suited to work on your own	19:02
whitequark	as you get to see more perspective	19:02
awygle	FL4SHK: my opinion is that if you haven't done a fair amount of work in one of the existing HDLs you will probably not succeed in solving their problems, at least not immediately	19:02
awygle	although we have a counterexample right above that message so :shrug:	19:02
FL4SHK	awygle: most of my HDL stuff has been CPUs	19:03
FL4SHK	at work we don't just write HDL code	19:03
FL4SHK	though I guess how much HDL code we write depends on if you count UVM stuff as HDL code or not, haha	19:03
whitequark	awygle: i did some verilog work, really just enough to see where the pain points are	19:03
FL4SHK	lack of custom types	19:03
FL4SHK	SystemVerilog pain point: lack of parameterizable custom types	19:04
awygle	personally, my experiences with the OSS HDL community have lead me to near-total indifference to languages as such	19:04
whitequark	awygle: probably less than someone else would need because i tend to go straight for the pain points	19:04
awygle	i am much, _much_ more interested in the surrounding ecosystems	19:04
whitequark	nevertheless, if i worked more with VHDL, i would have solved some problems in nMigen earlier	19:04
FL4SHK	Maybe I'll give VHDL work more of a try	19:04
whitequark	VHDL's simulator is nothing short of brilliant	19:05
FL4SHK	which simulator?	19:05
whitequark	https://insights.sigasi.com/opinion/jan/vhdls-crown-jewel/	19:05
tpb	Title: VHDL's crown jewel - Sigasi (at insights.sigasi.com)	19:05
whitequark	VHDL's simulation semantics	19:05
FL4SHK	oh, yes.	19:05
whitequark	the main problem with VHDL's semantics is that you still have to balance clock trees	19:05
FL4SHK	Those seem to be very well defined.	19:06
whitequark	which is something I hope to improve on	19:06
whitequark	but the basic mechanism is used in nMigen nearly intact and it works extremely well	19:06
FL4SHK	What do you mean by clock trees?	19:06
FL4SHK	And what is balancing them?	19:07
whitequark	imagine a behavioral clock gating primitive in VHDL	19:07
FL4SHK	an if statement?	19:07
whitequark	it'll have a combinatorial path from input clock to output clock, right?	19:07
whitequark	anything. an if statement works, i think	19:07
FL4SHK	clock gating... is that the same thing as a clock enable?	19:07
whitequark	no	19:07
FL4SHK	Hm, I see	19:08
FL4SHK	I don't think I've done anything other than clock enables.	19:08
FL4SHK	What is clock gating?	19:08
whitequark	a clock enable is a way to enable or disable some logic driven by the same clock signal as other logic. in other words, a clock enable is just a normal combinatorial input to your synchronous logic	19:09
FL4SHK	Right.	19:09
whitequark	you can represent it by wrapping every dff with a muxed path	19:09
whitequark	that works just fine	19:09
whitequark	in comparison, clock gating produces another clock, so your logic is now driven by two clock signals. however, when the gate is enabled, these two clocks are completely in-phase, at least in hardware	19:10
whitequark	unfortunately, if you implement it naively in VHDL, the output clock will lag one delta cycle behind the input clock	19:10
whitequark	so if you have a DFF driven by the gated clock capturing the output of a DFF driven by the ungated clock, you'll capture the wrong value	19:11
FL4SHK	It sounds to me like clock gating is something you don't want to do in an FPGA	19:11
whitequark	it'll be as if there is an infinitesimal but nonzero phase difference between the input (ungated) and output (gated) clock	19:11
FL4SHK	given that you're not supposed to clock logic using other logic	19:11
whitequark	well, FPGAs have clock gating primitives.	19:11
whitequark	some FPGAs.	19:11
FL4SHK	I see	19:11
whitequark	Xilinx has BUFGCE	19:11
whitequark	so you might want to simulate them	19:11
FL4SHK	Some FPGAs have internal tri-state stuff, too :P	19:11
whitequark	I mean modern widely used FPGAs	19:12
FL4SHK	old ones, anyway	19:12
FL4SHK	I see, interesting	19:12
FL4SHK	so is that what you'd use to make a PLL in an FPGA's logic?	19:12
whitequark	I don't think you can do that to make a PLL, but a simulated PLL would have the same problem	19:12
whitequark	if e.g. the output of a PLL regenerates the input clock	19:12
whitequark	or perhaps an integer ratio	19:12
whitequark	what you really want is some way to tell the simulator "this comb input and this comb output are in-phase. the transitions should either propagate within one delta cycle, or within nonzero time, but not in different delta cycles but same instant"	19:13
whitequark	VHDL doesn't have that	19:14
FL4SHK	This is something I've never run into, myself	19:14
FL4SHK	But I've never tried to create another clock outside of using a PLL	19:14
whitequark	instead what you do is to take your input clock, make a gated output clock (with one delta cycle delay), then make an ungated output clock (with one delta cycle dummy delay), then use just the last two	19:14
whitequark	so, this problem is something you encounter in ASIC development, mostly, I think	19:15
FL4SHK	I definitely want to get into ASIC development at some point	19:15
whitequark	I discussed it with some good VHDL and Verilog developers who did happen to hit it	19:15
FL4SHK	MOSIS is apparently as cheap as maybe $800 for 1 mm^2	19:15
whitequark	Verilog has blocking assignments, which allow you to express clock gating cleanly, but at the cost of determinism	19:15
FL4SHK	which is within my price range	19:15
whitequark	CMP is even cheaper	19:15
FL4SHK	CMP?	19:15
FL4SHK	What's that?	19:15
whitequark	https://mycmp.fr/	19:16
tpb	Title: CMP: Circuits Multi-Projets (at mycmp.fr)	19:16
FL4SHK	I'll need to keep this in mind	19:17
FL4SHK	I've wanted to do ASIC development for a long time now.	19:17
whitequark	anyway, the simulation issue I mentioned before primarily interests me from the perspective of bottom-up language correctness	19:17
whitequark	it's not something that is insurmountable in practice	19:18
whitequark	it's annoying and it does cause bugs, that's for sure	19:20
whitequark	but it's one of the lesser HDL footguns	19:20
FL4SHK	I've decided to do some HDL development in SystemVerilog, using sv2v so I can use yosys's formal verification.	19:24
FL4SHK	GHDL synthesis looks nice, too	19:24
FL4SHK	I like 'attr stuff in VHDL	19:24
FL4SHK	so I brought it into my HDL.	19:25
*** oldtopman has quit IRC		20:32
*** Cerpin has quit IRC		20:35
*** Cerpin has joined #yosys		20:36
*** Cerpin has quit IRC		20:40
*** Cerpin has joined #yosys		20:41
*** emeb_mac has joined #yosys		20:45
*** adjtm has quit IRC		20:56
*** adjtm has joined #yosys		20:57
*** kraiskil has joined #yosys		21:25
*** Asu has quit IRC		22:10
*** az0re has quit IRC		22:55
*** craigo_ has joined #yosys		23:23
*** emeb has quit IRC		23:38
*** az0re has joined #yosys		23:51

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!