Xilinx CPLD, strange warning message ?

Discussion in 'Embedded Systems and Microcontrollers' started by TechSpec, May 24, 2008.

  1. TechSpec

    Thread Starter Member

    Jul 9, 2007
    12
    0
    Hello

    Just made a simple program with VHDL, Synthesizing and translation was ok, no warnings/errors, But 'fit' gave me warnings (seen at the bottom of this message).

    There is one odd thing, it seems that the program is using all of the capacity of this chip, but "fit report" tells that the usage of this chip is hardly over 30%. What is wrong in here? If necessary, i can send the whole report and the source code.
    Should i take those warnings seriously, it seems to 'fit' into chip, but i would clear these warnings out.

    Tool is Xilinx ISE 7.1i

    TechSpec

    ************************* Mapped Resource Summary **************************

    Macrocells Product Terms Function Block Registers Pins
    Used/Tot Used/Tot Inps Used/Tot Used/Tot Used/Tot
    88 /256 ( 34%) 218 /896 ( 24%) 167 /640 ( 26%) 84 /256 ( 33%) 16 /173 ( 9%)


    ************************** Errors and Warnings ***************************

    WARNING:Cpld:265 - Logic for net 'counter_2<12>' exceeds physical capacity of device; the logic will be broken into intermediate nodes.
    WARNING:Cpld:265 - Logic for net 'counter_2<13>' exceeds physical capacity of device; the logic will be broken into intermediate nodes.
    WARNING:Cpld:265 - Logic for net 'counter_2<14>' exceeds physical capacity of device; the logic will be broken into intermediate nodes.
    WARNING:Cpld:265 - Logic for net 'counter_2<15>' exceeds physical capacity of device; the logic will be broken into intermediate nodes.
    ************************* Summary of Mapped Logic ************************
     
    Last edited: May 24, 2008
  2. Caveman

    Active Member

    Apr 15, 2008
    471
    0
    First of all. YES! You should always take warnings seriously. That doesn't mean they all have to go away, but they should.

    You are likely trying to connect too many things to these particular nets. It is breaking them up into smaller chunks that it can handle. Look at those nets and figure out what kind of logic must be inferred to do it. This is something that you should be inherently doing when designing in HDL anyways, so it is good practice.
     
  3. roddefig

    Active Member

    Apr 29, 2008
    149
    0
    I'll second that! One of the first things I learned with FPGAs is to take every warning seriously, only ignore them if you know exactly what they mean.
     
  4. Papabravo

    Expert

    Feb 24, 2006
    10,135
    1,786
    My guess is that with a sixteen bit counter you've run out of something. Is it obvious from your post which device you are using? My guess would be that the gating required to do stages 12-15 has exceeded the ability of the LUT and the routing channels required to do the implementation.
     
  5. TechSpec

    Thread Starter Member

    Jul 9, 2007
    12
    0
    Those counters are controlled by this process:


    process ( CLK_IN, impulse_ok )
    begin
    if (impulse_ok = '1') then

    if (CLK_IN'event and CLK_IN = '1') then

    if (prescaler_1 = "10011100010000") then
    prescaler_1 <= "00000000000000";

    if (counter_1 = "1111111111111111") then
    counter_1 <= "0000000000000000";

    if (counter_2 = "1111111111111111") then
    counter_2 <= "0000000000000000";
    else
    counter_2 <= counter_2 + '1';
    end if;

    else
    counter_1 <= counter_1 + '1';
    end if;
    else
    prescaler_1 <= prescaler_1 + '1';
    end if;
    end if;

    else
    counter_1 <= "0000000000000000";
    counter_2 <= "0000000000000000";
    prescaler_1 <= "00000000000000";

    end if;

    end process;

    ------------------------------------------------------

    counter values are used this way:
    -
    -
    -
    buf_24 <= counter_2(8);
    buf_25 <= counter_2(9);
    buf_26 <= counter_2(10);
    buf_27 <= counter_2(11);
    buf_28 <= counter_2(12);
    buf_29 <= counter_2(13);
    buf_30 <= counter_2(14);
    buf_31 <= counter_2(15);
    -
    -
    -

    nets are not used elsewhere. If those were used the wrong way or there is a conflict, it would give an error, now its not.

    -TechSpec
     
  6. Papabravo

    Expert

    Feb 24, 2006
    10,135
    1,786
    There are a ton of nets and gates that you can't see, that are required to implement a 16 bit prescaler and a 16 bit counter. What you have is a behavioral description, not a structural one.
     
  7. TechSpec

    Thread Starter Member

    Jul 9, 2007
    12
    0

    Hi

    device is Coolrunner 2, xc2c256

    Well it seems so that something has run out. Q is that what it is?
    It does fit into device, but in what cost, is unknown.

    well if something was run out, i would have expected program to tell it directly...

    -techspec
     
  8. TechSpec

    Thread Starter Member

    Jul 9, 2007
    12
    0

    Im very aware of that, i also have a tool that makes those for me so i dont have to go into details and think all those thousands of nets and gates inside the chip. For me there is only nets that are visible in my program, and those are only ones that i care for. If there is a conflict inside the chip when generating the logical structure, its not in my willpower to change that, its the task for the development tool to handle. And when there is an error, i would like to know what is causing that.

    -TechSpec
     
  9. Papabravo

    Expert

    Feb 24, 2006
    10,135
    1,786
    Sorry, I'm not familiar with that device.

    You are of course free to do things in any manner that you choose, but with those decisions come consequences that we must accept.
     
  10. Caveman

    Active Member

    Apr 15, 2008
    471
    0
    Wrong, wrong, wrong. It is the task of the tool to help you implement it. You have to direct it. Sometimes this means getting your hands dirty. These are amazing tools, but they're not as smart as a human.

    The problem you have here is that you basically have a very large counter, and it is trying to generate all of the logic for the rollover at once. A better way to do this is to define combinatorial "next_state" variables based on the previous counter values and split the three counters up into separate process statements. By telling it to split them up in a logical way (just like you would do if you had to do this in schematic entry), you direct the inference tool so it works smarter and uses resources more efficiently. Then the fitting tool will stop whining.
     
  11. Papabravo

    Expert

    Feb 24, 2006
    10,135
    1,786
    Well spoken Caveman. Sometimes you have to shake your head and just let it go.
     
  12. TechSpec

    Thread Starter Member

    Jul 9, 2007
    12
    0
    Offcourse, we are the directors, we control the process. What i ment is that what ever we decide to do, compiler allways have the last word. It is the one that makes the actual code and internal logic structure.
     
    Last edited: May 25, 2008
  13. TechSpec

    Thread Starter Member

    Jul 9, 2007
    12
    0

    I dont think i have to accept these consequences. You said it yourself, warnings should allways take seriously.

    Afterall, my intention was and still is to sort this out and remove those warnings. Accepting something that i dont know what im accepting or just "accepting consequences" is not a good way to do things.

    -TechSpec
     
    Last edited: May 25, 2008
  14. Caveman

    Active Member

    Apr 15, 2008
    471
    0
    No, you have the last word. If the design fails, it's your fault, not the tool's. The purpose of the tool is to allow you to easily design more complex things than you could do otherwise. But you still have to understand what is really going on and decide when it is good enough. This is true for all tools.

    Did you try what I said about splitting them up?
     
  15. TechSpec

    Thread Starter Member

    Jul 9, 2007
    12
    0
    I did split one 16 bit counter into half, but no change, still "exeeds physical capacity".

    Actually, amount of counters seems not to be the problem, the problem appears when counter cells are handled in a different process.
    When i removed these rows from the code, warnings disappeared:

    buf_16 <= counter_2(0);
    buf_17 <= counter_2(1);
    buf_18 <= counter_2(2);
    -
    - and so on....
    -

    This is a rather normal procedure to read counter values into 1bit registers. If i look at this type of functionality done with a discrete logic, it would be very simple to do. So why its not working in here. If i have the last word, i really would like use it right now.

    -TechSpec
     
    Last edited: May 25, 2008
  16. Caveman

    Active Member

    Apr 15, 2008
    471
    0
    Are you doing this in a process or just under in the architecture block?
     
Loading...