[MootWoop]

I think that the philosophy is different, and this implies a lot of things. We wanted to try something different, create a language and IDE that were easy to use rather than make something more or less compatible with C; and we aimed at making a language that could replace HDLs for most uses in the long term. This is why we created a new language from scratch rather than patching things up on top of C.

In practice, this means saner defaults (and better performance) than past C-like HDLs. Cx is cycle-accurate because this is how digital hardware works, and within a cycle you can have as many instructions as you want. There is no need for Handel-C's "par" statement, and it is much easier to understand and write code with good performance. In Cx, ports (Handel-C channels) can be "bare metal" so you can interact with the rest of the world, or slightly more sophisticated (with an additional synchronization signal). In general Cx is "fat free", what you type is what you get, so I'm pretty confident that logic consumption would remain under control :-) I've never written Handel-C, but from the manual it seems kind of complicated for even the simplest designs, and not very elegant.

I think most alternative HDLs have been abandoned :-/ Often the technology did not meet users' expectations: logic consumption was too high, and it was very difficult to obtain the desired performance. Additionally, I believe that these initiatives weren't targeted at the right public, and the target market itself was way too small. If you're interested, I've written a post about this on our blog: https://blog.synflow.com/marketing-disruptive-innovation/

[csirac2]

Cool! I've actually had a Virtex-6 ML605 eval board for quite some time now, gathering dust... I always wondered what the Synflow toolchain looked like, it seems quite expensive - perhaps I can dust it off for Cx :-)

[nsiret]

You're welcome csirac2. I'm curious to hear about your opinion of our toolchain!