UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor jegan02
Visitor
12,057 Views
Registered: ‎01-10-2014

SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution
My custom Spartan 6 board is working great for the most part.  Occasionally, I noticed that the FPGA does not start up properly on power up.  The symptom is that a "confidence" LED (configured to blink at 1 Hz on power up) never turns on.  Unfortunately, I have not been able to reproduce this on my bench so I don't know what state the configuration signals are in when it happens.  I just know that my configuration fails to run.   I verified that the main 3.3V supply rail is turning on in the shape of a nice clean ramp (@ 1.8V / ms).  I believe the Spartan 6 FPGA internal POR of 10mS.  Anyway, I probed the critical configuration signals during a power up when the FPGA ran fine.  They looked fine except for the INIT_B mysteriously is driven to 1.8V after the DONE bit is asserted.  I would expect the INIT_B to stay at 3.3V since the VCCO_2 bank is tied to 3.3V.  See the attached schematics.  I verified this is true on at least 2 boards.  Is this normal?  The other signals on bank 2 do swing between 0 and 3.3V as expected.  See the attached trace "tek00064.png":
YELLOW:  VccAux, and VCCO_2 (main 3.3V rail)
PINK: Vccint (1.2V)
BLUE: INIT_B (stays low for Tpor (~7-10mS), Spartan 6 releases it and is pulled high to 3.3V through R6, driven to 1.8V after configuration is complete).
GREEN: DONE
A few other notes:
-  I'm using a Xilinx platform flash and the master serial method for configuration
- SUSPEND stays low through the entire configuration process
The INITB behavior may have nothing to do with the problem I saw.  Based on the configuration method I am using and how my voltage rails are power do you have any general thoughts on how I could improve this design to allow the boot process more reliable?  One immediate though I had was to bring PROGRAM_B signal to our host processor in the event a global reset is needed.
Cheers,
John
sch_01.jpg
sch_02.jpg

 

tek00064.png
0 Kudos
1 Solution

Accepted Solutions
Instructor
Instructor
18,604 Views
Registered: ‎08-14-2007

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

Does this problem only happen on power-up, or if you use JTAG (or a pushbutton on PROG_B) to reconfigure the board does it sometimes happen, too?

 

The only thing I can think is that the 200 MHz oscillator can sometimes take longer to stabilize than the configuration time of the FPGA.

 

It's a good idea in general to have a reset circuit for the DCM that gives it a reset pulse when the DCM loses lock.  My designs that use DCM's generally have a counter that operates on a constant clock (not the output of the DCM they need to reset).  While the DCM is locked and the status bits indicate that the DCM's input clock is running, the counter is held in reset.  Otherwise the counter counts up and the DCM is reset when the counter is greater than 15/16 of full range (top four bits are 1).  The counter is allowed to wrap, releasing the DCM reset.  Then the DCM has time until the counter reaches 15/16th again in order to lock.  The length of the counter depends on the input clock.  Make sure its time to reach the reset condition is longer than the datasheet DCM lock time.

 

[Edit]

 

I realize that I may need to explain why the reset circuit is necessary.  The DCM will not try to re-acquire lock unless you reset it.  So If your input clock has changed frequency since the DCM's initial lock you must reset the DCM to regain lock.

-- Gabor
16 Replies
Xilinx Employee
Xilinx Employee
12,052 Views
Registered: ‎01-03-2008

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

You have an LED hanging off of DONE and according to the scope trace it is getting only up to ~2.1V instead of the 3.3V that it should be at. 

 

Try removing D6 and see if that results in 100% programming success.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
Instructor
Instructor
12,044 Views
Registered: ‎08-14-2007

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

INIT_B is an I/O after configuration is complete.  If your design doesn't use this IO, then it gets treated just like other "unused" pins.  Check the bitgen settings to see what happens to unused pins.  If they are pulled down, then that might explain the 1.8V level after config.  As you said, this probably has nothing to do with the failure mode.

 

When you get the failure to configure, is the DONE light illuminated?  If so, then I suspect McGett has the correct answer.  If not, there must be something else going on.  If you can connect a JTAG cable to the board, you can use Impact to read the configuration status register (in the debug menu of impact).  Read it after a normal start up and also after an abnormal one to see what might be different.

 

[Edit]  I noticed a 10K pull-down on M1.  If that's the actual value of the board-level resistor, it's too high.  Mode pins have internal pullups, and to pull them down you should use something less than 1K ohms.  If you don't need the M1 pin for IO after config, you can use a very small resistor value or even ground it directly.

-- Gabor
0 Kudos
Visitor jegan02
Visitor
12,028 Views
Registered: ‎01-10-2014

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

Excellent catch!  I'll try this.

0 Kudos
Visitor jegan02
Visitor
12,024 Views
Registered: ‎01-10-2014

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

Thank you so much for your quick reply.

 

That explains the INIT_B mystery.  Unused pins are configured to be pulled down.  This happens after configuration is complete so I agree this is probably unrelated.

 

The DONE LED "direct" driver topology was pulled from the SP601.  The difference may be that my VCCO_2 and VCCAUX is at 3.3V (not 2.5 on the eval board) putting an invalid voltage on DONE.  I'll try removing this LED. 

 

I was able to reproduce the problem this morning.  It seems to happen only to certain boards.  Anyway the DONE LED is illuminated.  Below is the output of the status registers as read by Impact.  I immediately noticed that that M1 and M0 were sampled incorrectely.  Unfortunatley, I did notice the 10K pull-up / pull-down error months ago and have applied a rework (adding a solder bridge across the R43 and R80 resistor pads.  If I remember correctly the 10K prevented the M1/M0 pins from ever being sampled correctly.  Maybe I'm dealing with noise on those pins?  Let me know if you see anything else strange in the Impact output.

 

 

INFO:iMPACT - Current time: 3/19/2014 7:59:38 AM
Maximum TCK operating frequency for this device chain: 15000000.
Validating chain...
Boundary-scan chain validated successfully.
'2': Reading bootsts register contents...
[0] VALID_0 - ERROR OR END OF STARTUP (EOS) DETECTED : 1
[1] FALLBACK_0 - FALLBACK RECONFIGURATION ATTEMPT DETECTED : 0
[2] RESERVED : 0
[3] WTO_ERROR_0 - WATCHDOG TIME OUT ERROR : 0
[4] ID_ERROR_0 - FPGA DEVICE IDCODE ERROR : 0
[5] CRC_ERROR_0 - CYCLIC REDUNDANCY CHECK (CRC) ERROR : 0
[6] VALID_1 - ERROR OR END OF STARTUP (EOS) DETECTED : 0
[7] FALLBACK_1 - FALLBACK RECONFIGURATION ATTEMPT DETECTED : 0
[8] RESERVED : 0
[9] WTO_ERROR_1 - WATCHDOG TIME OUT ERROR : 0
[10] ID_ERROR_1 - FPGA DEVICE IDCODE ERROR : 0
[11] CRC_ERROR_1 - CYCLIC REDUNDANCY CHECK (CRC) ERROR : 0
[12] STRIKE CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS : 0
[13] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS : 0
[14] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS : 0
[15] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS : 0
'2': Reading status register contents...
[0] CRC ERROR : 0
[1] IDCODE ERROR : 0
[2] DCM LOCK STATUS : 1
[3] GTS_CFG_B STATUS : 1
[4] GWE STATUS : 1
[5] GHIGH STATUS : 1
[6] DECRYPTION ERROR : 0
[7] DECRYPTOR ENABLE : 0
[8] HSWAPEN PIN : 1
[9] MODE PIN M[0] : 1
[10] MODE PIN M[1] : 1
[11] RESERVED : 0
[12] INIT_B PIN : 1
[13] DONE PIN : 1
[14] SUSPEND STATUS : 0
[15] FALLBACK STATUS : 0

done_led.jpg
0 Kudos
Instructor
Instructor
12,020 Views
Registered: ‎08-14-2007

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

I just want to confirm that this status register information is from the condition when the board did not start up properly?  The startup-related status seems normal, i.e. DONE is showing high as well as the global write enable, which would normally come up last during startup.

 

By the way, if you suspect the DONE light to be the issue, another workaround that does not involve removing parts would be to enable the "internal DONE pipe" in the Bitgen startup options.  This causes the startup circuitry to use the internal DONE signal rather than reading the actual pin.

 

As for the M0 and M1 pins, I have found that the reported value of these in the status register is not accurate for a configured device.  I'd suggest looking at the configuration status after a successful start-up and see if they show up differently.  Unless you see a difference between the two, I wouldn't read too much into this.

-- Gabor
0 Kudos
Visitor jegan02
Visitor
12,016 Views
Registered: ‎01-10-2014

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

The status information is from the condition when the board does not start.  I am in the process of trying to capture INIT_B, DONE, and both power rails on the scope using this board that exhibits the problem.  Anything else you think is worth probing?  Also, I will try reading out the status register routinetly when the FPGA does run normally and inspect the M0/M1 pins.

0 Kudos
Visitor jegan02
Visitor
12,014 Views
Registered: ‎01-10-2014

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

The scope trace of INITB, power rails, and done looks the same in both the working condition and failed startup condition.  The status register read also looks the same M1/M0 are always reports as high ('1').  

0 Kudos
Instructor
Instructor
12,012 Views
Registered: ‎08-14-2007

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

This is beginning to look like a system issue rather than an FPGA configuration issue.  Have you checked that the clock inputs to the FPGA are running when the start-up fails?  Is there anything besides clock, like a reset signal, that might prevent the LED from blinking?

-- Gabor
0 Kudos
Visitor jegan02
Visitor
12,010 Views
Registered: ‎01-10-2014

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

I agree with your inclination that it appears to be a system issue.  The removal of the LED hanging off DONE did not help.  Also, if it was a configuration issue, the DONE signal would probably have stayed deasserted.  I'll start to explore power, clocks, and resets  Thanks.

0 Kudos
Visitor jegan02
Visitor
10,426 Views
Registered: ‎01-10-2014

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

I noticed I have a floating pin driving my global reset pin (yikes!).  I tried tieing this low in the top level hdl but the symptom persists.  My host processor is not programmed to generate a reset.  Ideally (for now at least)  I would like to operate without an asyncronous external reset and just used the default values used in the hdl signal declaration.  Any tips for handling this?  Most of vhdl processes looks like:

if(reset = '1')  then

    set signals to default values;

else

     if rising_edge (clock) then

          do stuff;

      end if;

end if;

 

Do you see anything wrong with 

signal  reset : std_logoic := 0;

begin

reset <= 0;

to resolve the floating reset issue.  I understand this fix implies the reset block in all my code will probably never happen.

 

It's unfortunate this didn't solve the problem.  I thought this had to be it.

 

0 Kudos
Instructor
Instructor
10,418 Views
Registered: ‎08-14-2007

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

OK - take a deep breath and look back at your design.

 

What does the blinking light depend on?

 

clocks?  any DCM or PLL or MMCM involved in providing a clock?

 

Other reset sources (clock not locked, MIG calibration not complete, etc.)?

 

Other board-level signals (oscillator output enable, etc.)?

-- Gabor
0 Kudos
Visitor jegan02
Visitor
10,415 Views
Registered: ‎01-10-2014

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

You're right on the money.  But there is still a bit of work left.  All asynchronous functionaity (i.e. echoing characters back on the UART) works but anything that depends on a clock doesn't work.  The blinking LED depends on my main 48 MHz system clock.  This is generated by a DCM through a clocking wizard instantiation (see below).  The differential oscillator is 200 MHz (again...lifted from the SP601 design).  I routed the system clock to a pin and noticed that it stopped after 80 uS (and remianed high).  The trace looked like it was only 2 MHz and then changed frequency sporadically during the last 10 uS of its life.  However, I can't be sure my scope's time scale was set to sample fast enough.  Any ideas what could cause the DCM to loose lock?  I haven't explicity routed "LOCKED" to a pin but I assume this is happening.

 

-- Instantiate clk_core_ccd - generated by the Clocking Wizard
clk_core_ccd_i0 : clk_core_ccd
port map(
CLK_IN1_P => clk_sys_pin_p,
CLK_IN1_N => clk_sys_pin_n,
CLK_OUT1 => clk_ccd,
RESET => rst_i,
LOCKED => clock_locked_ccd);

0 Kudos
Instructor
Instructor
18,605 Views
Registered: ‎08-14-2007

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

Does this problem only happen on power-up, or if you use JTAG (or a pushbutton on PROG_B) to reconfigure the board does it sometimes happen, too?

 

The only thing I can think is that the 200 MHz oscillator can sometimes take longer to stabilize than the configuration time of the FPGA.

 

It's a good idea in general to have a reset circuit for the DCM that gives it a reset pulse when the DCM loses lock.  My designs that use DCM's generally have a counter that operates on a constant clock (not the output of the DCM they need to reset).  While the DCM is locked and the status bits indicate that the DCM's input clock is running, the counter is held in reset.  Otherwise the counter counts up and the DCM is reset when the counter is greater than 15/16 of full range (top four bits are 1).  The counter is allowed to wrap, releasing the DCM reset.  Then the DCM has time until the counter reaches 15/16th again in order to lock.  The length of the counter depends on the input clock.  Make sure its time to reach the reset condition is longer than the datasheet DCM lock time.

 

[Edit]

 

I realize that I may need to explain why the reset circuit is necessary.  The DCM will not try to re-acquire lock unless you reset it.  So If your input clock has changed frequency since the DCM's initial lock you must reset the DCM to regain lock.

-- Gabor
Visitor jegan02
Visitor
10,392 Views
Registered: ‎01-10-2014

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

SOLVED!!!

Upon further inspection I found that locked remained high but the CLOCK_VALID status signal from the DCM was dropping out.  In any event, after inspecting the layout (with the oscillator right next the the FPGA routed in a beautiful diff pair), and the soldering job on the 6 pins, I realized there was no termination for the 200 MHz differential oscillator.  Enabling the FPGA's internal termination by applying this pin constraint cleaned up the clock stability during startup immensely.  I've determined the symptom is gone after collecting a bunch of statistics with well over 50 (cold boot) power cycles!!!!  Thank you so much for all of your help and guidance over the past 48 hours.  

 

NET "clk_sys_pin_p" LOC = "C10" | DIFF_TERM = TRUE | IOSTANDARD = LVDS_33 ;
NET "clk_sys_pin_n" LOC = "A10" | DIFF_TERM = TRUE | IOSTANDARD = LVDS_33 ;

 

Previously I just specified the location pin constraint and set the IOSTANDARD = (to single ended) LVCMOS25 for each pin (what was I thinking?!?!).  To increase the robustness of this design and to sleep soundly, I still want to implement a version of your DCM reset circuit if I ever happen to loose lock.  What do you recommend I use to clock the counter?  You talk about using a "constant clock".  My guess is I would somehow want to use a single-ended, buffered version of the differential pair pins.  Since I used the clocking wizard to create and configure the DCM primitive, I assume that the buffer (BUFG?) is already realized inside the generated clock core.  So I guess what is the best way to use the DCM input clock without comprising the signal integrity.  Using one IOB to drive two buffers is not a good idea...correct?  My VHDL to instantiate the generated clock core looks like:

 

-- Instantiate clk_core_ccd - generated by the Clocking Wizard
clk_core_ccd_i0 : clk_core_ccd
port map(
CLK_IN1_P => clk_sys_pin_p,
CLK_IN1_N => clk_sys_pin_n,
CLK_OUT1 => clk_ccd,
RESET => rst_i,
LOCKED => clock_locked_ccd,
CLK_VALID=> clock_valid_internal
);

 

 

 

0 Kudos
Instructor
Instructor
10,380 Views
Registered: ‎08-14-2007

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

You should be able to use the input clock, but you'd need to get rid of the input buffers inside your clocking wizard, or bring out the signal from the clocking wizard.  If you don't feel comfortable editing the code created by the wizard, then go back and change the input setting from "differential" to "internal."  In this mode, the clocking wizard does not instantiate the input buffer.

 

Then in your top level code, instantiate an IBUFDS.  You can actually set the DIFF_TERM in the generic map of this instantiation instead of in the UCF.  The output of the IBUFDS goes two places:

 

1) the clocking wizard configured for "internal" clock input (note it does not need a BUFG in this path).

 

2) A BUFG to drive your reset logic.

 

I'm not sure if this is the case for S6, but I remember that some versions of the clocking wizard would allow you to route the output of the IBUFDS to an output port.  If that's the case you don't necessarily need to instantiate the IBUFDS at the top level, but in my opinion having the buffers in the top level code makes the clock routing more readily apparent, and helps you to avoid trouble if you ever need to make design changes.

-- Gabor
0 Kudos
Visitor jegan02
Visitor
10,375 Views
Registered: ‎01-10-2014

Re: SPARTAN 6 CONFIGURATION PROBLEM

Jump to solution

This is very clear.  I'll try this later today.  Thanks again.

0 Kudos