s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
tms_ has joined ##openfpga
emeb_mac has quit [Ping timeout: 268 seconds]
rohitksingh has joined ##openfpga
<tnt>
Sprite_tm: how is it going btw ?
<Sprite_tm>
tnt: Doing stuff on the sw side atm... fixed up a spi driver, so now I need to decide on flash partitions and os/hal and app separation, FAT wear leveling (if any) etc.
<tnt>
What flash chip is it btw ? Does it support things like QSPI-DDR and stuff liek that ?
<Sprite_tm>
Nah, just a boring w24q128 chip. It can do QPI, but I'm not using that atm.
<Sprite_tm>
SPI hw supports it but I have no nice hookup to the SOC of that feature yet.
<Sprite_tm>
I decided that optimization is something I could do later on ;)
<tnt>
Heh, that chip does most stuff, except for DTR.
<tnt>
Well if you took the picorv32 you could have taken the spi controller from that repo as well :p
<Sprite_tm>
Well, my SPI controller has a similar interface (I use it for the PSRAM as well) but I'm not sure if I want the flash chip as an actual memory in my address space... people will probably expect XIP somehow, which means you need to work around page writes... the ESP32 has that, and that's way more coding around that than I want to do here.
<Sprite_tm>
I'm still pondering DMA as an access method, but I want to get crap working first, then optimize later.
<tnt>
Yeah sure. But if you don't have XIP now, you're just loading into BRAMs ?
<Sprite_tm>
Nah, I've got 2x8MiB of PSRAM external, nicely accessed through cache.
<Sprite_tm>
That's the main memory, and as such I'm pretty comfortable using the flash as a hard disk equivalent instead of memory.
<tnt>
Oh so you're loadin the software from flash to psram at boot then XIP from the serial psram.
<Sprite_tm>
Yep.
<tnt>
but those psram also have qspi and stuff like that :p
<tnt>
Ah but you said you implemented a cache.
<Sprite_tm>
Technically, the bram that is the cache starts up with a bunch of dirty lines containing the boot code.
<Sprite_tm>
But yeah, I have a cache and technically, nothing is keeping me from throwing the flash chip on there as well and being read-only accessible as a memory range. Would be pretty fast as well. I just don't want to do it as the flash will be out-to-lunch when you're programming it.
<tnt>
yes, makes sense.
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
_whitelogger has joined ##openfpga
Miyu has quit [Ping timeout: 246 seconds]
<tnt>
Finally took the time to fix iceprog to properly reset the flash out of CRM/QPI/... this has been bugging me for a while.
flaviusb has quit [Ping timeout: 246 seconds]
flaviusb has joined ##openfpga
flea86 has quit [Quit: Sleeep.]
emeb has joined ##openfpga
dh73 has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
mumptai has joined ##openfpga
nurelin has quit [Quit: WeeChat 2.4]
nurelin has joined ##openfpga
flaviusb has quit [Ping timeout: 245 seconds]
flaviusb has joined ##openfpga
rohitksingh has quit [Ping timeout: 268 seconds]
<mwk>
whitequark: wrt what you said about programming xc6s and other stuff yesterday, I've been wondering
<mwk>
if using JPROGRAM is equivalent to pulsing PROG_B, what's stopping the device from immediately reconfiguring from whatever flash is configured by M0-M2 pins?
<mwk>
is it just different if you do it via JPROGRAM, or is the whole thing racy as fuck...
<mwk>
okay, I guess I found the answer
<mwk>
it configures from the flash the moment you load something other than JPROGRAM into the IR
<mwk>
other than JPROGRAM or CFG_IN
<mwk>
... or CFG_OUT, I suppose
<mwk>
hrm
<whitequark>
mwk: oh shit, that's actually a bug
<mwk>
whitequark: in that thing you posted yesterday
<whitequark>
in my code
<whitequark>
you're totally right, let me fix it
<mwk>
1. IR=JPROGRAM; while(!(IR & INIT_B));
<mwk>
how are you checking the IR?
<mwk>
are you shifting BYPASS into it?
<whitequark>
yes. i should be shifting in CFG_IN. but i am shifting BYPASS.
<mwk>
okay
<mwk>
good, that should fix it :)
<whitequark>
it actually still works
<whitequark>
i assume it's racy
<mwk>
leaving it at JPROGRAM unsurprisingly makes it never goes to 1
<whitequark>
indeed
<mwk>
FWIW
<mwk>
I tested all opcodes on spartan 3E
<whitequark>
wait
<whitequark>
ah no nvm
<mwk>
CFG_IN, CFG_OUT, JSTART, JSHUTDOWN are the ones that override the startup machinery and make the device *not* boot
<mwk>
+ JPROGRAM, but for different reasons
<mwk>
well, that and INTEST/EXTEST, but that's presumably it messes with the config pins, not due to actual functionality
<mwk>
/HIGHZ
<whitequark>
mwk: wait, I think I understand why it worked for me
<whitequark>
so, ECP5 has this thing where JTAG has a higher *priority* than serial
<whitequark>
i think (given that ECP5 is like xilinx) it actually works the same in xilinx devices
<whitequark>
so, when i shift in BYPASS, it disinhibits the startup machinery
<whitequark>
and it may even start configuring from flash
<whitequark>
but i shift in CFG_IN fast enough that it overrides that back
<mwk>
yes
<whitequark>
thanks :)
<mwk>
you're probably interrupting the configuration during bitstream load
<mwk>
and just overwriting the data frames
<whitequark>
yes, i shift CFG_IN in a few milliseconds at most, it might not even had time to get to the signature
<mwk>
it also makes me wonder that JSTART is actually for
<mwk>
*what
<mwk>
since the bitstream you load already has a START command in it
<mwk>
the only hypothesis I can come up with is that it gates the startup clock for StartupClk:JTAG
<whitequark>
mwk: this is actually what their docs say
<whitequark>
RTI in JSTART clock the startup process
<whitequark>
and similar for JSHUTDOWN
<mwk>
so if I use StartupClk:UserClk I don't need the JSTART?
<whitequark>
i think when you configure via JTAG, the chip overrides StartupClk?
<whitequark>
i'm not sure
<mwk>
it doesn't
<whitequark>
their docs are not clear on this part
<whitequark>
hm
<mwk>
bitgen specifically yells at you that your bitstream won't work if you do it wrong
<whitequark>
ok, so i have this bitstream with no -g StartupClk
<whitequark>
and it still works when i configure it via JTAG
<whitequark>
what gives?
<whitequark>
i specifically checked that
<whitequark>
like, i loaded it just now
<mwk>
I think that's because the startup oscillator is still enabled
<mwk>
grr, my machine with S3E bitgen capabilities decided to crap itself
<mwk>
hrm, the thing still starts with StartupClk:CClk even if mode pins are set to JTAG
<mwk>
so... wtf.
<mwk>
whitequark: so, here are my results for S3E
<mwk>
if I use UserClk, JSTART is indeed unnecessary
<mwk>
the device starts on its own, with CFG_IN still in its IR and no JTAG activity since the last bitstream word
<mwk>
but if I use either CClk or JtagClk, JSTART is necessary for both "master serial" and "JTAG" values of M0-M2 pins (the board doesn't allow me to select any other values)
<mwk>
it seems the device really overrides the COR0 bit, and bitgen lies
<whitequark>
hahaha
<mwk>
maybe some older FPGA doesn't have the override though
<mwk>
*shrug*
<mwk>
the digilent programmer for this board [basys2] goes out of its way to fix the startup clock in bitstream (mangling COR0 + CRC) if you use CClk and JTAG programming
<mwk>
now I suppose I should try programming StartupClk:JTAGClk to the serial flash and seeing what happens
<mwk>
but that would require me to write a programmer for this chip, do I really want to do that...
<mwk>
wait what
<mwk>
what in the name of fuck
<mwk>
it... gets better
<mwk>
so now I'm doing JPROGRAM+CFG_IN, but instead of JSTART I just return it to BYPASS
<mwk>
if I upload my design with StartupClk:CClk, it boots properly
<mwk>
*but* if I upload my design with StartupClk:JTAGClk, the device kind-of boots the bitstream from flash instead
<mwk>
but... it's broken
<mwk>
as if it was mixed with my JTAG-uploaded bitstream
<mwk>
as in, the flash contains digilent's test bitstream, which cycles digits on 7seg display and bypasses SW -> LED
<mwk>
the 7seg cycling works, but as for the LEDs, 3 are tied high, 2 are tied low, and only 3 are properly connected to SW
<mwk>
so um
<mwk>
here's my guess about what happens
<mwk>
the moment I drop CFG_IN, the config machine starts CCLK and commences fetching things from ROM (because !EOS)
<mwk>
if StartupClk:CClk is selected, the first few clocks are enough to push it to EOS and configuration stops before the ROM bitstream can do anything
<mwk>
but if StartupClk:JTAGClk is selected, the startup machine is frozen, and shit gets overwritten with ROM bitstream instead
<mwk>
given that the chip is already in startup, and the bitstream doesn't contain SHUTDOWN command, it's probably doing something akin to active reconfiguration and failing badly at it, resulting in the broken behavior
<mwk>
whitequark: so... I think the "wait for done" part should also be done with IR set to JSTART, or shit like the above will happen
emeb_mac has joined ##openfpga
<mwk>
I still wonder how the "override" works
<mwk>
it clearly remembers the selection, because it has different behaviors with IR=BYPASS
<mwk>
it would make sense if, while JTAG is in CFG_IN, TCK & (state == shift_DR) *was* the CCLK, due to being connected to the same internal configuration port net; but then the device would start if I just shifted in a lot of dummy words with CFG_IN, and that isn't happening, it really wants JSTART
<mwk>
another interesting data point: JSHUTDOWN basically pauses the FPGA (tristates the pins, disables writing to flops), and JSTART unpauses it, as expected
<mwk>
*but* that only works if StartupClk is set to JTAGClk or CClk; if it's UserClk, JSHUTDOWN doesn't do anything
<whitequark>
mwk: yes that seems to be quite like what they say in docs (re JSHUTDOWN)
<whitequark>
JSHUTDOWN is for readout right?
emeb_mac has quit [Ping timeout: 246 seconds]
<whitequark>
I really want to play with that... glasgow makes that so easy
<mwk>
readout, yes
<mwk>
and partial reconfiguration, although I suppose you'd want SHUTDOWN in the bitstream for that instead
<mwk>
whitequark: the docs don't say JSHUTDOWN doesn't work if you bring your own startup clock
<mwk>
that's the surprising part
<mwk>
(which I tied to the main board clock and is definitely toggling while I'm trying JSHUTDOWN)
<whitequark>
interesting
<mwk>
also, the config guide (ug380 page 170) recommends using JSHUTDOWN and not JPROGRAM to prepare the device for loading a new bitstream
<mwk>
which... doesn't sound like a good idea to me, unless you specifically want partial reconfiguration
<mwk>
I really have no idea why JSHUTDOWN exists; it seems in all cases when you'd want to use it, you're already going to be using CFG_IN anyhow and could just send a CMD<-SHUTDOWN packet
<mwk>
unless hm
<mwk>
the same mechanism that only passes JSTART clocks and not CFG_IN clocks to the startup machinery also affects shutdown clock
<mwk>
so the device wouldn't actually shut down with just the SHUTDOWN command, ugh
<whitequark>
huh
<mwk>
oh muahahaha
<mwk>
whitequark: that algorithm is still wrong
<mwk>
you know about the configurable startup cycles, right?
<mwk>
and how you can assign GWE/GTS/LCK/DONE to whatever cycles you want?
<mwk>
so... in the default configuration, DONE is asserted before GWE/GTS
<whitequark>
mwk: yeah
<mwk>
which means if you look at the status on the wrong cycle, you can hit the window between them
<mwk>
so DONE == 1, but GWE is still inactive / GTS is still active
<mwk>
I just modified my programmer to send RTI cycles one by one, and hit that case
<mwk>
what you really want to look at is EOS
<mwk>
it seems ISC_DONE might be what we want?
<mwk>
it goes high at the exact cycle when I would expect EOS to go high
<whitequark>
why not ... not just use the huge honkin FPGA you have sitting around in that thing
<whitequark>
i'm so confused
<mwk>
I think the XC18V01 configures the Virtex, which then configures your actual FPGA using the AMD flash
<mwk>
umm, it's not huge
<mwk>
it's a rather small virtex
<whitequark>
i mean the ball count mostly
<daveshah>
also, tsop in a bga is pretty qt
<mwk>
but yeah
<whitequark>
wtf, it's not even a die
<mwk>
the whole thing is... I have no idea what they were smoking
<mwk>
I think the whole shebang is because back then their FPGAs could only configure using their custom parallel / serial protocols, and you couldn't actually use off-the-shelf SPI or parallel ROMs
<mwk>
and their own custom PROMs were actually too small to configure the larger Virtex devices
<mwk>
so... the obvious solution is to use a small FPGA as a proxy between a large FPGA and a large off-the-shelf flash, right? ... right?
<TD-Linux>
LOL at the MPM version. I can't decide if that or the custom asic is worse though
Bike has joined ##openfpga
<whitequark>
mwk: "Internet Reconfigurable Logic"
<mwk>
the compactflash is kind of cute though
<mwk>
you stuff your card in a computer, drag & drop the bitstream to a VFAT filesystem, move the card to the board, and it boots
<mwk>
including hardware Xilinx.ini file parsing
<mwk>
er, xilinx.sys
<whitequark>
incredible
<mwk>
I mean, eh
<whitequark>
oh, the ASIC does have a CPU inside
<mwk>
I really hope it's some kind of a reconfigurable device with a small CPU core
<mwk>
but I see no obvious interface for that
<whitequark>
or wait, is it
<whitequark>
ohhhh no it can *interact* with a CPU
<mwk>
and the JTAG sig doesn't match any xilinx FPGA, that's for sure
<whitequark>
... decap it?
<mwk>
whitequark: yes, once it's done configuring the FPGA, the FPGA can talk to it to do reads/writes to the CF card
<daveshah>
The config from a CF card lasted a good long time
<daveshah>
Even the ML605 Virtex-6 has it
<mwk>
yep
<mwk>
whitequark: I would, but... I'm rather fond of it
<whitequark>
... pay someone to decap it nondestructively?
<whitequark>
not cheap, that's true
<daveshah>
Some of the Virtex7 even seem to have a SystemACE2 that's really a S3AN
<daveshah>
But that uses SD cards at least
X-Scale has quit [Ping timeout: 245 seconds]
Bike has quit [Ping timeout: 264 seconds]
Bike has joined ##openfpga
dh73 has quit [Remote host closed the connection]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 244 seconds]
<mwk>
whitequark: I'm not exactly sure how all that code works, but it seems in your applet's _poll function, you never go to RTI state, right?
<mwk>
you just shift IR all the time?
<mwk>
if so, that would result in a hang if the device doesn't manage to configure in the 16 RTI cycles you send in the beginning
<mwk>
(I've checked, *only* RTI cycles with JSTART count)