There are 18 messages in this thread.
You are currently looking at messages 10 to 18.
On Feb 9, 8:36=A0am, Sean Durkin <news_MO...@tuxroot.de> wrote: > Hi Brian, > > thanks for a lot of useful pointers! See my responses below. > > Brian Davis wrote: > > FWIW another of my favorite Impact 10.1 settings is > > =A0Edit->Preferences->Configuration Preferences-> > > =A0Startup Clock->Automatic Correction > > I think that's the default in ISE11 now, as it should be. > > > =A0If your normal method of configuration works fine, I wouldn't > > worry too much about curable JTAG issues like that. > > The thing is that I'm using configuration via SPI flash on this board. I > =A0was planning to use indirect SPI programming for initial flashing, but > it doesn't work. iMPACT downloads the JTAG->SPI-core-bitfile and then > just quits with "Programming failed", without giving any more detail. > > I suspect this is because the loading of the JTAG->SPI-core fails > because of the issue I'm having on this board. If the bitfile shipped > with iMPACT wasn't created with the DONE_cyle:6-setting, it won't work > on this board. > > Fortunately, I have a dedicated SPI programming connector on the board > as well, so I can use that for flashing. Loading the FPGA through SPI > works fine. > > > =A0I've seen that same sort of problem on a multi-chip V5 > > DONE cascade with Impact 10.1: > > =A0http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/2a29= 1... > > Only one V5 on this board. > > > ------------- > > > Random debug thoughts: > > > Configuration mode > > =A0- are the chip mode pins set to JTAG, or another boot mode? > > =A0- does changing the mode pins to JTAG affect the problem? > > Mode pins are set to SPI, but changing to JTAG or master serial makes no > difference. > > > External DONE timing/levels > > =A0- what value of pullup do you have on DONE pin? > > Originally I had the 300 Ohms Xilinx has in their application notes, but > I've tried different values up to 10k without success. > > > =A0- are you using the "drive DONE" bitgen option? > > Nope, I'll try that tomorrow. But of course I can't change it for the > JTAG->SPI bitfile shipped with iMPACT. Or is there a way to manipulate > settings like that in an existing bitfile? Theoretically this should be > possible by changing some bits and recalculating the CRC, but is this > documented somewhere? > > > =A0- have you tried the 'internal done pipe' bitgen option? > > Yes, no change. > > > =A0- what does the DONE risetime look like on the board? > > =A0- what happpens if you lower the JTAG clock rate? > > No change. > > > =A0- is your DONE LED buffered? ( I've seen some boards with > > =A0 =A0DONE LED hookups that load down the external DONE signal ) > > I don't have it buffered, but I have a transistor hooked up to it to > light up a LED when donfiguration is done. > > cu, > Sean > > -- > Replace "MONTH" with the three-letter abbreviation of the current month > and the two-digit code for the current year (simple, eh?). FWIW: I spent 3 days debugging an isse (see: "XST is driving me crazy" in this usenet group) that was resolved by adding one more clock to the startup stream. In my configuration, done would go high and all of the combitorial logic would word, but none of the sequential logic would work. One more (extra) CCLK, and everythig went working. G.______________________________
Sean Durkin wrote: > >> External DONE timing/levels >> - what value of pullup do you have on DONE pin? > > Originally I had the 300 Ohms Xilinx has in their application notes, > but I've tried different values up to 10k without success. > Values lower than 300 ( down to maybe(?) 100 ohms ) would help if DONE is rising too slow, although 330 should be fine with just one FPGA. What do you measure on the actual board for risetime and high/low voltage levels on the DONE pin ? > >> - is your DONE LED buffered? ( I've seen some boards with >> DONE LED hookups that load down the external DONE signal ) > > I don't have it buffered, but I have a transistor hooked up to > it to light up a LED when donfiguration is done. > Transistors normally fall within my definition of 'buffer' :) Unless a hypothetical assembly house stuffed, say, a 1.2 ohm (1R2) where a one Kohm (102) NPN base resistor was supposed to go, lighting the DONE LED just fine but clamping the DONE voltage seen at the FPGA pin to one VBE drop such that the FPGA thinks DONE never went high. > > The thing is that I'm using configuration via SPI flash on > this board. I was planning to use indirect SPI programming > for initial flashing, but it doesn't work. iMPACT downloads > the JTAG->SPI-core-bitfile and then just quits with > "Programming failed", without giving any more detail. > IIRC I'd get a 'Programming Failed' error box after the 'downloading core' stage was reported in the 10.1 log window, if DONE didn't go high on the board. Not sure it'll help any, but here's another post of SPI related stuff from previous application note trawls: http://groups.google.com/group/comp.arch.fpga/msg/797303edfd4e7cac > > I suspect this is because the loading of the JTAG->SPI-core > fails because of the issue I'm having on this board. If the > bitfile shipped with iMPACT wasn't created with the DONE_cyle:6 > setting, it won't work on this board. > <snip> > > But of course I can't change it for the JTAG->SPI bitfile > shipped with iMPACT. > It is a major nuisance that Xilinx doesn't provide the JTAG-SPI core for iMPACT in either source or black-box synthesizable form. This forces customers to reinvent the indirect SPI FLASH wheel. If you ever need to do this, I'd suggest starting with either the Ken Chapman Picoblaze flash example (S3E) or the Avnet V5 SPI flash eval board example, which demonstrates the V5 logic needed to do user access to the internal configuration logic. Also of note, command line 10.1 PROMGEN has an undocumented-in- the-manuals " -spi " option that will let you generate an .mcs file for SPI proms with the proper bit order. This is quite helpful, for instance, when iMPACT 10.1 crashes and burns each time you try to define a multiboot, multi-FPGA daisy chain SPI PROM from within the iMPACT GUI. Brian______________________________
ghelbig schrieb: > FWIW: I spent 3 days debugging an isse (see: "XST is driving me > crazy" in this usenet group) that was resolved by adding one more > clock to the startup stream. > > In my configuration, done would go high and all of the combitorial > logic would word, but none of the sequential logic would work. > > One more (extra) CCLK, and everythig went working. I know about THAT issue, but I had problems programming via iMPACT. The thing is that I have no influence on how many CCLK cycles iMPACT generates. It should be smart enough to know how many are needed but obviously is not. The only thing that helped was changing the DONE_cycle-setting, which is something I've never had to touch before, hence it took me awhile to get there... cu, Sean -- Replace "MONTH" with the three-letter abbreviation of the current month and the two-digit code for the current year (simple, eh?).______________________________
Brian Davis wrote: > Unless a hypothetical assembly house stuffed, say, a 1.2 ohm > (1R2) where a one Kohm (102) NPN base resistor was supposed > to go, lighting the DONE LED just fine but clamping the DONE > voltage seen at the FPGA pin to one VBE drop such that the > FPGA thinks DONE never went high. Ha, THAT was it! Thank you, you made my day! Putting in the right value fixes the issue: Bit-files load without the DONE_cycle-setting, plus indirect SPI-programming works now. The only question that remains is: why doesn't iMPACT give a "DONE did not go high"-message? If it did, I'd probably gotten there sooner. And another question is: what else did the assembly house mess up on this board? Lot of 0402 bird seed on this one, no way to tell by looking at it... But at least all supply voltages are correct and so on. > It is a major nuisance that Xilinx doesn't provide the JTAG-SPI > core for iMPACT in either source or black-box synthesizable form. Yep. Antti did post his version of such a core in the Xilinx user forums, though: http://tinyurl.com/yjtharz This is a start as well. > This forces customers to reinvent the indirect SPI FLASH wheel. > > If you ever need to do this, I'd suggest starting with either the > Ken Chapman Picoblaze flash example (S3E) or the Avnet V5 SPI > flash eval board example, which demonstrates the V5 logic needed > to do user access to the internal configuration logic. Fortunately, in the "production" release it'll be simpler. A host PC will send SPI-commands which will just be passed through the FPGA basically. The indirect programming bit is just something I wanted to try since I've never used it before and was a bit puzzled when it didn't work. BTW, Xilinx' xapp1020 can come in handy, too: http://tinyurl.com/y955nom > Also of note, command line 10.1 PROMGEN has an undocumented-in- > the-manuals " -spi " option that will let you generate an .mcs > file for SPI proms with the proper bit order. Good to know. Did I mention the iMPACT GUI sucks? :) Thanks for all the excellent pointers! Learned quite a bit from this. -- Replace "MONTH" with the three-letter abbreviation of the current month and the two-digit code for the current year (simple, eh?).
<snip> >And another question is: what else did the assembly house mess up on >this board? Lot of 0402 bird seed on this one, no way to tell by looking >at it... But at least all supply voltages are correct and so on. <snip> This reminded me of an article I saw in Circuit Cellar on Smart Tweezers (http://www.smarttweezers.com) which might help you out. I expect there may be some problems in circuit with parallel paths though, I think it is more meant for identifying mystery components in isolation. Peter Van Epp
On Feb 11, 2:50=A0pm, van...@sfu.ca (Peter Van Epp) wrote: > <snip>>And another question is: what else did the assembly house mess up = on > >this board? Lot of 0402 bird seed on this one, no way to tell by looking > >at it... But at least all supply voltages are correct and so on. > > <snip> > > =A0 =A0 =A0 =A0 This reminded me of an article I saw in Circuit Cellar on= Smart Tweezers > (http://www.smarttweezers.com) which might help you out. I expect there m= ay > be some problems in circuit with parallel paths though, I think it is mor= e > meant for identifying mystery components in isolation. > > Peter Van Epp We've got a set of these in our production area here, which is also the test and rework area (small company). You can often get information in-circuit, especially in cases like this where you might see a much lower impedance than you were expecting. They're also great for comparing two boards when one doesn't work, since whatever you measure on the good board (R L or C) is just a relative reference point rather than the presumed component value. Regards, Gabor
Sean Durkin wrote: > >> <snip> clamping the DONE voltage seen at the FPGA pin to one >> VBE drop such that the FPGA thinks DONE never went high. > > Ha, THAT was it! Thank you, you made my day! Putting in the > right value fixes the issue: Bit-files load without the > DONE_cycle-setting, plus indirect SPI-programming works now. > Great! I hadn't seen that exact problem before, but the DONE LED circuit found on many Xilinx/Digilent boards made me think of it: : : !!! Don't ever do this !!! : Evil circuit clamps DONE high level to the LED's Vf : : DONE >---o---/\/\---> VCC : | : | : v : - LED : | : | : GND Given that most Xilinx FPGAs have a Vih minimum threshold on the DONE pin of 2.0 V (LVTTL, LVCMOS33) or 1.7 V (LVCMOS25), it gives me the heebie-jeebies to see a circuit like that clamping DONE to the LED Vf - depending upon the exact LED, Vf could easily be down in the 1.5 V to 1.7 V range. > > The only question that remains is: why doesn't iMPACT give > a "DONE did not go high"-message? If it did, I'd probably > gotten there sooner. > There are two DONE related bits in the V5 status register, an internal "I-have-released-done" signal and then the actual DONE pin state; I'd guess that iMPACT is reading the former. The FPGA startup state machine uses the external signal seen on the DONE pin, so the FPGA will stall the startup sequence with your accidental Vbe clamp on DONE. It would be interesting to compare the before and after board-resistor-change state of the status register [Debug->Read Device Status], post JTAG download attempt. There are other helpful bits in that status register for troubleshooting exactly where the FPGA got stuck, here's a few: " " STARTUP_STATE [20:18] CFG startup state machine [ NOT BINARY ENCODED!!!] " DONE [14] Value on DONE pin " RELEASE_DONE [13] Value of internal DONE signal " EOS [4] End of Startup signal from Startup Block " from UG191 v3.8, V5 FPGA Configuration guide, page 120: http://www.xilinx.com/support/documentation/user_guides/ug191.pdf > >Antti did post his version of such a core in the Xilinx user >forums, though: > >http://tinyurl.com/yjtharz > Thanks, I hadn't seen that one before. Brian______________________________
Gabor <g...@alacron.com> writes: >On Feb 11, 2:50=A0pm, van...@sfu.ca (Peter Van Epp) wrote: >> <snip>>And another question is: what else did the assembly house mess up = >on >> >this board? Lot of 0402 bird seed on this one, no way to tell by looking >> >at it... But at least all supply voltages are correct and so on. >> >> <snip> >> >> =A0 =A0 =A0 =A0 This reminded me of an article I saw in Circuit Cellar on= > Smart Tweezers >> (http://www.smarttweezers.com) which might help you out. I expect there m= >ay >> be some problems in circuit with parallel paths though, I think it is mor= >e >> meant for identifying mystery components in isolation. >> >> Peter Van Epp >We've got a set of these in our production area here, which is also >the test and rework area (small company). You can often get >information >in-circuit, especially in cases like this where you might see a much >lower >impedance than you were expecting. They're also great for comparing >two boards when one doesn't work, since whatever you measure on the >good board (R L or C) is just a relative reference point rather than >the presumed component value. >Regards, >Gabor Even better, someone that has actually used one (which I haven't :-)). Peter Van Epp