Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Cx programming language

cx-lang.org

Post reply on HN
Print view View original

41–49 of 49 posts

Re: The Cx programming language

#41

Post by davidb_ »

csirac2 wrote: post #12

It's been 10 years since I did much FPGA dev, but at the time I had a lot of fun in Celoxica Handel-C. Sadly I could never quite synthesize my project to the size I could achieve with Verilog. I seem to recall having the Virtex-II datasheets next to me when coding Verliog, not so much with the Handel-C so perhaps I never quite got the hang of driving the language optimally for the target device at hand... My question…

Bluespec is a language that's getting attention from academia and industry: http://www.bluespec.com/

Re: The Cx programming language

#42

Post by MootWoop »

gothenburg wrote: post #37
MootWoop wrote: post #31

Earlier quoted context omitted.

That's a very good point. In fact the main difference in semantics is that Cx code is structured. Sure in VHDL/Verilog you have functions and if statements and loops. But they can only be used to describe combinational logic. There is a chasm between synchronous logic (everything in a big switch/case) and combinational statements. Cx supports functions, if and loops for both combinational and synchronous logic. You c…

"Another property is that there is no synthesizable subset in Cx. As far as I know, this is very rare in languages for hardware design, but the language is entirely synthesizable. You never have to think about synthesis versus simulation. Exactly like in software, nobody ever wonders if they can write code that won't run on the processor :-)" This is scary. I want the tool to tell me "I can't synthesize this" because…

@gothenburg @mng2 I get that you think it's not useful or even it's crazy, especially as both of you seem to be seasoned hardware designers. But as a software guy myself, there's nothing I have found more horrible when learning to write some VHDL than finding out what was allowed in synthesis, what was tolerated but not recommended, and what was legal VHDL but could never synthesize. Things like automatically inferred latches because of local variables, multidimensional arrays supported but not always (vendor-dependent), loops that work for combinatorial logic only, "wait" that are not permitted (or only in vendor-specific ways), etc.

In Cx you can't create latches, loops work for combinatorial logic and synchronous logic alike, and all in all there are no unsynthesizable constructs. Finding out if a piece of code will result in unacceptable performance is a different problem, I hope to have the compiler kind of "guide" you on this kind of things.

Re: The Cx programming language

#43

Post by csirac2 »

MootWoop wrote: post #13
csirac2 wrote: post #12

It's been 10 years since I did much FPGA dev, but at the time I had a lot of fun in Celoxica Handel-C. Sadly I could never quite synthesize my project to the size I could achieve with Verilog. I seem to recall having the Virtex-II datasheets next to me when coding Verliog, not so much with the Handel-C so perhaps I never quite got the hang of driving the language optimally for the target device at hand... My question…

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, t…

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 :-)

Re: The Cx programming language

#44

Post by nsiret »

csirac2 wrote: post #43
MootWoop wrote: post #13

Earlier quoted context omitted.

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, t…

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 :-)

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

Re: The Cx programming language

#45

Post by nsiret »

scott_wilson46 wrote: post #28
nsiret wrote: post #11

Earlier quoted context omitted.

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…

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?

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 :-)

Re: The Cx programming language

#46

Post by nsiret »

txomon wrote: post #16

I would love to use this instead of VHDL, I have been searching for an alternative to those such verbose languages for a long time, but wasn't able to find any. Where can I download a compiler? How may I start using it? I haven't found any reference of low level that could help me to understand what is the output of the compilers.

You can download the tool on www.synflow.com, start using it with our online course on https://eliademy.com/catalog/basic-of-the-cx-language.html and the output of the compilers are VHDL and Verilog.

Re: The Cx programming language

#47

Post by scott_wilson46 »

nsiret wrote: post #45
scott_wilson46 wrote: post #28

Earlier quoted context omitted.

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?

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.…

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).

Re: The Cx programming language

#48

Post by nsiret »

gothenburg wrote: post #24
MootWoop wrote: post #22

Earlier quoted context omitted.

Don't worry, you're not the first to find that this looks similar to Verilog. I have commented about the syntax aspect on EETimes: see http://www.eetimes.com/author.asp?section_id=36&doc_id=13252... It's more than the syntax though, it's about having a language for hardware design that most developers (yes software developers) will be able to read, understand, and write. For all sorts of purposes, from playing with F…

What I really wanted was a better explanation of Cx's advantages other than "The syntax is similar to C". And I'm not sure if you fully understand the difference between a programming language and a hardware description language. Yes, HDL's syntax might be awkward sometimes (whether it's Verilog or VHDL) but I think you are tackling the wrong problems with the wrong way. Taking the example you gave: always @(negedge…

In short, I would say.

(Main) advantages: - The Cx syntax is a lot easier to learn/debug than VHDL and Verilog (and SystemVerilog, and SystemC) - Cx is easier to use for making more complex systems (it's a structured language with Control structures, Subroutines, blocks, etc). - Being easier to use, Cx allows you to write programs faster. Generally these programs are also easier to debug and easier to maintain. Furthermore, it's easier to manage large, complex programs in Cx. - When you do need to have a really low level of abstraction, you can use VHDL/Verilog and call it in Cx

We are here to help people doing better hardware, and to open it to a majority of engineers so I don't think that fully understanding the difference (...) really matters.

Nothing is wrong with the syntax however it's too tedious and complex. In this simple example it's ok but the more larger the FSM the more complexity to handle.

How is this a different thing? The init is the same as a loop (n = 0; n Yes it is complex and error probing, and that is precisely why it is our duty to make it more simple. Handling and preventing the problems is the job of the compiler so hardware makers can focus on what's matter not on these kinds of complexities.

Clocks (and resets) can be either implicit or explicit. By default you only have one clock and reset, and if you need more you can explicit them - http://cx-lang.org/documentation/properties

Re: The Cx programming language

#49

Post by correnos »

jclis wrote: post #34
correnos wrote: post #26

Earlier quoted context omitted.

One difference from Verilog/VHDL is that Cx will handle state machines for procedural code automatically. Bluespec has a similar facility. Also like Bluespec, it makes the clock implicit which makes a lot of code less noisy.

I looked at Bluespec before I tried Cx, it has good points and very powerful features (parameterization of modules comes to mind), but overall I find the semantics to be too complicated for my taste. Rules firing in parallel with custom priorities and possibly non-deterministic?

Bluespec's thing is that rules are atomic, so they won't ever (appear to) fire in parallel. This is in contrast to Verilog and friends where that isn't guaranteed. The nondeterminism comes in when two conflicting rules are both ready to fire: they can't both fire, so the system needs to choose one. You're warned when the compiler detects this, and it can be resolved by giving one a higher priority.

I personally didn't find the semantics to be unreasonably complicated, but the type system is very much based on Haskell's so if you're not used to that there'll be more of a learning curve.

Post reply on HN