Projects
From Icarus Verilog
This page is a collection of suggested projects for Icarus Verilog. People looking for something to work on can come here to find thought out and ranked suggestions. People who would like to see something done can suggest it on the discussion page. After some hashing out it can be promoted to the projects page. This differs from the "Feature Requests" tracker in that these are thought through projects with estimates of complexity.
These projects also make sense as Google Summer of Code ideas.
Projects are rated as Easy, Moderate or Hard.
- Easy projects require no specialized skills other then the usual generic C/C++ programming skills.
- Moderate projects require more specialized skills in the form of advanced C/C++ skills, some detailed knowledge of CAD or EDA, or some internals of Icarus Verilog.
- Hard projects require an understanding of the subtleties of Icarus Verilog internals, and or advanced, real world HDL and/or EDA issues.
It may make sense for a project suggestion to start life in the Graffiti page until the idea is fleshed out and rated.
[edit] Verilog/VHDL code generator[s]
- Difficulty: Moderate
A Verilog code generator target to emit simplified Verilog code. This has use as a Verilog "reducer" (or obfuscator) to translate verilog to more simplified forms. It can also be used to support other Verilog run time engines.
A variant of this is to generate VHDL, and thus get a VHDL translation from the Verilog input.
This task remains pretty clear of the core Icarus Verilog compiler and just works with loadable code generators.
--Stevewilliams 16:50, 9 March 2007 (UTC)
[edit] Module parameters at Compile Time
- Difficulty: Moderate
It would be nice to be able to specify at compile time parameter overrides for instantiated modules of a design. For example, if a root module has a "parameter cpu_width = 32;" it would be nice to be able to include in the command file the line "+parameter+cpu_width=64" and have that parameter overriden in the root module. This would make for a more robust alternative to the preprocessor that is sometimes used.
This would involve some work in the core compiler (touching early elaboration code) as well as the compiler driver in order to handle the command argument itself. It's a moderately difficult task because the core compiler is a complex piece of code and finding one's way around here is difficult and time consuming.
Stevewilliams 17:37, 8 February 2008 (UTC)
[edit] Add a -gsystem-verilog Generation flag
- Difficulty: Easy
Add the "-gsystem-verilog" generation flag to enable SystemVerilog features that Icarus Verilog does or will support, including System Verilog keywords. It may make sense to absorb the "-gxtypes" flag into this, although it may also make sense to keep extended types separately enabled from the rest of System Verilog
This task is easy because it should not involve any work on the compiler at all. This is a matter for the driver itself, and only the bits of the core involved in collecting flags.
Stevewilliams 15:22, 5 May 2008 (UTC)
[edit] SystemVerilog Style Time Literals
- Difficulty: Moderate
In System Verilog one can give time literals including units. For example "#10ns foo = bar;" makes clear that you want to delay for 10ns no matter the time units currently in effect. This is largely a readability improvement for designs where time is important. (This does not, and cannot, eliminate the need for proper understanding of time scale and units in the design.)
At the same time, it also makes sense to implement the per-module timescale/timeunits support from SystemVerilog. This is better then the rather ugly timescale support of basic Verilog.
This task is moderate because it requires some skill with bison/flex to parse the extended syntax, and also requires some understanding of how the literals need to be scaled during elaboration.
[edit] Add SystemVerilog special "always" blocks.
- Difficulty: Hard
SystemVerilog adds new "always" statements "always_ff", "always_comb", "always_latch" and "final". These behave just like regular "always" statements (except for "final") but they give more information to the elaborator, which checks a variety of rules to make sure that the contained code really is synchronous, combinational, or level-sensitive as appropriate.
The syntax itself should be very easy to add. The hard part of this project is the checking of the rules. The elaboration will have to check that the code inside the statement meets the rules and generates the correct error messages. Once the check is done, the code generator does not need to pass this information on, so this task should live entirely within elaboration.
Stevewilliams 15:31, 5 May 2008 (UTC)
[edit] Back port appropriate V0.9 patches to V0.8
- Difficulty: Easy to Moderate
Given that V0.8 will likely be around for some time after V0.9 is officially released it makes sense to back port some of the patches from V0.9 to V0.8. The major guidance needed would be to verify which patches are appropriate since we need to maintain the stability of V0.8.
It also makes sense to update V0.8 to work with recent compilers.
Experience with C and C++ are the major requirements. Since much of this is simple cut and paste (with some modification) any other tools that are needed can be learned while working on the project.
Cary 01:55, 18 February 2008 (UTC)
[edit] Add git commit information to version strings
- Difficulty: Easy
The "iverilog -V" used to dump the CVS name. That's no longer useful as the development is via git now. It would be nice to build into the version string the git commit id (or even better, the nearest git tag) so that it is clear exactly what version it really is.
- NOTE: The above part of the task is already done, but there are some more aspects that need to be done. Read on.
Also, the "-V" handling through the sub-systems of the compiler parts is not consistent. We should have the driver do a version-only probing of the various sub-programs that does not then complain about not having source files. This probing includes invoking the ivlpp to get the verilog of the preprocesor, and the ivl core to get its version. The latter should in turn probe the code generator and possible loadable modules as well to get all their version strings as well.
This is easy because it does not really involve much of the compiler itself, just the git infrastructure, the build scripts, and the driver program. There is also a little fiddling with the ivl core and the loadable modules to get the detailed version information. Compared to almost any other possible project, this should be really easy, although it will teach you a lot about how the driver infrastructure works.
[edit] Add uwire (unresolved net) support
- Difficulty: Moderate
A little known feature of the Verilog 2005 LRM is support for the "uwire" net. These nets require that there are not multiple driver. This is a way of preventing double-driving at the design level and should be much more popular then it is amongst FPGA designers.
This task is moderately difficult because it requires understanding some of the internals of Icarus Verilog elaboration. It is not in of itself a big task.
