genii has quit [Quit: Morning comes early.... GO LEAFS GO!]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Degi has quit [Ping timeout: 260 seconds]
Degi has joined ##openfpga
rohitksingh has joined ##openfpga
ZipCPU has joined ##openfpga
____ has joined ##openfpga
Bike has quit [Quit: Lost terminal]
lutsabound has quit [Quit: Connection closed for inactivity]
mumptai has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
OmniMancer has joined ##openfpga
Cerpin has quit [Ping timeout: 260 seconds]
m4ssi has joined ##openfpga
rohitksingh has quit [Ping timeout: 240 seconds]
Asu has joined ##openfpga
mumptai has quit [Quit: Verlassend]
MicroHex has quit [Ping timeout: 240 seconds]
MicroHex has joined ##openfpga
keesj has quit [Ping timeout: 272 seconds]
keesj has joined ##openfpga
<mwk>
daveshah: hey, so... I implemented the dedicated GND/VCC sources in my s6 nextpnr backend, and it... made my design unroutable
<mwk>
as it turns out, the dedicated GND can only be connected to a subset of LOGICIN wires
<mwk>
if you want to use it for a wire that doesn't have a dedicated connection, you have to bounce around using LOGICIN* -> LOGICIN* pips
<mwk>
and if this particular site has enough pins connected, there may just not exist a valid path that doesn't trample on another actually-used pin
<mwk>
turns out this tends to happen for distributed RAMs that have address bits tied to 0...
<mwk>
have you seen anything like that on series7? any ideas?
<daveshah>
Nope, hasn't seen that
<daveshah>
*haven't
<daveshah>
UltraScale+ has almost no dedicated grounds at all, and just uses unused LUTs as 0 drivers, FWIW
<mwk>
does it still have dedicated vcc?
<daveshah>
Well, notionally (of course it is really just a case of setting nothing in the bitstream)
<mwk>
right
<mwk>
ok
<daveshah>
There are a few dedicated grounds in some of the clock tiles that can be accessed by convoluted routing, but not really very useful
<mwk>
perfect
<daveshah>
Vivado almost always if not always uses unused LUTs for ground
<mwk>
s6, otoh, gives you both the "default 1" vcc, and an *actual* dedicated vcc
<daveshah>
ECP5 seems a bit like that too
<mwk>
there are actual pins that have pips from both
<mwk>
so... any suggestions on how to deal with this mess? I imagine I could add a fake pip from the global 0 network to the LUT output pin for every LUT
<mwk>
but I'd have to somehow ensure it's only used if the LUT is not in use?
<daveshah>
For now for UltraScale+ I just do it for the A lut to keep things simple
<daveshah>
then a validity check to lock out the pip
<mwk>
yeah, ISE just sources ground from a LUT as well when it fails to route from the dedicated source
<mwk>
also, wtf is going on in the s6 switchbox
<mwk>
a lot of LOGICINs have a redundant-seeming pip from VCC_WIRE (despite already having a pip from KEEP1_WIRE)
<mwk>
it seems the whole thing could be significantly improved just by changing them over to GND_WIRE
<daveshah>
KEEP1_WIRE being explicit and VCC_WIRE being implicit?
<mwk>
no
<mwk>
KEEP1_WIRE is the implicit one (all-0 bits)
<daveshah>
Ah, VCC_WIRE is all-0 for ultrascale
<mwk>
does it also have two different VCC wires?
<daveshah>
No
<mwk>
er, well, const-1 wires I suppose
<mwk>
great, some sanity
<daveshah>
It also doesn't have tie primitives like xc7 had
<daveshah>
just wires
<mwk>
I suppose that's just a different representation of the same thing
<mwk>
probably xc7 had those since it had to be supported by ISE
<daveshah>
Indeed
<daveshah>
Don't know if other devices also do this, but it has several so-called "ground" wires which don't actually exist but are just there to keep a regular tile structure (but have no pips on/off them etc)
<mwk>
I think I saw something like that on another xilinx family
<mwk>
I don't remember which one
<mwk>
(could be s6 even)
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
m4ssi has quit [Remote host closed the connection]
mumptai has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 260 seconds]
<kc8apf>
Received a full Max EPM7128S + Flex EPF10K20 dev board w/ all the programming cables, software, documentation, and license dongle
rohitksingh has joined ##openfpga
<miek>
ooh, nice. i'd be interested to know more about the Flex - i've been reversing a thermal camera that's full of Flex 10K & 8K parts
_whitelogger has joined ##openfpga
stefanct has quit [Ping timeout: 246 seconds]
zyp has joined ##openfpga
emeb_mac has joined ##openfpga
<tnt>
So I'm tryint to build a litex design that has DDR and it fails with "ERROR: IOLOGIC 'TRELLIS_IO_1$IOL' has conflicting ECLKs 'IDDRX2DQA.ECLK$const' and 'TSHX2DQA.ECLK$const'"
stefanct has joined ##openfpga
<tnt>
But I would expect litedram to ... well have a valid working PHY so I find that error a bit suspitious.
<daveshah>
Sounds like the edge clocks are ending up at constants
<daveshah>
My guess is that the PLL has gone missing
<mwk>
heh
<mwk>
and nextpnr doesn't notice the two consts are the same.... /me had the same bug >_>
<mwk>
(not that the DDR register is going to work well with a const clock, but it's still a bug)
<daveshah>
Yeah, looks like edge clock promotion is happening before constants are merged
<cr1901_modern>
same constant, different net?
<mwk>
yep
<cr1901_modern>
and presumably nextpnr bombs if it notices the two ECLKs aren't the same net (Idk how DDR works that well)
<cr1901_modern>
?*
<daveshah>
Each IOLOGIC can only have one edge clock
<mwk>
I don't know how ECP5 works, but the problem I had was that the output DDR clock was != input DDR clock
<mwk>
presumably a similar issue here
<daveshah>
Almost exactly the same
<tnt>
indeed looks like in the verilog the sys2x_clk signal is not driven ...
<daveshah>
In this case, conflicting input and tristate DDR clocks
<cr1901_modern>
This might be a silly question, but why is there even an option in the first place to drive the IDDR and TSHX pin with two different clocks?
<mwk>
because they are separate primitives
<mwk>
so if you connect a 0 to the ECLK pin in both, they are processed separately, and get separate const nets
<cr1901_modern>
Ahhh, hmmm...
<tnt>
cr1901_modern: in the ECP5 the IO stuff is no complex that instead of 1 primitive with 1000s options, it's split in several primitives than you can combine ... but not all combinations are valid.
<mwk>
not just ECP5, that's exactly how xilinx works as well
<cr1901_modern>
Same w/ machxo2, now that I think about it
<mwk>
it took me a *long* time to exactly how tf the spartan6 io tile works
<daveshah>
UltraScale finally introduces a documented combined primitive
<cr1901_modern>
(well, everything except the embedded function block, which is hell)
<mwk>
(and I'm still hazy on the details)
<daveshah>
(BITSLICE_RX_TX)
<cr1901_modern>
mwk: Anyways, thanks for the details... I'm gonna need info like that soon lol
adamgreig is now known as adamgreig_
adamgreig_ is now known as adamgreig
Jybz has quit [Quit: Konversation terminated!]
<zyp>
is this a suitable place to discuss a nextpnr segfault?
<mwk>
sure
rohitksingh has quit [Ping timeout: 248 seconds]
<zyp>
it's segfaulting when I'm trying to open a json file in the gui, here's the relevant excerpt from macos' crash report: https://paste.jvnv.net/view/X4poF