From: td@emu.com (Tony Dean) Newsgroups: comp.arch.fpga Subject: Spartan II JTAG reconfiguration bug - workaround Date: 21 Sep 2002 21:30:24 -0700 Organization: http://groups.google.com/ Lines: 41 Message-ID: <33aa9b10.0209212030.73e929f4@posting.google.com> NNTP-Posting-Host: 207.111.213.115 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1032669024 30710 127.0.0.1 (22 Sep 2002 04:30:24 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 22 Sep 2002 04:30:24 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21173 I've just spent the last week in hell, baffled as to why my FPGA design was not working. Was I really THAT bad of a VHDL coder? To make a long and painful story short, it wasn't my fault. And it wasn't Synplicity's fault (sorry about that call to tech support). It is Xilinx's fault. I don't mean to bash Xilinx, as their products are great, but they blew this one. The problem: When using JTAG to configure a Spartan II FPGA (and perhaps Virtex too), the first configuration after power up will work, but subsequent ones will not. Worse, the re-configurations may APPEAR to work, because something did get downloaded, and the Impact programmer chirps "PROGRAM SUCCEEDED". But after 3 days of dissecting your code and backing all the way out to a trivial case (e.g. hard set a few output pins to 01010101 or some such), you'll find as I did that the part just did not get reprogrammed correctly. The problem is that the FPGA needs to have its configuration memory cleared before starting a new download, and the JTAG configuration inexplicably neglects to do this. Whether this is an oversight in the Impact downloader and can be fixed in a subsequent release (I'm using 4.2wP3.x), or whether it is an oversight in the chip design, I don't know. What you have to do is this: before reprogramming the FPGA via JTAG, you must pull the PROGRAM_BAR pin low (that clears the memory), and then bring it back high (if you leave it low, Impact will give you an error, saying the boundary-scan chain test failed). That you can't just use the JTAG pins to reprogram the part, and have to do this little dance with the PROGRAM pin is a flat out bug in my opinion. It should be fixed, or this workaround printed in 24-point red letters in the user's manual. I sincerely hope this posting helps some future poor sap(s) from wasting as much time as I did. -td ###### From: "Marcel" Newsgroups: comp.arch.fpga References: <33aa9b10.0209212030.73e929f4@posting.google.com> Subject: Re: Spartan II JTAG reconfiguration bug - workaround Date: Sun, 22 Sep 2002 10:32:13 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Lines: 52 Message-ID: <3d8d804f$0$34795$e4fe514c@dreader3.news.xs4all.nl> NNTP-Posting-Host: 213.84.89.80 X-Trace: 1032683599 dreader3.news.xs4all.nl 34795 213.84.89.80:14251 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!kibo.news.demon.net!demon!news2.euro.net!transit.news.xs4all.nl!newsfeed.xs4all.nl!xs4all!rhinewceros.xs4all.nl!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21176 Sure not your fault, I experienced also that after configuring an XC2S200 needs to be powered down, before loading a new configuration. When not doing so the behaviour seems unpredictable. "Tony Dean" wrote in message news:33aa9b10.0209212030.73e929f4@posting.google.com... > I've just spent the last week in hell, baffled as to why my FPGA > design was not working. Was I really THAT bad of a VHDL coder? > > To make a long and painful story short, it wasn't my fault. And it > wasn't Synplicity's fault (sorry about that call to tech support). It > is Xilinx's fault. I don't mean to bash Xilinx, as their products are > great, but they blew this one. > > The problem: > When using JTAG to configure a Spartan II FPGA (and perhaps Virtex > too), the first configuration after power up will work, but subsequent > ones will not. > > Worse, the re-configurations may APPEAR to work, because something did > get downloaded, and the Impact programmer chirps "PROGRAM SUCCEEDED". > But after 3 days of dissecting your code and backing all the way out > to a trivial case (e.g. hard set a few output pins to 01010101 or some > such), you'll find as I did that the part just did not get > reprogrammed correctly. > > The problem is that the FPGA needs to have its configuration memory > cleared before starting a new download, and the JTAG configuration > inexplicably neglects to do this. Whether this is an oversight in the > Impact downloader and can be fixed in a subsequent release (I'm using > 4.2wP3.x), or whether it is an oversight in the chip design, I don't > know. > > What you have to do is this: before reprogramming the FPGA via JTAG, > you must pull the PROGRAM_BAR pin low (that clears the memory), and > then bring it back high (if you leave it low, Impact will give you an > error, saying the boundary-scan chain test failed). > > That you can't just use the JTAG pins to reprogram the part, and have > to do this little dance with the PROGRAM pin is a flat out bug in my > opinion. It should be fixed, or this workaround printed in 24-point > red letters in the user's manual. > > I sincerely hope this posting helps some future poor sap(s) from > wasting as much time as I did. > > -td ###### Reply-To: "Blackie Beard" From: "Blackie Beard" Newsgroups: comp.arch.fpga References: <33aa9b10.0209212030.73e929f4@posting.google.com> Subject: Re: Spartan II JTAG reconfiguration bug - workaround Lines: 53 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <36lj9.5146$F83.36@nwrddc03.gnilink.net> Date: Sun, 22 Sep 2002 15:13:03 GMT NNTP-Posting-Host: 4.43.177.233 X-Complaints-To: abuse@verizon.net X-Trace: nwrddc03.gnilink.net 1032707583 4.43.177.233 (Sun, 22 Sep 2002 11:13:03 EDT) NNTP-Posting-Date: Sun, 22 Sep 2002 11:13:03 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.stueberl.de!cox.net!cyclone1.gnilink.net!spamfinder.gnilink.net!nwrddc03.gnilink.net.POSTED!fb931ecd!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21167 In Altera, if you load the program into the configurators, you always need to power cycle, since the configurators only "boot" upon application of power. If you program the part directly via jtag, instead of programming the configurators and letting them program the part, then you don't need to power cycle. I don't know anything about xilinx parts, though. "Tony Dean" wrote in message news:33aa9b10.0209212030.73e929f4@posting.google.com... > I've just spent the last week in hell, baffled as to why my FPGA > design was not working. Was I really THAT bad of a VHDL coder? > > To make a long and painful story short, it wasn't my fault. And it > wasn't Synplicity's fault (sorry about that call to tech support). It > is Xilinx's fault. I don't mean to bash Xilinx, as their products are > great, but they blew this one. > > The problem: > When using JTAG to configure a Spartan II FPGA (and perhaps Virtex > too), the first configuration after power up will work, but subsequent > ones will not. > > Worse, the re-configurations may APPEAR to work, because something did > get downloaded, and the Impact programmer chirps "PROGRAM SUCCEEDED". > But after 3 days of dissecting your code and backing all the way out > to a trivial case (e.g. hard set a few output pins to 01010101 or some > such), you'll find as I did that the part just did not get > reprogrammed correctly. > > The problem is that the FPGA needs to have its configuration memory > cleared before starting a new download, and the JTAG configuration > inexplicably neglects to do this. Whether this is an oversight in the > Impact downloader and can be fixed in a subsequent release (I'm using > 4.2wP3.x), or whether it is an oversight in the chip design, I don't > know. > > What you have to do is this: before reprogramming the FPGA via JTAG, > you must pull the PROGRAM_BAR pin low (that clears the memory), and > then bring it back high (if you leave it low, Impact will give you an > error, saying the boundary-scan chain test failed). > > That you can't just use the JTAG pins to reprogram the part, and have > to do this little dance with the PROGRAM pin is a flat out bug in my > opinion. It should be fixed, or this workaround printed in 24-point > red letters in the user's manual. > > I sincerely hope this posting helps some future poor sap(s) from > wasting as much time as I did. > > -td ###### Message-ID: <3D8DF226.2E87E41C@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Spartan II JTAG reconfiguration bug - workaround References: <33aa9b10.0209212030.73e929f4@posting.google.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 59 Date: Sun, 22 Sep 2002 16:33:46 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1032712426 68.15.41.165 (Sun, 22 Sep 2002 12:33:46 EDT) NNTP-Posting-Date: Sun, 22 Sep 2002 12:33:46 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!proxad.net!easynet-quince!easynet.net!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21163 If you have a spare pin on the FPGA, you can connect that to the /program pin and then use the JTAG to first hit the program pin then reprogram. Tony Dean wrote: > I've just spent the last week in hell, baffled as to why my FPGA > design was not working. Was I really THAT bad of a VHDL coder? > > To make a long and painful story short, it wasn't my fault. And it > wasn't Synplicity's fault (sorry about that call to tech support). It > is Xilinx's fault. I don't mean to bash Xilinx, as their products are > great, but they blew this one. > > The problem: > When using JTAG to configure a Spartan II FPGA (and perhaps Virtex > too), the first configuration after power up will work, but subsequent > ones will not. > > Worse, the re-configurations may APPEAR to work, because something did > get downloaded, and the Impact programmer chirps "PROGRAM SUCCEEDED". > But after 3 days of dissecting your code and backing all the way out > to a trivial case (e.g. hard set a few output pins to 01010101 or some > such), you'll find as I did that the part just did not get > reprogrammed correctly. > > The problem is that the FPGA needs to have its configuration memory > cleared before starting a new download, and the JTAG configuration > inexplicably neglects to do this. Whether this is an oversight in the > Impact downloader and can be fixed in a subsequent release (I'm using > 4.2wP3.x), or whether it is an oversight in the chip design, I don't > know. > > What you have to do is this: before reprogramming the FPGA via JTAG, > you must pull the PROGRAM_BAR pin low (that clears the memory), and > then bring it back high (if you leave it low, Impact will give you an > error, saying the boundary-scan chain test failed). > > That you can't just use the JTAG pins to reprogram the part, and have > to do this little dance with the PROGRAM pin is a flat out bug in my > opinion. It should be fixed, or this workaround printed in 24-point > red letters in the user's manual. > > I sincerely hope this posting helps some future poor sap(s) from > wasting as much time as I did. > > -td -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### From: Pierre-Olivier Laprise Subject: Re: Spartan II JTAG reconfiguration bug - workaround Newsgroups: comp.arch.fpga References: <33aa9b10.0209212030.73e929f4@posting.google.com> User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.18 (i686)) Lines: 37 Message-ID: <_Zpj9.624$%C6.203154@charlie.risq.qc.ca> Date: Sun, 22 Sep 2002 20:45:46 GMT NNTP-Posting-Host: 132.206.73.164 X-Complaints-To: abuse@mcgill.ca X-Trace: charlie.risq.qc.ca 1032727546 132.206.73.164 (Sun, 22 Sep 2002 16:45:46 EDT) NNTP-Posting-Date: Sun, 22 Sep 2002 16:45:46 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!snoopy.risq.qc.ca!charlie.risq.qc.ca!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21177 Tony Dean wrote: > The problem is that the FPGA needs to have its configuration memory > cleared before starting a new download, and the JTAG configuration > inexplicably neglects to do this. Whether this is an oversight in the > Impact downloader and can be fixed in a subsequent release (I'm using > 4.2wP3.x), or whether it is an oversight in the chip design, I don't > know. This might well be a bug, like you say, but there are certain issues that you should be aware of before jumping to conclusions. What you're describing seems to me to be a consequence of Xilinx's attempts at making the SpartanII partially reconfigurable. Indeed, you can imagine how it might be a problem when partially reconfiguring a chip for the config memory to be automatically cleared. However, I'm not sure how this should affect your chip if you are inputing a full bitstream, which should be reconfiguring the entire space and overwriting previous configuration data. > What you have to do is this: before reprogramming the FPGA via JTAG, > you must pull the PROGRAM_BAR pin low (that clears the memory), and > then bring it back high (if you leave it low, Impact will give you an > error, saying the boundary-scan chain test failed). This procedure is in fact documented in many places that speak of the configuration procedure, amongst others in the Spartan-II data sheet under the heading "Initiating Configuration", right next to a flow chart describing the proper configuration flow. I must admit, however, that few people need to know such details, and that it should have been taken care of elsewhere in the automated configuration flows, but there is always a fine line to walk between allowing the majority the easiest use of a product, and the minority to test its limits with a minimum of extra effort. Pierre-Olivier ###### From: Dali Newsgroups: comp.arch.fpga Subject: Re: Spartan II JTAG reconfiguration bug - workaround Date: Mon, 23 Sep 2002 02:34:12 +0000 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <3D8E7DA4.10302@ifrance.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <33aa9b10.0209212030.73e929f4@posting.google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@supernews.com Lines: 56 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news.stealth.net!news.stealth.net!telocity-west!TELOCITY!sn-xit-03!sn-xit-06!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21180 I have seen the same exact behaviour on XCV1000E while using JTAG for the second time after power-up. I first thought, I was doing something wrong but I figured out that even though the software reports a successful programming, it is not. Outputs seem locked in a state where they are alternatively pulled up/down. Never really bathered to report this to Xilinx as JTAG is not the way to go for multiple programming sequences in general. It is a practical way to work-around a too small serial EEprom ;) Dali Tony Dean wrote: > I've just spent the last week in hell, baffled as to why my FPGA > design was not working. Was I really THAT bad of a VHDL coder? > > To make a long and painful story short, it wasn't my fault. And it > wasn't Synplicity's fault (sorry about that call to tech support). It > is Xilinx's fault. I don't mean to bash Xilinx, as their products are > great, but they blew this one. > > The problem: > When using JTAG to configure a Spartan II FPGA (and perhaps Virtex > too), the first configuration after power up will work, but subsequent > ones will not. > > Worse, the re-configurations may APPEAR to work, because something did > get downloaded, and the Impact programmer chirps "PROGRAM SUCCEEDED". > But after 3 days of dissecting your code and backing all the way out > to a trivial case (e.g. hard set a few output pins to 01010101 or some > such), you'll find as I did that the part just did not get > reprogrammed correctly. > > The problem is that the FPGA needs to have its configuration memory > cleared before starting a new download, and the JTAG configuration > inexplicably neglects to do this. Whether this is an oversight in the > Impact downloader and can be fixed in a subsequent release (I'm using > 4.2wP3.x), or whether it is an oversight in the chip design, I don't > know. > > What you have to do is this: before reprogramming the FPGA via JTAG, > you must pull the PROGRAM_BAR pin low (that clears the memory), and > then bring it back high (if you leave it low, Impact will give you an > error, saying the boundary-scan chain test failed). > > That you can't just use the JTAG pins to reprogram the part, and have > to do this little dance with the PROGRAM pin is a flat out bug in my > opinion. It should be fixed, or this workaround printed in 24-point > red letters in the user's manual. > > I sincerely hope this posting helps some future poor sap(s) from > wasting as much time as I did. > > -td ###### From: andrew.bridger@paragon.co.nz (Andrew Bridger) Newsgroups: comp.arch.fpga Subject: Re: Spartan II JTAG reconfiguration bug - workaround Date: 22 Sep 2002 23:00:52 -0700 Organization: http://groups.google.com/ Lines: 11 Message-ID: <7939158e.0209222200.5836e84c@posting.google.com> References: <33aa9b10.0209212030.73e929f4@posting.google.com> NNTP-Posting-Host: 210.55.57.74 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1032760852 19256 127.0.0.1 (23 Sep 2002 06:00:52 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 23 Sep 2002 06:00:52 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news.stealth.net!news.stealth.net!logbridge.uoregon.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21196 Yes, I have experienced a very similar problem. To program my Spartan 2 FPGA properly via JTAG I have to cycle the power first. And yes it did have me fooled for a while, parts of the design would work but other parts did not. I found an SRL16E init = X"0001", output fed back to input was a good test case. I went through the exercise of opening a webcase with Xilinx. I was impressed with the very fast response but we did not solve the problem. I was told that I should not be seeing this behaviour. So it would be interesting to know if this is a bug/feature or not... ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Spartan II JTAG reconfiguration bug - workaround Date: Tue, 24 Sep 2002 15:56:39 -0700 Organization: Xilinx,Inc Lines: 12 Message-ID: <3D90EDA7.11937AF3@xilinx.com> References: <33aa9b10.0209212030.73e929f4@posting.google.com> <_Zpj9.624$%C6.203154@charlie.risq.qc.ca> <33aa9b10.0209240950.6573a03b@posting.google.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: Tony Dean Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!enews.sgi.com!nntp.wetware.com!attdv1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21253 I asked around within Xilinx, and here is the best answer I got: It's a software bug. There really is no need to pull PROG Low. Please download the 5.1i Service Pack 1 software from the support.xilinx.com website. This will eliminate the JTAG reconfiguration bug. If you have problems with some other method of reconfiguring, then we need to get details of how you are doing it. Peter Alfke, Xilinx Applications ###### From: alann@accom.com (Alan Nishioka) Newsgroups: comp.arch.fpga Subject: Re: Spartan II JTAG reconfiguration bug - workaround Date: 24 Sep 2002 18:54:12 -0700 Organization: http://groups.google.com/ Lines: 38 Message-ID: References: <33aa9b10.0209212030.73e929f4@posting.google.com> <_Zpj9.624$%C6.203154@charlie.risq.qc.ca> <33aa9b10.0209240950.6573a03b@posting.google.com> NNTP-Posting-Host: 209.1.249.229 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1032918853 11929 127.0.0.1 (25 Sep 2002 01:54:13 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 25 Sep 2002 01:54:13 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21300 td@emu.com (Tony Dean) wrote in message news:<33aa9b10.0209240950.6573a03b@posting.google.com>... > Pierre-Olivier Laprise wrote in message news:<_Zpj9.624$%C6.203154@charlie.risq.qc.ca>... > > > This procedure is in fact documented in many places that speak > > of the configuration procedure, amongst others in the Spartan-II > > data sheet under the heading "Initiating Configuration", right > > next to a flow chart describing the proper configuration flow. > > You are absolutely right. I don't know how I could have missed that. > > Actually, I do: I was reading the section in the configuration > procedure under "Boundary Scan Mode" (JTAG) which contains misleading > phrases such as "configuration being done entirely throught the TAP > (JTAG port)", and "configuration and readback via the TAP are always > available", and has a step-by-step procedure that does not mention the > PROGRAM pin. > > Nevertheless, I plead guilty to not being observant enough, and I > hereby acquit Xilinx of the heinous crime of docu-negligence, although > I submit that much future grief could be averted if in the JTAG > configuration documentation a simple clause was added, "... and of > course, one must pulse the PROGRAM line low before reconfiguring the > device via JTAG." > > Humbly, > -td Is it not possible to use the SHUTDOWN command with the Spartan-II? I looked through the Spartan-II datasheet and XAPP176, and it doesn't really talk about it. I know this works with Virtex-E. I have been using it for months. The only problem I had was when I installed new software and it set the disable reconfiguration and readback flag. Alan Nishioka alann@accom.com ###### Reply-To: "Steve Casselman" From: "Steve Casselman" Newsgroups: comp.arch.fpga References: <33aa9b10.0209212030.73e929f4@posting.google.com> Subject: Re: Spartan II JTAG reconfiguration bug - workaround Lines: 16 Organization: Virtual Computer Corporation X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: NNTP-Posting-Host: 64.169.101.9 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr14.news.prodigy.com 1032969607 ST000 64.169.101.9 (Wed, 25 Sep 2002 12:00:07 EDT) NNTP-Posting-Date: Wed, 25 Sep 2002 12:00:07 EDT X-UserInfo1: [[PAPDONWJWYB_XYGRNFOFTBTR\B@GXLN@GZ_GYO^JWTEPIB_NVUAH_[BL[\IRKIANGGJBFNJF_DOLSCENSY^U@FRFUEXR@KFXYDBPWBCDQJA@X_DCBHXR[C@\EOKCJLED_SZ@RMWYXYWE_P@\\GOIW^@SYFFSWHFIXMADO@^[ADPRPETLBJ]RDGENSKQQZN Date: Wed, 25 Sep 2002 16:00:07 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!news.tele.dk!small.news.tele.dk!207.115.63.138!newscon04.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr14.news.prodigy.com.POSTED!2ac7f5fa!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21247 The spartan II is a Virtex I and there is no "clear program memory" command in the command set. They do have this in the Virtex II though. However since the configuration files genereated by Impact are full configurations you should be able to write over a configuration with no problem. This must be a software bug. You can try and download Hotman from our web site it is not as "automatic" as impact so it does not have some of the bugs. Steve www.vcc.com > I sincerely hope this posting helps some future poor sap(s) from > wasting as much time as I did.