CPLDs

[mlynek]

Dear Collegaues,

Sorry for possible stupid question. I am quite new in CPLD programming. I wrote programm (in Veriolg) which was sucessfully fitted in CoolRunner X2C2128.

Unfortunately the same program couldn't be fitted in X95144 (that is my project requrements) I have tried to optimalize my program without success.

I guess there must be something wrong with my ISE settings ??

Thanks for your support in advance.

mlynek

[gszakacs]

You don't describe you design, so this is only a guess.

The XC9500 has a different macrocell architecture than the CoolRunner II.

So even though you may have more macrocells in the XC9500 series part,

you could run out of product terms with the same equations.  There are

also differences in the global interconnect that could cause problems

if you have equations that have a large number of inputs for example.

Then it may not be possible to partition the design into banks of macrocells.

HTH,

Gabor

[jprovidenza]

It's probably not a problem with ISE settings.

The Xilinx tools for CPLDs will output the equations for the different macro-cells, I believe.

 You may want to look at them to look for surprises that are using more logic than you would

expect.

How much do you miss fitting by?

John Providenza

[mlynek]

Hi Again,

Thank you for interesting in my problem and for your responses.

My design is quite simple. There is 9 inputs and 6 outputs. Inside I have two 16-bits buffers, and one 7bit counter, that is all.

As Gabor suggested.. I am out of "product terms" whatever it means:)

Here is what ISE says after fit process is failed: p, li { white-space: pre-wrap; }

ERROR:Cpld:853 - Insufficient number of product terms. This design needs at least 823 but only 720 left after allocating other resources.

Device 95144XL100 was disqualified.

ERROR:Cpld:868 - Cannot fit the design into any of the specified devices with the selected implementation options.

 
p, li { white-space: pre-wrap; }

And resource report:

Macrocells Used Pterms Used Registers Used Pins Used Function Block Inputs Used

6/144 (5%) 92/720 (13%) 6/144 (5%) 15/81 (19%) 96/432 (23%)

[jprovidenza]

Maybe you should post your code?

John P

[mlynek]

here is the code:

http://mill.eu.org/audio_switch.v

mlynek

[mlynek]

In the meantime I found this:

http://www.xilinx.com/support/answers/9924.htm

As it was suggested in point 1, I changed the "Logic Optimalization" from "speed" to "density" and now it works:

Macrocells Used	Pterms Used	Registers Used	Pins Used	Function Block Inputs Used

87/144  (61%)

254/720  (36%)

46/144  (32%)

15/81  (19%)

180/432  (42%)

That is huge difference, before I had: 823/720  Pterms, now it is 254/720 ...

BTW, I have no idea how it potentially influence the timming issues ...

mlynek

[jprovidenza]

Several coments on your code....

Have you simulated this?  I suspect the actual h/w will not match your simulations because of

your use of blocking assignments.   Assume foo starts at 0...

   always @(posedge clock)

         begin

         foo = foo + 1;

         my_out = foo;

         end

After the clock tick, foo will have a value of 1.  What value will my_out have in simulation and

in hardware.  Are they different?   (yes).  

   always @(posedge clock)

         begin

         foo <= foo + 1;

         my_out <= foo;

         end

After the clock tick for the above example, what are the values? Do simulation and hardware

match?  (yes)

 You need to appreciate that, in general, non-blocking assignments should be used in synchronous

logic.  I believe Cliff Cummings has a nice paper on this topic.

Next comment...

You're using a lot of arithmetic comparisons.  These are expensive in hardware.  Can you re-code

in a better manner?

For example, you have:

       if((main_cnt >= (channel_sel_1*16)) && (main_cnt < ((channel_sel_1*16)+16)))
This could be re-coded as:

     if ( (main_cnt[6:4] >=  channel_sel_1)  && main_cnt[6:4] < (channel_sel_1+1) )

John P

[mlynek]

Thanks John for your comments.

Actually I used the blocking assigment to be sure about values after assigment. Race conditions ...

And also thanks for hints how to optimize the code.

mlynek