Reply by April 3, 20082008-04-03
Nico Coesel wrote:
> SOmehow JTAG is extremely sensitive to electrical parameters. IIRC the > method used to generate the waveforms by Impact is not the best around > (data and clk are changed simultaneously). I've also had these sort of > problems on boards with multiple FPGAs. Sometimes adding a small RC to > the clock (TCK) line may help. You can use an oscilloscope to very > setup & hold timing on the JTAG bus.
That's interesting. I did wonder how the JTAG bus is driven. I've had a small project running in the background for a while to make my own usb JTAG module. Perhaps it's time to finish it off. Andy
Reply by April 2, 20082008-04-02
>removing the 100mhz oscillator :)
Didn't that defeat the purpose of the pcb ..? :)
>that PCB proto was SO BAD that no powersupply bypassing helped.. i >tried and looked with the scope
So a new pcb was made..?, what was explicitly changed..?
>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
sweeping Vcc?, iee overlaying a variable amplitude and frequency signal onto Vcc? By the way.. is switch regualator ripple a big issue for spartan fpga?
Reply by Nico Coesel April 1, 20082008-04-01
Andrew Greensted <ajg112@ohm.york.ac.uk> wrote:

>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?
SOmehow JTAG is extremely sensitive to electrical parameters. IIRC the method used to generate the waveforms by Impact is not the best around (data and clk are changed simultaneously). I've also had these sort of problems on boards with multiple FPGAs. Sometimes adding a small RC to the clock (TCK) line may help. You can use an oscilloscope to very setup & hold timing on the JTAG bus. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)
Reply by April 1, 20082008-04-01
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
Reply by colin April 1, 20082008-04-01
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
Reply by April 1, 20082008-04-01
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
Reply by Antti April 1, 20082008-04-01
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
Reply by April 1, 20082008-04-01
>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..?
Reply by April 1, 20082008-04-01
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
Reply by Antti March 31, 20082008-03-31
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