a mARTIAN dIARY

Software Defined Silicon (SDS) for dummies

Filed under: EDA - Past Present and Future, RaNTs@eARTH, TECHbabble — cafm @ 3:39 pm July 10, 2007

I was recently helping one of my juniors search for a seminar topic and I came across the idea of SDS (Software Defined Silicon). The following is some questions that where thrown at me while I was explaining it. A bagful of thanks to David Manners for his excellent article. Since the net is my primary source of information for me regarding this technology there might be mistakes in my understanding, so if you find any please leave a comment so that I can rectify it :)

Ok so what is it?
Software defined silicon is a new electronic device that is both low cost and easy to program.
 
At an abstract level, How is this different from existing ASIC/FPGA?

This is actually two questions. Traditionally Full/Partial custom ASIC is less costly that FPGA per unit when the volumes increase) where as FPGA is more suited for prototyping since the time taken for design changes to be translated to hardware is much lesser. So while choosing between FPGA and Custom ASIC is a trade-off between cost and programmability

SDS will offer the better programmability than FPGA at a much lesser cost than FPGA with lesser lead times and also in a single language (C)

At a abstract level, How is this different from existing micro processors?
Microprocessors are general purpose chips. They are designed with the traditional single threaded flow in mind. SDS can be called a "events-driven processor engine". An events-driven processor is one that is capable, when an event occurs, of executing software immediately, and then terminating, and waiting for the next event. The events are things like a pin changing state.
So it you would be able to write really "real-time" software whose performance can compare that to hardware. For example you can write real time communication protocol that’s traditionally implemented in hardware in software. Also in the creators own words “So we’ve taken a very responsive, fast, deterministic, real-time processor engine, and we’ve integrated into that very tight pin control”, says Hurley, “and we’ve developed a core-to-core communications interface. So now we can build arrays of cores that can control pins.”

Isn’t RTL similar to C?
At syntax level both are high level languages. But while writing RTL we need to be mindful of what hardware our code is going to infer so at the conceptual level its very different from C.

In one word?

“You’re implementing functionality that’s traditionally implemented in hardware in software”

How is the cost low even with better features?
From the silicon cost point of view, XMOS is using processors, which are silicon efficient, and RAM, which is the most silicon efficient structure. By using processors and RAM, it gains big cost advantages.

What about an example of development freedom?
“The development freedom the customer has is incredible because the customer can choose how to partition that capability”, says Hurley, “what’s really powerful is that a customer has a budget of processor cycles, he can choose how to spend that budget on real-time tasks such as interfaces, DSP, and control, and, more importantly, he is then able to dynamically alter that so, when they’re doing multiple products (typically consumer companies have a general platform supporting 20 or 30 products) he can choose to say: ‘I don’t want a UART in this design, but I do want to run an MP3 decoder. So I will remove the UART piece of code, and I will re-purpose those processing cycles into my DSP capability. I don’t believe anything in the market today can offer that level of capability to a customer.”

What does this mean for hardware engineers?
If this was to become the chip that survives the current war between FPGA /ASIC/PSoC/SDS , the hardware engineers outside this technology would starve :P

What does this mean for the software engineers?
They get more power as they can write more powerful code that can at a lot of level emulate hardware perfectly, Something that was not possible till now

What’s the different with respect to the design flow?
Usually the hardware flow would involve work on EDA software that would design the hardware to be implemented. The coding at this stage is usually done in RTL like verilog/ VHDL. Then if the hardware so implemented included processors software would be written run on the processor.
Here in SDS the design at the hardware level is generic. the resource you have is processor cycles that you can allot via your programming (in C with some additions for defining port structure and using multi-threading and parallelism) to the task to which you want to allot it to. So RTL coding is removed out of the flow.

"It’s a standard embedded software development flow starting with C/C++ source, compile, link, assemble and de-bug using standard industry development tools."

Ok what all can it currently do?
"SDS can run Ethernet MAC and the MII interface in software at 200Mbps, it has DSP capability and control capability"

2 Return Tranmissions... »

  1. wow..! useful post

    Comment by angel-doc — July 14, 2007 @ 7:10 pm

  2. Maybe I am dumb but I cant understand the tone of that comment ;) :P

    Comment by cafm — July 16, 2007 @ 9:00 am

Subscribe to Comments Feed

Get updated via email for a new comment on this blog

TrackBack URL

Leave a comment



Disclaimer
The thoughts expressed in this blog are mine and should in no manner be linked to the organization(s) with which I am (or have been) associated.