Message-ID: <3ADC78E9.AB79BABF@prowokulta.org> Date: Tue, 17 Apr 2001 19:10:01 +0200 From: Kolja Sulimma Reply-To: kolja@prowokulta.org X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Download Cable Mystery Solved Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 213.23.52.157 X-Trace: 17 Apr 2001 19:10:02 +0100, 213.23.52.157 Lines: 62 X-Complaints-To: abuse@arcor-ip.de Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!213.23.52.157 Xref: chonsp.franklin.ch comp.arch.fpga:5818 XILINX: Please read this and update the download software: ----------- Here is the schematic of the xilinx parallel download cable. http://toolbox.xilinx.com/docsan/3_1i/data/common/hug/chap01/hug01007.htm It has never been very reliable. It has been reported that some combinations of cables, mainboards and parallel board settings did not work. Also dongles and long cables have been a problem. For example Answer 7313: "Parallel cable You cannot use an extension. You cannot extend the cable because the parallel port drivers are not strong enough. The signals will attenuate, the data will become corrupted. Note: Make sure that your parallel cable is not running through a dongle. There have been cases where removing the dongle resolved programming issues." Well, we had a closer look at it. The PROGRAM signal is pulled LOW by the download software to initiate a reconfiguration. The software then holds the signal HIGH during configuration and than releases the signal to high impedance. The PROGRAM signal should remain high at the end of a configuration, usually hold by a pullup resistor. Here is what we saw when we had a look at the PROGRAM signal (top) and its output enable (bottom) at the end of a configuration. Signals are measured at the parallel port. http://bounty.em.informatik.uni-frankfurt.de/~prak/platine/downloadwaves.gif The download software releases the signal, but simultaneously sets its value to LOW. This results in a classical race condition: The output must be reliably disabled before it starts driving the PROGRAM signal low again.Depending on the relative strength of the pullup and pulldown transistors in the parallel port implementation, cable reflection, the buffers used in the dowload cables, its loads, etc. this might work correctly. Or it may not. If the pullup is much weaker than the pulldown (as in the example shown) there is a problem. Ever wondered what the 100pF capacitors in the schematic are there for? They slow the signal down, so that it does not change its value until the buffer is disabled. This is a very dirty solution. Instead the software should first disable the buffer and later change the value. Or even better: Do not change the value at all. Just disable the buffer. Kolja Sulimma ###### From: Greg Neff Newsgroups: comp.arch.fpga Subject: Re: Download Cable Mystery Solved Date: Tue, 17 Apr 2001 16:40:50 -0400 Organization: Microsym Computers Inc. Lines: 34 Message-ID: <4c9pdt4refoimmlmbdc2eb42flmldpldu3@4ax.com> References: <3ADC78E9.AB79BABF@prowokulta.org> NNTP-Posting-Host: hil-qbu-ppr-vty4.as.wcom.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sshuraaa-i-1.production.compuserve.com 987539978 17956 206.175.97.131 (17 Apr 2001 20:39:38 GMT) X-Complaints-To: newsmaster@compuserve.com NNTP-Posting-Date: 17 Apr 2001 20:39:38 GMT X-Newsreader: Forte Agent 1.8/32.548 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!news.compuserve.com!news-master.compuserve.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:5834 On Tue, 17 Apr 2001 19:10:01 +0200, Kolja Sulimma wrote: (snip) >Here is the schematic of the xilinx parallel download cable. >http://toolbox.xilinx.com/docsan/3_1i/data/common/hug/chap01/hug01007.htm > >It has never been very reliable. >It has been reported that some combinations of cables, mainboards and >parallel board settings did not work. >Also dongles and long cables have been a problem. > (snip) We have built the equivalent of the Xilinx parallel cable into a couple of manufacturing test fixtures. We experienced problems with reliability that you described. The main problem that we found is that there are glitches on the signal edges, including the clock signal. This is hardly a surprise, since the parallel port signals have slow edge times, are noisy, and are being buffered by 74HC125 that have no input hysteresis. As a quick fix we put a 470pF cap from the clock signal (pin 3 on the D connector) to ground. This cleaned up the noise and eliminated the extra transitions on the CCLK/TCK signal. In the future we will add a Schmitt trigger to the clock input. =================================== Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com ###### Message-ID: <3ADD3F32.C47838AB@sympatico.ca> From: Eric X-Mailer: Mozilla 4.6 [en] (Win98; U) X-Accept-Language: en,fr-CA,fr-FR MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Download Cable Mystery Solved References: <3ADC78E9.AB79BABF@prowokulta.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 41 Date: Wed, 18 Apr 2001 07:12:39 GMT NNTP-Posting-Host: 64.229.196.233 X-Trace: news20.bellglobal.com 987577959 64.229.196.233 (Wed, 18 Apr 2001 03:12:39 EDT) NNTP-Posting-Date: Wed, 18 Apr 2001 03:12:39 EDT Organization: Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.skycache.com!Cidera!cyclone-sjo1.usenetserver.com!news-out-sjo.usenetserver.com!news3.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:5809 Hi, I also had similar problems with a custom made passive parallel port cable (for serial slave Spartan, but should apply to all Xilinx FPGAs). Problem was not software related (as with the problem you discovered), but with crosstalk and noise in the cable itself. Sometimes it did not configure the FPGA at all, sometimes the FPGA stopped working for no apparent reason at random times. As in your case, it happened only with certain motherboards, cable length and moon phase (well, almost). I started by inserting "quiet" ( "0" during config) port signals interleaved with active ones and using a flat cable (twisted pairs cable with grounded returns would also work). CCLK / DIN crosstalk improved a lot and it nearly solved the problem with short cables, but still hanged with longer ones. The problem disappeared when I added a 1K resistor in serie on the "PROGRAM" pin, and a 2.2 nf to Ground (both on the FPGA board). Crosstalk between signals and PROGRAM pin caused short glitches that restarted the configuration sequence, either during programming itself or while the application was using the interface. Glitches (that are way shorter than the RC delay) are completely eliminated . It now reliably works with 30 feet cables with nearly all ports (including laptops if port is slowed down a bit). When possible, buffering the lines using 74xx14 Schmitt triggers close to the FPGA should be even better (but was not practical for my app). hope this helps. Eric.