Breaking News
News & Analysis

EDA Startup Offers Language, Hardware IDE

Eat your own dog food
9/16/2013 11:05 AM EDT
24 comments
NO RATINGS
1 saves
< Previous Page 2 / 2
More Related Links
View Comments: Threaded | Newest First | Oldest First
Frank Eory
User Rank
CEO
An intermediate level of abstraction?
Frank Eory   9/16/2013 2:00:23 PM
It sounds like they have aimed for a level of abstraction that is above RTL but below untimed, algorithmic HLS. This could be very appealing, but will designers warm up to the idea of capturing their designs in a new, proprietary language?

Matthieu Wipliez
User Rank
Manager
Re: An intermediate level of abstraction?
Matthieu Wipliez   9/16/2013 2:45:16 PM
NO RATINGS
Hi Frank,

thank you for your comment, and this is an interesting question that you're asking. We hope to get some early adopters for whom this won't be an issue, and work with them to make the language evolve until we feel comfortable it is ready for standardization.

daleste
User Rank
CEO
Re: An intermediate level of abstraction?
daleste   9/16/2013 9:35:48 PM
NO RATINGS
Great work to put yourself in the designers shoes and "eat your own dog food".  I expect this would have a wide appeal.  Hope the best for your company.

Nicolas_Yu.Wang
User Rank
Rookie
Re: An intermediate level of abstraction?
Nicolas_Yu.Wang   9/16/2013 9:54:13 PM
NO RATINGS
Loved to know this. I'm a believer of C/C++ in IC design.

Just curious, what's the major difference from SystemC or any other C/C++ attempt tried before? Is C~ between ESL and RTL or what?

Why do you create a new language instead of providing some package like "boost" to C++? Wouldn't it be easier?

 

Matthieu Wipliez
User Rank
Manager
Re: An intermediate level of abstraction?
Matthieu Wipliez   9/17/2013 8:41:26 AM
NO RATINGS
Hi Nicolas,

the major difference is that C~ is a programming language dedicated for hardware, contrary to C/C++, which are software languages. Try translating 'malloc' or 'new' to hardware ^^ SystemC is somewhere in the middle, but I think it is not the solution.

C~ is above RTL, as it does not have an explicit clock, reset, or signals. The language is still cycle-accurate, so it's lower level than the code you would typically write with HLS. So it's kind of in-the-middle, we use a model of computation derived from dataflow process networks, which define computations in terms of action firings; in C~ a firing is executed in a cycle.

As I explained in the post I linked to above, extending C++ is probably not a good idea, it is difficult to parse, complicated to analyze, and you still have to deal with the C++ layer (hello ugly error messages).

Peter Clarke
User Rank
Blogger
Re: An intermediate level of abstraction?
Peter Clarke   9/17/2013 5:12:29 AM
NO RATINGS
I see three factors that might afflict Synflow but I think you are right to highlight the language issue. Proprietary languages often struggle for adoption.

The question has to be how does C~ compare with such offerings as SystemVerilog and perhaps to a lesser degree SystemC...but also how the IDE can connect with descriptions in those languages.

A second factor is graphical design. Textual languages have dominated the IC design area for decades, despite one or previous attempts to introduce graphical design front-ends that failed to gain traction.

A third factor is Synflow's avowed intent to steer clear of software. This is a bit of double-edged sword. On the one hand they are probably right that there are two distinct audiences. One is system/software developers who are not interested in hardware.The second is hardware engineers. However, high-level hardware engineers for a long time had to have an eye on the software. Often they are choosing whether something should be software programmable or accelerated in hardware.

So there are fundamental questions to be addressed but all could be resolved in Synflow's favor if this tool produces high QoR designs in a fraction of the time of conventional design AND it could pass designs over to an SoC RTL to gate-level desgn process.

 

 

Matthieu Wipliez
User Rank
Manager
Re: An intermediate level of abstraction?
Matthieu Wipliez   9/17/2013 9:22:00 AM
NO RATINGS
Hi Peter,

yes these are big questions, we look forward to customers' reactions! Graphical design is a tough question, too. We already know it's not perfect for every use case in its current form, that said if done well graphical can be awesome. Anyway, it is already a huge improvement over how VHDL/Verilog/SystemC do it!

What we're saying is that software engineers may well get interested in designing hardware, but if they do they should not expect to dump a piece of C and expect the best hardware there is (HLS had promised that, I already blogged about why it will never be able to do that). However, if software engineers do get into hardware design and want a high quality of results, they would definitely go a lot faster with C~ than if they had to use VHDL/Verilog.

boblespam
User Rank
CEO
IP integration
boblespam   9/17/2013 2:27:36 AM
NO RATINGS
It looks very appealing for small to medium projects in companies thats can't afford big tool chains from synopsys or others. Is the simulator included ? Is it possible to simulate mixed design with C~ top level and some VHDL/Verilog IPs ? What about cosimulation ?

Peter Clarke
User Rank
Blogger
Re:Chisel
Peter Clarke   9/17/2013 7:08:51 AM
NO RATINGS
Thanks for drawing attention to Chisel.

I wonder if it has an adherents in Europe.

It is interesting to note that VHDL was backed by the US DoD and ended up being widely adopted in Europe while the US leading-edge preferred Verilog.

Broad generalization I know but that was how I remember it

Peter Clarke
User Rank
Blogger
Re:Chisel
Peter Clarke   9/17/2013 7:42:34 AM
NO RATINGS
I agree there has been a reluctance to move up to higher levels of abstraction but it is partly because HLS does not really work. Is definitely not sufficiently automated.

So you end up modeling at high-level and then designing at lower level and then spending a lot of effort to try and be confident that what you modeled at high level is equivalent to what you are designing at lower level.

And why has HLS not worked?

Here is my argument.

Because unlike RTL-to-gate-level -- where designers were willing to give up messing about with transistors and gates and dimensions of cells -- there was no obvious way to accept constraints (even at the IP core level).

And that has happened because there is not equivalent to the NAND completeness of logic at the gate level. Isn't it DeMorgan's Theorems that prove that all logic systems can be converted into NAND gates or NOR gates? Therefore being constained to using a limited set of gates allow all digital logic to be created. The constraint of using those predetermined gates allows synthesis to work.

There is no equivalent limited set of IP cores that could create all-imaginable logic circuits and so engineers are reluctant to accept any constraints on either IP cores or their dimensions and no obvious way to guide a synthesis engine.

Until we have automated provable synthesis of yet unimagined logic EDA is stuck working at multiple levels of abstraction and stuggling to prove their equivalence.

 

AZskibum
User Rank
CEO
Re:Chisel
AZskibum   9/17/2013 1:21:17 PM
NO RATINGS
"And why has HLS not worked?"



Two basic reasons: (1) Hardware designers are reluctanct to move from HDL to C -- even to hardware-friendly SystemC, and (2) The productivity gains of HLS only apply to DSP-oriented designs -- number crunchers. Try designing a complex state machine or a serial comm interface with HLS. Yes, it can be done, but by the time it is done, the designer wonders exactly what the point of that exercise was.

Matthieu Wipliez
User Rank
Manager
Re: An intermediate level of abstraction?
Matthieu Wipliez   9/17/2013 9:02:36 AM
NO RATINGS
Hi GSMD,

yes I'm aware of Chisel, I included it in my post on Synflow's blog Beyond RTL part 2: Domain-Specific Languages. I think Chisel is a good idea, like MyHDL and similar efforts. It has the advantage of being open-source, but being open or close source, or free or not, does not seem to have made a big difference in EDA historically.

Now back to Chisel, it is a bit like SystemC in that it is based on an existing, large, complex language (Scala is much better than C++, but it is far from being simple). Is the designer really free from having to deal with the Scala layer? Then it's a matter of taste, but I find Chisel's syntax complicated, and its semantics difficult to understand ('when' and 'unless' to do if/then/else but in a slightly different way).

jandecaluwe
User Rank
Rookie
The event-driven paradigm
jandecaluwe   9/17/2013 2:40:20 PM
NO RATINGS
Most HDLs that have been proposed are like Chisel and C~: registers are explicit, and events such as clock edges are implicit.

Notable exceptions are Verilog and VHDL. These HDLs follow the event-driven paradigm: registers are implicit and events are explicit.

Would-be HDL language designers seem to ignore this historical lesson systematically. The HDL language winners are the exception, and all those other HDLs are all but forgotten.

Why is that? Because the event-driven paradigm is much more expressive for modeling and better suited to verification (which is much harder than design itself). This is what the market wants and needs, not the focus on "full synthesizability" or "generating hardware".

In addition to SystemC, there is one more exception that I know of: MyHDL. MyHDL proudly follows the event-driven paradigm, like Verilog and VHDL. Of all the newer HDLs that have been proposed, it is the only one afaik.

Jan Decaluwe (the MyHDL guy)

Peter Clarke
User Rank
Blogger
Re: The event-driven paradigm
Peter Clarke   9/18/2013 6:32:39 AM
NO RATINGS
Thanks Jan

And MyHDL has the advantage of being open-source.

If that is an advantage????

 

 

 

p_suri
User Rank
Rookie
Re: The event-driven paradigm
p_suri   9/23/2013 12:12:51 PM
NO RATINGS
interesting...

Peter Clarke
User Rank
Blogger
Re: The event-driven paradigm
Peter Clarke   9/18/2013 6:32:40 AM
NO RATINGS
Thanks Jan

And MyHDL has the advantage of being open-source.

If that is an advantage????

 

 

 

jandecaluwe
User Rank
Rookie
Re: The event-driven paradigm
jandecaluwe   9/18/2013 8:05:45 AM
NO RATINGS
@Peter said: "And MyHDL has the advantage of being open-source. If that is an advantage????"

I expect people to use MyHDL primarily for technical reasons. Sometimes I don't even mention the open-source aspect.

The MyHDL developers try to make a better HDL in the first place. However, in no way this means throwing everything from Verilog/VHDL away. The event-driven paradigm is what the winning HDLs have in common, and I think it is an extraordinary good and successful concept.

Peter Clarke
User Rank
Blogger
Re: The event-driven paradigm
Peter Clarke   9/19/2013 7:44:01 AM
NO RATINGS
By saying "if it is an advantage" I meant to imply that the big commercial EDA vendors are perhaps reluctant to support or build off an open-source language?

jandecaluwe
User Rank
Rookie
Re: The event-driven paradigm
jandecaluwe   9/19/2013 9:04:19 AM
NO RATINGS
@Peter said: "By saying "if it is an advantage" I meant to imply that the big commercial EDA vendors are perhaps reluctant to support or build off an open-source language?"

Yes, big EDA still has to embrace open-source, unlike small software companies such as Google :-)

Matthieu Wipliez
User Rank
Manager
Re: The event-driven paradigm
Matthieu Wipliez   9/18/2013 9:14:05 AM
NO RATINGS
Hi Jan,

I'm not sure what you mean by 'registers are implicit [in Verilog/VHDL]'? How are they implicit? In C~ we have state variables, that translate directly to Verilog/VHDL regs/signals. We also have local variables, that are promoted to reg/signal if they are used over more than one cycle.

Additionnally, if you take a look at C~, you'll see that the language is cycle-accurate: what happens at each clock cycle is explicitly defined, just not in terms of 'rising_edge'. Similarly, a task's behavior is expressed with 'while', and 'if', and in the end it is transformed to a FSM with states and transitions.

I don't know about event-driven's suitability for verification, but if it is indeed more appropriate, then I guess we can always translate C~ designs to an event-driven representation (after all that is what we do when we generate VHDL or Verilog). Maybe it depends on the kind of designs you do, in some cases event-driven modeling might be better, in other cases it might not?

jandecaluwe
User Rank
Rookie
Re: The event-driven paradigm
jandecaluwe   9/18/2013 12:36:52 PM
NO RATINGS
@Matthieu said "I'm not sure what you mean by 'registers are implicit [in Verilog/VHDL]'? How are they implicit?"

In Verilog/VHDL/MyHDL you don't declare hardware registers. Signals/variables/regs imply hardware registers, or combinatorial logic, or both, strictly by how they are used in the model.

"Additionally, if you take a look at C~, you'll see that the language is cycle-accurate: what happens at each clock cycle is explicitly defined, just not in terms of 'rising_edge'."

In Verilog/VHDL/MyHDL, one can choose to model cycle-accurately (e.g. for RTL-style synthesizable models) or not (e.g. for higher-level models and test benches). This demonstrates how the event-driven paradigm is more powerful, which is especially important for verification.

"I don't know about event-driven's suitability for verification, but if it is indeed more appropriate, then I guess we can always translate C~ designs to an event-driven representation"

In practice, designers want a strong modeling and verification language in which you can also design hardware, not a narrow implementation-oriented design language.

 

 

Matthieu Wipliez
User Rank
Manager
Re: The event-driven paradigm
Matthieu Wipliez   9/19/2013 5:03:23 AM
NO RATINGS
"In practice, designers want a strong modeling and verification language in which you can also design hardware, not a narrow implementation-oriented design language."

Narrow? Or lean? ;-) And I take 'implementation-oriented' as a good quality :-) Anyway, as you say it all boils down to what 'designers want', and it would seem that different designers have different needs; I guess we will discover soon enough those who want C~ and those who don't, this is part of the game :-)

Peter Clarke
User Rank
Blogger
Re: The event-driven paradigm
Peter Clarke   9/19/2013 7:48:12 AM
NO RATINGS
And as well as being not so keen on an open-source language would people agree that the big EDA companies want to protect what they have which is based on RTL synthesis?

The big EDA firms don't really want higher-level synthesis to suceed as it might be disruptive to their current business models and tools?

That's not my idea but one that was put into my head by an industry veteran well known to EE Times readers.

 

 

jandecaluwe
User Rank
Rookie
Re: The event-driven paradigm
jandecaluwe   9/19/2013 11:00:23 AM
NO RATINGS
@Peter said: "The big EDA firms don't really want higher-level synthesis to suceed as it might be disruptive to their current business models and tools?"

I don't believe in that theory.

The evidence doesn't support it either. EDA companies, also big EDA, have a long history of developing and marketing a whole range of HLS tools, and some are on the market today. That cannot all be window dressing.

I believe that there is a technical reason why HLS has not been as successful as RTL synthesis. The problem with HLS is that, unlike RTL synthesis, it is in general not obvious how to define "correctness" between synthesis input and output. It is therefore not possible in general to assess what the tool is doing exactly.

Some HLS vendors go as far as pushing the problem to the designer. When the HLS flow works, it does so thanks to the tool, otherwise the problem is with the user :-) Such an attitude is unworkable in industrial practice.

The key problem is therefore not design, languages or algorithms. It is verification (as always :-)).

Flash Poll
Radio
LATEST ARCHIVED BROADCAST
EE Times editor Junko Yoshida grills two executives --Rick Walker, senior product marketing manager for IoT and home automation for CSR, and Jim Reich, CTO and co-founder at Palatehome.
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed