XIlinx Spartan 2E stuck in configuration mode

Hi

I am trying to programm a XC2S300E through a microcontroller using the
Slave p mode.
I make a ufp file ( which is just a hex file) of my program using
xilinx ISE 8.1 and then using the microcontroller and and slave mode
signals I send it to the fpga.
I have all this working for another design, which is exactly the same
micro but Xc2S150E FPGA. but I can not get this to work on XC2S300E.

here is what happens:

1. I pulsed the  ~prog line low and then high. ( to start the clearing
configuration memory)
2. I see FPGA lowers INIT line ( it shows it is busy clearning the
memory)
3. INIT goes high
4. I am sending Clock along with 8bit data on D[7:0] and CCLK.
5. I see INIT stays high ( so I thought CRC check was okay)
6. DONE stays low, I never see it coming up.

after extensive search on the Xilinx website I read something that I
could have a timing problem and I should keep sending CCLK till DONE
goes high. so I tried just running CCLK for like a full SECOND after I
was done sending my real data, and I still never saw DONE going high.

I purposly changed my hex file to see if I the CRC error happens and
INIT goes low. but I never saw this. INIT was high the entire time
after the initial memory clearning process( FPGA pulled it low then)
so this means I am not as far as CRC test on the flow chart. I am
wondering If FPGA thinks that it is not at the end of the file yet or
if it is reading anything at all.
I also checked the number of bits on hex file and it matches the number
on the Xilinx Datasheet. so I know I build the correct hex file.

I have 3 different boards with XC2S300E that I have this problem with.
so I doubt I have a connectivity issue or anything like that.

I also double checked my pull up and downs like 100 times by now. they
all makes sense and match my board with XC2S150E( which I can configure
with no problem)

Do you guys have any ideas where the problem coming from?.. what other
things I should look at?

I appreciate you taking the time and reading my long email and helping
me

Ben

Ben.Nader@gmail.com wrote:
> Hi
>
> I am trying to programm a XC2S300E through a microcontroller using the
> Slave p mode.
> I make a ufp file ( which is just a hex file) of my program using
> xilinx ISE 8.1 and then using the microcontroller and and slave mode
> signals I send it to the fpga.
> I have all this working for another design, which is exactly the same
> micro but Xc2S150E FPGA. but I can not get this to work on XC2S300E.
>
> here is what happens:
>
> 1. I pulsed the  ~prog line low and then high. ( to start the clearing
> configuration memory)
> 2. I see FPGA lowers INIT line ( it shows it is busy clearning the
> memory)
> 3. INIT goes high
> 4. I am sending Clock along with 8bit data on D[7:0] and CCLK.
> 5. I see INIT stays high ( so I thought CRC check was okay)
> 6. DONE stays low, I never see it coming up.
>
> after extensive search on the Xilinx website I read something that I
> could have a timing problem and I should keep sending CCLK till DONE
> goes high. so I tried just running CCLK for like a full SECOND after I
> was done sending my real data, and I still never saw DONE going high.
>
> I purposly changed my hex file to see if I the CRC error happens and
> INIT goes low. but I never saw this. INIT was high the entire time
> after the initial memory clearning process( FPGA pulled it low then)
> so this means I am not as far as CRC test on the flow chart. I am
> wondering If FPGA thinks that it is not at the end of the file yet or
> if it is reading anything at all.
> I also checked the number of bits on hex file and it matches the
> number on the Xilinx Datasheet. so I know I build the correct hex
> file.
>
> I have 3 different boards with XC2S300E that I have this problem with.
> so I doubt I have a connectivity issue or anything like that.
>
> I also double checked my pull up and downs like 100 times by now. they
> all makes sense and match my board with XC2S150E( which I can
> configure with no problem)
>
> Do you guys have any ideas where the problem coming from?.. what other
> things I should look at?
>
> I appreciate you taking the time and reading my long email and helping
> me
>
> Ben

I use a similar scheme for an XC2S200E and a '50E, except that I use a 
single bit wide data path. Initially I had similar problems. I found that 
the power supply rise was not monotonic, and this seemed to upset things. I 
also found that sometimes if the configuration process failed then the fpga 
needed to be power cycled before it would behave - so I implemented a series 
fet to do precisely that :-] The whole system is in a distributed noisy 
environment, and now I basically turn on the main power with the fpgas 
powered off, wait for everything to settle, then turn on and configure fpgas 
in a staggered sequence. Crude it may be, but it works in the field ...

Dave

Dave wrote:
> Ben.Nader@gmail.com wrote:
> > Hi
> >
> > I am trying to programm a XC2S300E through a microcontroller using the
> > Slave p mode.
> > I make a ufp file ( which is just a hex file) of my program using
> > xilinx ISE 8.1 and then using the microcontroller and and slave mode
> > signals I send it to the fpga.
> > I have all this working for another design, which is exactly the same
> > micro but Xc2S150E FPGA. but I can not get this to work on XC2S300E.
> >
> > here is what happens:
> >
> > 1. I pulsed the  ~prog line low and then high. ( to start the clearing
> > configuration memory)
> > 2. I see FPGA lowers INIT line ( it shows it is busy clearning the
> > memory)
> > 3. INIT goes high
> > 4. I am sending Clock along with 8bit data on D[7:0] and CCLK.
> > 5. I see INIT stays high ( so I thought CRC check was okay)
> > 6. DONE stays low, I never see it coming up.
> >
> > after extensive search on the Xilinx website I read something that I
> > could have a timing problem and I should keep sending CCLK till DONE
> > goes high. so I tried just running CCLK for like a full SECOND after I
> > was done sending my real data, and I still never saw DONE going high.
> >
> > I purposly changed my hex file to see if I the CRC error happens and
> > INIT goes low. but I never saw this. INIT was high the entire time
> > after the initial memory clearning process( FPGA pulled it low then)
> > so this means I am not as far as CRC test on the flow chart. I am
> > wondering If FPGA thinks that it is not at the end of the file yet or
> > if it is reading anything at all.
> > I also checked the number of bits on hex file and it matches the
> > number on the Xilinx Datasheet. so I know I build the correct hex
> > file.
> >
> > I have 3 different boards with XC2S300E that I have this problem with.
> > so I doubt I have a connectivity issue or anything like that.
> >
> > I also double checked my pull up and downs like 100 times by now. they
> > all makes sense and match my board with XC2S150E( which I can
> > configure with no problem)
> >
> > Do you guys have any ideas where the problem coming from?.. what other
> > things I should look at?
> >
> > I appreciate you taking the time and reading my long email and helping
> > me
> >
> > Ben
>
> I use a similar scheme for an XC2S200E and a '50E, except that I use a
> single bit wide data path. Initially I had similar problems. I found that
> the power supply rise was not monotonic, and this seemed to upset things. I
> also found that sometimes if the configuration process failed then the fpga
> needed to be power cycled before it would behave - so I implemented a series
> fet to do precisely that :-] The whole system is in a distributed noisy
> environment, and now I basically turn on the main power with the fpgas
> powered off, wait for everything to settle, then turn on and configure fpgas
> in a staggered sequence. Crude it may be, but it works in the field ...
>
> Dave

Have you checked the obvious stuff like pin-out and power supply
voltages?
Even though the XC2S300E and XC2S150E come in the same packages
there are slight differences in the pin usage.  In the larger packages
the
300E has more power pins, for example.

Also check that the hex file was generated with the correct format
(not bit-swapped vs. the 150E file that worked).  I would suggest
trying to load the working bitstream of the 150E to see if you can
make the INIT go low that way.  If the device doesn't see the correct
preamble it will not start loading code.  Are you using the same
version of tools that prepared the hex file for the 150E?  There was
a bug in the 8.1i iMpact GUI that cased raw hex files to come out
bit-swapped whether you checked the box or not.

HTH,
Gabor

On 13 Sep 2006 17:25:18 -0700, Ben.Nader@gmail.com wrote:

>Hi
>
>I am trying to programm a XC2S300E through a microcontroller using the
>Slave p mode.
>I make a ufp file ( which is just a hex file) of my program using
>xilinx ISE 8.1 and then using the microcontroller and and slave mode
>signals I send it to the fpga.
>I have all this working for another design, which is exactly the same
>micro but Xc2S150E FPGA. but I can not get this to work on XC2S300E.
>
>here is what happens:
>
>1. I pulsed the  ~prog line low and then high. ( to start the clearing
>configuration memory)
>2. I see FPGA lowers INIT line ( it shows it is busy clearning the
>memory)
>3. INIT goes high
>4. I am sending Clock along with 8bit data on D[7:0] and CCLK.
>5. I see INIT stays high ( so I thought CRC check was okay)
>6. DONE stays low, I never see it coming up.
>
>after extensive search on the Xilinx website I read something that I
>could have a timing problem and I should keep sending CCLK till DONE
>goes high. so I tried just running CCLK for like a full SECOND after I
>was done sending my real data, and I still never saw DONE going high.
>
>I purposly changed my hex file to see if I the CRC error happens and
>INIT goes low. but I never saw this. INIT was high the entire time
>after the initial memory clearning process( FPGA pulled it low then)
>so this means I am not as far as CRC test on the flow chart. I am
>wondering If FPGA thinks that it is not at the end of the file yet or
>if it is reading anything at all.
>I also checked the number of bits on hex file and it matches the number
>on the Xilinx Datasheet. so I know I build the correct hex file.
>
>I have 3 different boards with XC2S300E that I have this problem with.
>so I doubt I have a connectivity issue or anything like that.
>
>I also double checked my pull up and downs like 100 times by now. they
>all makes sense and match my board with XC2S150E( which I can configure
>with no problem)
>
>Do you guys have any ideas where the problem coming from?.. what other
>things I should look at?
>
>I appreciate you taking the time and reading my long email and helping
>me
>
>Ben

Check for ringing on the CCLK signal at the fpga... that has nailed us
a couple of times. Try adding 33 pF to ground, just to see if that's
the problem. Sometimes just probing CCLK at the chip will allow a
config to complete.

Rumor has it that some future Xilinx parts will add schmitt triggers
to CCLK and maybe some other config pins. Lately, we're adding
TinyLogic schmitt buffers right at the pin, unless the trace is *very*
short.

CCLK signal integrity requirements are right up there with all the
other clocks on the board.

John

False Rumor,

We still require signal integrity to be correct, and have no plans to
try to deal with bad engineering.

Austin

John Larkin wrote:
> On 13 Sep 2006 17:25:18 -0700, Ben.Nader@gmail.com wrote:
> 
>> Hi
>>
>> I am trying to programm a XC2S300E through a microcontroller using the
>> Slave p mode.
>> I make a ufp file ( which is just a hex file) of my program using
>> xilinx ISE 8.1 and then using the microcontroller and and slave mode
>> signals I send it to the fpga.
>> I have all this working for another design, which is exactly the same
>> micro but Xc2S150E FPGA. but I can not get this to work on XC2S300E.
>>
>> here is what happens:
>>
>> 1. I pulsed the  ~prog line low and then high. ( to start the clearing
>> configuration memory)
>> 2. I see FPGA lowers INIT line ( it shows it is busy clearning the
>> memory)
>> 3. INIT goes high
>> 4. I am sending Clock along with 8bit data on D[7:0] and CCLK.
>> 5. I see INIT stays high ( so I thought CRC check was okay)
>> 6. DONE stays low, I never see it coming up.
>>
>> after extensive search on the Xilinx website I read something that I
>> could have a timing problem and I should keep sending CCLK till DONE
>> goes high. so I tried just running CCLK for like a full SECOND after I
>> was done sending my real data, and I still never saw DONE going high.
>>
>> I purposly changed my hex file to see if I the CRC error happens and
>> INIT goes low. but I never saw this. INIT was high the entire time
>> after the initial memory clearning process( FPGA pulled it low then)
>> so this means I am not as far as CRC test on the flow chart. I am
>> wondering If FPGA thinks that it is not at the end of the file yet or
>> if it is reading anything at all.
>> I also checked the number of bits on hex file and it matches the number
>> on the Xilinx Datasheet. so I know I build the correct hex file.
>>
>> I have 3 different boards with XC2S300E that I have this problem with.
>> so I doubt I have a connectivity issue or anything like that.
>>
>> I also double checked my pull up and downs like 100 times by now. they
>> all makes sense and match my board with XC2S150E( which I can configure
>> with no problem)
>>
>> Do you guys have any ideas where the problem coming from?.. what other
>> things I should look at?
>>
>> I appreciate you taking the time and reading my long email and helping
>> me
>>
>> Ben
> 
> Check for ringing on the CCLK signal at the fpga... that has nailed us
> a couple of times. Try adding 33 pF to ground, just to see if that's
> the problem. Sometimes just probing CCLK at the chip will allow a
> config to complete.
> 
> Rumor has it that some future Xilinx parts will add schmitt triggers
> to CCLK and maybe some other config pins. Lately, we're adding
> TinyLogic schmitt buffers right at the pin, unless the trace is *very*
> short.
> 
> CCLK signal integrity requirements are right up there with all the
> other clocks on the board.
> 
> John
> 

Dave wrote:
> Ben.Nader@gmail.com wrote:
> > Hi
> >
> > I am trying to programm a XC2S300E through a microcontroller using the
> > Slave p mode.
> > I make a ufp file ( which is just a hex file) of my program using
> > xilinx ISE 8.1 and then using the microcontroller and and slave mode
> > signals I send it to the fpga.
> > I have all this working for another design, which is exactly the same
> > micro but Xc2S150E FPGA. but I can not get this to work on XC2S300E.
> >
> > here is what happens:
> >
> > 1. I pulsed the  ~prog line low and then high. ( to start the clearing
> > configuration memory)
> > 2. I see FPGA lowers INIT line ( it shows it is busy clearning the
> > memory)
> > 3. INIT goes high
> > 4. I am sending Clock along with 8bit data on D[7:0] and CCLK.
> > 5. I see INIT stays high ( so I thought CRC check was okay)
> > 6. DONE stays low, I never see it coming up.
> >
> > after extensive search on the Xilinx website I read something that I
> > could have a timing problem and I should keep sending CCLK till DONE
> > goes high. so I tried just running CCLK for like a full SECOND after I
> > was done sending my real data, and I still never saw DONE going high.
> >
> > I purposly changed my hex file to see if I the CRC error happens and
> > INIT goes low. but I never saw this. INIT was high the entire time
> > after the initial memory clearning process( FPGA pulled it low then)
> > so this means I am not as far as CRC test on the flow chart. I am
> > wondering If FPGA thinks that it is not at the end of the file yet or
> > if it is reading anything at all.
> > I also checked the number of bits on hex file and it matches the
> > number on the Xilinx Datasheet. so I know I build the correct hex
> > file.
> >
> > I have 3 different boards with XC2S300E that I have this problem with.
> > so I doubt I have a connectivity issue or anything like that.
> >
> > I also double checked my pull up and downs like 100 times by now. they
> > all makes sense and match my board with XC2S150E( which I can
> > configure with no problem)
> >
> > Do you guys have any ideas where the problem coming from?.. what other
> > things I should look at?
> >
> > I appreciate you taking the time and reading my long email and helping
> > me
> >
> > Ben
>
> I use a similar scheme for an XC2S200E and a '50E, except that I use a
> single bit wide data path. Initially I had similar problems. I found that
> the power supply rise was not monotonic, and this seemed to upset things. I
> also found that sometimes if the configuration process failed then the fpga
> needed to be power cycled before it would behave - so I implemented a series
> fet to do precisely that :-] The whole system is in a distributed noisy
> environment, and now I basically turn on the main power with the fpgas
> powered off, wait for everything to settle, then turn on and configure fpgas
> in a staggered sequence. Crude it may be, but it works in the field ...

The XC2S parts are notorious for being difficult to power.  They went
so far as to recommend that you use an LDO and large caps to generate
the core voltage to make sure the voltage ramp is monotonic in spite of
the the high surge current that the chips produce.  I never was bitten
by this one, but if you missed the spec on power-on surge requirments,
you could be a victim.

The Spartan 3 devices don't have this problem, so sometimes Xilinx does
deal with bad engineering, if it is their own!

On Fri, 15 Sep 2006 07:50:54 -0700, Austin Lesea <austin@xilinx.com>
wrote:

>False Rumor,
>
>We still require signal integrity to be correct, and have no plans to
>try to deal with bad engineering.
>

Whose side are you on? Do you *prefer* your FPGAs to not configure, as
some sort of punishment for crosstalk? 

CCLK is often bit-banged from a uP port and bussed to multiple
devices.  Lately it requires serious added drivers/buffers and
termination to be reliable with the faster FPGAs. Given a "slow" (say,
5 ns) risetime, the noise margin on Spartan3's is down in the
millivolts. Since you really can't clock these things above 20-25 MHz
in most situations, why use a gigahertz clock buffer on this pin?

John

Austin Lesea wrote:

> False Rumor,
> 
> We still require signal integrity to be correct, and have no plans to
> try to deal with bad engineering.

  Is that really what you meant to say ?!
-jg

John Larkin wrote:
> Rumor has it that some future Xilinx parts will add schmitt triggers
> to CCLK and maybe some other config pins.

and Austin Lesea replied:
> False Rumor,
>
> We still require signal integrity to be correct, and have
> no plans to try to deal with bad engineering.
>

 Oddly enough, that particular Schmitt CCLK rumor was
confirmed by Steve Knapp last spring [1] :
>
> Fortunately, this is already a planned enhancement on future families.
>

 Fortunately, those nice GPD guys don't seem to pay any
attention to Austin's newsgroup prevarications.

 Which gives us such improvements as Schmitt triggered
CCLKs,  and S3E's simplified, DCI-free I/O buffers, having
a quarter the input capacitance of a V4.

Brian

[1] Steve Knapp's post about forthcoming Schmitt CCLK pins
    http://groups.google.com/group/comp.arch.fpga/msg/e7a5680ff3675cca

Brian,

I see Steve at lunch, so I will have to ask him who he talked to.

100 mV of hysterisis is pretty much part of all input buffers, but that 
won't do it.

Austin

Brian Davis wrote:
> John Larkin wrote:
> 
>>Rumor has it that some future Xilinx parts will add schmitt triggers
>>to CCLK and maybe some other config pins.
> 
> 
> and Austin Lesea replied:
> 
>>False Rumor,
>>
>>We still require signal integrity to be correct, and have
>>no plans to try to deal with bad engineering.
>>
> 
> 
>  Oddly enough, that particular Schmitt CCLK rumor was
> confirmed by Steve Knapp last spring [1] :
> 
>>Fortunately, this is already a planned enhancement on future families.
>>
> 
> 
>  Fortunately, those nice GPD guys don't seem to pay any
> attention to Austin's newsgroup prevarications.
> 
>  Which gives us such improvements as Schmitt triggered
> CCLKs,  and S3E's simplified, DCI-free I/O buffers, having
> a quarter the input capacitance of a V4.
> 
> Brian
> 
> [1] Steve Knapp's post about forthcoming Schmitt CCLK pins
>     http://groups.google.com/group/comp.arch.fpga/msg/e7a5680ff3675cca
>