Friday, 2020-01-31

*** tpb has joined #symbiflow00:00
*** space_zealot has joined #symbiflow01:01
*** citypw has joined #symbiflow01:20
*** freemint has quit IRC02:22
*** freemint has joined #symbiflow02:22
*** freeemint has joined #symbiflow02:34
*** freemint has quit IRC02:36
*** Bertl_oO is now known as Bertl_zZ03:22
*** space_zealot has quit IRC03:37
*** freemint has joined #symbiflow03:38
*** freeemint has quit IRC03:40
hackerfooA 96-core box computes lookahead really fast.03:44
*** freemint has quit IRC04:22
*** freemint has joined #symbiflow04:22
*** freemint has quit IRC04:24
*** freemint has joined #symbiflow04:24
*** freemint has quit IRC05:38
*** _whitelogger has quit IRC07:08
*** Ultrasauce has quit IRC07:08
*** Ultrasauce_ has joined #symbiflow07:08
*** _whitelogger_ has joined #symbiflow07:10
*** yeti has quit IRC07:11
*** az0re has joined #symbiflow07:44
*** az0re has quit IRC08:16
-_whitenotifier-3- [sv-tests] towoe opened issue #597: Contribution guide -
*** rvalles_ has quit IRC09:35
*** _whitelogger_ has quit IRC09:40
*** _whitelogger has joined #symbiflow09:43
*** rvalles_ has joined #symbiflow09:49
sf-slack1<acomodi> mithro, litghost: updated timing report from Vivado after constraining the clock:
tpbTitle: Filebin :: bin ptwm4nla8k1gdm7r (at
sf-slack1<acomodi> We got ~1300 setup violation for the main system clock and 2 hold violation for the same clock10:49
*** luaraneda has joined #symbiflow10:58
*** freemint has joined #symbiflow11:28
mithroacomodi: Well that isn't going to work :-P11:34
sf-slack1<acomodi> mithro: Yep definetly, interestingly enough though, the CPU still woks fine as well as DDR calibration (apparently). With so many setup violations shouldn't be some issues also there?11:37
mithroacomodi: So what SDC file are you giving to vpr?11:38
tpbTitle: Snippet | IRCCloud (at
sf-slack1<acomodi> mithro: this one
tpbTitle: create_clock -period 5 sys4x_clk__main_clkout_buf1 create_clock -period 5 sys4x - (at
mithroacomodi: So you might need to specify them in the waveform mode as the phase alignment of the 3 * 200MHz clocks is important11:44
mithroacomodi: You probably also need the false path constraints11:45
mithroacomodi: create_clock -period 3 -waveform {1.25 2.75} clk11:45
sf-slack1<acomodi> mithro: I'll try that as well. I am also trying with max_delay/min_delays as well11:46
*** Bertl_zZ is now known as Bertl11:52
*** kraiskil has joined #symbiflow11:53
*** kraiskil has quit IRC11:54
*** kraiskil has joined #symbiflow11:54
mithroacomodi: Do you have the full xdc file?12:07
*** killruana has quit IRC12:14
*** killruana has joined #symbiflow12:17
*** Ultrasauce_ is now known as Ultrasauce12:20
*** freemint has quit IRC12:29
*** freemint has joined #symbiflow12:29
*** kraiskil has quit IRC12:32
sf-slack1<acomodi> @mithro: which one are you referring to?12:42
*** kraiskil has joined #symbiflow12:47
mithroacomodi: The XDC file you are using with vivado13:03
sf-slack1<acomodi> @mithro here it is
tpbTitle: # ## serial:0.tx #set_property LOC D10 [get_ports serial_tx] set_property IOST - (at
mithroacomodi: Why are the false paths commented out?13:09
mithroacomodi: Can you explain the pathway that vpr is using to get from an IO pin to the clock buffer via interconnect verse the path vivado takes?13:12
*** space_zealot has joined #symbiflow13:14
sf-slack1<acomodi> @mithro: this is the XDC in archdefs, the cells specified in there have different namings after fasm2bels13:16
sf-slack1<acomodi> mithro: regarding the pathway, basically the IOI_ILOGIC has the output that can be directed to two different locations: one is the general interconnect, and one gets to a clock resource that redirects the clock signal into the clock network.13:19
*** space_zealot_000 has joined #symbiflow13:19
sf-slack1<acomodi> VPR is not aware that the it is routing about which one of the two paths is the clock network, therefore it chooses the general interconnect path. Now, this is actually strange as the timing should be worse in case the clock gets through the general interconnect and the clock network should be the preferred path13:21
*** space_zealot has quit IRC13:23
mithroacomodi: Yes - but can you write it down for me somewhere?13:27
sf-slack1<acomodi> @mithro Sure13:27
*** somlo has quit IRC13:59
*** somlo has joined #symbiflow14:02
*** Bertl is now known as Bertl_oO14:23
-_whitenotifier-3- [ideas] tmichalak opened issue #40: Improve the visual representation of the placement done by VTR -
*** kraiskil has quit IRC14:37
mithroacomodi: Do you see my diagram in the doc now?14:42
sf-slack1<acomodi> @mithro Yes14:43
*** freemint has quit IRC14:45
*** freemint has joined #symbiflow14:45
mithroacomodi: Does the solution makes sense?14:51
mithroacomodi: What as the primitives inside an IOPAD anyway?14:56
*** somlo has quit IRC14:58
sf-slack1<acomodi> @mithro: So, I think that to apply this solution, we need to slightly modify the pb_type of the IOPAD, and add a new output that needs to be hooked to the correct path in the rr_graph.14:59
sf-slack1<acomodi> mithro: I am unsure still on how much effort would be required to do so15:01
*** somlo has joined #symbiflow15:06
litghostacomodi: That solution does not work, because the site does not connect to the dedicate path15:06
sf-slack1<acomodi> @litghost What if we can detach the dedicated path and the path to the general interconnect and assign each one to the corresponding site pin?15:08
litghostacomodi: That will require a lot of work, and it will require that synthesis emit a special subckt to force the packer to choose the specific exit we want15:09
litghostacomodi: I don't believe this course of action will be working for a while15:09
litghostacomodi: I suggest considering other options15:10
litghostacomodi: For example, using route_diag to determine why the router choose the interconnect path15:10
litghostacomodi: If criticality is the key, specific a low / mid / high criticality to route_diag, and example the router behavior in each15:11
*** kraiskil has joined #symbiflow15:16
*** space_zealot has joined #symbiflow15:34
*** space_zealot_000 has quit IRC15:38
-_whitenotifier-3- [symbiflow-arch-defs] litghost opened issue #1291: SDC/XDC create_clock and set_false_path constraints should propigate through Yosys -
*** yeti has joined #symbiflow16:05
*** az0re has joined #symbiflow16:16
*** citypw has quit IRC16:39
*** freemint has quit IRC17:33
*** freemint has joined #symbiflow17:33
*** piegames has joined #symbiflow17:42
*** kraiskil has quit IRC19:05
hackerfooI don't like preventing what should be valid because it's "bad" - the router should know why it is bad so that it can pick a good route.19:13
hackerfooIf the router wants to take the bad path, we're going to have to keep fighting it, like trying to push water uphill.19:15
hackerfooMaybe it's possible to calculate an upper bound for skew as the delay back to the first fanout from a source, which would be subtracting the delay up to the first fanout.19:24
litghosthackerfoo: It's worth noting that using the dedicated path vs direct shouldn't have a significant affect on modeled skew in VPR, because VPR lacks min/max delays on interconnect19:25
hackerfooAnything on the clock network should be near 0.19:25
litghosthackerfoo: So it's not clear if VPR could use that in this case19:25
litghosthackerfoo: Keep in mind this is from the CCIO clock to BUFG19:26
hackerfooIt would penalize early fanout as well.19:27
hackerfooThen after hitting the clock network without fanout, the skew would be near 0 throughout the network.19:28
hackerfooThe problem is that it might be expensive to track another delay to the first fanout, so it should be limited to clock nets.19:29
hackerfooThe justification for using this upper bound is that if two routes split right before one of them enters the clock network, the skew will be roughly the delay from that point to where they join again, assuming the clock network has much lower delay than general interconnect. It will be less accurate if they split earlier, but I don't think that will be a problem.19:38
*** freeemint has joined #symbiflow20:34
*** freemint has quit IRC20:35
*** freeemint has quit IRC20:40
*** freeemint has joined #symbiflow20:42
*** freemint has joined #symbiflow20:59
*** freeemint has quit IRC21:00
*** kraiskil has joined #symbiflow21:31
*** freemint has quit IRC22:38
*** az0re has quit IRC22:49
*** az0re has joined #symbiflow23:05

Generated by 2.13.1 by Marius Gedminas - find it at!