| *** tpb has joined #symbiflow | 00:00 | |
| *** Degi_ has joined #symbiflow | 01:06 | |
| *** Degi has quit IRC | 01:09 | |
| *** Degi_ is now known as Degi | 01:09 | |
| *** futarisIRCcloud has quit IRC | 01:09 | |
| *** umarcor has quit IRC | 01:12 | |
| mithro | oem: You might want to consider working with people like umarcor on docker packaging stuff @ https://github.com/hdl | 01:13 |
|---|---|---|
| mithro | oem: Probably https://github.com/hdl/containers to be specific | 01:13 |
| cr1901_modern | litghost: The past few weeks I've have been rough in meatspace so I haven't worked much on Symbiflow MachXO2 port. I'm ready to go back to it. However, I'm kinda stuck on where to go next on integrating stuff into the build system. >> | 01:18 |
| cr1901_modern | I was wondering if you have time this week for me to poke your brain/ask more qs to get me unstuck | 01:18 |
| cr1901_modern | I think I have three big pain points right now: >> | 01:20 |
| cr1901_modern | 1. The duplication of code between the python scripts calling conv.tcl/diff_io helper/synth.tcl and the arch() function doing essentially the same thing in its internals. | 01:20 |
| cr1901_modern | 2. Actually filling out the arch() cmake function itself and whether it's possible to fill it out piecemeal just so I can test that things are working. | 01:21 |
| cr1901_modern | 3. How might I incorporate python-symbiflow-v2x into the build system directly (and "can I used the upstream yosys techlibs to generate these" or should I reimplement them w/ the special annotations? | 01:22 |
| cr1901_modern | 4 (I lied). I have a python library hat is capable of building routing graphs for machxo2. There's no reason I can't use it for symbiflow. But is it recommended to generate the routing graphs before committing them? | 01:26 |
| mithro | This is pretty cool -> https://excamera.com/sphinx/article-cuflow-crossbar.html never heard of "River routing" before... | 01:26 |
| mithro | https://hackaday.com/2021/03/30/wires-vs-words-pcb-routing-in-python/ | 01:26 |
| tpb | Title: Crossbars in CuFlow (at excamera.com) | 01:26 |
| cr1901_modern | (Well, one of them, since symbiflow needs to generate the routing graph twice I think to sanitize it for VPR) | 01:26 |
| mithro | cr1901_modern: BTW Have you seen https://github.com/SymbiFlow/symbiflow-rr-graph ? | 01:27 |
| cr1901_modern | mithro: No I haven't. I will have to take a look and play around w/ it in an isolated work directory | 01:27 |
| cr1901_modern | prjtrellis can generate a generic routing graph structure; I can use that to perhaps generate XML output. | 01:28 |
| mithro | cr1901_modern: gatecat has been prjoxide has been bringing up fpga-interchange support..... | 01:29 |
| cr1901_modern | Shouldn't I worry about getting vpr to play nice w/ prjtrellis before I worry about fpga-interchange? | 01:35 |
| cr1901_modern | Also, not to mention: If fpga-interchange is meant to be the agreed-upon routing graph format for e.g. nextpnr fpgas, what will be done w/ the existing archs that use their own routing graph structures? | 01:36 |
| cr1901_modern | mithro: Can you point me to the symbiflow docs page that discusses the difference between -virt.xml rrgraph files and those without virt? | 01:58 |
| cr1901_modern | Assuming I'm not confusing -virt for something else (I just remember that symbiflow wants two versions of the routing graph) | 01:58 |
| mithro | cr1901_modern: IIRC The "virt" graph is the one that vpr generates by default | 01:59 |
| mithro | It's kind of a "fake" graph that can be used for research but is 100% useless for mapping to a real device until you do a *huge* amount of work | 01:59 |
| mithro | cr1901_modern: So we just replace it directly with the real routing graph | 02:01 |
| mithro | cr1901_modern: https://docs.google.com/document/d/1tigU9696M8LWO46nQBBcO1Uta7cwmXg-QylktISOc4o/edit#heading=h.tc2o015uyrch | 02:01 |
| tpb | Title: Making a VPR routing graph from prjxray - Google Docs (at docs.google.com) | 02:01 |
| mithro | https://docs.google.com/drawings/d/114n-yA-kCyeeQfUJJtbxXjjHuNc8YXJ1XnwaubWOWco/edit maybe? | 02:02 |
| tpb | Title: Prjxray import flow - Google Zeichnungen (at docs.google.com) | 02:02 |
| mithro | https://docs.google.com/drawings/d/1GwzV6Rs0gbiGI4DznWwG4000BLOcsuYYgYQ0YDqgXHY/edit | 02:02 |
| tpb | Title: SymbiFlow Architecture Definitions - File Diagram - Google Zeichnungen (at docs.google.com) | 02:02 |
| cr1901_modern | Okay I found the page I was looking at | 02:04 |
| cr1901_modern | https://github.com/SymbiFlow/symbiflow-arch-defs/blob/f34cd50d6eeeb0dc248dabf6ad6d0673f698489c/ice40/README.md | 02:04 |
| mithro | I'm quite out of date around how things work... | 02:04 |
| cr1901_modern | (Yes, I know it's ice40) | 02:04 |
| cr1901_modern | "The devices architecture descriptions have approximations of the real fabric, to get real fabric you have to override the rr_graph.xml file." | 02:04 |
| cr1901_modern | "Fake fabric which "approximates" the real fabric inside the iCE40." | 02:04 |
| mithro | The ice40 fabric is pretty regular so is much closer to what something like VPR generates compared to Xilinx stuff | 02:05 |
| *** gsmecher has quit IRC | 02:05 | |
| cr1901_modern | I'd been deliberately avoiding going down the 7-series rabbit hole b/c it's a lot more complex than machxo2. And if I don't have to, I don't want to have to learn how 7-series fabric works just to generate a routing graph for machxo2 | 02:05 |
| cr1901_modern | Btw, is rr_graph.real.xml fed back into VPR's --read-rr-graph option | 02:06 |
| cr1901_modern | ?* | 02:06 |
| mithro | cr1901_modern: I believe so | 02:06 |
| *** lopsided98_ has joined #symbiflow | 05:03 | |
| *** lopsided98 has quit IRC | 05:04 | |
| *** kraiskil has joined #symbiflow | 05:24 | |
| *** proteusguy has quit IRC | 05:37 | |
| *** kraiskil has quit IRC | 05:38 | |
| *** kraiskil has joined #symbiflow | 06:05 | |
| *** kraiskil has quit IRC | 06:29 | |
| *** proteusguy has joined #symbiflow | 06:31 | |
| *** kgugala_ has joined #symbiflow | 06:56 | |
| *** kgugala_ has quit IRC | 06:57 | |
| *** kgugala has quit IRC | 06:57 | |
| *** kgugala has joined #symbiflow | 06:58 | |
| *** hansfbaier has joined #symbiflow | 07:51 | |
| *** hansfbaier has quit IRC | 08:01 | |
| *** sirri has joined #symbiflow | 08:06 | |
| *** sirri has quit IRC | 08:23 | |
| *** sirri has joined #symbiflow | 08:39 | |
| *** sirri has joined #symbiflow | 08:39 | |
| *** sirri has quit IRC | 08:52 | |
| *** sirri has joined #symbiflow | 08:52 | |
| *** sirri has quit IRC | 08:57 | |
| *** sirri has joined #symbiflow | 08:57 | |
| sf-slack | <acomodi> FFY00_: here are the wrappers that would need re-writing: https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc/xc7/toolchain_wrappers | 09:14 |
| *** kraiskil has joined #symbiflow | 09:20 | |
| *** kraiskil has quit IRC | 09:35 | |
| *** sirri has quit IRC | 10:17 | |
| *** sirri has joined #symbiflow | 10:17 | |
| *** sirri has quit IRC | 10:22 | |
| *** sirri has joined #symbiflow | 10:22 | |
| *** kraiskil has joined #symbiflow | 10:50 | |
| *** kraiskil has quit IRC | 11:04 | |
| *** epony has quit IRC | 11:20 | |
| *** epony has joined #symbiflow | 11:25 | |
| *** sirri has quit IRC | 11:27 | |
| *** sirri has joined #symbiflow | 11:27 | |
| *** sirri has quit IRC | 11:32 | |
| *** sirri has joined #symbiflow | 11:32 | |
| *** sirri has quit IRC | 11:36 | |
| *** kraiskil has joined #symbiflow | 11:44 | |
| *** kraiskil has quit IRC | 12:24 | |
| *** umarcor has joined #symbiflow | 12:49 | |
| umarcor | oem: have a look at https://github.com/hdl/containers | 12:50 |
| umarcor | https://hdl.github.io/containers/#_tasks | 12:50 |
| tpb | Title: HDL containers (at hdl.github.io) | 12:50 |
| *** BryceSchroeder has quit IRC | 13:48 | |
| *** gsmecher has joined #symbiflow | 14:15 | |
| *** epony has quit IRC | 14:17 | |
| *** epony has joined #symbiflow | 14:18 | |
| *** rj has joined #symbiflow | 14:30 | |
| *** rj has quit IRC | 15:16 | |
| *** rj has joined #symbiflow | 15:21 | |
| FFY00_ | okay, that seems fairly straight forward. are there toolchain scripts for other families? I had a quick look but couldn't find anything. would be project involve doing anything else? I assume it will have stretch goals, things I can do if there is time left, but is there anything else in the deliverables? | 16:10 |
| FFY00_ | *would the project | 16:11 |
| FFY00_ | and could you elaborate a bit more on the "generalization". I am gonna guess we want to port these scripts to other families, right? or is it really just OS level generalization? | 16:15 |
| *** cjearls has joined #symbiflow | 16:25 | |
| sf-slack | <acomodi> FFY00_: So, I think getting to a place where those scripts are family-agnostic and OS-agnostic (at least for the main ones) would be the goal | 17:06 |
| FFY00_ | okay, so the deliverables would be developing a specification/format to write the scripts, port the xc7 family and what else? | 17:09 |
| sf-slack | <acomodi> That would do, probably we could get in also ports for other families in case they'll get supported as well. Another potential deliverable might be to add testing to cover all the wrappers functionalities | 17:13 |
| *** kraiskil has joined #symbiflow | 17:14 | |
| *** sirri has joined #symbiflow | 17:35 | |
| *** sirri has quit IRC | 17:38 | |
| *** sirri has joined #symbiflow | 17:38 | |
| *** sirri has quit IRC | 17:43 | |
| *** curtosis[away] has joined #symbiflow | 18:44 | |
| *** curtosis[away] has quit IRC | 19:06 | |
| *** sirri has joined #symbiflow | 19:25 | |
| sf-slack | <sdamghan> Hey all | 19:37 |
| mithro | Hey sdamghan! | 19:37 |
| mithro | sdamghan, you should chat with acomodi, kgugala, Lofty and maybe even gatecat about your ODIN-II partial mapping stuff | 19:37 |
| Lofty | Hmm? | 19:37 |
| mithro | Lofty: sdamghan is a student at News Brunswick that is working on ODIN-II and trying to make it integrate better with Yosys | 19:38 |
| Lofty | Could you be more specific with 'partial mapping'? | 19:39 |
| mithro | Lofty: ODIN-II has the ability to make potentially more intelligent choices about how to map to hard / soft logic | 19:39 |
| Lofty | mithro: ah; I call that deferred technology mapping rather than partial | 19:40 |
| mithro | Lofty: According to sdamghan it means it can choose to only map some stuff to hard logic and have other's kept it soft logic | 19:40 |
| mithro | But I'm just a manager these days, so no idea what I'm talking about :-) | 19:40 |
| Lofty | sdamghan: have you seen what the University of Utah have been working on with LSOracle? | 19:41 |
| Lofty | If I'm honest, I'm not sure that changing Yosys for Odin is the fix, because Odin still uses ABC under the hood, right? | 19:42 |
| Lofty | And to my knowledge ABC itself does not actually have support for this. | 19:43 |
| Lofty | Which is why UofU want to replace ABC wholesale | 19:43 |
| Lofty | So, I agree with the goal, I just don't think it's the right way to do it. | 19:44 |
| *** kraiskil has quit IRC | 20:40 | |
| *** sirri has quit IRC | 20:49 | |
| *** sirri has joined #symbiflow | 20:50 | |
| litghost | cr1901_modern: For v2x stuff, acomodi and kgugala are better folks to ask. I haven't touched v2x in a while | 20:50 |
| litghost | cr1901_modern: In terms of having a minimal define_arch, take a look at how testarch and the new quick logic arch are being brought up | 20:51 |
| litghost | cr1901_modern: There are options that start with NO_... that disable portions of arch-defs until that support is ready | 20:52 |
| litghost | cr1901_modern: I don't really understand your 4th question, can you rephrase? | 20:54 |
| *** sirri has quit IRC | 20:54 | |
| *** sirri has joined #symbiflow | 20:55 | |
| *** sirri has quit IRC | 20:59 | |
| *** sirri has joined #symbiflow | 21:00 | |
| *** sirri has quit IRC | 21:04 | |
| *** sirri has joined #symbiflow | 21:04 | |
| *** smkz has quit IRC | 21:08 | |
| *** smkz has joined #symbiflow | 21:10 | |
| *** FFY00_ has quit IRC | 22:01 | |
| *** FFY00_ has joined #symbiflow | 22:02 | |
| *** lambda has quit IRC | 22:03 | |
| sf-slack | <sdamghan> I haven't actually, its good to know about that tho | 22:25 |
| sf-slack | <sdamghan> Actually, Odin receives a Verilog file in addition to an xml architecture file and it outputs a blif file which is kinda partial mapped. | 22:26 |
| sf-slack | <sdamghan> The blif file is given to the ABC. Generally, Odin does not use ABC | 22:27 |
| sf-slack | <sdamghan> To the best of my knowledge, Yosys does not specify the hierarchy of a statement. For instance, this [link] blif file is generated for this [link] Verilog file from yosys. We do not have access to the instance _uut1_ or _uut2_ in the blif file, so specifying the hierarchy among modules could be a problem. 1. 2. Yosys generates a unique _.model_ for each module in the output blif. However, based on the above mentioned | 22:29 |
| sf-slack | matter, if there is a module instance inside the first module the _.model_ content for the first module would be empty. This happens while yosys should at least show the connectivity among the first module signals and the module instance signals. 3. Yosys generates a sub-circuit called $dff for reg assignments; However, in the output blif file the clock sensitivity, i.e. fallin, riasing, asynchronous or etc., is not specified. | 22:29 |
| sf-slack | [Verilog-link] [BLIF-link] | 22:29 |
| *** curtosis[away] has joined #symbiflow | 23:13 | |
| *** curtosis[away] has quit IRC | 23:42 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!