An always block executes when the signal inside changes. For instance, if the always block is written as: always@(a or b), the statements in said block will execute when either signal a or b changes. This error also occurs when always @(*) . This is the equivalent of always@(a or b) if a and b are the only inputs. If there was an input c it would be equivalent to always@(a or b or c)
Current Behaviour
Odin doesn't wait for a signal change but executes in each instance. The exception is when posedge or negedge is called then is waits for a posedge or negedge and in the meantime outputs xs.
Possible Solution
It should be similar to posedgoe or negedge but just compare that it changes.
Steps to Reproduce
module simple_op(a,b,c,out);
input a;
input b;
input c;
output reg out;
always @(a or c) begin
out = a & b;
end
endmodule
GLOBAL_SIM_BASE_CLK a b c
0 0 0 0
1 0 1 0
0 1 0 0
1 1 1 0
1 1 1 1
out
x
x
0
0
1
✔ {12:11}[]~/workspace/vtr-verilog-to-routing/ODIN_II:[ML/DNN ✭|… 12⚑ 1] ➭ ./odin_II -V regression_test/benchmark/verilog/ML/always_or_event.v -t regression_test/benchmark/verilog/ML/always_or_event_input -T regression_test/benchmark/verilog/ML/always_or_event_output
--------------------------------------------------------------------
Welcome to ODIN II version 0.1 - the better High level synthesis tools++ targetting FPGAs (mainly VPR)
Email: jamieson.peter@gmail.com and ken@unb.ca for support issues
Using Lut input width of: -1
Verilog: always_or_event.v
--------------------------------------------------------------------
High-level synthesis Begin
Parser starting - we'll create an abstract syntax tree. Note this tree can be viewed using Grap Viz (see documentation)
Adding file regression_test/benchmark/verilog/ML/always_or_event.v to parse list
Optimizing module by AST based optimizations
Converting AST into a Netlist. Note this netlist can be viewed using GraphViz (see documentation)
==========================
Detected Top Level Module: simple_op
==========================
Performing Optimizations of the Netlist
Performing Partial Map to target device
Outputting the netlist to the specified output format
Successful High-level synthesis by Odin
Blif file available at default_out.blif
==== Stats ====
Number of <FF_NODE> node: 0
Number of <INPUT_NODE> node: 2
Number of <OUTPUT_NODE> node: 1
Number of <CLOCK_NODE> node: 0
Number of <GENERIC> node: 1
Total estimated number of lut: 1
Total number of node: 1
Longest path: 3
Average path: 3
Elaboration Time: 0.9ms
--------------------------------------------------------------------
Reading top level module
Reading blif netlist...
100%|==================================================>| Total time: 0.5ms
-------------------------------------
Netlist Simulation Begin
Simulation starts
Beginning simulation. Output_files located @: .
Simulating 5 existing vectors from "regression_test/benchmark/verilog/ML/always_or_event_input".
default_out.blif:
Nodes: 10
Connections: 4
Threads: 1
Degree: 0.40
Stages: 4
Nodes/thread: 10(100.00%)
100%|==================================================>| Total time: 0.2ms
Warning::OUTPUT_BLIF Vector 0 equivalent but output vector has bits set when expecting don't care :
0 in output_vectors
x in regression_test/benchmark/verilog/ML/always_or_event_output
Warning::OUTPUT_BLIF Vector 1 equivalent but output vector has bits set when expecting don't care :
0 in output_vectors
x in regression_test/benchmark/verilog/ML/always_or_event_output
Warning::OUTPUT_BLIF Vector 3 mismatch:
1 in output_vectors
0 in regression_test/benchmark/verilog/ML/always_or_event_output
Error::OUTPUT_BLIF Vector files differ.
/home/emacdo12/workspace/vtr-verilog-to-routing/ODIN_II/SRC/simulate_blif.cpp:223: void simulate_netlist(netlist_t*): Fatal error
Aborted (core dumped)
Expected Behaviour
An always block executes when the signal inside changes. For instance, if the always block is written as: always@(a or b), the statements in said block will execute when either signal a or b changes. This error also occurs when always @(*) . This is the equivalent of always@(a or b) if a and b are the only inputs. If there was an input c it would be equivalent to always@(a or b or c)
Current Behaviour
Odin doesn't wait for a signal change but executes in each instance. The exception is when posedge or negedge is called then is waits for a posedge or negedge and in the meantime outputs xs.
Possible Solution
It should be similar to posedgoe or negedge but just compare that it changes.
Steps to Reproduce
Context
Your Environment