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.
[ANN] HercuLeS high-level synthesis tool
Started by ●July 11, 2011
Reply by ●July 11, 20112011-07-11
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 by ●July 12, 20112011-07-12
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
Reply by ●July 12, 20112011-07-12
On Jul 12, 5:41=A0am, 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
Reply by ●July 12, 20112011-07-12
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
Reply by ●July 12, 20112011-07-12
On Jul 12, 10:23=A0am, 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
Reply by ●July 12, 20112011-07-12
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
Reply by ●July 13, 20112011-07-13
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.
Reply by ●July 13, 20112011-07-13
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 :)
Reply by ●July 13, 20112011-07-13
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
