The VHDL defines a reset and reset conditions, actually uses a clock, and many other things that the Cx code is leaving out.
The Cx programming language
21–30 of 49 posts
Re: The Cx programming language
#22I 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…
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 FPGAs to designing devices for the IoT. And I think this is something pretty unique :-)
Re: The Cx programming language
#23The VHDL defines a reset and reset conditions, actually uses a clock, and many other things that the Cx code is leaving out.
Exactly! Isn't that a breeze? Reset and clock are implicit by default, but you can always override them (change name, set reset synchronous, etc.)
Re: The Cx programming language
#24I 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…
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 reset_n or posedge clock) begin
if (~reset_n) begin
count Can you point exactly what do you think it's wrong with this syntax? And don't compare it with a while() cycle in C, because this is a totally different thing. I'm not saying that this is the perfect way of doing things but there are good reasons why Verilog ended up this way.
I'm really scared with this whole "Hardware design for software developers" thing. Hardware design is very complex and if you aren't careful with what you write, you might end with problems like: CDC, synthesis tools mistaking flip-flops with latches, problems with the insertion of scan chain, and so on.
And by the way, where do you define your clocks in Cx?
Re: The Cx programming language
#25This 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 - perfect time to be kind of familiar but not enough. This is currently handled by integrating perl-like syntax into the HDL. Then it gets "pre-processed" into the proper values in place. It sounds clumsy , but it may be how the machine you're using to read this was made.
A second important use case is integrating writing test code with the source code. As the register, path widths, number of cycles, etc., change, the verification cases have to track. If you could find a way to simplify that, companies would pay a LOT for it.
Another major problem becomes "ifdef-hell" in which sometimes dozens of hierarchical #ifdefs are used to compile and configure HDL code. it's maddening, hence the pre-processor approach.
So, in summary, it's not the clumsy syntax of HDLs that slows progress, it's the ecosystem in which the HDLs are used.
Re: The Cx programming language
#26I 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.
Re: The Cx programming language
#27The VHDL defines a reset and reset conditions, actually uses a clock, and many other things that the Cx code is leaving out.
Exactly! Isn't that a breeze? Reset and clock are implicit by default, but you can always override them (change name, set reset synchronous, etc.)
Very cool, I was wondering where the clock was.
Re: The Cx programming language
#28I 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…
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?
Re: The Cx programming language
#29Advice 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 page is so simple. The equivalent VHDL and Verilog is also relatively simple. A simple example is good, and a comparison is good, but just presenting the differences is not enough. Stress what someone coding in Cx does not have to think about. In other words, what are the abstractions in Cx?
Consider what the equivalent page for C versus assembly would look like for a function that computes some simple arithmetic. Some people may say, "Oh, sure, the assembly has a few more lines because you need to push and pop parameters from the stack, but that's no big deal." And it's not - for one function. What's the big deal is that there are entire concepts - saving existing registers, pushing parameters onto the stack, register management - that C programmers don't need to think about. (Most of the time.)
The code you link to elsewhere in this thread hints to me that there are indeed significant abstractions behind Cx, that make it more than just an alternative syntax to Verilog and VHDL. See: https://github.com/synflow/sha-256/blob/master/SHA256/src/co...
Re: The Cx programming language
#30It'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 their cycle accurate simulator and can automate my test suites I'd be thrilled.