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.

Re:"Too good to be true?"

[risom]

System On a Chip - the embedded equivalent of cpu, gpu, nortbridge, southbridge etc. combined in one package.

Re:"Too good to be true?"

[Half-pint HAL]

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.

See, this is what's confusing me. Isn't a system-on-a-chip just CPU+GPU+soundset+RAM+flash on one chip? Is there any real hardware to implement? The whole summary makes it sound like they've implemented... a C compiler.....

Re:"Too good to be true?"

[Anonymous Coward]

more realistically, they generate a tuned architecture. for example, GPUs weren't good for some applications because they lacked double support. Likewise CPU's were comparitively bad at encryption until special instructions were added.

If you look at a C algorithm, an extract some of the parallel strucutres, and then look at the operations, you could determine what hardware accelleration would be a waste, and what would be a benefit. If there is a lot of parallel bulk-processing, the resulting die will look more like a GPU. If the design does a lot of networking, a TCP engine might be implemented. you can tailor the cache-size, associativity, the branch-prediction, etc... all for a given algorithm.

They don't claim to beat out HDL optimized designs, just as HDL designs don't claim to beat out hand-crafted transistor level designs.

Re:"Too good to be true?"

[solidraven]

If it's just a program that decides what large blocks you should put in a SoC then it's just plain stupid really. The first step to proper design is hiring engineers who aren't retarded monkeys that are able to make such design decisions easily.

Re:"Too good to be true?"

[gtall]

SoCs these days include a fair amount of FPGAs. So it is more likely they are just producing FPGA code. Xilinix has FPGAs with ARM chips on them, or you can use soft PPC processors, not sure if they have soft ARM processors yet but they are likely not far in the future if they do not have them already.

Right now, you could produce FPGAs using soft processors to implement C code using Xilinix tools. However, like the gp says, that ain't all there is to it.

Re:"Too good to be true?"

[Half-pint HAL]

Aha, so the they're taking one monolithic source program, identifying what can be done in software, what standard components are required in order for the code to function properly, and what non-standard stuff has to be custom designed... and then designing it. ++nontrivial. Very cool tech.

Re:"Too good to be true?"

[luis_a_espinal]

Buggered if I know, the poster didn't explain the acronyms. WTF is SoC?

http://lmgtfy.com/?q=SoC

Slashdot, where searching for an acronym's meaning is the next technical challenge.

Re:"Too good to be true?"

[rufty_tufty]

"Isn't a system-on-a-chip just CPU+GPU+soundset+RAM+flash on one chip? Is there any real hardware to implement"
Which CPU, Which GPU? How much pipelining is needed? Where is the best place in the FPU or in the individual multiplier to add a register stage to improve timing? Should you upsize the gate to improve timing, or duplicate the flop and logic to reduce loading? Is your problem caused by too large a gate and you need to shrink it?
What bus architecture will you use? How do you patch between bus standards? How will you close top level timing? How do you implement your test infrastructure (JTAG LBIST etc)? What about power distribution, power islands? What about floorplanning, where is the best arrangement for each block? What about analogue IP, how are your clocks distributed? At this process node what are the power characteristics of different ram architectures and are you better doubling the width of your memory and accessing it half as often?
How much cache is needed for the available system bandwidth, under congestion how do you flow control the intercommunicating block, how do you handle discard under congestion? How do you avoid and debug interlock and data loss?

But apart from that, no there is no hardware to design if you are just gluing IP blocks together.

Re:"Too good to be true?"

[unixisc]

Isn't Verilog itself an HDL that's identical in syntax to C? C is not an HDL, so if someone writes a C program and it ultimately ends up as a netlist, how exactly is it different from Verilog? Just that it's not using Verilog's own simulation engines in order to build and run?

I agree w/ the above - C would have to have some sort of error checking, as well as simulations of both static and behavioral models in order to be an HDL, and then the question would invariably arise - in what way would it be superior to verilog?

Re:"Too good to be true?"

[unixisc]

An SoC to me sounds like a CPU + memory + I/O + whatever glue logic is needed for each of them to talk to each other. The glue logic's part of it would be converting the CPU outputs into inputs for the memory, I/O etc and the memory or I/O outputs into CPU inputs. That's the sort of thing that's achieved using combinational and sequential logic, or in other words, FPGAs. With FPGAs being as sophisticated as they are these days and even including CPU cores within them, it would seem that an FPGA could be converted into a custom SoC using normal HDL code, or in case of the Algotchip, C code.

Re:"Too good to be true?"

[unixisc]

Are you designing the individual internals of the SoC components here, such as the CPU? How much pipelining is needed - that's something determined during CPU design, is it not? Same thing on where in the FPU to add a register stage to improve timing. But even if you are just gluing the IP blocks together, the design of the glue logic is itself considerable, given that it has to work within the limitations of the CPU, the memory and all other sub blocks.

Re:"Too good to be true?"

[unixisc]

Well, since Bloomberg has discovered that a software career is a deadend, maybe all those C programmers can try and make SoCs out of their programs, and try and get fabs to build those. Next thing - spin their own raspberry piss.

Re:"Too good to be true?"

[rufty_tufty]

"How much pipelining is needed - that's something determined during CPU design, is it not?"
That depends on your design team and the Ip block providers - but chances are you have to analise it and give feedback to the Ip vendor. You may choose not to, but if you do you stand a good chance of beating your competitor.

"same thing on where in the FPU to add a register stage to improve timing."
again not really because that will depend on things like your clock tree layout and power grid. You may choose to not optimise these things yourself, but a good designer would (given the time and resource) adapt them to their specific system

"But even if you are just gluing the IP blocks together, the design of the glue logic is itself considerable, given that it has to work within the limitations of the CPU, the memory and all other sub blocks."
Agreed, I never ment to imply otherwise, I was just trying to say that assembling an SOC requires a heck of a lot of hardware implementation and it is certainly not just sticking blocks together even if you are just sticking blocks together.

Re:"Too good to be true?"

[Rotag_FU]

While the website of the company does claim that they can also use this technology for FPGA-based designs, their big claim is that they are going from unmodified ANSI C to GDS-II in 8-16 weeks. GDS-II is a file format that specifies the physical implementation of the design and is used in microelectronic foundry flows. GDS-II files are not used in FPGA design flows, although they do have a much more highly abstracted analogue. However it is possible that they are using a reconfigurable fabric that they have developed or bought rights to use and are simply hard wiring it in their foundry flow (effectively making it a mask programmable gate array instead of an FPGA), but that would seem to be unlikely if their power claims are to be believed.

The biggest gap that I think they have is the lack of a decently defined verification flow. Their claim is that they use customer provided test vectors to validate the design. This seems too simplistic to me since exhaustive test vectors are infeasible for anything of modest complexity. Their flow could greatly benefit from some sort of formal verification basis proving that the SoC truly represents the same function as the C algorithm in order to be something that I'd be willing to gamble money on fabbing. At the very least, utilization of an extensive constrained random verification suite that is referenced back to the C model would be desirable for all but the simplest designs. That being said, either option would likely kick them out of the 8-16 week timeframe.

Re:"Too good to be true?"

[solidraven]

Verilog is still quite different from C in many aspects at first glance. I'm not really familiar with Verilog to be honest, so might be mistaken.

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

[paugq]

You don't just #include and magically get shit that can go onto silicon

I never said so. The fact that is a dialect of C++, not pure C++, speaks volumes already.

Re:SystemC

[davolfman]

Last I heard from people who use it on a daily basis, SystemC's synthesis tools weren't really mature enough to use seriously. It IS great for building a model to test your simulations from a purpose-built HDL against though.

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.

Re:SystemC

[geoskd]

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 problem with compiling any high level language to hardware is that there are simple high level constructs that are prohibitively difficult to render in hardware. A good example is any procedural function like a loop with dependencies that prevent parallelization. Such loops can only be processed sequentially while the rest of the "program" can be rendered simultaneously. This leads to all kinds of synchronization problems. Hardware description Languages combat this problem by making non-synchronous constructs explicitly non-synthesizeable, or outright prohibited. As a good exercise for the reader, ask yourself how you would implement a divider coupled to an adder in hardware. The adder is a simple construct that can be fully paralleled into a SOP (Sum of Products). The divider would require an almost impossible number of gates to create as an SOP for any realistic number of bits, so the divider needs to be implemented as a sequence of repeating steps, Now how would you make the adder interact with the divider? The answer is not trivial, and all we tried to do is implement X = A + B/C. At its root, compiling any language to hardware is a massive exercise in dependency mapping. Some languages are designed for this (Verilog, VHDL), others are not (any non HDL language).

-=Geoskd

Re:SystemC

[rufty_tufty]

Just because you can use the language to write synthesizable code does not mean all code is synthesizable.
An easy example is a re-entrant function that in software would be repeatedly called to solve the input. Assuming for different inputs you call it a different number of times a translation into pure hardware would require an arbitrary sized piece of hardware. Now you could set a limit on the range of values the hardware can solve for, but it's a tricky problem.
Likewise software would call new() and get a new function and associated dataypes including procedures and memory. Translating this into hardware would require you to get new memories and logic each time you reached a certain state. Not an option in a pure ASIC.
Now I've been trying to work out for a few years how to do this in an FPGA. You could pre-layout a multiplier (for example) and effectively calculate your FPGA's routing on the fly and then re-program sub slices of your fpga as you go. But it's a very difficult problem, and I'm not ready to quit my job and form the startup on that idea just yet...

Re:SystemC

[jd]

Loops to prevent parallelization can be substituted for with triggers, provided they can be detected. Triggers are easy to do in hardware.

Dividers can be implemented in four steps - a log-table lookup, an inverter, an adder and an inverse log-table lookup. No repeating steps. If you're programming a general-purpose maths core, you'll need a log table anyway. Since that's the only significant consumer of real-estate and it's already allocated for, you lose nothing by using it.

Having the adder interact with the divider is also not very complicated

Option 1: You have an instruction stack that stores one operation and three operands. The first two operands specify the source buffers* and the third operand specifies the target buffer. All three would probably be done as ring buffers and those are easy to do in hardware. The instruction stack would be triggered if and only if all* source buffers are non-empty. The instruction stack does not care if a previous instruction is complete or not, giving you the capacity for parallel execution where appropriate.

*Where you've one input, the other operand would be null. To simplify logic, you'd specify that a null buffer always has content.

Option 2: Each operation has its own independent logic, with the results going into buffers at the end. This time, it is the operations that have the lock and which wait until all the input buffers have content. So the adder will be called but will block because the second input buffer is currently empty. Once the division is complete, the results are copied into the second input buffer. This triggers the add.

There will be others, but these are the two most basic forms. Incredibly simple, incredibly easy to implement. Triggers, latches and buffers take care of almost all the significant hardware-related issues. They are your friends. Well, except when they are your enemies.

Re:SystemC

[geoskd]

Now implement a compiler that does all that, but for any arbitrary equation...

Let me know how that turns out.

-=Geoskd

Re:SystemC

[jd]

Still not hard*. Any sequence of multiplications and divisions can be kept in logarithmic notation. Any parentheses can be handled by an intermediate value buffer. Any barrier operation can be handled by having a 1-bit flag per result you're waiting on, where the barrier is cleared when the total value reaches 0 (assuming all flags start at 1 to mark that that operation is blocking). You can build that as a trigger by ORing the bits together and having the NOT of that as your input to a transistor's collector, where the transistor feeds into your trigger.

Early computers (including some for doing computational fluid dynamics) were all hard-wired. They weren't etched into silicon, they were a rat's nest of wires, thermionic vaccuum tubes, mercury delay lines, relays and other such components. It can be done, for digital, analogue and mixed signal. Although mixed signal is a lot harder with the two top people in the field dying in car crashes.

*Not being hard doesn't make it easy. This is a full spectrum, not a binary state. Furthermore, a compiler that can do the layout is very different from a compiler that can do a good layout. Software optimization is frequently demented and software is far easier to optimize. It is also very different from a compiler that can do a layout within specific constraints. Regular optimization is best-effort and a solution (even if not a good one) exists for any given method, but constraint-driven optimization need have no solution (the constraints may make it impossible to solve the problem given the optimization strategies known to the compiler) and you cannot know if that is definitely the case within finite time. You can use herustics and say that you can't guess at a solution within a time limit, but that's not the same as there being no solution.

The problem with designing ASICs or other chips is that you're almost always working with a constraint-driven problem. Fab plants work with dies of fixed size on a wafer of fixed size, in a 2D space. Heat has to be dissipated as evenly as possible, to avoid hot-spots. Pin count is a major determinant of cost and there will be cost constraints. Die size also impacts costs - and rejection rates. Writing a compiler to generate a hardware description that technically works is trivial in comparison to the problem of writing a compiler that can generate a hardware description that you can build deployable hardware from - particularly at a lower cost than needed to just get a good chip designer to hand-craft the damn thing.

That's the real hold-up. The compiler itself isn't the hard part, it's the writing of a compiler that can produce something worth producing at a cost that makes it worth producing that way.

Sounds plausible.

[Anonymous Coward]

After all, C to HDL has been around for awhile.

Re:Sounds plausible.

[TheRaven64]

There are lots of tools that do this, for varying levels of success. The problem is, translating C to hardware is not an especially difficult challenge. Translating algorithms that make sense running on a general purpose CPU to algorithms that make sense implemented in hardware is a very hard problem. C is intrinsically serial, hardware is intrinsically parallel (in two dimensions).

The hard problem, and one that's the focus of a lot of research, is analysing C (or whatever) code and determining how to modify the hardware so that the software can run quickly.

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.

Re:This is nothing new at all

[Anonymous Coward]

Um...from the Algotochip home page. Emphasis mine.

Algotochip is a Silicon Valley startup revolutionizing digital chip design. Algotochip dramatically...

Don't know about the revolutionizing part though...

Re:This is nothing new at all

[geoskd]

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.

Dear Sir, please implement the following program in hardware:

main(int argc, char* argv)
{
int niter=0;
double x,y;
int i,count=0; /* # of points in the 1st quadrant of unit circle */
double z;
double pi;

printf("Enter the number of iterations used to estimate pi: ");
scanf("%d",&niter);

/* initialize random numbers */
srand(SEED);
count=0;
for ( i=0; i x = (double)rand()/RAND_MAX;
y = (double)rand()/RAND_MAX;
z = x*x+y*y;
if (z; }
pi=(double)count/niter*4;
printf("# of trials= %d , estimate of pi is %g \n",niter,pi);
}


Let me know how that turns out.

-=Geoskd

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

[Anonymous Coward]

system on a chip

Re:A better question

[Anonymous Coward]

http://en.wikipedia.org/wiki/System_on_a_chip

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

[thammoud]

Ah how I miss having some points. Real funny shit.

Re:A better question

[Belial6]

Perhaps you could explain what TFS and TFA mean every time you use them so that the editors understand what your asking for....

Re:A better question

[JoeMerchant]

https://www.google.com/search?q=soc

I believe you are looking for result #2.

Re:A better question

[JoeMerchant]

http://www.tumblr.com/tagged/i'm-gonna-put-salsa-on-my-crotch

Re:A better question

[Bucky24]

Yeah! And what does 'C' stand for?

Just in case you're not trolling:
C is a high-level programming language (yes I know I could give a better description but my brain is fried this late in the day).
http://en.wikipedia.org/wiki/C_(programming_language)

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.

Re:A better question

[savuporo]

Friggin SoC has been in everyday tech lingo forever. If the crowd here doesn't get it, it just shows how far from the actual geek audience has slashdot gone.

Re:A better question

[schlachter]

People who work in the 'chip' business are familiar with SoC, or Salsa on Crotch.

Re:A better question

[Anonymous Coward]

With 14 different meanings in science and technology alone, according to Wikipedia. The point is that one person writes the summary and a huge number of people read it. Not all of them know everything. Just type few extra characters ("System on a Chip" instead of "SoC" the first time you use it) and by spending a few seconds you save others what probably adds up to quite a significant amount of time spent on figuring out what it means. That doesn't directly benefit the writer of the summary, of course, but there needs to be just one other person taking the trouble to type those few extra characters for a term the writer of this summary is not familiar with to more than compensate for the extra time spent.

It's efficient to be clear in what you write and not assume that everyone knows every acronym. What baffles me is how many geeks don't understand such a simple concept.

Re:A better question

[TheInternetGuy]

Well I'll take this one, it is easy! C stands for Chip. Or was it Crinkle Cut? I forget.

Re:A better question

[Half-pint HAL]

The point is that one person writes the summary and a huge number of people read it. Not all of them know everything.

Exactly. Or to put it in a way any geek should understand...

Your "source code" (= the summary) refers to an external source (= the definition of the abbreviation SoC). You could use the preprocessor to fetch that and insert it into the code as a string literal before running compilation (slashdot submission). As you didn't, this meant that the object code generated (= the slashdot summary) invoked a remote file access operation where the host operating system (= the slashdot reader's brain) didn't currently have the string literal "system on a chip" in local RAM.

Substituting the literal at compile time would have removed the need for thousands of file reads at the cost of 13 * sizeof (char) bytes.

Re:A better question

[Half-pint HAL]

What does "/." stand for?

It's a redundant alias for the system root directory. Assuming you're using a proper computer and not one of these modern toys.

\me ducks

Re:A better question

[geoskd]

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.

The only problem with that is that English majors are no longer qualified to understand the world around them. Once upon a time, a Liberal Arts degree came with enough STEM to be useful in many contexts, these days its just a very expensive credential that has no substance behind it, and the holders of these degrees are not qualified to speak to any subject outside their own very narrow view. These are not the people you want editing technical documents, because they would spell check the value right out of them. If you don't understand the acronyms, use Google until you do, or just give it up. Don't get mad at others because you have ill prepared yourself to understand the world around you, and for gods sake stop expecting anyone to feed you sanitized news because you might just be unlucky enough to get your wish.

-=Geoskd

Re:A better question

[luis_a_espinal]

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.

You might have a point if that were the sole entry in your google results page (alongside salsa on crotch or standard occupation classification).

But, by golly, that is not the case. Guess f* what? Systems on a Chip is right at the f* top of a google page result, with two sentences describing what it means. By golly, wouldn't that be enough to guide the supposedly nerd mind towards?

Oh, let me guess, if you don't find it on your first hit, right on the top with flashing colors and dancing monkeys on animated gifs, you give up? No concept of research, even of the most superficial kind? I think we need to write "Google for Dummies" then.

Re:A better question

[Jeng]

If you can't understand TFS then read the TFA, if you still don't understand it then it should at least leave you with enough information to look up the portions you do not know.

You learn more looking it up and finding out what you do not know rather than having someone spoon feed you the information.

So basically if the submitter or editor had included the information then you would actually end up learning less.

Re:A better question

[Geoffrey.landis]

Ah, what does google know? Real nerds use DuckDuckGo.

SOC = Special Operations Consulting - Security Management.

Quack!

Re:A better question

[EdIII]

Don't get mad at others because you have ill prepared yourself to understand the world around you, and for gods sake stop expecting anyone to feed you sanitized news because you might just be unlucky enough to get your wish

Wow. You're completely and utterly missing the point.

It would take another sentence at most to tie an explanation of SoC. This is not about anger, or being ill prepared. That is just ridiculous anyways. How do you prepare yourself for exposure to jargon from dozens of different fields? You can't. According to you, I am ill prepared to understand the world around me because I don't immediately recognize an acronym used in a very specific field? Really? Sorry, that is absurd.

The point is about quality journalism and writing. Try picking up a good magazine once in awhile and reading an article written by a *real* journalist. You'll see the difference right away.

It can be done. That's what I always liked about Stephen Hawking's books. They were written for people not in that field. Same thing here, the summary could have been written for people not in the field.

I got system-on-chip right away, so your ridiculous statement about me being angry or ill prepared is amusing. I'm just supporting the poster's lamentation about the degrading state of journalism everywhere.

Re:A better question

[geoskd]

It would take another sentence at most to tie an explanation of SoC. This is not about anger, or being ill prepared. That is just ridiculous anyways. How do you prepare yourself for exposure to jargon from dozens of different fields?

One word: Google

There are two kinds of people on the planet right now. Those that know how to find the answer to any question humanity knows the answer to... and those that don't. I don't understand 3/4 of any technical jargon that I see in slashdot articles. When I find the topic interesting enough, I Google the things I am unfamiliar with. This approach serves as a good launching pad for learning about any unfamiliar topic. Anyone who whines that other people aren't doing their basic research for them deserve to remain ignorant of the world around them.

That's what I always liked about Stephen Hawking's books.

My mother reads hawking. She is ill equipped to understand Relativity or Quantum Mechanics, but believes that because whe has read hawking, she understands something about these fields. It is patently absurd, because if you don't understand the jargon, you don't understand the field. The jargon didn't just spring up to make people sound elitist, it is there to denote very specific things that normal language cant relay. Hawking explains some of the jargon, but without the math it is irrelevant. More importantly, Hawking is in the business of selling books to lay people. These articles (And slashdot's subsequent conversations are not intended for that same audience).

-=Geoskd

Re:A better question

[EdIII]

You still don't get it.

It's about quality journalism, NOT research or ignorance despite your baseless antagonism and character attacks.

When you are writing a summary for people inside, and outside, of your field it is not impossible to explain the key concepts and acronyms in a quick manner. There is a crucial difference between a white paper prepared for your field (like say a RFC for Ethernet) and an explanation of Ethernet in a technical article for Slashdot, Reddit, etc.

To explain them is not "sanitizing" the news, enabling their ignorance, or any other absurd pot shot you wish to throw at somebody because they did not understand an acronym right away.

Sheesh. I think I have a Cluepon around here somewhere....

Re:Choose two:

[Anonymous Coward]

I'd be tempted to compile up a linux system with GNOME desktop into this... just to see the resulting chip!

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.

Re: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?

It won't do anything. The above piece of code will not translate to synthesizable logic. The printf() statement is not synthesizable. For the tool to output something meaningful, the input has to be meaningful (to the tool).

Re:Marvellous!

[gtall]

You can get chips with little neon signs on the top. So "Hello World" becomes a marquee marching across the top of the chip. In more sophisticated chips, it also synthesizes the words into speech.

Re:Marvellous!

[Half-pint HAL]

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?

It won't do anything. The above piece of code will not translate to synthesizable logic. The printf() statement is not synthesizable. For the tool to output something meaningful, the input has to be meaningful (to the tool).

But we're not just talking about FPGA imaging here -- we're talking system-on-a-chip with processor, RAM, Flash etc. So their system will generate a SoC from stock components with a processor, minimal Flash RAM and a very basic GPU. They won't need to generate any custom logic, but they'll still be generating a SoC to spec, one that will connect to some video display and show a single message.

Re:Marvellous!

[rufty_tufty]

"The printf() statement is not synthesizable."
Actually in a previous company we were experimenting with tools like this.
We got it to wrap printf statements up as a trigger to a machine to read the string from memory and pipe it to a 8 bit stream. This 8 bit stream them went to a serial port and voila your RTl would print to the serial port.
It even coped with concurrency, but if you hit error states one error code could swamp out the real error so it was far from perfect.

Very cool though.

Re:Marvellous!

[Asic Eng]

It will do the usual what every single one of these tools do: it will tell you that the printf statement is not supported.

I don't remember how many of these bullshit claims I've heard in my career as an ASIC designer. Basically C is not a language suitable to describe chips, so none of these tools will work outside the niche they are intended for (DSP mostly, and yes they are good for that).

C is closely mapped to the workings of a CPU, and it does a fine job for that. However if you write an algorithm which - e.g. allocates memory (pretty trivial for C isn't it?) you need to have that memory physically available on the chip. It's not a good idea to write an algorithm which allocates a lot of that, because your chip will become expensive. So you need to carefully think about the max amount.

Also hardware is inherently parallel - every little piece can run independently. Using C you have just about no tools to make use of that. It is after all a language which is supposed to run optimally on a CPU, and that executes instructions sequencially. The compiler may take advantage of the fact that your algorithm runs better with three multiplier units rather than one, and will probably give you that. However ultimately: either you know what you have in mind when you write the algorithm, or at best you'll get a choice between crap performance or high cost.

Now let's say you want a multi-core SOC sharing the same Flash memory and resetting itself if the operating voltage falls below a certain threshold. How do you describe that in C? It's possible, but it's not possible in the way you write software, and once it comes to writing C in that manner, you'll find it's not particularly suitable for the task. (Surprise, that's not what it's intended for - it's supposed to be executed by systems like that, not to build the systems.)

This is usually the point where the "synthesize your C algorithm to an SOC" folkd start to add custom extensions. And this is also the point where you find that there are already specialized languages available for SOCs which understand what a signal is, which support gate-level simulation and clock-domain crossings which have tools available for doing logic equivalence checking, which are portable between tool vendors and are IEEE standardized. Why not use one which already works instead of going back to what we had decades ago? Because "synthesize your C algorithm" makes a great marketing slide.

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.

Re:You provdided a link to define EDA

[mk1004]

Well, TSMC is a foundry. Wikipedia says GDSII is the industry-standard way of exchanging data for PCB and IC layout.--I should have known that since I've worked in the IC industry. No reason for most software and IT people to know those terms. Technical writers generally know that you define the acronym the first time they use it and then use the acronym afterwards. /. articles don't follow that rule. I guess so the people who know those terms can flame those who don't.

I'm guessing you could end up writing a lot of code to define how you want input and output to flow from the SoC.

Re:You provdided a link to define EDA

[Freebirth Toad]

That's good. You didn't define or even expand SoC, GDSII, or TSMC. That's bad.

The SoC contains potassium benzoate.

Re:You provdided a link to define EDA

[Your.Master]

Yeah, on Myspace people define TMSC, UMC, GDSII, SoC, and EDA. All the time.

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...

so it compiles, drops down a CPU core and a ROM

[YesIAmAScript]

The devil is in the details. It isn't a question as to whether a hardware device can be manufactured that runs your code, it is provably possible.

The issue is how cost-efficient is the SoC. How power efficient. How does it perform, does it do any more parallelism than a CPU would do if you just fed it the compiled code.

Re:so it compiles, drops down a CPU core and a ROM

[tomhath]

Exactly. Is there really any benefit to burning the program into nanocode ROM over normal compiling into a RISC instruction set? In theory, maybe. Burroughs used to do this a few decades ago and gave up on the idea.

Re:so it compiles, drops down a CPU core and a ROM

[thoughtspace]

Same thing happened to CPLDs. Once FPGAs were cheap - we all jumped to FPGAs.
Why lock yourself down - or even finish design before turning a PCB.

Algorithms vs. hardware

[unts]

Algorithms only work well if they fit well with the hardware they're targeting. You have to make certain assumptions, but depending on what your algorithm is, you should know which things you really need to think about (memory, branching, process communication, disk, ...)

Algorithms that get synthesised into hardware will only work well if they're written in such a way that lends itself to synthesis. There's going to be a huge heap of stuff that doesn't fit well, or doesn't work at all. Writing things like Verilog and even System C is very different to writing a piece of software. And let's not even mention the backend stuff like layout - stuff that can have a big impact on performance of the thing you're spending a lot of money fabricating (oh, I guess I /did/ mention it...)

So, maybe a bit ambitious, but if they've solved even some of the problems and helped bring software development and hardware design closer together, well, that's a good thing.

Finally...

[RevSpaminator]

I can have hardware devoted to celebrating my mastery of the C language... #include main() { printf ("Hello World!\n"); }

Re:Finally...

[unixisc]

Wonder what an SoC will look like. Except, that how would look like in HDL? What exactly would the headers be?

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.

[Anonymous Coward]

Even though interpreted languages are less efficient than C, they are good enough for so many tasks that they have taken off.

We are probably at or near the point where inefficient C translated to SoC is good enough for a large number of tasks.

There will always be room for C devs in the programming world and HDL programmers in the hardware world, but with the power of newer hardware not all tasks will require them.

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

[DeadCatX2]

I doubt we've reached the point where there are so many excess gates lying around that you can use shitty C-to-HDL converters. There is a large excess of CPU cycles but not nearly as much of an excess of gates. You really have to be conscious of how your design will be synthesized because it's very easy for a C-to-HDL converter to really screw up implementation and do terrible things that will bloat the netlist. I've used such a converter before for a small piece of an FPGA program, and I ended up re-writing half of it in HDL anyway because the result wouldn't fit in the FPGA I was using.

Besides, OP is right, C programmers are terrible hardware designers. C is a sequential language that jumps through hoops to be parallel. HDLs are parallel languages that jump through hoops to be sequential. If you want to be a C programmer in a world where HDL is king, your best bet is to implement a soft-core processor like MicroBlaze or Nios, and then have the C code run on that.

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.

[O('_')O_Bush]

Looks like it lacks the byte->char conversion (he did say ascii, and what's the point if the result is garbage ops?).

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]

Google just found me cunning way to implement binary to BCD conversion that works by using modified shift registers.

Very slick, Wouldn't be found by a 'C' to hardware process or 'C' programmer.

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

[DrFalkyn]

But if you need to fairly complex things like convert strings, aren't you just better off sticking a CPU on whatever you're designing?

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

[DeadCatX2]

Well yeah, if you have a CPU lying around on your PCB, and if it has division hardware, then it's easier to use the CPU for a task like that. But another part of designing hardware is knowing how to partition the design space such that you can make the most effective use of computing resources that are available.

The other side of the coin is that the algorithm I outlined above could reasonably compute a 5-digit binary-to-BCD conversion in six clock cycles. Your average embedded CPU would still be handling the first division by the time I have results (assuming it even has division hardware). Digital logic also scales much better than processor clock speeds, so if you needed to do a 20 or more digit conversion, the digital logic solution will be MUCH faster.

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

[Anonymous Coward]

>High frequency traders...

High fequency traders are scumbags.

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

[unixisc]

BCD? Just convert the world into an Octal system, which is the closest to decimal. Or even hexadecimal will work, but use something else other than A-F.

Re:Depends on the source code and what the chip ne

[TheRealMindChild]

Or you follow their SDK and let them do the work. Are you an engineer appropriate to make such statements?

Re:Satish?

[Anonymous Coward]

Downmodded. How disingenuous of a site with so many programmers who know firsthand of the shit that comes out of India. They have a completely different culture than the US, and that is the cause of what we perceive as poor workmanship and poor management. Reputation doesn't seem to matter a lot to them. If that's not true, then please explain the apparent lack of quality. They memorize dumps to pass certification exams and then deliver poor product under poor management and get paid poor wages for it. And when pressed, they really genuinely don't seem to give a shit. Why?

I'm sure the typical Japanese worker considers US workers lazy with an inflated sense of entitlement. And as a US citizen with a job, I'd agree with that assessment compared to the typical Japanese work ethic.

Re:Linux on a chip!

[JustOK]

It would be the size of a kernel

Design automation tradeoffs

[WaffleMonster]

Ease of design, power consumption and performance. Pick any two.

It would be interesting to see how this compares with the work of competent designers with a/d and analog skillz.

Translating C to hardware shouldn't be that hard

[Hentes]

The real question is how efficient it is.

What if ..

[Taco Cowboy]

What if Microsoft decides to compile their new Windows 8 into a SoC ?

Re:What if ..

[Anonymous Coward]

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

Re:What if ..

[rufty_tufty]

I'd love to see them malloc a new piece of hardware.

Re:What if ..

[unixisc]

Then you'll have fabs like TSMC, GSMC, UMC, Global Foundries, Vanguard all start making Windows 8 SoCs

I have a great idea

[caywen]

Why not just put the code onto high speed flash that goes on the SoC? Seems a whole lot easier, and I'm not clear why their solution is better. Really, I must be missing something, I'm curious.

Re:I have a great idea

[hamster_nz]

I don't know the details of this product, but in most cases 'C' to hardware tools are used to optimize the inner-most portion of critical loops,

One way is to build either a custom CPU instruction - for example a programmable "bitshuffle" for use in crypto.

Another is to build a custom on-chip peripheral where "my_code(arg1, arg2)" maps to "start arg1 in port X, store arg2 in port Y, read answer from port Z" and the custom logic transforms X and Y into Z. The ports might even have FIFOs allowing many operations to be queued or in flight at the same time.

One other common configuration to have the custom logic interface with the DMA subsystem and few control registers (e.g. for an RAID XOR engine).

Usually all these systems have a generic CPU to do the generic stuff - the idea is that the whole design implemented in the same (or almost the same) toolset.

Re:I have a great idea

[Asic Eng]

Well, let's say you want to make a calculation like this:

y =( a+b ) - c*8 + e/2 (operand size is 74 bits, for division we ignore the remainder, values are such that there is no overflow)

Building specialized hardware you can do that in a single clock cycle at basically negligible costs. Serializing this into a CPU, execution takes a lot longer and implementation (i.e. the CPU cost) is relatively expensive. Just reading from flash typically takes several clock cycles on an SOC. (High speed flash is still slow in comparison to ordinary logic.)

Let's say you have a few hundred expressions like in the example - if you don't mind adding more adders and subtractors you can run all of these in parallel if you use custom hardware.

Re:Choose two:

[TheDarkMaster]

The moment you plug it in ant flip the switch, you will blow up the power grid of the neighborhood

Re:Choose two:

[Anonymous Coward]

It is no longer true. Now, you have to pick one.

Re:Choose two:

[lister king of smeg]

step one: compile gnu code licensed under gpl3
step two: watch the lawsuits ensue while gnu demands the blueprint.

or

order a chip of qemu and get your own reverse engineered set of possessors see how many companies sue their asses off.

Alright!

[shadowrat]

We can finally get a hardware implementation of quake!

Re:8-16 weeks for the SOC 8-16 years for the lawsu

[mevets]

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

maybe turn in your "nerd" card?

[ashpool7]

"We can move your designs from algorithms to chips in as little as eight weeks"

That's enough hints to know what's going on here. If you can't be bothered to Google "SoC" and see the "chip" reference on the first page, or heck, even read TFA which has the definition in it how could you muster the typing to complain about it?

Sorry if Slashdot isn't "newbie friendly," but this isn't "news for new guys, stuff to help you understand." If you don't understand it, maybe it doesn't matter to you. If it bothers you, educate yourself... by reading the article.

Hitchcock had it right!

[Tumbleweed]

Those birds are going to be so much more angry now! We're doomed, I tell you -- DOOMED!

Dude, don't leave us hanging...

[ratboy666]

I dunno... I am just a programming hack.

But... given the underpowered nature of microcontrollers (and logic), I would either use a table of powers of ten, subtracting and counting, or a bcd table of powers of two, along with bcd add and adjust.

I would probably go for the bcd approach; guarantees that the job is done in 16 "cycles".

Is that what you were thinking?

Re:Dude, don't leave us hanging...

[Anonymous Coward]

I posted the code up in another comment.... but you extract bits once at a time, starting with the "40,000" bit, then the "20,000" bit, then "10,000" and so io

Here's something that aproaches the idea...
    long int temp = value;
    digit[4] = '0';
    if(temp >= 80000) { temp -= 80000; set bit 3 in digit [4];}
    if(temp >= 40000) { temp -= 40000; set bit 2 in digit [4];}
    if(temp >= 20000) { temp -= 20000; set bit 1 in digit [4];}
    if(temp >= 10000) { temp -= 10000; set bit 0 in digit [4];}

You then have the option to either step down to 8000, 4000.... digit[3], or to multiply 'temp' by 10 and reuse the same logic to extract digit[3].

Re:Dude, don't leave us hanging...

[ratboy666]

Got it, a combination of the two - subtract off highest powers of ten, but in bcd binary digits to fill in the lower bits of each display digit.

Good solution.

Re:Linux on a chip!

[cold fjord]

Popcorn?

How good is it actually?

[gweihir]

There are questions regarding performance, area-needs, etc. If all they do is compile the C-code, put it in ROM, supply RAM and a CPU to run it, the claim would be easy to fulfill, but the result would suck. Details do matter very much here. If they do not give detail, its best to assume the claim is overblown and what they can do is not nearly as good as some people would have it.

Re:lol indian junky shit

[Taco Cowboy]

They have zero reputation for creating junky hardware and code.

Really?

They are not the first.

[Vijaysj]

Searching for 'Asic ESL' resulted in these list of tools and quite a few of them synthesize c/c++ There are other projects which translate Ruby, Python, Haskel etc to HDL code.

Quine anyone ?

[Guignol]

I'd be tempted to compile something much simpler:
char*f="char*f=%c%s%c;main()
{printf(f,34,f,34,10);}%c";
main(){printf(f,34,f,34,10);}

Re:Choose two:

[sensei moreh]

I hope you're not talking GNOME-2 here and not GNOME-3 (or Unity)

Re:Satish?

[Half-pint HAL]

Downmodded. How disingenuous of a site with so many programmers who know firsthand of the shit that comes out of India.

If I had any mod points I would mod you up as "insightful". Because I wasn't aware that "Sunnyvale, Calif." was in India. I thought it was in the US. Thanks for clearing that up.

Re:Choose two:

[Shoe Puppet]

step one: compile gnu code licensed under gpl3
step two: watch the lawsuits ensue while gnu demands the blueprint.

Nah, I the blueprints would be more akin to the intermediate assembly that gets created when compiling somethin.g

Real World Example

[aprdm]

Hello guys i work with VHDL and C for a while (small company gotta do the SW and the HW) We are developing a product (embedded system) and some calculus were taking too much time doing it on software, so instead using a C program to do this calculus now we are using hardware. I developed a VHDL module responsible for doing FFT calculus that is an order of magnitude faster than the software equivalent plus it is real time by default (since it's hardware) Now we have a SoC with a FFT hardware attached to the CPU

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!

Re:acronymification [Re:A better question]

[Caratted]

Don't joke about acromynificationizing. Chaos doesn't even begin to describe the ramifications of such a move in the name of "5, funny."

learning != being spoon-fed

[luis_a_espinal]

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?

http://lmgtfy.com/?q=SoC

Slashdot, where searching for an abreviation's meaning has become the ultimate technical challenge.

Once again, editors, we don't all know everything about everything in the tech world.

News for nerds?. Ain't that supposed to mean something?

Some of us come here to learn new things

Bro, two words: Google and wikipedia. And one more word: 2012. You should consider a career/interest change if you don't grasp the meaning conveyed by these three words.

and you guys don't make it easy.

Not to be mean, but if you want easy, there is always hamburger flipping (which I did when I was in college) or pants folding at the GAP.

TFS should at least leave me with an impression of whether or not I need to read the TFA.

But you can make that determination by simply f* googling the SoC abbreviation. About 5/6 of the sentence already tells you that this is about translating C code into something. What that something means, you search it if you don't know it. The fact is that the mere idea of translating C into something, whatever that means, should constitute enough to warrant interest (or lack thereof) depending on your technical proclivities.

Also, if you really feel that a subject line should tell you whether or not you need to read something, you should not venture that much at all out of your comfort zone instead of demanding that stuff be made easy for you to digest. Technical fields are vast and complex, ergo the use of acronyms (and tools like google to find their meaning in seconds.)

You assume that because you didn't know the meaning of SoC, that people don't make it easy for you. In reality, it is a demonstration of your lack of an inquisitive mind with a proclivity of immediate satisfaction. Let me know how that works for you as you, and I quote you, "come here to learn new things."

You don't want learning. You want spood feeding of already masticated material.

Re:learning != being spoon-fed

[wonkey_monkey]

"SoC", to me, was utterly without meaning. For the want of half a second of typing, an editor could have given those of us who don't know all the acronyms under the Sun at least an inkling of what the article was about. If "SoC" was a secondary term in a quote from a source, or something (such as "ANSI C" in the summary), I'd be less peeved, but when it's exactly what the article is about, I don't think it's too much to ask.

Just take a look at the Sport pages on the BBC News website - not as niche as Slashdot, but you'd tend not to go there unless you had an interest in sport. And yet we see snippets such as this all around:

Chelsea striker Fernando Torres
Premier League footballer Steven Pienaar
Liverpool's Luis Suarez

I wouldn't have the first idea of who these people played for out of context, but the BBC have made it simple and clear with just a few extra words.

It just seems obvious to me that it would be good journalistic style to go that little extra millimetre to make something which you want people to read easy to read, rather than turning one's nose up at anyone too dumb to understand an article about an unexplained acronym.

Also, if you really feel that a subject line should tell you whether or not you need to read something

As a matter of fact, that is exactly what I feel a good subject line should tell you.

dilettante

[luis_a_espinal]

With 14 different meanings in science and technology alone, according to Wikipedia. The point is that one person writes the summary and a huge number of people read it. Not all of them know everything. Just type few extra characters ("System on a Chip" instead of "SoC" the first time you use it) and by spending a few seconds you save others what probably adds up to quite a significant amount of time spent on figuring out what it means. That doesn't directly benefit the writer of the summary, of course, but there needs to be just one other person taking the trouble to type those few extra characters for a term the writer of this summary is not familiar with to more than compensate for the extra time spent.

It's efficient to be clear in what you write and not assume that everyone knows every acronym. What baffles me is how many geeks don't understand such a simple concept.

What baffles me is how many geeks can't do basic research. We are talking about software translation for Christ' sake. It is evident then that translation is either to another language, or compilation towards a specific platform. That right there gives you the context with which to narrow your search.

What is worse is seeing many geeks in /. who don't know what SoC means. What's next? You need an explanation of what CPU means as well? GPU? RAM? ALU? LED? IO?

Not that I really put any credence to geek street creed, but seriously, what the heck. Seriously, I would expect a sophomore CS/CE/EE student (a good one worth its salt, not an HTML dilettante) to know most of these, and to be capable of autonomously acquire knowledge for those he doesn't.

You are just looking for a reason to be upset about your inability to reach immediate information satisfaction, and your unjustified believe that shit needs to be readily digested just for precious snowflake you at every corner you lays eyes upon. That is all.

Re:Choose two:

[unixisc]

step one: compile gnu code licensed under gpl3 step two: watch the lawsuits ensue while gnu demands the blueprint.

Actually, no fab will ever agree to run such a simulation, since GPL3 will insist that they make available all their process details, and in the process (pun not intended), end up giving their competitors all details about their various process parameters, yields and so on. The FSF will have to make its own fab to run this. Maybe RMS might be able to get his hands on one of the old DEC fabs in MA, and get them to manufacture all GNU SoCs. Of course, he'll demand unionized workers, and it will be fun seeing him deal w/ the unions that he sets up to work in those fabs. There'll be no secrets, and as a result, he'll have to price every chip exhorbitantly in order to break even. Hopefully, the FSF or FHF will go out of business trying to run such an operation.

Re:Linux on a chip!

[unixisc]

While Minix would fit on a microchip, being a microkernel

Emperor's New Clothes anyone?

[eminencja]

I've been hearing that kind of crap for more than 10 years now and have known several startups that claimed exactly that.

Some would claim they had some cool software and you would start thinking, "oh my, how did they do it? that's truly incredible. This might be worth even more than the 200ooo$ they charge for it". The truth was that the price tag was that high so that noone could buy the software (because it was not ready yet; and in fact never materialized).

Some companies had some technology, e.g. Celoxica that did Handle-C (C variant) synthesis to FPGA. They had large offices, their employees drew BMW's but finally the bubble burst; they moved to a more modest location; and then finally sold the C synthesis business to Catalytic, a company that claimed they could synthesize MATLAB to FPGA (haha); and finally all that crap was acquired for 80(?)k $ by Mentor Graphics.

Re:Depends on the source code and what the chip ne

[TheRealMindChild]

and lots of private memories for small pieces of the system

It is called Virtual Memory. Get back with me when you catch up to this year (do you know what year it is?)

Re:Depends on the source code and what the chip ne

[TheRealMindChild]

See, this is the problem with application layer software guys like you who haven't ever thought about the underlying HW implementation. You know about one tool, a hammer (sequential instruction streams executing in a VM controlled address space), and when someone tells you that things are different in other domains you won't even let the information in, because as far as you're concerned everything is a nail.

I don't disagree with you at all. But when the hammer says "Microsoft"/"Intel" on it, I can make all of the holes in the wall that I want, so long as the end result "works". Don't hate the player. Hate the game.