|
|
|
|
|
Listing of Synplify Warnings During Synthesis
The following is a non-comprehensive listing of warnings that you may encounter while attempting to synthesize your design. These errors have been grouped according to severity. You should especially pay attention to those classified as Critical, as getting these warnings usually means that your design will not be synthesized correctly. If you have questions about a warning that is not listed here, please contact one of the course staff or post it on the wiki so that we can update this list.
Critical - Will likely cause design to fail in implementation step
- [BN137] Found combinatorial loop during mapping at net X
Explanation: A combinatorial loop has been found in your design. This means that your design has a circuit where the output of the circuit is part of the input to the circuit, meaning that if the output were to change, it could result in itself changing again, which would in turn result in it changing again, and so on. Implementation cannot deal with this problem in any way other than by adding latches, which will cause the design to fail timing constraints.
Solution: Try to locate the combinatorial loop in your design and eliminate it. It may help to look at the nets named in the warnings that Synplify produces, as these nets will be along the path of the loop.
- [BN134] Found combinatorial loop during mapping
Explanation: See "[BN137] Found combinatorial loop during mapping at net X".
Solution: Try to locate the combinatorial loop in your design and eliminate it. It may help to look at the "Source Location" column in the Messages pane as this will list the modules involved and likely make it easier to track down the source of the loop.
- [CG141] Creating black_box for X (X is the name of a module in the design)
Explanation: Synplify has been unable to locate a definition for this module in the project that you have provided it, and will place a black box in the design which will presumably be implemented later by some additional definition provided to the ISE or other program involved in the implementation process. Since we will not be specifing implementations for modules later in the process, this will cause the implementation not to function correctly on the board.
Solution: Check the Libraries tab to ensure that all files in lib378 are included for synthesis. Next, check your synthesis settings to ensure that all files that you have created and are using are included in the synthesis. If all this is correct, you may have included a module that no longer exists or is from a library other than the ones that we use for synthesis. Track down this module and remove it if it is not in use, or replace it with an equivalent module from lib378 if possible.
- [CL168] Pruning instance X - not in use... (X will be the name of one of the modules in your design such as the register file or ALU)
Explanation: Synplify thinks that this module in your design is not being used to generate any useful output, and in order to make the design more efficient, removes it during synthesis. This will obviously cause problems as your processor will probably not function without this component inside it.
Solution: Check your wiring in ActiveHDL, and make sure that all components are connected to each other correctly. If there is some kind of miswiring or mislabeled wire, Synplify may decide that the component's output is not connected to anything and that it is not needed in the final design.
Potential Hazard - May cause unexplained failures in implementation
- [CG360] No assignment to wire X
Explanation: A wire in the design does not have a source.
Solution: If the wire named is one that should have a source, you should return to your design and verify that it is connected properly to its source. If the wire is not meant to have a source, then it should probably be removed from the design since it does not accomplish anything.
- [CG133] No assignment to X
Explanation: A register in the design has not been assigned a value.
Solution: If the source location of the warning is a module that is part of lib378, then you can safely ignore this warning. If the source is a module that you have written, you should make sure that the register which is named in the warning is not supposed to have a value, in which case you should remove it from the design. If it is supposed to have a value, make sure that the register is actually being assigned a value.
- [CL159] Input X is unused
Explanation: One of the modules in your design has an input that is not being used inside it to produce an output.
Solution: This warning is normally not a sign of a problem unless the input listed is one that the module requires to produce the correct output. If this is the case, you should recheck your module design to see why the input is not being used.
- [CL169] Pruning Register X
Explanation: A register found in the design has been deemed unnecessary and Synplify has removed it from the design. To find out why this register has been removed, check the other warnings to see if the register is unused or unassigned.
Solution: This warning is normally not a sign of a problem unless the register is supposed to contain a value that is being used by the processor. If this is the case, it might be helpful to check if it was pruned because it was exactly the same as another piece of logic (See "[BN132] Removing instance X, because it is equivalent to instance Y"). If it was not, you should check your design and make sure that the register is properly connected and that it is assigned values in an appropriate way.
- [BN116] Removing sequential instance X of view:X because there are no references to its outputs
Explanation: A part of a module is not producing any output that is being used, and Synplify is removing it to make the design more efficient.
Solution: If the source location of the warning is a module that is part of lib378, then you can safely ignore this warning. If the error is being caused by a module that you created, you should go back and make sure that all outputs from the module are connected correctly.
- [CL156] *Input X to this expression [instance] has undriven bits which are being tied to 0 - a simulation mismatch is possible
Explanation: Synplify has determined that an input to a module has undriven bits and as a result is tying them to ground rather than leaving them undriven.
Solution: This warning can be safely ignored if the module involved is a part of lib378 and you have wired the inputs to the module correctly. If the module was not part of lib378, you should check to make sure that all the connection to the input of your module has the same bus width as the input port and that all incoming wires that are part of the bus are being driven by their sources.
- [CL157] *Output X has undriven bits - a simulation mismatch is possible
Explanation: Synplify has determined that the output on a module contains bits that are not supplied with a value.
Solution: This warning can be safely ignored if the module involved is a part of lib378. If the module was not part of lib378, you should check to make sure that all the bits in the output of your module are actually being driven with values (particularly if the module was constructed as a block diagram, in which case there may be a mislabeled bus width or unconnected wire).
- [CL234] Input port bits <X to X> of N[X:X] are unused
Explanation: Some of the input bits on a bus input to a module are not being used by the module to produce its output.
Solution: If the source location of the warning is a module that is part of lib378, then you can safely ignore this warning. If the source is a module that you have written, you should make sure that the output of your module does not depend on the bits listed in the message. Additionally, it may be helpful to simply remove the bits from the input if you are not using them, as this will allow for a more efficient synthesis and implementation process.
- [CL170] Pruning bit <X> of N[X:X] - not in use...
Explanation: Some of the input bits on a bus input to a module are not being used by the module to produce its output. As such, Synplify will try to make the design more efficient by simply removing those bits.
Solution: If the source location of the warning is a module that is part of lib378, then you can safely ignore this warning. If the source is a module that you have written, you should make sure that the output of your module does not depend on the bits listed in the message. Additionally, it may be helpful to simply remove the bits from the input if you are not using them, as this will allow for a more efficient synthesis and implementation process.
- [CL171] Pruning Register bit <X> of N[X:X]
Explanation: Some of the register bits in a module are not being used by the module to produce its output. As such, Synplify will try to make the design more efficient by simply removing those bits.
Solution: If the source location of the warning is a module that is part of lib378, then you can safely ignore this warning. If the source is a module that you have written, you should make sure that the output of your module does not depend on the bits listed in the message. Additionally, it may be helpful to simply remove the bits from the register declaration if you are not using them, as this will allow for a more efficient synthesis and implementation process.
Safe - Can be safely ignored most of the time
- [CL189] Register bit X is always 0, optimizing
Explanation: A register being used in a module has a value that never changes. Synplify will optimize it by removing the register.
Solution: If the source location of the warning is a module that is part of lib378, then you can safely ignore this warning. If the error is being caused by a module that you created, you should make sure that the registers that you are using in the module are actually being updated correctly.
- [BN132] Removing instance X, because it is equivalent to instance Y
Explanation: Synplify has detected two equivalent pieces of logic in your design and has made the design more efficient by removing one of them.
Solution: This warning should not be an issue unless the two instances mentioned are clearly not equivalent.
- [MT246] Blackbox STARTBUF_VIRTEX2 is missing a user supplied timing model. This may have a negative effect on timing analysis and optimizations (Quality of Results)
Explanation: Synplify is unable to determine timing information for the blackbox specified, and as such cannot generate a proper model for it.
Solution: This warning can be safely ignored as the STARTBUF_VIRTEX2 component is available to the Xilinx ISE during implementation.
- [MO111] tristate driver X on net X has its enable tied to GND (module X)
Explanation:
Solution: This warning can be safely ignored.
|
CSE Home 
