Wednesday, 2019-04-24

*** tpb has joined #symbiflow00:00
hackerfooDoes anyone else typically have to remove the `build` directory in symbiflow-arch-defs after pulling in changes? It might only be when updating a submodule.00:26
*** proteusguy has joined #symbiflow00:27
*** citypw has quit IRC01:57
*** citypw has joined #symbiflow03:04
*** Bertl_oO is now known as Bertl_zZ03:32
*** citypw has quit IRC06:17
*** citypw has joined #symbiflow06:30
sf-slack2<mkurc> @hackerfoo I do it occasionally. It seems that submodules are updated only when running `make env` in the root. You can try running `make env` without removing the `build` directory.07:06
*** kraiskil has joined #symbiflow07:38
*** felix_ has quit IRC07:50
*** felix_ has joined #symbiflow07:51
*** JuanP has joined #symbiflow09:05
JuanPHi, I compiled a verilog file and diff occur between trellis ans diamond. Here is the pastebin: is is normal?09:06
JuanPNote: the code obviously does nothing interesting here09:06
daveshahYou mean the config is different?09:07
*** kraiskil has quit IRC09:07
*** kraiskil has joined #symbiflow09:08
daveshahComing up with the optimal mapping from Verilog to a place-and-routed design is hard (ie effectively impossible) and there may be more than one optimal solution anyway09:08
daveshahAll FPGA tools have different mapping rules, optimisations, heuristics, etc09:09
daveshahIt would be exactly the same as a diff between the assembly produced by gcc and Visual C++, for example09:09
JuanPyes the bitstreams are different. So it is a normal behavior then09:20
JuanPthe bottom line being: fpga are difficult to code for because there may be something hidden by the manufacturer still09:21
daveshahAs I say, this is exactly the same as almost any other toolchain - software or fpga09:25
daveshahDifferent toolchains will do different optimisations, have different mapping rules, etc09:25
daveshahFPGA placement and routing is perhaps even more complicated due to the use of heuristics like SA that depend on pseudo random decisions09:26
JuanPI get it perfectly. BTW, Diamond doesn't show all the wires a device is made of, does it? i mean, in Diamond, no overall view of the wires connecting one tile/slice/mux to one another, If yes, how did you achieve to get their names and position?09:29
JuanP(you get the compoenent names but that's it)09:30
*** kraiskil has quit IRC09:30
daveshahYou can go into physical view and enable the view of all the wires etc09:33
daveshahThere are some toolbar buttons that toggle09:33
JuanPgot it. it works. Was lookig at the floorplan. FINE! David, you are a wondeful person09:36
*** JuanP has left #symbiflow09:38
*** citypw has quit IRC10:03
*** kraiskil has joined #symbiflow10:26
*** kraiskil has quit IRC10:57
*** kraiskil has joined #symbiflow11:17
*** Bertl_zZ is now known as Bertl11:48
*** kraiskil has quit IRC12:45
*** kraiskil has joined #symbiflow13:27
*** kraiskil has quit IRC13:59
sf-slack2<acomodi> I think I spotted the issue with the equivalent tiles: I have added a workaround to get the correct slice to be added as prefix during the `fasm` generation. The workaround basically extracts the meta of the equivalent tile's slice. The issue was that the in the database (specifically in tile_type_CLB*.json), the SLICE sites are not ordered (e.g. in CLBLM SLICE X0Y0 is the first, while in CLBLL, SLICE X1Y0 is the14:04
sf-slack2first). This means that the `placement_index` of a `pb_graph_node` that I have used in genfasm was not consistent between equivalent tiles14:04
sf-slack2<acomodi> I think that once the tiles are split, the issue will be no more. I have temporarily swapped the order of the SLICEs in the tile_type_CLB*.json files to be all consistent one another and verify that this was the issue.14:06
sf-slack2<acomodi> confirmed! the issue was the one described above. `simple_ff` test is working with equivalent tiles. I am going to check all the tests now14:14
*** kraiskil has joined #symbiflow14:16
sf-slack2<mkurc> Great!14:16
sf-slack2<mkurc> Regarding the CLB tile split: I've written code which splits CLBs to "specialized" SLICE tiles (eg. CLBLL_L_SLICEL_X0Y0) and generates wire and pip mapping between CLB and SLICE tiles. Those specialized SLICEs will be converted to generic SLICEs when generating the `arch.xml`. Progressing with the integration with the rest of the prjxray import flow.14:18
*** celadon has quit IRC14:22
*** futarisIRCcloud has quit IRC14:22
*** celadon has joined #symbiflow14:23
*** Bertl is now known as Bertl_oO14:48
*** citypw has joined #symbiflow15:01
sf-slack2<acomodi> chain_packing test works on HW with equivalent tiles15:18
*** kraiskil has quit IRC15:26
*** citypw has quit IRC16:05
*** JuanP has joined #symbiflow16:10
JuanP@Davesha: I did the compilation again and Diamond showed a clock of 350ishMHz while trellis showed 630ishMHz. That is impressive16:11
daveshahProbably good luck on such a small design. Usually Yosys&nextpnr is ~20-30% behind Diamond16:13
JuanPYes I will throw a proper one soon and we will see. But overall I am very happy that this project exists.16:14
JuanPSorry I misspelled your name Dave16:15
*** JuanP has quit IRC16:15
*** Maya-sama has joined #symbiflow16:27
*** Miyu has quit IRC16:30
*** Maya-sama is now known as Miyu16:31
elmsacomodi: Awesome!16:45
sf-slack2<acomodi> elms: Yep, I still need to run all the tests. In the meanwhile I have started a picosoc build. Hopefully, In about an hour the bitstream should be available.16:50
elmsmithro: is there a way to rerun a build on kokoro? specifically a conda install failed
hackerfooelms: The "kokoro:force-run" tag should cause a PR to run again.17:00
mithrokgugala / acomodi: I have some stuff around v2x stuff17:08
mithroCurrently in a meeting then need to pack with chicago, will try and get back to you ASAP17:08
sf-slack2<kgugala> @mithro can you take a look on
tpbTitle: v2x dsp_in_registered test fix by kgugala · Pull Request #639 · SymbiFlow/symbiflow-arch-defs · GitHub (at
sf-slack2<kgugala> this adds multiple instance handling to v2x17:09
sf-slack2<kgugala> it's not complete though - we still need to update pb_num in included xmls17:10
*** kraiskil has joined #symbiflow17:16
mithrokgugala: I'm just packing, I'll be back in 2-3 hours18:13
sf-slack2<kgugala> @mithro sure, just ping me here or in the PR18:14
hackerfooCan we use the ARM cores on the ZYBO? It seems like they would be good for driving tests in hardware.18:21
sf-slack2<kgugala> @hackerfoo we still miss info how the core connects to the logic18:22
sf-slack2<kgugala> to be more precise which PS pin goes to which PIP18:22
sf-slack2<kgugala> also, we need yosys update so it can handle PS instance18:22
sf-slack2<kgugala> + arch.xml and routing graph update18:23
sf-slack2<kgugala> I agree this would be a great way of testing things18:23
*** kraiskil has quit IRC18:39
elmshackerfoo: I recall it being easy to load a bitstream from the ARM core, but yeah interacting once loaded is a little tricky. Once we understand the PS interconnect or maybe we could have it as part of a test harness.18:42
hackerfooI guess it won't happen any time soon, then. It would be nice to have the board cycle through a bunch of tests, since it's probably at least 1000x faster than simulation and more accurate, although generating bitstreams will still be slow, so maybe it doesn't matter much.19:04
hackerfooAny idea why this line isn't `.IS_WCLK_INVERTED(IS_WCLK_INVERTED)` as it is elsewhere?
tpbTitle: symbiflow-arch-defs/cells_map.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
sf-slack2<kgugala> hackerfoo: I think @mkurc may shed some light on it20:34
tpbTitle: Moved techmaps from Yosys to SymbiFlow by mkurc-ant · Pull Request #390 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** kraiskil has joined #symbiflow20:51
sf-slack2<mkurc> @hackerfoo This should not have any effect unless you have DRAM writes on negedge of clock in your design.21:07
sf-slack2<mkurc> @hackerfoo According to the documentation of Xilinx primitive library there is no `.IS_WCLK_INVERTED` parameter in the `RAM32X1D` primitive. Nor there is in any other DRAM primitives.21:07
sf-slack2<mkurc> @hackerfoo You are probably right, it should be passed as for all other DRAM types21:08
sf-slack2<mkurc> @hackerfoo I'll check tomorrow whether it has any influence on the FASM output.21:10
hackerfoomkurc: Thanks.
tpbTitle: Make sure IS_WCLK_INVERTED is passed for all DRAM types · Issue #640 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** kraiskil has quit IRC22:11
*** adjtm has quit IRC23:33
*** adjtm has joined #symbiflow23:34
* hackerfoo uploaded an image: di2.jpg (85KB) < >23:45
hackerfoo^ I think this means DI2 affects O6, not DI1.23:46
mithro@kgugala + @acomodi - FYI -
tpbTitle: Make v2x produce the new composable interconnect specification again (IE Revert #637). · Issue #642 · SymbiFlow/symbiflow-arch-defs · GitHub (at
mithrokgugala / acomodi: Hopefully you are asleep right now and will see that in the morning23:51
mithrohackerfoo: I confirm I would be suspicious23:52
tpbTitle: symbiflow-arch-defs/ntemplate.N_dram.model.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
mithrohackerfoo: Yeah, that potentially looks wrong (I'm not 100% confident that Vivado isn't lying in some way) but I'm not sure what effect incorrect model definitions would have....23:57
*** digshadow has joined #symbiflow23:59
mithrohackerfoo: You might want to ask digshadow about this23:59

Generated by 2.13.1 by Marius Gedminas - find it at!