Xilinx CPLD, strange warning message ?

Thread Starter

TechSpec

Joined Jul 9, 2007
12
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:

Caveman

Joined Apr 15, 2008
471
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.
 

roddefig

Joined Apr 29, 2008
149
First of all. YES! You should always take warnings seriously. That doesn't mean they all have to go away, but they should.
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.
 

Papabravo

Joined Feb 24, 2006
21,160
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.
 

Thread Starter

TechSpec

Joined Jul 9, 2007
12
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
 

Papabravo

Joined Feb 24, 2006
21,160
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.
 

Thread Starter

TechSpec

Joined Jul 9, 2007
12
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.

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
 

Thread Starter

TechSpec

Joined Jul 9, 2007
12
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.

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
 

Papabravo

Joined Feb 24, 2006
21,160
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.
 

Caveman

Joined Apr 15, 2008
471
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
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.
 

Thread Starter

TechSpec

Joined Jul 9, 2007
12
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:

Thread Starter

TechSpec

Joined Jul 9, 2007
12
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.

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:

Caveman

Joined Apr 15, 2008
471
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.
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?
 

Thread Starter

TechSpec

Joined Jul 9, 2007
12
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:
Top