Free verilog software for linux

Verilog::CodeGen module is a Verilog code generator.

SYNOPSIS

use Verilog::CodeGen;

mkdir DeviceLibs/Objects/YourDesign, 0755;
chdir DeviceLibs/Objects/YourDesign;

# if the directory YourDesign exists, the second argument can be omitted
# create YourModule.pl in YourDesign
&create_template_file(YourModule,YourDesign);

# create a device library for testing in DeviceLibs/Objects/DeviceLibs
&make_module(YourModule,YourDesign);

# create the final device library in DeviceLibs (once YourModule code is clean)
&make_module(,YourDesign);

Text::EP3::Verilog Perl module contains a verilog extension for the EP3 preprocessor.

SYNOPSIS

use Text::EP3;
use Text::EP3::Verilog;

This module is an EP3 extension for the Verilog Hardware Description Language.

The signal directive

@signal key definition Take a list of signals and generate signal lists in the differing formats that Verilog uses. This is accomplished by formatting a list of new defines and then calling the EP3 define method For example, the following command:

@signal KEY a[3:0], b, c[width:0], etc.

will cause the following to be done:

Define KEY with the list as it appears (can be used in further signal defs)
Define KEY{SIG} with the signal list (can be used in port lists)
e.g. replace KEY{SIG} with a[3:0], b, c[width:0]
Define KEY{EVENT} with the reg list (To be used in event lists)
e.g. replace KEY{EVENT} with a or b or c
Define KEY{IN} with the input list (you supply the first input and the trailing ;
e.g. replace KEY{INPUT} with [3:0] a;ninput b;ninput[width:0] c
or ... make the line
input KEY{INPUT}; become ..
input [3:0] a;
input b;
input [width:0] c;
Define KEY{OUT} with the output list (output [] sig).
e.g. like KEY{IN}
Define KEY{INOUT} with the inout list (inout [] sig).
e.g. like KEY{IN}
Define KEY{WIRE} with the wire list (wire [] sig).
e.g. like KEY{IN}
Define KEY{REG} with the reg list (reg [] sig).
e.g. like KEY{IN}
Define KEY{DSP} with the printf list (sig=%0[b|x] depending on width).
e.g. replace KEY{DSP} with a=%0x, b=%0b, c=%0x
This can be used in the $display task
$display("KEY{DSP}",KEY{SIG});

If the module and the test bench default is set up properly, the user needs only enter the signals in one place in the module file. This section can be included conditionally (e.g. @include "file" PORT) in the test bench and the signals can be automatically generated in the correct format in whichever header they are used. This means that a user can produce a module and its test bench by simply filling in the port list, the behavioral code, and the stimulus (which is of course, the real work). All of the signal header crud can be taken care of automagically.

The step directive

@step number [command] The step directive is useful to save verbage in test benches. @step 5 command; generates the following code:

repeat 5 @ (posedge tclk); command;

The posdege can be changed to or negedge (or whatever) using the edgetype directive. The tclk can be changed using the edgename directive.

The edgename directive

@edgename name The edgename directive allows the user to change the name used in the step directive. The default is tclk.

The edgetype directive

@edgetype type The edgetype directive allows the user to change the type used in the step directive. The default is posedge.

The denum directive

@denum key, key, [value], key, ... denum works like the ep3 enum, except that it generates verilog define statements. It also replaces KEY anywhere in the text with `KEY so that the verilog defines will work. (e.g. @denum orange, blue, green will generate:

`define orange 0
`define blue 0
`define green 0
@define orange `orange
@define blue `blue
@define green `green

Electric VLSI Design System is a complete Electronic Design Automation (EDA) system that can handle many forms of circuit design, including:

* Custom IC layout
* Schematic Capture (digital and analog)
* Textual Languages such as VHDL and Verilog
* Programmable logic (FPGAs)
* ...and much more.

Signs is a tool for logic synthesis and gate level simulation. Signss project main features include synthesis of RTL-style VHDL circuit descriptions and a dynamic graphical netlist viewer.
Supported formats include VHDL, ISCAS, and limited support for BLIF, Verilog, and EDIF netlists. Various true value and fault simulators and a combinational ATPG are included for circuit testing.
Aside from GUI mode, Signs has a pure command line mode and is fully scriptable in JavaScript and Ruby.
Main features:
- Written in Java, therefore platform-independent
- Aims to be VHDL93 compliant, at the moment a VHDL Subset is supported
- (Limited) support for non-synthesizable VHDL code, useful for testbenches
- Synthesis of RTL-style sequential VHDL process descriptions according to IEEE Std 1076.6
- Dynamic graphical netlist viewer supporting annotations (signal/gate names, signal values provided by simulators, faults)
- VHDL netlist output to file
- Input and output of netlists in ISCAS benchmark format
- Gate level true value simulators: event-based (any circuit), bit-parallel (combinational circuits only)
- Fault simulators: PPSFP, simple single faultsim
- Input and output of pattern lists in WGL format
- ATPG for combinational circuits: Implication-Graph based, PODEM
- Limited support for Verilog and EDIF netlists
- Fully scriptable in Rhino: JavaScript for Java and JRuby
- Pure command-line mode available besides GUI mode
- Integrated environment including source code and netlist structure tree views, build system, compilers and editors with syntax highlighting
Enhancements:
- While the release focus is clearly on bugfixes, there are also some feature improvements, such as enhanced test bench support and improved netlist and simulator views.
- The VHDL compiler has support for subprograms now and elaboration of big designs is much faster because of improved context handling.
- Internally, the intermediate representation layer was cleaned up, so intermediate objects form a proper tree now.

DParser project is an simple but powerful tool for parsing. You can specify the form of the text to be parsed using a combination of regular expressions and grammar productions.
Because of the parsing technique (technically a scannerless GLR parser based on the Tomita algorithm) there are no restrictions.
The grammar can be ambiguous, right or left recursive, have any number of null productions, and because there is no seperate tokenizer, can include whitespace in terminals and have terminals which are prefixes of other terminals.
DParser handles not just well formed computer languages and data files, but just about any wacky situation that occurs in the real world.
Main features:
- Powerful GLR parsing
- Simple EBNF-style grammars and regular expression terminals
- Priorities and associativities for token and rules
- Built-in error recovery
- Speculative actions (for semantic disambiguation)
- Auto-building of parse tree (optionally)
- Final actions as you go, or on the complete parse tree
- Tree walkers and default actions (multi-pass compilation support)
- Symbol table built for ambiguous parsing
- Partial parses, recursive parsing, parsing starting with any non-terminal
- Whitespace can be specified as a subgrammar
- External (C call interface) tokenizers and external terminal scanners
- Good asymptotically efficiency
- Comes with ANSI-C, Python and Verilog grammars
- Comes with full source
- Portable C for easy compilation and linking
- BSD licence, so you can included it in your application without worrying about licensing
Enhancements:
- Removed call to exec in python interface (Brian Sabbey)
- Fix binary_op_left in python interface (Brian Sabbey)

GTKWave is VCD/EVCD/LXT/Synopsis .out format electronic waveform viewer built using the GTK+ toolkit.

The project was originally developed by Tony Bybell but development has now passed to the APT group and we hope to extend and improve GTKWave to support new formats and features.

Installation

1) Type ./configure
2) make
3) make install (as root)

Make sure you copy the .gtkwaverc file to your home directory or to your VCD project directory. It contains the prefs for a good configuration that most people find ergonomic.

Note that Ver Structural Verilog Compiler AET files are no longer supported. They have been superceded by LXT. Also note that the AMULET group will be taking over maintenance of the viewer effective immediately.

sp_preproc is a SystemPerl Preprocessor.

SYNOPSIS

sp_preproc

sp_preproc takes a .sp (systemperl) file and creates the SystemC header and C files.

It is generally only executed from the standard build scripts.

ARGUMENTS

--help

Displays this message and program version and exits.

--hier-only

Read only hierarchy information, ignore all signal information. Useful for faster generation of sp_lib files.

--inline

Edit the existing source code "inline". Similar to the Verilog-mode AUTOs. Use --inline --noautos to remove the expanded automatics.

--libfile

Filename to write a list of sp_cells into, for later use as a --libcell to another sp_preproc run.

--libcell

Files listed before --libcell will be preprocessed or inlined as appropriate. Files after noexpand will only be used for resolving references, they will not be linked, linted, or otherwise checked. --nolibcell can be used to re-enable checking of subsequent files.

--ncsc

Create output files compatible with Cadence NC-SystemC.

--nolint

Disable lint style error checks, such as required to run doxygen on the SystemPerl output.

--preproc

Preprocess the code, writing to separate header and cpp files.

--trace-duplicates

Include code to trace submodule signals connected directly to a parent signal, generally for debugging interconnect. Without this switch such signals will be presumed to have the value of their parent modules signal, speeding and compressing traces.

--tree filename

Write a report showing the design hierarchy tree to the specified filename. This format may change, it should not be parsed by tools.

--noautos

With --inline, remove any expanded automatics.

--verbose

Shows which files are being written, or are the same.

--write-verilog filename

Write the SystemC interconnections in Verilog format to the specified filename. Note this does not include logic, it only contains module ports and cells.

-M

Makes the dependency listing (similar to cpp -M).

-Dvar=value

Sets a define to the given value (similar to cpp -D).

-f file

Parse parameters from the given file.

EP3 Perl module is the Extensible Perl PreProcessor.

SYNOPSIS

# Use options and files from command-line
use Text::EP3;
[use Text::EP3::{Extension}] # Language Specific Modules
# create the PreProcessor object
my $preprocessor = new Text::EP3 file;
# do the preprocessing, using command-line options from @ARGV
$preprocessor->ep3_execute;

# Set options and files from the Perl script
use Text::EP3;
[use Text::EP3::{Extension}] # Language Specific Modules
# create the PreProcessor object
my $preprocessor = new Text::EP3 file;
# configure the PreProcessor object (optional)
$preprocessor->ep3_output_file([$filename]);
$preprocessor->ep3_modules([@modules]);
$preprocessor->ep3_includes([@include_directories]);
$preprocessor->ep3_reset;
$preprocessor->ep3_start_comment([$string]);
$preprocessor->ep3_end_comment([$string]);
$preprocessor->ep3_line_comment([$string]);
$preprocessor->ep3_delimiter([$string]);
$preprocessor->ep3_gen_depend_list([$value]);
$preprocessor->ep3_keep_comments([$value]);
$preprocessor->ep3_protect_comments([$value]);
$preprocessor->ep3_defines($string1=$string2);
# do the preprocessing
$preprocessor->ep3_process([$filename, [$condition]]);

EP3 is a Perl5 program that preprocesses STDIN or some set of input files and produces an output file. EP3 only works on input files and produces output files. It seems to me that if you want to preprocess arrays or somesuch, you should be using perl. EP3 was first developed to provide a flexible preprocessor for the Verilog hardware description language.

Verilog presents some problems that were not easily solved by using cpp or m4. I wanted to be able to use a normal preprocessor, but extend its functionality. So I wrote EP3 - the Extensible Perl PreProcessor. The main difference between EP3 and other preprocessors is its built-in extensibility. Every directive in EP3 is really a method defined in EP3, one of its submodules, or embedded in the file that is being processed. By linking the directive name to the associated methods, other methods could be added, thus extending the preprocessor.