Ad blocker interference detected!
Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers
Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.
The main git repository for Icarus Verilog is available at email@example.com:steveicarus/iverilog.git. The master branch is always the main development path for Icarus Verilog, but there are also various subordinate branches that carry activity of various sorts.
Normally, after you clone the repository at github.com, git automatically create for you a local branch called "master" that tracks the remote branch "origin/master". That is, your local "master" tracks the "master" at the original that you cloned from. (The convention is to call the repository from which your local repository is cloned the "origin".) If you want to work on another branch, then you create a different local branch that tracks the origin branch you are interested in. For example, if you want to work on "v10-branch", you would create a local branch and check it out with this command:
% git checkout --track -b v10-branch origin/v10-branch
The command "git branch" will list your local branches, with a "*" in front of the branch that is currently checked out. After the above command, your branch list may look like this:
% git branch master * v10-branch
If you want to see all the branches, including the remote branches, add the "-a" flag:
% git branch -a master * v10-branch origin/master origin/v10-branch origin/v0_9-branch origin/verilog-ams origin/var-array-rework [...and so on]
The branches named "origin/..." are branches available in the remote repository. Do not checkout a remote branch directly. Instead, create a local branch that tracks the remote branch and check that out. When a branch tracks a remote branch, that means that the "git pull" command will automatically pull commits from the remote branch, apply them in your local branch after your local head, then advance the head to the new head that matches the remote. (For CVS users, this effect is much like "cvs update".)
The "git checkout -b ..." command example above created a new local branch "v10-branch" set up to track the "origin/v10-branch" from the remote, and checked out the newly created local branch. You can use the "git checkout" command without the "-b" flag to switch back and forth between local branches that already exist (i.e. "git checkout master") so you can keep several threads of work going at once.
Note, by the way, that the output from "git branch -a" lists the remote branches with the prefix "origin/". This prefix is in front of all the branches that were found on the repository from which you cloned your local repository. In the descriptions of branches below, we do not include the "origin/" prefix because we describe the branches from the perspective of the remote repository itself. So keep in mind that when you try to access one of these branches, you must create a local branch that tracks one of these branches, and the remote name will be (usually) "origin/<name>".
To visualize the relationships between branches, use the "gitk --all" command. The "--all" flag tells "gitk" to display data about all the branches it knows about, and not just the current checked out branch.
The master branch Edit
This is the main path of current development for Icarus Verilog. All work on the next major release of Icarus Verilog is either on this branch, or on a subordinate branch that is eventually merged back into the master. Snapshots are always tagged commits on the master branch. When a new release is created, a new release branch is created rooted on some point on the master branch.
This branch carries Verilog-AMS support work. This branch off the master is occasionally merged back into master as major feature sets are completed and ready for release into the main development stream, but the verilog-ams branch remains active for Verilog-AMS specific work.
This new branch is for supporting the use of vvp within other applications e.g. Spice for mixed signal simulation. The interface supports binding PWL signals to vvp signals.
This is a branch for working on performance improvements that may be a bit too risky to go directly into master.
The core compiler uses PExpr::elaborate_net methods to elaborate expressions in continuous assignment and similar contexts. This is a huge duplicate of code, so this branch is the effort to eliminate all uses of the PExpr::elaborate_net method.
This is a temporary branch for the complex task of reworking the way that variable arrays are handled in the Icarus Verilog simulation runtime. When these changes are complete, this branch will be merged back into master and the branch closed.
When the version 10 release was started, v10-branch was created. This branch is in practice a fork from the main development, in that work is not in general done to this new branch. Bug fixes for the v10 release sequence are pushed onto this branch, and sub-releases of v10 are taken from this branch.
This branch is not merged into the master branch. Of course, new v10 releases are occasionally made. Each v10 series release is tagged in this branch.
When the 0.9 release was made, the v0_9-branch was created. This branch is in practice a fork from the main development, in that work is not in general done to this new branch. Bug fixes for the v0.9 release sequence are pushed onto this branch, and sub-releases of v0.9 are taken from this branch.
This branch is not merged into the master branch, as the v0.9 is considered obsolete from the Icarus Verilog development perspective.