Interfacing Quad SPI flash to an XMOS device

XCore Project reviews, ideas, videos and proposals.
jmg
Member
Posts: 8
Joined: Thu Mar 22, 2012 11:50 am

Post by jmg »

Folknology wrote:Leon/jmg
One other possibility is to multiplex a single 1 bit port onto both QSPI chip's SI and use the remaining 1bit port to control an output enable on that port (via 2 hi-z buffers), that way the 4/8bit port can be input without needing the switch direction around.


I think you missed another 4/8 somewhere ? QuadSPI flips by opcode, so needs to send the Address info right after that 1 byte opcode, as Quad/Quad_DDR, so you need full DDR half-duplex port operation.
(see my note about a 64 bit remapped opcode, to avoid any HW gymnastics at the opcode/address boundary)

Sure, additional silicon and pins could be used, but that is an admission of defeat... ;)
jmg wrote: I can however see fish-hooks in the turn-around from send-address to receive data, but there are also latency bits in the Spansion Memory, and as long as the turn-around was always a fixed clock count, you can correct for it. Jitter would be the killer here.
I've thought about this issue I mentioned above, and think it can be checked by running a single additional receive channel, on the CLK-as-Data line.
Yes, it is more house-keeping, but it could be use to prove there really is a thread-immune system.

This would record the time the DDR clock really spends paused (because the internal sampling 2x clock does NOT pause, this time matters )
With no pauses, this will simply always read the 55H or AAH on the SPIqCLK line. During the turn-around time between address send and data in, this will show exactly how many 2x samples it took, and how much needs to be discarded to properly sync to real data.
In flow terms, you wait for Address block to send, then disable qDIO so make Rx only, then flush/restart receive and send receive clock.

The bit that ideally needs to be atomic is the "flush/restart receive and send receive clock", as you want a known and fixed delay here.
Last edited by jmg on Mon Mar 26, 2012 9:48 pm, edited 1 time in total.
jmg
Member
Posts: 8
Joined: Thu Mar 22, 2012 11:50 am

Post by jmg »

Folknology wrote: But it is weird that on the XS1-SU1 datasheet it marks T(XOVALID) Input data valid window, T(XOINVALID) Output data invalid window, T(XIFMAX) all as 'TBC' why have they done that if they are the same as XS1-L series
I think it is 'almost the same' - the specs they do fill in, give slightly faster times, and there is a 700MHz device penciled in, so it looks like maybe the FAB has a 'better recipe' that gets a little bit more out of the process node.
I doubt the step is big enough to be a process-node change, but it is large enough to give another speed-bin.
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am

Post by segher »

Folknology wrote:But it is weird that on the XS1-SU1 datasheet it marks T(XOVALID) Input data valid window, T(XOINVALID) Output data invalid window, T(XIFMAX) all as 'TBC' why have they done that if they are the same as XS1-L series
Pin switching speed is highly dependent on the device package. This is
a new package, and it seems XMOS doesn't have volume shipments
themselves yet (or they would sell them to us, don't you think? ;-) ), so
it's no real surprise this isn't characterised yet.

BGA tends to be better than QFP.
User avatar
dan
Experienced Member
Posts: 102
Joined: Mon Feb 22, 2010 2:30 pm

Post by dan »

Heater wrote: Ayway octal and I are looking at bringing the ZPU architecture to the XMOS. There is a GCC compiler for the ZPU and we have a ZPU virtual machine to run on an xcore. Performance is not a priority here so much as just being able easily run large C programs with program/data in some external memory. After all there is 7 other threads available on the xcore for the time critical work.

So having big gobs of external RAM via quad SPI in which the ZPU code could operate would be just perfect.
Hi Heater,

That's really interesting. Obviously due to the memory restrictions of current xmos devices this would be really valuable. Can you point this ZPU newbie to some introductory material about ZPU?

Also, regarding external memory, we are now working on an SDRAM controller that'll deliver up to 100 MB/sec (for large bursts). But I like the quad SPI alternative as well.

- Dan
jmg
Member
Posts: 8
Joined: Thu Mar 22, 2012 11:50 am

Post by jmg »

Heater wrote: So having big gobs of external RAM via quad SPI in which the ZPU code could operate would be just perfect.
Seems the choices here are expanding nicely.

For pure SRAM you have
Microchip at 32KB & 20MHz (no sign yet of larger/faster parts ? )
IPSiLog go to 64KB @ 20MHz, but not so easy to buy

then for code rather than data, you have the new Spansion DDR QuadSPI Flash memory,
* I see Macronix also do DDR qSPI, but for some reason, cloak that fact by calling it DTR
They start at 64MB MX25L6445E

and there are more devices in the middle, non volatile so not cheap, but available and an option for development, and they are faster which may matter.

Cypress NVSRAM - SPI to 40MHz 8KB/ 32KB/128KB at 40MHz

Everspin MRAM, 32KB / 128KB / 512KB 40MHz - all now at Digikey.
(They claim unlimited writes ? )

and FRAM from Ramtron and Fujitsu, but lower MHz and finite cycles.

Any artwork would be sensibly done for QuadSPI connections, so when SRAM does ship in DDR Quad models, it can drop onto the board.
Probably best to keep separate (not shared) pin access on CODE and DATA blocks.