Last Summer the SD association released SD 7.0 specification with two key new features: SD Express adding PCIe and NVMe interfaces to the legacy SD card interface for transfer rates of up to 985MB/s, and SDUC (SD Ultra Capacity) card allowing capacities of up to 128 TB. This all looks great, but while the latter was available for both micro SD cards and full size SD cards, microSD cards could not benefit from the new high speed interfaces part of SD Express specification.
SD 7.1 specification fixes that, as the SD association has now added microSD Express card which will also be able to reach up to 985MB/s (in theory) thanks to PCIe/NVMe interfaces, so we’ll be able to get sort of “removable SSDs” for smartphone and other devices that compatible with SD Express.
As illustrated above microSD Express cards will be available in various capacities as microSDHC Express, microSDXC Express and microSDUC Express cards.
Beside the higher transfer rate, and larger capacities we can expect from such microSD cards, PCIe3.1 also includes the low power sub-states (L1.1, L1.2) enabling low power implementations of SD Express, and as a result, (micro)SD Express cards are expected to consume less energy than traditional microSD memory cards while keeping the same maximum consumed power.
Both SD Express and microSD Express cards are currently powered by 3.3V and 1.8V, but an optional 1.2V supply is planned for the future with additional pins for both form factor. More technical details about (micro)SD Express card can be found in this white paper.
AFAIK, nor SD Express, microSD Express cards, or host devices that support SD Express specification are available for sale. The best microSD cards money can (soon) buy are SanDisk Extreme microSDXC UHS-I card and Micron c200 1TB microSDXC UHS-I card both with 1TB capacity, and transfer rates of around or slightly above 100MB/s.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Just one small, itsy bitsy tiny problem. This would require a space PCIe 3.0 lane from the SoC, which very few SoCs have today, be it for phones, tablets or general purpose use. We might see this in some cameras a couple of years down the road, but I expect it to take at least 3-4 years until this is a common standard in high-end phones, even longer to trickle down to mainstream devices. Just look at the uptake of UHS-II and UHS-III and you’ll get my point.
Beyond that, it looks like a great improvement of the standard. I just wish they’d simplified the naming scheme when they had the chance, but alas…
Spare, not space of course… doh!
More transfer rate is nice, but that’s not been the limit on SD/uSD card performance for a while. A1 and A2 are the most important specs for real world applications. The upside of this spec is that the protocol changes to the much more efficient NVMe standard which can handle more parallel requests–both for reading and writing.
One hopes that if a company goes through the trouble of adding this epensive electrical interface that they’ll actually use a decent flash controller and good performing flash memory in the device.
That only leaves us with the issue that @TLS mentions. I don’t see a lot of spare PCI-e lanes on SoCs these days. Soon, maybe?
Do you know what the memory size and transfer speed limits are on a USB3 thumb drive?
I’m not sure what you mean by memory size. Do you mean the maximum addressable storage? IIRC, it uses an escapsulated SCSI command set, so it’s probably in the Petabytes or so. The transfer speed limits for USB3.1Gen1 5Gt/s with a 8/10 encoding, plus protocol overhead. I’ve seen practical limits of 480MB/s or so. No host is perfect nor is any device, so you’ll never get peak theoretical speeds from anything. Newer versions of USB3 bring 10 and 20 Gt/s signaling, so you can probably multiply that value by 2 and 4–keeping in mind that the absolute latencies will take 2x or 4x the penalty out of that. Can’t beat the speed of light.
> I’ve seen practical limits of 480MB/s or so
I’ve seen a bit above 400 MB/s with external UAS enabled USB3 storage. But an ‘USB3 thumb drive’ usually isn’t UAS (USB Attached SCSI) capable and as such way slower. Also 100% of those I own or know are prone to thermal throttling and those theoretical sequential transfer speeds are far far away from reality (which is often lower than 30MB/s just after 2 minutes of continuous use when the thumb drives starts throttling).
What’s more interesting than those irrelevant sequential transfer speeds is random IO. But people will never stop to compare MB/s numbers while they should focus on IOPS with their use cases.
Fun fact: when doing some tests about swap efficiency it turned out that an USB2 connected SSD performed faster compared to the same SSD behind an USB3 port: https://forum.armbian.com/topic/8161-swap-on-sbc/
@tkaiser
So if the thumb driver are having thermal heat build up problems, do the SD cards experience over heating and throttling too ? If not, how are SD cards getting around the heat problem.
> do the SD cards experience over heating and throttling too
They heat up of course too. My only use case for this kind of sequential IO is writing OS images to SD cards, the fastest I get are 80 MB/s (my MacBook or its card readers are the bottlenecks here), I usually burn only small images (Armbian) but recently played with Fedora 29 (~12GB). I didn’t take care of throttling but the card was pretty hot after ejecting it (burning will take just 150 seconds at 80MB/s anyway).
BTW: this here is cnx-software.com and not a place dedicated to digital cameras or video recorders… so why are people talking about irrelevant sequential transfer rates measured in MB/s all the time and not about low latency and high IOPS?
With those new specs thanks to PCIe/NVMe both low latency and high random IO performance should be possible but why would I want to expose a PCIe lane to the outside of an embedded device? I’ve not seen that security has any importance in the embedded world yet and as such https://en.wikipedia.org/wiki/DMA_attack is a real issue…
Why video and cameras ?
Probably historical reason, Photography and Video use of SDcards came before RPI etc
A1 A2 class are more recent measurements.
I wonder how long till they make the SDcard memory just part of the SBC. Cutting out the SDcard packing and the retail packaging.
SDcard maker will not move to fast so they kill off small capacity SSD, in my opinion.
You mean something like eMMC? 😉
> I don’t see a lot of spare PCI-e lanes on SoCs these days
The Apple SoCs for mobile devices have some dedicated to NVMe storage since at least 3 years, and somewhat comparable SoCs from HiSilicon, Samsung, Qualcomm and the like are also equipped with PCIe since quite some time.
BTW: interesting forecast from 3 1/2 years ago: https://www.flashmemorysummit.com/English/Collaterals/Proceedings/2015/20150811_S101C_Baram.pdf
Yes, all mobile SoCs that support UFS flash supports PCIe, but you don’t have spare lanes sitting around waiting for this standard. PCIe takes up a lot of die space, so it means larger, more expensive chips. Which is why I think it’ll take some time until we see device support.
I did say “spare” PCI-e lanes, not simply PCI-e lanes at all. I’m not going to refer to Apple chips as they aren’t available for anyone else to use and they have never supported any kind of SD card. 🙂
Other SoCs that have had PCI-e lanes have only ever had one controller, no? That means you would have to decide which purpose to put the lanes to. Do you use it for a uSD express card or do you use it for SATA, wireless, etc.?
The scope of that comment is also inside that of ‘devices you would put a uSD card in for storage’ which further limits it. You can leave out high end networking SoCs like the Marvel chips–you’d never put something like uSD on them for storage when you could put on something higher performing and more reliable. The kinds of boards that use uSD cards like the ODROIDS (and even they offer eMMC because of the limits of SD), the Orange Pies, Raspberry Pies, etc. haven’t expanded into the world of SoCs with lots of PCI-e. Looks like we are starting to get a few boards in that camp with any PCI-e lanes. Maybe in a year or more when they start using SoCs with two PCI-e controllers–so that there is a spare for uSD express–these cards will start being relevant to readers of this news site.
Photography websites and some Android phone/tablet websites are excited by this announcement, but they’re further up the product stack than most of use here. As @TLS points out, they’ve had UFS for some time, so this isn’t as much of a change for them.
> You can leave out high end networking SoCs like the Marvel chips–you’d never put something like uSD on them for storage
Well, all our Marvell boxes and also all the large x86 servers run off SD cards or USB pen drives since why wasting a SATA or PCIe port for something that boring as ‘OS drive’ (it’s always about the use case and storage access patterns).
And I didn’t thought about those SBC anyway since why would someone who wants to buy cheap spend money on fancy storage like PCIe attached SD cards? And I’m totally with @dgp wrt DMA attacks, we had the problem already with Firewire/IEEE1394 and similar stuff decades ago…
>also all the large x86 servers run off SD cards or USB pen drives since why
>wasting a SATA or PCIe port for something that boring as ‘OS drive’
That’s interesting.. I guess you aren’t writing much back to the boot drive? In which case what is the advantage of booting from local media instead of from TFTP, PXE or whatever?
> I guess you aren’t writing much back to the boot drive?
Exactly. It’s what we called WORM (write once, read mostly) in the past. The benefit is offline cloning of the boot media for ‘backup’ purposes (easier than with SATA or NVMe). Netbooting is not an option since these machines are the PXE servers (amongst other stuff).
I’m not talking about a fleet of x86 servers (datacenter or cloud) but just a few per installation/location: 2 or 4 for the storage cluster, 2 for the virtualization cluster where almost everything runs, single storage servers for archive/backup purposes or at remote offices.
I can’t wait for someone to come up with an adapter that turns the PCI-E lane into a standard connector or rogue SD cards that use DMA attacks to root the host system and install malware.
If only there were such things like IOMMUs to protect from just this attack vector….
SDUC support appears to start at 2TB according to the sd website, so it likely will be quite some time before they are mainstream.
where can we buy these microSD Express controller breakout boards and hats
I don’t think they are available just yet.