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!

Spartan 6 configuration on power up xcf32p Prom

Accepted Solution Solved
Reply
Visitor
Posts: 7
Registered: ‎07-20-2016
Accepted Solution

Spartan 6 configuration on power up xcf32p Prom

I am using the Xilinx XCF32P Flash PROM in with the Spartan 6 lx100 FPGA in master serial mode. The Connections between the Flash Prom and the FPGA are shown in the PDF attached. I am capable of detecting both devices in the JTAG chain and can program the FPGA with my configuration file through the JTAG.

 

After startup, or when I select to program the Flash Prom and have it load the FPGA through ISE iMPACT, I read the Devise status from the FPGA I get the following.

 

INFO:iMPACT - Current time: 6/16/2017 7:43:49 AM

Maximum TCK operating frequency for this device chain: 15000000.

Validating chain...

Boundary-scan chain validated successfully.

'1': Reading bootsts register contents...

[0] VALID_0 - ERROR OR END OF STARTUP (EOS) DETECTED                              :         0

[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

'1': Reading status register contents...

[0] CRC ERROR                                                              :         0

[1] IDCODE ERROR                                                        :         0

[2] DCM LOCK STATUS                                                  :         1

[3] GTS_CFG_B STATUS                                                :         0

[4] GWE STATUS                                                           :         0

[5] GHIGH STATUS                                                        :         0

[6] DECRYPTION ERROR                                               :         0

[7] DECRYPTOR ENABLE                                               :         0

[8] HSWAPEN PIN                                                          :         0

[9] MODE PIN M[0]                                                       :         1

[10] MODE PIN M[1]                                                     :         0

[11] RESERVED                                                               :         0

[12] INIT_B PIN                                                              :         0

[13] DONE PIN                                                               :         0

[14] SUSPEND STATUS                                                 :         0

[15] FALLBACK STATUS                                                :         1

 

 

When Programming the XCF32P and selecting to have it load the FPGA from ISE iMPACT using the following settings I get the messages below

PROGRESS_START - Starting Operation.

'2': Putting device in ISP mode...done.

Maximum TCK operating frequency for this device chain: 15000000.

Validating chain...

Boundary-scan chain validated successfully.

'2': Erasing device...

'2': Erasure completed successfully.

'2': Putting device in ISP mode...done.

'2': Putting device in ISP mode...done.

done.

'2': Putting device in ISP mode...done.

'2': Putting device in ISP mode...done.

'2': Putting device in ISP mode...done.

'2': Putting device in ISP mode...done.

INFO:iMPACT:1624 - '1':Operation terminated.

done.

done.

'2': Putting device in ISP mode...done.

done.

'2': Starting FPGA Load with Prom Data...INFO:iMPACT:563 - '2':Please ensure proper connections as specified by the data book ...

'2': Programming completed successfully.

'2': Programming completed successfully.

PROGRESS_END - End Operation.

Elapsed time =     77 sec.

 

From this it seems like all the JTAG functionality seems to be working, however, after programming when I try to verify the Flash PROM it immediately fails and says

 

'2': Verifying device...

Failed at address, 0'2': Verification Terminated

 

Not sure if the reason the Flash PROM can’t configure the FPGA is due to this. After reading previous threads/posts it seems like this may be an error with the software but I am working with ISE iMPACT version 14.7. The other odd thing about the Flash PROM seems to be if I erase the device ISE iMPACT says it was successful however when I go to blank check it says the Part is not blank and more specifically that Version 0 is not blank. I selected the erase entire device under the erase properties and tried erasing only revision 0 and nothing different happens. I have also never set the device to write protect anything.

 

setting1.png

 

To determine the possible issues as to why the Flash PROM was not configuring the FPGA I started probing on the lines. Below are the various signals.

 

CCLK Configuration clock out of FPGA on boot up when power is first applied. Period of clock is right at 1us as expected. Entire time clock is on seems to be around .21s which doesn’t seem long enough for the entire code that I am trying to load onto the FPGA. MCS File size is 8912kB so I would expect it to take a bit longer

 

 

 

clk-1.png

 

clk-2.png

 

The Data Out signal seem to be unclean this could be where the problem lies but not entirely sure would like some confirmation or opinions. It seems like that data is too sporadic and I would have thought it would have a frequency similar to the clock in order to clock in the data properly.

 

data-1.png

 

 

data-2.png

 

This also occurs 3 time like the Do is trying to send out and because the done pin never goes high it later repeats which seems to also be the case to OE/Reset and INIT B

 

 

 

 oe-reset.png

 

 

 

OE/RESET & INIT B

 

This seems to pulse low for a single clock period then two times like it is trying to reset the configuration again possibly and after it does it twice it then remains low.

Like I have mentioned the Done Pin never goes high and what seem like is happening is that the Flash Prom is trying to configure the FPGA but that possibly the data being transmitted is not a clean enough signal for the FPGA to FPGA to capture and so it never get properly configured and then never sets the Done pin high and after a bit the CCLK stops and so the FLASH PROM stops trying to send the DATA. I am not entirely sure if my though process is correct or if possibly I am missing something else possibly in the pin connections.

 

 


Accepted Solutions
Visitor
Posts: 7
Registered: ‎07-20-2016

Re: Spartan 6 configuration on power up xcf32p Prom

Found out that two of my voltage regulators had swapped capacitors that caused the power on rise time to be much longer than it should be. After adjusting that a bit to get the rise times to be closer I found that first the power on rise time mush faster, the Flash Prom rises to Vccint=1.8 Volts in 4.5ms and the Vcco=3.3volts in 4ms this has solved all the issues of the flash prom not being able to erase or verify. The power cycling does effect the PROM in this fashion, it also seems that if Vcco=3.3volts took any longer than about 5.5 ms then it would cause errors because it reached its operational voltage to long after Vccint reached its power on threshold. Also the Data stream sent from the Flash Prom to FPGA does not vary drastically at its peak values (except for a little over and undershoot) anymore like it did in the picture of the original post of the question. 

 

 

View solution in original post


All Replies
Moderator
Posts: 8,793
Registered: ‎02-27-2008

Re: Spartan 6 configuration on power up xcf32p Prom

h,

 

Check the series resistor to Din is the correct value (is it 20 ohms? or 200, or 2,000 ohms...).  The data should not have inconsistent '1' voltage levels!

Austin Lesea
Principal Engineer
Xilinx San Jose
Visitor
Posts: 7
Registered: ‎07-20-2016

Re: Spartan 6 configuration on power up xcf32p Prom

Currently the resistor value is 22.5 Ohms, I was told to use this value because is was used on a previous design that involved a the Spartan 6 and the XCF04S Flash Prom which worked. I can have the value swapped out, what software or where can I find a reference to do the calculation to get the right value.

Moderator
Posts: 8,793
Registered: ‎02-27-2008

Re: Spartan 6 configuration on power up xcf32p Prom

Is it really 21.5 ohms?

 

A common mistake is to stuff the wrong value component.

 

Check it is the correct value ...

Austin Lesea
Principal Engineer
Xilinx San Jose
Visitor
Posts: 7
Registered: ‎07-20-2016

Re: Spartan 6 configuration on power up xcf32p Prom

I double checked it and it is indeed 21.5 Ohms. The other issue seems to be that the Flash Prom seem to not be fully erasing. When I erase then read back from the Flash prom it says that it is not blank.

Highlighted
Instructor
Posts: 9,048
Registered: ‎08-14-2007

Re: Spartan 6 configuration on power up xcf32p Prom

The blank check failure may be a red herring.  It is my understanding that "Design-Specific Erase Before Programming" means that only the sectors of the flash required to hold the bitstream will be erased.  This is usually the desired behavior in case you also use portions of the device to store other data like MicroBlaze binaries.  If you don't get a verify error when you program the flash, it's probably programmed correctly.

-- Gabor
Visitor
Posts: 7
Registered: ‎07-20-2016

Re: Spartan 6 configuration on power up xcf32p Prom

I do end up getting a verify fail when programming

PROGRESS_START - Starting Operation.
'2': Putting device in ISP mode...done.
Maximum TCK operating frequency for this device chain: 15000000.
Validating chain...
Boundary-scan chain validated successfully.
'2': Erasing device...
'2': Erasure completed successfully.
'2': Putting device in ISP mode...done.
'2': Putting device in ISP mode...done.
done.
'2': Putting device in ISP mode...done.
'2': Putting device in ISP mode...done.
'2': Putting device in ISP mode...done.
'2': Putting device in ISP mode...done.
'2': Programming revision selection to 0.
done.
'2': Putting device in ISP mode...done.
INFO:iMPACT:1624 - '1':Operation terminated.
done.
done.
'2': Putting device in ISP mode...done.
'2': Putting device in ISP mode...done.
'2': Verifying device...
Failed at address, 0'2': Verification Terminated
'2': Putting device in ISP mode...done.
done.
'2': Putting device in ISP mode...done.
'2': Programming completed successfully.
'2': Programming completed successfully.
PROGRESS_END - End Operation.
Elapsed time = 93 sec.

 

When I do erase the device and then read back the beginning and end of the .mcs file is comprised of F's and the middle of the .mcs file seems to have zero's and other values scattered throughout. After programming and then doing a read back the .mcs file changes so that the start of the files seems to have new the new data and then the end of the file still has all ones. Not sure if this is the reason it will not program the FPGA though.  

Visitor
Posts: 7
Registered: ‎07-20-2016

Re: Spartan 6 configuration on power up xcf32p Prom

New Found info,

 So the way the board was designed I am capable of using the JTAG to just access the Flash PROM and can ignore the FPGA for now. After checking some more signals I was able to find that I am truly unable to erase the device and a blank check fails and verify after programming fails. I am able to read the device ID and checked out the wave forms for the JTAG and those all seem to be ok. After more research I was able to find something very similar in

(Problem Erasing XCF16p [ New ]  https://forums.xilinx.com/t5/Silicon-Devices-Others-Archived/Problem-Erasing-XCF16p/td-p/120844

 

where they were running into a similar issue. After looking at my voltage signals I noticed that my rise time for VCCint was around 75ms and for VCCO was around 100ms. The data sheet says that Vccint  TVCC rise time should be a max of 50ms so I am planning on removing a Capacitor to try and meet this requirement. the data sheet also specifies that if the power supply cannot meet this requirement, then the device might not perform power-on-reset properly.

wave.JPG

 

 

 

 

So for the questions

 

1) How exactly does this affects the functionality of the device?

Hopefully more testing and I will be able to answer it myself but so far it is possible this is why the data out that the Flash Prom was sending out had varying levels and why the Flash PROM cannot be properly erased. 

 

2) Is there a delta value in which VCCInt and VCCO are required to reach the recommend voltage levels at? Would a difference of 20ms between when VCCInt reaches its POR threshold and when VCCO reaches its POR threshold reaches its value work. I have not been able to find any documentation specifying this.  

Visitor
Posts: 7
Registered: ‎07-20-2016

Re: Spartan 6 configuration on power up xcf32p Prom

Found out that two of my voltage regulators had swapped capacitors that caused the power on rise time to be much longer than it should be. After adjusting that a bit to get the rise times to be closer I found that first the power on rise time mush faster, the Flash Prom rises to Vccint=1.8 Volts in 4.5ms and the Vcco=3.3volts in 4ms this has solved all the issues of the flash prom not being able to erase or verify. The power cycling does effect the PROM in this fashion, it also seems that if Vcco=3.3volts took any longer than about 5.5 ms then it would cause errors because it reached its operational voltage to long after Vccint reached its power on threshold. Also the Data stream sent from the Flash Prom to FPGA does not vary drastically at its peak values (except for a little over and undershoot) anymore like it did in the picture of the original post of the question.