<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
<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
<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
<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
<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>
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
<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:84.10.63.242
<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