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

11–20 of 49 posts

Re: The Cx programming language

#11

Post by nsiret »

scott_wilson46 wrote: post #9

I can't help but feel that the VHDL that was written is a bit overly verbose. You could probably write something like: i_sm: process(clk, reset) begin if (reset) then state if (data_valid = '1') then if (count if (data_valid = '1') then if (count which is not too dis-similar from the Cx example (I've missed a few things out like port/signal declerations, just wanted to show the guts of the code). The thing I like abo…

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.

Re: The Cx programming language

#12

Post by csirac2 »

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 is, to a layman like me - does Cx bring something to the table that other C-like HDLs missed?

Edit: I Also very much enjoyed a scheme-like HDL called confluence... Seems it fizzled out. Have any alternative HDLs stuck?

Re: The Cx programming language

#13

Post by MootWoop »

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, 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/

Re: The Cx programming language

#14

Post by FraaJad »

scott_wilson46 wrote: post #9

I can't help but feel that the VHDL that was written is a bit overly verbose. You could probably write something like: i_sm: process(clk, reset) begin if (reset) then state if (data_valid = '1') then if (count if (data_valid = '1') then if (count which is not too dis-similar from the Cx example (I've missed a few things out like port/signal declerations, just wanted to show the guts of the code). The thing I like abo…

That Ada roots doe.

Re: The Cx programming language

#15

Post by bpg_92 »

runeks wrote: post #8

This looks pretty cool. Would love to see a toy example of a double-SHA256 engine. Would be kind of cool if people could build their own Bitcoin mining ASIC, crowd fund it, and give everyone access to cheap Bitcoin mining ASICs.

This needs to become a thing!!! I guess I will give Cx a chance.

Re: The Cx programming language

#16

Post by txomon »

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.

Re: The Cx programming language

#17

Post by txomon »

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.

I have found everything but the last part, which the output format is... I suppose I will have to download and test it.

Re: The Cx programming language

#18

Post by MootWoop »

bpg_92 wrote: post #15
runeks wrote: post #8

This looks pretty cool. Would love to see a toy example of a double-SHA256 engine. Would be kind of cool if people could build their own Bitcoin mining ASIC, crowd fund it, and give everyone access to cheap Bitcoin mining ASICs.

This needs to become a thing!!! I guess I will give Cx a chance.

We hope so too :) If somehow Cx doesn't live up to its promises and what you expect from it, please let us know! We're still improving it based on the feedback we get. Thanks!

Re: The Cx programming language

#19

Post by MootWoop »

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.

Good point, we need to make this clearer I think. We (Synflow) have a compiler and IDE that you can download from https://www.synflow.com The compiler and IDE are open source, and the compiler generates VHDL code. We also have additional (proprietary) features that include a Verilog code generator, a C-based simulator, and exporters to third-party tools.

Re: The Cx programming language

#20

Post by gothenburg »

I fail to understand what kind of advantage this language brings to the table compared to the existing solutions.

You touched the subject of the awkward syntax of VHDL. But what about the syntax of Verilog? The syntax seems to be very similar to Verilog.

And besides of the syntax, what are the other features that this language brings that we can't find anywhere else?

And why do you claim that this is oriented "for developers"? Who are these "developers"? Software guys?

Post reply on HN