<litghost>
mithro: I think no one can, so do your best. We need cross pollination on fuzzer reviewers, so try.
<mithro>
litghost: I think kgugala, elms and acomodi are definitely good candidates
<litghost>
For 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 in
<litghost>
CLK_BUFG_REBUF tile.
<litghost>
Basically something akin to a bit that is set if the port is touching an active global clock network
citypw has joined #symbiflow
<mithro>
litghost: That is a clock buffer / redriver ?
<mithro>
CLK_BUFG <-- Global clock buffer driver
<litghost>
BUFG_REBUF is a redriver
<litghost>
But there are also bits in the BUFG -> HCLK tile
<litghost>
It appears there is a redriver at every pip junction that is active
citypw has quit [Ping timeout: 258 seconds]
<mithro>
litghost: 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.
<mithro>
litghost: Dunno if Xilinx uses anything like that
<mithro>
litghost: BTW If you don't mention my nick, the likelihood I respond is pretty low :-P
proteusguy has joined #symbiflow
proteusguy has quit [Read error: Connection reset by peer]
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #symbiflow
proteusguy has joined #symbiflow
<kgugala>
mithro: we need to update technology mappings in YOSYS
<kgugala>
we'll create issue for that in symbiflow
<kgugala>
actually it should be done there, because after we update YOSYS we'll need to update symbiflow so it still work with VPR
<mithro>
kgugala: I think litghost had started moving the tech mapping into the symbiflow-arch-defs repo
<kgugala>
actually he created an issue, but I think mkurc will attack this
<tpb>
Title: Move VPR specific yosys tech maps into symbiflow-arch-defs · Issue #294 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<mkurc>
Can 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)?
<mkurc>
Or should I add the mapping in the VPR itself?
proteusguy has quit [Remote host closed the connection]
proteusguy has joined #symbiflow
ovf has quit [Ping timeout: 264 seconds]
ovf has joined #symbiflow
OmniMancer has joined #symbiflow
_whitelogger has joined #symbiflow
OmniMancer has quit [Quit: Leaving.]
OmniMancer has joined #symbiflow
OmniMancer has quit [Read error: Connection reset by peer]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mkurc2 has joined #symbiflow
<mkurc2>
litghost: ok, i will look at this tomorrow.
<litghost>
Basically 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 workflow
<mkurc2>
i 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.
<mkurc2>
Because we would like to have a point in the flow that is compatible both with vivado and vpr
<mkurc2>
currently the -vpr switch results in a different flow
<litghost>
The carry chain is harder to deal with
<litghost>
not impossible
<litghost>
You'll have to emit a CARRY4 primative
<litghost>
CARRY4 is a vivado tech primative
<litghost>
And then we can techmap the CARRY4 down into VPR CARRY0 and CARRY primatives
<mkurc2>
no, i managed to get it working with only MUXCY and XORCY
<litghost>
Ya, but that won't work with VPR
<mkurc2>
yes, but
<litghost>
Like I said, you'll need to emit a CARRY4
<litghost>
CARRY4 is the closest primative that both Vivado and VPR could handle
<mkurc2>
if i add another pass to yosys i think i can map muxcy and xorcy to carry0 and carry
<litghost>
Don't think so
<litghost>
a CARRY0 is both a MUXCY and XORCY
<litghost>
You'd need to fuze them
<mkurc2>
it can be done in yosys code
<litghost>
And you won't have knowledge of where the carry0 goes from a sea of MUXCY
<litghost>
e.g. C++?
<mkurc2>
yes
<litghost>
That's total overkill
<litghost>
Just have the carry chain techmap emit a carry4, and then fracture it for VPR
<mkurc2>
so you say it is better to go with carry4?
<litghost>
Absolutely
<mkurc2>
ok, thanks
<litghost>
Trying 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 primative
<litghost>
The VPR techmap logic already knows where the 0th, 3rd, etc carry bit is and emits a CARRY0
<litghost>
It is only a small leap from there to emitting a CARRY4 with bits 0-3, then CARRY4 with 4-7, etc
<mkurc2>
yes, but what if we have eg. chain with length of 6?
<litghost>
Then inputs 6/7 of the 2nd CARRY4 are disconnected
<mkurc2>
shall we emit a not fully used carry4?
<litghost>
Of course
<mkurc2>
ok
<litghost>
That strategy keeps the synthesis between Vivado and VPR as close a possible with limited downsides
<mkurc2>
I 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.
<mkurc2>
actually xorcy cannot exist without muxcy
<mkurc2>
there is no other thing that it can be connected to.
<mkurc2>
Ok, thank you for the feedback. i will back to it tomorrow. bye
mkurc2 has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
focus1 has joined #symbiflow
focus1 has quit [Client Quit]
<mithro>
Morning
<mithro>
elms / litghost: I was trying to figure out the right targets to run on the CI for symbiflow-arch-defs and got myself confused....
<mithro>
elms / litghost: Is there targets which map to "all xc7" / "all ice40" / etc ?
<litghost>
You can cd into the directory and run all
<litghost>
and check I think
<litghost>
so "cd build/xc7/ && make <target>"
<litghost>
and that will only build 7-series
<litghost>
mithro: Currently "all_route_tests" is only used by targets in <root>/tests
<litghost>
But that would be the obvious target to attach things too
<mithro>
litghost: What should I be using for target? Just all?