Simulation and Verification

[igrissom]

I have been working at this code for hours now and can't seem to figure out my mistake. Essentially, the code acts as a 4-bit binary to BCD converter. After the final value of each digit has been determined, it is sent to a module to print it out on a 7-segment display using cathode and anode. Behaviorally, the modules work fine. However, once translated, the code breaks down. A post-translation simulation reveals that "state" from the main module is being recognized as a 3-bit array, instead of 2. Any and all help is greatly appreciated. 

The following warnings are produced as well:

WARNING:Xst:646 - Signal <temp1> is assigned but never used. This unconnected signal will be trimmed during the optimization process.
WARNING:Xst:646 - Signal <T1> is assigned but never used. This unconnected signal will be trimmed during the optimization process.
WARNING:Xst:737 - Found 4-bit latch for signal <anode>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 7-bit latch for signal <cathode>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 8-bit latch for signal <switch_temp>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 4-bit latch for signal <hfinal>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 4-bit latch for signal <tfinal>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 4-bit latch for signal <ofinal>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 4-bit latch for signal <shift_counter>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 4-bit latch for signal <hundreds>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 4-bit latch for signal <tens>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 4-bit latch for signal <ones>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 8-bit latch for signal <binary>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:PhysDesignRules:372 - Gated clock. Clock net tens_not0001 is sourced by
   a combinatorial pin. This is not good design practice. Use the CE pin to
   control the loading of data into the flip-flop.
WARNING:PhysDesignRules:372 - Gated clock. Clock net shift_counter_or0000 is
   sourced by a combinatorial pin. This is not good design practice. Use the CE
   pin to control the loading of data into the flip-flop.
WARNING:PhysDesignRules:372 - Gated clock. Clock net control/anode_or0000 is
   sourced by a combinatorial pin. This is not good design practice. Use the CE
   pin to control the loading of data into the flip-flop.
WARNING:PhysDesignRules:372 - Gated clock. Clock net hundreds_not0001 is sourced
   by a combinatorial pin. This is not good design practice. Use the CE pin to
   control the loading of data into the flip-flop.
WARNING:PhysDesignRules:372 - Gated clock. Clock net ones_not0001 is sourced by
   a combinatorial pin. This is not good design practice. Use the CE pin to
   control the loading of data into the flip-flop.
WARNING:Route:455 - CLK Net:tens_not0001 may have excessive skew because 
(Par is working to improve performance)(Par is working to improve performance)WARNING:Route:455 - CLK Net:control/anode_or0000 may have excessive skew because 
WARNING:Route:455 - CLK Net:hundreds_not0001 may have excessive skew because 
WARNING:Route:455 - CLK Net:state<0> may have excessive skew because 
WARNING:Route:455 - CLK Net:clock/Milli_sec_clock may have excessive skew because 
WARNING:Route:455 - CLK Net:state<2> may have excessive skew because 

Here is the main module:

module Binary_Display
	(input CLK_50M, 
	input [7:0] switches, 
	input reset, 
	output [6:0] cathode, 
	output [3:0] anode);
	
	parameter [1:0] 	CLEAR = 2'b00,
							SHIFT = 2'b01,
							ADD_3 = 2'b10;
					
	wire mili_clk;
	reg [1:0] state, next = 0;
	reg [7:0] switch_temp, binary;
	reg [3:0] hundreds, tens, ones, hfinal, tfinal, ofinal;
	reg [3:0] shift_counter;
	
	Top_Module clock
	(.CLK_50M(CLK_50M),
	.reset(reset),
	.Milli_sec_clock(mili_clk));
	
	Display control
	(.clk_mili(mili_clk),
	.hundreds(hfinal),
	.tens(tfinal),
	.ones(ofinal),
	.reset(reset),
	.anode(anode),
	.cathode(cathode));
	
	always @ (posedge CLK_50M or posedge reset) begin
		if (reset) begin
			state <= CLEAR;
		end else if (switch_temp != switches) begin
			state <= CLEAR;
		end else begin
			state <= next;
		end
	end
	
	always @* begin
		next = state;
		case (state)
			CLEAR:	begin
							switch_temp = switches;
							shift_counter = 0;
							hundreds = 0;
							tens = 0;
							ones = 0;
							binary = switches;
							next = SHIFT;
						end
			SHIFT:	begin
							hundreds = {hundreds[2:0], tens[3]};
							tens = {tens[2:0], ones[3]};
							ones = {ones[2:0], binary[7]};
							binary = {binary[6:0], 1'b0};
							shift_counter = shift_counter + 1;
							next = ADD_3;
						end
			ADD_3:	begin
							if (shift_counter == 8) begin
								hfinal = hundreds;
								tfinal = tens;
								ofinal = ones;
								next = CLEAR;
							end
							else begin
								if (hundreds > 4) begin
									hundreds = hundreds + 3;
								end
								if (tens > 4) begin
									tens = tens + 3;
								end
								if (ones > 4) begin
									ones = ones + 3;
								end
								next = SHIFT;
							end
						end
			default: next = CLEAR;
		endcase
	end
endmodule

This is the module being used to control the display:

module Display
	(input clk_mili,
	input [3:0] hundreds,
	input [3:0] tens,
	input [3:0] ones,
	input reset,
	output reg [3:0] anode,
	output reg [6:0] cathode);
	
	parameter [2:0]	state1 = 3'b000,
							state2 = 3'b001,
							state3 = 3'b010,
							state4 = 3'b011,
							state5 = 3'b100;
					
	reg [2:0] state, next;
	reg [3:0] T1;
	reg [6:0] temp1;
	
	always@ (posedge clk_mili or posedge reset) begin
		if (reset) begin
			state <= state1;
		end else begin
			state <= next;
		end
	end
	
	always@ * begin
		case (state)
			state1:	begin
							cathode = 1;
							anode = 0;
							next = state2;
						end
			state2:	begin
							anode = 4'b1110;
							T1 = ones;
							case (T1)
								0: temp1 = 7'b0000001;
								1:	temp1 = 7'b1001111;
								2: temp1 = 7'b0010010;
								3:	temp1 = 7'b0000110;
								4:	temp1 = 7'b1001100;
								5:	temp1 = 7'b0100100;
								6:	temp1 = 7'b0100000;
								7: temp1 = 7'b0001111;
								8: temp1 = 7'b0000000;
								9: temp1 = 7'b0000100;
								10: temp1 = 7'b0001000;
								11: temp1 = 7'b1100000;
								12: temp1 = 7'b0110001;
								13: temp1 = 7'b1000010;
								14: temp1 = 7'b0110000;
								15: temp1 = 7'b0111000;
							endcase
							cathode = temp1;
							next = state3;
						end
			state3:	begin
							anode = 4'b1101;
							T1 = tens;
							case (T1)
								0: temp1 = 7'b0000001;
								1:	temp1 = 7'b1001111;
								2: temp1 = 7'b0010010;
								3:	temp1 = 7'b0000110;
								4:	temp1 = 7'b1001100;
								5:	temp1 = 7'b0100100;
								6:	temp1 = 7'b0100000;
								7: temp1 = 7'b0001111;
								8: temp1 = 7'b0000000;
								9: temp1 = 7'b0000100;
								10: temp1 = 7'b0001000;
								11: temp1 = 7'b1100000;
								12: temp1 = 7'b0110001;
								13: temp1 = 7'b1000010;
								14: temp1 = 7'b0110000;
								15: temp1 = 7'b0111000;
							endcase
							cathode = temp1;
							next = state4;
						end
			state4:	begin
							anode = 4'b1011;
							T1 = hundreds;
							case (T1)
								0: temp1 = 7'b0000001;
								1:	temp1 = 7'b1001111;
								2: temp1 = 7'b0010010;
								3:	temp1 = 7'b0000110;
								4:	temp1 = 7'b1001100;
								5:	temp1 = 7'b0100100;
								6:	temp1 = 7'b0100000;
								7: temp1 = 7'b0001111;
								8: temp1 = 7'b0000000;
								9: temp1 = 7'b0000100;
								10: temp1 = 7'b0001000;
								11: temp1 = 7'b1100000;
								12: temp1 = 7'b0110001;
								13: temp1 = 7'b1000010;
								14: temp1 = 7'b0110000;
								15: temp1 = 7'b0111000;
							endcase
							cathode = temp1;
							next = state5;
						end
			state5:	begin
							anode = 4'b0111;
							cathode = 1;
							next = state2;
						end
			3'b101:	next = state1;
			3'b110:	next = state1;
			3'b111:	next = state1;
			default: next = state1;
		endcase
	end
endmodule

And finally this is the module used to generate a 1 millisecond clock:

module Top_Module
	(input CLK_50M,
	input reset,
	output reg Milli_sec_clock);
	
	reg [14:0] counter = 0;
		
	always @ (posedge CLK_50M or posedge reset) begin
		if (reset) begin
			Milli_sec_clock <= 0;
			counter <= 1;
		end else begin
			if (counter == 25000) begin
				Milli_sec_clock <= ~Milli_sec_clock;
				counter <= 1;
			end else if (counter == 0) begin
				Milli_sec_clock <= 0;
				counter <= 1;
			end else begin
				counter <= counter + 1;
			end
		end
	end
endmodule

[eteam00]

I have been working at this code for hours now and can't seem to figure out my mistake.

Mistakes, not mistake.  Plural.  Is this a school assignment?  Have you asked your instructor for help?

Essentially, the code acts as a 4-bit binary to BCD converter.

We are engineers here.  Precise communication is essential.  Please distinguish between design intent and actual design behaviour.

After the final value of each digit has been determined, it is sent to a module to print it out on a 7-segment display using cathode and anode. Behaviorally, the modules work fine. However, once translated...

You mean:  once synthesised.  Correct?

... the code breaks down.

What should 'breaks down' mean to us?  Please don't make us guess.

A post-translation simulation reveals that "state" from the main module is being recognized as a 3-bit array, instead of 2.

Are you sure you are correctly distinguishing the multiple variables named 'state' ?

Any and all help is greatly appreciated.

The best help you can provide for yourself is to continue your Verilog study course and continue your logic system design course.  If you aren't enrolled, you should consider it.  The mistakes you are making are typical of very early beginners.

I don't think you are quite ready for the complexity of the multi-process design you are attempting.  IYou should have a better understanding of a clocked process and  a better understanding of a combinatorial process before you move on to combining the two types in a multi-process design.  Take one step at a time, building your confidence, knowledge and skills along the way.

I'll try to sum up some of your coding practices which need to be corrected and understood.

1.  Outputs of combinatorial logic (wires and/or gates) cannot be fed back into itself, without some intermediate state (i.e. clocked registers).  Even if the synthesiser permitted this as acceptable syntax, there is no hardware construct for strictly combinatorial gates which feed back once and only once from output to input to output.  For example:

hundreds = {hundreds[2:0], tens[3]};

2.  Comments are always good.  They provide a correspondence between your design implementation (i.e. code) and your design intent.  Some consider the absence of comments a matter of style.  I consider it mistaken coding practice and lack of discipline, unless proven otherwise.

3.  Although not an error, the use of two-process state machines is unnecessarily complicated.  This practice results in more code, more errors, and more debugging.   You will live longer, be happier, and be more productive if you learn to code state machines with a single clocked process.

4.  For the synthesiser, the difference between a latch and a combinatorial mux is simple:

• For a combinatorial mux, all the leaves of conditional statements (e.g. IF-THEN-ELSE, CASE) are fully populated with value assignments for all variables.

• For a latch, some leaves of conditional statements (e.g. IF-THEN-ELSE, CASE) are missing assignments for some variables -- and this implies storage (i.e. latching).

The multiple inferred LATCH and GATED CLOCK warnings are ample evidence that you are inadvertently inferring latches with incomplete conditional coding.  If a combinatorial variable is assigned a value in one leaf, it must be assigned a value in all leaves.

5.  In Top_Module, how does register counter reach the value of 0?

This should hopefully be of some help to you.

-- Bob Elkind

[igrissom]

Thank you for the feedback. I am indeed a student taking my first course in digital logic hardware/software. I apologize for my lack of understanding and clarity in my first post. 

The module was designed with the intent to convert an 8-bit binary input to a BCD output. When I said the module behavior was working as intended, this was based of the behavioral test-bench. When simulated with the behavioural test-bench, the code succesfully outputs the correct binary sequences to the anode and the cathode at 1ms intervals.

The problems occur when I attempt to run a post-translate, post-map, or post-route simulation. At this point, the signals no longer act as expected.

I have re-written the code to run using a single FSM, yet still get many of the same warnings. I did learn a little more about the variable "state" from the primary module. When the number of states of the FSM was increased from 3 to 4, state became a 4-bit register, when it was declared as a 2-bit register. This would make me think that the optimization process is converting the register "state" to be used in a one-hot coding method. I do not know if this is the case or not. 

I have not yet fixed the "hundreds', "tens", or "ones", problem where they are feeding into themselves yet, but I will do so, thank you. 

In Top_Module, counter never reaches the value of zero. Instead, it is reset to 1. This way the output will rise and fall at exactly .5 ms. 

Currently, this is what my code looks like:

module Binary_Display
	(input CLK_50M, 
	input [7:0] switches, 
	input reset, 
	output reg [6:0] cathode, 
	output reg [3:0] anode);
	
	parameter [1:0] 	CLEAR = 2'b00,
							SHIFT = 2'b01,
							ADD_3 = 2'b10,
							DISP = 2'b11;
					
	wire mili_clk;
	reg [1:0] state = 2'b00, next = 0;
	reg [7:0] switch_temp, binary;
	reg [3:0] hundreds, tens, ones, hfinal, tfinal, ofinal, T1;
	reg [3:0] shift_counter;
	reg [1:0] disp_counter;
	reg [6:0] temp1;
	reg flag;
	reg [2:0] shift_reg, temp_shift;
	
	Top_Module clock
	(.CLK_50M(CLK_50M),
	.reset(reset),
	.Milli_sec_clock(mili_clk));
	
	always @ (posedge CLK_50M or posedge reset) begin
		if (reset) begin
			state <= CLEAR;
		end else if (switch_temp != switches) begin
			state <= CLEAR;
		end else begin
			state <= next;
		end
		
		temp_shift = shift_reg[1:0];
		shift_reg = {temp_shift, mili_clk};
		if (reset) begin
			flag = 0;
			shift_reg = 3'b000;
		end
		else begin
			if (shift_reg == 3'b011) begin
				flag = 1;
			end
			else begin
				flag = 0;
			end
		end
	end
	
	always @* begin
		next = state;
		case (state)
			CLEAR:	begin
							switch_temp = switches;
							shift_counter = 0;
							hundreds = 0;
							tens = 0;
							ones = 0;
							binary = switches;
							next = SHIFT;
							disp_counter = 0;
							cathode = 1;
							anode = 0;
						end
			SHIFT:	begin
							hundreds = {hundreds[2:0], tens[3]};
							tens = {tens[2:0], ones[3]};
							ones = {ones[2:0], binary[7]};
							binary = {binary[6:0], 1'b0};
							shift_counter = shift_counter + 1;
							next = ADD_3;
						end
			ADD_3:	begin
							if (shift_counter == 8) begin
								hfinal = hundreds;
								tfinal = tens;
								ofinal = ones;
								next = DISP;
							end
							else begin
								if (hundreds > 4) begin
									hundreds = hundreds + 3;
								end
								if (tens > 4) begin
									tens = tens + 3;
								end
								if (ones > 4) begin
									ones = ones + 3;
								end
								next = SHIFT;
							end
						end
			DISP:
						begin
							if (flag == 1) begin
								if (reset) begin
									anode = 0;
									cathode = 1;
								end else begin
									if (disp_counter == 0) begin
										T1 = ofinal;
									end else if (disp_counter == 1) begin
										T1 = tfinal;
									end else if (disp_counter == 2) begin
										T1 = hfinal;
									end else begin
										cathode = 1;
									end
									case (T1)
										0: temp1 = 7'b0000001;
										1:	temp1 = 7'b1001111;
										2: temp1 = 7'b0010010;
										3:	temp1 = 7'b0000110;
										4:	temp1 = 7'b1001100;
										5:	temp1 = 7'b0100100;
										6:	temp1 = 7'b0100000;
										7: temp1 = 7'b0001111;
										8: temp1 = 7'b0000000;
										9: temp1 = 7'b0000100;
										10: temp1 = 7'b0001000;
										11: temp1 = 7'b1100000;
										12: temp1 = 7'b0110001;
										13: temp1 = 7'b1000010;
										14: temp1 = 7'b0110000;
										15: temp1 = 7'b0111000;
									endcase
									
									if (disp_counter == 0) begin
										anode = 4'b1110;
										cathode = temp1;
									end else if (disp_counter == 1) begin
										anode = 4'b1101;
										cathode = temp1;
									end else if (disp_counter == 2) begin
										anode = 4'b1011;
										cathode = temp1;
									end else begin
										anode = 4'b0111;
									end
									
									disp_counter = disp_counter + 1;
									if (disp_counter == 4) begin
										disp_counter = 0;
									end
								end
								next = DISP;
							end
						end	
			default: next = CLEAR;
		endcase
	end
endmodule

Again, thank you for your understanding and your help.

[eteam00]

I am indeed a student taking my first course in digital logic hardware/software.

Why aren't you discussing your code with your instructor(s)?  Not only does this give them a chance to do the job for which you are paying them  -- in a manner consistent with their course curriculum -- but this also gives them feedback on topics and applications where additional teaching time should be devoted.

I have re-written the code to run using a single FSM, yet still get many of the same warnings.

That's OK.  Most of the warnings you posted had no reference to the simple FSM.

In Top_Module, counter never reaches the value of zero. Instead, it is reset to 1. This way the output will rise and fall at exactly .5 ms.

Check the added highlights in the quoted code below.  I've taken the liberty of deleting (strike-through) several unnecessary BEGIN-ENDs in your code (it's one of my pet peeves).

always @ (posedge CLK_50M or posedge reset) begin
  if (reset) begin
    Milli_sec_clock <= 0;
    counter <= 1;
  end else begin
    if (counter == 25000) begin
      Milli_sec_clock <= ~Milli_sec_clock;
      counter <= 1;
    end else if (counter == 0) begin // this never happens, right?
      Milli_sec_clock <= 0;
      counter <= 1;
   end else begin
      counter <= counter + 1;
      end
  end
    end

-- Bob Elkind

[igrissom]

I have been unable to get in contact with my professor. I have tried several times. This project has been assigned and was already suppose to have been completed. I am not going back and attempting to complete it on my own time. When he responds, I will certaintly inform him of my difficulties. For now though, I feel the need to make sure I can figure out as many of my problems as possible. 

Sadly, I agree with you. Myself and most my classmates were poorly prepared for the assignment. Most people did not get any form of a working design. 

Thank you for the advice.

I have another question related to the warning messages I get. 

For warning like: "WARNING:Xst:646 - Signal <temp1> is assigned but never used. This unconnected signal will be trimmed during the optimization process."

Signals, such as the one in the warning message, are assigned and then used for conditional purposes. How do I prevent them from being trimmed?

[eteam00]

Signals, such as the one in the warning message, are assigned and then used for conditional purposes. How do I prevent them from being trimmed?

See Answer Record #23990.

-- Bob Elkind

[igrissom]

Again, thank you.

Where should I start looking, if I want to figure out why the bit-size of my "state" register changes? I've made sure that I am not assigning state to any value larger than 2-bits. I still suspect that "state" has been converted to be used for one-hot. Shouldn't the use of "parameter" have stopped that from happeneing though?

[eteam00]

I have re-written the code to run using a single FSM

Watch the use of blocking assignments ("=") in a clocked process.  Probably a holdover from the merge of combinatorial process into clocked process.

-- Bob Elkind

[igrissom]

Should I not be using blocking assignment in my second always block then? Several of the assignment depend on the sequential nature of the code. 

[eteam00]

Where should I start looking, if I want to figure out why the bit-size of my "state" register changes? I've made sure that I am not assigning state to any value larger than 2-bits. I still suspect that "state" has been converted to be used for one-hot. Shouldn't the use of "parameter" have stopped that from happeneing though?

There is a setting for default handling of state machine encoding.  Right-click on Synthesis-XST, select Process Properties:

 -- Bob Elkind