Undefined result for Ripple Counter - counter

I am writing a test bench for Ripple counter using d flip flop. My program is compiling without errors, however, I get undefined result. How can I solve this problem?
Here is the code:
module RCounter;
reg d,d2,d3,d4,clk;
wire q,q2,q3,q4;
DFlipFlop a(d,q,clk);
DFlipFlop a1(d2,q2,q);
DFlipFlop a2(d3,q3,q2);
DFlipFlop a3(d4,q4,q3);
initial
begin
clk =1;
d=0;d2=0;d3=0;d4=0;
#2 d=1;d2=~q2; d3=~q3; d4=~q4;
#2 d=0;d2=~q2; d3=~q3; d4=~q4;
#2 d=1;d2=~q2; d3=~q3; d4=~q4;
#2 d=0;d2=~q2; d3=~q3; d4=~q4;
#2 d=1;d2=~q2; d3=~q3; d4=~q4;
#2 d=0;d2=~q2; d3=~q3; d4=~q4;
#2 d=1;d2=~q2; d3=~q3; d4=~q4;
end
always
begin
#2 assign clk = ~ clk;
end
endmodule
What am I doing wrong and how can I solve this?

What you have there is not a ripple counter, and it seems that you don't really understand the boundary between your testbench and your DUT (design under test, or in your case, the 'ripple counter').
What you have is a testbench that is simulating four independent flip flops. If you were simulating a ripple counter, you should have a module called something like 'RCounter', which is instanced inside something else called 'RCounter_TB'. The testbench should only drive the inputs (for a counter, clock and reset), it should not drive the d pins of the individual flops, as the connections between these flops is what you want to test.
Inside the ripple counter module, you define the wired connections between your flip flops. There should not be any # time delays inside this module, because a module does not have a concept of fixed time delays. If you want the d2 pin to be driven from ~q2, then you just assign it as such:
assign d2 = ~q2
Because in hardware, this is just a wire looping back from the output of ~q2 back to d2. It always exists, and it has no concept of time.
As to specifically why you're getting X's on your output, I'll guess that it comes from the flip flop design you posted in your last question.
module DFlipFlop(d,q,clk);
input d,clk;
output q;
assign q = clk?( (d==1)? 1:0) : q;
endmodule
This is not a flip flop, as there is no state retention here, it's just an assign statement with an infinite feedback loop, (you essentially just have a wire driving itself).
If you want to model a flip flop, you need to use an always #(posedge clk) block, to imply that you want some state retention. I'll leave it to you to look up how to use an always block to model a flip flop.

Related

VHDL core synthesis and implementation in Vivado

I am currently developing an AES encryption core for a Pynq-Z1 FPGA board. I would like to see the routing of the logic in FPGA logic and timing summary of the design.
The project synthesises, but it results in a warning saying that I am using exceeding the number of IOB blocks on the package. This is understandable because the core takes in and outputs a 4 x 4 matrix.
Instead, I would like to have "internal I/O" in order to see the routing on FPGA fabric. How would I go about doing this? Currently, the device view shows an empty topology (shown below) but my synthesised design utilises 4148 LUT and 389 FF. I expect to see some CLBs highlighted.
design device view
I appreciate any feedback and reference to any application notes which might further progress my FPGA understanding.
Cheers
You can use a simple wrapper around your core with a serial interface. Something like:
entity wrapper is
port(clk, rst, dsi, dsi_core, shift_out: in std_ulogic;
di: in std_ulogic_vector(7 downto 0);
dso_core: out std_ulogic;
do: out std_ulogic_vector(7 downto 0)
);
end entity wrapper;
architecture rtl of wrapper is
signal di_core, do_core, do_buffer: std_ulogic_vector(127 downto 0);
begin
u0: entity work.core(rtl)
port map(clk, rst, dsi_core, di_core, dso_core, do_core);
input_process: process(clk)
begin
if rising_edge(clk) then
if rst = '1' then
di_core <= (others => '0');
elsif dsi = '1' then
di_core <= di & di_core(127 downto 8);
end if;
end if;
end process input_process;
output_process: process(clk)
begin
if rising_edge(clk) then
if rst = '1' then
do_buffer <= (others => '0');
elsif dso_core = '1' then
do_buffer <= do_core;
elsif shift_out = '1' then
do_buffer <= do_buffer(119 downto 0) & X"00";
end if;
end if;
end process output_process;
do <= do_buffer(127 downto 120);
end architecture rtl;
The wrapper just receives inputs, one byte at a time (when dsi = '1') and shifts them in a 128-bits register that is connected to the 128-bits input of your core. When 16 bytes have been entered the environment asserts dsi_core to instruct the core that the 128-bits input can be sampled and processed. The environment waits until the core asserts dso_core, signalling that the processing is over and the 128-bits output is available on the do_core output port of core. When dso_core is asserted the wrapper samples do_core in a 128-bits register (do_buffer). The environment can now read the leftmost byte of do_buffer which drives the do output port of the wrapper. The environment asserts shift_out to shift do_buffer one byte to the left and read the next byte...
This kind of wrapper is a very common practice when you want to test in the real hardware a sub-component of a larger system. As it frequently happens that the number of IOs of sub-components exceeds the number of available IOs, serial input-output solves this. Of course there is a significant latency overhead due to the IO operations but it is just for testing, isn't it?
Your demands are contradictory.
If the design can not place all the I/Os it can not show all the routing as it has not all the begin and/or endpoints. You should reduce your I/O.
The simplest way is to have a real or imaginary interface which much less pins.
An imaginary interface is one which is syntactically correct, reduces your I/Os but will never be used in real life so does not have to be functionally correct.
As it happens you are the third person to ask about reducing I/O in the last weeks and I posted an (untested) SPI interface which has a parameter to generate an arbitrary number of internal inputs and outputs. You can find it here: How can I assign a 256-bit std_logic_vector input

implementing inertial delay in multiple ways

I'm trying to implement inertial delay in SystemVerilog to generate a signal valid_inputs with following criterion
1. valid_inputs should go to '1' after some delay (say 15 units) if no inputs are X/Z
2. valid_inputs should go to '0' immediately if atleast one input becomes X/Z.
I am trying the above with 2 implementations:
module test (a, b, y);
input a, b;
output y;
wire temp;
assign temp = ^{a,b};
bit valid_inputs_temp, valid_inputs_2;
wire valid_inputs;
always #(temp)
begin
if (temp === 1'b1 || temp === 1'b0)
begin
valid_inputs_temp <= 1'b1;
end
else
begin
valid_inputs_temp <= 1'b0;
end
end
assign #(15,0) valid_inputs = valid_inputs_temp;
always #(temp)
begin
if (temp === 1'b1 || temp === 1'b0)
begin
#15 valid_inputs_2 <= 1'b1;
end
else
begin
valid_inputs_2 <= 1'b0;
end
end
endmodule
While the signal valid_inputs works perfectly, but I'm not quite sure why valid_inputs_2 doesn't work exactly the same? Is there a way I can implement the inertial delay using always-begin procedural code?
Please note that while I could modify the assign statement in the above code such that I totally eliminate the corresponding always-begin block, for some reason I need to use the always-begin style of coding.
Thanks,
Vinayak
The reason the second always block does not work is that you have a blocking #15 delay. That suspends the always process and misses a change on temp if it occurs in less that 15 time units. You need to move the delay to the other side of the <= so it becomes a non-blocking assignment delay.
valid_inputs_2 <= #15 1'b1;
And if you are confused about how an always block executes, see this link.
This is not a good example of inertial delay. The reason is that any 0->1 or 1->0 transition makes the output as 1. So pulses do not logically cause any difference in the output.
So there is no way to distinguish it from transport delay.
Moreover, the output turns 0 immediately for z. So there is no delay in that either.
Hence the signal "valid_inputs_2" is transport delay (<= #15).
To my knowledge there is no way to create inertial delay using always block.

which procedural block executed first, in SystemVerilog?

If I have both alwas_comb and always_ff in a single module, which one executed first?.
for example, I have seen this code in a book but I am confused about the functionality. for example, if WE=0 what will be the value of Qout?
module SyncRAM #(parameter M = 4, N = 8)(output logic [N-1:0] Qout,
input logic [M-1:0] Address, input logic [N-1:0] Data, input logic clk, WE);
logic [N-1:0] mem [0:(1<<M)-1];
always_comb
Qout = mem[Address];
always_ff #(posedge clk)
if (~WE)
mem[Address] <= Data;
endmodule
Any help about the truth table of this code is appreciated,
regards
The specific answer to your question is that Qout will just track the value of mem[Address]. In other words, on the rising edge of the clock, if WE is 0, Qout will be driven with the value written to the memory. This is because the memory will behave like a bank of flip-flops, while the Qout output will behave as if it is directly connected to the Q output of a bank of flip-flops.
The order of the execution of the two always blocks is deterministic, because Qout is driven using a blocking assignment (=), whereas the memory is written to using a non-blocking assignment (<=). See the answer here for much more detail.

verilog behavioral RTL to structural

I been assigned to manually convert the below RTL into its structural equivalent. I don't understand how you'd convert it. What's the structural description for this code in verilog? What steps should I take?
module cou(
output reg [7:0] out,
input [7:0] in,
input iti,
input c,
input clock);
always #(posedge clock)
if (iti == 1)
out <= in;
else if (c == 1)
out <= out + 1;
endmodule
Here is the basic process:
always #(posedge clock) tells you you have positive-edge D-flip-flops without an asynchronous reset or set.
out is the only value being assigned within the always statment. The size of out tells you the number of flops needed.
Drawing a component level schematic diagram can help visualize the structural logic.
Now all that is needed to figure out is the combination logic to the flop's D pin. I'll give you a clue that it can be done using only muxes and an adder.

Implementation of custom counter logic in SIMULINK

I am trying to implement a counter logic in SIMULINK where
in1, in2 are inputs
out1 is the output
if in2 = 0, out1 = 0;
if in2 = 1, out1 = 1 after x high edges of in1
I have tried using "Detect Rise Positive" block but failed miserably because I don't have sufficient experience of implementing a timing diagram correctly in SIMULINK. Could anyone kindly point me to the right direction?
Update
An approach I have taken since I posted this question is the "Triggered and enabled subsystem". I am trying to set it up so that:
in2 becomes the enable signal
in1 becomes the trigger
in2 becomes the intput to the subsystem
Out1 becomes the output of the subsystem
But I think that the above was rubbish. Unfortunately it is not VHDL where I could have implemented it using 4-5 lines of description of the hardware logic.
Using a Triggered and Enabled subsystem is the right approach, but your inputs (and no doubt what's inside the subsystem) needs to be modified.
Don't have any input to the subsystem (other than the trigger and enable signals).
Inside the subsystem,
set the enable block property to reset the state when disabled.
set the outport property to reset when disabled and give the initial condition as 0.
create a counter out of a constant (value=1), a summation and a unit delay block.
feed the counter into a Compare to Constant block set to the 'x' value in your question.
feed that block to the outport.
When enabled, the counter should count the required number of steps (when triggered) before the output goes high.
A counter logic can be implemented very easily in simulink. Take a switch,give the control input as int1. If int1 is 1 ur output shuld be 0 else take another switch give its control input as int2. if int2 is 1 ur output shuld be 1+ previous value given in feedback funit delay block