Startup Claims C-code To SoC In 8-16 Weeks

eldavojohn writes "Details are really thin, but the EE Times is reporting that Algotochip claims to be sitting on the 'Holy Grail' of SoC design. From the article: '"We can move your designs from algorithms to chips in as little as eight weeks," said Satish Padmanabhan CTO and founder of Algotochip, whose EDA tool directly implements digital chips from C-algorithms.' Padmanabhan is the designer of the first superscalar digital signal processor. His company, interestingly enough, claims to provide a service that consists of a 'suite of software tools that interprets a customers' C-code without their having any knowledge of Algotochip's proprietary technology and tools. The resultant GDSII design, from which an EDA system can produce the file that goes to TSMC, and all of its intellectual property is owned completely by the customer—with no licenses required from Algotochip.' This was presented at this year's Globalpress Electronics Summit. Too good to be true? Or can we expect our ANSI C code to be automagically implemented in a SoC in such a short time?"

Comments

Re:"Too good to be true?"

[AK Marc]

Well then, fix it with your own open source chip printer. 8-16 weeks? 5 minutes is long enough. Compile, spool, print.

SystemC

[paugq]

Why not? There is SystemC, a dialect of C++ which can be implemented in hardware (FPGA, for instance). What Algotochip is claiming is just one little more step forward.

Re:SystemC

[JoelDB]

While SystemC does have a synthesizable subset, it's mainly used for simulations at a high level from what I've seen. Going from synthesizable SystemC to hardware is an order of magnitude easier than going from a complex language such as C++ or C down to hardware, which is what this company is claiming. From reading the article I believe Tensilica is using a very similar approach with ASIPs) for bringing high-level lanaguages to hardware, and they are much more established in this field. One of the up-and-comers is AutoESL which was recently acquired by Xilinx. I've played around with this tool and its ability to bring C down to hardware is very impressive.

Re:SystemC

[jd]

Presumably, though, you could use a source-to-source compiler to convert C (with certain restrictions) into SystemC.* From there, you could do source-to-source compilation to convert SystemC into Verilog or whatever. You'd end up with crappy hardware, but the claim says nothing about design quality only design capability.

*The obvious restriction is that you can't translate something for which no translation exists, whether that's a function call or a particular class of solution.

Going directly from C to hardware without intermediate steps would indeed be a lot harder. But again that's not what the startup promises. They only promise that they can convert C to hardware, they say nothing about how many steps it takes on their end, only what it seems like from your end.

Having said that, a direct C to hardware compiler is obviously possible. A CPU plus software is just emulating a pure hardware system with the code directly built into the design. Instead of replacing bits of circuitry, you replace the instructions which say what circuitry is to be emulated. Since an OS is just another emulator, this time of a particular computer architecture, there is nothing to stop you from taking a dedicated embedded computer, compiling the software, OS and CPU architecture, and getting a single chip that performs the same task(s) entirely in hardware -- no "processor" per-se at all, a true System on a Chip. Albeit rather more complex than most SoC designs currently going, but hey. There's no fun in the easy.

Although there are uses for direct-to-hardware compilers, direct-to-FPGA for pure C would seem better. Take hard drives as an example. You can already install firmware, so there's programmable logic there. What if you could upload the Linux VFS plus applicable filesystems as well? You would reduce CPU load at the very least. If the drive also supported DMA rather than relying on the CPU to pull-and-forward, you could reduce bus activity as well. That would benefit a lot of people and be worth a lot of money for the manufacturer.

This, though, is not worth nearly as much. New hardware isn't designed that often and the number of people designing it is very limited. Faster conversion times won't impact customers, so won't be a selling point to them, so there's no profit involved. Further, optimizing is still a black art, optimizing C compiled into a hardware description language is simply not going to be as good as hand-coding -- for a long time. Eventually, it'll be comparable, just as C compilers are getting close to hand-turned assembly, but it took 30-odd years to get there. True, cheaper engineers can be used, but cheaper doesn't mean better. The issues in hardware are not simply issues of logic and corporations who try to cut corners via C-to-hardware will put their customers through worlds of hurt for at least the next decade to decade and a half.

This is nothing new at all

[Weaselmancer]

C code to SoC.

So, how is this offering from India any different? I could do it in less than 8 to 16 weeks if the customer supplies me the C code to be converted. As in, download/purchase any one of these utilities, run the customer's file through it, and mail it back to them.

Pretty simple.

A better question

[wonkey_monkey]

Or can we expect our ANSI C code to be automagically implemented in a SoC in such a short time?

How about you tell us what SoC stands for first? Once again, editors, we don't all know everything about everything in the tech world. Some of us come here to learn new things, and you guys don't make it easy. TFS should at least leave me with an impression of whether or not I need to read the TFA.

Re:A better question

[khellendros1984]

That would be "System on a Chip", a term which describes a complete system included on a single chip. An example I've seen used more often would be a phone's central chip; they tend to integrate the CPU, GPU, wireless chipsets, and part or all of the RAM on one chip. In this case, it looks like they're advertising the ability to quickly create a hardware chip that functions the same as an arbitrary chunk of C code; essentially, you can make a hardware chip that implements a specific algorithm.

Re:A better question

[Geoffrey.landis]

Yes, he shouldn't need to Google since he should know what a SoC is since this is supposed to be a site for technological literate people not reddit rejects.

Indeed.

"SoC" is short for "State of Charge," which is, basically, the status of a battery.

I'm not sure what this has to do with C-code. Maybe these chips they're talking about are used to make battery controllers that use SoC monitoring.

Re:A better question

[JustOK]

Salsa on Crotch

Re:A better question

[Anonymous Coward]

Yeah! And what does 'C' stand for?

Re:A better question

[Caratted]

Not sure if serious.

SoC has been emerging as a more common term in the last 5 or 6 years meaning System on a Chip. The advantages are it uses less power to do more things, and a lot of low level functions (radios, gpu rendering, etc) have more direct access to on-board cache and memory, as well as a direct line to RAM. They're used in just about everything and are essentially equivalent to saying CPU (for anything other than a desktop or laptop w/o IGP), these days.

Marvellous!

[Anonymous Coward]

I'm not entirely clear on how it works though. If I give them this:

#include <stdio.h>
int main() {
printf("Hello world!\n");
}

they will convert it into a custom integrated circuit chip with Hello World! silkscreened on the top of it or does the chip actually display "Hello World!" on whatever it is connected to?

Re:You provdided a link to define EDA

[blind biker]

GDSII or GDS-2 is a layout format, used by microsystems designers. It's a 2D-only format, but you can have unlimited layers.

TSMC (Taiwan Semiconductor Manufacturing Company) is the largest microsystems foundry in the world.

You are correct about SoC.

I hope not, but my money is on overhyped.

[hamster_nz]

Most of these technologies 'C' to hardware technologies are overhyped and under-deliver.

* It is definitely not ANSI C. It might share some syntax elements but that is about it
* C programmers do not make good hardware designers (C programmers will disagree, HDL programmers won't)
* The algorithms used in software by software developers do not translate well into hardware
* If you want "good" hardware developed, use hardware design tools.

If you don't agree with me on these points, post how you would convert "short unsigned value" into ASCII in char digits[5] and I'll show you how to do the same if you were designing a chip...

Re:I hope not, but my money is on overhyped.

[hamster_nz]

// Make value 17 bits long
  for(i = 0; i != 5 ; i++)
  {
      digit[i] = '0';
      if(value >= 80000) { value -= 80000; digit[i] |= 8; } // Extract the bits for the current digit - In 'C' I' need to use the |= operator as I never did get the hang of addressing bits in 'C'
      if(value >= 40000) { value -= 40000; digit[i] |= 4; }
      if(value >= 20000) { value -= 20000; digit[i] |= 2; }
      if(value >= 10000) { value -= 10000; digit[i] |= 1; }
      value = value*8 + value*2; // Prepare for extracting next digit. - the *4 and *2 would be implement by the wiring into the adder
  }

Advantages:
* No divide/mod operator
* Extracts digits from most significant to least significant (if you want to stream out the digits)
* Can be unrolled or pipelined to meet timing / throughput requirements

Sorry about any syntax/typos/errors in the code... it is a comment!

Re:Linux on a chip!

[JustOK]

It would be the size of a kernel

Re:"Too good to be true?"

[solidraven]

Any mistake in a SoC is expensive, especially if you go directly from design to wafer without extensive testing. Most of the time it's 1 week of actual writing a description in VHDL or Verilog and then spending a few weeks/months verifying the design and removing any bug. After you're done verifying you get to enjoy the trouble of mapping it. And since automation sucks for certain things, especially when the analogue signals are supposed to remain as noise free as possible, you then get to spend a few days doing the layout and verifying if the layout is actually the same as the netlist.
While this sounds nice, it's not the first "C to Silicon" program out there (Cadence beat them to it). And it certainly won't be the last. The thing is, the reason to use VHDL and to some extent Verilog is to minimize the occurrence of errors. Even when you verify your design bugs can still slip through. But due to the overall design of the language this is far less likely in VHDL.