JTAG: First of 4 Spartan-3E always UNKNOWN

Hi All,

I have custom board with 4 Spartan-3E (XC3S500E-PQ208). For 
configuration I have both JTAG and slave serial access. Slave serial 
works fine. However, when I try to identify the JTAG chain the first 
FPGA always comes back UNKNOWN.

If I'm correct, impact's response to the identify command lists the 
devices in reverse order. So the when it reports this:

'1': : Manufacturer's ID =Xilinx xc3s500e, Version : 0
INFO:iMPACT:1777 -
    Reading /opt/xilinx-ProgTools-9.1i/spartan3e/data/xc3s500e.bsd...

INFO:iMPACT:501 - '1': Added Device xc3s500e successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
Version is 0000

'2': : Manufacturer's ID =Xilinx xc3s500e, Version : 0
INFO:iMPACT:501 - '1': Added Device xc3s500e successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
Version is 0000

'3': : Manufacturer's ID =Xilinx xc3s500e, Version : 0
INFO:iMPACT:501 - '1': Added Device xc3s500e successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
Version is 1110
INFO:iMPACT:1588 - '4':The part does not appear to be Xilinx Part.
'4': : Manufacturer's ID =Unknown , Version : 14

INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
done.

the unknown device is actually the first in the chain. Slave serial uses 
the same device order, so the problem FPGA is also the first in the 
slave serial chain.

- I'm using a Platform Cable USB.
- VCCAUX is 2.5V
- All DONE pins are commoned with a 330R to 2.5V (VCCAUX)
- All PROG_B pins are commoned with a 4.7K to 2.5V
- All INIT_B pins are commoned with a 4.7K to 3.3V (VCCO)
- ISE 9.1i under linux

I've tried isolating the problem FPGA and it will not identify. I've 
also isolated the last three, these do identify (and configure).

I'm quite sure it is not a faulty FPGA. I've 4 other boards that show 
the same behaviour.

Here are the complete schematics:
http://www.elec.york.ac.uk/intsys/users/ajg112/board.pdf

Any suggestions as to what the problem might be would be a great help

Thanks
Andy

On 31 Mrz., 17:25, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote:
> Hi All,
>
> I have custom board with 4 Spartan-3E (XC3S500E-PQ208). For
> configuration I have both JTAG and slave serial access. Slave serial
> works fine. However, when I try to identify the JTAG chain the first
> FPGA always comes back UNKNOWN.
>
> If I'm correct, impact's response to the identify command lists the
> devices in reverse order. So the when it reports this:
>
> '1': : Manufacturer's ID =Xilinx xc3s500e, Version : 0
> INFO:iMPACT:1777 -
>     Reading /opt/xilinx-ProgTools-9.1i/spartan3e/data/xc3s500e.bsd...
>
> INFO:iMPACT:501 - '1': Added Device xc3s500e successfully.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Version is 0000
>
> '2': : Manufacturer's ID =Xilinx xc3s500e, Version : 0
> INFO:iMPACT:501 - '1': Added Device xc3s500e successfully.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Version is 0000
>
> '3': : Manufacturer's ID =Xilinx xc3s500e, Version : 0
> INFO:iMPACT:501 - '1': Added Device xc3s500e successfully.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Version is 1110
> INFO:iMPACT:1588 - '4':The part does not appear to be Xilinx Part.
> '4': : Manufacturer's ID =Unknown , Version : 14
>
> INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> done.
>
> the unknown device is actually the first in the chain. Slave serial uses
> the same device order, so the problem FPGA is also the first in the
> slave serial chain.
>
> - I'm using a Platform Cable USB.
> - VCCAUX is 2.5V
> - All DONE pins are commoned with a 330R to 2.5V (VCCAUX)
> - All PROG_B pins are commoned with a 4.7K to 2.5V
> - All INIT_B pins are commoned with a 4.7K to 3.3V (VCCO)
> - ISE 9.1i under linux
>
> I've tried isolating the problem FPGA and it will not identify. I've
> also isolated the last three, these do identify (and configure).
>
> I'm quite sure it is not a faulty FPGA. I've 4 other boards that show
> the same behaviour.
>
> Here are the complete schematics:http://www.elec.york.ac.uk/intsys/users/ajg112/board.pdf
>
> Any suggestions as to what the problem might be would be a great help
>
> Thanks
> Andy

impact select chain debug
issue TLR

create a string of 128 '11111111111111111.. with some text editor,
paste it into edit box for dr shift
shift it out
you should see JTAG ID of all 4 devices in chain scaned back in

if there is 32 bit 1'1 at one end of the return string your chain is
broken

Antti

Antti wrote:
  > impact select chain debug
> issue TLR
> 
> create a string of 128 '11111111111111111.. with some text editor,
> paste it into edit box for dr shift
> shift it out
> you should see JTAG ID of all 4 devices in chain scaned back in
> 
> if there is 32 bit 1'1 at one end of the return string your chain is
> broken

Here is the output (Cut and paste from the impact log) for this 
operation done 4 times. You can see how the output is slightly different 
each time, but the changes are only within the first 32 bits (i.e. the 
first device)

// *** BATCH CMD : bsdebug -scandr 
11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 

TDO Capture Data: 
11110000011000000010000010010011000000011100001000100000100100110000000111000010001000001001001100000001110000100010000010010011

// *** BATCH CMD : bsdebug -scandr 
11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 

TDO Capture Data: 
11110000000110001001000001000011000000011100001000100000100100110000000111000010001000001001001100000001110000100010000010010011

// *** BATCH CMD : bsdebug -scandr 
11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 

TDO Capture Data: 
11100000001110000100010000100001000000011100001000100000100100110000000111000010001000001001001100000001110000100010000010010011

// *** BATCH CMD : bsdebug -scandr 
11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 

TDO Capture Data: 
11000000011100001000100001001011000000011100001000100000100100110000000111000010001000001001001100000001110000100010000010010011

On 31 Mrz., 18:20, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote:
> Antti wrote:
>
> =A0 > impact select chain debug
>
> > issue TLR
>
> > create a string of 128 '11111111111111111.. with some text editor,
> > paste it into edit box for dr shift
> > shift it out
> > you should see JTAG ID of all 4 devices in chain scaned back in
>
> > if there is 32 bit 1'1 at one end of the return string your chain is
> > broken
>
> Here is the output (Cut and paste from the impact log) for this
> operation done 4 times. You can see how the output is slightly different
> each time, but the changes are only within the first 32 bits (i.e. the
> first device)
>
> // *** BATCH CMD : bsdebug -scandr
> 11111111111111111111111111111111111111111111111111111111111111111111111111=
1=AD11111111111111111111111111111111111111111111111111111
>
> TDO Capture Data:
> 11110000011000000010000010010011000000011100001000100000100100110000000111=
0=AD00010001000001001001100000001110000100010000010010011
>
> // *** BATCH CMD : bsdebug -scandr
> 11111111111111111111111111111111111111111111111111111111111111111111111111=
1=AD11111111111111111111111111111111111111111111111111111
>
> TDO Capture Data:
> 11110000000110001001000001000011000000011100001000100000100100110000000111=
0=AD00010001000001001001100000001110000100010000010010011
>
> // *** BATCH CMD : bsdebug -scandr
> 11111111111111111111111111111111111111111111111111111111111111111111111111=
1=AD11111111111111111111111111111111111111111111111111111
>
> TDO Capture Data:
> 11100000001110000100010000100001000000011100001000100000100100110000000111=
0=AD00010001000001001001100000001110000100010000010010011
>
> // *** BATCH CMD : bsdebug -scandr
> 11111111111111111111111111111111111111111111111111111111111111111111111111=
1=AD11111111111111111111111111111111111111111111111111111
>
> TDO Capture Data:
> 11000000011100001000100001001011000000011100001000100000100100110000000111=
0=AD00010001000001001001100000001110000100010000010010011


hm chain aint completly broken, weird
well i have seen wrong jtag id been returned, it was digged down to
have excessive 100mhz noise on VCCINT

Antti

Antti wrote:
> hm chain aint completly broken, weird
> well i have seen wrong jtag id been returned, it was digged down to
> have excessive 100mhz noise on VCCINT

Looks like I've got a similar problem. After removing the oscillator 
module the JTAG identification works fine.

Thanks for the pointer

Andy

>hm chain aint completly broken, weird
>well i have seen wrong jtag id been returned, it was digged down to
>have excessive 100mhz noise on VCCINT

How did you resolve the 100mhz noise source problem..?

On 1 Apr., 13:17, sky46...@trline4.org wrote:
> >hm chain aint completly broken, weird
> >well i have seen wrong jtag id been returned, it was digged down to
> >have excessive 100mhz noise on VCCINT
>
> How did you resolve the 100mhz noise source problem..?

removing the 100mhz oscillator :)
that PCB proto was SO BAD that no powersupply bypassing helped.. i
tried
and looked with the scope

BTW it was weird, i was also using lab power supply, so while sweeping
the VCC i could see the JTAG ID to change from virtex to spartan and
then
failing completly

Antti

Andrew Greensted wrote:
> Looks like I've got a similar problem. After removing the oscillator 
> module the JTAG identification works fine.

I've dropped in a lower frequency oscillator module, that seems to have 
improved things. It's not a massive problem, I'll just use a DCM to 
multiply things up.

I'm guessing the oscillator was causing noise on VCCO. However, isn't 
the JTAG TAP and IO powered by VCCAUX?

Andy

Andrew

I would be interested to know if now that JTAG works you hit the same
"feature" that we did recently (otherwise we have a hidden design
bug).

If you power up and program any device using JTAG it completes
programming, releases DONE but sees that DONE is still held by the
other three FPGAs and decides that it has failed and IMPACT returns
failed. We have to try to program all the devices which will all fail
except the last one which releases DONE and sees it high and so
passes. The other three then need programming again which will pass as
done is high.

Colin

On Mar 31, 5:25 pm, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote:
> Hi All,
>
> I have custom board with 4 Spartan-3E (XC3S500E-PQ208). For
> configuration I have both JTAG and slave serial access. Slave serial
> works fine. However, when I try to identify the JTAG chain the first
> FPGA always comes back UNKNOWN.
>
> If I'm correct, impact's response to the identify command lists the
> devices in reverse order. So the when it reports this:
>
> '1': : Manufacturer's ID =Xilinx xc3s500e, Version : 0
> INFO:iMPACT:1777 -
>     Reading /opt/xilinx-ProgTools-9.1i/spartan3e/data/xc3s500e.bsd...
>
> INFO:iMPACT:501 - '1': Added Device xc3s500e successfully.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Version is 0000
>
> '2': : Manufacturer's ID =Xilinx xc3s500e, Version : 0
> INFO:iMPACT:501 - '1': Added Device xc3s500e successfully.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Version is 0000
>
> '3': : Manufacturer's ID =Xilinx xc3s500e, Version : 0
> INFO:iMPACT:501 - '1': Added Device xc3s500e successfully.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Version is 1110
> INFO:iMPACT:1588 - '4':The part does not appear to be Xilinx Part.
> '4': : Manufacturer's ID =Unknown , Version : 14
>
> INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> done.
>
> the unknown device is actually the first in the chain. Slave serial uses
> the same device order, so the problem FPGA is also the first in the
> slave serial chain.
>
> - I'm using a Platform Cable USB.
> - VCCAUX is 2.5V
> - All DONE pins are commoned with a 330R to 2.5V (VCCAUX)
> - All PROG_B pins are commoned with a 4.7K to 2.5V
> - All INIT_B pins are commoned with a 4.7K to 3.3V (VCCO)
> - ISE 9.1i under linux
>
> I've tried isolating the problem FPGA and it will not identify. I've
> also isolated the last three, these do identify (and configure).
>
> I'm quite sure it is not a faulty FPGA. I've 4 other boards that show
> the same behaviour.
>
> Here are the complete schematics:http://www.elec.york.ac.uk/intsys/users/ajg112/board.pdf
>
> Any suggestions as to what the problem might be would be a great help
>
> Thanks
> Andy

Try to add 100R serial resitor between each TCK and the corresponding
FPGA PAD (up the PAD pin and add the resistor)
Verify that the last TDO (FPGA3config to your JTAG connector) is not
routed close to the TCK !!!

I am almost sure your VCCAUX is OK, I will first check the JTAG signal
integrity ;-)

Also, check that the GND is weel connected between the board and your
JTAG emulator.

 - Larry
http://www.amontec.com