BCD and 7segment decoder show strange result - verilog

I'm trying to create connection from BCD to 7-segment decoder. When I press button UP_* or DOWN_*, it should counting up or counting down. But my simulation only displays 0000001 even when I press button UP or DOWN.
BCD module code:
module BCDcountmod(
input Clock, Clear, up, down,
output reg [3:0] BCD1,
output reg [3:0] BCD0);
//reg [3:0] BCD1_1, BCD0_0;
always #(posedge Clock or negedge Clear) begin
//---- IS IT CLEAR? --------------
if (~Clear) begin
BCD1 <= 'b0;
BCD0 <= 'b0;
end
//---- IS IT UP? --------------
else if (up == 1'b1) begin
if (BCD0 == 4'b1001) begin
BCD0 <= 0;
if (BCD1 == 4'b1001)
BCD1 <= 0;
else
BCD1 <= BCD1 + 1;
end
end
//---- IS IT DOWN? --------------
else if (down==1'b1) begin
if (BCD0 == 4'b0000) begin
BCD0 <= 4'b1001;
if (BCD1 == 4'b0000)
BCD1 <= 4'b1001;
else
BCD1 <= BCD1 - 1;
end
else
BCD0 <= BCD0 - 1;
end
end
endmodule
7-segment module:
module segment7dec (output reg [6:0] display, input [3:0] bcd);
always #* begin
case(bcd)
4'b0000: display = 7'b1111110;
4'b0001: display = 7'b0110000;
4'b0010: display = 7'b1101101;
4'b0011: display = 7'b1111001;
4'b0100: display = 7'b0110011;
4'b0101: display = 7'b1011011;
4'b0110: display = 7'b1011111;
4'b0111: display = 7'b1110000;
4'b1000: display = 7'b1111111;
4'b1001: display = 7'b1111011;
default: display = 7'b0000000;
endcase
display = ~display;
end
endmodule
My testbench:
module scoreboard_testbench;
// Inputs
reg UP_A;
reg DOWN_A;
reg UP_B;
reg DOWN_B;
reg Reset;
reg CLK;
// Outputs
wire [6:0] disp1A;
wire [6:0] disp0A;
wire [6:0] disp1B;
wire [6:0] disp0B;
// Instantiate the Unit Under Test (UUT)
socreboard_top uut (
.UP_A(UP_A),
.DOWN_A(DOWN_A),
.UP_B(UP_B),
.DOWN_B(DOWN_B),
.Reset(Reset),
.CLK(CLK),
.disp1A(disp1A),
.disp0A(disp0A),
.disp1B(disp1B),
.disp0B(disp0B)
);
initial begin
// Initialize Inputs
UP_A = 0;
DOWN_A = 0;
UP_B = 0;
DOWN_B = 0;
Reset = 1;
CLK = 0;
// Wait 100 ns for global reset to finish
#100;
Reset = 0;
UP_A = 1'b1;
#500
UP_A='b0;
#500
UP_A=1'b1;
#500
DOWN_A=1'b1;
#4000 $finish;
// Add stimulus here
end
always #5 CLK=!CLK;
endmodule
Simulation picture:
Simulation Picture Result-Click Here
Any suggestions?

General entry level debugging procedure
Always run code in simulation before loading it onto a FPGA.
Determiner which module has a bug(s):
Make sure the stimulus for the module matches your intentions.
Make sure the output for a module makes sense for its input.
Step through line-by-line:
Make sure each branch is reachable and executing as intended.
Dump everything in the debug scope into waveform.
Add debug messages using $display.
Add small delays such as #0.1 into the design. This may require changing the time precision of the time scale.
After the potential bug is found:
Correct it and add a note on the same line with a searchable keyword (ex: //FIXED). Run simulation to validate the fix.
If the bug seems resolved. Comment-out (not remove) the debug messages and injected delays. Run simulation again.
Repeat step 4 until all the bugs are resolved.
It is now safe to remove the commented-out messages and delays.
RUN SIMULATION AGAIN!
Hint:
There is one design bug and one potential test bench issue.

The stimulus you are using is not consistent with how you designed your module to work. The problem is in your testbench. Since this is homework I'll let you take it from there.
EDIT: I'm going to assume that the homework deadline has passed. For the benefit of future readers, note that the Verilog module uses an active-low Clear signal that resets everything when it is at a logic 0. The testbench incorrectly assumes an active-high Reset signal, so Reset (and hence Clear) are being held low for almost the entire testbench. There's no way the Verilog module can do anything useful...it's being continuously cleared.

Actually i've already implemented such connection, you could see it in my github project: https://github.com/MossbauerLab/RomChipReader It works not only in simulation but also in hardware (i made short video with demo). You could see my impl of output to 7-seg in https://github.com/MossbauerLab/RomChipReader/blob/master/RomReader/src/address_display.v
don't forget to see testbenches also and it is important to use debouncer (https://github.com/MossbauerLab/RomChipReader/blob/master/RomReader/src/debouncer.v) if you are planning to change codes from buttons.

Related

EDAPlayground: Verilog code "reached maximum runtime"

I have a simple Verilog code for a sequential logic network. It consists of a design and a testbench file; it compiles, but it runs for too long. I'm not sure why; apart from the clk, I didn't put any loops in it. Maybe I have some syntax mistakes using the binary numbers. I ran it using the online EDA Playground software; I didn't try it on Xilinx.
Simulator: Icarus Verilog 0.9.7, compile options: -Wall. "Execution
interrupted or reached maximum runtime."
This is what the log wrote.
Design file:
module hazimodul(
input clk,
input rst,
input ce,
input x,
output z
);
reg[1:0] all;
reg[3:0] y;
reg[0:0] zout;
always#(posedge clk)
begin
if(rst)
begin
zout <= 1'b0;
all <= 2'b00;
y <= 4'b0111;
end
else if(ce)
begin
if(all == 2'b00)
begin
if(x== 1'b0)
zout<=1'b0;
else
all <=2'b01;
end
if(all==2'b01)
begin
zout <= y[3:3];
y <= {y[2:0],y[3:3]};
if (y == 4'b0111)
all <= 2'b10;
end
if(all==2'b10)
begin
if(x == 1'b0)
all <= 2'b00;
end
end
end
assign z = zout;
endmodule
Test file:
module test;
reg clk;
reg rst;
reg x;
reg ce;
// Outputs
wire z;
// Instantiate the Unit Under Test (UUT)
hazimodul uut (
.clk(clk),
.rst(rst),
.x(x),
.ce(ce),
.z(z)
);
initial begin
// Initialize Inputs
clk = 0;
rst = 0;
x=0;
ce=0;
#10;
rst<=1;
#20;
rst<=0;
#30
ce<=1;
#40
x<=1;
#80
x<=0;
#90
x<=1;
end
always #5
clk <=~clk;
endmodule
You need to tell the simulator when to stop running. One way is to use the $finish system task, which you can add to your testbench:
initial #1000 $finish;
Now, the simulation finishes on edaplayground. You can change the #1000 delay to something more meaningful to your design.
Here is an explanation of why your code continues to run. Your testbench has 2 parallel threads: one initial block and one always block. In both threads, you add events to the Verilog event queue. The initial block ends after the last assignment to x.
However, the always block continues to add events to the event queue, so the simulation never ends.
Adding the second initial block with the $finish forces the simulation to end, regardless of the infinite always block.

How to fix [Common 17-1293] error in Xilinx Vivado?

I was trying to run some simple behavioral simulations in Xilinx Vivado, but then I got the error -
[Common 17-1293] The path 'D:/Deepan/Text Books/internship/test/test.cache/wt' already exists, is a directory, but is not writable.
The Verilog files that I wanted to run used to work perfectly before, but suddenly it broke.
I made sure that the directory has proper access and was not stuck at read-only, still, I kept getting the error.
I kept getting the same error for both v2021.1 and v2020.3.
The files I wanted to run -
`timescale 1ns / 1ps
module Mealy_Sequence(
input wire clk,
input wire reset,
input wire level,
output reg tick
);
localparam //The Mealy states
zero = 1'b0,
one = 1'b1;
reg current_state, next_state;
always #(posedge clk, posedge reset)
begin
if(reset)
current_state <= zero;
else
current_state <= next_state;
end
always #(current_state, level)
begin
case(current_state)
zero: begin
if(level)
begin
next_state <= one;
tick <= 1;
end
else
begin
next_state <= current_state;
tick <= 0;
end
end
one: begin
if(level)
begin
next_state <= one;
tick <= 0;
end
else
begin
next_state <= zero;
tick <= 0;
end
end
endcase
end
endmodule
test bench -
`timescale 1ns / 1ps
module Sequence_Test_Mealy;
reg clk;
reg reset;
reg level;
wire tick;
Mealy_Sequence x(
.clk(clk),
.reset(reset),
.level(level),
.tick(tick)
);
always #5 clk = ~clk;
always #15 level = ~level;
initial
begin
clk <= 0;
level <= 0;
reset <= 1;
#10 reset <=0;
end
endmodule
Even though I had no spaces in the path names but I was still getting this error.
I solved this by making the path extremely small e.g., D:/a/a/a.xpr
I figured out the solution to my own problem. Vivado sometimes doesn't allow spaces in file paths( I had a space in Text Books). This applies to the entire project as well as the imported files.
Simply removing the space fixed the issue.

Verilog Synchronous 4 bit Counter stay on max value until given signal

So I have my counter in verilog which is 4 bits and I want it to stay on max value, 1111, until I give it a signal to start counting from 0000 again.
Here's what I've been able to come up with so far:
module contadorAscMax
(
input iClk,
input iRst,
output oQ,
input iCE,
input iSignal,
output [3:0] orCnt
);
reg[3:0] rvCnt_d;
reg[3:0] rvCnt_q;
assign orCnt = rvCnt_q;
always #(posedge iClk or posedge iRst)
begin
if(iRst)
begin
rvCnt_q<=4'b0;
end
else
begin
if(iCE)
begin
rvCnt_q<=rvCnt_d;
end
else
begin
rvCnt_q<=rvCnt_q;
end
end
end
always #*
begin
rvCnt_d=rvCnt_q+4'b1;
if(rvCnt_d == 4'b1111)
begin
rvCnt_d = rvCnt_d;
end
else if(rvCnt_d == 4'b1111 & iSignal)
begin
rvCnt_d = 4'b0;
end
end
endmodule
But it just won't wait for the signal. I am very new to verilog so my code probable doesn't make much sense to a hardware guy, since I am a software engineer so sorry if there are some rookie mistakes here.
As for the testbench, here is what I have:
`timescale 1ns / 1ps
module vtfContMax;
// Inputs
reg iClk;
reg iRst;
reg iCE;
reg iSignal;
// Outputs
wire oQ;
wire [3:0] orCnt;
// Instantiate the Unit Under Test (UUT)
contadorAscMax uut (
.iClk(iClk),
.iRst(iRst),
.oQ(oQ),
.iCE(iCE),
.iSignal(iSignal),
.orCnt(orCnt)
);
initial begin
// Initialize Inputs
iClk = 1;
iRst = 1;
iCE = 1;
iSignal = 0;
// Wait 100 ns for global reset to finish
#10;
iRst = 0;
repeat(10)
begin
repeat(10)
begin
wait(iClk);
wait(!iClk);
end
end
$stop();
// Add stimulus here
end
always
begin
#5;
iClk = ~iClk;
#10
iSignal = ~iSignal;
end
endmodule
Thanks for any help :)
You have split the code in a register and combinatorial section. Although that is a good idea for complex logic, for a simple 4 bit counter it is a bit over the top.
For solving your problem you are close. The trick with code like this, is to make the definition using 'programming' language. Then the code flows from that.
I want to have a counter which goes from 1111 to 0000 when a signal is present, else I want it to count up.
This then leads to:
always #(clk or posedge reset)
begin
if (reset)
count <= 4'b1111;
else
begin
if (count==4'b1111 && start_signal)
count <= 4'b0000;
else
count <= count + 4'b0001
end
end
What you don't mention, but what I see from your code you also have an enable (iCE) and an unused output oQ. The total then becomes:
module contadorAscMax
(
input iClk,
input iRst,
// output oQ,
input iCE,
input iSignal,
output reg [3:0] orCnt
);
always #(iClk or posedge iRst)
begin
if (iRst)
orCnt <= 4'b0000; // or should that be 4'b1111
// Is this really what you want?
// It will start counting after a reset!
else
begin
if (iCE)
begin
if (orCnt==4'b1111 && iSignal)
orCnt <= 4'b0000;
else
orCnt <= orCnt+ 4'b0001;
end
end
end
endmodule
Some more remarks:
Your reset condition looks flawed to me but you have to solve that.
Give the counter enable signal a decent name: 'count_enable' not 'signal'.
Last: I would not use all the 'i's and 'o's. The 'o' signals from one module will be the 'i' of another. Thus you have to change the signal names somewhere. It is better to have a defined signal in your system. If only so you can find in the timing report or gates after synthesis.

Verilog code 2 errors i can't find: Would be grateful for an extra pair of eyes to spot a mistake i might've overlooked

I'm writing a verilog code where i'm reading two files and saving those numbers into registers. I'm then multiplying them and adding them. Pretty much a Multiplication Accumulator. However i'm having a hard frustrating time with the code that i have. It read the numbers from the files correctly and it multiples but here is the problem? When i first run it using ModelSim, I reset everything so i can clear out the accumulator. I then begin the program, but there is always this huge delay in my "macc_out" and i cannot seem to figure out why. This delay should not be there and instead it should be getting the result out A*B+MAC. Even after the delay, it's not getting the correct output. My second problem is that if i go from reset high, to low (start the program) and then back to reset high ( to reset all my values), they do not reset! This is frustrating since i've been working on this for a week and don't know/can't see a bug. Im asking for an extra set of eyes to see if you can spot my mistake. Attached is my code with the instantiations and also my ModelSim functional Wave Form. Any help is appreciated!
module FSM(clk,start,reset,done,clock_count);
input clk, start, reset;
output reg done;
output reg[10:0] clock_count;
reg [0:0] macc_clear;
reg[5:0] Aread, Bread, Cin;
wire signed [7:0] a, b;
wire signed [18:0] macc_out;
reg [3:0] i,j,m;
reg add;
reg [0:0] go;
reg[17:0] c;
parameter n = 8;
reg[1:0] state;
reg [1:0] S0 = 2'b00;
reg [1:0] S1 = 2'b01;
reg [1:0] S2 = 2'b10;
reg [1:0] S3 = 2'b11;
ram_A Aout(.clk(clk), .addr(Aread), .q(a));
ram_B Bout(.clk(clk), .addr(Bread), .q(b));
mac macout(.clk(clk), .macc_clear(macc_clear), .A(a), .B(b), .macc_out(macc_out), .add(add));
ram_C C_in(.clk(clk), .addr(Cin), .q(c));
always #(posedge clk) begin
if (reset == 1) begin
i <= 0;
add<=0;
j <= 0;
m <= 0;
clock_count <= 0;
go <= 0;
macc_clear<=1;
end
else
state<=S0;
case(state)
S0: begin
// if (reset) begin
// i <= 0;
// add<=0;
// j <= 0;
// m <= 0;
// clock_count <= 0;
// go <= 0;
// macc_clear<=1;
// state <= S0;
// end
macc_clear<=1;
done<=0;
state <= S1;
end
S1: begin
add<=1;
macc_clear<=0;
clock_count<=clock_count+1;
m<=m+1;
Aread <= 8*m + i;
Bread <= 8*j + m;
if (m==7) begin
state <= S2;
macc_clear<=1;
add<=0;
end
else
state <=S1;
end
S2: begin
add<=1;
macc_clear<=0;
m<=0;
i<=i+1;
if (i<7)
state<=S1;
else if (i==8) begin
state<=S3;
add<=0;
end
end
S3: begin
add<=1;
i<=0;
j<=j+1;
if(j<7)
state<=S1;
else begin
state<=S0;
done<=1;
add<=0;
end
end
endcase
end
always # (posedge macc_clear) begin
Cin <= 8*j + i;
c <= macc_out;
end
endmodule
module mac(clk, macc_clear, A, B, macc_out, add);
input clk, macc_clear;
input signed [7:0] A, B;
input add;
output reg signed [18:0] macc_out;
reg signed [18:0] MAC;
always #( posedge clk) begin
if (macc_clear) begin
macc_out <= MAC;
MAC<=0;
end
else if (add) begin
MAC<=(A*B)+ MAC;
macc_out<=MAC;
end
end
endmodule
module ram_A( clk, addr,q);
output reg[7:0] q;
input [5:0] addr;
input clk;
reg [7:0] mem [0:63];
initial begin
$readmemb("ram_a_init.txt", mem);
end
always #(posedge clk) begin
q <= mem[addr];
end
endmodule
module ram_C(clk,addr, q);
input [18:0] q;
input [5:0] addr;
input clk;
reg [18:0] mem [0:63];
always #(posedge clk) begin
mem[addr] <= q;
end
endmodule
ModelSim Functional Simulation Wave Form
1) Take a look at the schematic view for your MACC module - I think some of your "problems" will be obvious from that;
2) Consider using an always#(*) (Combinational) block for your FSM control signals (stuff like add or macc_clear) rather than a always#(posedge clk) (sequential) - it makes the logic to assert them easier. Right now they're registered, so you have a cycle delay. ;
3) In your MAC, you clear the MAC register on a reset, but you don't clear the macc_out register.
In short, I think you need to step back, and consider which signals are combinational logic, and which ones are sequential and need to be in registers.

My Verilog behavioral code getting simulated properly but not working as expected on FPGA

I wrote a behavioral program for booth multiplier(radix 2) using state machine concept. I am getting the the results properly during the program simulation using modelsim, but when I port it to fpga (spartan 3) the results are not as expected.
Where have I gone wrong?
module booth_using_statemachine(Mul_A,Mul_B,Mul_Result,clk,reset);
input Mul_A,Mul_B,clk,reset;
output Mul_Result;
wire [7:0] Mul_A,Mul_B;
reg [7:0] Mul_Result;
reg [15:0] R_B;
reg [7:0] R_A;
reg prev;
reg [1:0] state;
reg [3:0] count;
parameter start=1 ,add=2 ,shift=3;
always #(state)
begin
case(state)
start:
begin
R_A <= Mul_A;
R_B <= {8'b00000000,Mul_B};
prev <= 1'b0;
count <= 3'b000;
Mul_Result <= R_B[7:0];
end
add:
begin
case({R_B[0],prev})
2'b00:
begin
prev <= 1'b0;
end
2'b01:
begin
R_B[15:8] <= R_B[15:8] + R_A;
prev <= 1'b0;
end
2'b10:
begin
R_B[15:8] <= R_B[15:8] - R_A;
prev <= 1'b1;
end
2'b11:
begin
prev <=1'b1;
end
endcase
end
shift:
begin
R_B <= {R_B[15],R_B[15:1]};
count <= count + 1;
end
endcase
end
always #(posedge clk or posedge reset)
begin
if(reset==1)
state <= start;
else
begin
case(state)
start:
state <= add;
add:
state <= shift;
shift:
begin
if(count>7)
state <= start;
else
state <=add;
end
endcase
end
end
endmodule
You have an incomplete sensitivity list in your combinational always block. Change:
always #(state)
to:
always #*
This may be synthesizing latches.
Use blocking assignments in your combinational always block. Change <= to =.
Good synthesis and linting tools should warn you about these constructs.
Follow the following checklist if something does work in the simulation but not in reality:
Did you have initialized every register? (yes)
Do you use 2 registers for one working variable that you transfer after each clock (no)
(use for state 2 signals/wires, for example state and state_next and transfer after each clock state_next to state)
A Example for the second point is here, you need the next stage logic, the current state logic and the output logic.
For more informations about how to proper code a FSM for an FPGA see here (go to HDL Coding Techniques -> Basic HDL Coding Techniques)
You've got various problems here.
Your sensitivity list for the first always block is incomplete. You're only looking at state, but there's numerous other signals which need to be in there. If your tools support it, use always #*, which automatically generates the sensitivity list. Change this and your code will start to simulate like it's running on the FPGA.
This is hiding the other problems with the code because it's causing signals to update at the wrong time. You've managed to get your code to work in the simulator, but it's based on a lie. The lie is that R_A, R_B, prev, count & Mul_Result are only dependent on changes in state, but there's more signals which are inputs to that logic.
You've fallen into the trap that the Verilog keyword reg creates registers. It doesn't. I know it's silly, but that's the way it is. What reg means is that it's a variable that can be assigned to from a procedural block. wires can't be assigned to inside a procedural block.
A register is created when you assign something within a clocked procedural block (see footnote), like your state variable. R_A, R_B, prev and count all appear to be holding values across cycles, so need to be registers. I'd change the code like this:
First I'd create a set of next_* variables. These will contain the value we want in each register next clock.
reg [15:0] next_R_B;
reg [7:0] next_R_A;
reg next_prev;
reg [3:0] next_count;
Then I'd change the clocked process to use these:
always #(posedge clk or posedge reset) begin
if(reset==1) begin
state <= start;
R_A <= '0;
R_B <= '0;
prev <= '0;
count <= '0;
end else begin
R_A <= next_R_A;
R_B <= next_R_B;
prev <= next_prev;
count <= next_count;
case (state)
.....
Then finally change the first process to assign to the next_* variables:
always #* begin
next_R_A <= R_A;
next_R_B <= R_B;
next_prev <= prev;
next_count <= count;
case(state)
start: begin
next_R_A <= Mul_A;
next_R_B <= {8'b00000000,Mul_B};
next_prev <= 1'b0;
next_count <= 3'b000;
Mul_Result <= R_B[7:0];
end
add: begin
case({R_B[0],prev})
2'b00: begin
next_prev <= 1'b0;
end
.....
Note:
All registers now have a reset
The next_ value for any register defaults to it's previous value.
next_ values are never read, except for the clocked process
non-next_ values are never written, except in the clocked process.
I also suspect you want Mul_Result to be a wire and have it assign Mul_Result = R_B[7:0]; rather than it being another register that's only updated in the start state, but I'm not sure what you're going for there.
A register is normally a reg, but a reg doesn't have to be a register.

Resources