Poor product focus

One of the advantages of RTL/ASIC methodology is the ability to separate much of the development from target process/technology. There is loosely coupled relationship between RTL Coding and Target Process. Similarly, the C language has the possibility to uncouple development from actual timing & throughput requirements- Nirvana from cycle to cycle coding. An algorithm developed once and need not to be modified for different throughput requirement over generations of a product. (In ASIC Methodology, RTL needs to be redesigned for different throughput requirements).  Time and Money in marketing and enabling high level synthesis products to achieve this, was never invested.

Similarly a good use of C based tools is HW-SW co-simulations and empower system architects to make informed decision and allow them to evaluate different scenario/tradeoffs (HLS Tool now support this). But more importantly, same code can be reused with different ratio of programmable hardware and custom hardware to target different market segments.

Feature set was designed to replace RTL and in the process, low level timing constructs were added to C itself. This took away inherent advantage of C language and introduced extra complexity in the language and this was bad move. As evident over time, ASIC flow never tried to replace analog design using Verilog, however, it complemented analog design. Similarly existing ASIC methodology is good for interface designs and ANSI C should be used to represent algorithmic portion of design. Why not allow best of both worlds (ASIC and HLS) to exist!!

Unrealistic Expectations

As mentioned before, over marketing (#2) and wrong use model (#5) set user expectations at very high level. Designer started looking for a magic tool which will solve the problem in a blink. But there is no such thing in world..

In an ideal tool flow, the specific steps of HLS process would be of no concern to the programmer; the application would simply operate at its highest possible efficiency through the magic of automated tools. In practice this is rarely the case: any programmer seeking high performance must have at least a rudimentary understanding of how the optimization and code generation or mapping process works, and must exert some level of control over the process either by adjusting the flow (specifying compiler options, for example) or by revisiting the original application and optimizing at the algorithm level, or both.

So yes, algorithm development and hardware is decoupled but it is still not totally independent process either and developer need to have HW in mind while coding C algorithm. Normally software have coding guidelines which are more tailored towards readability, maintainability etc because software size are much bigger. Though RTL may be big but not as big as software and representative C application is not going to be this big, anyway. So guidelines need to be more tailored towards performance & hardware.

Again here, guidelines are not introducing anything new in the language itself and should not be confused with new constructs. Later we will present specifics of guidelines to allow C coding more adaptable to HW tools.

Too General Application space

Tool companies tried to do everything but everything crappy. They should have focused more on one segment and set of design and tailor tools for that segment and than with maturing process, tool capabilities may be expended.

QoR and predictability

little loss of QoR is expected and acceptable if significant productivity gain is there. But what is not expected is loosing the ability to predict and visualize the implementation before design process starts. Since early tools were suffering from predictability issue, it was natural that design community did not accept such tool.

Modification to existing Language

This is already raised partially in one of the above issue, but what really happened that tool companies, in effort to tackle everything out there they added timing construct to existing tool. Resulting language was difficult for everybody out there. Software people did not understand HW part of it and HW people did not understand SW part of it. This create extra burden for training and at the same time, resulted in productivity loss.

Conclusion

There were plenty of reasons, as explained before which resulted in huge marketing and technical failure in HLS domain. Next we'll try to investigate and look for right model for High Level Synthesis. Please stay tuned for updates.

Disclaimer, the evil necessity: Posted views are of author only and this website is no way responsible for any damages caused by usage of this information.