spartan 3 xc3s1000 not getting programmed

[salimbaba]

Hi,
I am facing a problem, i stuffed a new FPGA spartan 3 xc3s1000 on a custo
board and it is not getting programmed. It gets detected correctly, all th
JTAG pins are in the correct state i.e. Pulled up to 2.5v. When i progra
the FPGA, xilinx ISE 12.1 says program succeeded but i do not see an
functionality of the FPGA.I am only running a counter in the code on th
incoming clock and viewing it on chipscope.
Chipscope detects the core but does not trigger and gives a messag
"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 lef
dry sold but still the same problem.And yes the clock is coming as i saw i
on oscilloscope.

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

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


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

kindly give me pointers to debug the issue.

regards


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

 

[Muzaffer Kal]

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

 

[Jon Elson]

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

 

[kevin93]

On Jan 7, 8:19 am, "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.

regards

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

 

[John Adair]

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 pm, "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.

regards

---------------------------------------        
Posted throughhttp://www.FPGARelated.com

 

[John Adair]

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 pm, "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.

regards

---------------------------------------        
Posted throughhttp://www.FPGARelated.com

 

[salimbaba]

I routed the signal to an external debug pin and observed the signal o
scope but no success. Counter being optimized away can happen, but even i
it is getting optimized away, chipscope should trigger. It doesnt ge
triggered so, anything else ?

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

 

[Mike Treseler]

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

 

[Muzaffer Kal]

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

 

[rickman]

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

 

[salimbaba]

ok the issue has been resolved but i have no idea how..

Previously i was using xilinx 12.1 to synthesize and implement the code
And it was showing the behavior i posted in my first post.

Today, just to check, i synthesized the same code on xilinx 9.1 and i
worked.
I have no idea why wasn't it working on xilinx 12.1, when both the RTLs ar
same.

Has anyone else experienced this problem before ?



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

 

[d_s_klein]

On Jan 11, 12:09 am, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:

ok the issue has been resolved but i have no idea how..

Previously i was using xilinx 12.1 to synthesize and implement the code.
And it was showing the behavior i posted in my first post.

Today, just to check, i synthesized the same code on xilinx 9.1 and it
worked.
I have no idea why wasn't it working on xilinx 12.1, when both the RTLs are
same.

Has anyone else experienced this problem before ?

---------------------------------------        
Posted throughhttp://www.FPGARelated.com

You mean the "works with ISE<12, fails with ISE==12" problem?

Yes, I experience that one a lot. A

 

[salimbaba]

Yes, i mean that the RTL i synthesized using xilinx ISE 12.1 didn't work
FPGA got programmed but didnt show any functionality. Whereas i synthesize
the same RTL using xilinx ISE 9.1 and it worked.

Do you know its reason ?

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

 

[d_s_klein]

On Jan 11, 10:30 pm, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:

Yes, i mean that the RTL i synthesized using xilinx ISE 12.1 didn't work,
FPGA got programmed but didnt show any functionality. Whereas i synthesized
the same RTL using xilinx ISE 9.1 and it worked.

Do you know its reason ?          

---------------------------------------        
Posted throughhttp://www.FPGARelated.com

There is a software defect in Version 12's synthesis (XST) phase. The
same defect is present in Version 11.

In addition, Version 12 has a software defect in the placer (MAP).
That defect is not present in Version 11.

<vent>
I have lost (wasted) many (100 or more) billable hours describing
these defects to Xilinx. After I was *finally* understood, the only
response I heard was "Oh".
</vent>

Two known work-arounds:

1) Never update past ISE Version 10.
2) Use Quartus-II or ISP-Lever.

Unfortunately, both prevent you from using the newest Xilinx parts.
Oh well.

RK

 

[Uwe Bonnes]

d_s_klein <d_s_klein@yahoo.com> wrote:

There is a software defect in Version 12's synthesis (XST) phase. The
same defect is present in Version 11.

In addition, Version 12 has a software defect in the placer (MAP).
That defect is not present in Version 11.

vent
I have lost (wasted) many (100 or more) billable hours describing
these defects to Xilinx. After I was *finally* understood, the only
response I heard was "Oh".
/vent

Probably there is no visible trace of that error in the Xilinx answer data
base.

Could you perhaps describe these errors a little so we don't stumble on
them?

Thanks
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Mawa_fugo]

On Jan 11, 2:09 am, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:

ok the issue has been resolved but i have no idea how..

Previously i was using xilinx 12.1 to synthesize and implement the code.
And it was showing the behavior i posted in my first post.

Today, just to check, i synthesized the same code on xilinx 9.1 and it
worked.
I have no idea why wasn't it working on xilinx 12.1, when both the RTLs are
same.

Has anyone else experienced this problem before ?

---------------------------------------        
Posted throughhttp://www.FPGARelated.com

the one that failed probably pulled out a netlist from your co-worker
last year design,

not a surprise bug

 

[d_s_klein]

On Jan 12, 9:42 am, Uwe Bonnes <b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:

d_s_klein <d_s_kl...@yahoo.com> wrote:
There is a software defect in Version 12's synthesis (XST) phase.  The
same defect is present in Version 11.
In addition, Version 12 has a software defect in the placer (MAP).
That defect is not present in Version 11.
vent
I have lost (wasted) many (100 or more) billable hours describing
these defects to Xilinx.  After I was *finally* understood, the only
response I heard was "Oh".
/vent

Probably there is no visible trace of that error in the Xilinx answer data
base.

Could you perhaps describe these errors a little so we don't stumble on
them?

Thanks
--
Uwe Bonnes                b...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

My notes don't exist anymore, but... I had some Verilog that worked
"just fine" with ISE <= 10, but with 11 and 12 PAR would fail to bind
a LUT. The defect was traced to XST 11 and 12 - if I used the output
of XST-10 then 11 or 12 could finish properly.

Right now I'm fighting a different ISE problem that is consuming all
of my attention: I have data that goes through 3 clock domains, A, B,
and C. These domains are connected with 2-clock/asynch FIFOs from
coregen. The FIFOs are hard placed in the UCF, and regions A and C
have non-overlapping area constraints. B is allowed to go "wherever"
to connect then up.

If I make a small change in the logic in area "A", then area "C" fails
timing, and it fails by a LOT. Looking at the timing report, the net
delay(s) have 25% logic, 75% route. If I go back to "working" and
extract/constrain placement information, it gets worse...

Argh.