Breaking News
Comments
Newest First | Oldest First | Threaded View
Page 1 / 3   >   >>
p_suri
User Rank
Author
Re: The event-driven paradigm
p_suri   9/23/2013 12:12:51 PM
NO RATINGS
interesting...

jandecaluwe
User Rank
Author
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 :-)).

jandecaluwe
User Rank
Author
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 :-)

Peter Clarke
User Rank
Author
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.

 

 

Peter Clarke
User Rank
Author
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?

Matthieu Wipliez
User Rank
Author
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 :-)

jandecaluwe
User Rank
Author
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
Author
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
Author
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
Author
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????

 

 

 

Page 1 / 3   >   >>


Radio
LATEST ARCHIVED BROADCAST

What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.

Brought to you by:

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Like Us on Facebook
Special Video Section
With design sizes expected to increase by 5X through 2020, ...
01:48
Linear Technology’s LT8330 and LT8331, two Low Quiescent ...
The quality and reliability of Mill-Max's two-piece ...
LED lighting is an important feature in today’s and future ...
05:27
The LT8602 has two high voltage buck regulators with an ...
05:18
Silego Technology’s highly versatile Mixed-signal GreenPAK ...
The quality and reliability of Mill-Max's two-piece ...
01:34
Why the multicopter? It has every thing in it. 58 of ...
Security is important in all parts of the IoT chain, ...
Infineon explains their philosophy and why the multicopter ...
The LTC4282 Hot SwapTM controller allows a board to be ...
This video highlights the Zynq® UltraScale+™ MPSoC, and sho...
Homeowners may soon be able to store the energy generated ...
The LTC®6363 is a low power, low noise, fully differential ...
See the Virtex® UltraScale+™ FPGA with 32.75G backplane ...
Vincent Ching, applications engineer at Avago Technologies, ...
The LT®6375 is a unity-gain difference amplifier which ...
The LTC®4015 is a complete synchronous buck controller/ ...
10:35
The LTC®2983 measures a wide variety of temperature sensors ...
The LTC®3886 is a dual PolyPhase DC/DC synchronous ...