Verilog - Signal has no load

[FlyMario]

So, I am starting to get these errors during the Place & Route phase

WARNING:Par:288 - The signal kbd<0>_IBUF has no load.  PAR will not attempt to route this signal.
WARNING:Par:288 - The signal kbd<1>_IBUF has no load.  PAR will not attempt to route this signal.
WARNING:Par:288 - The signal kbd<2>_IBUF has no load.  PAR will not attempt to route this signal.
WARNING:Par:288 - The signal kbd<3>_IBUF has no load.  PAR will not attempt to route this signal.
WARNING:Par:288 - The signal kbd<4>_IBUF has no load.  PAR will not attempt to route this signal.
WARNING:Par:288 - The signal kbd<5>_IBUF has no load.  PAR will not attempt to route this signal.
WARNING:Par:288 - The signal kbd<6>_IBUF has no load.  PAR will not attempt to route this signal.

it only started when I added the enb register.  It really makes no sense.

`timescale 1ns / 1ps
module Trigger(trig,trigb,kbd);
    output trig;
     output trigb;
    input[7:0] kbd;
    reg trigb;
     reg trig;
     reg enb;

    always
    begin
     trigb = kbd[7];
    end
      
     always @*
     begin
        case(kbd)

        0: begin
                enb = 0;
                trig = 0;
            end
        
        254: begin            // line 0
                    trig = 0;
                    enb = 0;
                //    kbdphase = 1;
              end         

        253: begin            // line 1
                    trig = 0;
                    enb =0;
              end         
        251: begin            // line 2
                    trig = 0;
                    enb =0;
              end         
        247: begin            // line 3
                    trig = 0;
                    enb =0;
              end         
        239: begin            // line 4
                    trig = 0;
                    enb =0;
              end         
        223: begin            // line 5
                    trig = 0;
                    enb =0;
              end         
        191: begin            // line 6
                    trig = 0;
                    enb = 1;
              end         
        127: begin            // line 7
                    if (enb)
                    begin
                            trig = 1;
                            enb = 0;
                    end
                    else
                    begin
                       enb = 0;
                        trig = 0;
                    end
              end
    
        default 
            begin
                enb = 0;
                trig = 0;
            end
        
        endcase;
    end
endmodule
 

The idea behind this is that the C64's Keyboard has 8 Column lines that get strobed individually.  The row lines will return the keys that are pressed on that column (not implemented).  Right now it just throws a line (TRIG) when a line goes high.  The problem is that the line 7 does not behave like exactly like the others.  It can actually go low for other reasons but never after line 6.  So I thought to put up an enable pin to be turned on during line 6 period and then this will let line 7 know it can do its job and it can set the enable register go low again.

Anyways, the ISE is giving me a terrible time.

Also I can't understand why it requires me to set the enb line low on practically every single part of the case statement... otherwise I get it complaining about a possible latch.

Do you all notice anything I am doing wrong?  

Thanks a lot for any help you can provide.

[D@n]

@FlyMario,

I'm looking through your design and not seeing a clock.  Are you using a clock elsewhere?  How does your clock relate to this logic?

Dan

[FlyMario]

There is no clock. I am using the signals from the kbd[7:0] to trigger the logic.  Its strange if I am required to use one since it has worked perfectly until this new issue.  I am all ears

[D@n]

@FlyMario,

No clock?  Anywhere in your entire design?  That is a recipe for a design that doesn't work.  Are you sure that's what you want to do?

How is it that you know, for example, that all of the digital lines have settled before your logic?  Remember, wires will have subtly different delay times between them.  Will all of those kbd lines get set at the same time?  Or might there be picoseconds between when the various wires get set?

To your question, though, the message that a signal doesn't drive any load is simply a way of saying that the signal doesn't drive any logic.  Since you have some logic in your design that appears to depend upon the signal, it may be that the following signal isn't driving any logic either.  As an example, your "enb" register is not listed on any output ports, so any good synthesis tool will throw it out as part of optimizing your design.

You might be interested, though, in the list of "rules" I've slowly been building for beginners.  I imagine I'll post them on my blog eventually, probably at the beginning of the next school year, but here's my list (so far):

• Build your design with only one clock.  If the clock that comes into your chip is not at the speed you want, then use a PLL to generate the clock speed you want/need and then let that result be your only clock.
• Force all of your logic to transition on a clock.
• Do not transition on any negative (falling) edges
• Do not transition on the positive (rising) edge of anything other than your system clock.  Here are some techniques for handling timing from a single master clock.
• Synchronize all external inputs (such as your kbd above) using two clock'd transfers before using them.  (Ref: Metastability)
• Do not use an asynchronous reset within your design.  Use initial values and synchronous resets instead if you need them.
• Simulate everything before you place it onto your hardware.
• Build unit tests that can "prove" that your components work, via a simulator.
• Build simulations that will not only support unit test, but also full up integration testing.

These rules are not absolutes.  If you continue working with FPGA's for a long time, there will come a time when you need to break each of these rules.  Just ... be very careful when you do so, do your research first, and make certain you understand what you are doing before you break any of them.

Dan

[FlyMario]

Thank you so very much for your response!  My word, I have so much to think about now. Exciting.  I am really just having fun,  playing with a fpga board and my Commodore 64. Way too old to start this as a new career. I am very thankful folks such as yourself are willing to spread you knowledge.  So many new bookmarks to look at now

Thanks Again,

Pete

[TrapperBob]

FlyMario,

I am not sure what your code is trying to accomplish. Are you trying to capture a sequence of keypress events and then indicating that by changing an output? A sequence implies examining state which implies memory which implies flip-flops which need a clock

[FlyMario]

Oh, wow I didn't include my timing diagram.  What a newbie.

So,  the first 8 lines are from the C64's keyboard column lines.  What happens is (from my theory) the the first 7 lines go low to see if any key is pressed. If it finds a value at all it sequences through all of the column lines accept for the 8th line (A7 Grey).  As you can see, all of the lows are easy to pick out accept for last one. That line only goes high if a key is detected... However you can see that it goes low when it is its turn to send out a key.

On the very bottom line (pink B7) is from the output of my Spartan 6 FPGA.  It is attached to the output trig. I am trying to get that trigger only to go high at the point where line A7 Goes low asking for they key line.  What you see instead though is B7 is following A7 too closely.  To filter the noise out, I am trying to allow line A6 to tell A7 when we get to it that it can set the trigger high.  

Wow...it seems hard to explain.  here is a link to how the keyboard is structured.

http://www.waitingforfriday.com/?p=470

Thanks,

Pete

[D@n]

@FlyMario,

Yeah ... you need a clock for all the reasons @TrapperBob just suggested.

Remember how we discussed the other day that blocking assignments didn't imply some unwritten clock?  They don't.  Indeed, such statements are not actually executed in order, they only appear to be executed in order.  In general, I've found the "<=" non-blocking assignment to be much more useful, and only found a small few examples that have needed the blocking assignment "=".  Even worse, the blocking assignment is known for creating simulation/hardware mismatch, so I would discourage you from using it in general unless you have a specific need for it.

To use a clock, you'll need to place "@(posedge i_clock_name)" at the top of all of your always blocks.  Any results you make with an "@*" always block should feed into a "@(posedge i_clock_name)" block.  I was once told that good design practice has all inputs to a unit clocked and all outputs clocked.  While I've had to violate this rule many times over, there's good reasons for it--most of them having to do with routing.

Dan

[FlyMario]

Well, I added a clock and that made a ton of improvement.  Now I do have the signals exactly as I wanted them.

Thanks a lot guys!

FlyMario