Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
04/16/07 20:01
Read: times


 
#137343 - warnings
Responding to: ???'s previous message
Mahmood Elnasser said:
The first warning is legitmate because I'm still working on the tri_address for i need to think how to do a triangle waveform. but the rest I have no clue.

Warning (10541): VHDL Signal Declaration warning at funcgen.vhd(40): used implicit default value for signal "tri_address" because signal
was never assigned a value or an explicit default value. Use of implicit default value may introduce unintended design optimizations.


This is bad. You didn't assign anything to tri_address. Perhaps you missed something? Perhaps something else got optimized away? Go back and check (read: simulate) the source code to find out what happened.

Warning (10631): VHDL Process Statement warning at kb_encoder.vhd(172): inferring latch(es) for signal or variable "kbrtn_encod", which
holds its previous value in one or more paths through the process


The tool inferred a combinatorial latch, which is generally a Bad Thing in an FPGA. Go back and sort out why. Usually adding a register solves this. You might have described something using a combinatorial "if" statement without an "else" clause.

Warning: Removed always-enabled tri-state buffer ROM:ROM1|lpm_rom:lpm_rom_component|otri[0] feeding logic, open-drain buffer, or output pin
Warning: Removed always-enabled tri-state buffer ROM:ROM1|lpm_rom:lpm_rom_component|otri[1] feeding logic, open-drain buffer, or output pin
Warning: Removed always-enabled tri-state buffer ROM:ROM1|lpm_rom:lpm_rom_component|otri[2] feeding logic, open-drain buffer, or output pin
Warning: Removed always-enabled tri-state buffer ROM:ROM1|lpm_rom:lpm_rom_component|otri[3] feeding logic, open-drain buffer, or output pin
Warning: Removed always-enabled tri-state buffer ROM:ROM1|lpm_rom:lpm_rom_component|otri[4] feeding logic, open-drain buffer, or output pin
Warning: Removed always-enabled tri-state buffer ROM:ROM1|lpm_rom:lpm_rom_component|otri[5] feeding logic, open-drain buffer, or output pin
Warning: Removed always-enabled tri-state buffer ROM:ROM1|lpm_rom:lpm_rom_component|otri[6] feeding logic, open-drain buffer, or output pin
Warning: Removed always-enabled tri-state buffer ROM:ROM1|lpm_rom:lpm_rom_component|otri[7] feeding logic, open-drain buffer, or output pin


This seems like a WARNING that should be an "INFO." Sounds like you described a ROM whose output is always enabled (which is fine). However, the LPM that was inferred has an output enable, which you've tied always true (like I said, this is fine) so the tools optimize out the unneeded tristates and WARN you.

(As an aside, sometimes the tools have weird notions of what's important enough for a WARNING and what's benign enough for an INFO. For example, VHDL lets you indicate that an unused port on an entity instance with the keyword "open". However, XST will give you a WARNING saying "unused port on entity foo," which is utterly retarded because the keyword "open" tells the tool that YOU KNOW THE PORT IS OPEN! Conversely, I did something silly with RAMs and I used up all of the block RAMs and the tool synthesized the remaining memories in LUTs, which ate up all of my chip resources. However, instead of WARNING me that I was now using distributed RAMs instead of BRAMs, I got a gentle "INFO" which I missed until I had to figure out why PAR failed.)

Warning: Latch kb_encoder:KEY_BOARD|kbrtn_encod[0] has unsafe behavior
Warning: Ports D and ENA on the latch are fed by the same signal kb_rtrn[2]
Warning: Latch kb_encoder:KEY_BOARD|kbrtn_encod[1] has unsafe behavior
Warning: Ports D and ENA on the latch are fed by the same signal kb_rtrn[1]
Warning: Timing Analysis is analyzing one or more combinational loops as latches
Warning: Node "kb_encoder:KEY_BOARD|kbrtn_encod[0]" is a latch
Warning: Node "kb_encoder:KEY_BOARD|kbrtn_encod[1]" is a latch


Go back and change the code that infers a latch into something that is registered.

Warning: Found pins functioning as undefined clocks and/or memory enables
Info: Assuming node "f_clk" is an undefined clock
Info: Assuming node "kb_rtrn[3]" is a latch enable and/or memory write/read enable. Will not compute fmax for this pin.
Info: Assuming node "kb_rtrn[2]" is a latch enable and/or memory write/read enable. Will not compute fmax for this pin.
Info: Assuming node "kb_rtrn[1]" is a latch enable and/or memory write/read enable. Will not compute fmax for this pin.
Info: Assuming node "kb_rtrn[0]" is a latch enable and/or memory write/read enable. Will not compute fmax for this pin.
Warning: Found 1 node(s) in clock paths which may be acting as ripple and/or gated clocks -- node(s) analyzed as
buffer(s) resulting in clock skew


More latch stuff. Fix the source. Don't use combinatorial latches.

-a

List of 54 messages in thread
TopicAuthorDate
VHDL FPGA            01/01/70 00:00      
   Hello, world?            01/01/70 00:00      
      LCD display            01/01/70 00:00      
         video overlay            01/01/70 00:00      
            funny you should say that            01/01/70 00:00      
   bcd to binary            01/01/70 00:00      
      Try a different algorithm            01/01/70 00:00      
      easier way            01/01/70 00:00      
         LUT            01/01/70 00:00      
   This is what you want!            01/01/70 00:00      
      It is not as easy as it seems!            01/01/70 00:00      
   Here\'s a little exercise ...            01/01/70 00:00      
      more info required            01/01/70 00:00      
         I don't think its very fair.            01/01/70 00:00      
            consider this ...            01/01/70 00:00      
         pick an arbitrary frequency            01/01/70 00:00      
   warnings            01/01/70 00:00      
      Give us a clue,what do they say?            01/01/70 00:00      
         warnings sample            01/01/70 00:00      
            You can ignore most of them, but Quartus is buggy            01/01/70 00:00      
               Combinational Loops            01/01/70 00:00      
                  No doubt about it ...            01/01/70 00:00      
            gated/ripple clocks            01/01/70 00:00      
               ... but those complaints aren\'t always relevant            01/01/70 00:00      
            warnings            01/01/70 00:00      
               Andy, how would YOU construct a latch?            01/01/70 00:00      
                  latches in FPGAs            01/01/70 00:00      
                     Excellent Posting            01/01/70 00:00      
                     more about latches            01/01/70 00:00      
                        I like clear terms in my latches            01/01/70 00:00      
                           The point is i think ... unitentional latches            01/01/70 00:00      
                              exactly ...            01/01/70 00:00      
                                 elsif            01/01/70 00:00      
                                    Bad code            01/01/70 00:00      
                                    elsif            01/01/70 00:00      
                                 Quartus complains if you use the library latch            01/01/70 00:00      
                           latch reset inputs            01/01/70 00:00      
                              the library latch has no clear function            01/01/70 00:00      
                                 Brand A vs Brand X            01/01/70 00:00      
                                    true enough            01/01/70 00:00      
   Modelsim            01/01/70 00:00      
      about the only limitations on modelsim are ;-            01/01/70 00:00      
      ModelSim, PicoBlaze, MicroBlaze            01/01/70 00:00      
         there's a CPLD <=>LCD app note            01/01/70 00:00      
            JTAG interface            01/01/70 00:00      
            darn            01/01/70 00:00      
               Xilinx CPLD applications handbook            01/01/70 00:00      
   Mahmood, stick with the recommended circuit            01/01/70 00:00      
      Recommended circuit            01/01/70 00:00      
         I would be really careful ...            01/01/70 00:00      
            Thanks Richard            01/01/70 00:00      
               don't be distracted by the unnecessary parts            01/01/70 00:00      
                  Xilinx Jtag for Altera            01/01/70 00:00      
                     How about Altera JTAG for ALTERA            01/01/70 00:00      

Back to Subject List