03:43 <hackerfoo> A 96-core box computes lookahead really fast.

09:15 <_whitenotifier-3> [sv-tests] towoe opened issue #597: Contribution guide - https://git.io/Jv3Te

10:46 <sf-slack1> <acomodi> mithro, litghost: updated timing report from Vivado after constraining the clock: https://filebin.net/ptwm4nla8k1gdm7r

10:46 <tpb> Title: Filebin :: bin ptwm4nla8k1gdm7r (at filebin.net)

10:48 <sf-slack1> <acomodi> We got ~1300 setup violation for the main system clock and 2 hold violation for the same clock

11:33 <mithro> acomodi: Well that isn't going to work :-P

11:36 <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 <mithro> acomodi: So what SDC file are you giving to vpr?

11:37 <mithro> https://www.irccloud.com/pastebin/U7cwNjy8/

11:37 <tpb> Title: Snippet | IRCCloud (at www.irccloud.com)

11:40 <sf-slack1> <acomodi> mithro: this one https://pastebin.com/CbcS8CVs

11:40 <tpb> Title: create_clock -period 5 sys4x_clk__main_clkout_buf1 create_clock -period 5 sys4x - Pastebin.com (at pastebin.com)

11:42 <mithro> acomodi: So you might need to specify them in the waveform mode as the phase alignment of the 3 * 200MHz clocks is important

11:43 <mithro> acomodi: You probably also need the false path constraints

11:44 <mithro> acomodi: create_clock -period 3 -waveform {1.25 2.75} clk

11:44 <sf-slack1> <acomodi> mithro: I'll try that as well. I am also trying with max_delay/min_delays as well

12:05 <mithro> acomodi: Do you have the full xdc file?

12:40 <sf-slack1> <acomodi> @mithro: which one are you referring to?

13:02 <mithro> acomodi: The XDC file you are using with vivado

13:04 <sf-slack1> <acomodi> @mithro here it is https://pastebin.com/TA2GTWBA

13:04 <tpb> Title: # ## serial:0.tx #set_property LOC D10 [get_ports serial_tx] set_property IOST - Pastebin.com (at pastebin.com)

13:08 <mithro> acomodi: Why are the false paths commented out?

13:10 <mithro> acomodi: 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:15 <sf-slack1> <acomodi> @mithro: this is the XDC in archdefs, the cells specified in there have different namings after fasm2bels

13:18 <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:20 <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 path

13:25 <mithro> acomodi: Yes - but can you write it down for me somewhere?

13:26 <sf-slack1> <acomodi> @mithro Sure

14:24 <_whitenotifier-3> [ideas] tmichalak opened issue #40: Improve the visual representation of the placement done by VTR - https://git.io/Jv33z

14:40 <mithro> acomodi: Do you see my diagram in the doc now?

14:41 <sf-slack1> <acomodi> @mithro Yes

14:50 <mithro> acomodi: Does the solution makes sense?

14:54 <mithro> acomodi: What as the primitives inside an IOPAD anyway?

14: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.

15:00 <sf-slack1> <acomodi> mithro: I am unsure still on how much effort would be required to do so

15:05 <litghost> acomodi: That solution does not work, because the site does not connect to the dedicate path

15: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 <litghost> acomodi: 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 want

15:08 <litghost> acomodi: I don't believe this course of action will be working for a while

15:08 <litghost> acomodi: I suggest considering other options

15:09 <litghost> acomodi: For example, using route_diag to determine why the router choose the interconnect path

15:09 <litghost> acomodi: If criticality is the key, specific a low / mid / high criticality to route_diag, and example the router behavior in each

15:44 <_whitenotifier-3> [symbiflow-arch-defs] litghost opened issue #1291: SDC/XDC create_clock and set_false_path constraints should propigate through Yosys - https://git.io/Jv3ZJ

19:12 <hackerfoo> I 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 <hackerfoo> If the router wants to take the bad path, we're going to have to keep fighting it, like trying to push water uphill.

19:23 <hackerfoo> Maybe 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 <litghost> hackerfoo: 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 interconnect

19:24 <hackerfoo> Anything on the clock network should be near 0.

19:24 <litghost> hackerfoo: So it's not clear if VPR could use that in this case

19:24 <litghost> hackerfoo: Keep in mind this is from the CCIO clock to BUFG

19:25 <hackerfoo> It would penalize early fanout as well.

19:26 <hackerfoo> Then after hitting the clock network without fanout, the skew would be near 0 throughout the network.

19:28 <hackerfoo> The problem is that it might be expensive to track another delay to the first fanout, so it should be limited to clock nets.

19:37 <hackerfoo> The 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.