@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 :-)).
"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 :-)
@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.
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?
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.
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.