<whitequark>
I was thinking about adding some PSRAM on board
<whitequark>
but I guess that'll wait for revD
<davidc__>
whitequark: out of curiosity, what for?
<whitequark>
davidc__: some kind of cache or buffer
<whitequark>
you can't easily do random access over usb at low latency
<whitequark>
maybe you want to simulate an SPI flash
<whitequark>
i think the fastest SPI PSRAM you can get is DDR with QSPI Fast Read which gives you like 100 MHz at 8 bits/cycle
<whitequark>
which is much wider than our USB interface
<whitequark>
we can't have QSPI though
<whitequark>
we can't even have regular SPI
<whitequark>
if we had 3 pins we could have used IFCLK
<whitequark>
extremely wild idea
<whitequark>
two wire SPI flash
<whitequark>
you never need to shift data INTO the flash at the same time as you shift data OUT of the flash, right
<whitequark>
so you can multiplex those
<whitequark>
but I imagine you might as well just wirewrap that at the AUX connector
<tnt>
whitequark: re-use the spi programming pin ?
<whitequark>
tnt: can you do this on hx8k?
<whitequark>
iirc you can't
<whitequark>
daveshah: ^
<davidc__>
gotcha. simulating spi flashes can be.. tedious. Might want to get that tested on another FPGA board before laying out HW for it
<davidc__>
you need to hit ~17ns from "last bit of address" to "first bit on the wire" in the worst case operating conditions for some modern SPI flashes
<davidc__>
and that is rather tricky; internal BRAMs aren't big enough, external parallel SRAMs can be but $$$. Best solution I've found (tested theoretically, not yet built) is to use a 32 or 64bit wide DDR2 or 3 SDRAM and trade the last 2 or 3 bits of the address for the access latency
<tnt>
whitequark: I've never seen anything about that limitation. The programming and configuration guide says pins are available as user IO after config and doesn't mention anything about this being limited to UP5k.
Jasjar has quit [Ping timeout: 245 seconds]
<whitequark>
tnt: oh, interesting, thanks
<tnt>
whitequark: also, I don't know any spi psram that does QPI DDR, only QPI. But then again most flash that do QPI DDR only do so at half the frequency of their QPI SDR support :/
<whitequark>
oh I see
<tnt>
I guess it's mostly a convenience thing to run your internal logic at lower clock rate and get 8 bit per cycle. (and half the frequency of the clock line)
m4ssi has joined #glasgow
<marcan>
davidc__: ha, cute trick with the addresses
<marcan>
not sure if I mentioned to you that before working on glasgow I was sketching together something that can romulate GBA cartridges
<marcan>
and it's tricky at the fastest supported speed for ROMs
<marcan>
the timings aren't exactly well documented, but the clock is 16MHz and I think the fastest timing is like one or two cycles from address to data
<marcan>
you can meet timing with sdram IIRC but refresh gets in the way
<marcan>
obviously NOR flash works, but that's flash
<tnt>
hyperram ?
<whitequark>
marcan: hmmmm
<whitequark>
you could have two SDRAMs
<marcan>
yeah
<marcan>
that's a solution that was thrown around
<marcan>
but they need to be quite independent in that case
<marcan>
(pinout-wise)
<whitequark>
mmm, you can't multiplex them?
<whitequark>
if you run the SDRAM interface at 32 MHz you have every other cycle for GBA
<whitequark>
and the rest for management
<whitequark>
oh wait
<marcan>
you need to run it at like 100MHz to meet the latency requirement in the first place, lol
<whitequark>
you wouldn't be able to catch up
<whitequark>
oh
<marcan>
the GBA accesses can be totally random
<whitequark>
hmmm
<whitequark>
that's a pain in the ass
<marcan>
yeah
<tnt>
how large are GBA ROMs ?
<daveshah>
whitequark: SPI pins are regular IO on HX8K too
<marcan>
tnt: like 32MB IIRC?
<marcan>
(max)
<whitequark>
daveshah: thanks
<whitequark>
so in theory we could consume the AUX port and hang a huge PSRAM off there
<whitequark>
but ... idk
<whitequark>
maybe for revC2?
<marcan>
I don't think this is going to happen for revC tbh
<marcan>
also it doesn't have enough IO pins anyway
<marcan>
but I'd like to explore it for revD
<marcan>
and certainly have something flexible for revE
<whitequark>
marcan: i mean by reusing the SPI pins
Jasjar has joined #glasgow
<tnt>
marcan: W968D6DA ?
<marcan>
whitequark: oh
<marcan>
whitequark: er, aren't we doing that already?
<marcan>
the SPI pins are hooked up to the FX2 data bus
<whitequark>
marcan: oh, shit
<tnt>
lol
<whitequark>
marcan: we COULD make it work
<whitequark>
if we connected SI and SO and used the other AUX pin for CS
<whitequark>
and the clock would be IFCLK
<whitequark>
but it's so marginal
<marcan>
for like a serial PSRAM?
<whitequark>
yes
<marcan>
I didn't even realize that was a thing
<whitequark>
i looked at a few datasheets, you never need SI and SO at the same time
<whitequark>
and fast read lets you have a period where you turn off the driver
<marcan>
at this point why not just make AUX 4 pins
<marcan>
with 3V3
<marcan>
and call it an expansion dongle
<marcan>
well, need IFCLK too
<whitequark>
meh
<whitequark>
i don't want to make it official
<daveshah>
whitequark: some FTDI chips use shared SI and SO for the SPI EEPROM
<marcan>
I don't look forward to getting IFCLK to that side of the board anyway
<marcan>
and tbh if I'm going to throw RAM on there I would rather just hang it off of the LVDS port
<whitequark>
marcan: oh wtf
<whitequark>
they... are too slow
<marcan>
lol
<whitequark>
20 MHz, 45 MHz...
<tnt>
whitequark: but how wold you 'turn off' the driver of the PSRAM ? AFAIK it will drive the line as soon as CS is asserted.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
m4ssi has quit [Remote host closed the connection]
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
m4ssi has joined #glasgow
m4ssi has quit [Remote host closed the connection]
<marcan>
whitequark: one solution to the SYNC port thing is pulldown instead, but really, you're never going to break anything by sending 200µA into 3V3
<marcan>
whitequark: err, the reason why QA4 and QA6 have two balls is due to the PLL thing
<marcan>
those balls are there to provide an I/O path for QA4 and QA6 when GBIN0/1 get used by the PLL
<marcan>
the point is to allow maximum flexibility; you can use those IOs as GBINs, as PLL input, and if used as PLL input you can still get the original clock out on the side balls (without having to use the secondary PLL output for that), and if you use fabric for the PLL input you can still use the IOs through the alternate balls