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.
Related
I am struggling to understand why the output flickers between 0 and 1, when the output should constantly remain 0 since the reduction OR gate of 000 is 0 not 1.
When I tried a different bit width, the problem suddenly disappeared. However, I would like to know what is going on rather than relying on randomness for correctness.
project_test .sv
`timescale 1ns/1ns
module project_test
( input logic clk, rst,
input logic in,
output logic [2:0] c
);
logic [2:0] out;
always#(posedge clk or posedge rst) begin
if(rst)
out <= 'b0;
else if(in) begin
if(|out)
out <= 'b0;
end
else
out <= out + 1'b1;
end
assign c = out;
endmodule: project_test
testbench.sv
`timescale 1ns/1ns
module testbench;
logic clk, rst;
logic in;
logic [2:0] c;
project_test project_test(
.clk(clk),
.rst(rst),
.in(in),
.c(c)
);
initial begin
clk = 0;
rst = 1;
in = 0 ;
#30
rst = 0;
#20;
in = 1;
#500;
rst=1;
#100ns;
$stop();
end
always#(clk) begin
#10ns clk <= !clk;
end
endmodule
Simulation output:
RTL viewer:
That is an improper way to generate a clock signal in the testbench. You should not have the clk signal in the sensitivity list because it keeps re-triggerring the always block. Your clock generator potentially adds events to the Verilog event queue, which can cause odd behavior. In fact, when I ran your code on the Cadence simulator, I did not see the clock toggling at all.
This is a more standard way to generate a clock:
always begin
#10ns clk = !clk;
end
You are using a very verbose implementation. Why can't you do something like below.
always#(posedge clk or posedge rst)
begin
if(rst)
out <= 'd0;
else
out <= (in) ? 'd0 : (out + 1'b1);
end
I'm trying to delay two signals. I wrote a register to do that and instantiated it but a strange thing happens. Delaying "state" signal seems to work, but delaying "nb_bits" signal doesn't.
Here's my code for the register:
`timescale 1ns / 1ps
module register(
input CLK,
input clr,
input en,
input [7:0] in,
output [7:0] out
);
reg [7:0] temp;
always # (posedge CLK or posedge clr) begin
if (clr) begin
temp <= 8'b00010000;
end
else if (en) begin
temp <= in;
end
else begin
temp <= temp;
end
end
assign out = temp;
endmodule
And that's ma instantiation:
wire [3:0] nbb;
nb_bits_register nb_bits_reg(
.CLK(CLK),
.clr(clr),
.en(en),
.in(nb_bits),
.out(nbb)
);
wire [7:0] stt;
register state_reg(
.CLK(CLK),
.clr(clr),
.en(en),
.in(state),
.out(stt)
);
nb_bits_register module is analogical; I didn't want to parametrize before solving this problem.
`timescale 1ns / 1ps
module nb_bits_register(
input CLK,
input clr,
input en,
input [3:0] in,
output [3:0] out
);
reg [3:0] temp;
always # (posedge CLK or posedge clr) begin
if (clr) begin
temp <= 4'b0000;
end
else if (en) begin
temp <= in;
end
else begin
temp <= temp;
end
end
assign out = temp;
endmodule
And here's a simulation:
enter image description here
And testbench:
`timescale 1ns / 1ps
module state_machine_tb();
reg CLK, clr, en;
reg [7:0] symbol;
reg [3:0] nb_bits;
wire [7:0] state;
initial begin
CLK <= 1;
clr <= 0;
en <= 0;
symbol <= 8'b00110010;
nb_bits <= 1;
#10
clr <= 1;
en <= 1;
#10
clr <= 0;
symbol <= 8'b00110001;
nb_bits <= 1;
#10
symbol <= 8'b00110010;
nb_bits <= 2;
#10
symbol <= 8'b00110001;
nb_bits <= 1;
#10
symbol <= 8'b00110001;
nb_bits <= 1;
#10
symbol <= 8'b00110000;
nb_bits <= 3;
#10
$finish;
end
always begin
#5 CLK <= ~CLK;
end
state_machine state_machine_inst(
.CLK(CLK),
.clr(clr),
.en(en),
.symbol(symbol),
.nb_bits(nb_bits),
.state(state)
);
endmodule
It does seem like a rase condition in the scheduler. By definition from the Verilog LRM, the order of evaluating procedural blocks (always blocks and initial blocks) is indeterminate. You might notice a pattern with a particular simulator and version, but that patter can change when changing the simulator or changing the version of the same simulator.
Use blocking assignment with your clock (ex: always #5 CLK = ~CLK;). With will guarantee the CLK will be updated before other stimulus.
In the test bench, change all the #10 to #(posedge CLK). The timing will be the same, however it guarantees CLK was updated before evaluating the new values symbol and other stimulus.
FYI: If you change output [7:0] out to output reg [7:0] out you can assign out directly in your always block, removing the need for temp. This doesn't change anything functionally; just fewer variables and lines of code.
It seems like a race condition: your changes of nb_bits coincide with positive edges of CLK, so there's an ambiguity resolved by the simulator in this way:
change nb_bits (from 1 to 2, etc.)
change CLK from 0 to 1
execute in nb_bits_register: if (en) temp <= in; ... assign out = temp;
As the result, out = in in nb_bits_register.
A solution is to avoid this coincidence, e.g. by changing the first #10 in the testbench to #11.
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.
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.
I am currently working on random number generation using Verilog. Sources have indicated that using Linear Feedback Shift Registers are one of the best ways to randomize MSBs. So I decided to code and testbench an LFSR. Snippet is below:
module lfsr_counter(clk, reset, ce, lfsr_done);
input clk, reset, ce;
output lfsr_done;
reg lfsr_done;
reg [10:0] lfsr;
initial lfsr_done = 0;
wire d0,lfsr_equal;
xnor(d0,lfsr[10],lfsr[8]);
assign lfsr_equal = (lfsr == 11'h359);
always #(posedge clk,posedge reset) begin
if(reset) begin
lfsr <= 0;
lfsr_done <= 0;
end
else begin
if(ce)
lfsr <= lfsr_equal ? 11'h0 : {lfsr[9:0],d0};
lfsr_done <= lfsr_equal;
end
end
endmodule
module testbench();
reg clk, reset, ce;
wire lfsr_done;
lfsr_counter dut(clk, reset, ce, lfsr_done); // Design Under Test
initial
begin
reset = 0;
clk = 1;
ce = 0;
#100
ce = 1;
#200 $finish;
end
//Generate Clock
always #10 clk = !clk;
endmodule
But I keep getting these parse errors:
I don't really get it. I'm using Verilogger Pro btw
I think always block terms are separated by or, not a comma.
always #(posedge clk or posedge reset) begin