emeb has quit [Quit: Leaving.]
_whitelogger has joined ##openfpga
emeb_mac has joined ##openfpga
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
implr has quit [Ping timeout: 258 seconds]
<whitequark> mwk: ohhh hm, you're right
<whitequark> lemme fix it
<mwk> hrm wtf
<mwk> another "fun" thing
<mwk> if you completely fuck up loading the bitstream and, in fact, never upload any valid data
<mwk> JSTART will *still* startup up the FPGA and light up DONE
<whitequark> but not ISC_DONE?
<mwk> ISC_DONE as well
<whitequark> i think i've seen that behavior, actually
<whitequark> hm
<whitequark> wait
<whitequark> are you sure this happens without a flash too?
<mwk> yes
<mwk> the jumper is set to JTAG-only
<mwk> heh
<mwk> try it
<whitequark> i can't
<mwk> just commend out the CFG_IN
<whitequark> my board isn't jumpered
<whitequark> i'd have to like desolder the flash
<whitequark> or i guess short it or something
<mwk> doesn't matter
<whitequark> ok sure
<mwk> just JPROGRAM + JSTART
<mwk> behavior is consistent with blank bitstream (ie. all outputs tristated, DONE high)
flea86 has joined ##openfpga
<mwk> I suppose that's weird but harmless for a blank bitstream (or something missing the sync word entirely)
<mwk> not so harmless for a configuration that failed because of CRC / IDCODE error though
<mwk> but, ugh
<mwk> there doesn't seem to be a JTAG register you could query for error status
<mwk> so you'd actually have to talk to it via CFG_IN / CFG_OUT?
<mwk> that just keeps getting worse, doesn't it...
<mwk> okay, it doesn't start for a CRC error, good
<whitequark> mwk: i commented CFG_IN
<mwk> I suppose it works for blank because it technically never triggers an error
<whitequark> doesn't start
<mwk> no DONE?
<whitequark> nope
<mwk> could be different on xc6s
<whitequark> yes, might have been a bug they fixed
<whitequark> fixed applet
<whitequark> how should i credit you btw
<mwk> realname, I guess
<mwk> eh
<mwk> I guess I'll try messing with CFG_IN/CFG_OUT now
<mwk> and/or maybe figure out wtf this ISC_* thing is
<whitequark> sounds good. I'm wondering about the bit order in ISC_*
<whitequark> btw do you have a glasgow
<mwk> no, using the builtin basys2 programmer
<mwk> hmm
<mwk> what is ISC anyway? I suppose I should read IEEE 1532 first?
<whitequark> in system configuration
<mwk> it's some kind of redundant interface to the same thing we're using, made in the name of conforming to some standard?
<whitequark> in my understanding yes
<whitequark> scihu has a copy of 1532
<whitequark> btw, ieee says that 1532 is "withdrawn", not sure what's up with that
<whitequark> a long time ago too
<whitequark> someone didn't pay the ieee rans^Wfees?
<whitequark> something i kinda want to have in the applet is readback...
<mwk> readback is tricky
<mwk> you have to actually send CFG_IN queries and get CFG_OUT responses
Bike has quit [Ping timeout: 248 seconds]
<mwk> and... well, there's the thing I don't really understand about it
<mwk> in normal JTAG, you have registers with well-defined lengths
<whitequark> yep
<mwk> if you have multiple devices in the chain, you just concatenate your shit with some BYPASS bits in the front and the back, and done
<mwk> but if CFG_IN is equivalent to just connecting TDI to DIN
<mwk> and your FPGA is not the first device in the chain
<mwk> you'll always submit some crap bits to it beforhand, whether you want it or not, correct?
<whitequark> yep.
<mwk> and for CFG_OUT, you'll always trigger a few more bits of readback than you are actually interested in
<whitequark> yep.
<mwk> so... how on earth are you supposed to do readback
<whitequark> i suspect that's why the ISC interface exists.
<whitequark> since it doesn't have infinite length registers.
<mwk> if your carefully-constructed commands are getting padded with shit
<whitequark> also. take a look at what iMPACT does maybe?
<whitequark> it can generate SVF files for multiple device chains
<mwk> and of course this board has an XCFsomething flash chip in front of the FPGA, so I'm going to run into this issue sooner rather than later
<mwk> ugh impact
<mwk> does this mean I'll actually have to install X on this machine...
<mwk> alright, so the bitgen -g IEEE1532:Yes option is boring
<mwk> it just packages the exact same bitstream (byte-reversed, or rather 32-bit word-reversed) into an .isc file
Bike has joined ##openfpga
<whitequark> hm, 32-bit word-reversed
<mwk> well
<whitequark> what's the size of ISC_PDATA register on your device?
<mwk> .isc is some text wrapping, with a comma-separated array of 32-bit words written as hex
<whitequark> because on xc6s it's 16 bit
<whitequark> but on some others it's 32 bit
<mwk> oh
<mwk> that's supposed to be like that
<whitequark> i'm not sure
<whitequark> i've never looked at 1532
<mwk> they changed the base word size for the bitstream from 32 btis to 16 bits on the Spartan 3E -> Spartan 3A jump
<mwk> ie. xc3sa, xc3sda, xc6s have 16-bit words for everything, everything else has 32-bit words
<whitequark> yep sounds about right
<azonenberg> mwk, whitequark: have you queried the INIT bit for that situation?
<whitequark> mwk: wait. what
<mwk> azonenberg: what situation? the JSTART with blank bitstream?
<whitequark> you mean *pre* xc3sa and *post* xc6s devices all have 32 bit words?
<azonenberg> Yeah
<azonenberg> whitequark: correct, XC6S was the lone departure
<mwk> INIT_B is 1
<azonenberg> almost everything else is 32
<azonenberg> XC6S is xilinx's windows ME
<mwk> not lone, this and Spartan 3A
<mwk> and yes
<mwk> xc6s is *special*
<whitequark> lol windows me
<mwk> it *is* windows me
<azonenberg> i'm serious, it was the architecture that was so bad they stopped having two product lines
<whitequark> looool
<mwk> right
<azonenberg> they killed it, and made spartan7 be a cut down virtex
<whitequark> what was the problem with it
<mwk> it's the single most fucked up family they made
<mwk> oh gods, lots of them
<azonenberg> it's literally the exact same thing ms did with winME
<mwk> I mean, eh
<mwk> lots of little things really
<azonenberg> mwk: also see jtaghal XilinxSpartan6Device.h#86 or UG380 table 5-35
<azonenberg> for spartan6
<azonenberg> crc and idcode error are clearly called out as specific state bits
<mwk> first, the whole chip is just... irregular as fuck
<azonenberg> yeah that alone is a reason why i dont think we will see a f/oss toolchain for it any time soon
<azonenberg> it's massively more work than something like 7 series
<mwk> virtex 4+ have clean column-based architecture
<mwk> virtex 2 / spartan 3 also have some sanity
<azonenberg> s6 doesnt even have square arrays
<azonenberg> they have random cutouts in the corners for GTPs
<whitequark> huh
<mwk> but s6 has just shit sprinkled around everywhere
<azonenberg> you have spots where there's tiny little peninsulas like two or three CLBs wide
<azonenberg> and if you manage to shove any logic in there, good luck making timing
<mwk> yes
<mwk> lots of them
<mwk> then there's the IO clocking clusterfuck
<azonenberg> Big cutout = GTP
<whitequark> azonenberg: 404
<azonenberg> smaller cutout below it = PCIe IP
<mwk> here's the geometry
<azonenberg> oops
<mwk> green == CLB, pink-ish == IO
<mwk> just have a look at left/right side
<mwk> the big pieces of shit at the top are GTPs, the slightly smaller one on the left is PCIE
<mwk> also note the skipped CLBs near the clock column
<mwk> the carry chain just kind of jumps over these
<azonenberg> mwk: btw, are you actually doing dev on s6 tools?
<whitequark> azonenberg: wow the GTP is *huge*
<azonenberg> whitequark: serdes ip in general is massive
<mwk> azonenberg: I'm wrapping up the fuzzers this week
<mwk> still fighting IO clocks
<azonenberg> mwk: I might have an Atlys i can part with for a steep discount on MSRP
<azonenberg> If you want one for testing
<mwk> does it do GTPs?
<whitequark> mwk: that pcie macro isn't small either
<azonenberg> No, it's a LX45 without the -T
<mwk> not of much use to me then, unfortunately
<mwk> already stocked up on non-t
<mwk> and as for other things wrong with spartan 6
<azonenberg> this is a 7a15t/35t/50t die
<mwk> there are just so many differences from other families
<azonenberg> GTP quad bottom left, you can see the change in power distribution mesh at the boundary
<mwk> the clocking setup is batshit
<azonenberg> i want dig to delayer it at some point (it's his specimen)
<mwk> the IO clocks in particular
<azonenberg> note the tx/rx diffpairs paired out and fanning out to bond pads
<mwk> [it's the one last area I'm struggling with fuzzing FWIW -- the IO clocks]
<mwk> I've read the clocking resources guide a few times by now, and still have no fucking clue what's going on
<mwk> it has documentation for attributes that don't actually exist in ISE
<mwk> and doesn't have documentation for some attributes that do
<azonenberg> lol
<azonenberg> hey, at least UG380 fixed some of the bugs in the configuration sequences i found when writing jtaghal
<azonenberg> there are referenes to a couple of webcases in the jtaghal source
<azonenberg> saying "datasheet is wrong, see case #1234, here's how it actually works"
<azonenberg> but the later doc revs fixed that
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<mwk> azonenberg: and yet, still buggy
<azonenberg> at least its not as bad as the grenepak stuff was
<mwk> you're only sending 64 RTIs in JSTART, right?
<azonenberg> (doc wise)
<azonenberg> check the source, i think so
<azonenberg> when i had time to work on greenpak stuff that is
<azonenberg> it got to the point that i had direct email access to the engineer who wrote the datasheets
<mwk> then you'll run into problems with bitstreams that take more time than that
<azonenberg> i was practically sending him diffs
<azonenberg> IIRC the docs said you only needed 16
<azonenberg> and i sent more to be safe
<_whitenotifier-3> [whitequark/libfx2] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjQId
<_whitenotifier-3> [whitequark/libfx2] whitequark 9d6146a - Work around a bug in SDCC 3.5.
<mwk> and that's bullshit
<mwk> you may need *a lot* of cycles
<mwk> if you use LCK_Cycle, the DCM can take quite a bit of time to lock
<mwk> what you really need to do is poll for EOS
<mwk> *and* keep sending JSTART RTIs to it
<azonenberg> I do a single check right now, not a full polling loop
<azonenberg> i guess i never used LCK_Cycle
<azonenberg> so never hit that
<azonenberg> if you want to file a ticket against jtaghal i can add a fix when time permits
<mwk> otherwise the startup machine won't proceed once it's done with locking
<mwk> sigh
<azonenberg> Side note, who decided LCK_Cycle was a good idea?
<mwk> UG380 really is crap
<azonenberg> This is what BUFGCE's are for
<azonenberg> Just gate your output clocks until the PLL output is stabke
<azonenberg> stable*
<azonenberg> (and of course DCMs are a whole other can of worms vs real PLLs...
<mwk> oh, that's part of the fun of spartan 6
<mwk> do you want a real PLL, or a DCM? you got both!
<azonenberg> yeeeeah
<azonenberg> but iirc you can only use the DCMs for certain things?
<mwk> heck, you can even chain them
<azonenberg> there's some weird dedicated paths
<mwk> nah
<azonenberg> i cant recall specifics, but there were situations when using a pll wasnt an option iirc
<azonenberg> maybe i just ran out of them?
<whitequark> what's a DCM?
<mwk> PLLs can route anywhere the DCMs can, and to some places they cannot as well
<mwk> whitequark: digital clock manager
<mwk> kinda-but-not-really PLL
<azonenberg> whitequark: it's basically a PLL with a variable length ring oscillator instead of a VCO
<whitequark> yeah like
<whitequark> oh thanks.
<whitequark> is that... why would you do that?
<azonenberg> so it's a giant ptv-dependent jitter machine
<mwk> on s6, you have two choices
<whitequark> yes. why the fuck would anyone want that
<azonenberg> along the same lines, the s6 IODELAYs are uncalibrated
<whitequark> oh great, so your board heats up adn it has to retrain DDR?
<azonenberg> so you cannot do static timing offsets, you have to experimentally figure out what gives the best BER
<whitequark> really?
<azonenberg> i mean you can do a static offset but it's PTV dependent
<azonenberg> meanwhile in 7 series, the delay lines are controlled by IIRC some kind of bias voltage generator and a feedback circuit
<azonenberg> that adjusts a reference delay line so... 32? taps equals one cycle of a provided refclk
<azonenberg> thus continually compensating for PTV
<mwk> DCM: takes a clock, deskews it wrt feedback clocks, has 9 outputs: 0/90/180/270 phase shift original clock, 0/180 phase shift original clock, original clock divided by a programmable integer (or integer and a half), and a 0/180 phase shift pair of a generated M/D clock
<azonenberg> this is how v6 works too
<azonenberg> s6 and s3 have DCMs because plls were expensive? :p
<mwk> and PLL: takes a clock, divides by D1, multiplies by M, and then has 6 outputs, each divided by independent D2
<mwk> + independent phase shifts for every output
<mwk> but there are twice as many DCMs as PLLs
<azonenberg> yeah, so it's helpful to use them if you can tolerate the downsides
<azonenberg> I don't miss leaving s6 one bit
<azonenberg> all of my projects are now vivado based and using SV on 7 series or ultrascale
<azonenberg> now i just need to find time to improve yosys sv support so prjxray will be able to work on my code...
<whitequark> please start by making always_ff actually do that
<whitequark> instead of being an alias for always
<mwk> whitequark: and oh yeah, delays are uncalibrated
<mwk> and so is on-chip termination
<azonenberg> oh yeah i forgot the termination was uncal too
<mwk> so you can select 50 Ohm impedance
<whitequark> that seems kind of a shit design, to put it bluntly
<azonenberg> OUT_TERM is just an alias for whatever drive strength is nominally kinda close to that
<mwk> and the data sheet says you may get 20 Ohm, or maybe 70 Ohm
<azonenberg> whitequark: as i've said many times before, i consider s6 to be NRND
<mwk> it kind of tries to make up for the "uncalibrated" part by having dynamically reconfigurable I/O though
<azonenberg> There is literally one thing it does better than 7 series, and that's low static power
<azonenberg> but it makes up for that by having much higher dynamic power
<mwk> and Xilinx memory controller IP does crazy shit with it to get DDR working
<whitequark> like what
<mwk> it basically does in gateware what Virtex does in hardware to do DCI / calibrated delays
<mwk> except shittier
<mwk> so you have programmable drive strength, right
<azonenberg> waaait the mig wrapper partial reconfigs the io *drivers*???
<azonenberg> i thought it just did delay calibration
<mwk> the mem IP uses a pin connected to a calibration resistor to kind of try different drive strengths
<azonenberg> that is even more cursed than i remembered the one time i dared look at the generated rtl
<mwk> and when it finds one it likes, it reconfigures all DQ pins
<azonenberg> are you serious
<mwk> and does that continuously
<mwk> azonenberg: completely
<whitequark> what the fuck
<mwk> I had a link somewhere...
<mwk> oh, and s6 is the only FPGA where you actually can reconfigure the drivers at runtime
<mwk> presumably only for that exact purpose
<mwk> azonenberg: oh, here
<mwk> these 8 registers correspond 1-1 to the I/O buffer tile in the bitstream
<azonenberg> my eyes...
<mwk> and here's the cursed state machine
<azonenberg> also wow the code readability there is atrocious
<azonenberg> no blank lines between blocks, etc
X-Scale has joined ##openfpga
<mwk> also, the other files were an "enjoyable" read as well
<mwk> the DRP port for the IOs is also quite... "special"
<azonenberg> i mean the 7 series PLL DRP is literally poking raw bitstream bits too
<azonenberg> but that's at least somewhat documented
<mwk> unlike all the other DRP ports in Xilinx (which are dead simple parallel read/write with plain address and data buses), it is serial
<mwk> kinda SPI
<mwk> and you always have to both read and write
<azonenberg> looool it's probably bypassing the frame logic
<mwk> yes
<azonenberg> and poking raw dff's
<azonenberg> i bet they bodged it on last minute
<azonenberg> and didnt have area to spare
<mwk> but then so is the normal virtex DRP
<azonenberg> so its a giant shif reg
<mwk> correct
<mwk> but not exactly
<mwk> it's quite a complex beast
<mwk> it's crap no doubt, but not last-minute crap
<whitequark> so to get background DRP, there's 2 FFs per 1 config bit right?
<whitequark> background DR*
<mwk> so you can select whether any given IO gets its own DRP port, or is connected to big DRP bus
<mwk> with the big DRP bus connected to the hard mem controller block
<mwk> not *driven* by it, just connected to it, it just kind of passes the signal through to interconnect logic
<mwk> in the "own port" case, you shift register address, then shift register data
<mwk> in the "bus" case, you have mixed parallel/serial addressing
<mwk> you select the I/O via parallel address line, but still select the register serially
<whitequark> so they're just saving interconnect lines to not have wide buses per IOB?
<mwk> yes
<mwk> and my favorite part is this
<mwk> every I/O has a programmable address on this (parallel) bus
<mwk> and for some crazy reason, the default address programmed by bitgen for unused I/Os is 0x13 (which you have to fuzz the FPGA to know)
<mwk> which the mem controller IP carefully avoids
<mwk> the whole thing looks like mem controller had a bug which caused it to accidentally reprogram some random I/Os, and they fixed it in the bitgen by changing the address for unused I/Os to something random which the IP happened to not be using...
<azonenberg> looooooool
<azonenberg> side note, if you ever figure out the root cause of the s6 9kb ram errata
<azonenberg> i would love to see some analysis on that
<azonenberg> (-g INIT_9K)
<mwk> it's pretty self-evident
<mwk> I mean, I don't have details yet
<mwk> but more or less what happens is
<mwk> the configuration logic kind of hijacks the normal BRAM ports to upload initial data
<mwk> standard procedure on all xilinx parts (and probably all FPGAs ever)
<azonenberg> well yeah you arent gonna add a third set of ports
<mwk> but, the bug is that if the ram is in 9k mode, you're restricted to writing half of it
<mwk> because they fucked up and didn't put an override in there for config mode
<mwk> so if you look at the bitstream
<azonenberg> So the high half of the 9k never gets written?
<azonenberg> sorry i mean, the 9k's in the second half of the 18k
<azonenberg> you can init the other half?
<mwk> it uploads the normal frames, except with 9k disabled
<mwk> then uploads the blockram frames
<azonenberg> oh, that's the bugfix?
<azonenberg> then they patch the mode bit
<azonenberg> that's actually really interesting
<mwk> and then sets FAR back to the frame with the mode bit and reupload it, yes
<azonenberg> you should do a little blog article on REing s6 errata
<mwk> I don't know what exactly happens when you config-write a ram in 9k mode, any kind of corruption could happen
<mwk> and fun fact
<mwk> the errata fix conflicts with bitstream encryption
<azonenberg> because you cant do partial overwrites with crypto
<mwk> because encryption requires you to always write the whole bitstream in one go
<azonenberg> yeah i think i recall reading about that
<mwk> as in, once you do an encrypted upload, you cannot overwrite anything without bonking on PROG_B and resetting all memory
<azonenberg> Yeah
<azonenberg> i guess the nicer option would have been to allow overwrites as long as the overwritten data was also encrypted and mac'd?
<mwk> they do that on 7 series
<azonenberg> i dont think that would have broken security
<mwk> cannot do it on spartan 6, because it doesn't support MAC
<azonenberg> aaah ok that makes sense then
<mwk> also I don't know how 7 series encryption works
<mwk> but on Spartan 6 it's... kind of the wrong level to enable secure partial reconfiguration
<mwk> the only thing that is encrypted is frame data, all aux config registers are unprotected
<azonenberg> i havent looked at 7 series crypto yet
<azonenberg> i havent gone below the frame layer
<azonenberg> but if i was doing it, i'd probably go AES-GCM on entire frames
<mwk> oh, and in case you want another reason why spartan 6 is batshit insane
<mwk> it doesn't have constant-length frames
<mwk> as opposed to... well, everything else
<mwk> you have 3 frame types on 6s
<mwk> the normal frames, which are always 16×64+16 bits long, and correspond to a 16-CLB-tail slice of the bitstream
<mwk> the blockram frames, which... to be honest I'm not sure what size they are (I could be off by power of two), but definitely constant and likely the same size as normal frames
<mwk> and the single extra-special IOB frame (singular), which consists of however many bits are required by the IOBs in the device
<mwk> 64 bits per IOB plus 384 bits per IO clock tile (one per side)
<mwk> and it's kind of circling around the whole device
<azonenberg> mwk: well you know how cursed the coolrunner bitstreams are right?
<mwk> I've heard bits of that
<mwk> but haven't looked closely
<azonenberg> the 2c32a is a 48 row x 260 bit array
<azonenberg> that is literally splatted right into the physical layout of the chip
<mwk> you know what
<mwk> so are FPGAs
<azonenberg> noo you misunderstand though
<azonenberg> the generated .jed file is logically addressed
<azonenberg> so you have a block for the and array, a block for the or array, a block for macrocells, a block for routing
<azonenberg> then you have to go through a giant undocumented permutation to put the bits from that into the jtag shift register
<azonenberg> mirroring things and interleaving the various portions of the array as you go
<azonenberg> I RE'd the permutation and it maps perfectly to the die layout
<azonenberg> and it made REing the bitstreams vastly easier
<azonenberg> But why not generate a bitfile in physical address space?
<azonenberg> a jed is supposed to be something you can serialize right out to the DUT
<azonenberg> it isnt supposed to need a MMU in the way :p
<mwk> yeah
<mwk> heh
<mwk> btw, as for what's below frame level...
<whitequark> azonenberg: similar for xc9572
<whitequark> which i re'd
<mwk> it's the same kind of hell
<whitequark> *xl
<azonenberg> side note, i love this community
<azonenberg> being able to actually complain about the cursedness of fpga bitstreams *and have somebody understand*
<azonenberg> lol
<mwk> bits arranged in whatever two-dimensional patterns will route nicely to the underlying gates
<azonenberg> yeah but that makes sense
<azonenberg> the .bit file has them in that order
<mwk> consider the Virtex 6 and 7 CLBs
<azonenberg> you arent optimizing for readability of the bitstream
<mwk> they are functionally completely identical
<azonenberg> the coolrunner jeds are very readable
<azonenberg> even with comments
<mwk> same capabilities, same attributes, exact same bits
<azonenberg> and wait, v6 and 7 series clbs are the same? they didnt change anything at all in the primitive structure?
<mwk> hell, the bitstream tile has the same dimensions
<azonenberg> just re-layout?
<mwk> but... the bitstream arrangement is different
<azonenberg> well yeah
<mwk> someone spent a lot of time moving these bits around to correspond to 28nm geometry
<azonenberg> i know the s6 clb is way different
<mwk> oh, it's not way different
<mwk> just a bit different
<azonenberg> Die, SLICEX
<azonenberg> killing that was the single best thing about 7 series
<azonenberg> i can put adders and wide muxes in every slice now
<mwk> eh
<mwk> right, SLICEX
<mwk> kind of forgot it was a thing
<mwk> fun fact: the documtation of that thing is buggy
<azonenberg> oh?
<mwk> shows a mux path that isn't there (O6 -> [ABCD]MUX)
<whitequark> what's up with AR34541?
<mwk> really non-obvious, because the output obviously exists, and is routable to [ABCD]MUX in SLICEM and SLICEL
<mwk> and when you emit .xdl files because you want to do your own P&R, the xdl hw description also lists O6 as a valid choice for that mux
<mwk> but xdl will fail conversion with some non-descript error message referring to random things
<mwk> I've had a *lot* of fun figuring out the root cause, because the dumb thing never said what its problem was
<mwk> whitequark: huh, no idea; just some random bug?
<mwk> I mean, the blockram really is crap on this device
<mwk> (see the INIT_9K discussion above)
<whitequark> mm
<mwk> also, xdl allows you to specify a 16kbit SDP RAM
<mwk> but it's not mentioned anywhere in the datasheets as an allowable configuration
<mwk> my guess is it turned out broken as well
<mwk> oh, and my favorite part of spartan 6 has to be the low-power version
<mwk> which is probably the exact same chip except you power it with 1V instead of 1.2V
<mwk> and apply a hilarious amount of workarounds to make it actually work
<mwk> as in, the datasheet has a long list of features you're not supposed to use, the generated bitstreams are slightly different, and synthesis has to insert some "fix-up" circuitry to look at undocumented DCM status bits and bonk on the reset button enough times to make it lock correctly
<whitequark> *what*
<whitequark> it does *fucking what*
<mwk> pages 81, 82
<mwk> enjoy
<mwk> don't ask me what this does, I have no clue
<whitequark> ...
<sorear> ecp5 5g’s evil twin?
Bike has quit [Quit: Lost terminal]
<Sprite_tm> Whaoh, and I thought some of the workaround the CPU people try to sneak past the radar are funky sometimes.
m_w has joined ##openfpga
<mwk> oh heh
<mwk> and I just remembered
<mwk> on the topic of crazy circuits inserted by xilinx software
<mwk> let me find a link...
<mwk> ahh, there it is
<mwk> so you have this shiny new Virtex 2 Pro FPGA with two hard PPC cores embedded (the left core and the right core)
<mwk> and it's a -7 speed grade FPGA, too
<mwk> so you can just connect a 350MHz clock to the PPC cores and everything will be fine
<mwk> but it turns out that these PPC cores could do 400MHz, but there's a little problem with the clock circuit
<mwk> and Xilinx provides a handy little macro that you can insert in yout clock path and fix it so that the left PPC core can do full 400MHz
<mwk> (the right PPC core doesn't need the macro and can always do 400MHz for some reason)
<mwk> so I've looked at the macro and... it does duty cycle distortion, for some reason the PPC core needs slightly longer 0 period than 1 period to do full 400MHz
<mwk> the macro is actually hand-placed and hand-routed, and consists of: 1 LUT1 that buffers the incoming clock, and 1 LUT2 that is just an AND gate that ands the clock with itself
<mwk> but the two inputs are routed differently; one is a direct connection, while the other is routed several columns over and back
<Sprite_tm> Huh. Instant lower duty cycle thanks to light speeds.
<mwk> effectively reducing the clock high period by the routing delay
<mwk> yup
<Sprite_tm> Gotta give props to the engineer who went 'I think I can fix this, but it's going to be tricky...'
<mwk> certainly a clever solution
<mwk> I also particularly love how that application note never mentions anything about duty cycles
<mwk> it just says that the clock requires "special considerations"
<Sprite_tm> *deeper magic* /me handwaves... You're not supposed to understand this...
Richard_Simmons3 has joined ##openfpga
<mwk> just use our... special considerations insertion macro
Richard_Simmons has quit [Ping timeout: 264 seconds]
rohitksingh has joined ##openfpga
<sorear> I guess you could call that "light" speeds
Jybz has joined ##openfpga
mkdir has joined ##openfpga
<mkdir> huddo
<mkdir> how do i send serial data from ice40 to the comp
<mkdir> over uart - is it $display?
<mkdir> or some other way
<sensille> mkdir: erm. normally i add a uart and fifo to my design and the state machine to fill it. $display is for simulation
<mkdir> thanks sensille
<mkdir> im currently looking for tuts, but can't find anything...
<sensille> it's not the easiest way to get debugging information
<mkdir> is it hard to add uart and fifo
<sensille> if that's what you want
<mkdir> I just need to get sensor data to plot
<mkdir> is there a better way?
<sensille> so it's a regular part of your design?
<tnt> for debug, if simulation isn't possible you can export some internal signals to pins and use a logic analyzer.
<sensille> or use some internal debug/LA core
<mkdir> sensille yes
<tnt> sensille: on an ice40 it's rarely an option
<sensille> but to regularly transport data to a PC uart is fine, especially because it's easy to receive
<mkdir> cool yeah it is a regular part of my design
<mkdir> as I mentioned, I wanna run some computation and plot data
<tnt> mkdir: What board is that on ?
<mkdir> lattice ic40
<mkdir> ice40
<sensille> mkdir: i'm using this uart in my design: https://github.com/cyrozap/osdvu
<mkdir> cool what's the fifo?
<tnt> board, not chip
<sensille> (just a more or less random choice)
<mkdir> tnt icestick
<sensille> there are tons of fifos available, but i just wrote my own stupid one
<mkdir> what is the fifo used for? I'm not familiar
<mkdir> I have used the uart communication protocol before though
<sensille> so you can generate data in burst, faster than they are transmitted
<mkdir> oh I see, it's a queue
<sensille> your design might or might not need it
<sensille> yeah
<tnt> yeah, on the icestick, uart is pretty much the only option to talk back to the PC
<mkdir> alright thanks tnt
<sensille> PC or *pi?
<mkdir> PC
<mkdir> basically I for not I have a clock circuit or clock divider and I just need to send data when it switches from high or low
<mkdir> so that I can plot it and see the signal
<sensille> probably enough to hold the data in a register and have a state machine that sends it to the uart
<sensille> tnt: i don't know the icestick, does it have an external uart you can use or would you implement your own in fpga?
<tnt> sensille: you need to implement it in the fpga, but it has a couple of pins connected to a FTDI
<mkdir> thanks both - I will try implementing this tomorrow
<mkdir> gn
<sensille> have fun
<mkdir> ty
<mkdir> and also ty for the link
mkdir has quit [Remote host closed the connection]
emeb_mac has quit [Ping timeout: 245 seconds]
zng has quit [Ping timeout: 245 seconds]
implr has joined ##openfpga
Jybz has quit [Remote host closed the connection]
implr has quit [Ping timeout: 268 seconds]
q3k has quit [Ping timeout: 264 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
Jybz has joined ##openfpga
implr has joined ##openfpga
_whitelogger has joined ##openfpga
m4ssi has joined ##openfpga
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
<ZirconiumX> My DE-10 arrived. Hopefully it keeps its magic smoke safely contained inside, but we'll see.
Jybz has quit [Ping timeout: 252 seconds]
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
rohitksingh has quit [Read error: Connection reset by peer]
emeb has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<mwk> whitequark: a few initial observations on ISC
<mwk> first, stuffing any of the 5 ISC opcodes (ISC_ENABLE, ISC_DISABLE, ISC_NOOP, ISC_PROGRAM, ISC_READ; presumably more for newer FPGAs) into IR instantly activates HIGHZ mode
<mwk> the FPGA keeps running, but with unconnected outputs
<mwk> further, ISC_ENABLE is kind of equivalent to JSHUTDOWN and ISC_DISABLE to JSTART, but with one extra thing
<mwk> there is this ISC_ENABLED flag in status register; ISC_ENABLE sets it once it's done with the shutdown sequence and ISC_DISABLE unsets it once it's done with startup sequence
mumptai has joined ##openfpga
<mwk> ISC_ENABLED == 1 also forces the FPGA to HIGHZ mode, so if you ISC_ENABLE and then JSTART, the FPGA goes through startup and is running, but still in HIGHZ mode until you actuall do ISC_DISABLE
<mwk> oh, and you clock both of these sequences using RTI like JSTART/JSHUTDOWN
<mwk> so... ISC_PROGRAM/ISC_READ is unfortunately unsuitable for live reconfig / readback because of the HIGHZ thing :(
<mwk> further
<mwk> executing JSHUTDOWN once the device is configured doesn't clear the ISC_DONE flag (aka the EOS flag)
<whitequark> yep, seems right
<mwk> so when starting the device back up with JSTART, there is no way to know whether you're actually done just by looking at the status register
<whitequark> you reverse engineer it faster than i can write it up :S
<mwk> you can probably tell by looking at the config port STATUS register
<mwk> but if you do this via ISC_PROGRAM/ISC_READ, you enable the HIGHZ mode and lose
<mwk> and if you want to do it via CFG_IN/CFG_OUT, you have to figure out how to deal with a non-single device on the chain...
<whitequark> CFG_IN is fine
<whitequark> there's a noop instruction right
dh73 has joined ##openfpga
<mwk> well yes
<whitequark> 2000...
<whitequark> wait, they go in MSB first
<whitequark> so the FPGA can be... only the second in the scan chain?
<mwk> but if you want to use it to read back a config port register, you have to synchronize it and figure out how to deal with extra bits you have to pad
<mwk> yes
<mwk> the board I'm using has exactly that
<whitequark> what does 0000 do?
<whitequark> i know iMPACT uses the 0000 command
<whitequark> or whatever it is
<mwk> it is AVR programmer -> xilinx PROM -> FPGA -> AVR
<mwk> hmm, or is it FPGA -> PROM
<mwk> doesn't matter; I've seen both configurations already
<mwk> 0000 is a noop
<whitequark> oh then this isn't a problem
<mwk> isn't it?
<whitequark> because BYPASS is loaded with 0
<mwk> yes, but
<mwk> you still have to time the CFG_IN -> CFG_OUT change right, I think
<whitequark> you have to shift 16-prefix zeroes in at the start
<whitequark> and shift 16-suffix more dummy bits out of CFG_OUT
<whitequark> that's not so hard
<whitequark> but it requires making the TAPInterface abstraction in Glasgow a bit more leaky
<whitequark> but that's fine I guess
<mwk> yes
<mwk> unless you have more than 16 devices you have to BYPASS in front / behind it
<mwk> though I suppose if you have 16-device scan chains you're already in hell
<whitequark> x=16-prefix; while x<0: x+=16
<mwk> hmm
<mwk> oh, you're right
<mwk> of course
<mwk> the only potential issue is whether the extra read cycles you perform via CFG_OUT will be a problem
<whitequark> yes
<whitequark> i *think* it's not actually an issue
genii has joined ##openfpga
<mwk> yeah, shouldn't be
<mwk> alright
<mwk> let's try out some shit
<mwk> *sigh* so what the fuck is ipython doing
<mwk> In [284]: byterev
<mwk> Out[284]: b'\x00\x80@\xc0 \xa0`\xe0\x10\x90P...
<mwk> In [285]: bytes(byterev[x] for x in b'abcd')
<mwk> NameError: name 'byterev' is not defined
<mwk> does IPython.embed() give you some kind of fucked up class scope...
<whitequark> mwk: also they mention some sort of "sync word"
<whitequark> oh, aa995566
<mwk> yes
<whitequark> yeah i'm guessing you can actually shift absolutely whatever into CFG_IN *if* you go through TLR
<mwk> hmm
<mwk> how?
<whitequark> i think it ignores everything before aa995566
<mwk> yes, that is correct
<whitequark> fun thing to test: does it even need you to maintain byte boundaries?
<mwk> nope
<whitequark> then you don't need to care about the devices before it in the chain at all
<whitequark> just go through TLR
<mwk> hmm, does TLR desync the config machine?
<whitequark> the docs seem to imply that
<mwk> that does make sense
<whitequark> oh, you sort of do need to care, i think
<whitequark> to push the tail of the configuration in
<whitequark> but that's easier
<whitequark> oh, and that wouldn't even violate the abstraction, right?
<mwk> right, you just pad it with extra nops
<whitequark> because you already shift in the suffix
<whitequark> no, you don't need extra nops
<mwk> oh
<mwk> right
<whitequark> you already shift in 0 there
<mwk> yes, of course
<whitequark> and actually, no
<whitequark> you don't need extra nops because the device won't see those extra bits
<whitequark> they'll get stuck in BYPASS before it
<mwk> correct
rohitksingh has joined ##openfpga
<whitequark> btw re our convo earlier about ISC_PROG
<whitequark> i looked at the SelectMAP interfac
<whitequark> it is *also* bit-reversed per byte regardless of width
<whitequark> so i *think* the ISC_PROG register will be bit-reversed per byte regardless fo its width
<mwk> that's just Xilinx numbering shit from MSB though, isn't it?
<whitequark> but not sure
<whitequark> it has a discontiguity in the middle
<mwk> but yes, if the .isc file bitgen spit out is correct, it's going to be bit-reversed
<mwk> hm no
<whitequark> per byte or per word?
<mwk> .isc is word bit-reversed
<whitequark> hm wtf
<whitequark> have you tried programming it yet
* daveshah
<mwk> no, I'm trying to get my tools to stop being shit first
<mwk> also I'm testing a different thing right now
<daveshah> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
<daveshah> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
<daveshah> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
<daveshah> crap sorry
<daveshah> shouldn't have been trying to fix keyboard while reading irc
<mwk> that never ends well
<mwk> what.
<mwk> so now I'm shifting in CFG_IN and *not* discarding the TDO output
rohitksingh has quit [Ping timeout: 258 seconds]
<mwk> it seems to be spewing out random crap, unrelated to what I put in
<mwk> hm, or are my tools being shit again
<whitequark> it might be floating
<whitequark> lemme check with glasgow
q3k has joined ##openfpga
<mwk> okay, so what happens is
<mwk> CFG_IN's TDO is whatever was on CFG_IN's TDI 64 cycles ago
<mwk> (persisted across IR changes including JPROGRAM)
<whitequark> iiinteresting
<mwk> which matches up with something I recall reading in one of the config guides, not sure for which FPGA
<whitequark> ganged configuration?
<mwk> which said that you have to align config packets going into JTAG to 64 bits, not 32 as should be expected
<mwk> and if you're doing readback, you may or may not have to insert a 32-bit nop, depending on where you are in the 64-bit alignment
<mwk> this is... not something I'm happy about
<mwk> (not sure what the equivalent numbers are for xc6s)
<mwk> whitequark: nah, I think there just is a 64-bit shift register which controls the packet parser
<mwk> and the bits falling off the end are kind-of an accident
<whitequark> lol
<mwk> Configuration Register (Boundary-Scan)
<mwk> The configuration register is a 64-bit register. This register allows access to the
<mwk> configuration bus and readback operations.
<mwk> very helpful, user guide, very helpful
<whitequark> wait
<whitequark> on xc6s it's 16-bit
<mwk> ah, found it
<whitequark> on xc3e it's 64-bit *but* the ISC_PROG is 32bit?
<whitequark> hwaet?
m4ssi has quit [Remote host closed the connection]
<mwk> All packet headers pass through a 64-bit buffer before reaching the packet processor; the
<mwk> packet processor itself interprets all commands in 32-bit words. To flush the last command
<mwk> in a sequence from the packet buffer, a sequence of configuration commands must end
<mwk> with least four 32-bit NOOP commands. Typically, this is found at the end of a bitstream, as
<mwk> shown in Table 4-18. JTAG read operations must consist of an even number of words in the
<mwk> command sequence.
<mwk> so
<mwk> the bitstream is 32-bit word oriented, but there's a 64-bit buffer along the way
<mwk> whitequark: the xc6s bitstream is 16-bit word oriented, that's for sure
<whitequark> ah
<mwk> but who knows what kind of buffers are there
<mwk> and xc6s config documentation is shit compared to xc2v, because you're not actually supposed to reconfigure spartans
<whitequark> "four NOOPs to clear the packet buffer"
<whitequark> so it's a 64-bit buffer too
<mwk> plausible
<whitequark> lemme try to measure DR length
<mwk> ISC_PROGRAM is 32 bits long though
<azonenberg> mwk: oh yeah this was the part of ug380 i found bugs in
<mwk> so how does this work
<mwk> 64-bit shift register, that much is clear
<azonenberg> With SLR-based FPGAs its even more fun
<mwk> and every 64 bits, there is a strobe that pokes packet processor, presumably
<azonenberg> i dont think i ever fully got that debugged
<mwk> with the strobe getting initially aligned when it finds the sync word
<azonenberg> but basically the SLR FPGAs are several dies with TDI/TDO ganged
<azonenberg> except all but one die are in a slave mode with no idcode or bypass register
<mwk> now how does this relate to normal JTAG capture/load flow
<azonenberg> So you get a m* wide IR and have to splat the IR out to all of the dies
<mwk> *sigh* ir probably doesn't
<mwk> azonenberg: ... and there's a special IR value that *does* include the other dies in the DR chain, yes
<mwk> it's "fun"
<mwk> so have you actually poked at one?
<azonenberg> I have a pair of vu9p's
<azonenberg> vcu118s
<azonenberg> i played with it but dont think i got them to boot fully yet
<azonenberg> need to get back to that soon
<mwk> I only had the pleasure of looking at a bitstream for one of those
<mwk> it's kind of batshit
<mwk> so it configures the first die, starts it up, desynchs the config interface
<azonenberg> yes
<azonenberg> I call that extra instruction "SLR_BYPASS"
<mwk> and then goes "ah, changed my mind", resyncs config, SHUTDOWNs the first die
<mwk> and uses a secrit command to enable bitstream forwarding to the *second* die
<whitequark> wtf
<mwk> then it starts the second die
<azonenberg> There's also an ISC_NOOP in there somewhere that i dont fully understand the point of
<azonenberg> nto mentioned in the datasheet but the generated bitstreams have it
<mwk> then *again* desynchs it, resynchs it, and configures the third die
<mwk> I think the startup sequence doesn't actually finish because DONE is still being pulled low by the other dies
<whitequark> i remember that ganged tdi/tdo is a common arrangement in die stacks
<mwk> but still, what
<azonenberg> whitequark: it isnt fully ganged
<whitequark> i mean
<azonenberg> because IR is 6*ndies bits wide
<whitequark> cjtag explicitly calls this out as a reason jtag is bad for multidie
<azonenberg> anyway i want to get this working once i set up the virtex boards in the new lab
<azonenberg> which is a few days out probably
<azonenberg> the big holdup right now is getting fiber pulled to the lab benches so i can get 10/40GbE from them to the core switch
<azonenberg> and the fiber is taking its sweet time to ship since its all custom lengths
<mwk> and *why*
<mwk> I mean, it'd be so simple to just make the thing visible as 4 devices on the chain
<mwk> but it has to pretend to be one device with a single-bit BYPASS register and all
<daveshah> I guess the whole marketing image is a single "3D FPGA" not four cheaper FPGAs and some superglue
<whitequark> lmao
<mwk> right, "3D"
<mwk> my ass
<mwk> it's the same story with Virtex 2/4/5 PPC cores btw
<mwk> they have their IRs in series with the FPGA one
<mwk> but they pretend to be one device with the FPGA skipping the PPCs in the DR chain unless you load the special "PPC bypass" opcode
<azonenberg> meanwhile zynq is sane
<azonenberg> in this regard
<whitequark> mwk: wait. what
<azonenberg> its an arm soc with an fpga bolted on and looks like that over jtag
<mwk> though I guess they haver a better rationale for the PPCs
<whitequark> *skipping* the PPCs in the DR chain?
<mwk> because the JTAG chain is actually connected to the PPCs in soft logic
<mwk> and it would be a shame if putting the FPGA in programming mode severed the JTAG chain
<mwk> maybe that's the precedent for the SLR bullshit
<azonenberg> meanwhile zynq has a tap for the FPGAs and a config strap to specify whether the arm should be in series with that tap
<azonenberg> or routed out to fpga fabric
<azonenberg> in the latter case you can jtag the arm via any four fpga gpios or a soft jtag master in the fpga fabric
<mwk> I guess that's because zynq is a CPU with an FPGA bolted on
<mwk> while Virtex 5 is an FPGA with a CPU bolted on
<mwk> whitequark: it's a clever thing really
<mwk> so the issue is that you want these PPC cores to be JTAGable by either fabric or external master
<mwk> and the cores export their JTAG pins to the fabric as ordinary interconnect i/o
<whitequark> mwk: no, i get that
<whitequark> i mean
<mwk> then, you have this JTAGPPC singleton primitive which you can connect to these if you want to hook them up to FPGA JTAG
<nats`> guyz guyz....
<whitequark> oh, nvm, i misread
<nats`> please let the dead alone
<whitequark> it makes total sense
<nats`> RIP V2P V4P and V5
<whitequark> misread if as else
<whitequark> if as unless*
<mwk> and to avoid thigns getting screwy, how it works is
<daveshah> nats`: this kickstarter doesn't agree
<mwk> for DR, the TDO is only connected to FPGA's TDO if you shift in the PPC bypass IR
<nats`> ....
<nats`> oO
<mwk> and for IR, the FPGA handles it on its own, it has a 14-bit shift register (6 bits for FPGA, 8 bits for PPCs)
<nats`> what a loss
<mwk> and it mirrors the IR for PPCs into JTAGPPC's TDI
<mwk> so if PPC JTAG is broken, it doesn't break the IR chain
<nats`> I worked with those monster and I'll not get back from Serie 7 and US.... (unless for S6 if needed)
<whitequark> mwk: so, i measured CFG_IN/CFG_OUT on xc6s
<whitequark> it's 16 bit
<mwk> what
<whitequark> D: g.applet.interface.jtag_probe: JTAG-H: scan dr length=16 data=<0000000000000000>
<whitequark> don't ask me lol
<mwk> so the datasheet lies?
<mwk> I mean
<mwk> about the 4 words alignment
<whitequark> i... have no idea?
<mwk> sigh
<whitequark> my brain hasn't booted up yet so i can't check it
<mwk> there could still be buffering, just somewhere else
<azonenberg> daveshah: why the hell would you use a virtex 5 in this day and age
<azonenberg> an artix7 is going to be faster, cheaper, more power efficient, and more
<mwk> cool hat
<daveshah> I can only assume someone has a big pile of them
<nats`> 25 daveshah
<nats`> that's a small pile
<azonenberg> mwk: and yeah i suspect it's a 4 word fifo that strobes every 16 tck cycles?
<nats`> but still apile
<emeb> I've gotten a lot of use out of a MiniZed I bought last year. Cheap, plenty of I/O, reasonably good support.
<nats`> yep
<nats`> using the microzed on my side
<nats`> integrated on a custom carrier :)
<emeb> built some I/O boards for it (Arduino headers, PMODs) and did some SDR experiments.
<ZirconiumX> I'm kinda curious why the MiSTer project picked the DE-10 Nano as a base platform
<emeb> 6 vs 1/2dozen - just depends on what the originators were familiar with. Terasic stuff is reasonably priced.
<ZirconiumX> True I suppose
<emeb> I was working a contract for some DSP stuff a few years ago and we were choosing an FPGA SoC platform. At that time the Cyclone boards from Terasic were a lot easier to find and cheaper than the Zynq based stuff.
<ZirconiumX> That's fair
<emeb> That was before Digilent released the first Zybo, so the only things you could get for Zynq were the full-sized Zedboards and they were in the $500 range...
<ZirconiumX> I think the DE-10 will probably be the initial target board for Mistral
<ZirconiumX> ~~simply because I have one~~
<emeb> Yep.
<emeb> Now of course you can get fully featured Z-Turn Lite boards for ~$60.
<emeb> Only downside to those is the I/O is on high-density connectors that are a bit harder to use than PMODs.
<mwk> hmm wtf
<mwk> ISC_PROGRAM is 32 bits long
<mwk> but ISC_READ is.. 69 bits long
<whitequark> nice
<mwk> certainly, but wtf
<whitequark> uh... valid, valid_hi, valid_lo, word_hi, word_lo?
<mwk> and ISC_NOOP is 5 bits long
<whitequark> mwk: oh btw
<whitequark> ISC_NOOP selects "ISC_CONFIG"
<whitequark> same as ISC_ENABLE and ISC_DISABLE
<whitequark> accroding to bsdl
<mwk> yes
<whitequark> wait
<whitequark> wait, no
<whitequark> it selects "ISC_DEFAULT"
<mwk> it seems IEEE 1532 defines a semi-standard status register
<whitequark> which is the same size as ISC_CONFIG
<whitequark> ah
<mwk> which ISC_NOOP accesses
<mwk> and is *also* chained in front of ISC_READ (which explains a bit) and in front of ISC_PROGRAM (which seems to be a lie)
<whitequark> right
<mwk> ISC_ENABLE and ISC_DISABLE are also 5 bits long FWIW
<mwk> this matches
* mwk continues reading
rohitksingh has joined ##openfpga
<mwk> hrm, wonderful specification
<mwk> doesn't actually specify what the status register *is*
<mwk> it just says there may or may not be one
<mwk> it doesn't actually seem to specify much at all
<whitequark> lol
<whitequark> mwk: so i'm doing something cursed
<whitequark> clock in JPROGRAM, then watch the IR while shifting in BYPASS
<whitequark> so that it loads from the memory
<mwk> you know what, fuck that
<mwk> fuck the standard and fuck the bsdl file
<mwk> I'll just blackbox this, because of them seem to be made of 70% lies
<mwk> so there is some sort of ISC status register indeed
<mwk> 0b00000 when in unprogrammed state, 0b01110 when in unprogrammed + ISC_ENABLED state
<mwk> and when you read ISC_READ, the low 5 bits are the ISC status register
<mwk> also, apparently the high 64 bits of ISC_READ are writable
<whitequark> but why
<mwk> *shrug* shift register
<mwk> in some circumstances it seems to overwrite half of my value (32 bits) with 0s, presumably because I triggered a read somehow
zino has quit [Ping timeout: 272 seconds]
<whitequark> oh wait
<whitequark> is the high part of ISC_READ the command and the low part the result?
<mwk> I... don't think so
<mwk> but could be
<mwk> also that would be "high high" part
<mwk> it's a 32-32-5-bit register
<whitequark> low, high, and high high?
<mwk> I guess we should settle for high, low, and status
zino has joined ##openfpga
<mwk> alright, let's actually try to read something
<whitequark> "high high" is what the designers of this interface were
<mwk> another random observation: JPROGRAM does not deassert ISC_ENABLED
<whitequark> yes, xc3sprog does ISC_ENABLE; JPROGRAM
<whitequark> for no very good reason
<whitequark> other than reading ISC_DNA perhaps
<mwk> IEEE 1532 says you're not supposed to shift in any non-ISC command without doing ISC_DISABLE by the way
<mwk> guess that's another thing noone cares about
<whitequark> of course
<mwk> arrrgh
<mwk> and if you JPROGRAM and then try to ISC_DISABLE
ZipCPU has quit [Quit: ZNC 1.6.4 - http://znc.in]
<mwk> then you've just executed a successful startup sequence with no bitstream and of course DONE goes high on this device
<whitequark> mwk: on xc6s, ISC_ENABLE plus clocking RTI gets DONE=0 ISC_DONE=1
<whitequark> i'm confused
<whitequark> wtf is ISC_DONE?
<mwk> EOS I think
<mwk> that's consistent with my results too
<whitequark> hm, yes, if I JPROGRAM, it goes low
<mwk> I don't know if it can be pulled low short of JPROGRAM
rohitksingh has quit [Ping timeout: 245 seconds]
ZipCPU has joined ##openfpga
ZipCPU|Alt has joined ##openfpga
<mwk> my attempts at programming the FPGA via ISC_PROGRAM are failing miserably
zino has quit [Excess Flood]
rohitksingh has joined ##openfpga
zino has joined ##openfpga
ZipCPU|Alt has quit [Quit: Cap'n! The dilithium crystals are ...]
<mwk> aha!
<mwk> got it
<mwk> you have to load 32 bits per shift
<mwk> and do an RTI cycle after every 32 bits
<mwk> no RTI == no worky
<mwk> any non-0 amount of RTI cycles is acceptable, matter of fact
<mwk> using ISC also requires you to maintain word alignment
<mwk> if you shift the bitstream by one byte, it no longer configures
<mwk> presumably because it doesn't use the "serial config mode" deserializer
<whitequark> ooooh
<whitequark> so what is the bit order for ISC_PROGRAM?
<mwk> same as for CFG_IN...
<whitequark> so, bit reversed bytes?
<whitequark> 4 at a time?
<mwk> you just have to chop it into 32-bti units
<mwk> yes
<whitequark> hrm
<whitequark> why are they bit reversed, i wonder
<whitequark> stupid ass behavior
<whitequark> oh right
<whitequark> SPI flashes...
<mwk> it's inconsistent with sanity
<mwk> but consistent with CFG_IN
<whitequark> Xilinx® All Inconsistent With Sanity
<whitequark> oh oh i know what "IS" in "ISC" means now.
<mwk> heh
<mwk> alright, so I can program shit with ISC
<mwk> that's... not particularly useful given that CFG_IN is less hassle
<mwk> for a full bitstream, at least
<mwk> so let's try reading now
<mwk> it seems you also have to clock RTI with ISC_READ to actually read shit
rvense has quit [Quit: leaving]
zino has quit [Ping timeout: 248 seconds]
rohitksingh has quit [Ping timeout: 272 seconds]
<whitequark> right
<mwk> alright, finally
<mwk> got that damn readback
zino has joined ##openfpga
<mwk> ISC_PROGRAM <- sync word + read IDCODE + two NOPs [with RTI after each word]
<mwk> then load ISC_READ, RTI, and read from DR, the (reversed) readback value is in the low word
<whitequark> nice
<whitequark> what about the high wor
<mwk> *shrug*
<mwk> I'll try reading several words and see what happens
<mwk> alright
<mwk> so you always read 2 words at a time
<mwk> if I submit a "read 5 words from IDCODE" packet
<mwk> and start ISC_READing, I get: 2× (IDCODE, IDCODE), 1× (0, IDCODE), inf× (0, 0)
<mwk> also: probably unsurprising, but ISC_PROGRAM/READ doesn't work without lighting ISC_ENABLED
<mwk> again I don't understand something
<daveshah> Hehe, just realised some of the commands in ECP5 bitstreams are actually 1532 commands (e.g. the command to set usercode is called ISC_PROGRAM_USERCODE and also defined thus in the BSDL file)
<mwk> so as long as IR has any ISC_* command in it, the outputs are in HIGHZ
<mwk> but, ISC_DISABLE is also effectively JSTART
<mwk> so as you go through the startup sequence, you enable GWE, and the clocked logic inside FPGA goes active
<mwk> but your outputs are still disconnected for as long as it takes the programmer to notice that ISC_ENABLED went low and change IR to BYPASS for whatever
<mwk> this... won't work all that well for lots of circuits
<mwk> *sigh* confirmed, the design is already running and blinking LEDs while opcode is still ISC_DISABLE
<mwk> and the LEDs are disconnected
<mwk> can I just conclude that ISC is a steaming pile of shit?
<ZirconiumX> Can't you conclude that for most things?
<mwk> daveshah: so how does this work? do the packet processor and JTAG share some of the command set on ECP5?
<daveshah> Yup
<mwk> because they're almost completely separate on xilinx
<mwk> JSTART/JSHUTDOWN being the notable exceptions
<daveshah> There's also a command LSC_BITSTREAM_BURST that fires TDI directly into the bitstream packet processor (I think similar to CFG_IN in Xilinx?)
<mwk> that sounds like CFG_IN, yes
<daveshah> Incidentally, someone recently hit an interesting problem where the chip failed to program if you had a SPI mode command (e.g. to enable QSPI in a flash bitstream) in the bitstream given to that instruction
<mwk> does... does it enable quad-JTAG in this case?
<mwk> that would be hilarious
<daveshah> Alas not
<daveshah> Just sets various meaningless error bits in the status register
<daveshah> Although perhaps it is actually trying to talk to the flash
<daveshah> I should check that
<whitequark> quad-JTAG
<whitequark> i'm not sure if i love or hate it
<whitequark> it's certainly disgusting
<sorear> does it use both edges of TCK?
<whitequark> sorear: aaaaaaa
<azonenberg> {TDI, TDO, TMS, TRST} on rising and falling tck edges
<azonenberg> for 8x the jtag bandwidth :D
<whitequark> daveshah: no. no no no no
<mwk> daveshah: aaaaaaaaaaa
<tnt> mwk: well, did you see spy-bi-wire ?
<tnt> it's serialized tms/tdi/tdo in 3 'clk' timeslots.
<whitequark> azonenberg: nonono, that's too straightforward
<whitequark> you have to sample TMS only on like every 2nd edge
<whitequark> and TRST would be totally asynchronous and with some annoying setup/hold constraint to TCK
<whitequark> and there should be like 5 "modes" and which one you can use you only learn after interrogating the device in the slowest one
<mwk> I think every 4th clock should be TMS
<mwk> and every 16th TRST
<davidc__> heh, I've seen a debug protocol that manages to combine the worst of both worlds between I2C and a synchronous bus
<davidc__> (device originates "debug clock". Debug IO pin is open drain
<davidc__> Periodic framing bit is sent (10 bits IIRC?) on the debug IO pin from the device
<davidc__> IIRC, one of the bits also signals an "interrupt" from the device to host; and the remaining 8 bits are used bidirectionally to convey higher protocol layer bytes in each direction
<whitequark> daveshah: that... that reminds me acutely of PS/2
<whitequark> it's almost identical in many aspects
<whitequark> davidc__: * sorry
<davidc__> For bonus points, the debug clock changes wildly during device boot, since its derived directly from the core clock
<davidc__> so as you change the core PLL / etc, the debug clock changes with it
<davidc__> (including bonus glitches during clock change!)
<sorear> Does that require a wire short enough that propagation delays are ignorable?
<davidc__> Probably. The only debugger for this monstrosity is the vendors debug tools; and it has a captive cable
<davidc__> (might explain why it has a captive cable!)
<whitequark> ha
<davidc__> vendor's tool was $2k or so.... supported a total of 3 parts (very very niche but high volume part)
<davidc__> Internally, it was just a cypress USB bridge + FPGA (similar to glasgow) but much older parts
<implr> that's a quite popular combo, xilinx's platform cable is like that too
<whitequark> fx2 is a super common thing to put together to an fpga
<daveshah> Saw one video capture card which was PCIe -> USB3.0 bridge -> FX3 -> FPGA
<whitequark> that's pretty cursed actually.
<whitequark> so one day i wanna make you know what? boneless fx
<whitequark> like fx2 but with boneless instead of 8051 and all on an fpga
<emeb> sure. eliminate parts.
<whitequark> no, it will only work at full speed
<whitequark> because HS USB is cursed
<whitequark> i guess with a PHY it could work at HS.
<emeb> eliminating 8051s is always a net positive
<whitequark> true
<whitequark> i might also implement a formally verified 8051
<emeb> but yeah - you'd have to design a fully FPGA-able HS PHY.
<daveshah> USB3300s are super cheap
<whitequark> i *think* it could be completely microcoded in one 256x16 BRAM
<davidc__> whitequark: that requires something to verify against
<daveshah> If you don't care about adding a few BOM lines
<whitequark> daveshah: and the spec, of course
<whitequark> arrr
<whitequark> davidc__: ^
<davidc__> I think the biggest downside of eliminating the USB controller/processor is how one handles reconfiguration / bitstream testing
<davidc__> I wish proper partial reconfiguration was a thing
<whitequark> yes
<whitequark> glasgow will always use fx*
<whitequark> because they're extremely foolproof
<davidc__> something something greater fool
<whitequark> i didn't say completely
<emeb> 500yrs from now 8051s will still exist. buried in essential infrastructure.
<whitequark> you *can* soft-brick glasgow revC
<whitequark> (you need to short 2 pins to fix that)
kuldeep has quit [Remote host closed the connection]
<whitequark> you *can* hard-brick glasgow revC by electrically destroying it
<whitequark> or mechanically
<daveshah> Even with partial reconfig you'll still want to update your wrapper/"bootloader" module at some point
<whitequark> but not short of that
<daveshah> Which is where something like an FX2 is very nice (and where countless tinyfpgas have been lost)
<TD-Linux> daveshah, you could aways just use two fpgas too. not worse than fpga + fx2
<TD-Linux> tinyfpgas don't do partial reconfig though. what kills them?
<daveshah> I think USB3300+ECP5-12k is similar component price wise to fx2 (but higher assembly cost from more parts)
<whitequark> daveshah: in fairness tinyfpgas have a really stupid bootloader and i don't know why
<daveshah> The bootloader update going wrong
<whitequark> it's not hard to validate commands
<daveshah> This isn't even to do with command validation
<whitequark> ah
<daveshah> This is to do with the programmer dieing in the middle of updating the bootloader
<whitequark> oh it doesn't do atomic updates
<daveshah> e.g. due to modemmanager, random command validation, etc
<davidc__> daveshah: I guess there's restrictions on doing an A/B scheme
<daveshah> *random command errors
<TD-Linux> yeah you can't really do A/B because the fpga reads from the same start address always
<daveshah> It could easily copy the image into spare flash, write an updater into the user app area, and warmboot into that
<whitequark> ^
<TD-Linux> ah true
<daveshah> Then the only risk is a power failure or FPGA uoset, as opposed to any kind of issue with the Linux USB-serial infrastructure or fragile Python atop it
<davidc__> TD-Linux: depends on the FPGA. Some will search for a magic, and a magic at offsets
<daveshah> ECP5 has a golden image feature like that
<TD-Linux> you could also just never update the first stage bootloader
<davidc__> If you write the magic after verifying the rest of the image, its hard to brick
<whitequark> yeah, write it in the flash and protect it
<whitequark> just make that region OTP ROM
<whitequark> atmel dataflash can do that
<azonenberg> davidc__: this is what i like about xilinx parts
<azonenberg> they have pretty good support for fallback boot
<azonenberg> i havent had to use it yet (none of my boards have been field updateable)
<whitequark> ecp5 has extensive support for that
<azonenberg> but good to have
<davidc__> I'm a big fan of "can flash entire board through single cable"
emeb_mac has joined ##openfpga
<azonenberg> davidc__: well most of my boards these days are just an fpga with no other programmable stuff :p
<azonenberg> i cant recall the last time i used a MCU in a design
<azonenberg> integralstick has one but i've never used it yet
<TD-Linux> still haven't figured out ideal ice40 end user flashing solution. a more robust version of tinyfpga programmer would be great but still too big for hx1k
<TD-Linux> ffp is my favorite so far
<TD-Linux> but still requires a separate flashing step
<davidc__> azonenberg: I typically use FTDI parts as data pump + flasher. They have their challenges, but once you can make them work, they work.
<azonenberg> davidc__: most of the time i use raw jtag for flashing and ethernet for communication
<azonenberg> i want to write a tftp bootloader at some point
<azonenberg> i'm trying hard to move away from USB, including but not limited to ftdi
<davidc__> azonenberg: I've played with some designs for an ethernet-capable flash+JTAG debugger
<davidc__> azonenberg: looked at some PHYs that have NC-SI or other sideband
<davidc__> azonenberg: I'd love to come up with some BOM cost under $10 design, and make a pile of castellated modules
<davidc__> then just solder them down in designs + get JTAG/SPI muxed into an existing 1G ethernet port
<azonenberg> ah yeah that is very different, i was talking about actually having application layer firmware updating using the existing udp/ip soft logic on the fpga
<azonenberg> as far as jtag over ethernet for prototypes, my plan is starshipraider
<azonenberg> i actually just dusted off (literally) the prototype
<azonenberg> gearing up to do more work on it as i slowly unpack the lab
<azonenberg> i passed electrical inspection this morning, city final tomorrow
<azonenberg> So we're moving in momentarily
<azonenberg> Still gonna be a bit of a mess for a few months because i just burned my month's spare cash on a 6 kVA Eaton UPS that hasn't come in yet
<azonenberg> once my wallet recovers i'm buying some cabinets and shelving
<whitequark> TD-Linux: i think i can fix USB+boneless into hx1k
<whitequark> fit*
<whitequark> i might implement it later
<whitequark> davidc__: "I'd love to come up with some BOM cost under $10 design, and make a pile of castellated modules" this was the original design for glasgow :D
<whitequark> design intent*
<TD-Linux> whitequark, that would be pretty cool. hx1k allows the very easy tqfp package that works on 2 layer boards
<whitequark> alright
<whitequark> btw how is that LPC-ISA board going?
<TD-Linux> I haven't done much on it yet, I'm on "vacation" on the farm right now. (which actually has 100/100 fiber, I have no excuse)
<whitequark> ah heh
<TD-Linux> the fpga on there needs to be flashable, which is why I was thinking about this :)
<whitequark> TD-Linux: oh that's trivial
<TD-Linux> I'm probably going to use either the tqfp100 or tqfp144 package (hx4k) on it. without pci it's a lot easier
<whitequark> just wire the LPC pins to the configuration bank
<whitequark> and a sideband to Glasgow or a jumper, depending on pin restrictions
<whitequark> i think only a jumper will work with one IDC
<TD-Linux> sure, that would work.
emeb_mac has quit [Ping timeout: 244 seconds]
<davidc__> whitequark: heh. At some point I want to make a derivative of glasgow that is castellated (basically, drop the level shifters)
<davidc__> whitequark: For solder-in use on prototypes
<whitequark> davidc__: with the fx2 and everything?
<davidc__> whitequark: yeah, FX2 + FPGA... though I might look into whether different packages are available
<whitequark> also, i assume you will drop the bitstream EEPROM
<whitequark> but keep the FX2 one?
<whitequark> what about programmable pulls?
<whitequark> i would be very worried about supporting a glasgow derivative that doesn't have programmable pulls
<whitequark> but e.g. one that has fewer ports or no programmable Vregs seems basically fine
<davidc__> Oh, I'd have absolutely no expectations for upstream support
<whitequark> i think if you keep the ADC and pulls i could support it upstream.
<davidc__> If upstream breaks, thats my problem, since the board will probably only exist in my shop :P
<whitequark> if you don't you'd be basically making a revB and many applets (like i2c) barf on revB
<davidc__> current plan is to drop the ADC; and just have a VIO provided by the host board since the IO voltage will already be around
<whitequark> right, you'd obviously drop the DAC and LDO
<davidc__> er, duh, DAC
<davidc__> Sorry :)
<whitequark> but the ADC is kind of important to the flow
<davidc__> whitequark: I'll get back to you once I have a more defined plan :)
<gruetzkopf> i have previously slapped my revb into my products backplane with a terrible perfboard adapter, can confirm usefulness
<whitequark> davidc__: with the ADC and pulls i'd be perfectly happy to have the board and code upstream
<whitequark> this is certainly something people have asked for
<gruetzkopf> (though that was via the headers - and i'm dealing with big stuff that fills a 3U eurocard carrier or 200)
<mwk> whitequark: so I would like to write up some of that stuff about JTAG and also about the packet processor
<mwk> is there some obvious place I can put it?
<whitequark> mwk: yes. let's rename glasgow.arch.xilinx.xc6s to glasgow.arch.xilinx.fpga
<whitequark> and put it there
<mwk> what? in the big comment on top?
<whitequark> yep
<whitequark> i plan to convert these to docstrings at some point
<whitequark> but a *lot* of applet and arch files have huge comments explaining things
<whitequark> and i refer people to these a lot
<whitequark> check out the one for floppies :D
<mwk> oh yes, that one was quite epic
<whitequark> you can also drop every document you directly reference to docs/archive/
<whitequark> i try to do that
<whitequark> although it sounds like most of your work is blackbox RE
<mwk> pretty much yes
<whitequark> i should certainly make sure you get a glasgow, at some point :p
<azonenberg> gruetzkopf: starshipraider is descended from a management card that i was going to put in my MARBLEWALRUS fpga cluster
<azonenberg> Ethernet to nine lanes of jtag, nine lanes of uart, nine lanes of i2c, and a bunch of gpios and other stuff
<whitequark> no kill like overkill
<azonenberg> for one side of a 3U eurocard chassis (two ten-card backplanes plus a PSU in 3U)
<gruetzkopf> yeah i'm running a 25-slot (one of them controller) plane plus PSU
<mwk> hmmm
<mwk> I basically have all the xilinx user guides / config guides / whatever guides mirrored already
<mwk> 0.5GB of crap
<whitequark> i have a lot of them in my library
<whitequark> check out Electronics/Programmable Logic/Xilinx
<whitequark> with nicer names so you can use desktop file search like spotlight
<mwk> I um
<mwk> I get an internal server error when I try to log in
<mwk> Remote Address: ::ffff:
<whitequark> uhh. try again
<mwk> Request ID: GBtfBlVQ7g1eqYFmaqgE
<whitequark> it does that sometimes intermittently
<whitequark> hateful heap of php crap
<mwk> oh yes, worked now
<whitequark> the actual docs can be synced (partially too) with a desktop client or via any webdav client
<gruetzkopf> my next thing to poke at is this PABX which implements the TDM switch in a XC2V2000
<mwk> nice
<mwk> so, whould I just dump my collection there?
<whitequark> if you can make it fit the existing structure you can dump it right into the main hierarchy yes
<whitequark> if you don't want to bother dump it to Incoming/ which is world writable
<mwk> easy
<whitequark> for the former i'd need to give you a write bit
<whitequark> ok give me a sec
<whitequark> feel free to dump any other docs into it as long as they're sorted and renamed
<whitequark> the scope is "all documentation"
<whitequark> mwk: you have the write bit
<azonenberg> mwk: let me see how big my datasheet archive is...
balrog has quit [Quit: Bye]
<azonenberg> azonenberg@havequick:/nfs4/share/datasheets$ du -h --summarize .
<azonenberg> 3.6G    .
<azonenberg> but that isnt all xilinx
<azonenberg> only 612 MB of xilinx stuff
<whitequark> ~/Library$ du -hs .
<whitequark> 37G .
<azonenberg> whitequark: is that just datasheets though?
<azonenberg> or journal articles, books, etc
balrog has joined ##openfpga
<whitequark> azonenberg: a lot of it is the entire set of DIN standards
<whitequark> hm, a FIB manual
<whitequark> a directory called "missile textbooks"
<azonenberg> lol
<mwk> hilarious software
<whitequark> a huuuuge collection of Intel manuals with information Intel scrubbed from it
<whitequark> the VISA stuff
<mwk> if I'm renaming a file and corrently entering the file name, and the browser window loses focus because I move mouse to another display, it performs the rename immediately
<whitequark> mwk: that's common to desktop software. but yeah ill-advised in browser
<whitequark> it's also very very slow
<mwk> whitequark: so the format is "DS420 <title straight from the document> v6.9.pdf"?
<whitequark> the server is in uhhhh singapore for uhhh reasons
<whitequark> mwk: exactly
<mwk> alright, let's do that
<whitequark> just enough to make it easily searchable with spotlight if content indexing is turned off
<whitequark> (or the kde spotlight-like thing)
<whitequark> because while it *does* index 37 GB of mostly PDFs that takes a while
<azonenberg> i dont have any of my stuff indexed
<azonenberg> i just have /nfs4/share/datasheets/Vendor[/family if lots of stuff]/File.pdf
<whitequark> azonenberg: i can do super+r ug380 enter and it gives me the document
<whitequark> or super+r ieee 1352
<whitequark> all the world's standards at my fingertips :p
<whitequark> well not all. not *yet*
<whitequark> i should scrape all of ieee sometime
<gruetzkopf> whitequark: my (very incomplete) DIN set is 100G
<whitequark> gruetzkopf: hm
<whitequark> did the DIN upload not finish?
<whitequark> 11981 files
<whitequark> 9.6 GB
<gruetzkopf> my DIN - no - other - orgs involved set is 23.5kFiles alone
<whitequark> ah crap
<whitequark> wanna complete my set?
<gruetzkopf> mine's incomplete too, but apparently bigger now. i actually have non-terrible internet now too!
<mwk> whitequark: do you want Xilinx PROMs, SystemACE, etc. in the same directory, or is there another place for them?
<whitequark> mwk: it's related to programmable logic so it's fine
<mwk> (of course you're going to get the SystemACE™ datasheet from me)
<whitequark> it's also ok to put the same file in multiple places
<whitequark> i don't *think* it deduplicates things but that's temporary
<Ultrasauce> find something less janky than nextcloud?
<whitequark> Ultrasauce: it's on the todo list
<whitequark> find or write
<Ultrasauce> ah yes
<Ultrasauce> another project
<whitequark> because i don't think anynone implemented a system with quite the featureset i want
<whitequark> trustless distributed encrypted storage
<whitequark> tahoe-lafs but like, with write speeds over 100 kb/s
<whitequark> because i want to be able to upload ~100 TB into it an have itwork
<gruetzkopf> whitequark: i would but the seafile2seafile link fell over
<gruetzkopf> *nextcloud2nextcloud
dh73 has quit [Remote host closed the connection]
<whitequark> gruetzkopf: aw, crap
<whitequark> is it debuggable
<gruetzkopf> Have spent zero time on trying
<gruetzkopf> Should just grab a normal acct
<whitequark> understandable
Bike has joined ##openfpga
<mwk> whitequark: it appears your "Series 7" directory contains, in fact, mostly UltraTrash documentation
<mwk> I'll fix it...
<TD-Linux> UltraLimescale
<mwk> hrm, it appears that old libraries guides don't have a UGxxx number
<mwk> how annoying
<whitequark> mwk: hehe, another person who calls it UltraTrash
<kc8apf> Where do I get access to this library?
<mwk> if I have a different document version than you, I'm supposed to upload it and we keep both, right?
<kc8apf> Unrelated: new Spectre variant came out of embargo today
<mwk> windows-only hardware bug?
<mwk> what the fuck?
emeb has quit [Quit: Leaving.]
emeb_mac has joined ##openfpga