bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #yosys
bjorkintosh has joined #yosys
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #yosys
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #yosys
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #yosys
bjorkintosh has quit [Changing host]
bjorkintosh has joined #yosys
_whitelogger has quit [Server closed connection]
_whitelogger has joined #yosys
bjorkintosh has quit [Ping timeout: 272 seconds]
bjorkintosh has joined #yosys
bjorkintosh has quit [Ping timeout: 258 seconds]
bjorkintosh has joined #yosys
bjorkintosh has quit [Client Quit]
schaeg has joined #yosys
schaeg_ has quit [Ping timeout: 252 seconds]
freshmaker666 is now known as greeb
aosync has left #yosys [WeeChat 3.2.1]
FabM has joined #yosys
FabM has joined #yosys
svenn has quit [Server closed connection]
svenn has joined #yosys
cr1901 has joined #yosys
cr1901_ has quit [Ping timeout: 258 seconds]
sugarbeet has quit [Server closed connection]
sugarbeet has joined #yosys
<schaeg>
Question: Does someone have a good reason to disagree with the assertion: "A hardware description language describes the wanted behaviour using the description of an simplified, abstract and ideal hardware. This does also applies to the RTL or the netlist which also describe abstract and idealized hardware. A hardware description language maybe used to develop hardware and that creates some confusion by suggesting HDLs are used to
<schaeg>
develop hardware. However one should think of Hardware description languages as a 'description through hardware', not 'description for hardware' and also not 'description of hardware'. "
<schaeg>
(agreement or sources which have a similar definition are welcome too)
<lofty>
schaeg: that last sentence makes no sense.
<lofty>
And really, the first sentence seems a little incorrect to me because in practice HDLs - especially newer ones - can have very different models of computing as a basis.
<lofty>
Verilog and VHDL are event machines; BlueSpec Haskell is a term rewriting system; and HLS starts with a serial model of computing.
<schaeg>
Mhh , i wouldn't call C++ a HDL, even though FPGAs can be configured through it via an HLS compiler.
whitequark[cis] has joined #yosys
<whitequark[cis]>
anything is a HDL if you're brave enough :3
<schaeg>
well that doesn't help me argue my case.
anticw has quit [Server closed connection]
anticw has joined #yosys
<schaeg>
So ... i am in the cursed situation of having to define a HDL for a task-graph like computation framework where invidual tasks can be analog computations, optimisation problems or general purpose computations and yeah the analog computations will be run on a analog computer.
<schaeg>
So i hoped i could make the arguement: Well an abstract hybrid computer actually just has $list_of_components_which_map_to_things_we_could_do as abstract hardware components and our HDL is program that.
* schaeg
stops from musing publicly, hoping people comment.
<schaeg>
Is there some HDL, where i can encode invariants? like f(g(h(x1,x2),x2)) = f(h(g(j(x1), x2), x2)) and the synthesizer is expected to pick the variant under those rules which best matches the harware available?
<lofty>
Unfortunately not, because the lowest common denominator is Verilog/VHDL, and that's not really expressible in those languages
xiretza[cis] has joined #yosys
<xiretza[cis]>
that sounds like techmapping
<schaeg>
and like f,g,h,j are so complicated things that no compiler could be expected to discover that invariance/ computation graph rewrite-rule
<lofty>
Sure, there's stuff like $assert/$assume, but synthesis tools tend to ignore them
<schaeg>
xiretza[cis] what's techmapping?
<lofty>
at best you can say something like `if (cond) output = 'x;`, but tooling doesn't always use that either
<lofty>
schaeg: technology mapping
<lofty>
AKA "turning logic into something implementable in hardware"
<schaeg>
If i was just working in the logic world all would be nice. ...
bjorkintosh has joined #yosys
bjorkintosh has joined #yosys
bjorkintosh has quit [Changing host]
<lofty>
schaeg: in theory, theory and practice are the same; in practice, they are not.
<schaeg>
I guess i wanna jointly transform and rewrite nummeric and analog computations. I don't wanna have to proof that i can do those transformation safely, i just wanna allow a language where i can do those transformations. I also want to reason about the length in wall clock time of different elements. I don't wanna have to support a different interface where i can't do those. So i am trying to make up something i can call an HDL which
<schaeg>
would allow for that and all stuff would have to be implemented on top of that so we can do dirty, dirty tricks easily to get the most out of our multi-tenant time hardware.
<schaeg>
Calling that interface an HDL is important because people negotiated that we expose an HDL.
schaeg_ has joined #yosys
schaeg has quit [Ping timeout: 255 seconds]
schaeg_ is now known as schaeg
ecs has quit [Server closed connection]
ecs has joined #yosys
tlwoerner has quit [Server closed connection]
tlwoerner has joined #yosys
<schaeg>
Actual yosys question this time: How heavily are netlists specific to the FPGA targeted? Are the synth.edif generally portable between vendors? If so how big is the performance difference if you use one optimised for a different chip?
<lofty>
schaeg: *highly* specific to the targeted chip
<lofty>
Like, we turn the netlists into vendor-specific cells, like LUTs, flops, memory blocks, DSPs, etc
<schaeg>
I think there are multiple netlists in a normal synthesis workflow. Does that also hold for the highest level artefact of netlist you produce?
<lofty>
we don't produce artifacts for anything but the lowest level netlist
* schaeg
nods.
<lofty>
There's no use for anything other than the low-level architecture-specific netlist
<lofty>
It says that these are levels of abstraction for digital circuits
<schaeg>
which all have netlists associated with them?
<lofty>
slide 7 shows that Yosys only goes as low as physical gate level
<schaeg>
Sorry i missphrased.
<lofty>
Yosys works by running a series of passes which gradually lower the netlist representation from behavioural level down to physical gate level
<lofty>
and while you can draw points in a flow and say this is more-or-less one of the levels
<lofty>
most flows are a bit blurrier than that
<lofty>
a good example would be carry-chain inference in FPGAs
<lofty>
given an input behavioural netlist, you will have things like $add, $sub, $lt, and so on
<lofty>
`alumacc` unifies these different cells into `$alu` (as well as $macc, but I'm ignoring that)
<schaeg>
If one were extract something equivalent to a RTL netlist from a yosys synthesis run would that "highest level" netlist already be platform specific?
<lofty>
then on pretty much all FPGA synthesis scripts, a `techmap` call will turn that directly into a target cell for the FPGA
<lofty>
which means that adders go from behavioural level immediately into physical gate level
<lofty>
You can extract a non-specific RTL netlist from Yosys, yes
<lofty>
When you load a Verilog file in Yosys, the first possible time you can access it is at an almost-RTL level
<schaeg>
Is the RTLIL the front end produces after reading a non vendor specific source code already vendor specific?
<lofty>
no, that RTLIL is non-vendor specific
<schaeg>
Thank you for helping me refine the question.
<schaeg>
Is it generally safe to assume that netlist files are vendor specific and non-vendor specific netlists are some "pathological" case i just constructed because i have to little idea about FPGA work flows
<lofty>
That's a difficult question to answer
<lofty>
You can produce an entirely generic netlist in Yosys
<lofty>
but this entirely-generic netlist is not very useful, because to use it in actual hardware you will need to make it vendor-specific
<lofty>
(modern) FPGAs do not have the concept of an AND gate or a NOT gate
<lofty>
even though these are generic concepts
<lofty>
you will need to turn those into LUTs, and the moment you do so you begin to make the netlist more specialised
<lofty>
If you choose to target, say, an Intel Cyclone V, the design physically won't fit on a Lattice iCE40
<lofty>
If you target a Xilinx 7 Series, it won't fit in either the Cyclone V or iCE40
<schaeg>
okay ... well would i be an asshole if for the FPAAs my company produces all the netlists my tools return are vendor specific?
<schaeg>
*returns
<lofty>
you would be entirely normal :p
<schaeg>
That helps me a lot.
<lofty>
But unfortunately, Yosys has...basically no support for FPAAs
<lofty>
So we can offer advice and opinions
<lofty>
but if your idea is "why don't I implement tooling for my FPAA with Yosys", you should be aware that it wouldn't be that much less effort than writing an entirely new tool
<schaeg>
Oh it's not.
<schaeg>
Let me tell you the biggest problem i see, a good enough netlist depends continous parameters which are unknown until the data is available, the number of elements can both increase and decrease as you change those problem parameters in one direction.
<lofty>
see, FPGAs are pretty similar in that respect
<lofty>
so...we just don't bother about it
<lofty>
run synthesis, and then in place-and-route do we figure out if the resulting netlist can be fit in the final chip
<schaeg>
Like, wanna solve the problem with alpha=0.2, gamma=0.4, delta=0.7, omega=0.8 cool here is your netlist. What? You used alpha=0.24 ? Well the netlist is invalid as executing it runs into the working limits of some calculation component.
<schaeg>
so ... fpga netlists are atleast valid for all data you ask them to be valid for. Here you need many netlists to cover a parameter range.
* schaeg
shudders.
<mewt>
I guess I'll just go ahead and open an issue for the param thing
<schaeg>
Nahh please don't ...
* schaeg
thinks
<schaeg>
Actually i don't care but I don't see much potential using Yosys for the fpaas i work on. If you wanna do the parameter thing for FPGAs *shrugg* none of my buisness
<mewt>
My issue above, sorry
<mewt>
I am committed to using Yosys even if I have to eventually figure this out myself
<schaeg>
There seem to be multiple version of the EDIF file format. Did you consult any standard documents when implementing EDIF? If so do you still have those flying around and can look up whether the term "netlist" is defined in there?
notgull has quit [Ping timeout: 252 seconds]
notgull has joined #yosys
<lofty>
schaeg: make no mistake: EDIF is not a portable standard. Every tool interprets it differently and in highly contradictory ways
* schaeg
wimpers.
<lofty>
schaeg: what Yosys outputs is probably best described as Xilinx-flavoured EDIF; something ISE and Vivado will accept
<lofty>
I have managed to get one other tool to mostly accept it, aside from triggering a buffer overflow inside the EDIF parser if a netlist is big enough
<lofty>
Quartus, for example, pretty much directly rejects the output of Yosys as invalid