| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has quit IRC (Remote host closed the connection) | 00:27 | |
| *** bjorkintosh <bjorkintosh!~bjork@2600:1700:5400:c80:a11e:c4e2:84b4:adb> has joined #yosys | 00:27 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has quit IRC (Remote host closed the connection) | 00:36 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has joined #yosys | 00:37 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has quit IRC (Remote host closed the connection) | 00:40 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has joined #yosys | 00:41 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has quit IRC (Remote host closed the connection) | 00:48 | |
| *** bjorkintosh <bjorkintosh!~bjork@2600:1700:5400:c80:a11e:c4e2:84b4:adb> has joined #yosys | 00:48 | |
| *** _whitelogger <[email protected]> has quit IRC (Server closed connection) | 01:00 | |
| *** _whitelogger <[email protected]> has joined #yosys | 01:01 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has quit IRC (Ping timeout: 272 seconds) | 01:11 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has joined #yosys | 01:12 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has quit IRC (Ping timeout: 258 seconds) | 01:20 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has joined #yosys | 01:29 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has quit IRC (Client Quit) | 01:33 | |
| *** schaeg <schaeg!~anabrid@2a02:3036:268:d670:68ac:760d:58ed:d419> has joined #yosys | 02:02 | |
| *** schaeg_ <schaeg_!~anabrid@2a02:3036:26a:8b0c:7c60:4034:1653:4150> has quit IRC (Ping timeout: 252 seconds) | 02:03 | |
| *** freshmaker666 is now known as greeb | 05:13 | |
| *** aosync <aosync!~alews@user/aws> has left #yosys (WeeChat 3.2.1) | 07:17 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:2e60:8c7c:e8fb:7990> has joined #yosys | 07:18 | |
| *** svenn <[email protected]> has quit IRC (Server closed connection) | 07:47 | |
| *** svenn <[email protected]> has joined #yosys | 07:47 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:226:edb4:c334:3b9c:abc4> has joined #yosys | 09:00 | |
| *** cr1901_ <cr1901_!~cr1901@2601:8d:8600:226:828:2469:efd7:4ee6> has quit IRC (Ping timeout: 258 seconds) | 09:00 | |
| *** sugarbeet <[email protected]> has quit IRC (Server closed connection) | 10:36 | |
| *** sugarbeet <[email protected]> has joined #yosys | 10:36 | |
| 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 | 11:12 |
|---|---|---|
| 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'. " | 11:12 |
| schaeg | (agreement or sources which have a similar definition are welcome too) | 11:20 |
| lofty | schaeg: that last sentence makes no sense. | 11:54 |
| 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. | 11:57 |
| lofty | Verilog and VHDL are event machines; BlueSpec Haskell is a term rewriting system; and HLS starts with a serial model of computing. | 12:01 |
| schaeg | Mhh , i wouldn't call C++ a HDL, even though FPGAs can be configured through it via an HLS compiler. | 12:46 |
| *** whitequark[cis] <whitequark[cis]!whitequark@2a01:4f8:c012:5b7:0:1:0:4> has joined #yosys | 12:46 | |
| whitequark[cis] | anything is a HDL if you're brave enough :3 | 12:46 |
| schaeg | well that doesn't help me argue my case. | 12:51 |
| *** anticw <[email protected]> has quit IRC (Server closed connection) | 12:56 | |
| *** anticw <[email protected]> has joined #yosys | 12:57 | |
| 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. | 13:01 |
| 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. | 13:05 |
| * schaeg stops from musing publicly, hoping people comment. | 13:10 | |
| 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? | 13:33 |
| lofty | Unfortunately not, because the lowest common denominator is Verilog/VHDL, and that's not really expressible in those languages | 13:34 |
| *** xiretza[cis] <xiretza[cis]!xiretzaxir@2a01:4f8:c012:5b7:0:1:0:88> has joined #yosys | 13:34 | |
| xiretza[cis] | that sounds like techmapping | 13:34 |
| 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 | 13:35 |
| lofty | Sure, there's stuff like $assert/$assume, but synthesis tools tend to ignore them | 13:35 |
| schaeg | xiretza[cis] what's techmapping? | 13:36 |
| lofty | at best you can say something like `if (cond) output = 'x;`, but tooling doesn't always use that either | 13:36 |
| lofty | schaeg: technology mapping | 13:36 |
| lofty | AKA "turning logic into something implementable in hardware" | 13:36 |
| schaeg | If i was just working in the logic world all would be nice. ... | 13:39 |
| *** bjorkintosh <bjorkintosh!~bjork@2600:1700:5400:c80:d45d:36a0:e613:b333> has joined #yosys | 13:40 | |
| lofty | schaeg: in theory, theory and practice are the same; in practice, they are not. | 13:49 |
| 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 | 13:50 |
| 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. | 13:50 |
| schaeg | Calling that interface an HDL is important because people negotiated that we expose an HDL. | 13:51 |
| *** schaeg_ <schaeg_!~anabrid@2a02:3036:268:d670:68ac:760d:58ed:d419> has joined #yosys | 14:43 | |
| *** schaeg <schaeg!~anabrid@2a02:3036:268:d670:68ac:760d:58ed:d419> has quit IRC (Ping timeout: 255 seconds) | 14:43 | |
| *** schaeg_ is now known as schaeg | 14:53 | |
| *** ecs <ecs!ecs@hare/maintainer/ecs> has quit IRC (Server closed connection) | 14:53 | |
| *** ecs <ecs!ecs@hare/maintainer/ecs> has joined #yosys | 14:53 | |
| *** tlwoerner <[email protected]> has quit IRC (Server closed connection) | 15:00 | |
| *** tlwoerner <[email protected]> has joined #yosys | 15:00 | |
| 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? | 16:04 |
| lofty | schaeg: *highly* specific to the targeted chip | 16:07 |
| lofty | Like, we turn the netlists into vendor-specific cells, like LUTs, flops, memory blocks, DSPs, etc | 16:08 |
| 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? | 16:09 |
| lofty | we don't produce artifacts for anything but the lowest level netlist | 16:10 |
| * schaeg nods. | 16:10 | |
| lofty | There's no use for anything other than the low-level architecture-specific netlist | 16:11 |
| schaeg | I am following https://github.com/YosysHQ/yosys-manual-build/releases/download/manual/presentation.pdf where the Register-Transfer Level (RTL), the Logical Gate Level, the Physical Gate Level and the Switch Level are said to be netlists in yosys. | 16:13 |
| lofty | No it doesn't | 16:14 |
| lofty | It says that these are levels of abstraction for digital circuits | 16:14 |
| schaeg | which all have netlists associated with them? | 16:14 |
| lofty | slide 7 shows that Yosys only goes as low as physical gate level | 16:14 |
| schaeg | Sorry i missphrased. | 16:16 |
| lofty | Yosys works by running a series of passes which gradually lower the netlist representation from behavioural level down to physical gate level | 16:17 |
| lofty | and while you can draw points in a flow and say this is more-or-less one of the levels | 16:17 |
| lofty | most flows are a bit blurrier than that | 16:18 |
| lofty | a good example would be carry-chain inference in FPGAs | 16:18 |
| lofty | given an input behavioural netlist, you will have things like $add, $sub, $lt, and so on | 16:19 |
| lofty | `alumacc` unifies these different cells into `$alu` (as well as $macc, but I'm ignoring that) | 16:19 |
| 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? | 16:19 |
| lofty | then on pretty much all FPGA synthesis scripts, a `techmap` call will turn that directly into a target cell for the FPGA | 16:20 |
| lofty | which means that adders go from behavioural level immediately into physical gate level | 16:20 |
| lofty | You can extract a non-specific RTL netlist from Yosys, yes | 16:21 |
| lofty | When you load a Verilog file in Yosys, the first possible time you can access it is at an almost-RTL level | 16:24 |
| schaeg | Is the RTLIL the front end produces after reading a non vendor specific source code already vendor specific? | 16:25 |
| lofty | no, that RTLIL is non-vendor specific | 16:25 |
| schaeg | Thank you for helping me refine the question. | 16:26 |
| 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 | 16:28 |
| lofty | That's a difficult question to answer | 16:29 |
| lofty | You can produce an entirely generic netlist in Yosys | 16:30 |
| 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 | 16:30 |
| lofty | (modern) FPGAs do not have the concept of an AND gate or a NOT gate | 16:31 |
| lofty | even though these are generic concepts | 16:31 |
| lofty | you will need to turn those into LUTs, and the moment you do so you begin to make the netlist more specialised | 16:32 |
| lofty | If you choose to target, say, an Intel Cyclone V, the design physically won't fit on a Lattice iCE40 | 16:33 |
| lofty | If you target a Xilinx 7 Series, it won't fit in either the Cyclone V or iCE40 | 16:33 |
| schaeg | okay ... well would i be an asshole if for the FPAAs my company produces all the netlists my tools return are vendor specific? | 16:34 |
| schaeg | *returns | 16:34 |
| lofty | you would be entirely normal :p | 16:34 |
| schaeg | That helps me a lot. | 16:35 |
| lofty | But unfortunately, Yosys has...basically no support for FPAAs | 16:35 |
| lofty | So we can offer advice and opinions | 16:35 |
| 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 | 16:36 |
| schaeg | Oh it's not. | 16:37 |
| 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. | 16:39 |
| lofty | see, FPGAs are pretty similar in that respect | 16:40 |
| lofty | so...we just don't bother about it | 16:40 |
| lofty | run synthesis, and then in place-and-route do we figure out if the resulting netlist can be fit in the final chip | 16:41 |
| 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. | 16:43 |
| 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. | 16:45 |
| * schaeg shudders. | 16:46 | |
| mewt | I guess I'll just go ahead and open an issue for the param thing | 16:55 |
| schaeg | Nahh please don't ... | 16:57 |
| * schaeg thinks | 16:58 | |
| 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 | 16:59 |
| mewt | My issue above, sorry | 17:00 |
| mewt | I am committed to using Yosys even if I have to eventually figure this out myself | 17:00 |
| 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? | 17:05 |
| *** notgull <notgull!~notgull@ec2-50-112-148-23.us-west-2.compute.amazonaws.com> has quit IRC (Ping timeout: 252 seconds) | 17:50 | |
| *** notgull <notgull!~notgull@ec2-50-112-148-23.us-west-2.compute.amazonaws.com> has joined #yosys | 18:13 | |
| lofty | schaeg: make no mistake: EDIF is not a portable standard. Every tool interprets it differently and in highly contradictory ways | 18:36 |
| * schaeg wimpers. | 18:47 | |
| lofty | schaeg: what Yosys outputs is probably best described as Xilinx-flavoured EDIF; something ISE and Vivado will accept | 18:56 |
| 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 | 18:57 |
| lofty | Quartus, for example, pretty much directly rejects the output of Yosys as invalid | 18:58 |
| lofty | and I have no idea why | 18:58 |
| *** schaeg_ <schaeg_!~anabrid@2a02:3036:268:d670:68ac:760d:58ed:d419> has joined #yosys | 19:52 | |
| *** schaeg <schaeg!~anabrid@2a02:3036:268:d670:68ac:760d:58ed:d419> has quit IRC (Ping timeout: 272 seconds) | 19:53 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 252 seconds) | 20:03 | |
| *** buhman <buhman!sid411355@user/buhman> has quit IRC (Server closed connection) | 20:45 | |
| *** buhman <buhman!sid411355@user/buhman> has joined #yosys | 20:46 | |
| *** schaeg_ is now known as schaeg | 21:23 | |
| schaeg | why is everything so cursed | 21:23 |
| lofty | schaeg: welcome to the field. | 21:23 |
| *** stephe <[email protected]> has quit IRC (Ping timeout: 240 seconds) | 22:17 | |
| *** stephe <[email protected]> has joined #yosys | 22:19 | |
| *** nonchip <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 23:20 | |
| *** nonchip <[email protected]> has joined #yosys | 23:20 | |
| *** schaeg <schaeg!~anabrid@2a02:3036:268:d670:68ac:760d:58ed:d419> has quit IRC (Ping timeout: 252 seconds) | 23:50 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!