FPGARelated.com
Forums

Problems with Xilinx Parallel III Cable

Started by Unknown March 28, 2007
Hi,

To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3
XCS400) at the same time, I decided as a programmer to use the Xilinx
Parallel Cable III. I implemented the programmer 100% the same as
found in Xilinx's website (
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html).
The programmer worked, but not without problems. For programming the
Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable
from the LPT port to Programmer was 20cm long and from the programmer
to the uC/FPGA board was not more than 10 cm.
The problem related with this programmer were verification errors, i.e
the PC can't program or read properly from the board. The interesting
thing is how these verification problem came up.
In the morning when I turn the PC and Board on, these verification
errors are a lot. When the code that I want to download is big, its
impossible to program the FPGA/uC, for small codes it works but after
many tries. After 10 tries or so, the programming works  correct and
no verification errors no matter how many times I try to download the
code or how big the code is, and this without even touching a thing on
the hardware!!!

Since this problem applies to more than one board, I assume the
problem must lay on the programmer itself. My explanation is that
maybe the buffer IC's get hot or something...I really don't know.
I want to know if there is anyone who has had problems with this
programmer cable.


Thank You,
JJ

On Mar 28, 11:12 am, jid...@hotmail.com wrote:
> Hi, > > To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3 > XCS400) at the same time, I decided as a programmer to use the Xilinx > Parallel Cable III. I implemented the programmer 100% the same as > found in Xilinx's website (http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html). > The programmer worked, but not without problems. For programming the > Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable > from the LPT port to Programmer was 20cm long and from the programmer > to the uC/FPGA board was not more than 10 cm. > The problem related with this programmer were verification errors, i.e > the PC can't program or read properly from the board. The interesting > thing is how these verification problem came up. > In the morning when I turn the PC and Board on, these verification > errors are a lot. When the code that I want to download is big, its > impossible to program the FPGA/uC, for small codes it works but after > many tries. After 10 tries or so, the programming works correct and > no verification errors no matter how many times I try to download the > code or how big the code is, and this without even touching a thing on > the hardware!!! > > Since this problem applies to more than one board, I assume the > problem must lay on the programmer itself. My explanation is that > maybe the buffer IC's get hot or something...I really don't know. > I want to know if there is anyone who has had problems with this > programmer cable. > > Thank You, > JJ
I'm doing exactly the same, but I'm using the Digilent Parallel JTAG3 cable ($12 http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Cables&Cat=Cable) Impact 6.3 to program my Spartan3-1000, and avrdude to program my ATmega64. I had problems in the past when I had some noisy power supplies in the lab and got mysterious errors, sometimes I had to turn off the noisy power supply to make my JTAG work :) Zoltan
On 28 Mrz., 18:25, "zcsizma...@gmail.com" <zcsizma...@gmail.com>
wrote:
> On Mar 28, 11:12 am, jid...@hotmail.com wrote: > > > > > Hi, > > > To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3 > > XCS400) at the same time, I decided as a programmer to use the Xilinx > > Parallel Cable III. I implemented the programmer 100% the same as > > found in Xilinx's website (http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html). > > The programmer worked, but not without problems. For programming the > > Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable > > from the LPT port to Programmer was 20cm long and from the programmer > > to the uC/FPGA board was not more than 10 cm. > > The problem related with this programmer were verification errors, i.e > > the PC can't program or read properly from the board. The interesting > > thing is how these verification problem came up. > > In the morning when I turn the PC and Board on, these verification > > errors are a lot. When the code that I want to download is big, its > > impossible to program the FPGA/uC, for small codes it works but after > > many tries. After 10 tries or so, the programming works correct and > > no verification errors no matter how many times I try to download the > > code or how big the code is, and this without even touching a thing on > > the hardware!!! > > > Since this problem applies to more than one board, I assume the > > problem must lay on the programmer itself. My explanation is that > > maybe the buffer IC's get hot or something...I really don't know. > > I want to know if there is anyone who has had problems with this > > programmer cable. > > > Thank You, > > JJ > > I'm doing exactly the same, but I'm using the Digilent Parallel JTAG3 > cable ($12http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Ca...) > Impact 6.3 to program my Spartan3-1000, and avrdude to program my > ATmega64. > I had problems in the past when I had some noisy power supplies in the > lab and got mysterious errors, sometimes I had to turn off the noisy > power supply to make my JTAG work :) > > Zoltan
Glad to hear that I am not the only one who has a problem with this programmer!! I thought at the beginning also it has to be some kind of interference from somewhere, but as I said, I usually change nothing, just click many times until it works, and when it does, it works without any problems for hours.But before i reach this phase, it really gives me headach :( JJ JJ
<jidan1@hotmail.com> wrote in message 
news:1175098335.158323.203250@n59g2000hsh.googlegroups.com...
> Hi, > > To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3 > XCS400) at the same time, I decided as a programmer to use the Xilinx > Parallel Cable III. I implemented the programmer 100% the same as > found in Xilinx's website ( > http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html). > The programmer worked, but not without problems. For programming the > Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable > from the LPT port to Programmer was 20cm long and from the programmer > to the uC/FPGA board was not more than 10 cm. > The problem related with this programmer were verification errors, i.e > the PC can't program or read properly from the board. The interesting > thing is how these verification problem came up. > In the morning when I turn the PC and Board on, these verification > errors are a lot. When the code that I want to download is big, its > impossible to program the FPGA/uC, for small codes it works but after > many tries. After 10 tries or so, the programming works correct and > no verification errors no matter how many times I try to download the > code or how big the code is, and this without even touching a thing on > the hardware!!! > > Since this problem applies to more than one board, I assume the > problem must lay on the programmer itself. My explanation is that > maybe the buffer IC's get hot or something...I really don't know. > I want to know if there is anyone who has had problems with this > programmer cable. > > > Thank You, > JJ
The newer Xilinx programming cables (Parallel Cable IV, Platform Cable USB) use comparators rather than simple buffers to establish proper voltage levels from the VREF pin connected to the programmer and VCC supplied eternally (keyboard passthrough or USB). The VCC supplied to the Parallel Cable III powers the buffers; the result is poor signal levels on low voltage interfaces. I had a 2.5V JTAG interface I could not get working when using the Parallel Cable III powered by 2.5V. Just by increasing the VCC to 3.3V, I was able to keep decent logic levels and get the interface working. But I never trusted it; if I got a good result I was happy. The convenience and (decent) reliability of the Platform Cable USB is well worth the price in my mind. - John_H
On 28 Mrz., 18:55, "John_H" <newsgr...@johnhandwork.com> wrote:
> <jid...@hotmail.com> wrote in message > > news:1175098335.158323.203250@n59g2000hsh.googlegroups.com... > > > > > Hi, > > > To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3 > > XCS400) at the same time, I decided as a programmer to use the Xilinx > > Parallel Cable III. I implemented the programmer 100% the same as > > found in Xilinx's website ( > >http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html). > > The programmer worked, but not without problems. For programming the > > Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable > > from the LPT port to Programmer was 20cm long and from the programmer > > to the uC/FPGA board was not more than 10 cm. > > The problem related with this programmer were verification errors, i.e > > the PC can't program or read properly from the board. The interesting > > thing is how these verification problem came up. > > In the morning when I turn the PC and Board on, these verification > > errors are a lot. When the code that I want to download is big, its > > impossible to program the FPGA/uC, for small codes it works but after > > many tries. After 10 tries or so, the programming works correct and > > no verification errors no matter how many times I try to download the > > code or how big the code is, and this without even touching a thing on > > the hardware!!! > > > Since this problem applies to more than one board, I assume the > > problem must lay on the programmer itself. My explanation is that > > maybe the buffer IC's get hot or something...I really don't know. > > I want to know if there is anyone who has had problems with this > > programmer cable. > > > Thank You, > > JJ > > The newer Xilinx programming cables (Parallel Cable IV, Platform Cable USB) > use comparators rather than simple buffers to establish proper voltage > levels from the VREF pin connected to the programmer and VCC supplied > eternally (keyboard passthrough or USB). The VCC supplied to the Parallel > Cable III powers the buffers; the result is poor signal levels on low > voltage interfaces. > > I had a 2.5V JTAG interface I could not get working when using the Parallel > Cable III powered by 2.5V. Just by increasing the VCC to 3.3V, I was able > to keep decent logic levels and get the interface working. But I never > trusted it; if I got a good result I was happy. The convenience and > (decent) reliability of the Platform Cable USB is well worth the price in my > mind. > > - John_H
I used 3.3V JTAG interface since the beginning, and also since the beginning I had problems with it. I think part of the problem might be in the buffer itself. The input voltage at the buffer(74HC125) used there, according to the data sheet, should be max. VCC+1.5. And if you are using VCC=3.3V or 2.5V, the high level voltage coming from the LPT(5V) will be exceeding the max. input voltage. A series resistor was used to limit the current going through the clamp didoe, however the signal might have got distorted because of that.I have also thought about using Schmitt-triggers instead of buffers. At the end I built the exact circuit posted in xilinx website, because I thought the Xilinx team knows better than me. But that circuit has caused me a lot of problems and it seems I am not the only one! JJ
jidan1@hotmail.com wrote:
> > I used 3.3V JTAG interface since the beginning, and also since the > beginning I had problems with it. I think part of the problem might be > in the buffer itself. The input voltage at the buffer(74HC125) used > there, according to the data sheet, should be max. VCC+1.5. And if you > are using VCC=3.3V or 2.5V, the high level voltage coming from the > LPT(5V) will be exceeding the max. input voltage. A series resistor > was used to limit the current going through the clamp didoe, however > the signal might have got distorted because of that.I have also > thought about using Schmitt-triggers instead of buffers. At the end I > built the exact circuit posted in xilinx website, because I thought > the Xilinx team knows better than me. But that circuit has caused me a > lot of problems and it seems I am not the only one!
I've always stuck two (because they are inverting) 74HCT14 Schmidt triggers in there, and have no problems with long parallel cables on a number of different boards and computers.
On 28 Mrz., 21:16, Duane Clark <junkm...@junkmail.com> wrote:
> jid...@hotmail.com wrote: > > > I used 3.3V JTAG interface since the beginning, and also since the > > beginning I had problems with it. I think part of the problem might be > > in the buffer itself. The input voltage at the buffer(74HC125) used > > there, according to the data sheet, should be max. VCC+1.5. And if you > > are using VCC=3.3V or 2.5V, the high level voltage coming from the > > LPT(5V) will be exceeding the max. input voltage. A series resistor > > was used to limit the current going through the clamp didoe, however > > the signal might have got distorted because of that.I have also > > thought about using Schmitt-triggers instead of buffers. At the end I > > built the exact circuit posted in xilinx website, because I thought > > the Xilinx team knows better than me. But that circuit has caused me a > > lot of problems and it seems I am not the only one! > > I've always stuck two (because they are inverting) 74HCT14 Schmidt > triggers in there, and have no problems with long parallel cables on a > number of different boards and computers.
May I ask why you used inverting and not non-inverting schmitt- triggers? I assume if you used inverting schmitt-triggers you would have to change the programmer software to allow these inverted signals to be understandable. JJ
On 28 Mrz., 22:30, jid...@hotmail.com wrote:
> On 28 Mrz., 21:16, Duane Clark <junkm...@junkmail.com> wrote: > > > > > jid...@hotmail.com wrote: > > > > I used 3.3V JTAG interface since the beginning, and also since the > > > beginning I had problems with it. I think part of the problem might be > > > in the buffer itself. The input voltage at the buffer(74HC125) used > > > there, according to the data sheet, should be max. VCC+1.5. And if you > > > are using VCC=3.3V or 2.5V, the high level voltage coming from the > > > LPT(5V) will be exceeding the max. input voltage. A series resistor > > > was used to limit the current going through the clamp didoe, however > > > the signal might have got distorted because of that.I have also > > > thought about using Schmitt-triggers instead of buffers. At the end I > > > built the exact circuit posted in xilinx website, because I thought > > > the Xilinx team knows better than me. But that circuit has caused me a > > > lot of problems and it seems I am not the only one! > > > I've always stuck two (because they are inverting) 74HCT14 Schmidt > > triggers in there, and have no problems with long parallel cables on a > > number of different boards and computers. > > May I ask why you used inverting and not non-inverting schmitt- > triggers? I assume if you used inverting schmitt-triggers you would > have to change the programmer software to allow these inverted signals > to be understandable. > > JJ
...or did you actually mean you used two inverted schitt-triggers becuase you didn't have one non-inverted schmitt-trigger :)
jidan1@hotmail.com wrote:
> > ...or did you actually mean you used two inverted schitt-triggers > becuase you didn't have one non-inverted schmitt-trigger :) >
Yep, thats what I meant ;)
On 28 Mrz., 22:49, Duane Clark <junkm...@junkmail.com> wrote:
> jid...@hotmail.com wrote: > > > ...or did you actually mean you used two inverted schitt-triggers > > becuase you didn't have one non-inverted schmitt-trigger :) > > Yep, thats what I meant ;)
LOL...you might have not known this, but by using two schmitt-triggers (rather than one) you have made the programmer more noise immune! Do you still have the schematic for this circuit?