[ANN] HercuLeS high-level synthesis tool

[Nikolaos Kavvadias]

Hi everyone

i'm pleased to announce that after two years (and about 2000 man-
hours), the HercuLeS high-level synthesis tool is ready for non-
trivial work. HercuLeS allows you to synthesize ANSI C code (certain
rules apply) to RTL VHDL.

HercuLeS is named after the homonymous constellation and not after the
demigod. You can find information on HercuLeS here:
http://www.nkavvadias.com/hercules/index.html

Some of its features:
1. Integer and fixed-point (VHDL-2008) arithmetic of arbitrary lengths
2. It is able to synthesize VHDL from code spanning across several C
functions
3. Support for both the Synopsys "de-facto standard" libraries and the
official IEEE standard libraries
4. Support of synchronous read ROM and RAM memories (directly mapped
to FPGA block RAMs)
5. Functions can pass single-dimensional array arguments
6. Support of streaming outputs (producing a sample at a time)

You can either code your input in ANSI C or in a bit-accurate typed-
assembly language called NAC (N-Address Code). Then, your input is
converted to a series of CDFGs (Control/Data Flow Graphs), expressed
as Graphviz graphs with user-defined attributes, which again are
translated to VHDL code adhering to the FSMD (Finite-State Machine
with Datapath) paradigm.

I would appreciate if you had a look at the sample files available at
the website. They illustrate complete examples of automatically
synthesized algorithms such as Bresenham's line drawing algorithm, and
the Sieve of Eratosthenes. Overall, eight complete examples can be
found at the HercuLeS website.

There will be regular updates on the HercuLeS webpage (every 1-1.5
months). The October update, scheduled for 2011/10/11, will allow
access to HercuLeS via a web interface! But first I would appreciate
feedback on whatever related to the HercuLeS webpage.

Best regards,
Nikolaos Kavvadias
Lecturer, Research Scientist, Hardware developer,
Ph.D., M.Sc., B.Sc.

 

[Quadibloc]

Is the limitation to *non-programmable* hardware merely a technical
limitation, or is it a license restriction?

For example, could one use it to design a microprocessor by simply
excluding the RAM from the C program, and then adding a bit of hand-
written RTL VHDL to the output to add in the programmability?

John Savard

 

[Nikolaos Kavvadias]

Hi John

Is the limitation to *non-programmable* hardware merely a technical
limitation, or is it a license restriction?

I would say that is only a matter of engineering to interface the
produced hardware by HercuLeS to programmable platforms as
coprocessors. This should be the straightforward way of applying this
approach to a programmable context.

Currently, I haven't developed any wrappers for the produced hardware
to interface e.g. to popular FPGA soft-cores.

For example, could one use it to design a microprocessor by simply
excluding the RAM from the C program, and then adding a bit of hand-
written RTL VHDL to the output to add in the programmability?

Ultimately, the overall infrastructure could be used for producing an
application-specific processor from scratch. This would require a
"skeleton" processor to whom the added functionalities should be
attached. A previous effort of mine was the ByoRISC processor which is
a configurable ASIP:
Demo simulator: http://www.nkavvadias.com/misc/byorisc-demo-0.0.1.zip
Paper: http://www.nkavvadias.com/publications/kavvadias_vlsisoc08.pdf

This approach also has some serious problems, mainly the automatic
generation of complete software development toolset, especially the
regarding the compiler and the libraries. Probably I wouldn't take
this approach.

So HercuLeS infrastructure can take account of these issues (of non-
programmability) so that targeting third-party programmable platforms
does not meet serious technical limitations.

Best regards,
Nikolaos Kavvadias

 

[Quadibloc]

On Jul 12, 5:41 am, Nikolaos Kavvadias <nikolaos.kavvad...@gmail.com>
wrote:

Currently, I haven't developed any wrappers for the produced hardware
to interface e.g. to popular FPGA soft-cores.

Ah. But that's a different question. I hadn't expected it to do
_that_, because there already exists software to take VHDL or Verilog,
and compile it into a program for an FPGA.

My concern was for the thing described by the C code being read, and
translated to VHDL, describing a programmable object instead of a non-
programmable one.

John Savard

 

[Nikolaos Kavvadias]

Hi John

My concern was for the thing described by the C code being read, and
translated to VHDL, describing a programmable object instead of a non-
programmable one.

a ByoRISC is a programmable object (since it is a soft-core
microprocessor), but then mapping a NAC program to its assembly is a
trivial backend matter. You seem to refer to something else.

Do you have anything specific in mind when you refer to a
"programmable object"?

Best regards,
Nikolaos Kavvadias

 

[Quadibloc]

On Jul 12, 10:23 am, Nikolaos Kavvadias <nikolaos.kavvad...@gmail.com>
wrote:

Do you have anything specific in mind when you refer to a
"programmable object"?

I was wondering if, despite the limitation you cited, whether your
tool might still be useful in generating VHDL for a microprocessor,
since many major components of a microprocessor are not programmable
in themselves.

John Savard

 

[Nikolaos Kavvadias]

Hi quadibloc

I was wondering if, despite the limitation you cited, whether your
tool might still be useful in generating VHDL for a microprocessor,
since many major components of a microprocessor are not programmable
in themselves.

In principle, yes! The hardware that is now produced follows the FSMD
(Finite-State Machine with Datapath) model of computation.

It is known that there is a strong relation between FSMD and
implementing a microprocessor ISA. A relevant work that clearly
discusses the equivalence of these two MoCs is:
"A Unified Formal Model of ISA and FSMD"
with direct link here:
http://www.cs.york.ac.uk/rts/docs/SIGDA-Compendium-1994-2004/papers/1999/codes99/pdffiles/5_1.pdf

sets this relation in a formal basis.

However, the FSMD and ISA models have different structures (as also
noted in the above work). For deriving an ISA (microprocessor) model
from a N-Address Code program the following would be required:

1) Identify the distinct operations required to be supported by the
microprocessor by static analysis of the NAC program.
2) Implement computational "states" for each one of the operations
(this assumes naive, sequential scheduling of work). One could do
better in terms of performance, by grouping more operations in a
single state and calling this group an "instruction".
3) Map the NAC program to e.g. a microprogram store.
4) You need a skeleton microprocessor that allows modifications, e.g.
removing and adding computational states and their respective
functional units at design compile time.

That is all that is required. AFAICS the current infrastructure would
not demand extensive changes.

Best regards,
Nikolaos Kavvadias

 

[Nicholas Collin Paul de G]

Dr. Kavvadias <nikolaos.kavvadias@gmail.com> sent on July 11th, 2011:
|----------------------------------------------------------|
|"[..] |
| |
|You can [..] code your input [..] in a bit-accurate typed-|
|assembly language called NAC (N-Address Code). [..] |
|[..] |
| |
|[..]" |
|----------------------------------------------------------|


Ah, strongly typed assembly languages. One does not see many of
those.

 

[Tom Gardner]

Nicholas Collin Paul de GlouceĹżter wrote:

Dr. Kavvadias<nikolaos.kavvadias@gmail.com> sent on July 11th, 2011:
|----------------------------------------------------------|
|"[..] |
| |
|You can [..] code your input [..] in a bit-accurate typed-|
|assembly language called NAC (N-Address Code). [..] |
|[..] |
| |
|[..]" |
|----------------------------------------------------------|


Ah, strongly typed assembly languages. One does not see many of
those.

You do if you are assembling hardware

 

[Nikolaos Kavvadias]

Hi

Ah, strongly typed assembly languages. One does not see many of
those.

You do if you are assembling hardware

Yes, bit-accurate, strongly-typed (generic) assembly languages is the
way to go as an intermediate representation especially for hardware
compilation. It provides some other benefits for the infrastructure in
the long term.

I decided to develop and extend an extremely lightweight typed-
assembly language (called NAC), to keep all the infrastructure light
and manageable by a single person. It certainly is manageable at the
present time.

Best regards,
Nikolaos Kavvadias