UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Newbie kevinlp12
Newbie
6,043 Views
Registered: ‎11-05-2013

Xst:737 and PhysDesignRules:372 warnings

This is my Verilog code for a programmable sequence detector. The code functions as expected in simulation, but gives me warnings when synthesizing and loading on to the FPGA:

 


module seq_det(
	input wire clk,
	input wire wreset,
	input wire wA,
	input wire wB,
	input wire wC,
	input wire Program,
	output reg LED
);

debouncer a_debounce(
    .clk(clk),
    .async_input(wA),
    .synchronized_debounced_pulse(A)
    );

debouncer b_debounce(
    .clk(clk),
    .async_input(wB),
    .synchronized_debounced_pulse(B)
    );
	 
debouncer c_debounce(
    .clk(clk),
    .async_input(wC),
    .synchronized_debounced_pulse(C)
    );

debouncer reset_debounce(
    .clk(clk),
    .async_input(wreset),
    .synchronized_debounced_pulse(reset)
    );
 
parameter S_IDLE = 0; //idle state
parameter S_PROG = 1; //programming state
parameter S_SEQ_STORE = 2; //storing sequence state
parameter S_DETECT =4; //detect matching sequence state
 
reg [2:0] next_state, state;
 
//sequential logic
always @ ( posedge clk ) 
	begin
	if ( reset ) 
		state <= S_IDLE;
	else 
		state <= next_state;
	end
 
wire buttonpress; 
wire [1:0]letter; //encodes A, B, or C as 2-bits

reg [1:0]seq[0:7]; //stored sequence in 8 x 2-bit register 
reg [3:0]seq_len = 3'b0; //stored sequence length
reg [3:0]det_len = 3'b0; //detected sequence length
 
//2-bit values are assigned to A, B, and C 
assign buttonpress = A | B | C;
assign letter = A ? 2'b00 : B ? 2'b01 : C ? 2'b10 : 2'b11;
 
//combinational logic
always @ ( seq[0], seq[1], seq[2], seq[3], seq[4], seq[5], seq[6], seq[7], state, Program, reset, buttonpress, seq_len, det_len, letter )
	begin
		next_state = S_IDLE; 
		case( state )
			S_IDLE: 	begin //IDLE STATE
						if ( Program ) 
								begin
								LED = 0;
								next_state = S_PROG; //programming mode enabled
								end
						else if ( reset ) 
								begin
								LED = 0;
								next_state = S_IDLE; //idle state, detected sequence length reset
								det_len = 3'b0;
								end
						else if ( buttonpress ) 
								begin
								next_state = S_DETECT; //button pressed, check for matching sequence
								end
						else 	
								next_state = S_IDLE; //else, idle state
						end
 
			S_PROG: 	begin //PROGRAMMING STATE
						seq_len = 3'b0; //lengths of stored and detected sequence cleared
						det_len = 3'b0;
						next_state = S_SEQ_STORE; //next state stores user-input sequence
						LED = 0;
						end
 
	 S_SEQ_STORE:	begin //STORING SEQUENCE STATE
						if ( buttonpress ) 
								begin
								seq[seq_len] = letter; //store button pressed
								seq_len = seq_len + 1; //increment stored sequence counter
								next_state = S_SEQ_STORE; //next state waits for button release;
								end
						else if ( !Program )
								next_state = S_IDLE; //program button de-asserted, next state idle
						else
								next_state = S_SEQ_STORE; //programming mode still enabled, continue storing sequence
						end
 
		S_DETECT: 	begin //DETECT MATCHING SEQUENCE STATE
						if ( buttonpress && ( letter == seq[det_len] ) ) //if button pressed and matches current stored 2-bit sequence value
								begin
								if ( det_len + 1 == seq_len ) //if length of current detection equals the length of the stored
										LED = 1; //match detected, LED on
								else 
									begin
										det_len = det_len + 1; //else, increment detection length counter
										next_state = S_DETECT; //wait for button release
									end
								end
						else if ( buttonpress && ( letter != seq[det_len]) ) //if button pressed and does not match current stored 2-bit sequence value
								begin
								det_len = 3'b0; //no match, reset detection
								LED = 0;
								next_state = S_IDLE;  
								end
						else
								next_state = S_IDLE;
						end
 
		  default:	begin
						next_state = S_IDLE;
						LED = 0;
						end 
		  
		endcase
  end
endmodule

 

Warnings:

 

WARNING:Xst:737 - Found 2-bit latch for signal <seq_0>. 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 2-bit latch for signal <seq_1>. 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 2-bit latch for signal <seq_2>. 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 2-bit latch for signal <seq_3>. 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 2-bit latch for signal <seq_4>. 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 2-bit latch for signal <seq_5>. 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 2-bit latch for signal <seq_6>. 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 2-bit latch for signal <seq_7>. 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 1-bit latch for signal <LED>. 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 <det_len>. 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 <seq_len>. 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:Security:42 - Your software subscription period has lapsed. Your current
WARNING:PhysDesignRules:372 - Gated clock. Clock net seq_len_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 seq_0_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 seq_1_cmp_eq0000 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 seq_2_cmp_eq0000 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 seq_3_cmp_eq0000 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 seq_4_cmp_eq0000 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 seq_5_cmp_eq0000 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 seq_6_cmp_eq0000 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 seq_7_cmp_eq0000 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 det_len_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 LED_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:Security:42 - Your software subscription period has lapsed. Your current version of Xilinx tools will continue
Phase 12  : 0 unrouted; (Par is working to improve performance)WARNING:Route:455 - CLK Net:seq_len_not0001 may have excessive skew because 
WARNING:Route:455 - CLK Net:det_len_not0001 may have excessive skew because 
WARNING:PhysDesignRules:372 - Gated clock. Clock net seq_len_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 seq_0_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 seq_1_cmp_eq0000 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 seq_2_cmp_eq0000 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 seq_3_cmp_eq0000 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 seq_4_cmp_eq0000 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 seq_5_cmp_eq0000 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 seq_6_cmp_eq0000 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 seq_7_cmp_eq0000 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 det_len_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 LED_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.

 

I've been working on this for weeks and can't find a solid solution to removing these warnings. Any help would be greatly appreciated. Thanks

0 Kudos
3 Replies
Advisor eilert
Advisor
6,030 Views
Registered: ‎08-14-2007

Re: Xst:737 and PhysDesignRules:372 warnings

Hi,

besides the latches, coming from incomplete ifs and cases in the combinatorical part of your design, the tool sees a lot of signals used as clocks for some reason.

Since these clocks are derived from internal logic they are using generic routing ressources, which causes problems due to heavy delays and skew. This must not happen unintended!

 

See the ISE language templates or search the web for proper verilog FSM coding techniques to identify the mistakes in your code.

 

btw.

A lot of code, no matter how badly written, works nice in simulation.

But just because in simulation most anything is allowed that can be expressed by the used language.

This is no guarantee that you will be able to synthesize this code at all. Or even if synthesizable that the code really behaves the same, e.g. due to stuff that is simply ignored by synthesis etc. .

 

 

Have a nice synthesis

 

  Eilert

0 Kudos
Teacher eteam00
Teacher
6,020 Views
Registered: ‎07-21-2009

Re: Xst:737 and PhysDesignRules:372 warnings

Here is an example of what Eilert is describing, from your posted code:

 

  case( state )
   S_IDLE:
    begin //IDLE STATE

     // LED = ??;      // default assignment for LED variable is missing

     // det_len = ??;  // default assignment for det_len variable is missing
     if ( Program )
       begin
        LED = 0;
        next_state = S_PROG; //programming mode enabled
       end
     else
      if ( reset )
       begin
        LED = 0;
        next_state = S_IDLE; //idle state, detected sequence length reset
        det_len = 3'b0;
       end
      else  // no assignment for LED or det_len here
       if ( buttonpress )
        begin
         next_state = S_DETECT; //button pressed, check for matching sequence
        end
       else  
        next_state = S_IDLE; //else, idle state
     end

 

You have not defined assignments for LED or det_len for all possible conditions, so the synthesiser has no choice but to infer a latch -- a storage element -- to maintain unchanged values for these variables.  The variables tested for conditional assignment will become the latch enables -- the clocks -- for these storage elements.

 

As an aside:  Thank you for well-formatted code in your posting.  It helps greatly that your code is presented in a readable form.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Highlighted
Historian
Historian
6,013 Views
Registered: ‎01-23-2009

Re: Xst:737 and PhysDesignRules:372 warnings

You need to take a step back and think hardware.

 

For everything in this code you have to think about exactly what you expect in terms of hardware for what you are writing. You have done this for your actual state machine bits (state), which are implemented as flip-flops. But what about everything else?

 

Of particular concern are the seq, seq_len, and det_len... What are these?

 

In your "next state" calculation you have things coded as

 

  seq_len = seq_len+1

  det_len = det_len+1

 

What are these supposed to be in hardware? Are they flip-flops? No - they are not updated only on the positive edge of the clock, they are updated under certain conditions in your next_state calculation (which is combinatorial logic). But yet, you expect them to hold state. So what are they? The answer is "unintentional latches".

 

Next, the "seq". What is this? It has eight 2 bit entries. But what are they? Again, you expect them to hold state, but what are they?

   - are they to be implemented in a block RAM? No. A block RAM has a clocked read and a clocked write. You are updating their value combinatorially

  - are they to be implemented in a distributed RAM? No. A distributed RAM has a clocked write, but can use an asynchronous (or combinatorial) read

  - are they to be implemented in 16 flip-flops? No. Again, they are updated in combinatorial process.

 

So what are they? Again, the answer is "latches".

 

So your code is fundamentally flawed. You haven't actually figured out how you are going to manage seq_len, dec_len and seq as hardware constructs. You have basically coded them as if you were coding in C...

 

You need to architect this design, and then write RTL that matches the architecture you have in mind.

 

(And, as bassman will say) - the two process state machine is always error prone. I acknowledge that there are sometimes reasons to use the two process state machine, but it is really the exception, rather than the rule. The original dogma for using the two process state machine comes from a limitiation in Synopsys Design Compiler prior to something like version 3.1 - that reason hasn't existed since the early 90's (more than 20 years ago!). Its time that universities stop teaching the two process state machine, and teach the one process state machine as the "norm", and advocate using the 2 process one only when there are specific reasons for doing so.

 

Avrum

Tags (1)