show1 has quit [Ping timeout: 265 seconds]
eightdot has quit [Ping timeout: 265 seconds]
anticw has quit [Ping timeout: 256 seconds]
anticw has joined ##openfpga
eightdot has joined ##openfpga
show1 has joined ##openfpga
Degi has quit [Ping timeout: 256 seconds]
Degi has joined ##openfpga
gregdavill has quit [Remote host closed the connection]
gregdavill has joined ##openfpga
gregdavill has quit [Remote host closed the connection]
gregdavill has joined ##openfpga
Bike has quit [Quit: Lost terminal]
emeb has quit [Quit: Leaving.]
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 240 seconds]
OmniMancer1 has joined ##openfpga
OmniMancer has quit [Ping timeout: 264 seconds]
OmniMancer has joined ##openfpga
OmniMancer1 has quit [Ping timeout: 240 seconds]
emeb_mac has quit [Quit: Leaving.]
OmniMancer has quit [Read error: Connection reset by peer]
OmniMancer has joined ##openfpga
<azonenberg> daveshah: ping
<daveshah> pong
<azonenberg> How familiar are you with the 7 series i/o cells?
<daveshah> Not that familiar, mwk is probably a better person to talk to
<azonenberg> mwk: ok, are you around then? :p
<azonenberg> I'm running into a really weird problem routing what should be a straightforward i/o structure in vivado
<azonenberg> wondering if there's something subtle about the io cell that makes this not work
<azonenberg> tl;dr a bidirectional i/o using the OLOGIC FF
<azonenberg> the output from the IOBUF (O pin, to fabric) is reporting unroutable
<azonenberg> Or at least it's supposed to be using the OLOGIC FF because I set the IOB constraint
<daveshah> I don't remember seeing anything like that whilst poking Ultrascale IO
<azonenberg> post P&R netlist is showing a FDRE cell
<daveshah> But I don't know the 7 series enough in detail
<azonenberg> But... oh ok that's fine, it's placed at OLOGIC_X1Y64
<azonenberg> so it is an iob flop
<azonenberg> i've done bidirectional io plenty of times, although i can't recall using iob ff's when doing so
<azonenberg> and never had such a problem
<mwk> azonenberg: what's the T connected to?
<azonenberg> mwk: EMIO GPIO on the PS
<azonenberg> this is a mux for switching a signal between a test-mode input and normal-mode output
<azonenberg> output is timing critical with an iob ff, input is going to another EMIO GPIO
<mwk> I'm not that famliar with 7series IO, but my guess would be that it needs to be registered as well
<azonenberg> You think i need to register the input if i use the output pad ff?
<mwk> no
<mwk> register the tristate enable
<azonenberg> oh register the T
<azonenberg> why is it failing to route O/
<azonenberg> ?
<azonenberg> I and T are working fine
<azonenberg> O shows "routable but not routed"
<daveshah> Sometimes Vivado can do odd things when it doesn't like a site configuration
<daveshah> So the T might really be the problem and Vivado is just in a mess
<azonenberg> Yes. That's why i'm asking the folks who know more about xilinx low level than anybody outside xilinx :p
<mwk> one moment
<mwk> what chip is that? and what I/O kind?
<mwk> (ie. HP or HR)
<azonenberg> 7z020, only has HP
<azonenberg> HR*
<mwk> hmm
<mwk> ohhh damn stupid thing
<mwk> of course the signal names are reversed on the IOB and I'm looking at the wrong pin
<mwk> so it's failing to route the *input* path, okay
<azonenberg> veeery interesting
<azonenberg> So implementation completed with failed nets after registering T
<azonenberg> i.e. it didnt change a thing
<azonenberg> and yes this is why i have my own BidirectionalBuffer wrapper lol
<mwk> yeah right, I just... misread the error
<azonenberg> it has ports named "fabric_in", "fabric_out", "pad", and "oe"
<azonenberg> and also takes a width parameter with a generate loop for multi-bit buses
<mwk> so what's instantiated around the iob?
<mwk> as I understand it, you have an IOBUF + a FDRE
<azonenberg> output side: fabric logic -> OLOGIC FF -> pad
<azonenberg> input side: pad -> EMIO GPIO
<mwk> how are you selecting IOB placement?
<mwk> er
<azonenberg> select: EMIO GPIO -> FF registered by the same clock as the OLOGIC FF -> pad
<mwk> how are you forcing the FF to be in the IOI?
<azonenberg> I'm applying the IOB constraint to the ff by net name
<azonenberg> in the xdc
<mwk> by what net name?
<azonenberg> genblk3[*].ecb_tx_bus_muxed_reg[*][*]
<azonenberg> which is each of the four buses, all bits in each field (it's a sv struct)
<mwk> nut which net is it?
<azonenberg> i dont understand what you mean
<mwk> the IOBUF's pad? I?
<azonenberg> oh
<azonenberg> It's the FF
<mwk> ...
<mwk> you just said you're applying the constraint to a *net* not a cell
<azonenberg> well the ff's output
<azonenberg> actually wait
<mwk> so the IOBUF's I?
<azonenberg> let me see, i use get_cells
<azonenberg> so no i apply it to the FDRE itself
<azonenberg> looking at the post P&R netlist i confirm the FDRE is placed in the OLOGIC site
<mwk> this really doesn't make sense...
<mwk> I mean, sure, the O pin is not routable, as in not connected to general interconnect
<azonenberg> wait it's not?
<azonenberg> what does O go to then?
<azonenberg> its a pad driver, its sole purpose is to connect to general interconnect??
<mwk> but vivado should know to insert the necessary ILOGIC
<mwk> no, the IOB is the bare buffer
<azonenberg> So there's no route around the ILOGIC if you arent using any ffs, iddr, etc?
<mwk> the I/O/T pins are dedicated connections only routable to the ILOGIC/OLOGIC/IODELAY blocks
<daveshah> There's a route through pip through the ILOGIC
<mwk> but the ILOGIC has an output that is just the bypassed combinatorial value
<daveshah> That configures it in route through mode
<mwk> and vivado should know to insert ILOGIC if O is not connected to something where the direct path can be used
<mwk> so seems it's going wrong in packing
<daveshah> There's no ILOGIC route through insertion in Vivado, afaik
<daveshah> It relies on the route through pip
<mwk> *shrug* same thing, different name
<daveshah> I don't think it is a packing problem though
<daveshah> What is going on though, god knows
<daveshah> Maybe it thinks the route through pip is unavailable because the ologic is used
<azonenberg> I'm going to see if i can force inference of an ilogic by adding an input ff
<azonenberg> and constrain that to be in the ilogic
<azonenberg> if nothign else it should shed some light on the problem
<azonenberg> if that doesnt work, customer is ready to give up and just use a separate bitstream for test mode :p
<azonenberg> we really wanted to do this all in one firmware if possible
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 240 seconds]
<azonenberg> daveshah, mwk: ok i am even more confused now
<mwk> the what
<azonenberg> it's failing to route the path from the INBUF_EN's OUT pin
<azonenberg> ... to the ILOGIC's D pin
<mwk> is pin cursed
<azonenberg> this happens to the entire 5-bit bus
<azonenberg> i just have everything but this one commented out for testing
<azonenberg> sooo yeah. when you can fail to make an input buffer route, you're having a reeeally special day
Asu has joined ##openfpga
mumptai has joined ##openfpga
<mwk> ... restart machine, reinstall vivado?
<mwk> I mean uh, last time I've seen errors that made this little sense, my SSD was literally lying to me
<azonenberg> well this has happened across two vivado versions
<azonenberg> it happened months ago and i tabled the test feature to work on other parts of the firmware
<azonenberg> on 2019.2 same thing
<mwk> ... crap.
<daveshah> The ILOGIC is being placed correctly, right?
<azonenberg> Yes
<azonenberg> and it's failing to route
<azonenberg> i give up, i'm just goign to make the test code a different firmware
<daveshah> Does report_drc give you anything other than the failure to route?
<azonenberg> Nothing useful
<azonenberg> i don't have more time to spend debugging this
<daveshah> Yeah, just burn it :)
<daveshah> Much too cursed
Jybz has joined ##openfpga
Jybz has quit [Client Quit]
Jybz has joined ##openfpga
mumptai_ has quit [Quit: Verlassend]
Jybz has quit [Ping timeout: 272 seconds]
_whitelogger has joined ##openfpga
____2 has joined ##openfpga
____ has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Ping timeout: 240 seconds]
gregdavill has quit [Ping timeout: 256 seconds]
Bike has joined ##openfpga
____2 has quit [Quit: Nettalk6 - www.ntalk.de]
____ has joined ##openfpga
____ has quit [Read error: Connection reset by peer]
emeb has joined ##openfpga
_franck_9 has joined ##openfpga
_franck_ has quit [Ping timeout: 256 seconds]
OmniMancer has quit [Quit: Leaving.]
<anuejn> does anyone know how much current the VCCHTX, VCCHRX and VCCA rails on an ecp5-5G need?
<anuejn> and if it is safe to connect them all on to ldo?
<anuejn> s/to/one/
_franck_9 is now known as _franck_
genii_ has joined ##openfpga
genii_ is now known as genii
<ZirconiumX> It'd be nice if the open tooling had something equivalent to Quartus' timing closure recommendations
<ZirconiumX> ...Although the recommendations are...not the best
<ZirconiumX> "Reduce the levels of combinational logic for the path from r_nbk[33] to dirgolem:dirgolem|check_from_diag[19]"
<ZirconiumX> Yeah, but how?
<lambda> ZirconiumX: yeah, I missed those too when going from quartus to vivado, but as I learned more about FPGAs and how they work, the recommendations became less and less useful. mostly "look at the critical paths" like in your example or "improve something else so this can be routed better" (paraphrasing).
rohitksingh has joined ##openfpga
CounterPillow has quit [Remote host closed the connection]
Maylay has quit [Ping timeout: 265 seconds]
CounterPillow has joined ##openfpga
Maylay has joined ##openfpga
dh73 has joined ##openfpga
<ZirconiumX> lambda: I ended up building a spreadsheet of terms that depend on previous terms to get an idea of where to pipeline stuff
mumptai has quit [Quit: Verlassend]
dh73 has quit [Read error: Connection reset by peer]
Asu has quit [Remote host closed the connection]
gregdavill has joined ##openfpga
Richard_Simmons has quit [Remote host closed the connection]
Richard_Simmons has joined ##openfpga