ISE报错问题集锦(转载)

1、XST - "ERROR:Xst:902 - .v, line xx: Unexpected event in always block sensitivity list."

解决方法：Resolution 1
XST does not currently support logical operators in the sensitivity list. Because these logical operators are not evaluated during synthesis, there is no need to include them in the sensitivity list. Instead, include the operands in the sensitivity list and perform the logical operation in the procedural block.
For example:
Change the following:
always@(A && B)
if (A && B) ...
to the following:
always@(A or B)
if (A && B) ...
Resolution 2
XST also reports the above error if the sensitivity list is mixed between edge-sensitive and level-sensitive signals.
For example:
always @(posedge c or a or b or d) q <= a & b & d;
However, the above construct is illegal in Verilog. The sensitivity list must be either edge-sensitive or level-sensitive and not a combination of the two.
Resolution 3
XST also produces the above error message if a parameter is listed in the sensitivity list:
For example:
module test (in1, in2, out1);
parameter const = 5;
input [2:0] in1, in2;
output reg [3:0] out1;
always @(in1, in2, const)
out1 = in1 + in2 + const;
endmodule
Because parameters never change values (or are static at compile time), you do not need to include them in the sensitivity list and you can safely remove them.
Resolution 4
See (Xilinx Answer 20391).

 

2、ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test condition for is incompatible with the event declaration in the sensitivity list.

代码：

always @(posedge counter_increment or posedge reset)

     begin
  if (!reset)
   index <= index + 1;
  else
   index <= 5'b00000;
     end
 always @(posedge enable)

   out[index] <= in;
解决方法：问题出在，在always中，RESET是边沿触发的敏感信号，而在下面的描述中，RESET必须是高电平有效也就是说一切敏感事件必须在高电平时发生。可以修改如下：

always @(posedge counter_increment or posedge reset)

     begin
  if (reset)
   index <= index + 1;
  else
   index <= 5'b00000;
     end
 always @(posedge enable)

   out[index] <= in;

按以上修改，就能解决问题，主要是因为触发器的问题。

 

3、ERROR:Xst:880 - "mon.v" line 72: Cannot mix blocking and non blocking assignments on signal .

解决办法：

Solution

XST rejects Verilog designs if a given signal is assigned through both blocking and non-blocking assignments. For example:

always @(in1) begin
if (in2) out1 = in1;
else out1 <= in2;
end

If a variable is assigned in both a blocking and non-blocking assignment, the above error message is reported.
Restrictions also exist when blocking and non-blocking assignments are mixed on bits and slices. The following example will be rejected, even if there is no genuine mixing of blocking and non-blocking assignments:

if (in2) begin
out1[0] = 1'b0;
out1[1] <= in1;
end
else begin
out1[0] = in2;
out1[1] <= 1'b1;
end

Errors are checked at the signal level, not at the bit level. If there is more than a single blocking/non-blocking error, only the first one will be reported. In some cases, the line number for the error might be incorrect (as there might be multiple lines in which the signal has been assigned).

 

4、WARNING:Xst:647 - Input is never used. This port will be preserved and left unconnected if it belongs to a top-level block or it belongs to a sub-block and the hierarchy of this sub-block is preserved.
  解决办法：This particular port has been declared in your HDL description, but does not drive or is not driven by any internal logic.
Unused input ports will remain in the design, but they will be completely unconnected. If the port is not intended to be used, this message can be safely ignored. To avoid this message, remove any loadless or sourceless elements from your HDL description.
Output ports will remain in the final netlist and will be driven by a logic 0. To avoid the message and to save the port resource, remove the unused output port from your HDL description.

 

5、Xst:2677 - Node of sequential type is unconnected in block .

    解决办法：That warning is caused by lot of things.....
One main reason is if your outputs are not connected..ie if you are not reading the module outputs the ise optimisation step removes all signal inside your block and fire a 2677 warning...
check the module outputs

 

6、ERROR:ProjectMgmt:387 - TOE: ITclInterp::ExecuteCmd gave Tcl result 'error copying "mppr_result.par''

出错描述：

Setting a project to use both SmartGuide and Multi-pass, Place & Route generates the following error when the "Implement Design" process is run. 

 

"ERROR:Par:368 - SmartGuide and MPPR are incompatible. Please remove the -smartguide switch or the -n switch 

ERROR (dpm_executeCommand): par failed 

ERROR:ProjectMgmt:387 - TOE: ITclInterp::ExecuteCmd gave Tcl result 'error copying "mppr_result.par": no such file or directory'. 

Tcl_ErrnoId: ENOENT 

Tcl_ErrnoMsg: no such file or directory 

_cmd: ::Xilinx::Dpm::dpm_chTransformExecuteForPar dpm_parRun $piThisInterface 

errorInfo: error copying "mppr_result.par": no such file or directory 

while executing 

"file copy -force $_MpprReport $_MpprRpt " 

(procedure "dpm_parSortMpprResults" line 12) 

invoked from within 

"dpm_parSortMpprResults $sProjectDir" 

(procedure "::Xilinx::Dpm::dpm_chTransformExecuteForPar" line 79) 

invoked from within 

"::Xilinx::Dpm::dpm_chTransformExecuteForPar dpm_parRun $piThisInterface"

解决办法：

The usage is incorrect. SmartGuide and MPPR do not work together. The error from PAR clearly indicates this problem. However, Project Navigator should have prevented this use model or issued a warning when you set the incompatible properties. Additionally, the Project Navigator Tcl script for PAR should handle the inconsistency better. 

 

7、XST - "WARNING:Xst:737 - Found n-bit latch for signal "

问题描述以及产生原因：

Keywords: HDL Advisor
Urgency: Standard
General Description:
When a latch inference is discovered during HDL synthesis, XST reports the following HDL Advisor message:
"WARNING:Xst:737 - Found n-bit latch for signal ."
The listing for "n" is the width of the latch.
If latch inference is intended, you can safely ignore this message. However, some inefficient coding styles can lead to accidental latch inference. You should analyze your code to see if this result is intended. The examples below illustrate how you can avoid latch inference.

解决办法：

1、Include all possible cases in the case statement.
Verilog
always @ (SEL or DIN1 or DIN2)
begin
case (SEL)
2'b00 : DOUT <= DIN1 + DIN2;
2'b01 : DOUT <= DIN1 - DIN2;
2'b10 : DOUT <= DIN1;
endcase
end
VHDL
process (SEL, DIN1, DIN2)
begin
case SEL is
when "00" => DOUT <= DIN1 + DIN2;
when "01" => DOUT <= DIN1 - DIN2;
when "10" => DOUT <= DIN1;
end case;
end process;
These two examples create latches because there is no provision for the case when SEL = "11." To eliminate the latches, add another entry to deal with this possibility.
Verilog
2'b11 : DOUT <= DIN2;
VHDL
when "11" => DOUT <= DIN2;
Using the "DEFAULT" (Verilog) or "WHEN OTHERS" (VHDL) clause always works, but this can create extraneous logic. This is always the safest methodology, but might produce a larger and slower design since any unknown state has logic that is needed to bring it to a known state.

2、Assign to all the same outputs in each case.
Verilog
always @ (SEL or DIN1 or DIN2)
begin
case (SEL)
2'b00 : DOUT <= DIN1 + DIN2;
2'b01 : DOUT <= DIN1 - DIN2;
2'b10 : DOUT <= DIN1;
2'b11 :
begin
DOUT <= DIN2;
TEMP <= DIN1;
end
endcase
end
VHDL
process (SEL, DIN1, DIN2)
begin
case SEL is
when "00" => DOUT <= DIN1 + DIN2;
when "01" => DOUT <= DIN1 - DIN2;
when "10" => DOUT <= DIN1;
when "11" =>
DOUT <= DIN2;
TEMP <= DIN1;
end case;
end process;
These examples infer latches because the "11" case assigns two outputs, while the others assign only one. Looking at this case from TEMP's point of view, only one of four possible cases are specified, so it is incomplete. You can avoid this situation by assigning values to the exact same list of outputs for each case.

3、Make sure any "if / else if" statements have a concluding "else" clause:
VHDL:

process (ge, din) is begin
if (ge = '1') then
dout_a <= din;
else
dout_a <= '0'; -- This is a concluding "else" statement.
end if;
end process;

Verilog:

always @(ge