It is amazing, at times, how much disinformation there appears to be. Sometimes this disinformation is created by the EDA companies themselves, because they are trying to smooth over deficiencies in their tools. Sometimes disinformation manifests itself just because of how the industry moves over time. And sometimes we run into disinformation issues simply because things are not obvious.
In order to address this problem, in this column I want to go back to something very fundamental, which is to look at the languages that are being used as the input to transaction-level synthesis. Later, I hope to progress to some more "meaty stuff" related to pipelines and scheduling.
As far as I am aware, C, C++, SystemC, Bluespec (both variants as discussed below), and Simulink (even a graphical language is a language) comprise the complete set of languages being used as the input to transaction-level synthesis on the market today. I want to start by first dealing with some issues surrounding the C, C++, SystemC spectrum, because there is a lot of confusion as to which is “higher level” than the other. The problem is that there are two ways to look at the issue, and these two ways will lead you to come to two different conclusions.
First, let's consider the diagram shown above. This says that the C language is quite capable of defining everything necessary at the block level, but descriptions written in C are not highly reusable or adaptable to different usage scenarios.
Next we have C++, which has become the language of choice for most software developers, not because it has any capabilities that are not present in C, but because it makes things so much easier. It enhances productivity and enhances reuse.
Now consider SystemC. This has nothing that cannot be described in C++; in fact, SystemC is nothing more than a C++ library. It does not extend the language in any way, and thus there is nothing that can be written in SystemC that could not be written in C++ or C. What SystemC adds are things that extend C++’s utility for defining things found in the hardware world in ways that make it more productive to use.
SystemC also provides other capabilities that enable it to fit into a hardware development flow. That means that SystemC is capable of defining system-level tasks -- composed of both hardware and software -- better than C++, and it is definitely better at describing hardware-only tasks. So, I ask you at this stage, which language is at a higher level of abstraction? It would appear that SystemC can more usefully be used for describing system-level behavior, whereas C is less suitable.
I would tend to call/classify this style of design as one method/piece of high level system design as opposed to hardware/digital design.
hardware/digital design is much, much more than a language (HDL or otherwise).
can a software engineer learn hardware/digital design? absolutely. however, using a HLS tool is NOT the same learning digital design.
and a hardware engineer can certainly learn software design.
and hardware and software engineers who step into system design make some of the best system engineers I've had the pleasure to work with.
my main point is that once a designer is no longer worrying about clocks or timing, I feel they are wearing a system engineer hat, not a hardware engineer hat. THAT hardware awareness is what I view as the line in the sand.
an experienced digital designer (possibly also concurrently experienced in SW) could certainly choose to use an HLS for a given (piece of a ) design. now while I may not like/agree with this, in my view, they at least are well aware of the implications/hurdles/issues/etc that might come up when using a "generated" design module, as opposed to a non-hardware engineer (or unexperienced) doing the same thing.
jandecaluwe 9/17/2012 12:33:10 PM User Rank Blogger
Re: SW/HW function split question.
"designing at a level of abstraction that removes "timing" awareness/considerations from the design process can hardly be called hardware design anymore."
I see. No matter how great this technology may work, it cannot be called hardware design. No matter how productive the folks that practice it, they are just untrue, unreal hardware designers.
@Brian: Application code and hardware functions have completely different objectives. There has always been an interface between them, such as access methods and device drivers. The device drivers communicate with the hardware using still another interface(MMIO) Application languages do not directly access hardware -- they use function calls to an operating system.
I do not believe that the "tool" developers can bridge the gap from application to FPGA configuration.
The application as well as the hardware has to be modelled to get to the system level and if the HW guy has to write the application, hell may freeze over before even one of them comes along.
"Abstraction" seems to be the magic bullet, but is so abstract that it cann ot be defined.
Whether or not you like it, "when clock rises" os a physical event that is extremely important/religion, real, and must be dealt with. Do I believe the language/tool developers are up to the task -- NO. Just after they figure out multi-core/parallel programming, maybe.
Hardware design deals/depends on parallel operation and the people writing TLS probably mainly think sequential.
Sure, I am missing things but the TLS zealots may be missing the boat.
designing at a level of abstraction that removes "timing" awareness/considerations from the design process can hardly be called hardware design anymore.
Brian Bailey 9/17/2012 11:31:30 AM User Rank Blogger
Re: SW/HW function split question.
Language, in this respect, is almost a religious issue. I have never said that I believe that C, C++, SystemC is a good choice of language for defining hardware but it is the direction that most vendors have gone done. Bluespec strongly believes that they have a better language that is inherently concurrent as opposed to a sequential language. SystemC could not be described as a software language unless you want to define fine level concurrency in software – something unlikely to happen because the communications speeds are too slow.
So, there is a valid change in abstraction here in that timing is being abstracted. In this respect it is the same and as the gate to RTL transition and at that time I also remember people saying it was not the same as transistor to gate because it was graphics to text language.
it makes no sense for a real, true, HW engineer to use a SW language to design HW. it is not an "abstraction" thing either. and comparing gate/schematic level transition to RTL is apples and oranges when compared against RTL to a SW language.
HW design by it's very nature MUSTbe HW aware at all times.
HW engineering is improving and evolving, yes (devices, HDLs, etc). However, SW engineering is trying to change and replace HW engineering with push button tools. problem is, HW design is much more than just VHDL and Verilog.
Brian Bailey 9/17/2012 10:43:09 AM User Rank Blogger
Re: SW/HW function split question.
Karl - I think that what you are missing is that the HW engineering is changing. Just like they did with the last abstraction change. Yes - there were gate level, schematic HW guys who were great at their job, but they could handle the change to RTL. They were basically moved into management positions or let go. The new generation of HW engineers had a slightly different skill set and no many of them would not have been able to create good designs at the gate level.
So, it is still HW engineers creating the new abstract models - just slightly different skill set than ones who created RTL. Many RTL engineers will not be able to drop the use of "when clock rises" and so will not be able to make the transition.
@Brian: The cases you just mentioned are interesting and may not need to go all the way down to configuring the FPGA. The idea is to have a series/cascaded ALUs instead of fixed function like adder - multiply.
Each stage might do add, multiply, subtract, etc with the operator for each alu depending on the algorithm. The operators could be kept in local memory blocks so the algorithm would be controlled by memory and writing to the memory is all that is needed to change the algorithm.
Since multipliers are limited, there are no doubt lots of ways to efficiently share a few. Actually there are probably enough that sharing would not be necessary.
What a fun project if I were only an algorithm expert.
@Brian: If the class libray contains multiple classes with the same properties but different levels of behavior then a "system" can be created by instantiating classes of various levels and so long as there is a class that has been created at the senthesized level that can be the TLS output. This would explain why it has taken so many years to create the library -- it is open ended and three function levels of each block are required.
The "abstraction" is that the user instantiates high function level classes, but the "synthesized" output is compiled from the previously synthesized "timed" level.
Fits the OOP structure very well and the class library is essentially a collection of IP blocks that can be wired together in a smilar way LUTs and Flops are wired on an FPGA. The user is unaware that the "compilation" took place just as the OOP programmer is unaware that millions of cpu instructions may result from compilation of the source code.
Next question: Is the TLS output HDL/RTL that goes through the normal tool flow?
I believe 3D ICs are basically the replacement for the PCB. In the near future, the PCB will become nothing other than a holder with the ability to add connectors and perhaps a few components that cannot be economically integrated within the chip package.
Is the recent news that Altera will be using the Intel 14nm node with TriGate technology for their future FPGAs significant, or is it just industry noise?
Recent developments in high-level synthesis (HLS) and IP Integration technology mean that software developers can more easily create hardware to accelerate their applications.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
