[Iverilog-devel] Draft GSoC proposal

[Nick G. <nm...@yo...>]

Hi,

I've written a draft SoC proposal. Would you mind having a quick look at it before I submit it? 
Feedback appreciated :-).

Thanks a lot,
Nick

--------------


== Abstract ==

I propose to build a VHDL code generator for Icarus Verilog. This is based on a
project idea from [1]. A VHDL code generator will allow Icarus Verilog to be
used as a Verilog to VHDL translator. Benefits include:
* Verilog libraries and designs can be used in VHDL-only projects without the
   expense of manually rewriting the code.
* Systems developed with Icarus Verilog can be used with tools that only accept
   VHDL.
There is clearly demand for this sort of functionality as at least one
proprietary tool already exists [2].

The VHDL produced will conform to a standard (probably VHDL93 as this is most
widely available) and not use any proprietary extensions, so the output is
compatible with as many tools as possible.

I would aim for as much coverage of the Verilog language as possible. However,
some features such as VPI will probably be impossible to support in VHDL.

Ideally, the VHDL produced should be pretty-printed and human-readable. This
will allow it to be maintained and modified independently of the original
Verilog.

Additionally, I will modify the build system/wrapper program to insert the git
commit id or tag in the -V output. (This is the final project from [1].)

== Deliverables ==

* A new VHDL code generator that can be run with -tvhdl (implemented in C, with
   sources under tgt-vhdl in the git repository). The code generator will
   produce VHDL modules corresponding to the Verilog abstract syntax passed to
   the code generator. When simulated or synthesised, the VHDL should behave
   identically (wherever possible) to the Verilog it was generated from.
* Updates to configuration files and build scripts to support the new code
   generator.
* Any VHDL packages required to support the generated code.
* Set of unit tests and application-level tests to demonstrate the correct
   operation of the code generator.
* Updates to the documentation and man page to document the new code generator.
* Changes to the build system to support displaying the git commit id (or
   corresponding tag) in the -V output.

== Plan ==

I will initially work on the git commit id project, as looking at the build
system is a good way to learn about the code base. I do not expect this to take
too long, but I will need to learn a bit more about git first (I have some
limited experience already).

Icarus Verilog has a well-defined loadable target API that insulates code
generators from the rest of the compiler: this means the project will be
relatively self-contained.

For many Verilog constructs there is an obvious mapping to VHDL (e.g. initial and
always -> processes) and many of the operators and data types are
similar. However, some Verilog features are not found in VHDL and will require a
more complex translation (e.g. the Verilog reduction operators would need to be
implemented by a loop in VHDL), and some features might be quite difficult to
translate (e.g. the Verilog fork/join construct will require some thought). In
order to make progress and produce useful code at regular intervals, I will
work incrementally, starting with the easy language features and progressing to
the more complex ones. I expect most of the core Verilog features to have a
quite natural and straightforward translation, particularly those in the
synthesisable subset.

Only a subset of Verilog (and VHDL) is synthesisable. The synthesisable subsets
of both languages contain simpler constructions than found in the complete
language, so it would make sense to work on this first. I would aim to have a
reasonably complete translation of synthesisable Verilog by the midterm
evaluation. To evaluate this, iverilog would be run on `real' synthesisable
Verilog code (for example, the AES core at [3]) producing VHDL, which should
synthesise in a tool such as Xilinx XST.

For the second half of the project, I would concentrate on the simulation-only
constructs (which I expect will be somewhat harder to translate). This would be
successful if a Verilog testbench could be translated to a valid VHDL testbench
(probably using the same OpenCores project to evaluate).

Throughout the project I will develop a set of automated tests (using a VHDL
simulator) to verify the output generated is correct.

== Availability ==

I have university commitments until the end of May, but otherwise I am free to
work on SoC throughout the summer and into September. However, I am moving house
at the end of June which may cause some disruption and intermittent internet
access for a few weeks (although I should be able to keep working on the project
during this period).

I will treat the project as a full time job: I expect to spend approximately 37
hours a week working on it.

== About me ==

I'm in the final year of a 4-year Computer Systems and Software Engineering
degree at the University of York (UK). After graduating, I'm hoping to study for
a PhD in real-time systems.

Relevant industrial experience:
* July 2005 - August 2006: Placement year at IBM United Kingdom, Hursley
   -> Developed test automation frameworks for IBM middleware products.
* Summer 2007: Internship in Dept. of Comp. Sci. at University of York
   -> Worked in the AI group on information retrieval systems.

Relevant skills:
* Good background in digital electronics, embedded systems, and FPGA design in
   particular.
* Lots of experience developing FPGA applications in VHDL (and Handel-C).
* Basic knowledge of Verilog (although I have time to improve this if I am
   accepted for SoC).
* Lots of experience in C/C++ programming
* Good knowledge of Perl, shell script, AWK, etc.
* I have some experience managing build systems with GNU autotools.
* Basic working knowledge of git.

== References ==

[1] http://iverilog.wikia.com/wiki/Projects
[2] http://www.ascinc.com/products/verilog2vhdl/
[3] http://www.opencores.org/projects.cgi/web/aes_core/overview