Development Time Line

From Icarus Verilog

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.

Contents 1 The Release Process 1.1 Snapshots 1.2 Release Candidates 1.3 Released Releases 2 Version 0.8.7 3 Version 0.9.2 4 Next development snapshot (version 0.10.devel) 5 Development After 0.9 6 Notes For Planned Tasks 6.1 Verilog A/MS

[edit] The Release Process

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

[edit] 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.

[edit] 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.

[edit] 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 (). 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 () 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.

[edit] Version 0.8.7

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

[edit] Version 0.9.2

We have made a significant number of bug fixes/enhancements since the V0.9.1 release that will not be listed here. The following are what we would like to add before the next release.

• Fix pr2881797 (Auto-re-config doesn't necessarily touch output) report. Done.

• Fix pr2546206 (Embedded spaces in install paths not supported) for MinGW. The idea here is that the executable will fully support spaces in the paths. We still have a limitation in the Makefile that can not easily be worked around, but the configure script reports an error for this case. For MinGW the executable can be relocated so for it we can install into a non-space path and then relocate during installation into a path with space. This is exactly the case that instigated this report.

• Possibly fix pr2874755 (VCD contains "changes" of unchanged values). It would be nice if we could fix this before the release or decide if this is just a feature of the Icarus dumper.

• Possibly fix pr2785294 (cbValueChange for a part/bit select runs for any bit changes). This is one of the few higher priority bugs that we may be able to fix in V0.9. The rest require significant changes that can only be implemented in development (v0.10).

• Any other V0.9 appropriate bugs that may come up between now and the release date.

• Should the autoconf.sh file be updated to remove autom4te.cache or is there a flag we can use to force the cache to be rebuilt? This is only an issue if you are upgrading from an older version of autoconf, but if this is not done it will create some very strange error messages until the cache is deleted. Should this also be added to the distclean target? With the new autoconf code in the Makefile should this be part of the configure target as well?
  • I looked into this a bit. autoconf's manual claims up to 30% speed in the auto* tools using autom4te.cache, but other than that it is pretty useless.  Since our configure.in is relatively small and we don't use automake, autoheader, etc. it doesn't seem like a problem to just not use it.  If we are going to delete it before every run, we might as well delete it after instead, so it is just never there.  An interesting note is the debian packages include a patch to autoconf that makes it detect the out of date autom4te.cache on upgrade and regenerate it automatically, but that patch, while pretty old, doesn't seem to be in the main autoconf repo.  -- Jared
  • My assumption was that we would only need to delete this before configure was regenerated and to be honest given that we now require a modern version of autoconf it may not make sense to mess with this. I never meant to imply that we wanted to disable this functionality. I still think it should be added to distclean, but I'm not so sure about any other change. I'll think on this a bit more and see if anyone else has comments. Thanks for looking at this! -- Cary
  • Well if you delete it before configure is regenerated, then you are essentially disabling the functionality, since it is only used to speed up the creation of configure. :)  I agree that adding it to distclean is probably enough.  -- Jared
  • I think if you delete it before the configure script is created (autoconf is run) the cache will still be used during the creation of the configure script. It will obviously not provide information between runs. -- Cary
  • This has been added to the distclean target. This may be enough to call this fixed. -- Cary We are calling this change good enough.

• Fix the tranif issues or mark them as not fixable (EF) in V0.9 (pr2832234, pr2834340 and pr2834340b). Done. pr2834340 are fixed in git v0_9-branch. The fix for pr2832234 relies on the vvp-net-out-rework, so is not fixable.

• Double check that the test results are the same for the various architectures and operating systems. There should only be one fail in V0.9 and that is pr1877743 (the modpath if race). We do not expect this to be fixed in V0.9, but since it has not been fixed in development we do not know for sure so it will remain as a normal fail.

After this release we expect our major focus will be on the development branch and only easy or critical fixes will be back ported to V0.9.

[edit] Next development snapshot (version 0.10.devel)

Not fully defined yet, but here is something to start he list.

• 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.).

[edit] 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.

• Rework the run time support for nets (as opposed to variables) so that they are part of an existing functor. They should not have their own vvp_net object. This should save run-time costs and fix bugs related to force and vpi_put_value to nets. Finished and merged into development.

• 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).

• 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.

• 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.

• Look at the unreported SDF problem. This may only require the net rework mentioned above. The net rework was not enough, this is still not working correctly.

[edit] Notes For Planned Tasks

[edit] 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.