<_whitenotifier-1>
[Glasgow] marcan commented on pull request #120: revC1: add io port pinout to back silkscreen - https://git.io/fjLmO
zkms has joined #glasgow
<whitequark>
hey, does anyone want to debug a horrible USB issue?
<ZirconiumX>
Is this "horrible because of USB", or "horrible, and USB"
<whitequark>
i'm not sure
<whitequark>
so in the benchmark applet, i have a loopback benchmark
<whitequark>
the gateware just mirrors everything it sees
<whitequark>
and well, everything's good except the last few IN BULK packets appear to never arrive
<whitequark>
the thing is, i can see (by adding a register) that the gateware has written everything into the FX2
<whitequark>
but wireshark doesn't show me those BULK IN URBs as finishing...
<ZirconiumX>
<dumb>What's the FX2?</dumb>
* ZirconiumX
has no idea what it is
<whitequark>
Cypress CY7C68013A
<ZirconiumX>
Is it just a USB interface?
<whitequark>
yes
<marcan>
whitequark: is this a ZLP issue?
<whitequark>
marcan: hm
<marcan>
if you want me to slap an openvizsla in front I can tell you whether it's a ZLP issue :p
<whitequark>
marcan: i do want you to slap an openvizsla in front
<whitequark>
repro is to run `glasgow run benchmark loopback` repeatedly
<whitequark>
about 1/5 attempts hangs
<marcan>
kk
<whitequark>
the FPGA insists it submitted all data, wireshark insists it never received the last... 3..15 packets?
<whitequark>
and i've compared the received data to the expected data, i don't see any discrepancies other than the tail missing
<whitequark>
so it's not *skipped* chunks
<tnt>
whitequark: do you have a USB analyzer ?
<whitequark>
tnt: nope
<whitequark>
that's the problem
<tnt>
whitequark: if you're interested I can probably get you an openviszla.
<tnt>
but for now I'll try to reproduce the issue here and dump the bus traffic at least.
<whitequark>
tnt: I think an openviszla would help, yes
<marcan>
lol I'm so bottlenecked on the OV
<marcan>
thankfully it has a big fat SDRAM for buffering
<marcan>
but I get to wait until all the data gets parsed :p
<marcan>
whitequark: 8 attempts so far and no hang
<whitequark>
marcan: try -c 131072
<marcan>
ah, that should help
<marcan>
repro'd
<marcan>
whitequark: packet is 512 bytes and has no ZLP after it, I see the last data written coming back.
<marcan>
ZLP issue, pretty sure
<marcan>
you need to either figure out a way to make it issue ZLPs to flush data, or submit 512-byte URBs only (which is a performance problem)
<whitequark>
marcan: wait what
<whitequark>
*what*
<whitequark>
oh
<whitequark>
ohhhhh
<whitequark>
oh my fucking GOD
<whitequark>
AAAAAAAAAAAAAA
<whitequark>
marcan: i haven't realized previously i could hate USB any more, but here we go.
<marcan>
lolol.
<marcan>
so if you know how much data you're *expecting* you can just submit URBs using that
<marcan>
but if you *don't* then you need ZLPs.
<whitequark>
yeah, this explains why redoing the pipelining broke it
<whitequark>
I think I can make the FX2 submit ZLPs
<marcan>
the only issue with ZLPs is that they reduce performance of course, so you need to either do a timeout thing or have an explicit flush signal that isn't spuriously asserted too much or whatever
<whitequark>
I have an explicit flush signal, that gets spuriously asserted too much
<whitequark>
sigh
<marcan>
lol
<marcan>
IN xfers are 8K, 512 byte packets, last n..15 packets getting stuck in an incomplete URB sounds about right
<whitequark>
why does USB suck so hard.
<marcan>
to be fair this is kind of a difficult problem, for anything
<marcan>
you have a stream of bytes on one end and a stream of packets on the other
<marcan>
doing that always sucks
<whitequark>
well ok, fair
<whitequark>
so, hm
<marcan>
the way FTDI handles this is by... always returning data.
<marcan>
their shitty status bytes.
<whitequark>
...
<marcan>
they do have a timeout flush thing, but that's just for the internal buffers inside the FIFO
<marcan>
(as well as a way of explicitly flushing)
<whitequark>
ok so i have _ZEROLENIN enabled in the FX2
<whitequark>
that means that I can assert PKTEND and that will send a ZLP
<whitequark>
... assuming the FX2-side buffer is empty in the first place
<whitequark>
FX2 *also* has enabled the AUTOIN feature, where it autosubmits a packet once it reaches 512 bytes
<whitequark>
so the FPGA isn't aware of the packet boundaries directly, only of flags
<marcan>
right
<marcan>
I think you just need a PKTEND every time you need to force a flush to the host
<whitequark>
what if the flush flag is permanently asserted?
<marcan>
PKTEND?
<whitequark>
no, flush flag, inside the FPGA
<marcan>
oh
<marcan>
well I dunno :p
<whitequark>
so I have a "streaming mode" where the FPGA never automatically commits a packet smaller than 512 bytes
<whitequark>
and a ... whatever is the inverse of that
<whitequark>
where the FPGA commits a packet each time it empties the FIFO
<whitequark>
oh
<whitequark>
do I need *two* PKTEND pulses each time?
<marcan>
I don't think so
<marcan>
because it should auto commit at 512 bytes
<marcan>
so an additional pktend pulse should add the ZLP
<marcan>
... unless you have a pipelining issue where the pktend is asserted *at the same time* as the autocommit and it only commits once
<marcan>
also the ZLP takes up an extra buffer so if the FIFO is full it won't work I think?
<marcan>
(e.g. if you just filled it)
<whitequark>
yes, exactly
<whitequark>
what I mean by two PKTEND pulses is
<whitequark>
let's say I have 100 bytes in the FIFO
<whitequark>
I just put them into FX2
<whitequark>
my FIFO is empty and flush flag is active, so I pulse PKTEND
<whitequark>
that sends a 100 byte packet
<whitequark>
now I need to pulse PKTEND *again* to send the ZLP
<marcan>
you don't need a ZLP
<marcan>
you only need a ZLP after a 512 byte packet
<marcan>
any packet <512 bytes will terminate the URB
<whitequark>
marcan: ohhh
* whitequark
stares harder at the arbiter
<whitequark>
I Do Not Like I
<whitequark>
*It
<ZirconiumX>
...Sam-I-Am?
<whitequark>
marcan: do I understand it correctly that
<whitequark>
well, right now I have an edge case where I sent 511-byte packages to avoid hangs
<whitequark>
so if I have a 1M URB, that will terminate it right away?
<marcan>
yes
<whitequark>
so I guess the only reasonable solution is to add a counter FPGA side that would let it know how full the FX2 side IN FIFO is.
<marcan>
if you can accurately keep track of packet sizes from the FPGA, that will let you be a lot smarter about it, yes
<whitequark>
the other reason that counter simplifies things is that well
<whitequark>
right now the input from FX2 is latched on negedge
<whitequark>
and not re-registered
<whitequark>
this makes timing analysis very unhappy
<whitequark>
well, it correctly infers that the Fmax is about half of what it should be
<whitequark>
so if I *do* re-register stuff that makes the edge cases worse
<whitequark>
because there's no way for me to know that the FIFO I have writes pipelined into is already full, until I've already removed those entries from the buffer
<gruetzkopf>
ERROR: Max frequency for clock 'por_clk': 19.50 MHz (FAIL at 30.00 MHz)
<gruetzkopf>
Info: Max delay <async> -> posedge por_clk: 6.58 ns
<gruetzkopf>
i can't even get it to build a bitstream
<whitequark>
comment line 67 in target/hardware.py
<gruetzkopf>
ok
<whitequark>
marcan: tnt: so here's a problem I see with OUT packets
<whitequark>
the FX2 indicates the end of an OUT packet by deasserting a flag
<whitequark>
I indicate reading from the OUT FIFO by asserting SLWR
<whitequark>
if the flag is registered twice, there could be a situation where FX2 deasserts the flag, two cycles later I deassert SLWR, but one cycle later FX2 asserts the flag again
<whitequark>
oh yeah that's because i told you to disable the timings check and it probably doesn't actually work
<whitequark>
let's get this fixed properly
<gruetzkopf>
whoops
<gruetzkopf>
sorry for always having the most cursed hardware
<gruetzkopf>
(in other news i borrowed the uncooperative tb card)
<whitequark>
i mean, it's definitely useful
<whitequark>
even if it IS a problem with the board, knowing how to narrow it down is immensely useful
<gruetzkopf>
(the glasgow is still connected to the slow amd box, but connecting you to my vpn may be a better idea than the portforward)
<whitequark>
gruetzkopf: i have a wireguard setup here
<gruetzkopf>
okay, perfect
<gruetzkopf>
if 172.20.239.80 doesn't collide for you you can route just that
<whitequark>
doens't collide
<whitequark>
gruetzkopf: what address should i pick?
<gruetzkopf>
you *should* be able to throw that onto an existing if as long as you tell me your ip, otherwise .81
<gruetzkopf>
in the latter case, proper netmask on that is /26
<whitequark>
gruetzkopf: my ip is dynamic
<gruetzkopf>
sure, no problem
<gruetzkopf>
"Endpoint" is entirely optional
<marcan>
whitequark: oh, another revC1 thing. we never did put the final resistor pack values into the docs
<marcan>
the inline ones
<whitequark>
yeah
<whitequark>
what -is- the final value
<marcan>
do we have one? :D
<whitequark>
i have no idea
<marcan>
greg used 33Ω on both sides of the shifters
<whitequark>
yeah, just measured them
<marcan>
I guess 33Ω is 100mA at 3.3V
<marcan>
which sounds reasonable since that's the global current limit for the whole port anyway
<marcan>
whitequark: fpga side could probably be way higher, 8mA is 400 ohms
<marcan>
but I guess that means adding another part to the BOM
<whitequark>
mhm
<marcan>
whitequark: lol so I was talking to someone about this
<marcan>
and, yeah, about that "8mA" current limit on the FPGA
<marcan>
my multimeter says more like 50mA
<whitequark>
nice
<gruetzkopf>
at least they're not AVR port drivers
<gruetzkopf>
which are "it will win against your supply rail"
<whitequark>
wait what
<daveshah>
I'm pretty sure it's 8mA where some given output voltage is guaranteed (LVCMOS or whatever)
<gruetzkopf>
i've NEVER killed an AVR io
<whitequark>
oh yeah
<whitequark>
i've killed one once, i think
<whitequark>
charging a very large MOSFET gate directly
<gruetzkopf>
not even by shorting it to VCC and driving it to ground for MONTHS
<whitequark>
why would you do that
<marcan>
daveshah: yeah, 8mA for 200mV offset or whatever
<gruetzkopf>
eeh was a perfboard fuckup
<whitequark>
ah
<marcan>
whitequark: I'll put them down as 33Ω, but I'm going to wait for a response on that silkscreen thing or time out if it's not done by the weekend and do it myself
<marcan>
because I kind of want to get C1 finalized this weekend
<whitequark>
sounds good
<whitequark>
feel free to fix the silkscreen yourself right away if you have time
<_whitenotifier-1>
[Glasgow] electroniceel commented on pull request #120: revC1: add io port pinout to back silkscreen - https://git.io/fjLsG
<marcan>
whitequark: there seems to be more interchangeability in the package for the SP7538PUTG though. RCLAMP7528T ESDLC5V0PB8 824014885 all look like package-compatible.
<whitequark>
hmm
<marcan>
looks like the esd7008 is our only option if we go with that package
<marcan>
now tell me how those aren't the same chip with different pinout/application diagrams and suitable use of "NC pins that should have no connection"
<marcan>
anyway, off to sleep, but that's funny. they're selling the same chip with 3 different pinouts under 3 different part numbers, lol.
<Hellsenberg>
lovely
<_whitenotifier-1>
[Glasgow] marcan commented on pull request #120: revC1: add io port pinout to back silkscreen - https://git.io/fjLs6
<_whitenotifier-1>
[Glasgow] whitequark commented on pull request #120: revC1: add io port pinout to back silkscreen - https://git.io/fjLsi
<davidc__>
marcan/whitequark: maybe consider adding I2C testpads to the top of the board too? (given that all the connectors are facing to the top, it might be useful to have them on the topside for test fixtures)
<marcan>
we have those already
<davidc__>
Ok, cool. I saw the labelled testpads on the bottom, wasn't sure if there were matching ones on top
<marcan>
actually what we don't have on top is GND, but the screw holes are GND
<davidc__>
Also, consider filling the "serial no" box in with white silkscreen
<marcan>
good point
<davidc__>
that way you can write on a serial number with black fine sharpie for short prod runs
<whitequark>
the serial is kind of really long
<marcan>
the usb one anyway
<whitequark>
that's the same serial
<marcan>
right
<marcan>
could make the box a bit bigger too
<marcan>
anyway, nn :)
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+1/-1/±4] https://git.io/fjLZd