[ANN] HercuLeS high-level synthesis tool

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:

formatting link

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.

Reply to
Nikolaos Kavvadias
Loading thread data ...

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

Reply to
Quadibloc

Hi John

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.

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:

formatting link
Paper:
formatting link

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

Reply to
Nikolaos Kavvadias

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

Reply to
Quadibloc

Hi John

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

Reply to
Nikolaos Kavvadias

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

Reply to
Quadibloc

Hi quadibloc

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:

formatting link

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

Reply to
Nikolaos Kavvadias

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.