siriusfox has quit [Ping timeout: 265 seconds]
siriusfox has joined #symbiflow
Thalheim has joined #symbiflow
Bertl_oO is now known as Bertl_zZ
citypw has joined #symbiflow
unkraut has quit [Remote host closed the connection]
freemint has quit [Ping timeout: 248 seconds]
OmniMancer has joined #symbiflow
az0re has joined #symbiflow
citypw has quit [Quit: Leaving]
citypw_ has joined #symbiflow
citypw_ has quit [Remote host closed the connection]
sth0R__ has joined #symbiflow
sth0R__ has quit [Remote host closed the connection]
citypw has joined #symbiflow
proteus-guy has joined #symbiflow
tiwEllien has joined #symbiflow
rvalles_ has quit [Ping timeout: 260 seconds]
rvalles_ has joined #symbiflow
proteus-guy has quit [Ping timeout: 260 seconds]
az0re has quit [Remote host closed the connection]
freemint has joined #symbiflow
freemint has quit [Ping timeout: 245 seconds]
acomodi has quit [Quit: Connection closed for inactivity]
Bertl_zZ is now known as Bertl
OmniMancer has quit [Quit: Leaving.]
az0re has joined #symbiflow
tiwEllien has quit [Ping timeout: 265 seconds]
<mithro> acomodi: How goes the DDR work?
<sf-slack1> <acomodi> @mithro: I could get through fasm2bels, obtaining a bitstream, which unfortunately didn't work. We have though the design place and routed through Vivado as well
<sf-slack1> <acomodi> I might have an idea on why it still does not pass the memtest. The input IPAD related to the 100 MHz clock is still being routed through general interconnect instead of getting into the dedicated clock net through the CCIO pip
<sf-slack1> <acomodi> There also might be an issue with CI (https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/369). There is a build that is hanging
<tpb> Title: Sdcparser fix by acomodi · Pull Request #369 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)
siriusfox has quit [Ping timeout: 268 seconds]
<sf-slack1> <acomodi> That PR is adding the fix for the sdcparser to master+wip
<litghost> acomodi: I don't believe the CI hung, I believe a failure is causing log spam
<sf-slack1> <acomodi> @litghost The problem is finding what is causing that. Here I get a red CI instead https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1285, but I doubt the changes in that PR are causing that issue
<sf-slack1> <acomodi> The log in the last PR is actually pretty massive ~1.5 Gigs
<sf-slack1> <acomodi> BTW, I also get this warning from Vivado in fasm2bels
<sf-slack1> <acomodi> `WARNING: [DRC REQP-1580] Phase alignment: Unsupported clocking topology used for RIOI3_X43Y45_OLOGIC_X1Y46_OSERDESE2. This can result in corrupted data. The RIOI3_X43Y45_OLOGIC_X1Y46_OSERDESE2/CLK / RIOI3_X43Y45_OLOGIC_X1Y46_OSERDESE2/CLKDIV pins should be driven by the same source through the same buffer type or by a BUFIO / BUFR combination in order to have a proper phase relationship OSERDESE2. Please refer to
<sf-slack1> the Select I/O User Guide for supported clocking topologies of the chosen INTERFACE_TYPE mode.`
<litghost> "/tmpfs/src/github/symbiflow-arch-defs/utils/quiet_cmd.sh: line 9: 13120 Killed "$@" > $OUTPUT 2>&1"
<litghost> So OOM?
<sf-slack1> <acomodi> Apparently yes
<mithro> acomodi: What is the clock path into the serdes?
<sf-slack1> <acomodi> @mithro: IPAD (clk100) -> BUFG -> BUFHCE -> PLL -> BUFG -> BUFHCE -> SERDES
<mithro> acomodi: Where is the general interconnect being used?
<sf-slack1> <acomodi> IPAD -> BUFG
<mithro> acomodi: What does the pathway IPAD -> BUFG look like when Vivado does PnR?
<sf-slack1> <acomodi> @mithro: The output pin of the ILOGIC, instead of going through the interface and consequently to an INT tile, follows the IOI_I2GCLK_TOP, which ends up in a HCLK_CMT tile. From there it can get into the BUFG through the dedicated net
<mithro> acomodi: Does litghost's clock placer respect the "Table 2-1: Clock-Capable Input Placement Rules" table?
<litghost> mithro/acomodi: I believe the answer in this case is to artificially increase the criticality of the clock net
<sf-slack1> <acomodi> @mithro: Yes, the rules in the table are preserved
<mithro> acomodi: A CMT must be placed in the same clock region as the clock-capable input. <-- that is the important one
<mithro> Also -> When used as a differential clock input, the direct connection comes from the P-side of the differential input pin pair
<sf-slack1> <acomodi> @mithro: interesting actually, the minitest produces an implementation that goes against that rule. But I believe that it actually is sth like `it is highly suggested to do so` kind of rule.
<sf-slack1> <acomodi> What is a P-side?
<sf-slack1> <acomodi> litghost: how to achieve the increase of criticality of a net?
<litghost> acomodi: Initially? hack it up. Simplest answer: Provide an argument the net should have high/max criticality
<litghost> acomodi: Good long term answer: If a net sinks at a clock port, then it should have high/max criticality
<sf-slack1> <acomodi> @litghost Ok, I think the long term solution could be achieved in a reasonable amount of effort
<litghost> acomodi: ok
<litghost> The reason I was suggesting a fast path was to first verify if raising the criticality even did what we wanted
<sf-slack1> <acomodi> @litghost I'll start with the immediate hack to
<sf-slack1> <acomodi> @litghost Yes, in fact I want first to verify this could solve the issue
citypw has quit [Ping timeout: 240 seconds]
<mithro> acomodi: Where is the minitest?
<tpb> Title: prjxray/minitests/litex/min_ddr/arty/src.yosys at master · SymbiFlow/prjxray · GitHub (at github.com)
<sf-slack1> <acomodi> mithro: ^
<mithro> acomodi: Oh - it isn't part of arch-defs?
<sf-slack1> <acomodi> @mithro: No, the minitest created in xray was run and verilog + mem_init files are being used in arch-defs
<sf-slack1> <acomodi> But @tmichalak can confirm that
citypw has joined #symbiflow
<mithro> acomodi: So it looks like IPAD -> BUFG -> PLL is in the verilog
<mithro> acomodi: Is the BUFG location the same between vivado and VPR?
<sf-slack1> <acomodi> @mithro yes, exactly that one, I have actually locked all the clocking resources to use the correct locations manually
<sf-slack1> <acomodi> Without using the clock placer
<mithro> acomodi: Okay
<sf-slack1> <acomodi> mithro: I do believe though that this is a timing-related issue
<sf-slack1> <acomodi> By inspecting the dcp, there are some nets relative to the DDR that are routed vertically through three different clock regions
<sf-slack1> <tmichalak> @acomodi @mithro the mini_ddr test has been merged to prjxray but for arch-defs it still remains a PR.
<hackerfoo> Is the VTR nightly test borken? Every test result is -1 even with verilog-to-routing/master.
<litghost> hackerfoo: The QoR is out of date
<litghost> But that's it
<tpb> Title: Adding the kokoro CI configuration. by litghost · Pull Request #1082 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
<hackerfoo> It's seems the perl scripts are broken, because the output from VPR looks normal, with no "-1"'s.
<litghost> Context?
<hackerfoo> litghost: This fails on my machine, and I can't make it not fail: ./run_reg_test.pl vtr_reg_nightly -show_failures
<litghost> At the end it should report "run failures" if any, and "QoR" failures, which we expect some of
<litghost> Because the QoR is out of date
<hackerfoo> I got the same thing in CI here: https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/366
<tpb> Title: Disable high fanout routing when nearly done routing by HackerFoo · Pull Request #366 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)
<litghost> Ya, it fails because of 5 QoR failures
<litghost> Go look at the end of the log file
<hackerfoo> Ah okay. On my machine I get something different.
<hackerfoo> As long as it's expected, I guess.
<litghost> The CI failure seems consistent, and should be fixed upstream
Seraxis has joined #symbiflow
az0re has quit [Quit: Leaving]
Bertl is now known as Bertl_oO
Seraxis has quit [Quit: おやすみ]
Seraxis has joined #symbiflow
Seraxis has quit [Quit: おやすみ]
Seraxis has joined #symbiflow
Seraxis has quit [Remote host closed the connection]
Seraxis has joined #symbiflow
freemint has joined #symbiflow
freemint has quit [Ping timeout: 265 seconds]
tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow