Feb 16, 2012

Infrastructure for Application Security

posted by Bryon Moyer

Security is becoming an increasingly visible topic in discussions of things embedded and mobile. While the need to be secure isn’t new, there’s more of a push to change architectures to make them intrinsically less open to skullduggery.

One simple embodiment of the notion is to partition execution into two: one running a standard rich OS, which looks very much like what we’re used to – let’s call it the lay environment, the secular world. All kinds of things happen out there, many of which we don’t talk about. Then there’s a second environment running a minimal secure OS which acts as a “trusted” environment – let’s call it the temple. We don’t get to see what’s going on in there (although we can create salacious myths about the their rituals). This is where the Golden Legacy is protected so that, even if the lay world sends itself up in flames, there is a kernel of civilization that can re-seed the lay world anew.

Communication between the two worlds is carefully managed by a messaging system as if through anointed mutes with elaborate credentials and passwords.

This is the kind of world that Elliptic is trying to fit into. They’ve unveiled their new tVault infrastructure for supporting security in applications. This is a capability that’s invisible to the user and even to the application programmer: it supports higher-level security features. For instance, they’ve got it running under Android’s Security Framework. Apps programmers program to the Android API; underlying that, tVault manages the implementation.

tVault helps handle secure data and transactions like encryption key storage and retrieval. Applications and processes get IDs so that only the correct program gets access to its data; no other process can intercede and bugger off with someone else’s key.

The tVault concept is actually a collection of firmware, APIs, hardware support, and hardware acceleration. Their first focus is DRM on Android machines.

You can find more in their release

Tags :    0 comments  
Feb 10, 2012

Missing LED Details

posted by Bryon Moyer

Two releases came out within a few days of each other that make very similar claims for very different reasons, with neither of them providing the real data that would back the claim.

On Monday, Plessey announced that they were cutting the cost of high-brightness LEDs by going to 6” GaN-on-Si technology; they were acquiring CamGaN, a Cambridge spin-out. They make their cost comparison to SiC or sapphire technology.

Then, on Tuesday, Cree announced that it was doubling the lumens/dollar (or, conversely, cutting the cost of a lumen in half) for its SiC technology. While that doubling was with respect to its prior family, the general tone of the release was that this “…addresses the largest obstacle to mass LED lighting adoption, initial cost, and enables LED lighting systems to replace their inefficient ancestors.”

So the general impression is that both of these take cost (and, by implication, pricing) where it’s never gone before. And yet, even though the main message in both is about cost or price, there is no price information anywhere in either release.

Now, I’m generally not a big follower of pricing information in press releases; I’m much more interested in the “how” than the “how much.” But when your story is about price (ultimately), then it seems like that’s relevant information. Even if just a general range.

Nonetheless, neither company responded to a request for more information on pricing. Not even a “thanks for your interest, but we can’t give you that.”

You can find more about Plessey’s release here and Cree’s here. “More,” however, doesn’t include price.

Tags :    0 comments  
Feb 06, 2012

What Comes Around… Is Reflected?

posted by Bryon Moyer

With higher-frequency (GHz) signals becoming more prevalent on trusty old-school FR-4 boards, it’s become increasingly important to test the quality of the lines – specifically, their insertion loss (SDD21) – as a PCB manufacturing step. The problem is that you have to probe both ends of a trace in order to do this. Not so hard in the lab, but high-volume testers aren’t really built for that – they want to probe in one place.

Two years ago at DesignCon, Intel proposed a new method of determining the insertion loss by taking time-domain measurements at only two points, both at the same end of the line. They called it “Single-Ended TDR to Differential Insertion Loss,” or SET2DIL.

A quick terminology note here: there seems to be inconsistency in the industry about what those test points are called. Some refer to them as two “terminals,” which equate to one “port.” Rhode and Schwartz (and perhaps other) seem to equate “terminal” and “port,” so the kinds of systems we’re talking about here are all four-terminal systems, but may be two-port or four-port systems, depending on your definition of “port.” So the problem being solved here is the ability to test the four-terminal system by measuring only two terminals. And, critically, both of those terminals are at the same end of the two traces that make up the differential pair.

At this year’s DesignCon, SET2DIL appears to be showing up, at least in software form. Rhode and Schwarz was demonstrating, among other things, that their vector network analyzer (VNA) could make the time domain (reflectometry or transmissometry) measurements and then drive them into a computer that ran the SET2DIL algorithm to calculate the differential insertion loss. They say that they’re working to integrate the algorithm into the VNA itself.

Polar Instruments also appears to be supporting SET2DIL in software as of their 2012 Atlas release.

More information on Rhode and Schwarz’s solution can be found in their release.

Tags :    0 comments  
Get this feed  
« PreviousNext » 1 2 3 4 5 6 ... 55

Login Required

In order to view this resource, you must log in to our site. Please sign in now.

If you don't already have an acount with us, registering is free and quick. Register now.

Sign In    Register