Interfacing Quad SPI flash to an XMOS device

[leon_heller]

I started designing a board with two chips on it. Here is the schematic:

http://www.leonheller.com/XMOS/W25Q.pdf

I think it was intended for an XC-1A board.

[jmg]

I can see different levels to this problem.

Sending the clock as data, allows fine control of clocks, and also allows a pause to change direction, but it will always be slower.

Using CS timed on a non-gated clock will be fastest, but is best suited to one-direction.
eg The Erase commands, and a Page write all work write-only from the host.
A good test point would be high-speed-path output on these, and a slower read-back to verify.

This mode will also suit FPGA interfaces, which may have a separate signal line for Direction.
In one application, we plan a Quad channel for main data, and a single-pin channel for general control.

This can have data, CS qualified, and even a few bits gives useful control.
(one FPGA example could be first N bits after CS _/=, set the mode for next CS low )
Using this, could give a FPGA mode that is read-only, during the CS active, that should also have
maximum-speed ability.

Most challenging will be the QuadSPI read, when you need to write an address, then flip BUS direction, but cannot change CS to qualify the clock, and HOLD is swallowed by IO3.
So this may require a hybrid, of a lower speed ADDRESS (CLK as Data) send, and then a Flip to CLK out mode.

Delays in hand-over of clock should be somewhat forgiving, as the same clock shifts in data, not so sure about glitches at hand over ?. Provided BOTH ends see the pulse, it should be ok.

End-of-read should also be ok as now CS can be used, and read-overrun does not matter so much on a QuadSPI memory, as the next read has a new address prefix. (write over-run is a no-no)
Once CS is high, Stop clock can be issued to save power, but the latencies do not matter.

So the general channel form would be
* Quad Main Data = 4 bits I/O, read/write as 4bit buffered
* CSn, clock qualifier, sent as single bit buffered data
* FPCD - fpga control data (optional) , as for CSn, logic level, or data sent as single bit buffered data
This may not need to be continuous, an update at each CSn edge supports 32+32 bits of signaling control.

The 700MHz XS1–S mentioned, becomes interesting. That suggests 175MHz fpga speed on paper, but as that will push PortIO speed, this would probably be better supported with a DDR 87.5MHz clock ?

With a DDR clock, then Clock-as-Data is less of an issue, as it does not limit the bandwidth.
It would need a fractional phase shift, to give Tsu/Th

I just searched again, as DDR QuadSPI is really just a matter of time, and voila :

http://www.spansion.com/Support/Datashe ... 56S_00.pdf
http://www.spansion.com/Products/Serial ... %20FL.aspx

Nice device, and available, if not quite as cheap as SDR.
Specs an impressive 66MBytes/sec bandwidth

This does DDR by opcode, so the first 8 edges are 1wSDR, then it flips to 4wDDR. So to keep the port modes, you could map that 8 bit opcode, onto 64 bits.

[Folknology]

Yeah the DDR QuadSPI is an interesting development but unless the XS1-SU1 has something new up its sleeve in terms of IO spec there is no chance of using that here. Unfortunately the Datasheet still quotes 'TBC' when it comes to port sample frequency/validity. Also both edge clocking has historically been a no no on Xmos XS1. Anyone from Xmos care to enter this conversation and help us out regarding port timings ?

regards
Al

[jmg]

Also both edge clocking has historically been a no no on Xmos XS1. Anyone from Xmos care to enter this conversation and help us out regarding port timings ?

The Xmos has no native support for DDR, but I think it can easily work with DDR QuadSPI ?

You generate the DDR clock using a data stream (as they do now for SPI) and use opposite edge clocking on the associated DATA lines, to meet Tsu/Th during write.
Should give 62.5MBytes/sec peak transfer, on a 500MHz part, which is quite close to the memory spec ceiling of 66MBytes.
The XMOS ports see a clock of 125MHz, whilst the SPI memory sees 62.5MHz

I think the XMOS ports can delay-adjust to 2.5ns(400MHz) steps, in one direction at least, and you read based on the 'internal' 125Mhz clock + delay, not on the SPI clk line.

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.

[leon_heller]

Al,

Any comments on my schematic?

[Folknology]

Hold off on the schematics Leon until we fully understand what is possible and the caveats/hoops we have to jump through. I am trying to understand Jmg's comments but they are a little over my head (clearly he has some experience with QuadSpi) and also the possibility of DDR is intriguing, unfortunately we don't have any input from Xmos yet on this thread, it would be helpful if they would participate given how much better they understand the in and outs of the ports/direction changes etc..

regards
Al

[Bianco]

Yeah the DDR QuadSPI is an interesting development but unless the XS1-SU1 has something new up its sleeve in terms of IO spec there is no chance of using that here. Unfortunately the Datasheet still quotes 'TBC' when it comes to port sample frequency/validity. Also both edge clocking has historically been a no no on Xmos XS1. Anyone from Xmos care to enter this conversation and help us out regarding port timings ?

regards
Al

Hi Al, there are no major changes in SU with regards to ports.

[Folknology]

Yeah the DDR QuadSPI is an interesting development but unless the XS1-SU1 has something new up its sleeve in terms of IO spec there is no chance of using that here. Unfortunately the Datasheet still quotes 'TBC' when it comes to port sample frequency/validity. Also both edge clocking has historically been a no no on Xmos XS1. Anyone from Xmos care to enter this conversation and help us out regarding port timings ?

regards
Al

Hi Al, there are no major changes in SU with regards to ports.

Thanks for responding Bianco

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

P.S. do you have any thoughts on what Jmg is saying about ways of shoe horning QuadSPi memory onto XS1, I would appreciate you input.

regards
Al

[Bianco]

Yeah the DDR QuadSPI is an interesting development but unless the XS1-SU1 has something new up its sleeve in terms of IO spec there is no chance of using that here. Unfortunately the Datasheet still quotes 'TBC' when it comes to port sample frequency/validity. Also both edge clocking has historically been a no no on Xmos XS1. Anyone from Xmos care to enter this conversation and help us out regarding port timings ?

regards
Al

Hi Al, there are no major changes in SU with regards to ports.

Thanks for responding Bianco

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

P.S. do you have any thoughts on what Jmg is saying about ways of shoe horning QuadSPi memory onto XS1, I would appreciate you input.

regards
Al

I am not saying that there aren't any changes at all but something radical like DDR support you can forget.
One reason could be that since it is different silicon everything needs to be verified again and since it is different silicon it might also differ a bit. Not to forget there may be some changes to improve timing. Don't forget that this is a preliminary datasheet and it could just have been a lack of time to fill in the tables.

I haven't looked into this quad spi in detail and I lack a bit of time right now, sorry.

[Folknology]

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.

regards
Al