<tpb>
Title: GitHub - fl4shk/fling_hdl: A Hardware Description Language with features similar to my custom programming language, Fling (at github.com)
<FL4SHK>
Fling the programming language is on hold, haha
<whitequark>
yeah, RTLIL
<whitequark>
RTLIL is a lot easier to emit correctly than Verilog
<whitequark>
so much so that nMigen doesn't bother with the latter
<FL4SHK>
There are certain advantages to spitting out behavioral Verilog
<whitequark>
yeah?
<FL4SHK>
One of them is that it's perhaps easier to debug the compiler :P
<FL4SHK>
I plan on using the \identifier feature of Verilog
<whitequark>
oh, nMigen does output a .debug.v file next to every .il file
<whitequark>
since in most cases the converted Verilog is enough
<whitequark>
it's just that it "outsources" the complexity of writing correct Verilog to Yosys
<FL4SHK>
My language is actually defined in terms of Verilog
<FL4SHK>
i.e. simulation, for example, uses Verilog semantics
<FL4SHK>
the `module` keyword, in my language, is equivalent to a single `module` in Verilog
<whitequark>
full disclosure: I think just about everything about Verilog is awfully designed
<FL4SHK>
I think it's fine as a compilation target.
<whitequark>
so in my eyes, that's a strict downside of your language, though there could be reasons why it's necessary
<FL4SHK>
It's pretty terrible for actually developing stuff in
<whitequark>
I think it's even worse as a compilation target than for developing things in
<FL4SHK>
Maybe our viewpoints are different
<whitequark>
it is unable to represent most of the interesting semantics while having so much nonessential complexity that tooling is nearly always incorrect
<FL4SHK>
It's pretty terrible
<FL4SHK>
I see
<whitequark>
I think the way 1364.1 defines a DFF with async set and reset is very enlightening
<whitequark>
it *requires* you to write a code with sim/synth mismatch
<whitequark>
*write a code pattern
<FL4SHK>
That's uh
<FL4SHK>
That's unfortunate
<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
<FL4SHK>
I've never really run into simulation/synthesis mismatches
<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
<whitequark>
multiply by the number of tools.
<whitequark>
there are tools that supposedly ingest Verilog that can't cope with concatenations on assign LHS
<whitequark>
RTLIL is *much* better than Verilog as a compilation target, though still imperfect because its semantics are pretty much just "what Yosys does"
<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
<FL4SHK>
I didn't know that concatenations being assigned to was so poorly supported.
<FL4SHK>
That strikes me as very unfortunate because it's such a nice thing
<whitequark>
I think it's supported in most tools you might encounter
<daveshah>
This isn't a problem with synrhesis tools
<whitequark>
that's not the problem I'm talking about
<daveshah>
It's a problem with the undefined nature of "structural Verilog"
<whitequark>
^
<FL4SHK>
Maybe I'll add in support for spitting out VHDL
<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
<whitequark>
but... it's just not there yet
<FL4SHK>
I'll have to give that a try, too.
vidbina has quit [Ping timeout: 272 seconds]
Cerpin has quit [Quit: leaving]
emeb_mac has joined #yosys
dys has joined #yosys
emeb_mac has quit [Quit: Leaving.]
<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
<whitequark>
I assumed this all is well-known among tooling developers, I think, but you have my permission to paste as you see fit
Cerpin has joined #yosys
<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
<ZirconiumX>
VQM looks a lot like Verilog '95 except incredibly sucky.
<ZirconiumX>
Or maybe that's just an inherited property of Verilog '95
<whitequark>
FL4SHK: ^
<ZirconiumX>
It's not even much faster to parse than using the full SV parser that Quartus has.
<ZirconiumX>
The speed gain - as far as I can tell - comes from avoiding megafunctions
<awygle>
whitequark: "but [FIRRTL]'s just not there yet" can you elaborate on what you feel is missing?
<FL4SHK>
awygle: wait, you're on IRC now?
<awygle>
FL4SHK: i've been on IRC longer than discord :p
<FL4SHK>
same
<FL4SHK>
big same
<whitequark>
awygle: tooling support
<whitequark>
yosys doesn't have a firrtl frontend.
<FL4SHK>
so, not a problem with FIRRTL itself
<FL4SHK>
frontend? why not a backend?
<FL4SHK>
oh wait
<FL4SHK>
derp, derp
<whitequark>
both frontend and backend
<whitequark>
the backend exists
<whitequark>
the frontend does not
<FL4SHK>
I see.
<FL4SHK>
I'll probably jump straight into FIRRTL, then, when I decide to output not-Verilog
<FL4SHK>
...though perhaps I'll switch to outputing a non-optimized netlist
<FL4SHK>
netlist Verilog is hopefully well-supported, eh?
<FL4SHK>
Oh well
<whitequark>
structural Verilog is what i think i'm calling what you call netlist Verilog
<FL4SHK>
I see.
<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)
<whitequark>
awygle: sure
<whitequark>
nextpnr doesn't take LoFIRRTL either, though it morally ought to
<whitequark>
can I simulate FIRRTL?
<whitequark>
can I feed it to basically any extant tool that takes structural Verilog currently?
<whitequark>
Verilator?
<whitequark>
(Verilator equivalent, anything)
<whitequark>
analyzers? generators? anything?
<whitequark>
my impression of FIRRTL is that at the moment it's a (good!) spec that exists in a near vacuum
<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
<awygle>
should have been more explicit
<whitequark>
right, so the main difference with RTLIL is that RTLIL isn't really trying to be an interchange format
<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
<awygle>
mhm
<awygle>
i getcha
<whitequark>
hm, ok, so there's an interpreter for FIRRTL, in Scala
<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.
<whitequark>
nope, actually FIRRTL has a few things that gave me inspiration for improvements in nMigen
<FL4SHK>
Is there anything really wrong with me using an existing HDL in place of my own until my own is done?
<FL4SHK>
For some reason it makes me uncomfortable to just start using another HDL, like it's morally wrong or something
<whitequark>
absolutely nothing wrong
<FL4SHK>
I honestly really want to start doing some HDL work
<FL4SHK>
I've got my job, sure
<FL4SHK>
but I don't really get to pick what I work on there
<whitequark>
in fact, using other languages daily makes you better suited to work on your own
<whitequark>
as you get to see more perspective
<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
<awygle>
although we have a counterexample right above that message so :shrug:
<FL4SHK>
awygle: most of my HDL stuff has been CPUs
<FL4SHK>
at work we don't just write HDL code
<FL4SHK>
though I guess how much HDL code we write depends on if you count UVM stuff as HDL code or not, haha
<whitequark>
awygle: i did *some* verilog work, really just enough to see where the pain points are
<FL4SHK>
lack of custom types
<FL4SHK>
SystemVerilog pain point: lack of parameterizable custom types
<awygle>
personally, my experiences with the OSS HDL community have lead me to near-total indifference to languages as such
<whitequark>
awygle: probably less than someone else would need because i tend to go straight for the pain points
<awygle>
i am much, _much_ more interested in the surrounding ecosystems
<whitequark>
nevertheless, if i worked more with VHDL, i would have solved some problems in nMigen earlier
<FL4SHK>
Maybe I'll give VHDL work more of a try
<whitequark>
VHDL's simulator is nothing short of brilliant
<whitequark>
the main problem with VHDL's semantics is that you still have to balance clock trees
<FL4SHK>
Those seem to be very well defined.
<whitequark>
which is something I hope to improve on
<whitequark>
but the basic mechanism is used in nMigen nearly intact and it works extremely well
<FL4SHK>
What do you mean by clock trees?
<FL4SHK>
And what is balancing them?
<whitequark>
imagine a behavioral clock gating primitive in VHDL
<FL4SHK>
an if statement?
<whitequark>
it'll have a combinatorial path from input clock to output clock, right?
<whitequark>
anything. an if statement works, i think
<FL4SHK>
clock gating... is that the same thing as a clock enable?
<whitequark>
no
<FL4SHK>
Hm, I see
<FL4SHK>
I don't think I've done anything other than clock enables.
<FL4SHK>
What is clock gating?
<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
<FL4SHK>
Right.
<whitequark>
you can represent it by wrapping every dff with a muxed path
<whitequark>
that works just fine
<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
<whitequark>
unfortunately, if you implement it naively in VHDL, the output clock will lag one delta cycle behind the input clock
<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
<FL4SHK>
It sounds to me like clock gating is something you don't want to do in an FPGA
<whitequark>
it'll be as if there is an infinitesimal but nonzero phase difference between the input (ungated) and output (gated) clock
<FL4SHK>
given that you're not supposed to clock logic using other logic
<whitequark>
well, FPGAs have clock gating primitives.
<whitequark>
some FPGAs.
<FL4SHK>
I see
<whitequark>
Xilinx has BUFGCE
<whitequark>
so you might want to simulate them
<FL4SHK>
Some FPGAs have internal tri-state stuff, too :P
<FL4SHK>
old ones, anyway
<whitequark>
I mean modern widely used FPGAs
<FL4SHK>
I see, interesting
<FL4SHK>
so is that what you'd use to make a PLL in an FPGA's logic?
<whitequark>
I don't think you can do that to make a PLL, *but* a simulated PLL would have the same problem
<whitequark>
if e.g. the output of a PLL regenerates the input clock
<whitequark>
or perhaps an integer ratio
<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"
<whitequark>
VHDL doesn't have that
<FL4SHK>
This is something I've never run into, myself
<FL4SHK>
But I've never tried to create another clock outside of using a PLL
<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
<whitequark>
so, this problem is something you encounter in ASIC development, mostly, I think
<FL4SHK>
I definitely want to get into ASIC development at some point
<whitequark>
I discussed it with some good VHDL and Verilog developers who did happen to hit it
<FL4SHK>
MOSIS is apparently as cheap as maybe $800 for 1 mm^2
<whitequark>
Verilog has blocking assignments, which allow you to express clock gating cleanly, but at the cost of determinism