analognoise has joined #symbiflow
Bertl_zZ is now known as Bertl
proteusguy has quit [Ping timeout: 246 seconds]
OmniMancer has joined #symbiflow
proteusguy has joined #symbiflow
analognoise1 has joined #symbiflow
analognoise has quit [Ping timeout: 250 seconds]
<sf-slack2> <mkurc> @litghost Regarding the rr graph traversal tool: I wrote it in C++ for better efficiency both in speed and memory usage (in my opinion). I'll rewrite it in Python and see if the difference is significant.
analognoise1 has quit [Quit: Leaving]
analognoise has joined #symbiflow
analognoise1 has joined #symbiflow
analognoise has quit [Ping timeout: 250 seconds]
citypw has joined #symbiflow
citypw has quit [Ping timeout: 252 seconds]
sxpert has quit [Ping timeout: 264 seconds]
sxpert has joined #symbiflow
sxpert has quit [Ping timeout: 252 seconds]
sxpert has joined #symbiflow
sxpert has quit [Quit: WeeChat 1.6]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<mithro> Morning everyone
<sf-slack2> <kgugala> Morning @mithro
<sf-slack2> <acomodi> Morning
<sf-slack2> <mkurc> Morning
<mithro> sloppydiakon: There is plenty we need help with! I would suggest looking at our issue trackers
<mithro> kgugala: How does the bel timing stuff go?
<sf-slack2> <kgugala> @mithro We discussed that with @litghost and @elms and we will proceed with generating all the xmls from verilog and inject the timings into the xmls
<sf-slack2> <kgugala> I'm right now removing the xmls and update CMake rules to generate those
<sf-slack2> <kgugala> I think I have something to push later today
OmniMancer has quit [Quit: Leaving.]
<sf-slack2> <mkurc> @me1 @litghost I've been thinking how to progress with the CLB split once the grid location mapping is done. And to be honest I do not have a clear idea what to do next. I've prepared an updated draft drawing of the import flow which I shared with you. I wrote a comment there with some of my thoughts about how the split should be done.
<litghost> Mkurc: you should create a pip table with a forgeign key to both the pip_in_tile and tile and phy_tile
<sf-slack2> <mkurc> @litghost I know that but this will not be enough. What I am supposed to do with that mapping?
<sf-slack2> <mkurc> @litghost All the connection information comes from the prjxray database through the Connection() class. It provides a generator which yields connection between tiles (CLBs). And these connections are passed as tile names and wire names. I cannot keep those names as wires that go to SLICE_X0Y0 are different that for SLICE_X1Y0
<sf-slack2> <mkurc> @litghost If I provide a table that maps pips between different tiles via foreign keys then I will still have to modify wire names as they are required in arch.xml
<sf-slack2> <mkurc> BTW: Why cannot we generate the rr graph XML directly via a python scripy? Why there is a need to use the VPR for initial rr graph generation in which we modify nodes and edges ?
<sf-slack2> <tmichalak> Morning everyone, I am still working on the prjxray stabilzation of the CI runs, and my latest attempts are in the dedicated PR (https://github.com/SymbiFlow/prjxray/pull/728). The runtime of the entire pipeline is kind of troublesome but it seems that I was able to get rid of most of them. The last one that I see very consistently is in 041-clk-hrow-pips fuzzer: Orig line:
<sf-slack2> CLK_HROW_BOT_R.CLK_HROW_CK_MUX_OUT_R2.CLK_HROW_R_CK_GCLK27 26_26 27_29 New line: CLK_HROW_BOT_R.CLK_HROW_BOT_R_CK_BUFG_CASCO0.CLK_HROW_CK_BUFRCLK_L3 26_26 27_29 I decided to create a separate fuzzer for pips with the CLK_HROW_CK_MUX_OUT destination and of course excluded them for being solved in 041-clk-hrow-pips
<tpb> Title: [WIP] Fuzzers stabilization by tmichalak · Pull Request #728 · SymbiFlow/prjxray · GitHub (at github.com)
citypw has joined #symbiflow
<litghost> mkurc: the pip table is required to prreform the tile split on the pips
<litghost> mkurc: the wire table already have a tile pkey, so the tile split for site pins can simply be done via assigning the tile forgien key in the wire table
<litghost> mkurc: The Connection() class never changes under a tile split, period
<litghost> mkurc: So the answer to you question is nothing changes there
<litghost> mkurc: You are correct that during routing import we need to map IPIN/OPIN to site pin wire rows
<litghost> mkurc: The name of the tile_type in the tile table should match the VPR tile name
<litghost> mkurc: And the site pin map between the VPR tile and the wire table is encoded in the site_type_*.json and the wire table during initial generation
<litghost> mkurc: So the rough process is 1) Create pip table, assigning VPR tiles based on tile split, 2) When creating the wire table use the VPR tile forgien key rather than the prjxray parent phy_tile forgien key 3) Update how the VPR IPIN/OPIN map lookup works to account for split/non-split tiles
<litghost> mkurc: In terms of why we start with the virtual rrgraph from VPR, a couple reasons
<litghost> mkurc: 1) VPR's generation of the virtual rrgraph is correct in terms of IPIN, OPIN, SOURCE, SINK nodes
<litghost> mkurc: 2) The virtual graph generation provides an early sanity check that the arch.xml is valid
<litghost> mkurc: It's unclear what benefit generating the IPIN/OPIN/SOURCE/SINK nodes, of the metadata portion of the rr graph (e.g switchlist, blocklist, grid) would gain use
<litghost> mkurc: The arch.xml grid definition defines the grid list found in the virtual rrgraph, so we still need to generate the arch.xml no matter what
<litghost> mkurc: Does that make sense?
citypw has quit [Ping timeout: 245 seconds]
<sf-slack2> <acomodi> update on equivalent tiles: unfortunately picosoc did not work on HW, I have been debugging to find the reason. Anyways _kem gave a detailed description on what is for him the best way to proceed with the equivalence tiles (https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/513). With a little change on my PR on the Symbiflow fork I can implement its first option (strict pin equivalence between two
<sf-slack2> tiles)
<tpb> Title: Support Equivalent Placement Sites · Issue #513 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
<sf-slack2> <mkurc> @litghost Makes sense but still I do not have a clear vision how to do this.
<sf-slack2> <mkurc> @litghost Because splitting a CLB is not just moving pips sites and pins. It has to be consistent with the arch.xml
<sf-slack2> <mkurc> @litghost I will keep working on it basing on your latest insights. But I still do not understand why shouldn't we go with the of modifying input to the prjxray_*.py scripts.
<litghost> mkurc: From a routing standpoint "s not just moving pips sites and pins" is exactly what it is
<litghost> mkurc: The arch.xml bit is extremely straight forward, where is the confusion
<litghost> acomodi: Are you running with https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/42 merged?
<tpb> Title: Fix bug in routing walk logic. by litghost · Pull Request #42 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)
<sf-slack2> <acomodi> litghost: actually no, I'll run genfasm again with the patch (or is the whole routing to be done again)?
<litghost> acomodi: genfasm only
<sf-slack2> <acomodi> litghost: all right, thanks
<litghost> tmichalak: > Orig line:
<litghost> The word offset for the clk HROW was moved in https://github.com/SymbiFlow/prjxray/commit/c2df5c97eb27011ffe57a7acb22fff270266f225, so the aliasing you see there is simply caused by tilegrid definition being updated
<litghost> 8:49 AM CLK_HROW_BOT_R.CLK_HROW_CK_MUX_OUT_R2.CLK_HROW_R_CK_GCLK27 26_26 27_29 New line: CLK_HROW_BOT_R.CLK_HROW_BOT_R_CK_BUFG_CASCO0.CLK_HROW_CK_BUFRCLK_L3 26_26 27_29 I decided to create a separate fuzzer for pips with the CLK_HROW_CK_MUX_OUT destination and of course excluded them for being solved in 041-clk-hrow-pips
<litghost> tmichalak: In this case, I incorrectly determined the base word offset and had to expand how many words belonged to CLK_HROW, so the old solution is just wrong
<litghost> tmichalak: At least wrong from the standpoint of the new tilegrid
<litghost> mkurc: Oh another reason to not generate the entire rrgraph: It's slow! When I was optimizing prjxray_routing_import.py, I originally was creating the output xml soley from the python datastructures in graph2. Doing that took a minute or so! Simply copying the portion of the rrgraph from virt to real took less than a second!
<litghost> kgugala: > I'm right now removing the xmls and update CMake rules to generate those
<litghost> Does that include the FF's?
<litghost> kgugala: I needed to add some pack patterns for https://github.com/SymbiFlow/symbiflow-arch-defs/pull/576 and they are awful. My thinking was handling this in v2x (I have some ideas). If you haven't done FF xml -> .v + v2x, I can start that today
<tpb> Title: WIP: Add explicit CEUSEDMUX and SRUSEDMUX support. by litghost · Pull Request #576 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<sf-slack2> <tmichalak> @litghost Yes, I know that, I found that the correct solution is CLK_HROW_BOT_R.CLK_HROW_CK_MUX_OUT_R2.CLK_HROW_R_CK_GCLK27 26_186 27_189
analognoise1 has quit [Read error: Connection reset by peer]
<litghost> tmichalak: Okay, I was just providing context on why those values changed
<litghost> And you'll note that 26_26 -> 26_186 is a 5 32-bit words different (186-26 = 160, 160/5 = 32), which matches the change done in https://github.com/SymbiFlow/prjxray/commit/c2df5c97eb27011ffe57a7acb22fff270266f225
<tpb> Title: Working complete HROW pip fuzzer. · SymbiFlow/prjxray@c2df5c9 · GitHub (at github.com)
<sf-slack2> <tmichalak> ok, makes sense
<sf-slack2> <tmichalak> did something change with regards to rerunning the CI build using the kokoro:force-run label? I am not able to rerun the tests using it. It used to work...
<litghost> tmichalak: It is likely that the CI is just backed up
<litghost> tmichalak: Let me take a look
<litghost> tmichalak: CI might be broken, one minute
<litghost> tmichalak: Looks like it resolved itself. Maybe the VM's were just cold, but they are running now
<sf-slack2> <tmichalak> @litghost: yepp, everything works now
<sf-slack2> <kgugala> @litghost right now I'm focusing on LUT's and making the SLICEL and SLICEM independent (as they have different timings)
<sf-slack2> <kgugala> at this moment I'm solving verilog dependancies in Cmak
<litghost> kgugala: Ah good. Do push any v2x changes you have so I don't double
<litghost> kgugala: Need help, or all good?
<sf-slack2> <kgugala> I'll push that later
<sf-slack2> <kgugala> so far It's ok
<litghost> kgugala: Thanks
<mithro> kgugala: Where did we get with finishing up and landing acomodi's tests pull request here -> https://github.com/SymbiFlow/symbiflow-arch-defs/pull/316 ?
<tpb> Title: WIP: Improve the Verilog to XML conversion process by acomodi · Pull Request #316 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> kgugala: Ya, echoing mithro, we should get https://github.com/SymbiFlow/symbiflow-arch-defs/pull/316 merged before we start expanding v2x support to cover timing and FASM
<tpb> Title: WIP: Improve the Verilog to XML conversion process by acomodi · Pull Request #316 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<sf-slack2> <kgugala> oh, sorry didn't see @mithro's message
<sf-slack2> <kgugala> I agree we should have it
<tpb> Title: WIP: Improve the Verilog to XML conversion process by acomodi · Pull Request #316 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> kgugala: Especially now that CI is running tests, we should get some baselines v2x tests running (e.g. fixup and merge https://github.com/SymbiFlow/symbiflow-arch-defs/pull/316), and then add to the test suite as we need features from v2x
<sf-slack2> <kgugala> I didn't need it yet - all the conversions I need so far didn't need this
<sf-slack2> <kgugala> @acomodi can you take a look on that, or comment why it is still WIP
<sf-slack2> <kgugala> besides merge conflict and failing CI of course
<sf-slack2> <kgugala> are those the only issues we need to fix before the merge?
<litghost> kgugala: I just did a review pass, there are quiet of few weird changes, debug prints, etc
<litghost> kgugala: It looks very WIP
<litghost> kgugala: Most comments were of that variety, some requests for documentation, and some requests for adding some usability features (all targets, update golden file targets, etc)
tmichalak has joined #symbiflow
<sf-slack2> <acomodi> litghost, kgugala: yes, it was a very WIP. I had taken mithro commits and added new ones but then left it to focus on other higher priority issues. I would say that we can clean it up and then merge and continue from there
<mithro> I've been working on trying to get the latches in symbiflow-arch-defs in order
<mithro> I now have the following flip flop diagram -> https://usercontent.irccloud-cdn.com/file/0kyvbm3r/image.png
<tpb> Title: Flip Flops - Google Sheets (at docs.google.com)
Bertl is now known as Bertl_zZ
<mithro> I think I have all the Yosys internal, iCE40 and XC7 flip flop types in that spreadsheet so far
<mithro> I can also generate sim models from them
<mithro> trying to get truth tables and test benches auto created too...
<mithro> And also techmaps...
<hackerfoo> RAM32X1D only uses O5 when packing two of them in half a slice (e.g. C/DLUT), but VPR doesn't seem to do this. Would it make sense to comment out O5 in dpram32.pb_type.xml?
<litghost> hackerfoo: I think it makes sense to make an issue and add a TODO pointing to the issue to fix this in the future
<litghost> hackerfoo: I don't think it makes sense to remove the pin
<litghost> hackerfoo: The routing expression is correct, but the O5 to blackbox connection is missing until the TODO is closed
<litghost> hackerfoo: Also do ensure that the RAM32X1D that gets packed is the same one as Vivado packs when only one RAM32X1D is in use
<litghost> hackerfoo: fasm2v lacks control over some aspects of vivado, so if vivado makes a choice we lack control over, we need to make the same choice to ensure consistent bitstreams
<hackerfoo> Where is fasm2v? I couldn't find it.
<tpb> Title: symbiflow-arch-defs/xc7/fasm2bels at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> And it is used with <target>_bit_v
<litghost> for xc7 targets
<hackerfoo> Thanks
<hackerfoo> ^ I get that error on *_bit_v targets.
<hackerfoo> ram64 -> ram32, now I get AssertionError "AO6" and "CO6"
<hackerfoo> Is there a *_bit_v target known to work?
<litghost> Anything under ff_ce_sr
<litghost> Those are tested via CI
<litghost> scalable proc when running with https://github.com/SymbiFlow/symbiflow-arch-defs/pull/587
<tpb> Title: Make scalable tests debuggable with fasm2v by litghost · Pull Request #587 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> Ah, if thats probably a C/P error ram64 -> ram32
<tpb> Title: symbiflow-arch-defs/clb_models.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<hackerfoo> I fixed that, but then run into assertion errors.
<litghost> Which assertion?
<litghost> Ah, add_sink -> add_internal_source
<tpb> Title: symbiflow-arch-defs/clb_models.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> Noting of course that it doesn't support the double RAM32 pack
<hackerfoo> AO6 (ram_test), CO6 (dram_2_32x1d), and others for other targets.
<tpb> Title: symbiflow-arch-defs/clb_models.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> I was also asking which line of code was asserting
<hackerfoo> File "/home/dusty/src/symbiflow-arch-defs/xc7/fasm2bels/verilog_modeling.py", line 387, in connect_internal
<hackerfoo> s/add_sink/add_internal_source seemed to fix it, thanks.
<litghost> yay typos
tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow
<hackerfoo> How do I load the result into Vivado? I have a Verilog file and a TCL script, but "vivado -mode batch -source top_bit.v.tcl" asks me to create a project first.
<sf-slack2> <mgielda> hi all; digging in prjxray Makefile - https://github.com/SymbiFlow/prjxray/blob/master/docs/Makefile - and admittedly not a Make master so just looking to understand some things. 1) should the "livereload" .PHONY target be "livehtml" and this is just a remnant?
<tpb> Title: prjxray/Makefile at master · SymbiFlow/prjxray · GitHub (at github.com)