spartan 3 xc3s1000 not getting programmed

Hi,
I am facing a problem, i stuffed a new FPGA spartan 3 xc3s1000 on a custom
board and it is not getting programmed. It gets detected correctly, all the
JTAG pins are in the correct state i.e. Pulled up to 2.5v. When i program
the FPGA, xilinx ISE 12.1 says program succeeded but i do not see any
functionality of the FPGA.I am only running a counter in the code on the
incoming clock and viewing it on chipscope.
Chipscope detects the core but does not trigger and gives a message
"waiting for core to be armed" or something like that.
So i changed the clock pin of FPGA assuming that the pin may have been left
dry sold but still the same problem.And yes the clock is coming as i saw it
on oscilloscope.

So, i started probing all the signals i.e. DONE, Prog_B and INIT_B to view
their proper behaviour. DONE was going high when xilinx said program
succeeded, INIT_B always goes low at the start of programming sequence. But
Prog_B never goes low :s It should go low to clear the configuration memory
but it doesn't. So, does it have anything to do with the dysfunctional FPGA
?

And i also checked the power rails, before and after programming and they
were stable.


so what can be the problem here?Is is possible that some bank is not
getting proper voltages and while mapping the logic in FPGA, xilinx maps it
to that area, is that possible ?

kindly give me pointers to debug the issue.

regards
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Fri, 07 Jan 2011 10:19:43 -0600, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:

>Hi,
>I am facing a problem, i stuffed a new FPGA spartan 3 xc3s1000 on a custom
>board and it is not getting programmed. It gets detected correctly, all the
>JTAG pins are in the correct state i.e. Pulled up to 2.5v. When i program
>the FPGA, xilinx ISE 12.1 says program succeeded but i do not see any
>functionality of the FPGA.I am only running a counter in the code on the
>incoming clock and viewing it on chipscope.
>Chipscope detects the core but does not trigger and gives a message
>"waiting for core to be armed" or something like that.
>So i changed the clock pin of FPGA assuming that the pin may have been left
>dry sold but still the same problem.And yes the clock is coming as i saw it
>on oscilloscope.
>
>So, i started probing all the signals i.e. DONE, Prog_B and INIT_B to view
>their proper behaviour. DONE was going high when xilinx said program
>succeeded, INIT_B always goes low at the start of programming sequence. But
>Prog_B never goes low :s It should go low to clear the configuration memory
>but it doesn't. So, does it have anything to do with the dysfunctional FPGA
>?
>
>And i also checked the power rails, before and after programming and they
>were stable.
>
>
>so what can be the problem here?Is is possible that some bank is not
>getting proper voltages and while mapping the logic in FPGA, xilinx maps it
>to that area, is that possible ?
>
>kindly give me pointers to debug the issue.

Route the incoming clock to an  output and observe with the scope.
Depending on what you see you need to take different routes to further
debug.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

On 01/07/2011 10:19 AM, salimbaba wrote:

>
> so what can be the problem here?Is is possible that some bank is not
> getting proper voltages and while mapping the logic in FPGA, xilinx maps it
> to that area, is that possible ?
>
I am not sure about Spartan 3, but I believe on earlier Spartans this 
CAn happen.  I thought that the symptom would be a failure to program, 
ie. DONE would stay low, but can't be sure.  But, anyway, check ALL 
power pins to be sure they are getting a valid supply voltage, and that 
it is compatible with the specified voltage for that bank in your config
setup.  Also, if any of the banks need a Vref then make sure that is 
working, too.  (I don't think this would affect the ability to program, 
but it would certainly stop the IO from working.)

Jon

On Jan 7, 8:19=A0am, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
> Hi,
> I am facing a problem, i stuffed a new FPGA spartan 3 xc3s1000 on a custo=
m
> board and it is not getting programmed. It gets detected correctly, all t=
he
> JTAG pins are in the correct state i.e. Pulled up to 2.5v. When i program
> the FPGA, xilinx ISE 12.1 says program succeeded but i do not see any
> functionality of the FPGA.I am only running a counter in the code on the
> incoming clock and viewing it on chipscope.
> Chipscope detects the core but does not trigger and gives a message
> "waiting for core to be armed" or something like that.
> So i changed the clock pin of FPGA assuming that the pin may have been le=
ft
> dry sold but still the same problem.And yes the clock is coming as i saw =
it
> on oscilloscope.
>
> So, i started probing all the signals i.e. DONE, Prog_B and INIT_B to vie=
w
> their proper behaviour. DONE was going high when xilinx said program
> succeeded, INIT_B always goes low at the start of programming sequence. B=
ut
> Prog_B never goes low :s It should go low to clear the configuration memo=
ry
> but it doesn't. So, does it have anything to do with the dysfunctional FP=
GA
> ?
>
> And i also checked the power rails, before and after programming and they
> were stable.
>
> so what can be the problem here?Is is possible that some bank is not
> getting proper voltages and while mapping the logic in FPGA, xilinx maps =
it
> to that area, is that possible ?
>
> kindly give me pointers to debug the issue.
>
> regards
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

Are you sure that the counter has not been optimized away?

If there are no outputs the logic reduction may have removed it -
bring the MSB of the counter out to a physical pin to ensure this
doesn;t happen.

kevin

For starters it should be DONE that is used to clear the config
memory.

Check the configuratin signals by doing a STATUS read using JTAG. THis
will tell you losts including if your mode pins are wrong (bad joint
elimination).

If it is configured check you have a clock and not held in reset (if
implemented in your logic).

John Adair
Enterpoint Ltd. - Home of Drigmorn4. The Spartan-6 Development Board.


On Jan 7, 4:19=A0pm, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
> Hi,
> I am facing a problem, i stuffed a new FPGA spartan 3 xc3s1000 on a custo=
m
> board and it is not getting programmed. It gets detected correctly, all t=
he
> JTAG pins are in the correct state i.e. Pulled up to 2.5v. When i program
> the FPGA, xilinx ISE 12.1 says program succeeded but i do not see any
> functionality of the FPGA.I am only running a counter in the code on the
> incoming clock and viewing it on chipscope.
> Chipscope detects the core but does not trigger and gives a message
> "waiting for core to be armed" or something like that.
> So i changed the clock pin of FPGA assuming that the pin may have been le=
ft
> dry sold but still the same problem.And yes the clock is coming as i saw =
it
> on oscilloscope.
>
> So, i started probing all the signals i.e. DONE, Prog_B and INIT_B to vie=
w
> their proper behaviour. DONE was going high when xilinx said program
> succeeded, INIT_B always goes low at the start of programming sequence. B=
ut
> Prog_B never goes low :s It should go low to clear the configuration memo=
ry
> but it doesn't. So, does it have anything to do with the dysfunctional FP=
GA
> ?
>
> And i also checked the power rails, before and after programming and they
> were stable.
>
> so what can be the problem here?Is is possible that some bank is not
> getting proper voltages and while mapping the logic in FPGA, xilinx maps =
it
> to that area, is that possible ?
>
> kindly give me pointers to debug the issue.
>
> regards
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

For starters it should be INIT that is used to clear the config
memory.

Check the configuratin signals by doing a STATUS read using JTAG.
THis
will tell you losts including if your mode pins are wrong (bad joint
elimination).


If it is configured check you have a clock and not held in reset (if
implemented in your logic).


John Adair
Enterpoint Ltd. - Home of Drigmorn4. The Spartan-6 Development Board.


On Jan 7, 4:19=A0pm, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
> Hi,
> I am facing a problem, i stuffed a new FPGA spartan 3 xc3s1000 on a custo=
m
> board and it is not getting programmed. It gets detected correctly, all t=
he
> JTAG pins are in the correct state i.e. Pulled up to 2.5v. When i program
> the FPGA, xilinx ISE 12.1 says program succeeded but i do not see any
> functionality of the FPGA.I am only running a counter in the code on the
> incoming clock and viewing it on chipscope.
> Chipscope detects the core but does not trigger and gives a message
> "waiting for core to be armed" or something like that.
> So i changed the clock pin of FPGA assuming that the pin may have been le=
ft
> dry sold but still the same problem.And yes the clock is coming as i saw =
it
> on oscilloscope.
>
> So, i started probing all the signals i.e. DONE, Prog_B and INIT_B to vie=
w
> their proper behaviour. DONE was going high when xilinx said program
> succeeded, INIT_B always goes low at the start of programming sequence. B=
ut
> Prog_B never goes low :s It should go low to clear the configuration memo=
ry
> but it doesn't. So, does it have anything to do with the dysfunctional FP=
GA
> ?
>
> And i also checked the power rails, before and after programming and they
> were stable.
>
> so what can be the problem here?Is is possible that some bank is not
> getting proper voltages and while mapping the logic in FPGA, xilinx maps =
it
> to that area, is that possible ?
>
> kindly give me pointers to debug the issue.
>
> regards
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

I routed the signal to an external debug pin and observed the signal on
scope but no success. Counter being optimized away can happen, but even if
it is getting optimized away, chipscope should trigger. It doesnt get
triggered so, anything else ?	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On 1/8/2011 12:33 AM, salimbaba wrote:
> I routed the signal to an external debug pin and observed the signal on
> scope but no success. Counter being optimized away can happen, but even if
> it is getting optimized away, chipscope should trigger. It doesnt get
> triggered so, anything else ?	

Have a look at your counter on the rtl viewer.
If synthesis were happening correctly,
you would have seen something on the scope.
Post the hdl code for the counter.

           -- Mike Treseler

On Sat, 08 Jan 2011 02:33:42 -0600, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:

>I routed the signal to an external debug pin and observed the signal on
>scope but no success. 

It's not clear to me whether you were able to see the incoming clock
(not dcm output etc.) on the debug pin.
If you're able to see the clock on the debug pin,  then there is an
issue with the rest of your design. Did you simulate your RTL? One way
to prevent it being optimized out is to 'or' your counter output
vector and send it out to the same debug pin. The simulate the design
in RTL, do P&R, check timing carefully and/or simulate gate level
netlist.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

On Jan 8, 3:33 am, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
> I routed the signal to an external debug pin and observed the signal on
> scope but no success. Counter being optimized away can happen, but even if
> it is getting optimized away, chipscope should trigger. It doesnt get
> triggered so, anything else ?

No, if the counter is optimized away, chipscope won't have anything to
trigger on.  But I would expect an error from chipscope when it tries
to hook into the design and finds the signals missing.

I'm a little unclear on what you are saying about the config pins.  If
you were using the config interface to load the device, you would
drive the PROG pin low to start the configuration.  The FPGA then
pulls DONE low and INIT low.  After some time INIT goes high.  You can
hold INIT low if you want to delay the start of configuration.  Once
INIT goes high the configuration proceeds and when complete DONE goes
high.  Like INIT, DONE is bidirectional and can be forced low to delay
startup of the FPGA.  After the device finished configuration, the
INIT pin will go low if there is a CRC error in the data stream.

To the best of my knowledge, when programmed through JTAG, the INIT
and DONE pins still toggle normally, but the PROG pin is input only.
So I would expect PROG to remain high at all times and INIT and DONE
will do what they normally do, that is to go low and end up high at
the end.

As to your design, I suggest that you bring all of the counter bits
along with the clock out to I/O pins and observe them with a scope.
That will tell you much more than chipscope ever will at this stage of
the game.

Rick