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

"Too good to be true?"

[Ironchew]

"Too good to be true?"

Perhaps not, if you don't mind patent-encumbered chips with the occasional bug in them.

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.

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.

Re:"Too good to be true?"

[Darinbob]

Now the snag is trying to find any of these twenty something coders who know C.

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

[wiredlogic]

SystemC is a C++ library and simulation kernel. It isn't a dedicated language. The synthesizable subset of SystemC is very limited. Because it's plain C++, you have to implement all low level logic with much more code overhead than the equivalent VHDL or Verilog.

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

[LurkerXXX]

The point is, you shouldn't have to freaking google to find out what the heck an article is about. The brain-dead submitter, or brain-dead 'editor' should be clarifying anything that isn't very common everyday tech lingo/acronyms.

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.

Re:A better question

[EdIII]

Do we need to start having a basic competency test before letting idiots like this post? Jesus fuck, you newtards are idiots. No wonder CmdrTaco left...

That's hugely unfair. I figured out what it was based on the context. Hmmmm... SoC.. moving algorithms to chips... might it be System-On-Chip?

However, there are plenty of articles here about some pretty heavy physics, particle physics, medical advancements, etc. that are well outside of my own field. It would be nice to have some quality journalism where a term or concept is explained in the summary.

It's not that hard. Another sentence at most. I don't have a problem searching for terms and concepts I don't fully grasp, but it would be nice to have some quality journalism again. Seriously.... grammar and spelling mistakes everywhere now, even at mainstream outlets like CNN. Just once I would like the impression that somebody with an English major was doing actual editing.

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:Marvellous!

[Logger]

The press release says the user doesn't need to know anything about how their tool works. So obviously it will infer the appropriate solution and implement that too.

Actually the printf example is one of the easiest to implement. You'll receive a sheet of paper with "Hello World" printed on it in 6-8 weeks.

You provdided a link to define EDA

[Chris Mattern]

That's good. You didn't define or even expand SoC, GDSII, or TSMC. That's bad. I'm guessing SoC is "System on Chip" but I have no idea what the other two are.

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.

Depends on the source code and what the chip needs

[erice]

Most SOC's do a lot more than a direct translation of the c coded alogrithm would suggest. I guess if you had a "wrapper" platform that was good enough for many applications you could streemline the process. My guess that this platform and the links to C synthesis is most of Algotochip's secret sauce.

C synthesis itself can't handle most programs writen in C. Essentially you need to write Verilog in C in order to make it work. Any dynamic allocation of memory, whether directly or indirectly, is a problem. IO can not be expected to work.

So it boils down to: If you C source is uncharacteristicly just right and your application fits a pre-defined mold then you can make it a chip real quick. ..as long as you don't ecounter any problems during place and route or timing closure...

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:I hope not, but my money is on overhyped.

[DeadCatX2]

I'm curious, though... how would you convert unsigned to ASCII on chip?

I think OP's point is that your average C programmer would just start doing all kinds of dividing; most of the time there is very little hardware support for division, and so if you fed this into a C->HDL converter it would generate massive bloat as it imported some special library to handle division.

My first brute-force guess would involve a state machine (FSM), a comparator (16-bit), two adders (one 4-bit, one 16 bit), two muxes (16-bit and 4-bit, four input), a 16-bit register with clock enable and an associated input mux, and four 4-bit registers with clock enable. The FSM would control the 16-bit mux which selects a constant from four powers of 10 (10,000 to 10), and the output of the mux is connected to the 16-bit adder and the comparator. The other input is the 16-bit register, which also needs a mux for selecting between the argument and the adder's output. This register output is also a comparator input. The comparator is configured for "less than" and its output goes to the FSM so it can make decisions. The FSM also controls a 4-bit wide mux which connects four 4-bit registers that represent the various 10s digits (10,000 to 10) to an adder with the other input set to "1".

1) If the number is greater than 10,000 then inc the "ten-thousands" digit, subtract 10,000 from the argument, and repeat this step.
2) Once it is less than 10,000 then the state machine would walk forward to the thousands digit
3) If the number is greater than 1000, inc the thousands digit, subtract 1000 from the argument, and repeat this step.
4) Once it is less than 1000... (you can extrapolate some here) ...
n) Once the tens digit has been processed, the remaining argument is the ones digit

This would give you a series of 4-bit numbers. Once the FSM is done (it's important for it to finish first and change all bits simultaneously, so that downstream logic doesn't see glitches), it would append 0x3 to the front of each 4-bit number, turning them into ASCII.

Note that this approach requires very little in terms of hardware resources, at the expense of requiring a variable amount of time to process its inputs. Consider that 00000 would take 6 clock cycles to produce (need a cycle to load the input), while 29,999 would require like 33 clock cycles (no need to do subtractions on the ones digit)

There are other approaches that may be faster in exchange for requiring more hardware. Consider if you had 9 comparators, one for each digit (except 0), and an adder with a 9-input mux; every input would require 6 clock cycles. But this took an extra 8 comparators (and a significantly bigger mux too); size for speed (interestingly, the divider still only gets you 6 clock cycles, and probably takes up many more resources than 9 comparators. But if you could find other work for the divider then time-sharing might make it worth your while, maybe). You could even go all the way and use 32,000+ comparators, if fan-out wouldn't spell doom for such an approach, and then you could always calculate every possible value in 1 clock cycle...but this would require MASSIVE resources. Now if you only needed, say, from 0 to 1000, that might be slightly less unreasonable (perhaps within fanout limitations but probably still unreasonably large).

OPs point is that a good hardware engineer knows about these tradeoffs and handles them appropriately, while a C programmer isn't trained to think about these issues and their language doesn't even naturally express the structures that it will be mapped on to. Writing the kind of C code that you need to properly synthesize what you want feels like saying the alphabet backwards while jumping up and down on one foot while rubbing your belly and patting your head. And that's if you can even figure out how to tell the C synther that since your values only go from 0 to 1000 that it doesn't need all 16-bits of that unsigned short and it could really get away with only 10 bit support.

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

[hamster_nz]

Looks like you failed to spot the character constant in digit[i] = '0'; - it is already a character....

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

[hamster_nz]

We all know that it is stupid, but one the "next big thing" ideas for FPGA technology will be using them for ultra-low latency high frequency share trading.

The idea being that if you can bypass switches, routers, NICs, buffers, IRQs, CPU contet switches and so on you will be able to issue your trade requests before the whole data packet has finished coming off the wire, allowing you to get a big jump on your competitors.

One assumes that the "buy, buy, buy" or "sell, sell, sell" packets will need to be generated in the finial formats needed by the market, which will most probably need something to be converted from bInary to ASCII characters.

High frequency traders dream that it would be possible to turn a trade around within a few nano-seconds of the market data arriving.

Re:Linux on a chip!

[JustOK]

It would be the size of a kernel

Re:What if ..

[Anonymous Coward]

Then you could have a BSOD in hardware. Or in windows 8, Multiple Coloured Squares of Death.

acronymification [Re:A better question]

[Geoffrey.landis]

Not sure if serious.

according to the moderation, "5, funny."
 

SoC has been emerging as a more common term in the last 5 or 6 years meaning System on a Chip.

Don't be silly. That would be SoaC. Clearly, if you acronymize the "on", you have to acronymify the "a" as well. The acronominalization standards demand it. Why, if you abandon all rules for acromynificationizing, there would be chaos!