Can I make ModelSim simulation to display text (rather than a numeric value) on a signal? I have a couple of state-machine states say,
localparam S_IDLE = 2'b00;
localparam S_START = 2'b01;
localparam S_STOP = 2'b10;
Is there a way to display S_IDLE for example, on a signal rather than 00? Thanks.
One thing you can do that is should work across all simulators is to create a signal that holds an ascii string, and then change the radix of that signal to ascii in the simulation window:
reg [8*8-1:0] mytextsignal;
always#(state) begin
case(state)
S_IDLE : mytextsignal = " S_IDLE";
S_START: mytextsignal = " S_START";
S_STOP: mytextsignal = " S_STOP";
default: mytextsignal = " UNKNOWN";
endcase
end
It should show up as readable text in the waveform viewer.
In Modelsim you can add FSM using following steps:
use FSM recognition and FSM coverage options (+acc, +cover) during compile,
use the -fsmdebug and -coverage options on the vsim command line.
Check ModelSim User's Manual for more details. Notice that using View > FSM list you can check all FSMs detected by ModelSim and add it to a wave.
Related
Trying this on a Terasic DE10-Lite, programmed with Quartus Prime Lite Edition.
SW[0] is a switch. LEDR[0] is an LED. KEY[0] is a push button. The push button is active low.
I want to model a flip flop that stores SW[0] in register r0 and displays it in LEDR[0] when KEY[0] delivers a rising edge.
The following works as expected:
module flipfloptest (
input [9:0] SW,
input [1:0] KEY,
output [9:0] LEDR);
reg r0;
assign LEDR[0] = r0;
always #(posedge(~KEY[0]))
r0 <= SW[0];
endmodule
I now add another push button, KEY[1], to the sensitivity list with the intention that pushing either down will set the flip flop.
module flipfloptest (
input [9:0] SW,
input [1:0] KEY,
output [9:0] LEDR);
reg r0;
assign LEDR[0] = r0;
always #(posedge(~KEY[0]) or posedge(~KEY[1]))
r0 <= SW[0];
endmodule
This behaves like a latch (i.e. no longer edge triggered). LEDR[0] immediately reflects the state of SW[0] without the need to press either KEY[0] or KEY[1]. Pressing one or both does not affect behavior in any way.
Clearly, I don't understand the meaning of this sensitivity list. What is the correct interpretation?
More context: I can get the desired behavior using a clock and state machine as shown below. My question is why the sensitivity list isn't behaving intuitively.
module flipfloptest (
input MAX10_CLK1_50,
input [9:0] SW,
input [1:0] KEY,
output [9:0] LEDR);
reg [1:0] tic0, tic1;
reg r0;
assign LEDR[0] = r0;
always #(posedge MAX10_CLK1_50) begin
case (tic0)
0: tic0 = (~KEY[0])?1:0;
1: tic0 = (~KEY[0])?2:0;
2: tic0 = (~KEY[0])?2:0;
endcase
case (tic1)
0: tic1 = (~KEY[1])?1:0;
1: tic1 = (~KEY[1])?2:0;
2: tic1 = (~KEY[1])?2:0;
endcase
if (tic0==1 | tic1==1)
r0 <= SW[0];
end
endmodule
Synthesis tools only recognize certain Verilog coding patterns. Refer to synthesizable constructs. The documentation for your Quartus tool set should describe what coding styles are supported.
Your 1st and 3rd code examples adhere to the synthesizable coding style, whereas your 2nd example does not. You should look at the log files that your synthesis tools created: there should be messages in there warning you about unintended latches.
The code in your 2nd example is unusual. Perhaps your synthesis tool did not know what to do with it, and it just decided to give you a latch. Unfortunately for you, that is not how your code simulates.
This code:
always #(posedge(~KEY[0]) or posedge(~KEY[1]))
r0 <= SW[0];
can be simplified as:
always #(negedge KEY[0] or negedge KEY[1])
r0 <= SW[0];
r0 will be updated with SW[0] every time you get a negedge of either KEY[0] or KEY[1]. That does not behave like a latch. But, as I said, this code does not adhere to typical synthesis coding style.
My project is to use a CPDL, which I am programming in verilog to commutate a BLDC motor. Part of that process is to read in hall sensors A,B,C.
I want to count the amount of positive edges on A,B or C. I have a 3 bit variable [2:0] hallIn to store these inputs. The code below works in a modelsim simulation but not on an actual chip. How come? What is the proper way to do this? The error message I get is: 73:12:73:55|Can't mix posedge/negedge use with plain signal references
always # (posedge hallIn[2] or hallIn[1] or hallIn[0])
Synthesize code is a subset of what Verilog will let you do. Synthesizable code requires a coding structure that can be mapped to logic cells. Non-synthesizable code is intended for behavior modeling and test benches.
Flip-flops should normally be synchronized by a common clock source; not data. With a clock, you could detect the posedge data by comparing the inputs current value against it previous value.
Example:
assign posedge_detected = |(hallIn & ~prev_hallIn);
always #(posedge clock) begin
if (reset) begin
prev_hallIn <= 3'b000;
count <= 16'h0000;
end
else begin
prev_hallIn <= hallIn;
count <= count + posedge_detected;
end
end
end
I wrote some verilog code about a 7-to-1 Multiplexer with "always" and "case" statements but when I made a simulation in ModelSim, the outcome seems to not work as expected
Part of multiplexer logic :
when SW[9:7] = 000, OUT = SW[0]
Contradiction :
In the simulation when SW[0] is changed to 1, the outcome stays at 0.
module SevenToOneMUX(SW, OUT);
input [9:0] SW;
output reg OUT;
always#(SW[9:7])
begin
case (SW[9:7])
3'b000: OUT = SW[0];
3'b001: OUT = SW[1];
3'b010: OUT = SW[2];
3'b011: OUT = SW[3];
3'b100: OUT = SW[4];
3'b101: OUT = SW[5];
3'b110: OUT = SW[6];
endcase
end
endmodule
The problem is that you only put the 3 most-significant bit of SW in the sensitivity list of your combinational block. This means that the compiler will only execute the always#(SW[9:7]) block if SW[9:7] changes.
If you want to the simulator to update OUT when any of SW's bits changed, change your sensitivity list to the following:
always#(*)
begin
/*...*/
end
It is also worth to note that always#(*), which was added in Verilog-2001, is usually used when creating synthesizable combinational logic. In hardware, the real logic will be "sensitive" to every right-hand side variable. That means: if any input of the logic you describe changes, the output will also change.
I'm learning verilog and I think there is something that I must not understand about always #* and always (#posedge clk, ...)
Here is a piece of code supposed to send bits via uart. It fails at synthesization.
The error is
" The logic for does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release."
(and 3 other errors for , and )
If I change the always #(...) by always #*, things fail in the next step ("implement design") because things are not connected.
In the book that I have, they implement an fsmd with an always (posedge clk) for the state, and always #* for the other logic, but I don't understand why this doesn't work.
On another forum, I read that the error could come from too complicated conditions. But I have simplified things too (not code the code here but basically I removed the case(state) and the ifs to have single line assignments with ? : or binary conditions, but it didn't work either)
I have seen this error before in other pieces of code that I wrote but I didn't get to the bottom of it, so if you could help me understand the general problem (with this uart thing as a support for a concrete example), I would be very happy.
Thanks
Thomas
P.S : Im using xilinx spartan 3e starter kit and xilinx ise 14.4
module UART_out #(parameter [3:0] NUM_BITS = 8)
(
input wire baud_clk,
input wire send_tick,
input wire[NUM_BITS-1:0] data_in,
output wire tx,
output wire debug_done
);
localparam
IDLE = 0,
TRANSMIT = 1;
reg[NUM_BITS:0] bits_to_send;
reg state;
reg out_bit;
reg[4:0] cnt;
always #(posedge baud_clk, posedge send_tick)
begin
case (state)
IDLE:
if (send_tick)
begin
bits_to_send <= {data_in, 0};
state <= TRANSMIT;
cnt <= 0;
end
TRANSMIT:
begin
if (cnt < NUM_BITS)
cnt <= cnt + 1;
else
state <= IDLE;
bits_to_send <= {1, bits_to_send[NUM_BITS:1]};
out_bit <= bits_to_send[0];
end
endcase
end
assign tx = (state == IDLE ? 1 : out_bit);
assign debug_done = (state == IDLE);
endmodule
The error:
The logic for does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
Is referring to the fact that the synthesis tool does not have any hardware cells to use which match your description.
What hardware do you want from :
always #(posedge baud_clk, posedge send_tick)
This looks like you want a flip-flop with an enable signal. The enable signal (send_tick) should be 1 clock period wide. This is then used to select the path of logic on a clock edge. not as an alternative trigger.
I think that this is all you really need:
always #(posedge baud_clk) begin
case (state)
IDLE:
if (send_tick) begin
//...
end
//...
endcase
end
If send_tick is from another clock domain then you will need to do some clock domain crossing to turn it it to a clock wide pulse on the baud_clk.
You may be getting confused with blocks which have multiple triggers, they are normally a clk and reset. A negedge reset_n or posedge reset are often added for reset (initialisation) conditions.
If adding a reset :
always #(posedge baud_clk or negedge reset_n) begin
if (~reset_n) begin
//reset conditions
state <= IDLE;
//...
end
else begin
// Standard logic
end
end
You will notice that there is a very definite structure here, if reset else ... The synthesis tools recognise this as a flip-flop with an asynchronous reset. The data in the reset condition is also static, typically setting everything to zero.
I have been reading verilog code online and have noticed this in many of the code examples. Whenever an input is needed from a hardware source such as a button press, the input is copied to a flip flop and then AND'd with the invert of the input. I dont know if this made much sense but in code here it is:
input btn;
reg dff1, dff2;
wire db_tick;
always # (posedge clock) dff1 <= btn;
always # (posedge clock) dff2 <= dff1;
assign db_tick = ~dff1 & dff2;
And then db_tick is used as the button press.
In some cases this is also used as a rising edge detector, but cant a rising edge detector easily be implemented with always#(posedge signal)
It's called a monostable multivibrator or, specifically for digital circuits, a one-shot. The purpose of the circuit is to change an edge into a single cycle pulse.
When connected directly to a physical switch it can be a way to effect switch debouncing, but that's not really a good use for it. It's hard to say what the intent is in the code without more context.
This is providing edge detection synchronous to your clock domain. I do not see any debouncing happing here, it is quite common to also include 2 meta stability flip flops before the edge detection.
input a;
reg [2:0] a_meta;
always #(posedge clk or negedge rst_n) begin
if (~rst_n) begin
a_meta <= 3'b0 ;
end
else begin
a_meta <= {a_meta[1:0], a};
end
end
// The following signals will be 1 clk wide, Clock must be faster than event rate.
// a[2] is the oldest data,
// if new data (a[1]) is high and old data low we have just seen a rising edge.
wire a_sync_posedge = ~a_meta[2] & a_meta[1];
wire a_sync_negedge = a_meta[2] & ~a_meta[1];
wire a_sync_anyedge = a_meta[2] ^ a_meta[1]; //XOR