whitequark changed the topic of #glasgow to: glasgow debug tool · code https://github.com/GlasgowEmbedded/Glasgow · logs https://freenode.irclog.whitequark.org/glasgow
gruetzkopf has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
gruetzkopf has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
Guest87205 has joined #glasgow
uberushaximus has quit [Quit: leaving]
uberushaximus has joined #glasgow
<whitequark> marcan: pokepoke
<marcan> whitequark: ESD protection thing queued for today (maybe a bit later)
<marcan> do you have a preference for the part?
<whitequark> marcan: i'm thinking the onsemi part, it's cheap and available
<marcan> we considered 3 footprints; XBP14E5UFN, ESD7008, SP7538PUTG/RCLAMP7528T/ESDLC5V0PB8/824014885
<marcan> the 7008? sure
<whitequark> yeah
<whitequark> i don't like any of them much more than the others and esd7008 seems like the cheapest option with least part count
<whitequark> so, weak pref for it
<marcan> sgtm
<marcan> and that way I can ask esden to throw in a spare and I can test my theory about them selling the same part under two names
<marcan> (if the NC pins aren't NC at all)
<whitequark> ha
<marcan> thoough tbh, that part, as advertised and documented, isn't very good at negative clamping
<marcan> because it has two diodes in series
<marcan> like, you'd *want* straight diodes to GND in our application
<marcan> i.e. the MG2040 version
<marcan> also, one neat thing about that version is that it has extra pins, so I can throw a couple of them on Vsense and Vio (if I can route that)
<marcan> whitequark: thoughts?
<marcan> oh, huh
<marcan> https://www.onsemi.com/pub/Collateral/ESD7104-D.PDF might be package-compatible with XBP14E5UFN ?
<marcan> yeah it is
<whitequark> hmm
<whitequark> i guess that works
<marcan> whitequark: go with ESD7104 then? layout will look like the example on github (I'm still redoing it though)
<marcan> at least this way I guess we have two sources for the part
<marcan> and it has proper negative clamping
<marcan> (and it's mildly more flexible I guess; I could see using that part on, like, some kind of 4-wire aux bus)
<whitequark> that adds two euros to BOM
<whitequark> hrm
<whitequark> as opposed to about one and a half
<whitequark> well, no
<marcan> digikey has it for $.60
<marcan> so $2.40, yeah, two euros I guess
<marcan> my only concern is that if we use the ESD7008 then any low voltage negative transients are going to be eaten up by the shifters, instead of the protection
<marcan> since the shifters are going to clamp at -0.7V or whatever, that thing doesn't even start to kick in until -5V
<marcan> hence using the MG2040 instead
<whitequark> ah I see
<whitequark> yes, i agree
<marcan> so which option then?
<whitequark> so... we have ESD7008 or ESD7104 that wouldn't clamp negative transients
<marcan> ESD7104 would
<marcan> no wait
<marcan> XBP14E5UFN would
<marcan> lol
<whitequark> right, but ESD7104 wouldn't
<marcan> same package, different function
<marcan> dammit
<whitequark> so it's not a true replacement
<whitequark> yes
<marcan> I got confused there
<whitequark> but MG2040 will, right?
<whitequark> and XBP14 will
<marcan> yes
<marcan> yup
futarisIRCcloud has joined #glasgow
<whitequark> so, MG2040 adds about 1 eur to the cost @ 100, lets us add additional protection to Vio and Vsense maybe
<whitequark> i mean
<whitequark> we don't really need protection on Vio as there's a huge cap there, and Vsense has a matching network that serves a similar function
<whitequark> we talked with awgyle about this, there's an issue on the tracker
<whitequark> that exlains why esd on those pins isn't a huge issue
<marcan> sure, but I mean it can't hurt it we just send a trace this way either
<whitequark> sure
<marcan> also I'm thinking more eventual I2C pins or whatever too
<whitequark> xbp14e5... costs about as much
<marcan> the only problem with this part is that our pins are way more spread out than this; we'll have "effective" ESD protection on the IOs, the aux pins are more of a wash whether I can route them all the way to the chip
<whitequark> eiter of them is single source
<marcan> yeah
<whitequark> who the hell is torex
<whitequark> i've never heard of them but mouser has seven freaking thousands of PMICs in stock
<whitequark> by torex
<marcan> lol
<marcan> japanese company
<whitequark> actually these don't look half bad
<marcan> they don't even have a wikipedia page
<marcan> I would file them under "weird japanese companies nobody outside has ever heard of"
<whitequark> >
<whitequark> LDO Voltage Regulators (4.137)
<whitequark> how do you even DESIGN four thousand different LDOs
<marcan> offer them in a million different voltages?
<whitequark> yes but FOUR THOUSAND
<marcan> 0.01V resolution!
<whitequark> i bet it's like three dies and efuse
<marcan> looking at their "PMICs", looks like it's just supervisors
<marcan> and they did a cartesian product of a few packages and voltages
<marcan> they have them in 0.1V increments
<marcan> soo yeah
<whitequark> 4000 LDOs, 1500 switchers, 1600 supervisors
<whitequark> idk
<whitequark> i'd say go with the onsemi part
<marcan> 0.1V increments is like 30 options already
<marcan> times, say, 5 packages
<marcan> times 3 because of digikey packaging options
<marcan> there's 450 supervisors :p
<marcan> MG2040?
<whitequark> yeah
<marcan> kk
<whitequark> it's a jellybean hdmi part, it's not gonna disappear
<whitequark> by onsemi too
<marcan> yeah
<marcan> let's see how layout works for that
<marcan> I'm slightly but not overly concerned
<marcan> well, I'm not going to hook up the underside GNDs, pretty sure
<marcan> but that should be fine, they say a single GND pin is enough
<marcan> the eeschema symbol is going to just break them all out separately
<marcan> since with these kinds of devices connectivity is very much layout-driven
<whitequark> yeah
<marcan> heck, the footprint says "center pads optional"
<marcan> I'm tempted to just not have them
<marcan> can you even do trapezoid pads in kicad? :p
<marcan> I guess you need two pads for that, adjacent
<marcan> oh it can do custom shapes, nifty
<marcan> lol the package diagram isn't even to scale
<marcan> aaand I just crashed kicad with that feature
<whitequark> lol
<Hellsenberg> O_o
_whitelogger has joined #glasgow
<marcan> whitequark: gotta run, but basically: https://mrcn.st/t/Screenshot_20190407_172430.png
<marcan> lol, with those trapezoid GND pads (that I can't ground anyway) we can't meet DRC
<marcan> I need to cut down the corners a tiiiny smidge more
<marcan> but that should be no issue
<Hellsenberg> DRC?
<marcan> design rule check
<Hellsenberg> hm
<marcan> so, I can provide two GNDs to the chi
<marcan> *chip
<marcan> which should be fine
<whitequark> marcan: sweet
<marcan> if I remove those trapezoid pads then maaybe I can squeeze in a GND vias instead and hook it up to the remaining GND pins
<marcan> no wait, that won't work
<marcan> actually maybe it will
<marcan> anyway
<marcan> this needs a 0.025mm grid to route on
<marcan> but the vertical dimension is less tight than with the XBP14E5UFN attempt, I think
<marcan> slightly
<marcan> and I can pull out 3 spare pins
<marcan> maaybe 4-5 if I do some funny routing on the sides
<marcan> for auxiliary protection
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #glasgow
_whitelogger has joined #glasgow
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 3 commits to master [+2/-0/±8] https://git.io/fjtff
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 439a920 - revC1: add MG2040 symbol and footprint
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 7bb2843 - revC1: fix some ERC errors
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan b9794b5 - revC1: add ESD protection to IO banks
<marcan> whitequark: please review
<marcan> btw, I made the testpoint top silkscreen size 0.8; ran out of space for the 3V3/5V labels
<marcan> (but I changed them all)
<marcan> bottom testpoints silkscreen is still larger since we have space there
<marcan> missing the 3D model for the new IC of course, let me see if I can put something together
<whitequark> ack. needs an issue for upstreaming the symbol and fp
<marcan> yeah
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±3] https://git.io/fjtfk
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 705033b - gateware.fx2_crossbar: rename FIFOs to reflect their function. NFC.
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark ffdc0ae - gateware.fx2_crossbar: simplify and clarify. NFCI.
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjtfL
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan e8fcc6f - revC1: fix U32 reference size
<marcan> I swear I'm going to miss something stupid like that and it's going to haunt me forever after we get them fabbed
<marcan> (that one part had a reference text that was larger than the rest)
<whitequark> back when i was laying out revA i was thinking "no way i could let anyone else do the layout, i have an autistic obsession over minor details and will never let go of control"
<whitequark> but you know i feel fine now
<marcan> lol
<marcan> I also snuck in an alignment fix for the IO bank silkscreen
<marcan> the labels were aligned but the GND lines weren't :p
<whitequark> excellent
<marcan> (and I ended up moving everything in Y to make it overlap less badly with the new vias)
<whitequark> ugh fucking kicad
<whitequark> they still haven't fixed the 3d viewer on hidpi
<marcan> btw, right now we're mixing 0.7 and 0.8 sized refs
<marcan> there is some logic to it
<whitequark> mhm
<marcan> everything is 0.8 except the right side of the board on the top (with the Vio supplies, and also the pull ICs and passives around that, but not the resistor networks or connectors), and the references in the box under the FPGA on the rear, which are 0.7
<whitequark> this is like, insanely tight
<whitequark> are you sure it'll fit
<marcan> it might make sense if we just make everything 0.7
<marcan> what will fit?
<whitequark> the ESD protection package
<marcan> the courtyard has margin and I'm not overlapping it with the connectors
<marcan> look at f.fab
<marcan> that's the actual package size
<whitequark> oh, excellent
<marcan> I'm not sure if this is documented anywhere, but my understanding is that the intent of the courtyards is that you're not supposed to overlap them, and that leaves enough clearance
<marcan> (though we are doing that in a few places, but not significantly so)
<whitequark> right
<whitequark> btw what happened to all the other 3d packages?
<marcan> did something happen?
<whitequark> oh, outdated packages3D
<marcan> oh, I just realized the Sync headr has a bullshit package
<marcan> it should be a KK connector, not a bare pin header, right?
<marcan> (you know, with polarity)
<marcan> oh btw, I did route vsense and vio through the ESD protection (like physically routed near the IC)
<marcan> and I put two pins on Vio because I had three
<whitequark> yes
<whitequark> also, nice
<whitequark> hm, let's change silk from "LVDS Bank" to just "LVDS", it bothers me
<whitequark> because we don't have "A Bank"
<marcan> I think the idea of "bank" was more that it was the FPGA bank
<marcan> but sure
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjtfZ
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 28f520d - revC1: s/LVDS Bank/LVDS/
<whitequark> thanks
<marcan> baaaah, kicad has molex KK vertical, but not horizontal
<whitequark> yeah, that's why the model was bullshit
<marcan> silkscreen too though
<marcan> which bugs me
<whitequark> i'm this close to unfucking the fx2 crossbar
<whitequark> that would be the last major FPGA-side problem besides async resets being broken because lolmigen
<marcan> so there's this
<marcan> for some stupid reason it's not upstream
<whitequark> no license
<marcan> blergh
<whitequark> "generated with kicad-footprint-generator"
<whitequark> maybe we could talk to them?
<marcan> let me open an issue
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjtfP
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 02cf946 - gateware.fx2_crossbar: factor out more logic into _FX2Bus. NFC.
<_whitenotifier-1> [Glasgow] whitequark closed issue #118: Improve ESD immunity - https://git.io/fjIUq
<_whitenotifier-1> [Glasgow] whitequark commented on issue #118: Improve ESD immunity - https://git.io/fjtfX
<marcan> whitequark: we still don't have protection for sync, btw
<marcan> well other than a resistor
<whitequark> mhm
<marcan> have a favorite single-channel TVS? :p
<whitequark> not really
<marcan> at least I hope those just come in some trivial diode package
<_whitenotifier-1> [Glasgow] whitequark reopened issue #118: Improve ESD immunity - https://git.io/fjIUq
<_whitenotifier-1> [Glasgow] whitequark commented on issue #118: Improve ESD immunity - https://git.io/fjtfb
<whitequark> they should
<whitequark> didn't Hellsenberg remove a dead one from a motherboard juts nearby
<whitequark> *just recently
<marcan> do we want to use a 3V3 part or a 5V part?
<marcan> SYNC is nominally 3V3 but, right now, if in input mode, 5V tolerant
<whitequark> 5V definitely
<marcan> ok
<whitequark> people will use it to sync with external 5V logic and that's valid
<marcan> so something like that?
<marcan> (going along with the onsemi theme)
<whitequark> the ESD protection goes before the resistor, right?
<marcan> yes (my theory being that that way the resistor protects downstream from whatever voltage the TVS clamps to)
<marcan> of course it also means enough energy will blow the TVS
<whitequark> right
<marcan> but it should be specced for that anyway
<whitequark> so if people use 5V input then it will get clamped to our 3V3 rail through the level shifter
<marcan> the shifter doesn't clamp to vcc
<whitequark> at all?
<marcan> nope
<marcan> in input mode anyway
<whitequark> oh that's handy
<whitequark> yep definitely need a 5V TVS
<marcan> at least that's what the datasheet says
<marcan> I haven't attempted to measure it
<marcan> it's somewhat vague
<whitequark> mmm
<whitequark> yeah sure, that onsemi device is ok
<marcan> multimeter says I've got a diode drop to GND but nothing to Vio
<marcan> so yeah
<gruetzkopf> are you planning on being showcased by onsemi for their protection devices?
<whitequark> gruetzkopf: lol
<whitequark> seriously though
<marcan> whitequark: do we care about AUX?
<whitequark> i assumed the shifter clamps to Vio
<whitequark> if it doesn't it means we *really* need these TVS
<marcan> I mentioned this fact earlier here :-)
<whitequark> for positive pulses
<whitequark> yeah, i must have missed it somehow?
<whitequark> as for AUX, it's internal and shouldn't be exposed in cass
<whitequark> *cases
<whitequark> so i think the resistors are fine
<whitequark> i don't plan on keeping AUX anyway on revD
<whitequark> hm, question
<whitequark> are there any shift registers where you shift O and OE into them, and shift out I?
<marcan> it's just going to be D_Zener btw
<marcan> hm, what do you mean?
<whitequark> imagine the PCA bus extender but on SPI instead of I2C
<marcan> right
<marcan> hm, good question
<whitequark> revD will not come along for a while and i want an interim solution
<whitequark> i can make a hardware abstraction for a pin extender
<marcan> interim solution for what?
<whitequark> like, gateware abstraction
<marcan> oh
<marcan> I see what you mean
<marcan> well you could just chain off standard shift registers and our existing level shifters
<whitequark> that sounds depressing
<marcan> hm actually no
<whitequark> that's a fuckton of packages
<whitequark> i mean
<whitequark> it is obviously doable with two packages
<whitequark> wait, no
<whitequark> marcan: troll answer: put an XC9500XL there
<marcan> lololol
<whitequark> which..... might actually be the lowest cost solution
<whitequark> because it's very fast and it can clearly do what i want
<whitequark> marcan: there'd be a stupid problem with XC9500
<whitequark> it can't run on 5V
<whitequark> so that board will need to be shipped with a zener and a ten pack of 0805 SMD fuses
<whitequark> or i guess a polyfuse?
<marcan> err ESD9X5.0 is way too fucking small
<whitequark> too small for what?
<marcan> 0.80 x 0.60mm lol
<whitequark> christ
<whitequark> that's well into "inhalation hazard" territory
<marcan> it's somewhat smaller than 0402, but I don't want anything smaller than 0402
<marcan> oh wait
<marcan> maybe it *is* 0402?
<marcan> yeah actually
<whitequark> 0.039x0.024
<whitequark> that's more or less 0402
<marcan> yeah actually
<marcan> I think I can just use the 0402 footprint
<whitequark> that feels dirty
<whitequark> though
<marcan> I mean
<marcan> "The SESD0402S-005-054 device is an ultra-low-capacitance SOD-923 (0402-size package)"
<marcan> I think it's probably intended to actually be 0402
<whitequark> doesn't kicad have sod-923?
<marcan> nope
<whitequark> aw
<marcan> but it has a 0402 diode
<ali_as> I like the xc9500s, they're obsolete now I think.
<whitequark> ali_as: hence XL
<ali_as> Are they still in production?
<whitequark> yes
<whitequark> the XL version is
<whitequark> it's a smaller process
<whitequark> so, no longer 5V, though still 5V-tolerant
<whitequark> internals are quite different too
<ali_as> Cool, I thought they'd all been discontinued.
<ali_as> Still has the 90 product terms limitation.
<Hellsenberg> when did I remove a dead TVS from a board
<Hellsenberg> oh, I did remove an ESD protector
<whitequark> ys.
<whitequark> ali_as: i think it's a similar architecture but different silicon
<Hellsenberg> i think it's dual channel, even if it's in a 6 pin package
<whitequark> the bitstream organization is totally different
<whitequark> ali_as: as for 90 product terms... i'm just using it as a long shift register, pretty sure i'll be fine
<ali_as> Strange, the XL is specced at a higher clock rate but pit to pin delay is the same.
<ali_as> Pin to pin.
<Hellsenberg> wait it's actually four channel
<whitequark> ali_as: can XC9500 do DDR?
<ali_as> Latch on both edges? Yikes not sure.
<whitequark> > Each macrocell flip-flop is configurable
<whitequark> for either single edge or DualEDGE clocking, providing
<whitequark> distribute a slower clock (thereby saving power).
<whitequark> either double data rate capability or the ability to
<whitequark> why the fuck is that a trademark
<Hellsenberg> lolwut
<marcan> whitequark: so, lol
<marcan> and they are *all different*
<marcan> I think I can just get away with using the 0402 diode package :p
<whitequark> marcan: that'll just cause issues when upstreaming i think
<whitequark> but feel free
<marcan> there is nothing to upstream
<marcan> it's a generic diode
<marcan> I'm using the zener symbol
<marcan> and to fix the lack of 3D I'm doing what that last link did
<marcan> which is take the 0603 model and set scale to 0.7
<whitequark> ack
<ali_as> I'm finding references to duel edge capability in coolrunner but not 9500 series.
<ali_as> Was the quote you posted about 9500?
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±4] https://git.io/fjtJX
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 4af0475 - revC1: add a TVS protection diode to SYNC
<marcan> wait I derped
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±4] https://git.io/fjtJD
<whitequark> oh wait
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 59c960b - revC1: add a TVS protection diode to SYNC
<marcan> whitequark: sorry for the force push
<whitequark> marcan: five second rule applies
<whitequark> :P
<whitequark> well more like five minute rule
<marcan> yeah I was going to say :P
<marcan> (had the wrong part, and I also fixed the fab layer)
<marcan> (I always forget about the fab layer, lol)
<marcan> esden: might want to review the footprint choice; it's generic 0402 for a SOD-923 (see https://www.onsemi.com/pub/Collateral/ESD9X3.3ST5G-D.PDF)
<marcan> pretty sure it'll work, the pads are just larger
<marcan> but you have more manufacturing experience
<marcan> if needed we can make a more accurate footprint, I'm just not sure if it's worth doing
<whitequark> ali_as: sorry, brain fart
<whitequark> i somehow thought 9500 is the same as coolrunnerii
<whitequark> xc9572 is probably enough
<whitequark> hm, maybe not
<whitequark> for n pins i need n*3 registers
<whitequark> or, no, n*4
<whitequark> a pair to latch io and oe value, and a pair to shift them
<_whitenotifier-1> [Glasgow] marcan commented on issue #118: Improve ESD immunity - https://git.io/fjtJy
<_whitenotifier-1> [Glasgow] marcan closed issue #118: Improve ESD immunity - https://git.io/fjIUq
<whitequark> so for 16 io that'd be 64 registers
<marcan> whitequark: I just through of this, but are the names on the front intended to be twitter, or github?
<marcan> unfortunately I'm the only one on there with a mismatch
<marcan> (marcan on github, marcan42 on twitter)
<whitequark> marcan: uh, i don't know
<Hellsenberg> are we going to stick a cpld on the glasgow? reminds me of several chonky fpga boards
<whitequark> i think they're intended to be both
<marcan> dammit
<whitequark> pick your poison?
<whitequark> i'd say github
<whitequark> Hellsenberg: no, as an addon
<marcan> well, first of all, let me take care of the obvious problem
<Hellsenberg> hmm
_whitelogger has joined #glasgow
<whitequark> ha
<marcan> probably safer to leave it as @marcan42 then
<marcan> since @marcan is some rando
<marcan> (on twitter)
<whitequark> sure
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±5] https://git.io/fjtU0
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark c4ec091 - revC: tiny changes to text placement on schematic for readability.
<Hellsenberg> marcan: have you considered adding this to marcan42's github picture: https://www.tenforums.com/geek/gars/images/2/types/thumb_14378800210Shortcut_arrow.png
<marcan> Hellsenberg: lol
<Hellsenberg> wouldn't be a bad idea :P
<marcan> whitequark: so I went and made this in openscad, but now I have no idea if I can export this into kicad :p https://mrcn.st/t/Screenshot_20190407_235647-1.png
<marcan> apparently the "recommended" way is freecad, but fuuuck that
<marcan> the ebuild isn't even in gentoo any more because it's still qt4, lol
<whitequark> it normally has to be STEP but this part has no round corners
<whitequark> so it probably doesn't matter?
<marcan> the only round thing is the pin1 marker
<whitequark> mhm
<marcan> whitequark: meh, I can't find any flow that doesn't involve freecad
<marcan> have you ever done this before?
<whitequark> marcan: yes, i used freecad
<whitequark> i absolutely detest freecad in every possible way
<marcan> okay, then I'm not bothering with this until freecad is back in gentoo
<marcan> also, what is it with 3d software being shit and unbuildable
<marcan> wings3d fails to build too
<whitequark> solvespace doesn't :P
<marcan> I'm going to see if I can get my openscad thing into blender and out to wrl, just for the fancy render
<marcan> no STEP
<marcan> (thus no upstream)
<marcan> and if this doesn't work, screw it
<whitequark> no STEP on peng
<marcan> peng?
<whitequark> like no step on snek, but peng, as in linux penguin
<marcan> lol
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
uovo has joined #glasgow
<marcan> whitequark: https://mrcn.st/t/Screenshot_20190408_010529.png good enough to get pretty renders
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+1/-0/±2] https://git.io/fjtkB
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan ed9ac32 - revC1: add UDFN-18 package model
<whitequark> nice
<whitequark> wow
<whitequark> i completely reworked the crossbar and it worked the 1st time
m4ssi has joined #glasgow
<gruetzkopf> wow
<whitequark> i mean, i also simplified it to like three FSM states
<whitequark> well, five states, four decision points
<whitequark> and it ALSO works even faster now
<whitequark> because it correctly sends ZLPs
<Hellsenberg> pardon my ignorance, what is a crossbar?
<Hellsenberg> i am not sure how the fx2 and the fpga talk to each other, so I should address this too
<tnt> Hellsenberg: glue logic between busses
<tnt> in this case the internal FIFOs of the fpga and the FX2 interface.
<Hellsenberg> hm, I see
<whitequark> oh, my skepticism was warranted, it does hang in some edge cases
<whitequark> though in fewer edge cases than before
<whitequark> and more deterministically
<whitequark> so it's still good
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjtkj
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan bf02244 - revC1: make the routing around the ESD protection more uniform
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjtIk
<marcan> 5 minute rule again :p
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan de5346f - revC1: make the routing around the ESD protection more uniform
<marcan> pin1 of the ESD protection is special, the mirror symmetry caused the trace to enter the pad strangely. adjusted both sides to match and look decent for both
<Hellsenberg> marcan: don't get really used to this, afaik the AUR does not allow it
<marcan> ?
<Hellsenberg> force pushing
<Hellsenberg> had a friend tell me he's had to do a sad small fixup commit a few times :P
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjtIq
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 2ee4744 - revC1: make the routing around the ESD protection more uniform
<marcan> Hellsenberg: how is AUR related to this?
<Hellsenberg> not much
<Hellsenberg> don't mind me I brain farted
<whitequark> ah, fencepost error
<whitequark> one i knew about, even
<whitequark> just forgot to actually handle
<Ultrasauce> whats with the copper islands there https://twitter.com/marcan42/status/1114936186542235648 ?
<marcan> pads
<marcan> GNDs actually, but I'm not connecting them because I can't
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fjtIo
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 5a7d18a - gateware.fx2_crossbar: rework to handle pipelining. (UPDATE FIRMWARE)
<whitequark> daveshah: can you explain why does ice40 even -have- PIN_INPUT_DDR?
<daveshah> what do you mean exactly?
<whitequark> oh wait
<whitequark> PIN_INPUT_REGISTERED and PIN_INPUT_DDR is exactly same
<daveshah> yes
<whitequark> I thought they were different, but they are not
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
ali_as has quit [Remote host closed the connection]
<esden> marcan: I am not sure, I did use some SOD footprint on an 0603 footprint in the past, and despite on paper they seemed ok in practice I ended up with the diode floating on solder and I had to rework a bunch of boards. I am not sure this will be an issue in this case, but I did end up adjusting the foot print to be exactly as they recommend to battle the issue I had. As I said I was 0603 not 0402.
<marcan> hm, floating on solder as in not attaching at the pins?
<esden> I bet you don't have space for 0603 footprint but for parts that come in plastic tape I prefer them in bigger packages, 0402 parts in plastic tape are super bouncy :(
<marcan> I think I can fit a 0603 in there, if you have a preferred 5V TVS in that package
<marcan> something in SOD-523 I guess (which kicad *does* have)
<esden> I have not used TVS diodes in singles yet. https://github.com/icebreaker-fpga/icebreaker/issues/26 ;)
<esden> I only have a schottky diodes that I use in many things. I was using those bit less common 0603 packaged ones. Switching over to SOD-523 in the future.
<marcan> oh, onsemi has these in SOD-523 too
<whitequark> gruetzkopf: i found another setup/hold violation
<gruetzkopf> yaaay
<whitequark> the FX2 has somewhat ridiculous clock-to-flag timings
<whitequark> 9.5 ns
<whitequark> well, i understand why they did it
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±2] https://git.io/fjttU
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan b82a151 - revC1: switch to a SOD-523 diode for the SYNC protection
<gruetzkopf> interesting..
<gruetzkopf> (why can't they provide a useful machinereadable timing model)
<marcan> esden: datasheet says 0.48 × 0.40 pads though, while the KiCad footprint has 0.6 × 0.7
<marcan> (even though both claim to be SOD-523)
<marcan> not sure if you think that might be a problem
<esden> marcan: it could be a problem, it might float the part in a strange way. It is hard to know until tested on a hundred boards or so...
<esden> maybe less but still :)
<marcan> heh
<marcan> well, the problem is the usual thing where several manufacturers call a package $foo but then specify totally different recommended solder patterns
<esden> just put the large one on the board for now... if we need a custom one because the one in kicad is wrong we will try to solve it. :)
<tnt> whitequark: 9.5 ns should be fine ?
<marcan> yeah, that photo is of that commit I just made
<tnt> why do you think it's a setup/hold violation ?
<marcan> SOD-523 (0603 ish size)
<marcan> only reason we had a 0402 is it was the first part I stumbled upon from a related datasheet from onsemi
<esden> marcan: yes that is why I chose it. I will be making my custom footprint that matches the datasheet for the icebreaker.
<whitequark> tnt: 9.5 ns or 13.5 ns with externally sourced IFCLK
<marcan> well, and it's $.10 cheaper in 0402
<whitequark> hmm
<whitequark> tnt: oh yeah 9.5 ns is fine at 30 MHz
<whitequark> but not 48 MHz
<marcan> esden: the footprint I'm using claims to be SOD-523, to be clear (it's different from plain 0603)
<marcan> but if you want me to dump a custome one with the pad sizes adjusted that's trivial too
<marcan> *custom
<marcan> it's just one more one-off footprint
<gruetzkopf> 48MHz * (*not for any interesting case)
<gruetzkopf> 9.5ns leaves what, .7ns to falling edge of CLK?
<whitequark> interesting case?
<tnt> whitequark: still ndon't get it. If you capture on the falling edge, 9.5 ns clk-to-out it still fine
<whitequark> hrmm
<tnt> capture window is 1.3 ns to 5.6 ns after the capture edg.e
<whitequark> ok
* whitequark reverts some changes
<whitequark> OH
<whitequark> logic error elsewhere caused me to look for this S/H violation
<whitequark> nevermind everything
<Hellsenberg> ohno
<esden> marcan: it might be better to trust the data sheet on the footprint probably. I will cross check that with the parts I will be using later today. And see if they differ.
<whitequark> marcan: tnt: review requested on the final form of the FX2 crossbar
<whitequark> i think i like everything about it now
<whitequark> and it withstands my tests
<gruetzkopf> even the cursed device test?
<whitequark> haven't checked yet
<whitequark> er and haven't pushed
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fjtt8
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 995e002 - gateware.fx2_crossbar: re-register FX2 outputs.
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 468e706 - gateware.fx2_crossbar: eliminate wait states.
<_whitenotifier-1> [Glasgow] whitequark closed issue #89: Use SB_GB_IO instead of SB_IO+SB_GB - https://git.io/fjvFD
<whitequark> gruetzkopf: jesus fuck that machine is *slow*
<whitequark> Info: SA placement time 65.18s
<tnt> and HeAP ?
<gruetzkopf> it's a slow-clocking, laptop variant of AMD Fam 14h, "Bobcat"
<gruetzkopf> that's a 2011-ish ultra-low-power thing
<gruetzkopf> (and yeah, i want a replacement for it)
<whitequark> tnt: dunno, i don't want to fiddle with that over ssh
<whitequark> i absolutely hate that shit
<Hellsenberg> i guess the only good thing this amd chip has is coreboot support
<whitequark> it's bad enough that i need to download 8 MB over... 15 KB/s?
<whitequark> gruetzkopf: ok yeah no, i'm not gonna debug thi
<whitequark> if you want me to look at it any further give me a real machine with a real internet connection
<whitequark> selftest succeeds, source benchmark fails
<whitequark> i have two files, actual.bin and golden.bin
<gruetzkopf> 15KB/s is like factor 20 off from expected
<whitequark> that's upload
<whitequark> i'm trying to grab those files from a machine where i don't have root, to a machine where i do
<whitequark> it looks like the difference starts at byte 0x200
<whitequark> which is weird
<whitequark> oh wait
<whitequark> wait nevermind
<whitequark> i forgot to rebuild and upload firmware
<whitequark> gruetzkopf: YEP
<whitequark> the cursed device works now
<whitequark> I: g.applet.internal.benchmark: mode loopback: 6.91 MiB/s (55.26 Mb/s)
<whitequark> that's a whopping one third of the speed you should be getting
<whitequark> gruetzkopf: enjoy your glasgow :D
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjttr
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 238cced - device.config: fix typo.
<tnt> whitequark: so what was the issue ?
<whitequark> tnt: issue with what exactly?
<whitequark> gruetzkopf's device?
<tnt> yes
<whitequark> i'm not entirely sure, but it's probably some combination of s/h violations and me using pipelining incorrectly
<whitequark> okay, so i also made everything 1.5-1.8 times faster
<whitequark> because now we're limited by posedge->posedge and not negedge->posedge
<gruetzkopf> YAAAY
<whitequark> aaaaaand i made it EVEN FASTER
<whitequark> I: g.applet.internal.benchmark: mode loopback: 30.83 MiB/s (246.62 Mb/s)
<tnt> E: g.applet.internal.benchmark: mode source failed!
<tnt> :/
<whitequark> tnt: need to update firmware
<whitequark> go to software/ and do python3 setup.py build_ext
<marcan> whitequark: wait hold on what
<marcan> 30MiB/s loopback?
<whitequark> yes.
<marcan> that is not a thing
<tnt> whitequark: ah yes, indeed, thanks :)
<marcan> that is faster than the USB bit rate
<whitequark> uhm
<whitequark> did i make an error in math somewhere?
<whitequark> i... don't think so?
<whitequark> 1 << 20 is one megabyte
<hl> I think what he means is, USB HS is still half-duplex, so 480/2=240Mb/s
<marcan> yes
<marcan> so this is impossible
<whitequark> hrm
<whitequark> oh, i know what happens
<whitequark> i forgot a flush call lmao
<whitequark> wait no
<whitequark> what
<whitequark> what the fuck
<hl> only explanation: you broke through the USB shittiness barrier and made USB better than it previously was
<whitequark> ...
<marcan> for reference, my record is 42MiB/s on an FT2232H in one direction (so no turnaround overhead).
<whitequark> oh, i see the problem
<whitequark> i count each byte twice
<marcan> that makes more sense
<marcan> so it's full throughput, not in both directions
<whitequark> yes
<marcan> so you still have 40% improvement margin to match my FTDI record :p
<whitequark> yes
<whitequark> i mean
<whitequark> not using python to run the benchmark would be a start?
<marcan> probably
<marcan> FTDI thing was in C :P
<marcan> though if you have big pipelined URBs that shouldn't be an issue
<daveshah> kernel mode glasgow ;)
<whitequark> i have big pipelined URBs but i'm pretty sure this can be improved
<whitequark> because i haven't even profiled it
<whitequark> i mean, big = 8k
<marcan> this is master, right?
<marcan> oh I think I had like 128k URBs lol
<whitequark> not yet
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fjtt9
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 097593b - Raise IFCLK frequency on revC0+ to 48 MHz. (UPDATE FIRMWARE)
<whitequark> now it's master
<tnt> oh, it's rev C only :)
<whitequark> well yes
<marcan> ah, just checked. I was doing 16K URBs but queuing 32 of them at once
<whitequark> revB is faster too, but it can't quite clear that barrier
<whitequark> i get 40 MHz Fmax
<marcan> so 512k worth of queuing
<whitequark> it *might* be possible to optimize
<whitequark> marcan: lemme try those settings
<marcan> note that this was single direction. do you have a test like that?
<marcan> i.e. glasgow just generates a stream of crap
<whitequark> marcan: yes
<whitequark> benchmark runs source, sink and loopback
<marcan> ah
<marcan> also note that the FTDI iface clock is 60MHz
<marcan> this is 48, right?
<whitequark> yes
<whitequark> but it should be able to saturate the bus with 48 MHz
<marcan> E: g.applet.internal.benchmark: mode source failed!
<marcan> E: g.applet.internal.benchmark: mode loopback failed!
<whitequark> since that's 384 Mbps and USB can't move that much data
<marcan> eeh
<marcan> what happened here?
<whitequark> marcan: need to update firmware
<whitequark> python3 setup.py build_ext
<marcan> oh
<whitequark> it probably should replace that with a symlink if you run `python3 setup.py develop`, maybe
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjttQ
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark dc63586 - access.direct.demultiplexer: increase buffering to 32 packets ×16.
<marcan> err
<marcan> okay there is something le dumb about this
<marcan> I: g.applet.internal.benchmark: running benchmark mode source for 8.000 MiB
<marcan> I: g.applet.internal.benchmark: mode source: 21.50 MiB/s (172.00 Mb/s)
<marcan> I: g.applet.internal.benchmark: running benchmark mode source for 128.000 MiB
<marcan> I: g.applet.internal.benchmark: mode source: 5.24 MiB/s (41.92 Mb/s)
<marcan> CPU limited
<whitequark> yes
<whitequark> i'm not entirely sure why
<marcan> cutting up bytestrings the dumb way, maybe?
<whitequark> no
<whitequark> shouldn't be
<whitequark> wait, let me check something
<whitequark> marcan: yeah
<whitequark> lemme fix this
<marcan> read_data += packet? :p
<whitequark> yes
<marcan> (or the like)
<marcan> called it.
<whitequark> is that quadratic?
<marcan> yes
<marcan> well the statement is linear in the size of read_data
<marcan> so overall calling it for every packet is quadratic
<whitequark> marcan: I: g.applet.internal.benchmark: mode source: 30.14 MiB/s (241.09 Mb/s)
<whitequark> with quadratic fix
<marcan> push?
<whitequark> I: g.applet.internal.benchmark: mode source: 31.61 MiB/s (252.90 Mb/s)
<whitequark> and this is what i get if i don't concatenate the received packets inside the timed section
<marcan> yeah, that's reasonable
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjtqk
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark f574101 - access.direct.demultiplexer: fix accidentally quadratic read().
<marcan> eh, there's still something wrong here
<marcan> I: g.applet.internal.benchmark: running benchmark mode source for 32.000 MiB
<marcan> I: g.applet.internal.benchmark: mode source: 26.19 MiB/s (209.52 Mb/s)
<marcan> I: g.applet.internal.benchmark: running benchmark mode source for 128.000 MiB
<marcan> I: g.applet.internal.benchmark: mode source: 18.10 MiB/s (144.78 Mb/s)
<whitequark> yes, it's linear in the amount of data
<whitequark> because it's concatenating all those URBs in the timed loop
<marcan> it's *slowing down* with more data, so it's worse than linear
<whitequark> hmmm
<whitequark> maybe python's join() is not linear?
<whitequark> marcan: lemme just add some more benchmark modes
<whitequark> that would discard the received data
<whitequark> or send zeroes
<marcan> I can concatenage 8GB of data in 3.8 seconds in python, so .join() is clearly not the problem here
<marcan> *concatenate
<whitequark> hm
<marcan> (that's 8K buffers)
m4ssi has quit [Remote host closed the connection]
<whitequark> marcan: hm, no
<whitequark> i added zero mode instead of prbs
<whitequark> no difference whatsoever
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjtqg
<marcan> whitequark: *now* it's linear.
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 48bd1a3 - chunked_fifo: fix O(n²) __len__()
<whitequark> of fucking course
<marcan> still very clearly CPU limited during the transfer though, but at least now it's a constant optimization problem
<marcan> okay, off to sleep :p
<whitequark> nini
<marcan> whitequark: actually, _packets_per_xfer = 64 makes it no longer CPU limited on my system
<marcan> but I barely get any improvement; looks like I'm right on the edge here
<marcan> so the bottleneck seems to be elsewhere (could be a pipelining issue)
<marcan> I: g.applet.internal.benchmark: running benchmark mode source for 128.000 MiB
<marcan> I: g.applet.internal.benchmark: mode source: 26.81 MiB/s (214.49 Mb/s)
<marcan> I: g.applet.internal.benchmark: mode sink: 30.97 MiB/s (247.76 Mb/s)
<marcan> I: g.applet.internal.benchmark: running benchmark mode sink for 128.000 MiB
<marcan> I: g.applet.internal.benchmark: running benchmark mode loopback for 128.000 MiB
<marcan> I: g.applet.internal.benchmark: mode loopback: 31.15 MiB/s (249.20 Mb/s)
<marcan> that's what I get right now
<marcan> whitequark: I might opevizsla this later to check bus utilization
<marcan> (will probably have to write some analysis tool for the output though :p)
<marcan> anyway, nn!
<marcan> whitequark: okay it's definitely hardware limited. (I did attempt to go to sleep but failed :p)
<whitequark> how so?
<marcan> I see NAKs from the FX2
<whitequark> hmmm
<marcan> an IN xfer takes about 9-10µs; I see a pattern of 3 packets - NAK - 4 packets - NAK, approximately
<marcan> and my host controller decides to wait 21µs after each NAK before trying again
<whitequark> oh.
<marcan> so that's 70µs active 40µs blocked
<whitequark> so if i use an iso endpoint with bInterval=1 it should get better, right?
<whitequark> and three packets per microframe of course
<marcan> iso is complicated
<marcan> you need high bandwidth transfers for that
<marcan> and you might lose data
<marcan> don't use iso
<whitequark> yeah
<marcan> iso is a major PITA
<whitequark> why can't the HC just, not wait before another BULK IN token ;w;
<gruetzkopf> because usbif?
<gruetzkopf> isn't that enough?
<whitequark> usbif does not specify HC behavior
<tnt> welll why the NAK in the first place ? if the fpga kept the FX2 buffer filled, it shouldn't NAK.
<tnt> it doesn't seem unreasonable for the HC to pause a bit if the device last reported it had nothing to say.
<marcan> because the FPGA can't keep the FX2 buffer filled
<marcan> not at 48MHz
<marcan> USB2 linerate is 60MHz
<marcan> (hence why the FTDI FIFO runs at that rate, and *that* certainly keeps the buffers topped up)
<whitequark> FX2 can do better than 30 MB/s i think
<whitequark> lemme see
<marcan> the problem here is we're running into NAKs
<whitequark> yes
<marcan> so, like, as soon as you *can't* saturate the bus, you drop a lot of bandwidth
<marcan> and this is HC dependent
<Hellsenberg> stupid question: is "make the fpga run faster" not an option?
<Hellsenberg> or is the 30 MHz clock a hard requirement?
<marcan> in fact, lol.
<marcan> I: g.applet.internal.benchmark: running benchmark mode source for 32.000 MiB
<marcan> I: g.applet.internal.benchmark: running benchmark mode sink for 32.000 MiB
<marcan> I: g.applet.internal.benchmark: mode sink: 31.64 MiB/s (253.13 Mb/s)
<marcan> I: g.applet.internal.benchmark: mode source: 35.81 MiB/s (286.47 Mb/s)
<marcan> I: g.applet.internal.benchmark: running benchmark mode loopback for 32.000 MiB
<marcan> I: g.applet.internal.benchmark: mode loopback: 40.54 MiB/s (324.32 Mb/s)
<marcan> that's on EHCI
<whitequark> marcan: what.
<marcan> previous was on xHCI :D
<whitequark> WHY
<marcan> see, the FTDI runs faster on xHCI (42MB/s vs 40 or so)
<marcan> buuut I guess EHCI retries faster?
<whitequark> Hellsenberg: we already run the FPGA at 48 MHz
<whitequark> on revC
<Hellsenberg> oh, so it got a speedup. nice.
<Hellsenberg> thought it would still be running at 30 MHz
<marcan> I was using xHCI under the assumption that it would be faster, as it was for FTDI
<marcan> but I guess not :D
<gruetzkopf> xhci firmware bug?
<whitequark> marcan: The results
<whitequark> show that the average throughput that can be achieved with the BULK transfers is 43.8 MBps and the maximum
<whitequark> throughput that can be achieved with ISO transfers is 24 MBps.
<whitequark> this is what the FX2 docs say
<whitequark> that's Intel IHC9 EHCI on Win7
<marcan> well I just got 40MB/s on EHCI sooo
<whitequark> marcan: ohhhhhh
<whitequark> wait
<whitequark> marcan: i know how to improve it dramatically lol
<whitequark> give me a moment
<marcan> what?
<whitequark> I: g.applet.internal.benchmark: running benchmark mode source for 8.000 MiB
<whitequark> I: g.applet.internal.benchmark: running benchmark mode sink for 8.000 MiB
<whitequark> I: g.applet.internal.benchmark: mode source: 43.37 MiB/s (346.94 Mb/s)
<whitequark> I: g.applet.internal.benchmark: running benchmark mode loopback for 8.000 MiB
<whitequark> I: g.applet.internal.benchmark: mode sink: 42.76 MiB/s (342.09 Mb/s)
<whitequark> I: g.applet.internal.benchmark: mode loopback: 42.91 MiB/s (343.24 Mb/s)
<whitequark> that's on xhc
<Hellsenberg> sorcery
<marcan> hahaha
<marcan> I saw that
<marcan> and I was wondering if you were using it
<marcan> is this okay for all use cases?
<whitequark> no
<whitequark> this only works in 2 EP mode
<whitequark> lemme wire it up so it automatically activates if there's only two EPS
<marcan> EHCI:
<marcan> I: g.applet.internal.benchmark: running benchmark mode source for 64.000 MiB
<marcan> I: g.applet.internal.benchmark: mode source: 40.07 MiB/s (320.54 Mb/s)
<marcan> I: g.applet.internal.benchmark: mode sink: 39.63 MiB/s (317.06 Mb/s)
<marcan> I: g.applet.internal.benchmark: running benchmark mode sink for 64.000 MiB
<marcan> I: g.applet.internal.benchmark: running benchmark mode loopback for 64.000 MiB
<marcan> I: g.applet.internal.benchmark: mode loopback: 40.61 MiB/s (324.89 Mb/s)
<marcan> xHCI:
<marcan> I: g.applet.internal.benchmark: running benchmark mode source for 64.000 MiB
<marcan> I: g.applet.internal.benchmark: mode source: 43.03 MiB/s (344.21 Mb/s)
<marcan> I: g.applet.internal.benchmark: mode sink: 45.49 MiB/s (363.96 Mb/s)
<marcan> I: g.applet.internal.benchmark: running benchmark mode sink for 64.000 MiB
<marcan> I: g.applet.internal.benchmark: running benchmark mode loopback for 64.000 MiB
<marcan> I: g.applet.internal.benchmark: mode loopback: 44.37 MiB/s (354.94 Mb/s)
<marcan> now we're talking
<marcan> congratulations, you beat FTDI
<whitequark> NICE
<gruetzkopf> whoa, neat
<marcan> 45MiB/s in sink mode is very nice
<marcan> okay, I can sleep now :p
<Hellsenberg> O_o
<marcan> btw, max physical is 45.77 MiB/s (that's 48MHz)
<gruetzkopf> if jtag-pinout doesn't need revC i can connect the AlpineRidge Card like this time tomorrow
<marcan> so *basically* sink mode is fully utilizing the FIFO interface
<marcan> that makes sense, since that will never NAK
<marcan> source mode is probably still losing some throughput to NAKs
<marcan> (but not as much)
<Hellsenberg> these FX2 chippos are rather interesting
<marcan> er, sorry, sink mode will NAK, but as long as the buffers are full it'll saturate
<marcan> anyway
<marcan> nn :p
<tnt> err, on revB that patch with setConfig(2) reduces throughput
<tnt> 27 -> 21
<tnt> mmm ... that might have been a fluke
<whitequark> sounds very unlikely that it would
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±3] https://git.io/fjtm2
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark a727634 - access.direct: select configuration with optimal pipe count.
<tnt> yeah, it doesnt ... sorry must have been my cpu doing something at that particular benchmark.
futarisIRCcloud has joined #glasgow
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to wip-audio.yamaha_opl-ymf262 [+0/-0/±2] https://git.io/fjtmp
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 9ee6fc5 - WIP: applet.audio.yamaha_opl: YMF262 support.