Design Con 2015
Breaking News
Blog

Cx: A New Language for Hardware Design & Verification

NO RATINGS
View Comments: Newest First | Oldest First | Threaded View
Page 1 / 3   >   >>
AZskibum
User Rank
CEO
Re: Interested, but Skeptical
AZskibum   10/14/2014 11:44:10 PM
NO RATINGS
It sounds like a higher level of abstration than RTL, but not as high as HLS. That could be quite handy for boosting desiger productivity, but only if the efficiency of the generated HDL, when synthesized into a netlist, is on par with what an RTL designer would normally write. Increasing designer productivity is a one axis of improvement, but it cannot come at a cost of larger die size, meaning higher product cost.

Matthieu Wipliez
User Rank
Manager
Re: Interested, but Skeptical
Matthieu Wipliez   10/11/2014 8:50:16 AM
NO RATINGS
Interesting - I looked at your code and while the management interface looks nice and clean

Thank you Martin!
I also looked at your CRC function [...]

Yeah... that's funny as this is the only piece of hardware that we imported, mostly because I actually had no clue how to design a CRC in hardware, so the code is just copy/paste from the output of the tool at easics.be

Your proposal for the design of a CRC hardware definitely sounds much better than the mess we have there! Cx has support for purely combinatorial functions with "for" loops (just as Verilog/VHDL), so we could just rewrite the function in that way. We have made no comparison, but I expect that in the end it's the same, synthesizers generally just unroll "for" loops and end up with the same sea of XOR gates as there is in the function.

Matthieu Wipliez
User Rank
Manager
Re: How applicable is it?
Matthieu Wipliez   10/11/2014 8:46:34 AM
NO RATINGS
@Alvie, thank you for your comments, I'll try to address them as best as I can :-)

1) Cx has C-like syntax, in the same sense that C++, C#, Java, or even Javascript all have C-like syntax. It does not mean these languages have the same syntax, they look alike (using curly braces, types, keywords all defined by C, and adding their own syntax and keywords on top of it).

2) you're absolutely right, although the key word in my comment was "at the moment", because we aim to provide the simulator pretty soon :-)

3) Regarding your questions:

a) incorporating IP: if you mean instantiate an existing IP core that you've already written in VHDL or Verilog, then you simply describe the Cx signature for that IP, and you can use it in the rest of your Cx code.

b) what hard IP blocks are you looking for? We already provide common RAM types (single, pseudo dual, true dual), synchronizers, FIFOs in VHDL and Verilog. And you're free to describe your own RTL blocks and instantiate them, or if you feel that a component is missing, just tell us and we'll decide how to include it.

c) actually you can choose whether a task will be synchronous or asynchronous, whether reset will be asynchronous or synchronous, and whether it is active high or low, this kind of thing. Again, if there is something missing, we can add it to the tool if we agree that this will benefit other designers.

d) I've never used these, what is the use case for timing checks? We have support for properties on input ports, like p.available() that is true when data is available on that port, is it something like this that you're looking for?

In general, we try to keep the number of features small, but sufficient for 90% of designs. We avoid adding too many features so the language can remain simple and usable, so there's always a trade-off and discussions regarding what should be added or not.

Alvie
User Rank
Blogger
How applicable is it?
Alvie   10/10/2014 5:42:02 PM
NO RATINGS
@Matthieu. I just went some of your examples, and:


You named this like "Cx", succesor of "C~", but all I see is a pretty much Java syntax, completely unrelated to "C" (I don't know about C#, don't want to, perhaps it has the same/similar syntax?).


Second, and more important, the only advantage I see of using higher level languages to describe hardware is the ability of simulating them - and you have no means to, as I understood from your comments.


So, although it may be interesting in the future, there's no actual real-life applicability of this. Correct me if I am wrong, but there looks like there is also no means of:
 a) Incorporate IP. b) Ensure inference of hard-IP blocks/common blocks. c) No low-level control of more tricky hardware aspects (like async/sync resets/sets) d) No Timing/event checks [like VHDL's 'event, 'stable, so on].


Again, I just read some examples on github. Good thing is they are pretty much understandable, but they tell me nothing about how the detailed implementation will go.

 

KarlS01
User Rank
Manager
Re: Interested, but Skeptical
KarlS01   10/10/2014 1:26:03 PM
NO RATINGS
@Matthieu:  Sorry I asked.

Matthieu Wipliez
User Rank
Manager
Re: Interested, but Skeptical
Matthieu Wipliez   10/10/2014 10:07:59 AM
NO RATINGS
@Matthieu: Within the last month there was an article here "M-Soft Plugs FPGA into Data Center". They concluded that tools are too slow and elected to implement programmable blocks and just change memory content rather than compile HDL. ImpulseC found that compile times were an issue also for accelerators. By generating HDL, won't Cx have the same issue since compile is still necessary?

@KarlS01 yes I've read that article, and I've commented on it too, basically saying that it was a pity that they had to resort to that kind of solution because of tools' limitations :-/

That is correct that we generate HDL from Cx, but compile times are negligible. Our tool supports incremental building, so you only re-generate what has changed, not the rest. And the HDL code generation itself is very fast, virtually instantaneous for most tasks.

Sadly, at the moment you still have to generate HDL to simulate your Cx code. But in the next version, we will provide a standalone simulator for Cx code that will avoid the need of generating HDL for verification. Then, the only time when you will generate HDL will be when you want to do the actual implementation on FPGA (or if you're designing ASIC, when you want to ship IP).

Martin Thompson
User Rank
Rookie
Re: Interested, but Skeptical
Martin Thompson   10/10/2014 6:24:22 AM
NO RATINGS
Interesting - I looked at your code and while the management interface looks nice and clean,  I also looked at your CRC function in https://github.com/synflow/ethernet-mac/blob/master/MAC/src/com/synflow/net/mac/MacPack.cf ... Very softwarey!  I'd be interested to see what the back-end tools make of that and whether they optimise it to the same as the (more natural hardware) unrolled shift-and-XOR loop.  I think in this case that the latter would certainly be shorter and easier to read, and might result in better hardware usage.  Have you compared them?

KarlS01
User Rank
Manager
Re: Interested, but Skeptical
KarlS01   10/9/2014 9:12:04 AM
NO RATINGS
@Matthieu:  Within the last month there was an article here "M-Soft Plugs FPGA into Data Center".  They concluded that tools are too slow and elected to implement programmable blocks and just change memory content rather than compile HDL.  ImpulseC found that compile times were an issue also for accelerators.

By generating HDL, won't Cx have the same issue since compile is still necessary?

Matthieu Wipliez
User Rank
Manager
Re: Great Job!
Matthieu Wipliez   10/9/2014 5:37:36 AM
NO RATINGS
Thanks @Tobias! You're welcome to use the tool if you want to test how well the generated code can be transformed by your tools at EDAptix. Cheers!

Matthieu Wipliez
User Rank
Manager
Re: Interested, but Skeptical
Matthieu Wipliez   10/9/2014 5:32:26 AM
NO RATINGS
What if we used C syntax to describe the control logic and executed the statements directly in hardware? (not just loops) Elimination of the compiler optimization and unpredictability of CPUs and memory systems should help.

@KarlS01 you've just described Cx in a nutshell :-) We've designed an Ethernet MAC in Cx, and as part of this design, we need to configure a PHY to set up auto-negotiation, determine the speed that has been negotiated, and wait for the link to be up. Now traditionally, this is done in software, and in hardware you just have the MII bus implementation (see our implementation in Cx).

We did not have a processor, and did not want to have one, so we implemented the PHY configuration in hardare. You can see the code on Github here. The code will be improved once we add support for "do ... while" loops and allow "return" in all functions (currently it only works for combinational functions). Still, I think it looks pretty good! Remember that this is a piece of hardware, described in a way that software guys like @TonyTib and myself can read and write.

Page 1 / 3   >   >>
Radio
NEXT UPCOMING BROADCAST
EE Times Senior Technical Editor Martin Rowe will interview EMC engineer Kenneth Wyatt.
Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Flash Poll