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

31–40 of 49 posts

Re: The Cx programming language

#31

Post by MootWoop »

scott_s wrote: post #29

Advice to the authors: don't stress syntax, but semantics . People here are getting caught up on the notion that "this syntax is not too different from Verilog/VHDL". But that's not the point; it's not what you say, but what that means . You have created a programming model that software people can understand intuitively, but also easily maps to hardware. People may get hung up on this because the example on your pag…

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 can have a function that spans over two cycles. You can give parameters to this kind of function just like in software, except that in the end this is all inlined and the state machine is flattened.

The language encourages a higher level of abstraction where you think in terms of blocking reads and data availability rather than "is my signal true". The best is that this can be extended just by changing the port signature, for example to provide rendez-vous style communications (we call it "sync ack" but they're not implemented yet), whereas in HDL you'd have to write a lot of boilerplate code.

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

And for the example you mention, this is another interesting feature of the language. Because we support sequential loop constructs etc. you can actually write code that works and synthesizes pretty easily, albeit it is slow. And then you can produce a derived version that is optimized :-)

Re: The Cx programming language

#32

Post by MootWoop »

daphreak wrote: post #30
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 don't know if MyHDL( http://www.myhdl.org/ ) really stuck but I've used it a few times for some smaller things. What I really liked about it was how fast I could simulate while iterating on a design, and the fact that I could use Python unittest for testing. I will definitely be taking Cx for a spin. Not wasting time with clock/reset/fsm boilerplate will make development faster. If I can get my hands on a trial of…

Yes it is still in use, and the simulation capabilities are quite advanced! It remains a HDL, better than VHDL and Verilog, so you still have to worry about resetting, clocks and state machine.

Just a word of caution the cycle accurate simulator is still a bit experimental (don't use big numbers, and bit accurate signed arithmetic is not finished yet... we're working on it)

Re: The Cx programming language

#33

Post by MootWoop »

chillingeffect wrote: post #25

This is interesting, but if you really want to get user traction, look deeper into how the industry uses HDLs. For example, one of the most common use cases is scaling code from year-to-year, e.g. the video card market. This means that in 2012, your code works with 16 bits, then 2013, 32, then 2014, 64-bit etc. And you need to keep updating your code to do this, having not touched it for just about six months - perfe…

Really? Aren't they using VHDL generics/Verilog parameters?

Cx supports specialization of entities with this kind of semantics, so you give an instance parameters and the compiler generates specialized code (so there's no more need for Perl scripts thankfully ^^). Right now you can't enable or disable things, but this is something that would be excellent: modify the hierarchy, add or remove ports, all depending on which flags the entity was instantiated with.

As I explained in another comment a few minutes ago, we're not so much about syntax as we're about better semantics and higher level description (I agree this isn't very clear on the website). Your remark about the ecosystem is perfectly right, and this is what makes EDA a tough market.

I don't know enough about verification to comment. I know SystemVerilog is very powerful but very complex, I've read about UVM and stuff, some people use SystemC. I wonder how they even manage to get hardware validated!

Re: The Cx programming language

#34

Post by jclis »

correnos wrote: post #26
gothenburg wrote: post #20

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

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?

Re: The Cx programming language

#35

Post by scott_wilson46 »

daphreak wrote: post #30
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 don't know if MyHDL( http://www.myhdl.org/ ) really stuck but I've used it a few times for some smaller things. What I really liked about it was how fast I could simulate while iterating on a design, and the fact that I could use Python unittest for testing. I will definitely be taking Cx for a spin. Not wasting time with clock/reset/fsm boilerplate will make development faster. If I can get my hands on a trial of…

If you are interested in using python for unit testing there is also Cocotb which is a python based library for running verilog and vhdl simulations. It interfaces to the simulator and allows you to stimulate your design directly from python:

https://github.com/potentialventures/cocotb

Re: The Cx programming language

#36

Post by daphreak »

scott_wilson46 wrote: post #35
daphreak wrote: post #30

Earlier quoted context omitted.

I don't know if MyHDL( http://www.myhdl.org/ ) really stuck but I've used it a few times for some smaller things. What I really liked about it was how fast I could simulate while iterating on a design, and the fact that I could use Python unittest for testing. I will definitely be taking Cx for a spin. Not wasting time with clock/reset/fsm boilerplate will make development faster. If I can get my hands on a trial of…

If you are interested in using python for unit testing there is also Cocotb which is a python based library for running verilog and vhdl simulations. It interfaces to the simulator and allows you to stimulate your design directly from python: https://github.com/potentialventures/cocotb

Very interesting. Will definitely look into this.

All of our tests right now are implemented as VHDL/Verilog testbenches. We automate building and running in ISim with a simple Python tool which generates xunit output. It works but its slow and kind of painful to manage testcases.

Re: The Cx programming language

#37

Post by gothenburg »

MootWoop wrote: post #31
scott_s wrote: post #29

Advice to the authors: don't stress syntax, but semantics . People here are getting caught up on the notion that "this syntax is not too different from Verilog/VHDL". But that's not the point; it's not what you say, but what that means . You have created a programming model that software people can understand intuitively, but also easily maps to hardware. People may get hung up on this because the example on your pag…

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 when it does, it might infer characteristics of the design that I might not want.

Do you have some kind of paper or detailed explanation about this part?

Sometimes a bad design is not bad because it's badly written, it's bad because it's not complying with some timing constraints or because the synthesis tool decided to infer some crazy system from the code the designer wrote.

Re: The Cx programming language

#38

Post by scott_s »

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…

Is it any scarier than having wildly inefficient software code? (Think a naive traversal of large matrices that thrashes the cache.)

That's a workflow where optimization requires knowing the internals and how they interact, but you can ignore such things if you just want correctness. At least in software, that model works well, because the performance of most of the code we write doesn't matter - even in applications where performance is a concern.

Re: The Cx programming language

#39

Post by mng2 »

scott_s wrote: post #38
gothenburg wrote: post #37

Earlier quoted context omitted.

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

Is it any scarier than having wildly inefficient software code? (Think a naive traversal of large matrices that thrashes the cache.) That's a workflow where optimization requires knowing the internals and how they interact, but you can ignore such things if you just want correctness. At least in software, that model works well, because the performance of most of the code we write doesn't matter - even in applications…

I wouldn't call it 'scary', myself, but it doesn't strike me as a particularly useful feature. In software, a single slow subroutine can simply take up more cycles. But in hardware, a slow path becomes your critical path, and you have a hard clock cycle requirement. (Sure, you can use multi-cycle paths and/or change clock speed, but those generally have to be adjusted manually/physically, and not all design situations will have that flexibility.)

Re: The Cx programming language

#40

Post by [deleted] »

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…

[deleted]
Post reply on HN