Shop OBEX P1 Docs P2 Docs Learn Events
P2 Boot Decision Tree Suggestions - Page 8 — Parallax Forums

P2 Boot Decision Tree Suggestions

1456810

Comments

  • RaymanRayman Posts: 13,797
    edited 2016-10-01 17:08
    Here's another presentation on SQI flash from ST:
    http://www.st.com/content/ccc/resource/training/technical/product_training/73/9a/02/7b/df/8d/4c/21/STM32L4_Memory_QuadSPI.pdf/files/STM32L4_Memory_QuadSPI.pdf/jcr:content/translations/en.STM32L4_Memory_QuadSPI.pdf

    Reading this makes me think that a dedicated 4-bit SQI interface might be better.
    Or, at least, that 3-pin SPI support should not reduce SQI performance.

    If P2 had a dedicated 4-bit SQI interface, it would have superior speed to the internal flash of other microcontrollers.

    Also opens up the possibility of fast code execution from flash...
  • Rayman wrote: »
    Here's another presentation on SQI flash from ST:
    http://www.st.com/content/ccc/resource/training/technical/product_training/73/9a/02/7b/df/8d/4c/21/STM32L4_Memory_QuadSPI.pdf/files/STM32L4_Memory_QuadSPI.pdf/jcr:content/translations/en.STM32L4_Memory_QuadSPI.pdf

    Reading this makes me think that a dedicated 4-bit SQI interface might be better.
    Or, at least, that 3-pin SPI support should not reduce SQI performance.

    If P2 had a dedicated 4-bit SQI interface, it would have superior speed to the internal flash of other microcontrollers.

    Also opens up the possibility of fast code execution from flash...
    How do we execute code from flash? The P2 can't fetch instructions from external memory and has no TLB/cache mechanism.

  • RaymanRayman Posts: 13,797
    edited 2016-10-01 17:32
    Doesn't GCC do that already for P1?

    Ok, maybe not really, it pulls it into the cog first...
    Still, could be a way to run huge programs...
  • Rayman wrote: »
    Doesn't GCC do that already for P1? Ok, maybe not really, it pulls it into the cog first...
    Yes, PropGCC has XMM mode but that is just a variant of LMM where software fetches the instructions. I would assume we would want hardware to handle fetching the instructions on P2 and that would require something like a TLB to translate external addresses into locations in an on-chip cache.
  • cgraceycgracey Posts: 14,133
    edited 2016-10-01 19:29
    The SD SPI interface is a subset of SPI, as it doesn't even float DO on CSn low.
    Cluso99 wrote: »
    David Betz wrote: »
    Does an SD card work if you tie DI and DO on the SPI boot flash? In other words, can I share those three pins between a SPI boot flash and an SD card?
    NO. You will have contention on at least some cards, including SanDisk, because they do not drop driving the DO line when /CS goes high. It requires additional clocks with DI=1.

    In addition to this, the norm is for the micro to output DI=1 while receiving data in on the DO pin.

    Thus, SD SPI WILL NOT WORK WITH SHARED DI & DO !!!

    I think that is what you were after David.

    SD SPI will not even work on a SPI bus!

    While SPI memory chips are overly well-mannered, SD SPI doesn't even follow the basic SPI tristate rule per CSn.
  • cgracey wrote: »
    The SD SPI interface is a subset of SPI, as it doesn't even float DO on CSn low.
    Cluso99 wrote: »
    David Betz wrote: »
    Does an SD card work if you tie DI and DO on the SPI boot flash? In other words, can I share those three pins between a SPI boot flash and an SD card?
    NO. You will have contention on at least some cards, including SanDisk, because they do not drop driving the DO line when /CS goes high. It requires additional clocks with DI=1.

    In addition to this, the norm is for the micro to output DI=1 while receiving data in on the DO pin.

    Thus, SD SPI WILL NOT WORK WITH SHARED DI & DO !!!

    I think that is what you were after David.

    SD SPI will not even work on a SPI bus!

    While SPI memory chips are overly well-mannered, SD doesn't even follow the basic tristate rule per CSn.
    It does if you first get it out of SDIO mode I believe. The cache driver for the C3 has to do this since its SPI bus is shared between SD, SRAM, and flash.

  • David Betz wrote: »
    cgracey wrote: »
    The SD SPI interface is a subset of SPI, as it doesn't even float DO on CSn low.
    Cluso99 wrote: »
    David Betz wrote: »
    Does an SD card work if you tie DI and DO on the SPI boot flash? In other words, can I share those three pins between a SPI boot flash and an SD card?
    NO. You will have contention on at least some cards, including SanDisk, because they do not drop driving the DO line when /CS goes high. It requires additional clocks with DI=1.

    In addition to this, the norm is for the micro to output DI=1 while receiving data in on the DO pin.

    Thus, SD SPI WILL NOT WORK WITH SHARED DI & DO !!!

    I think that is what you were after David.

    SD SPI will not even work on a SPI bus!

    While SPI memory chips are overly well-mannered, SD doesn't even follow the basic tristate rule per CSn.
    It does if you first get it out of SDIO mode I believe. The cache driver for the C3 has to do this since its SPI bus is shared between SD, SRAM, and flash.
    Actually, I just realized that this doesn't really work. It's fine if the SD card is inserted when you initialize the common SPI driver but it fails if you hot-plug an SD card after initialization. Ugh.

  • cgraceycgracey Posts: 14,133
    edited 2016-10-01 19:32
    David Betz wrote: »
    David Betz wrote: »
    cgracey wrote: »
    The SD SPI interface is a subset of SPI, as it doesn't even float DO on CSn low.
    Cluso99 wrote: »
    David Betz wrote: »
    Does an SD card work if you tie DI and DO on the SPI boot flash? In other words, can I share those three pins between a SPI boot flash and an SD card?
    NO. You will have contention on at least some cards, including SanDisk, because they do not drop driving the DO line when /CS goes high. It requires additional clocks with DI=1.

    In addition to this, the norm is for the micro to output DI=1 while receiving data in on the DO pin.

    Thus, SD SPI WILL NOT WORK WITH SHARED DI & DO !!!

    I think that is what you were after David.

    SD SPI will not even work on a SPI bus!

    While SPI memory chips are overly well-mannered, SD doesn't even follow the basic tristate rule per CSn.
    It does if you first get it out of SDIO mode I believe. The cache driver for the C3 has to do this since its SPI bus is shared between SD, SRAM, and flash.
    Actually, I just realized that this doesn't really work. It's fine if the SD card is inserted when you initialize the common SPI driver but it fails if you hot-plug an SD card after initialization. Ugh.

    Maybe it's just a supposed reliance upon drivers that causes a lot of the concern over how to work this, exactly. This is a Prop chip, though, and you can program it to do things however you want.
  • cgracey wrote: »
    David Betz wrote: »
    David Betz wrote: »
    cgracey wrote: »
    The SD SPI interface is a subset of SPI, as it doesn't even float DO on CSn low.
    Cluso99 wrote: »
    David Betz wrote: »
    Does an SD card work if you tie DI and DO on the SPI boot flash? In other words, can I share those three pins between a SPI boot flash and an SD card?
    NO. You will have contention on at least some cards, including SanDisk, because they do not drop driving the DO line when /CS goes high. It requires additional clocks with DI=1.

    In addition to this, the norm is for the micro to output DI=1 while receiving data in on the DO pin.

    Thus, SD SPI WILL NOT WORK WITH SHARED DI & DO !!!

    I think that is what you were after David.

    SD SPI will not even work on a SPI bus!

    While SPI memory chips are overly well-mannered, SD doesn't even follow the basic tristate rule per CSn.
    It does if you first get it out of SDIO mode I believe. The cache driver for the C3 has to do this since its SPI bus is shared between SD, SRAM, and flash.
    Actually, I just realized that this doesn't really work. It's fine if the SD card is inserted when you initialize the common SPI driver but it fails if you hot-plug an SD card after initialization. Ugh.

    Maybe it's just a supposed reliance upon drivers that causes a lot of the concern over how to work this, exactly. This is a Prop chip, though, and you can program it to do things however you want.
    True but how would you handle someone inserting an SD card while the shared SPI bus is currently reading a SPI flash chip? Won't the initial SDIO state of the SD card interfere with the flash read?
  • cgraceycgracey Posts: 14,133
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    David Betz wrote: »
    cgracey wrote: »
    The SD SPI interface is a subset of SPI, as it doesn't even float DO on CSn low.
    Cluso99 wrote: »
    David Betz wrote: »
    Does an SD card work if you tie DI and DO on the SPI boot flash? In other words, can I share those three pins between a SPI boot flash and an SD card?
    NO. You will have contention on at least some cards, including SanDisk, because they do not drop driving the DO line when /CS goes high. It requires additional clocks with DI=1.

    In addition to this, the norm is for the micro to output DI=1 while receiving data in on the DO pin.

    Thus, SD SPI WILL NOT WORK WITH SHARED DI & DO !!!

    I think that is what you were after David.

    SD SPI will not even work on a SPI bus!

    While SPI memory chips are overly well-mannered, SD doesn't even follow the basic tristate rule per CSn.
    It does if you first get it out of SDIO mode I believe. The cache driver for the C3 has to do this since its SPI bus is shared between SD, SRAM, and flash.
    Actually, I just realized that this doesn't really work. It's fine if the SD card is inserted when you initialize the common SPI driver but it fails if you hot-plug an SD card after initialization. Ugh.

    Maybe it's just a supposed reliance upon drivers that causes a lot of the concern over how to work this, exactly. This is a Prop chip, though, and you can program it to do things however you want.
    True but how would you handle someone inserting an SD card while the shared SPI bus is currently reading a SPI flash chip? Won't the initial SDIO state of the SD card interfere with the flash read?

    Possibly. Even likely?

    Weigh that SPI SD is not compatible with an actual SPI bus because it breaks CSn-tristate/drive rule.

    The boot pins probably need to be left as just boot pins for reasons like these.
  • cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    David Betz wrote: »
    cgracey wrote: »
    The SD SPI interface is a subset of SPI, as it doesn't even float DO on CSn low.
    Cluso99 wrote: »
    David Betz wrote: »
    Does an SD card work if you tie DI and DO on the SPI boot flash? In other words, can I share those three pins between a SPI boot flash and an SD card?
    NO. You will have contention on at least some cards, including SanDisk, because they do not drop driving the DO line when /CS goes high. It requires additional clocks with DI=1.

    In addition to this, the norm is for the micro to output DI=1 while receiving data in on the DO pin.

    Thus, SD SPI WILL NOT WORK WITH SHARED DI & DO !!!

    I think that is what you were after David.

    SD SPI will not even work on a SPI bus!

    While SPI memory chips are overly well-mannered, SD doesn't even follow the basic tristate rule per CSn.
    It does if you first get it out of SDIO mode I believe. The cache driver for the C3 has to do this since its SPI bus is shared between SD, SRAM, and flash.
    Actually, I just realized that this doesn't really work. It's fine if the SD card is inserted when you initialize the common SPI driver but it fails if you hot-plug an SD card after initialization. Ugh.

    Maybe it's just a supposed reliance upon drivers that causes a lot of the concern over how to work this, exactly. This is a Prop chip, though, and you can program it to do things however you want.
    True but how would you handle someone inserting an SD card while the shared SPI bus is currently reading a SPI flash chip? Won't the initial SDIO state of the SD card interfere with the flash read?

    Possibly. Even likely?

    Weigh that SPI SD is not compatible with an actual SPI bus because it breaks CSn-tristate/drive rule.

    The boot pins probably need to be left as just boot pins for reasons like these.
    I'm not sure I'd go quite that far. If I have to put a SPI flash chip on a board for booting I'd also like to use it for other data storage including maybe a filesystem. I think it is likely to get used for purposes beyond just booting just like the upper half of 64k EEPROMs are on the P1.
  • By the way, the ESP8266 has two SPI busses. One is used to talk to the flash that is used for booting and for fetching code. The other can be used for whatever you want. I think they discourage you from trying to use the boot bus for anything other than booting and code execution.
  • RaymanRayman Posts: 13,797
    XMM might work better with P2 due to the executable LUT cog memory.

    Maybe there's a clever way the use the shared LUT feature to some advantage...
  • Rayman wrote: »
    XMM might work better with P2 due to the executable LUT cog memory.

    Maybe there's a clever way the use the shared LUT feature to some advantage...
    We can certainly provide faster XMM than on the P1 but it will still be quite slow compared with hub execution. On the other hand, code overlays could be fast. Didn't someone start working on using overlays with PropGCC on P1?
  • cgraceycgracey Posts: 14,133
    edited 2016-10-01 20:05
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    David Betz wrote: »
    cgracey wrote: »
    The SD SPI interface is a subset of SPI, as it doesn't even float DO on CSn low.
    Cluso99 wrote: »
    David Betz wrote: »
    Does an SD card work if you tie DI and DO on the SPI boot flash? In other words, can I share those three pins between a SPI boot flash and an SD card?
    NO. You will have contention on at least some cards, including SanDisk, because they do not drop driving the DO line when /CS goes high. It requires additional clocks with DI=1.

    In addition to this, the norm is for the micro to output DI=1 while receiving data in on the DO pin.

    Thus, SD SPI WILL NOT WORK WITH SHARED DI & DO !!!

    I think that is what you were after David.

    SD SPI will not even work on a SPI bus!

    While SPI memory chips are overly well-mannered, SD doesn't even follow the basic tristate rule per CSn.
    It does if you first get it out of SDIO mode I believe. The cache driver for the C3 has to do this since its SPI bus is shared between SD, SRAM, and flash.
    Actually, I just realized that this doesn't really work. It's fine if the SD card is inserted when you initialize the common SPI driver but it fails if you hot-plug an SD card after initialization. Ugh.

    Maybe it's just a supposed reliance upon drivers that causes a lot of the concern over how to work this, exactly. This is a Prop chip, though, and you can program it to do things however you want.
    True but how would you handle someone inserting an SD card while the shared SPI bus is currently reading a SPI flash chip? Won't the initial SDIO state of the SD card interfere with the flash read?

    Possibly. Even likely?

    Weigh that SPI SD is not compatible with an actual SPI bus because it breaks CSn-tristate/drive rule.

    The boot pins probably need to be left as just boot pins for reasons like these.
    I'm not sure I'd go quite that far. If I have to put a SPI flash chip on a board for booting I'd also like to use it for other data storage including maybe a filesystem. I think it is likely to get used for purposes beyond just booting just like the upper half of 64k EEPROMs are on the P1.

    I agree that a file system would be a totally appropriate use for the boot device. I just don't think those wires should be loaded up with other stuff. If you are running a file system, you may have a cog serving memory requests for other cogs. It is not going to work well if other cogs are wanting to talk to non-file system devices on those same wires.
  • David BetzDavid Betz Posts: 14,511
    edited 2016-10-01 20:07
    cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    David Betz wrote: »
    cgracey wrote: »
    The SD SPI interface is a subset of SPI, as it doesn't even float DO on CSn low.
    Cluso99 wrote: »
    David Betz wrote: »
    Does an SD card work if you tie DI and DO on the SPI boot flash? In other words, can I share those three pins between a SPI boot flash and an SD card?
    NO. You will have contention on at least some cards, including SanDisk, because they do not drop driving the DO line when /CS goes high. It requires additional clocks with DI=1.

    In addition to this, the norm is for the micro to output DI=1 while receiving data in on the DO pin.

    Thus, SD SPI WILL NOT WORK WITH SHARED DI & DO !!!

    I think that is what you were after David.

    SD SPI will not even work on a SPI bus!

    While SPI memory chips are overly well-mannered, SD doesn't even follow the basic tristate rule per CSn.
    It does if you first get it out of SDIO mode I believe. The cache driver for the C3 has to do this since its SPI bus is shared between SD, SRAM, and flash.
    Actually, I just realized that this doesn't really work. It's fine if the SD card is inserted when you initialize the common SPI driver but it fails if you hot-plug an SD card after initialization. Ugh.

    Maybe it's just a supposed reliance upon drivers that causes a lot of the concern over how to work this, exactly. This is a Prop chip, though, and you can program it to do things however you want.
    True but how would you handle someone inserting an SD card while the shared SPI bus is currently reading a SPI flash chip? Won't the initial SDIO state of the SD card interfere with the flash read?

    Possibly. Even likely?

    Weigh that SPI SD is not compatible with an actual SPI bus because it breaks CSn-tristate/drive rule.

    The boot pins probably need to be left as just boot pins for reasons like these.
    I'm not sure I'd go quite that far. If I have to put a SPI flash chip on a board for booting I'd also like to use it for other data storage including maybe a filesystem. I think it is likely to get used for purposes beyond just booting just like the upper half of 64k EEPROMs are on the P1.

    I agree that a file system would be a totally appropriate use for the boot device. I just don't think those wires should be loaded up with other stuff. If you are running a file system, you may have a cog serving memory requests for other cogs. It is not going to work well if other cogs are wanting to talk to non-file system devices on those same wires.
    I guess I'm beginning to agree with you on that. Took me long enough! :-)
    However, I'd still like to be able to use a QPI device on those pins.

  • cgraceycgracey Posts: 14,133
    edited 2016-10-01 20:23
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    David Betz wrote: »
    cgracey wrote: »
    The SD SPI interface is a subset of SPI, as it doesn't even float DO on CSn low.
    Cluso99 wrote: »
    David Betz wrote: »
    Does an SD card work if you tie DI and DO on the SPI boot flash? In other words, can I share those three pins between a SPI boot flash and an SD card?
    NO. You will have contention on at least some cards, including SanDisk, because they do not drop driving the DO line when /CS goes high. It requires additional clocks with DI=1.

    In addition to this, the norm is for the micro to output DI=1 while receiving data in on the DO pin.

    Thus, SD SPI WILL NOT WORK WITH SHARED DI & DO !!!

    I think that is what you were after David.

    SD SPI will not even work on a SPI bus!

    While SPI memory chips are overly well-mannered, SD doesn't even follow the basic tristate rule per CSn.
    It does if you first get it out of SDIO mode I believe. The cache driver for the C3 has to do this since its SPI bus is shared between SD, SRAM, and flash.
    Actually, I just realized that this doesn't really work. It's fine if the SD card is inserted when you initialize the common SPI driver but it fails if you hot-plug an SD card after initialization. Ugh.

    Maybe it's just a supposed reliance upon drivers that causes a lot of the concern over how to work this, exactly. This is a Prop chip, though, and you can program it to do things however you want.
    True but how would you handle someone inserting an SD card while the shared SPI bus is currently reading a SPI flash chip? Won't the initial SDIO state of the SD card interfere with the flash read?

    Possibly. Even likely?

    Weigh that SPI SD is not compatible with an actual SPI bus because it breaks CSn-tristate/drive rule.

    The boot pins probably need to be left as just boot pins for reasons like these.
    I'm not sure I'd go quite that far. If I have to put a SPI flash chip on a board for booting I'd also like to use it for other data storage including maybe a filesystem. I think it is likely to get used for purposes beyond just booting just like the upper half of 64k EEPROMs are on the P1.

    I agree that a file system would be a totally appropriate use for the boot device. I just don't think those wires should be loaded up with other stuff. If you are running a file system, you may have a cog serving memory requests for other cogs. It is not going to work well if other cogs are wanting to talk to non-file system devices on those same wires.
    I guess I'm beginning to agree with you on that. Took me long enough! :-)
    However, I'd still like to be able to use a QPI device on those pins.

    I hear you.

    I know people get excited about being able to read the SPI memory 4x faster, but what I fear is that it will rarely ever be used to any significant advantage, but always demanded as built-in, wasting pins, and making a more practical topology of only three pins look anemic, when three pins would have been a much better solution for almost everyone. When/if we get down to low-pin-count devices, we really need things to be tight and simple. I like the idea of solving this problem once and well.
  • RaymanRayman Posts: 13,797
    edited 2016-10-01 20:26
    It's 8x with DDR...

    Also looks like 4-lane with DDR also saves a lot of energy for any given transaction.
  • RaymanRayman Posts: 13,797
    edited 2016-10-01 20:37
    Maybe I could use a depletion mode mosfet to provide the initial tie between DI and DO.

    After boot, could use an I/O pin to make it go high impedance.
    So, I'd lose one pin, but save 3...

    Also need external pullup on CS for the case of reset when SQI is in data output state...
  • cgraceycgracey Posts: 14,133
    edited 2016-10-01 20:49
    Rayman wrote: »
    It's 8x with DDR...

    Also looks like 4-lane with DDR also saves a lot of energy for any given transaction.

    I've been looking and I can't find a DDR SPI flash. I know I've encountered a data sheet before that mentioned DDR.

    Here is from that presentation you posted:

    SPI_DDR.png

    Note that, for whatever reason, this is not showing a significant performance improvement. Maybe DDR SPI flash chips, or just this ST microcontroller, can't move the nibbles on every clock edge at the same clock frequency that it can move one nibble per clock cycle.
    1055 x 250 - 162K
  • RaymanRayman Posts: 13,797
    edited 2016-10-01 20:59
    The CPU speeds are different by factor of 2, right? Not exactly a fair test...

    I think P2's max input rate will equal clock frequency for DDR.
    Will be half of that for non-DDR, right?

    If we get a 160 MHz P2, then chip listed in next post can input at 80 MB/s.
  • cgraceycgracey Posts: 14,133
    edited 2016-10-01 21:46
    Rayman wrote: »

    Yes, that will do a full 80MHz, but it's a 1.8V part. That's probably why I couldn't find it, again. I had seen that before in my own searching. I wonder if there are any 3.3V DDR parts. I spent about 15 minutes searching DigiKey for DDR SPI parts, but I couldn't find anything, not even that 1.8V part.
  • RaymanRayman Posts: 13,797
    edited 2016-10-01 22:18
    Here's the 3.3 V version:
    http://www.cypress.com/file/177966/download

    Looks in stock at Mouser...

    Try googling "ddr qpi flash"
  • jmgjmg Posts: 15,140
    Rayman wrote: »
    If P2 had a dedicated 4-bit SQI interface, it would have superior speed to the internal flash of other microcontrollers.

    Also opens up the possibility of fast code execution from flash...
    Do you mean over and above the Streamer Nibble support, I believe is there already ?

    Has anyone done speed tests on a mix of Software and Streamer, for highest Flash read speeds ?
    Do you need to issue Command.Address in Software, then enable Streamer(nibble) for read, or can two streamer packets be closely packed.
    ie One Tx packet with Command+address, and another Rx packet 'right behind' that ?
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I've been looking and I can't find a DDR SPI flash. I know I've encountered a data sheet before that mentioned DDR.

    Sometimes this is also called DTR.

    The new ECOXIP parts have this
    http://www.adestotech.com/products/ecoxip/

    as also does the Macronix MX25LM51245G

    The appeal of these newest parts over HyperFLASH, is they include a SPI 1-Bit subset, so should Boot P2.

    HyperRAM and HyperFLASH are also DDR/DTR based memory
    Rayman wrote: »
    The CPU speeds are different by factor of 2, right? Not exactly a fair test...

    I think P2's max input rate will equal clock frequency for DDR.
    Will be half of that for non-DDR, right?

    If we get a 160 MHz P2, then chip listed in next post can input at 80 MB/s.

    DDR/DTR parts often also include a clock-echo, to compensate for PCB & pin delays, and in some cases to auto-qualify latency delays, and page-skip effects. Sometimes called DQS.

    I'm not sure P2 can properly support the DDR/DTR DQS ?

  • RaymanRayman Posts: 13,797
    Actually, I guess we should see if the current pin selection accommodates using the streamer in nibble mode...
  • jmgjmg Posts: 15,140
    Rayman wrote: »
    Actually, I guess we should see if the current pin selection accommodates using the streamer in nibble mode...

    Yup, certainly, and the Streamer in both Nibble and Byte modes too...

  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    Rayman wrote: »
    If P2 had a dedicated 4-bit SQI interface, it would have superior speed to the internal flash of other microcontrollers.

    Also opens up the possibility of fast code execution from flash...
    Do you mean over and above the Streamer Nibble support, I believe is there already ?

    Has anyone done speed tests on a mix of Software and Streamer, for highest Flash read speeds ?
    Do you need to issue Command.Address in Software, then enable Streamer(nibble) for read, or can two streamer packets be closely packed.
    ie One Tx packet with Command+address, and another Rx packet 'right behind' that ?

    It's too bad the streamer can't input a clock signal, instead of only running off its NCO's rollover. It would make software a little simpler. As it is, you need to coordinate instructions in time to get things correlated. I'm going to look into making the streamer trigger from pin rise, fall, and change (DDR).
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    Here's the 3.3 V version:
    http://www.cypress.com/file/177966/download

    Looks in stock at Mouser...

    Try googling "ddr qpi flash"

    That's the best SPI flash there is, I think. It can pump out nibbles at 160MHz. It costs about $2.10 in volume, which is only about 55 cents more than the inexpensive Winbond part of the same size.
Sign In or Register to comment.