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