Octal xSPI Memory
Blazingly Fast. Low Power Consumption
- High Bandwidth
- Low Power
- Read While Write
With the need for greater processing performance at lower power, execute-in-place (XiP) is quickly becoming the architecture of choice for IoT devices. EcoXiP’s blazingly fast performance and low power consumption allow even time-critical software to be executed directly out of non-volatile memory, reducing boot time and system cost.
Best performance, best power
CoreMark® test on NXP’s i.MX RT1050 with 8 instruction cache
invalidations every ms to simulate task switching & interrupt handling.
CoreMark® score / power consumption.
EcoXiP Octal xSPI Memory
|Density||Product / Datasheet||Speed||Vcc range||Interface||Details||Status||Samples|
|128Mbit||ATXP128 (up to 105°C)||150MHz||1.7V-1.95V||SPI Octal SDR/DDR||● Active||Order Samples|
|64Mbit||ATXP064B (up to 105°C)||170MHz||1.7V-1.95V||SPI Octal SDR/DDR||● Preview||Order Samples|
|32Mbit||ATXP032 (up to 105°C)||150MHz||1.7V-1.95V||SPI Octal SDR/DDR||● Active||Order Samples|
|ATXP128-CCUE-Y||24CC - 8x6|
|ATXP128-CCUE-T||24CC - 8x6|
|ATXP128-UUE-T||WLCSP - Contact Adesto|
|ATXP128-DWF||See Wafer-Die Solution Menu|
|ATXP032-CCUE-Y||24CC - 8x6|
|ATXP032-CCUE-T||24CC - 8x6|
|ATXP032-UUE-T||WLCSP - Contact Adesto|
|ATXP032-DWF||See Wafer-Die Solution Menu|
|ATXP064B-CCUE-Y||24CC - 8x6|
|ATXP064B-CCUE-T||24CC - 8x6|
|ATXP064B-UUE-T||WLCSP - Contact Adesto|
|ATXP064B-DWF||See Wafer-Die Solution Menu|
Adesto EcoXiP Octal EVK Hardware Setup
Adesto EcoXiP Octal EVK Software Setup
Read While Write feature improves system performance
4 months ago
AT25SL128A Data Corruption on WritePosted by MortenSchmidt 30 points 3 replies
We are using AT25SL128A and have a problem with data corruption. We use 8MHz plain SPI mode and have also tried 4MHz clock. We operate in SPI mode 3, verified with logic analyzer the SPI format is valid.
One in about 10-50 writes fail our readback test. Subsequent reads produce consistent output, the problem is isolated to the write operations.
The corruption also always results in one or two bits that should be 1 being corrupted to 0. Never the other way around.
The corruption always occurs in the 2nd last byte in a block.
Most of the time only one bit is corrupted but we have sometimes seen two, and when this happens they are two adjacent bits.
We have verified signal integrity. MISO from AT25SL128A has rise and fall times just about 2.2ns without ringing and CLK+MOSI have rise/fall times just about 7ns without ringing. Traces are quite short. Further the fact we have seen two 1's in a row corrupted to two 0's steers suspicion away from a signal integrity problem.
We have also experimented with improved power supply decoupling and even external 1.8V from an independent 1.8V supply, none of this has made any difference.
What could possibly be the problem here?