cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
9,229 Views
Registered: ‎04-04-2012

XC2C32A CPLD long Configuration time

Jump to solution

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

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
11,598 Views
Registered: ‎07-30-2007

If the delayed output behavior is on all outputs, then it's not anything in the design itself that is the problem. 

 

I looked at your makefile and it looks like you are using some sort of Digilent software to do the CPLD programming. Is this a Digilent board? I am guessing you are using a Digilent programming cable as well.  Depending on what sort of programming cable that you have, the Xilinx iMPACT programming software may support it. I suggest you try using that to program the CPLD instead of the Digilent tools. My mind is fuzzy on this, but there are additional bits that need to be programmed that aren't in the Jedec file, and if the Digilent tools aren't programming them properly, it could hold off self configuration. 

 

/Arthur

View solution in original post

0 Kudos
23 Replies
Highlighted
Professor
Professor
9,223 Views
Registered: ‎08-14-2007

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

-- Gabor
0 Kudos
Highlighted
9,220 Views
Registered: ‎04-04-2012

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

 

0 Kudos
Highlighted
Professor
Professor
9,218 Views
Registered: ‎08-14-2007

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

-- Gabor
0 Kudos
Highlighted
9,216 Views
Registered: ‎04-04-2012

 

 

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.

 

0 Kudos
Highlighted
Scholar
Scholar
9,213 Views
Registered: ‎02-27-2008

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).

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Highlighted
Professor
Professor
9,210 Views
Registered: ‎08-14-2007

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

-- Gabor
0 Kudos
Highlighted
9,201 Views
Registered: ‎04-04-2012

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?

 

0 Kudos
Highlighted
9,197 Views
Registered: ‎04-04-2012

"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!

 

 

0 Kudos
Highlighted
Scholar
Scholar
9,195 Views
Registered: ‎02-27-2008

m,

 

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

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Highlighted
8,988 Views
Registered: ‎04-04-2012

a

I'm not trying to use it as a registered pin.  The VHDL code is

  tp_out <= '0';

 

Is there a specific report / file which would give a positive indication what the compiler/fitter has done so I can give you a better answer? 

 

0 Kudos
Highlighted
8,984 Views
Registered: ‎04-04-2012

Update on some  tests I have done today.

 

I retargeted the code to an eval board for Xc2c256 (the cool 'X' shaped pcb CoolRunner-II Starter Kit).  The long "configuration" time was NOT observed.  The retargeting involved writing a new .ucf file and changing the target device, so I'm fairly confident now that the VHDL/synthesis/fit process is producing what I was expecting (tp_out <='0').

 

Back to my board.

I looked further at the tp_out pin during this long configuration time.  The period is 1.7 seconds, and it appears to be high-z with a weak pull up during this time.

 

I powered the device with only the Vccint (Vccio off).  I saw the output rise to 1.8v for approximately 1.7 sec before going to 0V.

 

I tied TMS, TCK, and TDI to Vccio, there was no change in the startup behavior.

 

I've read the excellent "XAPP440 Power On Behavior of Xilinx CPLD's".  Lots of great insight into what is going on in the chip! 

 

Still no success in changing the behavior with the long config time.  Any ideas are welcome! (does that sound too much like begging?)

 

 

 

 

 

0 Kudos
Highlighted
Scholar
Scholar
8,981 Views
Registered: ‎02-27-2008

I have asked the question to someone here who should know,


I will post back when I get an answer....

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Highlighted
Scholar
Scholar
8,979 Views
Registered: ‎02-27-2008

"VCCINT rise time is a natural. Stalling in the neighborhood of 1-1.2V where it's open to noise might ne something to look at. Frequently hanging a scope probe on VCCINT makes it go away suggesting insufficient Decoupling."

 

Try looking at how the Vccint rises....

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,973 Views
Registered: ‎07-30-2007

Mike,

 

Very curious issue! 

 

I am assuming that none of the other IOs are working until this ~1.7 delay after power-up, correct ? Or is it just this tp_out that isn't working?

 

Archive the project and attach it to your next post. I can take a quick look at it to see if there's any hints in the fitter report.

 

Also are you scoping VccInt at the CPLD pin (as opposed to the output of the regulator - wherever that may be) ?

 

/Arthur

 

0 Kudos
Highlighted
8,968 Views
Registered: ‎04-04-2012

austin.lesea wrote:

Try looking at how the Vccint rises....

 

 


Austin
I looked at Vccint rise times. I saw the plateau you referred to

with an external power supply located about 2ft away I observed the following at the chip.

1) a very fast rise to 375mV, <10usec

2) a monotonic rise from there to 1.00V occurring over 1.6msec.

3) a plateau from 1.00V to 1.40V over 1.6msec

4) a rapid rise to 1.8V over 420usec

 

In the design have a 10uF ceramic about 1in away.  I added a 0.1uF ceramic about 80 mils from the part.  This did not change the 1.7sec configuration time.

 

0 Kudos
Highlighted
8,967 Views
Registered: ‎04-04-2012

@ayang wrote:

Mike,

 

Very curious issue! 

 

I am assuming that none of the other IOs are working until this ~1.7 delay after power-up, correct ? Or is it just this tp_out that isn't working?

 

Archive the project and attach it to your next post. I can take a quick look at it to see if there's any hints in the fitter report.

 

Also are you scoping VccInt at the CPLD pin (as opposed to the output of the regulator - wherever that may be) ?

 

/Arthur

 


Arthur  the delay is seen on all output pins, not just the tp_out pin.

 

I am scoping about 50-100mils from the part.  I am using a Very old scope, HP54501. I think it was one of the first digitals out in the early 1980's.  Fast transients on Vccio won't be captured.

 

See attached for the latest files to build, I am building the x6_1a.jed file, ignore other targets.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
11,599 Views
Registered: ‎07-30-2007

If the delayed output behavior is on all outputs, then it's not anything in the design itself that is the problem. 

 

I looked at your makefile and it looks like you are using some sort of Digilent software to do the CPLD programming. Is this a Digilent board? I am guessing you are using a Digilent programming cable as well.  Depending on what sort of programming cable that you have, the Xilinx iMPACT programming software may support it. I suggest you try using that to program the CPLD instead of the Digilent tools. My mind is fuzzy on this, but there are additional bits that need to be programmed that aren't in the Jedec file, and if the Digilent tools aren't programming them properly, it could hold off self configuration. 

 

/Arthur

View solution in original post

0 Kudos
Highlighted
8,948 Views
Registered: ‎04-04-2012

I'm out of the office today, but I'll give the Impact software a shot when I get in tomorrow. 

 

Any special settings needed for the Impact tool to set these special bits?

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,942 Views
Registered: ‎07-30-2007

Nope, these bits will be programmed properly by iMPACT automagically. =)

 

/Arthur

0 Kudos
Highlighted
5,134 Views
Registered: ‎04-04-2012

Awesome fix!    Thanks.

Using Impact programming tool with Digilent programmer does the trick!

The time "tp_out"  remains High Z is now 1.8msec!

 

Now, how to go forward? 

The Xilinx impact tool, while nice in an engineering environment, doesn't work in our production line which is basically a script with go/no-go response, so I either need to get a fix that works with the Digilent software or find another programming solution.  In the plethora of ./bin/ files supplied by Xilinx is there a command line tool that might work?  Other third party tools?

 

I assume that the bits you are referring to are the ISC done bits?  Is there a reference document describing how to deal this these bits?   I'll be contacting Digilent with this so see if they can be persuaded to apply a fix.  It would be nice to have some supporting documentation to give them.

 

Thanks to everyone who helped out with this!

Mike

0 Kudos
Highlighted
5,131 Views
Registered: ‎04-04-2012
I think I found the reference document "CoolRunner-II Programmer Qualification Specification"
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
5,126 Views
Registered: ‎07-30-2007

The unspecified bits are the 'transfer bits' and the 'done' bit -- they all need to be programmed properly.

 

iMPACT can be run in a script mode.

 

impact -batch whatever.txt

 

whatever.txt is the commands that you want iMPACT to run

 

I expect it to look something like this

 

setmode -bs

setcable -port auto

identify

program -p 1 -e -v myfile.jed

 

In the iMPACT help, there is a section on batch commands so you can find more info there.

 

/Arthur

0 Kudos
Highlighted
5,115 Views
Registered: ‎04-04-2012

Awesome! 

 

The exact install.txt file format (more verbose than needed) was this

 

 

setMode -bs
setCable -target "digilent_plugin"
identify
assignFile -position 1 -file x6_1a.jed
erase -position 1
program -position 1 -verify
identify
closeCable
deleteDevice -all
exit

 

And the syntax for impact was

/opt/Xilinx/13.4/ISE_DS/ISE/bin/lin64/impact -batch install.txt

 

I had some problems with the older version of the Digilent runtime software (seg fault on exit), but they released a new version recently ant that seems to have cleared up that issue.

 

Thanks for helping me get back into production mode!

Mike

0 Kudos