Microchip QuadSPI 80MHz or 40 Bytes/Second/Chip.
jmg
Posts: 15,185
I see new info on 16/32 MBit, QuadSPI 80MHz parts SST26VF016 / SST26VF032
http://ww1.microchip.com/downloads/en/DeviceDoc/25017A.pdf
These are designed for 'execute in place', and they have some additional commands, to lower the
Address-change overhead. Priced ~ $1.50/ $3.00
New address is usually 5 Bytes [Opcode+3B Adr+dummyB], but they have a page-jump., that is [Opcode+1B Adr+dummyB]
Opcode summary:
High-Speed Read Read Memory at Higher Speed 0BH+ 3 + 1
Read PI Jump to address within 256 Byte page indexed by n 08H+ 1+ 1
Read I Jump to address within block indexed by n 09H +2+ 2
Read BI Jump to block Indexed by n 10H +1 +2
Page jump drops from 5 bytes to 3, a worthwhile gain in speed.
I jump seems pointless from a time-budget angle, as the time is the same as a full address, but I could see some use in a simple file-Blocking design, that allocates 1 page (64K) per 'file' - with Block-relative opcodes, it would not care which physical chip page it was located in.
The decision to issue a Full, or Page jump looks like it could be done at the HW level, needing just a copy of the upper 16 bits. If only the lower 8 bits have changed, it can send 08H, instead of 0BH.
Likewise a flag could be used to say if 16 or 24 bit addressing within the executable was being used.
Small Code would run with 16b page, and the 'OS' would select the page.
A core with a skip opcode, would also match up well with this sort of memory.
Given the prop's memory-dictated design, this type of smarter/faster Serial memory looks very important.
Hopefully the Prop2 fully supports all this in silicon, but it would be easy to confirm operation with a SW overhead in a Prop 1.
http://ww1.microchip.com/downloads/en/DeviceDoc/25017A.pdf
These are designed for 'execute in place', and they have some additional commands, to lower the
Address-change overhead. Priced ~ $1.50/ $3.00
New address is usually 5 Bytes [Opcode+3B Adr+dummyB], but they have a page-jump., that is [Opcode+1B Adr+dummyB]
Opcode summary:
High-Speed Read Read Memory at Higher Speed 0BH+ 3 + 1
Read PI Jump to address within 256 Byte page indexed by n 08H+ 1+ 1
Read I Jump to address within block indexed by n 09H +2+ 2
Read BI Jump to block Indexed by n 10H +1 +2
Page jump drops from 5 bytes to 3, a worthwhile gain in speed.
I jump seems pointless from a time-budget angle, as the time is the same as a full address, but I could see some use in a simple file-Blocking design, that allocates 1 page (64K) per 'file' - with Block-relative opcodes, it would not care which physical chip page it was located in.
The decision to issue a Full, or Page jump looks like it could be done at the HW level, needing just a copy of the upper 16 bits. If only the lower 8 bits have changed, it can send 08H, instead of 0BH.
Likewise a flag could be used to say if 16 or 24 bit addressing within the executable was being used.
Small Code would run with 16b page, and the 'OS' would select the page.
A core with a skip opcode, would also match up well with this sort of memory.
Given the prop's memory-dictated design, this type of smarter/faster Serial memory looks very important.
Hopefully the Prop2 fully supports all this in silicon, but it would be easy to confirm operation with a SW overhead in a Prop 1.
Comments
I've posted code for Prop1, which I am working to improve...
It is too late to ask for Prop2 support for Quad-SPI. Designing a chip specifically for this type of specialization from a single vendor would be a mistake anyway. A generic QuadSPI interface would be more palatable.
I also have QuadSPI solutions. One is available now in a DIP32 stamp-like module with a Propeller, crystal, eeprom, retulator and 2 QuadSPI chips in parallel on P0-7. The other solution that will run the demo is not announced yet, but it should be very interesting to many here.