CPLDs

[mcrowe@gcdataconcepts.com]

Hello

I am experiencing an apparent  long Tconfig time of 2 to 3 seconds with a XC2C32A CPLD. The data sheet indicates that Tconfig is 50usec.

The VHDL code (snippet) that I am using consists of

     tp_out <= '0';

when power is applied the pin goes high.  It eventually goes low after 2 to 3 seconds.

The Vcc 1.8V power is derived from a linear regulator (microchip TC1014) from 3.3V standby, which is what powers the CPLD Vccio.

Power on time for Vcc1.8 is ~20usec

Power on time for Vccio is much slower ~500usec.

Power on appears to be monotonic (linear ramps).

I can't measure the relationship between the two because I have crappy equipment.

The VHDL code simulates correctly and has been used for about a year in some other production equipment (probably has the same problem).

While most of the VHDL code is combinatorial, there is a 32kHz clock and a 1 pulse per second "clock".

Anyone have ideas of what might be going on?  Have some test that might provide some insight?  I'm happy to post VHDL code testbenches Makefiles, ... see attachement.

Thanks

Mike

[gszakacs]

It's hard to imagine how your VHDL code could cause a long config time.  It seems more likely

that there is some other dependency that holds up the assertion (low) of the tp_out signal,

possibly a global tristate net.  Perhaps looking through the fitter reports you could find something.

The fact that the time scale is similar to one of your global clock inputs is suspicious.  Another

possibility is that the tp_out signal is not actually on the pin you were scoping.  Make sure that

your .ucf LOC constraints match the fitter report.

-- Gabor

[mcrowe@gcdataconcepts.com]

Thanks for looking at my question and giving the quick response! 

I agree, that the timescale for the pps and the assert is suspicious.  After the power on sequence though, all combinatorial pins start acting "normal" e.g.. No long delays.

tp_out is a signal that I added to insure that there wasn't another signal on on the board pulling it a particular direction.  In my original post I should have added that the observed behavior is common to all output pins. I've  rechecked the .ucf  and the *pad.csv  though and the assignment of tp_out is what I was expecting.

Global tristate net? Would the compiler do something like that automatically?  I'ved look through the fitter reports for something like that and don't seem to see anything there.  I looked at the .rpt file in detail.   I did find a line with

Global Ouput Enable Optimization            : ON

and

Use DATA_GATE Attribute                     : ON

That global output enable optimization being on looked interesting. I turned it off with the -nogtsopt option in the cpldfilt tool.  It didn't affect a change.

Is there a more specific file I should be looking at? 

I've been working through a possible a power on sequencing issue causing a CMOS latch-up that resolves its-self after the device heats up.  Doesn't seem to be anything obvious there.

Any other ideas (far out is fair game at this point)?  Jupiter in conjunction with Saturn?

Thanks

[gszakacs]

Well, the first thing I would try is to decouple the VHDL code from the board electrical issues.

Make a real simple project that just ties all of the outputs to a known value and see if it

starts up more quickly than the original project.  If not, it's an electrical issue.

One more thing...  Do you have pull-up resistors on the JTAG inputs?  It is possible that

floating JTAG lines could cause the device to go into a boundary scan mode...

-- Gabor

[mcrowe@gcdataconcepts.com]

No, I do not have any pull up resistors on the JTAG pins.  I was under the impression that the xc2c32a already had a weak pullup on the JTAG.  Would  a single pullup on the TMS suffice?

Another good thought.  Decouple the design with an "all output all pins low no input pins used"  type of dummy code.  I was hoping that it wouldn't come to that ( effort involved).   I'll give it a try in a few minutes.  Thanks.

[austin]

m,

The weak pullup may be too weak.  Water washed pcb after soldering often contains salts, and the result is a weak pull down (sometimes surprisingly strong pull down from contamination).

[gszakacs]

I didn't see any mention of pullups on the JTAG pins, only the user I/O.  I would think

pulling down the TCK pin would actually prevent any unwanted JTAG activity.  Pulling

TMS high would also work as long as TCK doesn't wiggle too fast under open circuit

conditions.  I normally pull up all JTAG pins except TCK and pull that one low.  However

a pull-up on TCK is also acceptable.  My reasoning for pulling it low is to avoid an

edge during power up.  This is probably unnecessary due to internal POR circuitry.

You might also want to look through XAPP389.

-- Gabor

[mcrowe@gcdataconcepts.com]

I'm experienced with weak pull ups not being sufficient with today's cleaning standards and our local humidity levels (South Mississippi, a dry day is 60%RH).

I've placed a single 23kohm pull up resistor on the TMS line.  The long "configuration" time is still there, no change.

When probing the JTAG lines  before adding the pull up I noticed that when power is applied the TMS, TCK, and TDI lines went to 3.3V within 3ms (monotonic), TDO remained low.  Scope probe resistance is 10Mohm.  Is this normal?

[mcrowe@gcdataconcepts.com]

"Xilinx UG445 CPLD I/O User Guide", p 12 states

"CoolRunner-II devices have internal pull-ups on TDI, TMS, and TCK.
It is not necessary to externally terminate JTAG pins with internal termination; they can be
left floating. External pull-ups on pins with internal termination is allowed, but not
necessary. External pull-down termination is not recommended as it would conflict with
the internal pull-ups."

Your right though it's not in the device data sheet.

I modified the VHDL so that all inputs are ignored, and all outputs are tied low.  No change on the "configuration" time.

I've connected an external power supply so that the 1.8V and the 3.3V power to the CPLD are powered by it.  I haven't seen a change in the behavior (1.7sec "configuration" time).  By powering the CPLD separately the signals to the CPLD remain static (no 32khz clock, no pps signal).

I've browsed through the app note that you suggested,  I'll look at it a little more today.

In my mind, I haven't been able to isolate the problem to anything specific.  It seems I could still have a power on sequencing problem,  a JTAG problem, a firmware problem, or an unknown electronic problem. 

I'm open to more ideas, things to try.  This issue really has me stumped!

[austin]

m,

Is this io pin registered?  If so, the 32 KHz clock is required?  How fast does the clock startup?