Differences

This shows you the differences between two versions of the page.

Link to this comparison view

xilinx:xst_messages [2013/11/01 23:33]
mcmaster created
xilinx:xst_messages [2014/01/22 13:33] (current)
sky
Line 3: Line 3:
  
 ====== 2042: internal tristates are replaced by logic ====== ====== 2042: internal tristates are replaced by logic ======
 +
  
 Sample: Sample:
  
-  ​WARNING:​Xst:​2042 - Unit my_bus: 32 internal tristates are replaced by logic (pull-up yes): sys_bus_data<​0>,​ sys_bus_data<​10>,​  + 
-  ... sys_bus_data<​8>,​ sys_bus_data<​9>​.+<​code>​ 
 +WARNING:​Xst:​2042 - Unit my_bus: 32 internal tristates are replaced by logic (pull-up yes): sys_bus_data<​0>,​ sys_bus_data<​10>,​  
 +... sys_bus_data<​8>,​ sys_bus_data<​9>​. 
 +</​code>​ 
 + 
 + 
 +_FCKG_BLANK_TD_ 
  
 (seeminly in no particular bit order) (seeminly in no particular bit order)
 +
  
 Modern FPGAs typically have tristates on the IOBs but not internally. ​ Thus, the signals are replaced by muxes to emulate tri-state behavior. ​ Its still unclear to me if this is actually a bad thing. ​ Note that this is why Xilinx doesn'​t let you have inouts cross pblocks. Modern FPGAs typically have tristates on the IOBs but not internally. ​ Thus, the signals are replaced by muxes to emulate tri-state behavior. ​ Its still unclear to me if this is actually a bad thing. ​ Note that this is why Xilinx doesn'​t let you have inouts cross pblocks.
Line 16: Line 25:
 ====== 2677: Node X of sequential type is unconnected in block Y ====== ====== 2677: Node X of sequential type is unconnected in block Y ======
  
-  WARNING:​Xst:​2677 - Node <​my_modules/​.../​my_output>​ of sequential type is unconnected in block <​module_top>​. 
  
-This means the signal really is unused. ​ Check design to see if this is intentional. ​ Unfortunately,​ this warning is generated on explicitly unconnected signals...so you might end up filtering a lot of these.+<​code>​ 
 +WARNING:​Xst:​2677 - Node <​my_modules/​.../​my_output>​ of sequential type is unconnected in block <​module_top>​. 
 +</​code>​ 
 + 
 + 
 +_FCKG_BLANK_TD_ 
 + 
 + 
 +This means the signal really is unused. ​ Check design to see if this is intentional. ​ Unfortunately,​ this warning is generated on explicitly unconnected signalsso you might end up filtering a lot of these.
  
  
 ====== 1426: value init of the FF/Latch X hinder the constant cleaning in the block Y ====== ====== 1426: value init of the FF/Latch X hinder the constant cleaning in the block Y ======
  
-  ​WARNING:​Xst:​1426 - The value init of the FF/Latch my_var_4 hinder the constant cleaning in the block my_module + 
-     ​You should achieve better results by setting this init to 1.+<​code>​ 
 +WARNING:​Xst:​1426 - The value init of the FF/Latch my_var_4 hinder the constant cleaning in the block my_module 
 +   ​You should achieve better results by setting this init to 1. 
 +</​code>​ 
 + 
 + 
 +_FCKG_BLANK_TD_ 
  
 Does this occur when you have combinational logic assigned to a reg that you initialize? ​ That is, it will glitch at startup and then settle on a combinatorial value? Does this occur when you have combinational logic assigned to a reg that you initialize? ​ That is, it will glitch at startup and then settle on a combinatorial value?
Line 30: Line 53:
  
 ====== 1710: FF/Latch has a constant value ====== ====== 1710: FF/Latch has a constant value ======
 +
  
 WARNING:​Xst:​1710 - FF/Latch <​my_var_11>​ (without init value) has a constant value of 0 in block <​my_module1>​. This FF/Latch will be trimmed during the optimization process. WARNING:​Xst:​1710 - FF/Latch <​my_var_11>​ (without init value) has a constant value of 0 in block <​my_module1>​. This FF/Latch will be trimmed during the optimization process.
 +
  
 Unfortunately verilog does not distinguish between lazy use of types and values that really are getting optimized out.  For example, when people really want an auto sizing value they may use type int which defaults to 32 bits.  This is sufficient for most operations and they are happy to let the synthesizer optimize out the bits that they don't really need.  Unfortunately,​ your state machine could also get optimized out if you have a logic error, so this can also be a good hint when it wasn't intended that you need to double check your design. Unfortunately verilog does not distinguish between lazy use of types and values that really are getting optimized out.  For example, when people really want an auto sizing value they may use type int which defaults to 32 bits.  This is sufficient for most operations and they are happy to let the synthesizer optimize out the bits that they don't really need.  Unfortunately,​ your state machine could also get optimized out if you have a logic error, so this can also be a good hint when it wasn't intended that you need to double check your design.
 +
  
 Related to 413 Related to 413
Line 40: Line 66:
 ====== 413: Result of X-bit expression is truncated to fit in X-1-bit target ====== ====== 413: Result of X-bit expression is truncated to fit in X-1-bit target ======
  
-  ​WARNING:​HDLCompiler:​413 - "​my_module.v"​ Line 123: Result of 25-bit expression is truncated to fit in 24-bit target.+ 
 +<​code>​ 
 +WARNING:​HDLCompiler:​413 - "​my_module.v"​ Line 123: Result of 25-bit expression is truncated to fit in 24-bit target. 
 +</​code>​ 
 + 
 + 
 +_FCKG_BLANK_TD_ 
  
 generated from: generated from:
  
-  ​q_next <= q_reg + 1;+ 
 +<​code>​ 
 +q_next <= q_reg + 1; 
 +</​code>​ 
 + 
 + 
 +_FCKG_BLANK_TD_ 
  
 This often happens when you use implicitly 32 bit values like "​1"​ instead of matched size of relying on sign extension. ​ This can be eliminated using sign extension by doing: This often happens when you use implicitly 32 bit values like "​1"​ instead of matched size of relying on sign extension. ​ This can be eliminated using sign extension by doing:
  
-  ​q_next <= q_reg + 1'b1;+ 
 +<​code>​ 
 +q_next <= q_reg + 1'b1; 
 +</​code>​ 
 + 
 + 
 +_FCKG_BLANK_TD_ 
  
 Now instead of truncating a 32 bit value you are sign extending a 1 bit value which xst seems pretty happy with. Now instead of truncating a 32 bit value you are sign extending a 1 bit value which xst seems pretty happy with.
 +
 +
 ====== References ====== ====== References ======
  
-Understanding Verilog Warnings (well xst really): http://​www.bigmessowires.com/​2011/​09/​09/​understanding-verilog-warnings/​ 
  
 +Understanding Verilog Warnings (well xst really): [[http://​www.bigmessowires.com/​2011/​09/​09/​understanding-verilog-warnings/​|http://​www.bigmessowires.com/​2011/​09/​09/​understanding-verilog-warnings/​]]
  
 
xilinx/xst_messages.txt · Last modified: 2014/01/22 13:33 by sky
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution 4.0 International
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki