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 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...
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 :-)
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 <= DATA_BITS;
elsif (clk'event and clk = '1') then
case (state)
when DATA_BITS =>
if (data_valid = '1') then
if (count < 8) then
count <= count + 1;
else
state <= STOP_BIT;
count <= 0;
end if;
end if;
when STOP_BITS =>
if (data_valid = '1') then
if (count < num_stop_bits) then
count <= count + 1;
else
state <= DATA_BITS;
count <= 0;
end if;
end if;
end case
end if;
end process i_sm;
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 about VHDL/Verilog is that its easy to tell the exact port names, what the clk is, the name and type of reset, etc which is useful information for putting the block in the context of an overall system.
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.
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?
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/
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.
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.
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 - 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.
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!
Hard to tell from the site if the language is proprietary or if it's just the IDE they're flogging.
I have to say "what this needs is another proprietary component in the toolchain" is not something I've ever thought when working with FPGAs. Quite the contrary.
Hi I'm a co-founder of Synflow and author of the website. Sorry if this is not clear about what is open source or not.
To answer your question the language, compiler, and IDE are open source: https://github.com/synflow/ngDesign
We're using Xtext to develop the language.
The open source version includes everything you need to design with Cx and then generate VHDL code. We also have a proprietary version that adds a Verilog code generator, exporters to third-party tools, and a C-based simulator.
I agree that a lot of tools for FPGAs are much too proprietary, hopefully we're contributing to changing that. I wish we could make it all open source but we also have to make a living :-)
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 :-)
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.
In the example, shouldn't it be checking that stop bits are ones?
Does available() extract and discard the bit if one's available? Or does it act a flag that's reset upon reading? Why doesn't loop() extract stop bits then?
I mean, this is clearly aimed at a technical audience with embedded background, so the code should really match the specs, even if it's just an illustartive example :)
Hi I'm the person who wrote this example. In fact you don't need to check that stop bits are ones because one is the default: when nothing is being written on the line, it is high all the time. This is why it's just a matter of convention (number of stop bits) rather than a specific pattern.
EDIT: available checks that data is available on a port. If the test is true, then you can read from the port; if you don't read from the port, this is equivalent to an implicit read and data is discarded.
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.
You might be interested by my implementation of SHA-256 in Cx available on Github: https://github.com/synflow/sha-256
It is a toy example (I haven't implemented the pre-processing step), with an architecture that offers a good trade-off in terms of performance / area, so it's probably not the ideal implementation if you want a very highly-optimized ASIC, but it's still a good starting point.
[+] [-] scott_s|11 years ago|reply
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...
[+] [-] MootWoop|11 years ago|reply
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 :-)
[+] [-] scott_wilson46|11 years ago|reply
[+] [-] nsiret|11 years ago|reply
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.
[+] [-] FraaJad|11 years ago|reply
[+] [-] csirac2|11 years ago|reply
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?
[+] [-] MootWoop|11 years ago|reply
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/
[+] [-] daphreak|11 years ago|reply
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.
[+] [-] davidb_|11 years ago|reply
[+] [-] txomon|11 years ago|reply
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.
[+] [-] MootWoop|11 years ago|reply
[+] [-] nsiret|11 years ago|reply
[+] [-] txomon|11 years ago|reply
[+] [-] chillingeffect|11 years ago|reply
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.
[+] [-] MootWoop|11 years ago|reply
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!
[+] [-] niklasni1|11 years ago|reply
I have to say "what this needs is another proprietary component in the toolchain" is not something I've ever thought when working with FPGAs. Quite the contrary.
[+] [-] MootWoop|11 years ago|reply
To answer your question the language, compiler, and IDE are open source: https://github.com/synflow/ngDesign We're using Xtext to develop the language. The open source version includes everything you need to design with Cx and then generate VHDL code. We also have a proprietary version that adds a Verilog code generator, exporters to third-party tools, and a C-based simulator.
I agree that a lot of tools for FPGAs are much too proprietary, hopefully we're contributing to changing that. I wish we could make it all open source but we also have to make a living :-)
[+] [-] gothenburg|11 years ago|reply
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?
[+] [-] MootWoop|11 years ago|reply
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 :-)
[+] [-] correnos|11 years ago|reply
[+] [-] eps|11 years ago|reply
Does available() extract and discard the bit if one's available? Or does it act a flag that's reset upon reading? Why doesn't loop() extract stop bits then?
I mean, this is clearly aimed at a technical audience with embedded background, so the code should really match the specs, even if it's just an illustartive example :)
[+] [-] MootWoop|11 years ago|reply
EDIT: available checks that data is available on a port. If the test is true, then you can read from the port; if you don't read from the port, this is equivalent to an implicit read and data is discarded.
[+] [-] runeks|11 years ago|reply
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.
[+] [-] MootWoop|11 years ago|reply
You might be interested by my implementation of SHA-256 in Cx available on Github: https://github.com/synflow/sha-256 It is a toy example (I haven't implemented the pre-processing step), with an architecture that offers a good trade-off in terms of performance / area, so it's probably not the ideal implementation if you want a very highly-optimized ASIC, but it's still a good starting point.
[+] [-] bpg_92|11 years ago|reply
[+] [-] Quanticles|11 years ago|reply
[+] [-] MootWoop|11 years ago|reply