The first new feature to be announced is TCG Opal compatibility, basically the consumer version of the enterprise Trusted Computing Group (TCG) standard. Since Sandforce controllers themselves don’t qualify for TGC certifications, only the end devices do, they won’t directly get the stamp of approval. Devices built around Sandforce silicon should have an easy time getting that stamp unless they do something very odd with the firmware. Sandforce also helps OEMs work through problems should there be any that crop up.
Sandforce wants all the drives running their silicon to be Opal certified and the best way to do that is by providing silicon that meets the standard and helping OEMs to not screw it up from there. They also work with the two main suppliers of TCG silicon to make sure any software they produce is aware of Sandforce controllers and their capabilities. This makes the drive controllers about as compatible and ready out of the box as possible, not much more can be done.
Next we come to a new power savings mode called DevSleep that so far is only compatible with Haswell systems. The idea is to drop power to the point where the Microsoft connected standby features don’t suck batteries dry, at least from the drive side that Sandforce deals with. The idea is to have <5mw idle states for the controller, and the current silicon is far sub 1mw.
.047mA is not exactly high power draw for an SSD
In a demo shown to SemiAccurate the Sandforce based drive was pulling a bit over 20mA at 3.3V without DevSleep, put the drive in DevSleep mode and it dropped to <.05mA or a bit over .16mW. How does it work? If you assert the previously undefined pin 3 on the SATA power connector with DevSleep silicon on both sides, the drive goes to (Dev)Sleep. Simple, easy, and low power. Given the lack of complexity it should be pretty idiot proof too, one signal isn’t a high bar to send.
When talking about how it works on the drive side, LSI didn’t want to give away all the secrets but did broadly talk about how it works. The drive isn’t idle in DevSleep, it is totally off. When you wake it up, the silicon effectively boots really fast, fast enough for the user not to notice any interruptions at all. All the code is local on ROM but LSI wouldn’t say if the Sandforce controllers have that ROM on device or off. Given how much of a concern power and speed are the code is almost assuredly on the controller itself but no more details were forthcoming.
Those are the two new features Sandforce is talking about. The silicon isn’t changed but the features are either added through firmware or just disclosed for the first time. Given how much of a pain TCG problems are to solve, Opal compatibility with all the extras is a really good thing. DevSleep is too, at least on a technical level but Microsoft’s utter inability to secure a wet paper bag means it will end up being a nightmare for malware removal. Luckily that isn’t Sandforce’s problem, they just deliver low power use silicon and hope the software guys don’t screw it up badly. For the things they control, everything seems to be done right.S|A
Have you signed up for our newsletter yet?
Did you know that you can access all our past subscription-only articles with a simple Student Membership for 100 USD per year? If you want in-depth analysis and exclusive exclusives, we don’t make the news, we just report it so there is no guarantee when exclusives are added to the Professional level but that’s where you’ll find the deep dive analysis.
Latest posts by Charlie Demerjian (see all)
- Globalfoundries 7nm process isn’t even close to the name - Sep 26, 2016
- ARM upgrades realtime offerings to v8-R and adds Cortex-R52 - Sep 21, 2016
- Everspin and Globalfoundries team up for embedded ST-MRAM - Sep 15, 2016
- Intel’s Xpoint is pretty much broken - Sep 12, 2016
- ARM adds 2048-bit vectors to v8A with SVE - Sep 7, 2016