ODIN uses CMake as it’s build system. CMake provides a protable cross-platform build systems with many useful features.
For unix-like systems we provide a wrapper Makefile which supports the traditional make and make clean commands,
but calls CMake behind the scenes.

Warning

After you build Odin, please run the included verify_microbenchmarks.sh script. This will automatically compile, simulate,
and verify all of the included microbenchmark circuits to ensure that Odin is working correctly on your system.

will simulate the generated netlist with the entered number of clock cycles using pseudo-random test vectors. These vectors and the resulting output vectors are written to “input_vectors” and “output_vectors” respectively. You can supply a predefined input vector using -t

-L

<Comma-separated list>

Comma-separated list of primary inputs to hold high at cycle 0, and low for all subsequent cycles.

<config><verilog_files><!-- Way of specifying multiple files in a project! --><verilog_file>verilog_file.v</verilog_file></verilog_files><output><!-- These are the output flags for the project --><output_type>blif</output_type><output_path_and_name>./output_file.blif</output_path_and_name><target><!-- This is the target device the output is being built for --><arch_file>fpga_architecture_file.xml</arch_file></target></output><optimizations><!-- This is where the optimization flags go --></optimizations><debug_outputs><!-- Various debug options --><debug_output_path>.</debug_output_path><output_ast_graphs>1</output_ast_graphs><output_netlist_graphs>1</output_netlist_graphs></debug_outputs></config>

Note

Hard blocks can be simulated; given a hardblock named block in the architecture file with an instance of it named instance in the verilog file, write a C method with signature defined in SRC/sim_block.h and compile it with an output filename of block+instance.so in the directory you plan to invoke Odin_II from.

When compiling the file, you’ll need to specify the following arguments to the compiler (assuming that you’re in the SANBOX directory):

If the netlist generated by Odin II contains the definition of a hardblock which doesn’t have a shared object file defined for it in the working directory, Odin II will not work if you specify it to use the simulator with the -g or -t options.

Warning

Use of static memory within the simulation code necessitates compiling a distinct shared object file for each instance of the block you wish to simulate. The method signature the simulator expects contains only int and int[] parameters, leaving the code provided to simulate the hard blokc agnostic of the internal Odin II data structures. However, a cycle parameter is included to provide researchers with the ability to delay results of operations performed by the simulation code.

Each line represents a vector. Each value must be specified in binary or hex. Comments may be included by placing an # at the start of the line. Blank lines are ignored. Values may be separated by non-newline whitespace. (tabs and spaces) Hex values must be prefixed with 0X.

Each line in the vector file represents one cycle, or one falling edge and one rising edge. Input vectors are read on a falling edge, while output vectors are written on a rising edge.

The verify_microbenchmarks.sh and verify_regression_tests.sh scripts
compile and simulate the microbenchmarks and a larger set of benchmark
circuits. These scripts use simulation results which have been verified
against ModelSim.

After you build Odin II, run verify_microbenchmarks.sh to ensure that
everything is working correctly on your system. Unlike the
verify_regression_tests.sh script, verify_microbenchmarks.sh also
simulates the blif output, as well as simulating the verilog with and
without the architecture file.

Before checking in any changes to Odin II, please run both of these
scripts to ensure that both of these scripts execute correctly. If there
is a failure, use ModelSim to verify that the failure is within Odin II
and not a faulty regression test. The Odin II simulator will produce
a test.do file containing clock and input vector information for ModelSim.

When additional circuits are found to agree with ModelSim, they should
be added to these test sets. When new features are added to Odin II, new
microbenchmarks should be developed which test those features for
regression. Use existing circuits as a template for the addition of
new circuits.

ModelSim may be installed as part of the Quartus II Web Edition IDE. Load
the Verilog circuit into a new project in ModelSim. Compile the circuit,
and load the resulting library for simulation.

Simulate the circuit in Odin II using the -E option to ensure that Odin II
outputs both edges of the clock. You may use random vectors via the -g option,
or specify your own input vectors using the -t option. When simulation is
complete, load the resulting test.do file into your ModelSim project and
execute it. You may now directly compare the vectors in the output_vectors
file with those produced by ModelSim.

To add the verified vectors and circuit to an existing test set, move the
verilog file (eg: test_circuit.v) to the test set folder. Next, move the
input_vectors file to the test set folder, and rename it test_circuit_input.
Finally, move the output_vectors file to the test set folder and rename
it test_circuit_output.