The code looks something like this...
The module adder (a, b, c, c_);
Input (3-0) a, b;
The output [4] c;
Input c_;
Reg [4] c;
Reg [3-0] g, p;
Genvar I;
The generate
for(i=0; i<=3; I=I + 1)
The begin
The assign g=[I] a [I] & amp; B [I];
The assign p=[I] a [I] | b [I];
End
The assign c [1] + [1]=g (p [I] & amp; C_);
for(i=2; i<=4; I=I + 1)
The assign c [I] [I] |=g (c/I - 1 & amp; P [I]);
Endgenerate
Endmodule

Don't complain, but the simulation results both input and output are x...
Initialization is initialized!

CodePudding user response:

Pro, your testbench, and simulation cases are generally not initialise when X (unvalued) or Z (high impedance state),

CodePudding user response:

First test_bench should write to,
Second in click the simulate behavioral model, must be first selected in the hierarchy of your test_bench module,

CodePudding user response:

Don't believe in the simulation, the simulation experience is XILinx unreliable

CodePudding user response:

In your policy documents no fakes clock or clock no initial value or writing motivation

CodePudding user response:

Initial to initialize the value of the test bench

CodePudding user response:

X is usually unpredictable, this according to the actual hardware, not necessarily a problem

CodePudding user response:

Really do engineering, general each module will join a reset input signal, and at the time of the signal down to all REG do initialization, and then reset up when dealing with business logic,

CodePudding user response:

If only the simulation study, you need in your module to join the initial block, in which be reg initialization,