Wednesday, 2019-02-13

*** tpb has joined #symbiflow00:00
mithrolitghost: I don't think it makes sense to request my review on prjxray changes - I don't feel like I can give that meaningful review00:06
mithroelms / litghost: Has is the status on a FASM style guide?00:06
mithroI assume no progress?00:06
litghostmithro: I think no one can, so do your best.  We need cross pollination on fuzzer reviewers, so try.00:07
mithrolitghost: I think kgugala, elms and acomodi are definitely good candidates00:07
litghostFor anyone who knows about FPGA clock trees, there are bits that appear to be set on 7 series interconnect ports that become active if a global clock network is enabled, even if the interconnect port is not used.  I assume these are designed to improve clock performance.  Do they have a technical name?  I've found them in at least two places, the ports to the CLK_HROW  tile and the bottom and top sides of the bipips in01:02
litghostCLK_BUFG_REBUF tile.01:02
litghostBasically something akin to a bit that is set if the port is touching an active global clock network01:02
*** citypw has joined #symbiflow01:10
mithrolitghost: That is a clock buffer / redriver ?02:02
mithroCLK_BUFG <-- Global clock buffer driver02:02
litghostBUFG_REBUF is a redriver02:03
litghostBut there are also bits in the BUFG -> HCLK tile02:03
litghostIt appears there is a redriver at every pip junction that is active02:05
*** citypw has quit IRC02:14
mithrolitghost: From what I've seen on some parts clock trees you need to enable drivers to kinda of "terminate" a tree. IE You need to enable one more driver than you would expect.02:24
mithrolitghost: Dunno if Xilinx uses anything like that02:25
mithrolitghost: BTW If you don't mention my nick, the likelihood I respond is pretty low :-P02:27
*** proteusguy has joined #symbiflow06:58
*** proteusguy has quit IRC07:01
*** lopsided98 has quit IRC07:14
*** lopsided98 has joined #symbiflow07:15
*** proteusguy has joined #symbiflow07:16
kgugalamithro: we need to update technology mappings in YOSYS07:25
kgugalawe'll create issue for that in symbiflow07:25
kgugalaactually it should be done there, because after we update YOSYS we'll need to update symbiflow so it still work with VPR07:26
mithrokgugala: I think litghost had started moving the tech mapping into the symbiflow-arch-defs repo07:27
kgugalaactually he created an issue, but I think mkurc will attack this07:28
kgugalahe's made some progress with YOSYS07:29
*** mkurc has joined #symbiflow08:12
*** Fabian has joined #symbiflow08:56
*** Fabian has quit IRC08:58
acomodiI am going to work on this issue instead:
tpbTitle: The way sites are named in Tile.get_instance_sites is broken · Issue #134 · SymbiFlow/prjxray · GitHub (at
mkurcI will work on:
tpbTitle: Move VPR specific yosys tech maps into symbiflow-arch-defs · Issue #294 · SymbiFlow/symbiflow-arch-defs · GitHub (at
mkurcCan somebody point me out whether I should add additional pass to Yosys that will map output of the "Xilinx flow" to VPR (as suggested in comment to #294)?09:06
mkurcOr should I add the mapping in the VPR itself?09:06
*** proteusguy has quit IRC09:25
*** proteusguy has joined #symbiflow09:27
*** ovf has quit IRC09:49
*** ovf has joined #symbiflow09:51
*** OmniMancer has joined #symbiflow10:38
*** _whitelogger has quit IRC11:13
*** _whitelogger has joined #symbiflow11:15
*** OmniMancer has quit IRC12:30
*** OmniMancer has joined #symbiflow13:30
*** OmniMancer has quit IRC14:14
*** mkurc has left #symbiflow16:08
litghostmkurc: Pass is already added16:14
tpbTitle: symbiflow-arch-defs/synth.tcl at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostStart of VPR specific techmaps are
tpbTitle: symbiflow-arch-defs/xc7/techmap at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** jevinskie has joined #symbiflow16:32
*** jevinskie has quit IRC17:30
*** mkurc2 has joined #symbiflow18:16
mkurc2litghost: ok, i will look at this tomorrow.18:23
litghostBasically anything that is changing the yosys techmap from master to master+wip should either 1) move to symbiflow if possible 2) be toggled by the -vpr flag in the synth_xilinx workflow18:25
mkurc2i was thinking about sth. like that: we have a synthesis flow that maintains yosys-vivado compatibility followed by another pass that maps its result to primitives cimpatible with vpr.18:27
mkurc2Because we would like to have a point in the flow that is compatible both with vivado and vpr18:28
mkurc2currently the -vpr switch results in a different flow18:29
litghostThe carry chain is harder to deal with18:29
litghostnot impossible18:29
litghostYou'll have to emit a CARRY4 primative18:30
litghostCARRY4 is a vivado tech primative18:30
litghostAnd then we can techmap the CARRY4 down into VPR CARRY0 and CARRY primatives18:30
mkurc2no, i managed to get it working with only MUXCY and XORCY18:31
litghostYa, but that won't work with VPR18:31
mkurc2yes, but18:31
litghostLike I said, you'll need to emit a CARRY418:31
litghostCARRY4 is the closest primative that both Vivado and VPR could handle18:32
mkurc2if i add another pass to yosys i think i can map muxcy and xorcy to carry0 and carry18:32
litghostDon't think so18:32
litghosta CARRY0 is both a MUXCY and XORCY18:32
litghostYou'd need to fuze them18:33
mkurc2it can be done in yosys code18:33
litghostAnd you won't have knowledge of where the carry0 goes from a sea of MUXCY18:33
litghoste.g. C++?18:33
litghostThat's total overkill18:33
litghostJust have the carry chain techmap emit a carry4, and then fracture it for VPR18:33
mkurc2so you say it is better to go with carry4?18:34
mkurc2ok, thanks18:34
litghostTrying to merge MUXCY and XORCY, and find the root of the chain in C++ is significantly more complicated than having the verilog group carry bits into groups of 4 and emitting a CARRY4 primative18:35
litghostThe VPR techmap logic already knows where the 0th, 3rd, etc carry bit is and emits a CARRY018:35
litghostIt is only a small leap from there to emitting a CARRY4 with bits 0-3, then CARRY4 with 4-7, etc18:36
mkurc2yes, but what if we have eg. chain with length of 6?18:37
litghostThen inputs 6/7 of the 2nd CARRY4 are disconnected18:37
mkurc2shall we emit a not fully used carry4?18:37
litghostOf course18:37
litghostThat strategy keeps the synthesis between Vivado and VPR as close a possible with limited downsides18:38
mkurc2I was thinking that by doing it using individual muxcy and xorcy we can have carry chains of length not being multiply of 4. Then we would not emmit partially occupied carry4 and the remaining logic could then became a part of another chain.18:40
mkurc2actually xorcy cannot exist without muxcy18:41
mkurc2there is no other thing that it can be connected to.18:42
mkurc2Ok, thank you for the feedback. i will back to it tomorrow. bye18:43
*** mkurc2 has quit IRC18:43
*** focus1 has joined #symbiflow20:31
*** focus1 has quit IRC20:32
mithroelms / litghost: I was trying to figure out the right targets to run on the CI for symbiflow-arch-defs and got myself confused....20:51
mithroelms / litghost: Is there targets which map to "all xc7" / "all ice40" / etc ?20:51
litghostYou can cd into the directory and run all20:54
litghostand check I think20:54
litghostso "cd build/xc7/  && make <target>"20:54
litghostand that will only build 7-series20:54
litghostmithro: Currently "all_route_tests" is only used by targets in <root>/tests20:57
litghostBut that would be the obvious target to attach things too21:03
mithrolitghost: What should I be using for target? Just all?22:23

Generated by 2.13.1 by Marius Gedminas - find it at!