[nsiret]

Hi Scott, I'm a co-founder of Synflow. You're right, the VHDL on our website is a bit overly verbose. I will update the website with the right version of the code that day.

And I also agree on your point. This is why we added properties to the language (http://cx-lang.org/documentation/properties) so one can either use the (implicit) default names and types for the clk, reset, etc. or explicit/tweek things for more complex systems.

[scott_wilson46]

Actually another thing I am curious about is how asynchronous clock domains are handled Usually this is something thats quite tricky to model in a HLS tool. Also, how about simulating the interactions between the domains?

[nsiret]

That's a good point Scott. Asynchronous clock domains are indeed complex and it took us time to manage them efficiently. When you need to connect different clock domains with Cx/ngDesign you have to synchronize the various tasks with specific components (e.g. SynchronizerMux) http://cx-lang.org/documentation/instantiation/stdlib. Simulating the interactions between the domains is not yet supported by our simulator. We will develop this feature when people will request it. And you know, we're a startup so we still have plenty of R&D to do :-)

[scott_wilson46]

I think if you can crack the modelling and simulation of asynchronous clock domains then I suspect you will have something that the other HLS solutions don't have at the moment that would be an incredibly useful feature. Design with async clocks is difficult and I have seen loads of bugs with these interfaces (including bugs found in the field for chips that were release many years previously).