Breaking News
News & Analysis

EDA Startup Offers Language, Hardware IDE

9/16/2013 11:05 AM EDT
24 comments
NO RATINGS
1 saves
Page 1 / 2 Next >
More Related Links
View Comments: Oldest First | Newest First | Threaded View
<<   <   Page 2 / 3   >   >>
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.

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.

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

 

 

 

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.

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

<<   <   Page 2 / 3   >   >>
Most Recent Comments
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
Top Comments of the Week