Oct 28, 2013

Programmable SoCs?

posted by Dick Selwood

The scene: a top-secret conference room in the West of England.

Present: a group of high-powered technical guys.

Topic: The next stage in project X

 

We are now shipping quantities of project X. The press are going to start asking where we go next

We will soon be able to announce that Sony is using an 8 core device in their new headphone amplifier.

That’s good

And we are going to give away 2500 startKits and then sell more for only $14.99.

That’s good as well, but we need to push the technology even more.

We can add more cores?

We have committed to doing that.

We could add a different core.

Why?

People are using our products as an add-on for a standard processor. We provide specialist I.O. and also DSP and then an ARM based device runs the application.

So?

We could add an ARM core to our product.

How do we add an ARM.?

Well rather than implement one, ourselves we should talk to Energy Micro. They have some very low power Cortex-M3 processors. We can put in an interface between our xCONNECT switch and the ARM interface and it will look like just another core to our logical cores. Bang in some Flash and with ARM’s own memory and the xCORE RAM and then we have what is really a programmable  System on Chip, with a huge range of different interfaces available through software and 100#% timing determination. And it will be very low power so it can be used in battery operated devices

We can launch it in October 2013 in time for ARM Techcon.

And that is what those clever people at XMOS have done, despite Energy Micro becoming part of Silicon Labs (The joy of a fast moving industry) And if you want a sample they are now shipping samples for the top end xCORE–XA the XAU8-1024 with seven virtual cores and a Cortex M3, producing 500 MIPs performance with a typical power consumption of around 50 mA., 192KB of SRAM, 1024 KB of Flash, 38 I.0., and USB 3.0. There are multiple levels of stand-by with the lowest drawing only 100 nA.

You can see more at

http://www.xmos.com/products/silicon/xa-series

Tags :    0 comments  
Oct 25, 2013

LinkedIn’s Man in the Middle?

posted by Bryon Moyer

LinkedIn has just introduced a new phone app called Intro that helps provide information to you about LinkedIn members when they send you email. That info is added to the email itself. Or something like that.

Now… before I go much further, I have to admit (to anyone that hasn’t already seen this obvious point in some of my earlier stuff) that I still hold to quaint notions about privacy and keeping control over my own things and any statements or messages ascribed to me. When I tried to install the Facebook app on my phone and saw all of the things it got access to (like, everything), I backed out. So if you think that’s ridiculous, then perhaps you need read no further.

But I just saw an interesting review of this LinkedIn app, which some of the mainstream press is calling relatively innocuous (possibly because the implications aren’t obvious to them, just as they might not be to pretty much anyone that installs the app).

As much as I’m skeptical about the motives of a lot of these apps, I’m also aware that there are lots of hypesters out there that like to make mountains out of molehills to get Likes. So I don’t want to swallow this whole. But… an app that totally changes how your emails are routed? Running all your emails through their servers??? Sheesh, not even the NSA had the cojones (or the bright idea) to do that.

So I’m curious… do you guys agree with the analysis at the link above? Or is it overblown?

And if it is indeed that insidious, is this just a sign that sheeple will install anything? Or at some point will people start to become suspicious of apps? And if people stop trusting the basic app concept, what does that do to the overall cell phone business ecosystem?

Tags :    1 comment  
Oct 17, 2013

Breker Supplements Simulation

posted by Bryon Moyer

We’ve talked about Breker’s C-level test generation tools a couple of times in the past. But the context for that discussion was simulation – the tests were run in the virtual domain.

But not all validation happens there. There are several scenarios where hardware platforms contribute to the verification plan. Emulators are one good example, where programmable hardware elements implement newly-designed logic so that extensive testing that might be too slow for simulation – in particular, running software – can be performed.

Likewise, FPGA prototypes can be part of the plan. These are usually faster than an emulator implementation, but they take longer to create since they’re optimized for speed. They’re often used by software writers as a way to test software that will ultimately run on the silicon chip. But such software designers may well be interested in stressing the design with specific uses cases that their software may exercise. So some of the silicon verification can bleed over to them.

Finally, after all of the verification is done, you have an actual chip. (With all the focus on 100%-proof-that-it-works before cutting masks, it’s easy to forget that we’re actually making a real chip.) That chip must be validated to ensure that it works the way the verification plan said it would.

All of these scenarios are now supported by Breker’s TrekSoC-Si product, which complements the existing version. It means that tests generated for simulation can also be applied in all of these other phases of verification and validation.

You can find out more in their release.

Tags :    0 comments  
Get this feed  

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