Semiwiki on LinkedIn Semiwiki on Facebook Semiwiki on Twitter Register / Log in 
Array
(
    [content] => 
    [params] => Array
        (
            [0] => /forum/threads/aldec-enters-hls-market-by-selling-cyberworkbench-from-nec.3093/
        )

    [addOns] => Array
        (
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2021770
            [XFI] => 1050270
        )

    [wordpress] => /var/www/html
)

Aldec Enters HLS Market by Selling CyberWorkBench from NEC

Daniel Payne

Daniel Payne

Moderator
At DAC I met with engineers from both Aldec and NEC, then blogged about HES for hardware prototyping and HLS with CyberWorkBench.

Today there was an announcement from Aldec that they will be selling the CyberWorkBench tool outside of Japan, Taiwan and China.

There are several HLS competitors now:



What is your favorite HLS tool and why?
 
Last edited:
Not voting on a favorite but as a supplemental, there is also Impulse Accelerated Technologies who are located not far from you, in Bellevue, WA!

Also, before anybody asks, the startup AutoESL was acquired by Xilinx and goes by the label Vivado HLS (small typo there, Daniel!).
 
Gary,
Thanks for the catch, I've updated Vivado HLS and added Impulse. There are several other HLS tools, but they are more hobbyist, academic and specialty oriented.
 
Most of these tools (including CyberWorkbench, aka CWB) do the same thing: HLS from C/C++/SystemC. The technology (HLS) is more than 20 years old, with the first papers appearing in the beginning of the 90's. Several of the tools out there are more than 10 years old, with CWB being the oldest (NEC claims it has been used to produce chips for more than 15 years)...

Maybe it is time to wonder if "traditional" HLS (HLS of C/C++/SystemC) is the right approach?

For instance, one of the key arguments behind using C to describe hardware is that this way there is only one description. Though, as the CWB Overview figure shows (see there: CyberWorkBench: Products | NEC), in the design of a whole system, there is a "C for software" description, and a "C for hardware" description which is given to CWB. It turns out "C for hardware" is actually very different from the "normal" C code written with software in mind.

This is why BlueSpec has created its own language, Bluespec SystemVerilog (BSV), and why we at Synflow have designed a C-based language dedicated for hardware. Maybe this is not HLS per se (in an interview the guys behind CWB say that BlueSpec does not do 'scheduling', whatever that means, so this is not really HLS :confused:). But at least these are generic approaches, that work and generate efficient hardware for any kind of design, which is a good advantage over traditional HLS :)
 
Last edited:
Hi, I just saw the comment "the guys behind CWB say that BlueSpec does not do 'scheduling', whatever that means, so this is not really HLS", and would like to respond (I'm Bluespec's CTO).


What they probably mean is this: C-based HLS solutions (including CWB) usually work on an intermediate form such as CDFGs (Control and Data Flow Graphs), and these are "scheduled" into clock cycles based on various constraints, using various heuristics (ASAP, ALAP, ...). And indeed they are right in saying that Bluespec does not do this.


But to say that, therefore, Bluespec is "not really HLS" is relying a bit on a self-serving circular definition. As far as the user is concerned, CDFG-based scheduling is a second-level detail; the first-order questions are, "Is the source language high level? Does it get synthesized to efficient hardware? How productive am I with this approach?". And on these more end-to-end metrics, we're happy to take on any C-based HLS tool.


Bluespec actually does extremely sophisticated scheduling, just in a form that is not done by other HLS tools. Bluespec's scheduling is based on concurrent atomic transactions, which none of the C-based HLS tools do, and which are, in our opinion, far more important and useful to the user. This kind of scheduling has been at the core of Bluespec technology from day 1 (more than 10 years ago).


In our view, the biggest question is really about the ability to specify architecture abstractly (and at many layers of abstraction). In HW design, algorithm and architecture are fused. An algorithm's quality is based on the cost model of its operations; the cost model is directly a consequence of architecture; and architecture itself is a design outcome (unlike SW design, where an architecture and its cost model is a fixed input).


Unfortunately, C/C++/SystemC are not well suited for describing architectures and their massive, fine-grain, heterogeneous parallelism and concurrency (these languages were designed for sequential von eumann architectures). Incidentally, this is one major reason behind a previous remark that "'C for hardware' is actually very different from the 'normal' C code written with software", it's because people struggle to fit C/C++ to this purpose. This is why Bluespec has chosen a very different computation model, atomic rewrite rules, which is much better suited for HW architectures and concurrency.


I'd be happy to go into more technical depth on any of these points.
 
That's a good question, Daniel :) We just have to get companies to try our product first!
We are having trouble finding people who are ready to change their design methods; it seems that many hardware designers (at least in French SMEs) are still happy being stuck with RTL... A few companies that we have met have been curious in the past about the mainstream HLS products (mainly Catapult-C and some C-to-Silicon), but in the end they were disappointed with the area/performance ratio.
That said, we have already a few working designs, I implemented a high-performance AES 128-bit cipher (11 cycles latency, comparable to commercial AES IP), a simple UART, we implemented with my associate an Ethernet 10/100/1000 MAC (tested on FPGA), and we had a trainee who worked on a turbo encoder and FFT (+ IFFT/DCT based on the FFT).

Thank you Rishiyur for these detailed explanations! I'm glad you took the time to register and post here.

We at Synflow take yet another approach: our input is a (graphical representation of) hierarchical network of parallel tasks; the tasks themselves are written in a dedicated language called C~ (a subset of C with hardware constructs). Scheduling is done by the user in C~, as the language is cycle-accurate. The idea here is that our input, compared to RTL, is like C to assembly: it's higher level, more concise, more understandable, and there is a direct, predictable mapping from C~ to RTL.
This mapping is based on the Dataflow Process Network model (i.e. firing rules with scheduling conditions), but a description is not a DPN. The reason is simple: an implementation of a DPN model requires a handshake-style FIFO for every port, which did not seem very practical...

In the end we are probably lower-level than you, but I think the two approaches are complementary.

Anyway, I know that designers have successfully designed several processors with Bluespec, so I'd like to design a processor with Synflow Studio as a 'user case' and describe the result when it's done :)
I was thinking of the RISC-V instruction set (modern, unencumbered, true RISC)
(see http://inst.eecs.berkeley.edu/~cs152/sp12/handouts/riscv-spec.pdf for the details)
 
Hello All,

It is good to see discussion around HLS, and good to know the variety of tools available for HLS.

From the discussions, it appears that few tool vendors have defined their own language.

It may not be a good idea that every HLS tool vendor define their own language. Better will be that industry move towards some common language that is widely accepted.

There are some standardization efforts to define the Synthesizable subset of SystemC, and there are several tools available today that supports this standard. Looking at the news in recent past it seems adoption of these tools in increasing in the industry, perhaps the technology has become mature enough.

I have few queries for Nikhil :


  1. If anyone designs using BSV, will it work with Bluespec tools only, or are there other HLS tool vendors also who support it (BSV) models ?

  2. If it is better language when compared to SystemC, it will be good if Bluespec can work with the Industry consortium to make it a standard.


Thanks in advance.
 
Hi pvs,

I agree that it would be best if all tool vendors used the same language, instead of defining their own. The problem is, of course, that SystemC is not a language, but more importantly, it is not the solution for hardware design. Having a synthesizable subset should be a warning sign that SystemC is not really better than VHDL or Verilog for hardware design (personally I think it is even worse, because at least VHDL and Verilog are languages on their own).

You talk about the technology that 'has become mature enough', do you mean HLS? HLS of C/C++/SystemC is certainly mature, but that does not necessarily mean interesting (except in a few specific cases, as Kevin Morris pointed out in its article).

At Synflow we have created another language C~ which is a C-like language dedicated to hardware. It is somewhat complementary to BSV, certainly not as powerful in terms of elaboration and typing, but probably more intuitive in terms of syntax and semantics.

Finally, on the 'standards' issue. Will a language not being a standard prevent you from using it?
 
You must log in or register to reply here.
Back
Top