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...
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.
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.
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.
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.
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.
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.
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?
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.
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.
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?
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.
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.
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.
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:
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.
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.
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 ?
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 ?
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).
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.
Comments
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...
Ok, maybe not really, it pulls it into the cog first...
Still, could be a way to run huge programs...
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.
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.
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.
Maybe there's a clever way the use the shared LUT feature to some advantage...
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.
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.
Also looks like 4-lane with DDR also saves a lot of energy for any given transaction.
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...
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:
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.
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.
http://www.cypress.com/file/216421/download
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.
http://www.cypress.com/file/177966/download
Looks in stock at Mouser...
Try googling "ddr qpi flash"
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 ?
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
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 ?
Yup, certainly, and the Streamer in both Nibble and Byte modes too...
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).
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.