Wikia

Icarus Verilog

Projects

Talk1
44pages on
this wiki

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.

Verilog code generator[s] Edit

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.

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)

gnucap Code Generator Edit

Difficulty: Moderate

Icarus Verilog has some support for Verilog-AMS syntax. In the long run, we intend for the vvp run-time to support analog/Mixed Signal simulation, but in the short run we can get some use by having a code generator that turns a Verilog-A/MS into a compiled model for gnucap. Even when we get our own analog runtime, this would be of continuing use to gnucap users.

This task generally remains clear of the Icarus Verilog core, although there may be need to improve support for missing features in the ivl_target API. This task will also require some knowledge of how to compile models for gnucap. The multiple-discipline knowledge needed increases the difficulty. Adding new expression operator types, if desired, will involve Icarus Verilog parser and elaboration knowledge and can increase the overall difficulty.

--Stevewilliams 17:01, 5 February 2009 (UTC)

Module parameters at Compile Time Edit

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.

Done.

Stevewilliams 17:37, 8 February 2008 (UTC)

SystemVerilog Style Time Literals Edit

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.

This is being worked on. There are patches in the master branch as of 14 July 2011 that make this work.

Add SystemVerilog special "always" blocks. Edit

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)

Add uwire (unresolved net) support Edit

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.

Write a stand-alone VCD file compare utility Edit

Difficulty: Easy

We can really use a VCD checker utility that extracts information from a a VCD dump file, and compare VCD files for equality. This tool should verify that the header is well formed and that the value dump records are correct and reasonable. It should also be able to compare with a reference VCD file and report signals that are new/missing/different, and for the common signals any time/values that are different.

The main use for this tool is in the test suite, where it can be used to verify that the VCD dump routines are working correctly. A side benefit is that users may be able to use the tool to check a run with a reference dump.

The task is marked as Easybecause there are no tricky technical challenges. This doesn't have to touch any of the other parts of Icarus Verilog, and the VCD format itself is simple. The difficulty of this program is only that it needs to be somewhat robust.

This project could be expanded out to a GSoC project if some advanced features are added.

Stevewilliams 02:14, 7 September 2008 (UTC)

Put VCD/LXT Dumpers in Helper Threads Edit

Difficulty: Moderate

There is some evidence that the formatting of dump files is CPU intensive. Since it is common to want to run a simulation that dumps large portions of a design (or all of it) there is potential performance improvements to be had by moving portions of the dumper into a thread of its own. The benefits would include removing the compression (LXT) and file I/O of dumping from the main simulation thread. This should buy us some parallelism on ubiquitous multi-core systems.

This task should also include cleanup and refactoring of the VCD/LXT dumper code. Currently, there is a lot of duplication. Once that's worked out, all the handling of VCD/LXT output should be moved into a worker thread that receives messages from the main thread.

This task does not require special knowledge of Icarus Verilog internals, and can be done entirely through VPI. (See the existing dumper code.) I've marked this task as Moderate because of the need for deep understanding of the $dumpXXXX system tasks, and the needs for an understanding of the consequences of creating threads within vpi code.


A Horrible Idea Edit

Difficulty: Hard

A Horrible Idea Multithreaded Verilog Simulator

SystemVerilog 'N bit vectors Edit

Difficulty: Moderate

SystemVerilog (Verilog 2009) adds the tokens '0, '1, 'x and 'z. These are similar to 'bN but are a single bit and are guaranteed to be a repeat of that bit value to the width of the expression. There are subtle differences, notably that the 'bN form may zero pad or sign extend, whereas 'N is guaranteed to self-replicate.

The difficulty from this project comes not from the parsing of the syntax (that should be easy for anyone with basic compiler experience) but from handling all the special cases it may bring up during elaboration.

The following commit from Jared Casper fixed this issue. See below

From b6ff4039b1b58c3e5dffec04630dbd562a5b58e0 Mon Sep 17 00:00:00 2001
From: Jared Casper <jaredcasper@gmail.com>
Date: Sun, 23 Jan 2011 16:21:54 -0800
Subject: [PATCH] SystemVerilog 'N bit vectors.

Adds a is_single_ flag to the verinum class to indicate it came from a
'N bit vector and needs to be handled accordingly.
---
elab_expr.cc | 2 +-
lexor.lex | 19 +++++++++++++++++--
verinum.cc | 27 +++++++++++++++------------
verinum.h | 5 +++++
4 files changed, 38 insertions(+), 15 deletions(-)

Advertisement | Your ad here

Around Wikia's network

Random Wiki