Xilinx XC9536 current draw ?

So you are saying the device is 100% functional, when programmed ? How many devices have you checked ? The symptoms suggest a shorted pin, or bad drive (not Vdd, or Vss) you could try the same code, but with all outputs connected to an OE on one of your spare IOs, and see if the Icc changes on OE. It it does, there is output contetion somewhere.

-jg

Jon,

Have you seen the design drawing lower current in another batch? Also, you're saying you are using pretty much all of the device's resources. Is this all registered? Are you using latches in the design? I ask this because I have had similar problem in the past with a 128MC design, consuming almost 300mA of current @5V. The main reason was a failure in the netlist generation, resulting in all the flipflops behaving as a latch. Manually editing the netlist resolved the issue.

Good luck,

Luc

About 4-5.

No, I really don't think so. I have gone over it very carefully, and also checked it by loading the same program into a chip on a different board that I have used before. I just put the CPLD on that board, nothing else.

I'm pretty sure it isn't external output contention. This design only has 3 inputs and 7 outputs, although the internal logic is full (first time I've ever used all of a CPLD). Now that I go back over things, I don't think Xilinx's formula for

95xx current draw has EVER been correct, within a factor of 2 or 3, this is just the first time it really mattered, as this board runs off 12 V, and I put a tiny regulator on the board to get 5 V. I have had to change to a larger regulator (both current-wise and physically) and put more copper on the board as a heat dissipator.

Thanks,

Jon

WOW! First, I don't see why the latches should increase power consumption, but there must be some reason. I have some doubt that all my FFs could be latches, as I have some multi-stage counters in there, I don't see how that could be implemented with latches. 300 mA is not a shocker with a 128 macrocells. I don't know what family you are referring to, the 95xx comes in

108, 144 and 180 MCs in that range. I've used some of the 144 and 216 MC versions, and I'm sure they drew close to 200 mA, and that is within sight of the datasheet figures, anyway. Xilinx's formula for all MCs in low-power, and no clock is Icc = 0.9*#MC. For 36 macrocells, all in low power, then the current should be 0.9 * 36 = 32.4 mA. Turning the clock on or off makes only a small and reasonable difference, about 3 mA. So, it is static power draw that seems to be the problem.

Can you describe the netlist problem a little more, and tell me what family it was? I'm using Xilinx ise 4.2i, which is one of the last versions that supported the 5 V chips. I entered my design as a single VHDL file, I have used the boilerplate

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

in most of my processes, I think that is supposed to map to a type-D FF for all sequential assignments. A quick scan of the xxx.rpt file shows a whole bunch of lines like :

/a_hi := enable_out * apol * apolold * adrive a_hi.CLKF = /clock_in a_hi.PRLD = GND

That appears to me to be the typical definition of a D FF. There is a fair amount of combinatorial logic in the design, the web case consultant from Xilinx said that could raise power consumption, but he didn't elaborate on that.

Thanks much for the info,

Jon

Jon,

This design is almost 6 years ago - and was a lattice ispLSI1032 normal currents were something like 200..220mA, so 300mA was almost

50% increase. I must admit that the original design was done in schematic entry and maybe some conversion problem may have risen.

To elaborate on your doubt on latch power - this is/was done by a couple of OR or XOR ports (I don't remember all the details anymore).

By examining the netlist, one particular part was repeated a lot of times (the latches) of which there were quite some in the design. This design was amongst other things an interface to a 8051 µC so there is always at least one latch to split address and data. Then I built a single latch using VHDL and schematic and comparing the two netlists. I found that this was done a different way. So I then edited the original netlist with the VHDL generated netlist part. This way I cound reduce the current consumption to normal values.

Like you tell you are using an older version of ISE it can well be that there are some minor bugs in the netlist generation that causes the problems. As the design is 'only' 36MC's you should be able to scan for possible issues with what you had in mind, don't you think?

Good luck,

Luc

If you can measure Idd in the positive supply line you could try the following.

Turn all 7 outputs high. Measure Idd. Turn one output low. Measure Idd.

Increase the number of outputs low until all are off. Measure Idd each time.

The changes of Idd should be comparable to the output IOH.

Drive all inputs high. Measure Idd.

Turn each output off and note the change in Idd. Unless you have low value pullups/pulldowns you may have to measure all high then all low.

The will give you an indication of the input current taken by all of your input cells. Does it compare with your datasheet?

Ideally you can do this without changing the output state. Your design may not ket you do this.

Take you original Idd and subtract the output current and input current. This gives you the active supply current+plus any static pin clashes.

It's worth running a dvm over pins which you think are inactive just to make sure that they are floating.

Good luck. Andy

There will be a Product term OR collector current adder, and that WILL hike with usage. Each wide-and product term, uses an open drain sense amp scheme in these older devices.

As a simple test, you could set up the same FF usage, same power flags, but design a simple shift register - single D FF's. That will have the same qty of MACROCELLs enabled, but a fraction of the OR channels. If Icc plummets, then that is your problem.

Ouch. You could look at the Atmel ATF1502ASL and ATF1504ASL. that have 5V operation, and low Static Icc.

-jg

the 5 V chips.

Jon; Last year I was using ISE 7.1 (SP4) for doing XC95108 and XC95216 (XC95288?) CPLD designs. BTW, ISE v6.3 was reasonably sized; the code bloat started with v7.1. ISE v8 and up are so huge they will only fit on DVDs.

-Dave Pollum

the 5 V chips.

Hmm, maybe I believed Xilinx's own material, which I think in ise 5.2 or whatever said it would be the last release to support the 5 V chips. Very interesting to hear that 7.1 handles them also. What about 5 V Spartan? I do more of that then 9500 parts.

Jon

With no load on the outputs, this shouldn't make any difference.

Why should changing an input from high to low change the Idd, when there is nothing connected to the output pin?

With nothing connected to any input, there should be no input current.

They are all grounded by the default "ground all unused pads" option, which Xilinx recommended.

Anyway, I did some more current measurements : erased 23 mA simple config 39 mA complex config 75 mA

The "simple config" is a design that patches a bug in an ASIC, it has 8 D flip-flops and 6 gates, so it uses only a small number of product terms and MCs in the 9536. That current draw is still WAY over what is predicted by Xilinx's formula, which is now clearly wrong in my opinion. This problem has gone from a "help me fix my mistake" situation to a "help me convince Xilinx to publish a better procedure for power estimation". I'm not asking for even a 10% accuracy, but up to 200% error is not acceptable!

Jon

In an ideal world, the Fitter would read a simple model file, and calculate the Power figures for you.....

I notice that the 9536XL power eqn adds Product Term values, and they have ICC(mA) = MCHS(0.175*PTHS + 0.345) + MCLP(0.052*PTLP+ 0.272) + 0.04 * MCTOG(MCHS +MCLP)* f

So I'd ask Xilinx what those coefficents are for the XC9536. this formula does show config can have a BIG effect on the Icc.

or, you could use you numbers above, to get something like MCLP(0.48*PTLP+ 0.640) for the older part.

-jg

Another simple check you could do, is flip the macrocells to HIGH power, and check the Icc does actually increase - just to verify that setting is taking effect.

-jg

Oh, yeah! It really increases, to about 130+ mA! I didn't let ir run for more than a few seconds at that level, as the little chip gets REALLY hot, well over 50 C at the package exterior. This test was done when there was significantly less logic in the design, so it would likely be worse now.

Jon

the 5 V chips.

Jon; ISE 6.3i doesn't support 5v Spartan. It supports Spartan II and 3. I'm guessing, but maybe ISE 4.2i was the last version that supported

5v Spartan.

-Dave Pollum

ISE 9.1 also supports the XC9500-series. But the later ISE-versions seem to have some problems in regards to these CPLDs. I've bumped into a problem where the FSM extraction acted up for example:

/Andreas