Monday, 2019-04-15

*** tpb has joined #symbiflow00:00
*** analognoise has joined #symbiflow01:27
*** Bertl_zZ is now known as Bertl06:07
*** proteusguy has quit IRC07:44
*** OmniMancer has joined #symbiflow07:47
*** proteusguy has joined #symbiflow07:48
*** analognoise1 has joined #symbiflow07:50
*** analognoise has quit IRC07:54
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.08:03
*** analognoise1 has quit IRC08:09
*** analognoise has joined #symbiflow08:09
*** analognoise1 has joined #symbiflow08:16
*** analognoise has quit IRC08:20
*** citypw has joined #symbiflow08:27
*** citypw has quit IRC09:12
*** sxpert has quit IRC09:50
*** sxpert has joined #symbiflow09:51
*** sxpert has quit IRC09:56
*** sxpert has joined #symbiflow10:31
*** sxpert has quit IRC12:10
*** futarisIRCcloud has quit IRC12:26
mithroMorning everyone14:15
sf-slack2<kgugala> Morning @mithro14:15
sf-slack2<acomodi> Morning14:16
sf-slack2<mkurc> Morning14:16
mithrosloppydiakon: There is plenty we need help with! I would suggest looking at our issue trackers14:16
mithrokgugala: How does the bel timing stuff go?14:26
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 xmls14:39
sf-slack2<kgugala> I'm right now removing the xmls and update CMake rules to generate those14:40
sf-slack2<kgugala> I think I have something to push later today14:40
*** OmniMancer has quit IRC15:12
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.15:25
litghostMkurc: you should create a pip table with a forgeign key to both the pip_in_tile and tile and phy_tile15:40
sf-slack2<mkurc> @litghost I know that but this will not be enough. What I am supposed to do with that mapping?15:51
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_X1Y015:51
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.xml15:51
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 ?15:54
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:15:57
sf-slack2CLK_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-pips15:57
tpbTitle: [WIP] Fuzzers stabilization by tmichalak · Pull Request #728 · SymbiFlow/prjxray · GitHub (at github.com)15:57
*** citypw has joined #symbiflow15:57
litghostmkurc: the pip table is required to prreform the tile split on the pips15:58
litghostmkurc: 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 table15:59
litghostmkurc: The Connection() class never changes under a tile split, period15:59
litghostmkurc: So the answer to you question is nothing changes there15:59
litghostmkurc: You are correct that during routing import we need to map IPIN/OPIN to site pin wire rows16:00
litghostmkurc: The name of the tile_type in the tile table should match the VPR tile name16:01
litghostmkurc: 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 generation16:01
litghostmkurc: 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 tiles16:02
litghostmkurc: In terms of why we start with the virtual rrgraph from VPR, a couple reasons16:03
litghostmkurc: 1) VPR's generation of the virtual rrgraph is correct in terms of IPIN, OPIN, SOURCE, SINK nodes16:03
litghostmkurc: 2) The virtual graph generation provides an early sanity check that the arch.xml is valid16:04
litghostmkurc: 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 use16:04
litghostmkurc: 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 what16:05
litghostmkurc: Does that make sense?16:05
*** citypw has quit IRC16:12
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 two16:17
sf-slack2tiles)16:17
tpbTitle: Support Equivalent Placement Sites · Issue #513 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)16:17
sf-slack2<mkurc> @litghost Makes sense but still I do not have a clear vision how to do this.16:18
sf-slack2<mkurc> @litghost Because splitting a CLB is not just moving pips sites and pins. It has to be consistent with the arch.xml16:19
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.16:23
litghostmkurc: From a routing standpoint "s not just moving pips sites and pins" is exactly what it is16:46
litghostmkurc: The arch.xml bit is extremely straight forward, where is the confusion16:46
litghostacomodi: Are you running with https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/42 merged?16:48
tpbTitle: Fix bug in routing walk logic. by litghost · Pull Request #42 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)16:48
sf-slack2<acomodi> litghost: actually no, I'll run genfasm again with the patch (or is the whole routing to be done again)?16:52
litghostacomodi: genfasm only16:52
sf-slack2<acomodi> litghost: all right, thanks16:54
litghosttmichalak: > Orig line:17:01
litghost8: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-pips17:01
litghostThe 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 updated17:01
litghosttmichalak: 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 wrong17:02
litghosttmichalak: At least wrong from the standpoint of the new tilegrid17:02
litghostmkurc: 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!17:10
litghostkgugala: >  I'm right now removing the xmls and update CMake rules to generate those17:11
litghostDoes that include the FF's?17:11
litghostkgugala: 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 today17:12
tpbTitle: WIP: Add explicit CEUSEDMUX and SRUSEDMUX support. by litghost · Pull Request #576 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)17:12
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_18917:22
*** analognoise1 has quit IRC17:23
litghosttmichalak: Okay, I was just providing context on why those values changed17:23
litghostAnd 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/c2df5c97eb27011ffe57a7acb22fff270266f22517:24
tpbTitle: Working complete HROW pip fuzzer. · SymbiFlow/[email protected] · GitHub (at github.com)17:24
sf-slack2<tmichalak> ok, makes sense17:25
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...17:27
litghosttmichalak: It is likely that the CI is just backed up17:29
litghosttmichalak: Let me take a look17:30
litghosttmichalak: CI might be broken, one minute17:30
litghosttmichalak: Looks like it resolved itself.  Maybe the VM's were just cold, but they are running now17:34
sf-slack2<tmichalak> @litghost: yepp, everything works now17:38
sf-slack2<kgugala> @litghost right now I'm focusing on LUT's and making the SLICEL and SLICEM independent (as they have different timings)17:48
sf-slack2<kgugala> at this moment I'm solving verilog dependancies in Cmak17:49
litghostkgugala: Ah good.  Do push any v2x changes you have so I don't double17:49
litghostkgugala: Need help, or all good?17:49
sf-slack2<kgugala> I'll push that later17:49
sf-slack2<kgugala> so far It's ok17:49
litghostkgugala: Thanks17:49
mithrokgugala: Where did we get with finishing up and landing acomodi's tests pull request here -> https://github.com/SymbiFlow/symbiflow-arch-defs/pull/316 ?17:51
tpbTitle: WIP: Improve the Verilog to XML conversion process by acomodi · Pull Request #316 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)17:51
litghostkgugala: 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 FASM19:37
tpbTitle: WIP: Improve the Verilog to XML conversion process by acomodi · Pull Request #316 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)19:37
sf-slack2<kgugala> oh, sorry didn't see @mithro's message19:38
sf-slack2<kgugala> I agree we should have it19:38
litghostkgugala: 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 v2x19:38
tpbTitle: WIP: Improve the Verilog to XML conversion process by acomodi · Pull Request #316 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)19:38
sf-slack2<kgugala> I didn't need it yet - all the conversions I need so far didn't need this19:39
sf-slack2<kgugala> @acomodi can you take a look on that, or comment why it is still WIP19:39
sf-slack2<kgugala> besides merge conflict and failing CI of course19:39
sf-slack2<kgugala> are those the only issues we need to fix before the merge?19:40
litghostkgugala: I just did a review pass, there are quiet of few weird changes, debug prints, etc19:41
litghostkgugala: It looks very WIP19:41
litghostkgugala: 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)19:41
*** tmichalak has joined #symbiflow20:23
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 there21:00
mithroI've been working on trying to get the latches in symbiflow-arch-defs in order21:39
mithroI now have the following flip flop diagram -> https://usercontent.irccloud-cdn.com/file/0kyvbm3r/image.png21:39
mithroI also have the following spreadsheet -> https://docs.google.com/spreadsheets/d/16yvScRkedOkPCRBSInFuHE_cUMD8Ls-b9KFmHocpC-o/edit21:40
tpbTitle: Flip Flops - Google Sheets (at docs.google.com)21:40
*** Bertl is now known as Bertl_zZ21:41
mithroI think I have all the Yosys internal, iCE40 and XC7 flip flop types in that spreadsheet so far21:44
mithroI can also generate sim models from them21:45
mithrotrying to get truth tables and test benches auto created too...21:49
mithroAnd also techmaps...21:49
hackerfooRAM32X1D 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?21:54
litghosthackerfoo: I think it makes sense to make an issue and add a TODO pointing to the issue to fix this in the future21:58
litghosthackerfoo: I don't think it makes sense to remove the pin21:58
litghosthackerfoo: The routing expression is correct, but the O5 to blackbox connection is missing until the TODO is closed21:59
litghosthackerfoo: Also do ensure that the RAM32X1D that gets packed is the same one as Vivado packs when only one RAM32X1D is in use22:00
litghosthackerfoo: 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 bitstreams22:00
hackerfooWhere is fasm2v? I couldn't find it.22:04
litghosthttps://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc7/fasm2bels22:05
tpbTitle: symbiflow-arch-defs/xc7/fasm2bels at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)22:05
litghostAnd it is used with <target>_bit_v22:05
litghostfor xc7 targets22:05
hackerfooThanks22:07
* hackerfoo sent a long message: < http://sandbox.hackerfoo.com:8008/_matrix/media/v1/download/sandbox.hackerfoo.com/jcxKbzakObEcbLSzDvkuLTGL >23:13
hackerfoo^ I get that error on *_bit_v targets.23:14
hackerfooram64 -> ram32, now I get AssertionError "AO6" and "CO6"23:18
hackerfooIs there a *_bit_v target known to work?23:20
litghostAnything under ff_ce_sr23:28
litghostThose are tested via CI23:28
litghostscalable proc when running with https://github.com/SymbiFlow/symbiflow-arch-defs/pull/58723:29
tpbTitle: Make scalable tests debuggable with fasm2v by litghost · Pull Request #587 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)23:29
litghostAh, if thats probably a C/P error ram64 -> ram3223:29
litghostYep https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/fasm2bels/clb_models.py#L500 and https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/fasm2bels/clb_models.py#L503 oaught read "ram32" instead of "ram64"23:30
tpbTitle: symbiflow-arch-defs/clb_models.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)23:30
hackerfooI fixed that, but then run into assertion errors.23:30
litghostWhich assertion?23:31
litghostAh, add_sink -> add_internal_source23:31
litghosthttps://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/fasm2bels/clb_models.py#L477 is roughly https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/fasm2bels/clb_models.py#L50723:32
tpbTitle: symbiflow-arch-defs/clb_models.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)23:32
litghostNoting of course that it doesn't support the double RAM32 pack23:32
hackerfooAO6 (ram_test), CO6 (dram_2_32x1d), and others for other targets.23:32
litghosthackerfoo:  add_sink -> add_internal_source, per https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/fasm2bels/clb_models.py#L477 is roughly https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/fasm2bels/clb_models.py#L50723:33
tpbTitle: symbiflow-arch-defs/clb_models.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)23:33
litghostI was also asking which line of code was asserting23:33
hackerfoo  File "/home/dusty/src/symbiflow-arch-defs/xc7/fasm2bels/verilog_modeling.py", line 387, in connect_internal23:35
hackerfoos/add_sink/add_internal_source seemed to fix it, thanks.23:38
litghostyay typos23:45

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!