01:13 <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:18 <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:20 <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:21 <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:22 <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:26 <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:27 <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:28 <cr1901_modern> prjtrellis can generate a generic routing graph structure; I can use that to perhaps generate XML output.

01:29 <mithro> cr1901_modern: gatecat has been prjoxide has been bringing up fpga-interchange support.....

01:35 <cr1901_modern> Shouldn't I worry about getting vpr to play nice w/ prjtrellis before I worry about fpga-interchange?

01:36 <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:58 <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:59 <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

02:01 <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:02 <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:04 <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:05 <mithro> The ice40 fabric is pretty regular so is much closer to what something like VPR generates compared to Xilinx stuff

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:06 <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

09:14 <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

12:50 <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)

16:10 <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:11 <FFY00_> *would the project

16:15 <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?

17:06 <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:09 <FFY00_> okay, so the deliverables would be developing a specification/format to write the scripts, port the xc7 family and what else?

17:13 <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

19:37 <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:38 <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:39 <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:40 <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:41 <Lofty> sdamghan: have you seen what the University of Utah have been working on with LSOracle?

19:42 <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:43 <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:44 <Lofty> So, I agree with the goal, I just don't think it's the right way to do it.

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:51 <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:52 <litghost> cr1901_modern: There are options that start with NO_... that disable portions of arch-defs until that support is ready

20:54 <litghost> cr1901_modern: I don't really understand your 4th question, can you rephrase?

22:25 <sf-slack> <sdamghan> I haven't actually, its good to know about that tho

22:26 <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:27 <sf-slack> <sdamghan> The blif file is given to the ABC. Generally, Odin does not use ABC

22:29 <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]