This page is meant to be a living document that describes current thinking for what we want to do with Icarus Verilog development. We try to divide our intentions into a release schedule of sorts.

Note that there are no dates. It'll be ready when it's ready.

The Release Process

The release process for Icarus Verilog takes place in the git repository, and is managed by branches and tags.

Snapshots

Snapshots are tagged points on the master branch. Snapshot tags have the form sYYYYMMDD where YYYY is the year, MM the numeric month and DD the day. Keeping to this format for snapshot tags makes them easy to recognize.

Release Candidates

A release comes to existence as a branch in the git repository, so that all development on the master branch does not go into the release branch by default. A new branch format v0_X-branch starts the release candidates for the 0.X release series. Initially, there are no release tags on a release branch, and the release isn't really released yet. This is a release candidate branch. The actual candidates are managed in an ad hoc manner up to the first actual release. There may be non-release tags to mark potential releases.

Thus we create the branch for the release and put it into a feature freeze. We then have time to polish it up for the first proper release on the branch, and the master can in the mean time continue on with new development.

Released Releases

The first release will be tagged v0_X_1 for release 0.X.1 and marks the end of the release candidate phase. The next release will be tagged v0_X_2 for release 0.X.2, and so forth. Release tags all have the same format. We start the releases as .1 to leave .0 for the first release candidates.

Within a release branch, we try to assure that minimum standards of compatibility are met:

• It is necessary that any vvp output generated by iverilog X.Y.m must run under vvp X.Y.n (${\displaystyle m < n}$). In other words, backward compatibility within a release series is required. Does this also include messages (textual output)? or is this more simulation output? We need a definition of what output is (simulation results, compiler output, error/warning messages, etc.)

• For any program where X.Y.m generates correct output, then X.Y.n (${\displaystyle m < n}$) may not change the output, even if the different is also correct by other definitions.

• New features should be kept to a minimum, and new features may not create any backward compatibility problems. In other words, if a program compiles and runs correctly on X.Y.m, then it must also compile and run on X.Y.n. For example, no new keywords!

• If X.Y.m compiles and runs but generates incorrect output, then X.Y.n may generate different and more correct output.

• If the input program is incorrect and X.Y.m compiles it but shouldn't, then X.Y.n may generate error messages instead.

Version 0.8.7

We have released 0.8.7. We expect this to be the last release in the 0.8 branch. We will only do another release if we need to fix critical bugs in the simulator or significant bugs in the synthesis code.

Version 0.9.5

We released Icarus Verilog 0.9.5 on November 1st, 2011.

Next development snapshot (version 0.10.devel)

The last development snapshot was created on November 11th, 2011.

The following are some of the things we plan to work on for future snapshots:

• Fix bug report pr3366114. Done

• Add a target for emitting 1364-1995 compatible Verilog. As an extension a flag can be set to translate the various signed constructs. This is currently being worked on.

• Add a preprocessor/elaborator for VHDL. This will allow mixed language simulation and with the new Verilog target can even be used to convert VHDL to Verilog. This is currently being worked on.

• Document the new command line/file parameter override along with the limitation it currently has (can only override top level parameters, does not have priority over defparms, etc.).

• Add support for long arguments and add flags to control the default time scale. This will allow us to close feature request pr1403406, our oldest open report. It will also make it easier to add new functionality in the future.

• Look at fixing feature request pr1903439.

• Possibly fix some of the existing bugs. For example pr2785294, pr2808786 or even some of the older non-expression rework related bugs.

• As appropriate, fix any new bug.

• Write the release notes, Yes, more pesky writing tasks.

Development After 0.9

The following list is for items that do not have a bug report. In general we plan to work on fixing some of the long standing bug reports and add some of the missing functionality for each release.

• Verilog-AMS fleshed out enough that it is usable.

• Bring back synthesis (this is a lower priority task).

• Get specify block to work correctly including implementing the timing checks.

• Verify VPI interface functionality against standard functions and add missing functionality that makes sense for Icarus.

• Add support for dynamic expression evaluation. We have implemented the start of this with the &A<> and &PV<> constructs. We need another construct to support arbitrary expressions. For some expressions this is a bidirectional construct (it can get or put a value). We believe this functionality is required to fix the following bug reports: pr2951659, pr2874755, pr2781845, pr2728557, pr2459145 and pr2070488. It is also a prerequisite for pr2888087. This is currently being worked on and is a major effort, so it will be some time before it is completed.

• It would be nice to have the stub target do full checking of the compiler interface and return a value that we can wrap around an alternate test suite script. Basically a stub_reg.pl script that only runs the compiler with -tstub.

• Add vzt dump file support. This is another GTKWave file format. See the GTKWave source and the discussion on iverilog-devel. The latest GTKWave (3.2.0) has code that could be used as a template in the contrib/vpi directory. We also need to look at the ghw format since it should support mixed mode results more efficiently. We added fst support instead since it is expected to be better than vzt.

• Finish the valgrind cleanup of vvp and start to look at doing the same for ivl. ivlpp and the iverilog driver should already be clean.

Notes For Planned Tasks

Verilog A/MS

The long-term plan is for Icarus Verilog to support Verilog-A/MS as completely as regular Verilog. That's a fairly large task and it needs a strategy for tackling it.

• Parse and Elaborate

The first goal is to properly parse and elaborate a reasonable subset of Verilog-AMS language constructs. This gathers together enough compiler infrastructure for later steps.

• Code generation for gnucap

Actually implementing the analog run-time can be put off by instead targeting gnucap. The idea here is to write a loadable code generator that emits models for gnucap, which can then simulate that model. This makes the Icarus Verilog analog support useful even at this early stage.

• Analog runtime in vvp

Add to the vvp runtime support for analog simulation kernels. This amounts to writing a new analog simulator, so this will take some real time. It is unlikely that this will be even started before the 0.9 release.