Hi, I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new prototype but I'm getting some weird results back while programming it. I hope somebody with more experience can help me out. The fpga is the 2nd device in a chain of 3 devices, of which the third a XC95144XL is which can be programmed succesfully. I assume therefore that there are acceptable noise levels on the bus and bus speed (currently at about ~1.2MHz - depends a bit on how fast the programmer can handle incoming data but not faster than that) is Ok. When fetching the status register before any programming, I get; mask; 0x01FFFFFFFE 34 bits; 0x0260000000 The fpga being the second device, it actually clocks out 0x30000000 (and the first device seems to add a 1?) After programming I get; 34 bits; 0x0262000000 So it actually clocks out 0x31000000 So apparently (if I follow xapp452) the DCM are locked and DCI is matched (even though I haven't flashed in anything yet - the PROM onboard doesn't contain valid data - and don't have any DCI pins configured as actual DCI) and after a programming attempt GHIGH_B is deasserted, and there are _no_ CRC errors reported here. It doesn't, however, start up. DONE pin stays low (isn't connected to anything) as well as GTS_CFG and GWE etc, basically, the startup is stalled for some reason. So I decided to pick up the multimeter and start measuring; DONE stays low PROG_B stays high INIT_B goes high, than goes low again after programming This seems to indicate a CRC error after all? I've tried setting the BitGen option for unused IOB pins to pull-up (I'm not using the DONE pin as IO) but that still made DONE go low. So right now I have no idea how to continue in figuring out what the problem is or how to get the fpga working. I haven't tried disabling the CRC check completely yet. Any tips, hints, suggestions are very welcome. Cheers, Mike http://projectvga.org
Possible CRC error on XC3S400 - now what?
Started by ●February 4, 2008
Reply by ●February 4, 20082008-02-04
Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:>I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new >prototype but I'm getting some weird results back while programming it. >I hope somebody with more experience can help me out.>The fpga is the 2nd device in a chain of 3 devices, of which the third a >XC95144XL is which can be programmed succesfully. I assume therefore >that there are acceptable noise levels on the bus and bus speed >(currently at about ~1.2MHz - depends a bit on how fast the programmer >can handle incoming data but not faster than that) is Ok.* Check power for any dips or transients. * Connect directly with a parallell port jtag adapter. Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf (And only try the USB approch once it confirmed to work) * Lower the clocking frequency, try 50 kHz. * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B, CCLK, etc) * You could connect pins to the fpga DIN etc.. back to your PC to verify your fpga actually get the data you expect.
Reply by ●February 5, 20082008-02-05
Hi,> I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new > prototype but I'm getting some weird results back while programming it. > I hope somebody with more experience can help me out.Try to switch the modepins to JTAG only. Do you use a PC3 clone? There seems to be some problems in certain impact versions with PC3 and S3 if the chip is not in JTAG only mode. best regards Thorsten Trenz -- www.trenz-electronic.de
Reply by ●February 5, 20082008-02-05
Hi, Sky465nm@trline5.org wrote:> Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote: > >>I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new >>prototype but I'm getting some weird results back while programming it. >>I hope somebody with more experience can help me out. > > >>The fpga is the 2nd device in a chain of 3 devices, of which the third a >>XC95144XL is which can be programmed succesfully. I assume therefore >>that there are acceptable noise levels on the bus and bus speed >>(currently at about ~1.2MHz - depends a bit on how fast the programmer >>can handle incoming data but not faster than that) is Ok. > > > * Check power for any dips or transients.My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't really know what's causing this (it's just below the minimum required, isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V.> * Connect directly with a parallell port jtag adapter. > Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf > > (And only try the USB approch once it confirmed to work)The thing is, the programmer is embedded on the board itself so connecting a different programmer would require me to start cutting pcb traces.> * Lower the clocking frequency, try 50 kHz.Didn't seem to help. Afaik there's no minimum clock so I even tried it at ~100Hz (which takes forever btw, in case you never tried it) but it still failed.> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B, > CCLK, etc)M[2:0] are all tied to ground, and changing this would again require some force so I'd rather not. This shouldn't matter afaik, since you can always program using JTAG anyway, right? Likewise, when configuring using JTAG it doesn't matter what CCLK is, does it? I mentioned the state of INIT_B, PROG_B and DONE earlier.> * You could connect pins to the fpga DIN etc.. back to your PC to verify your > fpga actually get the data you expect. >Would data pushed in through JTAG appear on DIN? I could write something that checks TDO but I'm told the spartan spits out zeroes or other nonsense when I'm shifting data in. Thorsten Trenz wrote: > Hi, > > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There > seems to be some problems in certain impact versions with PC3 and S3 if > the chip is not in JTAG only mode. The programmer is an FTDI FT2232 using an homebrew XSVF parser. I believe I've got all the bugs worked out of the software since programming the CPLD goes without a problem. Cheers, Mike http://projectvga.org
Reply by ●February 5, 20082008-02-05
On Feb 5, 9:56 am, Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:> Hi, > > > > Sky46...@trline5.org wrote: > > Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote: > > >>I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new > >>prototype but I'm getting some weird results back while programming it. > >>I hope somebody with more experience can help me out. > > >>The fpga is the 2nd device in a chain of 3 devices, of which the third a > >>XC95144XL is which can be programmed succesfully. I assume therefore > >>that there are acceptable noise levels on the bus and bus speed > >>(currently at about ~1.2MHz - depends a bit on how fast the programmer > >>can handle incoming data but not faster than that) is Ok. > > > * Check power for any dips or transients. > > My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't > really know what's causing this (it's just below the minimum required, > isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V. > > > * Connect directly with a parallell port jtag adapter. > > Like this:http://www.xilinx.com/support/programr/jtag_cable.pdf > > > (And only try the USB approch once it confirmed to work) > > The thing is, the programmer is embedded on the board itself so > connecting a different programmer would require me to start cutting pcb > traces. > > > * Lower the clocking frequency, try 50 kHz. > > Didn't seem to help. Afaik there's no minimum clock so I even tried it > at ~100Hz (which takes forever btw, in case you never tried it) but it > still failed. > > > * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B, > > CCLK, etc) > > M[2:0] are all tied to ground, and changing this would again require > some force so I'd rather not. This shouldn't matter afaik, since you can > always program using JTAG anyway, right? Likewise, when configuring > using JTAG it doesn't matter what CCLK is, does it? I mentioned the > state of INIT_B, PROG_B and DONE earlier. > > > * You could connect pins to the fpga DIN etc.. back to your PC to verify your > > fpga actually get the data you expect. > > Would data pushed in through JTAG appear on DIN? I could write something > that checks TDO but I'm told the spartan spits out zeroes or other > nonsense when I'm shifting data in. > > Thorsten Trenz wrote: > > > Hi, > > > > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There > > seems to be some problems in certain impact versions with PC3 and S3 if > > the chip is not in JTAG only mode. > > The programmer is an FTDI FT2232 using an homebrew XSVF parser. I > believe I've got all the bugs worked out of the software since > programming the CPLD goes without a problem. > > Cheers, > > Mikehttp://projectvga.orgYou didn't say what the first device in the chain was. There are known issues when placing a PlatformFlash (XCF02S for instance) in front of a Spartan device wired up for master serial configuration mode. Do you have a pullup on the DONE pin? If not have you checked the "Drive Done pin high" option in bitgen? Are you providing enough clocks at the end of the bitstream load to start up the device (again look at where DONE is supposed to go high in the bitgen options)? That's all I can think of. By the way if you are using an XFCxxS device in front of your FPGA, try erasing it to see if that helps the JTAG load. Regards, Gabor
Reply by ●February 5, 20082008-02-05
Gabor wrote:> On Feb 5, 9:56 am, Michael Meeuwisse > <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> > wrote: > >>Hi, >> >> >> >>Sky46...@trline5.org wrote: >> >>>Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote: >> >>>>I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new >>>>prototype but I'm getting some weird results back while programming it. >>>>I hope somebody with more experience can help me out. >> >>>>The fpga is the 2nd device in a chain of 3 devices, of which the third a >>>>XC95144XL is which can be programmed succesfully. I assume therefore >>>>that there are acceptable noise levels on the bus and bus speed >>>>(currently at about ~1.2MHz - depends a bit on how fast the programmer >>>>can handle incoming data but not faster than that) is Ok. >> >>> * Check power for any dips or transients. >> >>My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't >>really know what's causing this (it's just below the minimum required, >>isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V. >> >> >>> * Connect directly with a parallell port jtag adapter. >>> Like this:http://www.xilinx.com/support/programr/jtag_cable.pdf >> >>> (And only try the USB approch once it confirmed to work) >> >>The thing is, the programmer is embedded on the board itself so >>connecting a different programmer would require me to start cutting pcb >>traces. >> >> >>> * Lower the clocking frequency, try 50 kHz. >> >>Didn't seem to help. Afaik there's no minimum clock so I even tried it >>at ~100Hz (which takes forever btw, in case you never tried it) but it >>still failed. >> >> >>> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B, >>> CCLK, etc) >> >>M[2:0] are all tied to ground, and changing this would again require >>some force so I'd rather not. This shouldn't matter afaik, since you can >>always program using JTAG anyway, right? Likewise, when configuring >>using JTAG it doesn't matter what CCLK is, does it? I mentioned the >>state of INIT_B, PROG_B and DONE earlier. >> >> >>> * You could connect pins to the fpga DIN etc.. back to your PC to verify your >>> fpga actually get the data you expect. >> >>Would data pushed in through JTAG appear on DIN? I could write something >>that checks TDO but I'm told the spartan spits out zeroes or other >>nonsense when I'm shifting data in. >> >>Thorsten Trenz wrote: >> >> > Hi, >> > >> > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There >> > seems to be some problems in certain impact versions with PC3 and S3 if >> > the chip is not in JTAG only mode. >> >>The programmer is an FTDI FT2232 using an homebrew XSVF parser. I >>believe I've got all the bugs worked out of the software since >>programming the CPLD goes without a problem. >> >>Cheers, >> >>Mikehttp://projectvga.org > > > You didn't say what the first device in the chain was. There are > known > issues when placing a PlatformFlash (XCF02S for instance) in front of > a Spartan device wired up for master serial configuration mode. >Yeah sorry, it's a XCF04S. I've got some other issues with that one however, it seems that is has some dead banks which is why I'm trying to program the fpga directly in the first place. As far as I can tell these two problems are unrelated.> Do you have a pullup on the DONE pin? If not have you checked the > "Drive Done pin high" option in bitgen? >No, no external pull up. I've set "Configuration pin done" to Float and checked "Drive done pin high" as suggested by table 2.6 of ug332.> Are you providing enough clocks at the end of the bitstream load to > start up the device (again look at where DONE is supposed to go high > in the bitgen options)? >I think so, I've tried programming the CPLD after I attempted to program the FPGA which should provide plenty of clock cycles, but it didn't change anything.> That's all I can think of. > > By the way if you are using an XFCxxS device in front of your FPGA, > try erasing it to see if that helps the JTAG load. > > Regards, > GaborAs it turns out, the LM1086-2.5 needs a minimum of 4V and I'm only giving it 3.3V so that might be cause of some of the trouble - it certainly explains why my VccAux is only ~2.3V. I'm going to fix that now and hopefully it'll help. Cheers, Mike http://projectvga.org
Reply by ●February 5, 20082008-02-05
>> * Check power for any dips or transients.>My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't >really know what's causing this (it's just below the minimum required, >isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V.XC3S400-PQ208 http://direct.xilinx.com/bvdocs/publications/ds099.pdf (t31 p58/208) Min Nom Max Vccint 1.140 1.200 1.260 Vccaux 2.375 2.500 2.625 Vcco 1.140 - 3.450 LM1086-2.5 http://users.ece.utexas.edu/~valvano/Datasheets/LM1086.pdf Min Typ Max Vout 2.450 2.50 2.525 (Vin=4-18V Ifull) Current limit: Min=1.5A Typ=2.7A at Vin=8V Your Vcco regulator uses "3V3" for Vin with a 10uF capacitor on each input and output. "3V3" comes from S53, S39, S33, S27, S21, C25, C31, C36, C41, C43, C54 on the PCI connector (CON1). (Schematic: http://wacco.mveas.com/img/schema1d.png) So the Vin of the 2.5V regulator is not enough. Also there's the issue of voltage ramp time upon startup. Vcco 2000 us Vccaux - us (no requirement) Vccint 500 us (p57 Table 29 Power voltage ramp time requirements) So you might need to check Vccint vs Vccaux. The Vccaux should be powered before Vccint, but it's not that sensitive (or?). (see p53) Check that your oscillator does have proper power. And outputs a correct waveform at the XC3S400 input (Bank5 GCLK2, P76). (LVTTL 0.8 - 2.0 swing + flanks)>> * Connect directly with a parallell port jtag adapter. >> Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf >> (And only try the USB approch once it confirmed to work)>The thing is, the programmer is embedded on the board itself so >connecting a different programmer would require me to start cutting pcb >traces.Measure the output of your onboard usb programmer that it does what you expect it to do. Ie feedback it's TDO to your parallell port. If this fails, try the cut traces approach and solder some wires so you can change programmer at will. Also use program directly via JTAG mode to start with, only when that works try eeprom. The first bitstream ("program") should be something simple like pulsing a LED. (604-00033G-ND IC FTDI2232L USB/SERIAL 48-LQFP) Scan chain (reverse order?): FTDI2232L - XC95144XL - XC3S400 - XCF01S - FTDI2232L>> * Lower the clocking frequency, try 50 kHz.>Didn't seem to help. Afaik there's no minimum clock so I even tried it >at ~100Hz (which takes forever btw, in case you never tried it) but it >still failed.Verify bitstream at TDI+TCK? {M0,M1,M2} = 3'b000 (ds099 p45 for mode table) So configuration mode is master serial. Thus CCLK+DIN is the ones that dictates programming. Setting M0=1, M1=0, M2=1 gives you jtag programming mode. Which might make life easier in the beginning. It's also the mode that is smoother to use when developing.>> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B, >> CCLK, etc)>M[2:0] are all tied to ground, and changing this would again require >some force so I'd rather not. This shouldn't matter afaik, since you can >always program using JTAG anyway, right? Likewise, when configuring >using JTAG it doesn't matter what CCLK is, does it? I mentioned the >state of INIT_B, PROG_B and DONE earlier.M[2:0] = 000 => Master serial mode according to datasheet ds099 page 45. So CCLK will matter. Btw, check if CCLK (2.5V) does output a proper waveform at the eeprom input (Pin3 CLK). And that eeprom output is correct at the fpga. Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V Signals: INIT_B Shall go high after memory is cleared. And shall not be tied low. PROG_B Goes high? DONE Goes high after configuration is complete. HSWAP_EN Is tied low in your schematic => Pullup resistors enabled on all pins not activly involved in the configuration process. Check that no pullup'ed pin interfere with the configuration process. (ds099 p101) You might use these to find out what's going on.>> * You could connect pins to the fpga DIN etc.. back to your PC to verify your >> fpga actually get the data you expect.>Would data pushed in through JTAG appear on DIN? I could write something >that checks TDO but I'm told the spartan spits out zeroes or other >nonsense when I'm shifting data in.My idea was to attach a wire directly to TDI/TDO + TCK back into an INPUT pin of the parallell port to verify data.>Thorsten Trenz wrote: > > Hi, > > > > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There > > seems to be some problems in certain impact versions with PC3 and S3 if > > the chip is not in JTAG only mode.>The programmer is an FTDI FT2232 using an homebrew XSVF parser. I >believe I've got all the bugs worked out of the software since >programming the CPLD goes without a problem.Verify board connections -> Power -> Clocks -> Other. I think also that if you try to program: Onboard USB -> XCF01S eeprom eeprom -> FPGA You add more steps that may fail. Also you could try to manually read if the contents of the XCF01S is what you expect.>it's a XCF04S. I've got some other issues with that one >however, it seems that is has some dead banks which is why I'm trying to >program the fpga directly in the first place. As far as I can tell these >two problems are unrelated.So you need to alter M[0:2] pins to 1-0-1 (ds099 p45). And according to table 26 (ds099 p45) you need at least an XCF02S. So schematic is contradictive.. :) Your schematic would be easier to follow if you added consistent chip identifications ie Ux XC3S400 etc.. Also soldering pads for debug fixes could be something to have in mind for later revisions. Assume failure ;)
Reply by ●February 5, 20082008-02-05
Sky465nm@trline5.org wrote:>>> * Check power for any dips or transients. > > >>My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't >>really know what's causing this (it's just below the minimum required, >>isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V. > > > XC3S400-PQ208 > http://direct.xilinx.com/bvdocs/publications/ds099.pdf (t31 p58/208) > Min Nom Max > Vccint 1.140 1.200 1.260 > Vccaux 2.375 2.500 2.625 > Vcco 1.140 - 3.450 > > LM1086-2.5 > http://users.ece.utexas.edu/~valvano/Datasheets/LM1086.pdf > Min Typ Max > Vout 2.450 2.50 2.525 (Vin=4-18V Ifull) > > Current limit: Min=1.5A Typ=2.7A at Vin=8V > > Your Vcco regulator uses "3V3" for Vin with a 10uF capacitor on each input > and output. > "3V3" comes from S53, S39, S33, S27, S21, C25, C31, C36, C41, C43, C54 on > the PCI connector (CON1). > (Schematic: http://wacco.mveas.com/img/schema1d.png) > > So the Vin of the 2.5V regulator is not enough. >Yep, I realised that too and got just back from uni where I've got better tools than here at home. The Vin is now tied to 5V and the output is a clean 2.50V. (Also, I fixed the second led on the CPLD but that's irrelevant for this discussion) Still can't program the fpga though.> Also there's the issue of voltage ramp time upon startup. > Vcco 2000 us > Vccaux - us (no requirement) > Vccint 500 us > (p57 Table 29 Power voltage ramp time requirements) > > So you might need to check Vccint vs Vccaux. The Vccaux should be powered > before Vccint, but it's not that sensitive (or?). (see p53) >Hmm, I checked the fpga and it's a revision E with the GQ fabrication process code so I guess I'm lucky and don't have to worry about any of this.> Check that your oscillator does have proper power. And outputs a correct > waveform at the XC3S400 input (Bank5 GCLK2, P76). > (LVTTL 0.8 - 2.0 swing + flanks) >This is where it gets annoying, I don't have anything to check out the waveform with. I'll have to drag everything to uni tomorrow if I want to see what's happening on such lines which is a much bigger effort than just taking the PCI card - I'll do it anyway, but still. It would be easier if I was able to program the fpga so I could fling a little counter-thing on it outputting it to the led.> >>> * Connect directly with a parallell port jtag adapter. >>> Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf >>> (And only try the USB approch once it confirmed to work) > > >>The thing is, the programmer is embedded on the board itself so >>connecting a different programmer would require me to start cutting pcb >>traces. > > > Measure the output of your onboard usb programmer that it does what you > expect it to do. Ie feedback it's TDO to your parallell port. > If this fails, try the cut traces approach and solder some wires so you can > change programmer at will. > > Also use program directly via JTAG mode to start with, only when that works > try eeprom. The first bitstream ("program") should be something simple like > pulsing a LED. >Right now the program is exactly (except for pinout of course) the same as the thing I flashed succesfully into the CPLD. It had the led tied to counter[25] where counter = counter + 1 on every posedge clk. I'm completely ignoring the eeprom at the moment.> (604-00033G-ND IC FTDI2232L USB/SERIAL 48-LQFP) > > Scan chain (reverse order?): > FTDI2232L - XC95144XL - XC3S400 - XCF01S - FTDI2232L > >It's FTDI tdi -> XCF04S -> XC3S400 -> XC95144XL -> FTDI tdo>>> * Lower the clocking frequency, try 50 kHz. > > >>Didn't seem to help. Afaik there's no minimum clock so I even tried it >>at ~100Hz (which takes forever btw, in case you never tried it) but it >>still failed. > > > Verify bitstream at TDI+TCK? >The CPLD verifies so I'm pretty sure it's not the programmer. I'll do a debug output though and check it by hand tonight.> {M0,M1,M2} = 3'b000 (ds099 p45 for mode table) > > So configuration mode is master serial. Thus CCLK+DIN is the ones that > dictates programming. Setting M0=1, M1=0, M2=1 gives you jtag programming > mode. Which might make life easier in the beginning. It's also the mode > that is smoother to use when developing. >All documentation seems to say that M[2:0] don't matter at all when you want to program using JTAG, say, the first line of the chapter "JTAG Configuration Mode" of ug332 (page 187). http://www.xilinx.com/support/documentation/user_guides/ug332.pdf> >>> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B, >>> CCLK, etc) > > >>M[2:0] are all tied to ground, and changing this would again require >>some force so I'd rather not. This shouldn't matter afaik, since you can >>always program using JTAG anyway, right? Likewise, when configuring >>using JTAG it doesn't matter what CCLK is, does it? I mentioned the >>state of INIT_B, PROG_B and DONE earlier. > > > M[2:0] = 000 => Master serial mode according to datasheet ds099 page 45. > So CCLK will matter. Btw, check if CCLK (2.5V) does output a proper waveform > at the eeprom input (Pin3 CLK). And that eeprom output is correct at the fpga. > > Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V >Sorry you lost me - is this a problem? I followed figure 4 of xapp453 to enable 3.3V powered programming; http://www.xilinx.com/support/documentation/application_notes/xapp453.pdf Rpar is R24 in case you can't find it in my (unfortunately somewhat confusing) schematic. The only changes I made is the DONE pin connection because I want to imitate the behavior of Figure 1 of xapp694, which makes it possible to use parts of the eeprom for user data. http://www.xilinx.com/support/documentation/application_notes/xapp694.pdf> Signals: > INIT_B Shall go high after memory is cleared. And shall not be tied low.Is low, goes high when programming starts, goes back to low after that> PROG_B Goes high?Always high> DONE Goes high after configuration is complete.Always low> HSWAP_EN Is tied low in your schematic => Pullup resistors enabled on all > pins not activly involved in the configuration process. > Check that no pullup'ed pin interfere with the configuration process. > (ds099 p101) >I wouldn't know which one besides the ones already mentioned. The only user IO pin that's connected to any of these is P102 (bank 4) which is tied to CCLK so I can clock out user data at a later point after configuration. A pull-up on CCLK shouldn't matter afaik.> You might use these to find out what's going on. > > >>> * You could connect pins to the fpga DIN etc.. back to your PC to verify your >>> fpga actually get the data you expect. > > >>Would data pushed in through JTAG appear on DIN? I could write something >>that checks TDO but I'm told the spartan spits out zeroes or other >>nonsense when I'm shifting data in. > > > My idea was to attach a wire directly to TDI/TDO + TCK back into an INPUT pin > of the parallell port to verify data. > >Hmm. Not sure if that's possible, I'd need at least a tool to sample the parallel port correctly. I'll check the data I'm sending to the FTDI first, maybe something odd is happening in there.>>Thorsten Trenz wrote: >> >>>Hi, >>> >>>Try to switch the modepins to JTAG only. Do you use a PC3 clone? There >>>seems to be some problems in certain impact versions with PC3 and S3 if >>>the chip is not in JTAG only mode. > > >>The programmer is an FTDI FT2232 using an homebrew XSVF parser. I >>believe I've got all the bugs worked out of the software since >>programming the CPLD goes without a problem. > > > Verify board connections -> Power -> Clocks -> Other. > > I think also that if you try to program: > Onboard USB -> XCF01S eeprom > eeprom -> FPGA > > You add more steps that may fail.That's why I'm not and didn't mention the eeprom at all at first ;)> Also you could try to manually read if the contents of the XCF01S is what > you expect. > > >>it's a XCF04S. I've got some other issues with that one >>however, it seems that is has some dead banks which is why I'm trying to >>program the fpga directly in the first place. As far as I can tell these >>two problems are unrelated. > > > So you need to alter M[0:2] pins to 1-0-1 (ds099 p45). > And according to table 26 (ds099 p45) you need at least an XCF02S. > So schematic is contradictive.. :) >Since I'm using an XCF04S I have twice the space I really need so I'm not sure why my schematic is contradictive here. :)> Your schematic would be easier to follow if you added consistent chip > identifications ie Ux XC3S400 etc.. > > Also soldering pads for debug fixes could be something to have in mind for > later revisions. Assume failure ;) >Yeah, that's the big lesson out of all this; use busses and name everything correctly. You're not the first to be confused by the schematic. Soldering pads is also a good one, I was stubborn enough not to add any, which is dumb. Thanks so far anyway :) Cheers, Mike http://projectvga.org
Reply by ●February 5, 20082008-02-05
On Feb 5, 3:04 pm, Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:> Sky46...@trline5.org wrote: > >>> * Check power for any dips or transients. > > >>My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't > >>really know what's causing this (it's just below the minimum required, > >>isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V. > > > XC3S400-PQ208 > > http://direct.xilinx.com/bvdocs/publications/ds099.pdf(t31 p58/208) > > Min Nom Max > > Vccint 1.140 1.200 1.260 > > Vccaux 2.375 2.500 2.625 > > Vcco 1.140 - 3.450 > > > LM1086-2.5 > > http://users.ece.utexas.edu/~valvano/Datasheets/LM1086.pdf > > Min Typ Max > > Vout 2.450 2.50 2.525 (Vin=4-18V Ifull) > > > Current limit: Min=1.5A Typ=2.7A at Vin=8V > > > Your Vcco regulator uses "3V3" for Vin with a 10uF capacitor on each input > > and output. > > "3V3" comes from S53, S39, S33, S27, S21, C25, C31, C36, C41, C43, C54 on > > the PCI connector (CON1). > > (Schematic:http://wacco.mveas.com/img/schema1d.png) > > > So the Vin of the 2.5V regulator is not enough. > > Yep, I realised that too and got just back from uni where I've got > better tools than here at home. The Vin is now tied to 5V and the output > is a clean 2.50V. (Also, I fixed the second led on the CPLD but that's > irrelevant for this discussion) > > Still can't program the fpga though. > > > Also there's the issue of voltage ramp time upon startup. > > Vcco 2000 us > > Vccaux - us (no requirement) > > Vccint 500 us > > (p57 Table 29 Power voltage ramp time requirements) > > > So you might need to check Vccint vs Vccaux. The Vccaux should be powered > > before Vccint, but it's not that sensitive (or?). (see p53) > > Hmm, I checked the fpga and it's a revision E with the GQ fabrication > process code so I guess I'm lucky and don't have to worry about any of this. > > > Check that your oscillator does have proper power. And outputs a correct > > waveform at the XC3S400 input (Bank5 GCLK2, P76). > > (LVTTL 0.8 - 2.0 swing + flanks) > > This is where it gets annoying, I don't have anything to check out the > waveform with. I'll have to drag everything to uni tomorrow if I want to > see what's happening on such lines which is a much bigger effort than > just taking the PCI card - I'll do it anyway, but still. It would be > easier if I was able to program the fpga so I could fling a little > counter-thing on it outputting it to the led. > > > > > > >>> * Connect directly with a parallell port jtag adapter. > >>> Like this:http://www.xilinx.com/support/programr/jtag_cable.pdf > >>> (And only try the USB approch once it confirmed to work) > > >>The thing is, the programmer is embedded on the board itself so > >>connecting a different programmer would require me to start cutting pcb > >>traces. > > > Measure the output of your onboard usb programmer that it does what you > > expect it to do. Ie feedback it's TDO to your parallell port. > > If this fails, try the cut traces approach and solder some wires so you can > > change programmer at will. > > > Also use program directly via JTAG mode to start with, only when that works > > try eeprom. The first bitstream ("program") should be something simple like > > pulsing a LED. > > Right now the program is exactly (except for pinout of course) the same > as the thing I flashed succesfully into the CPLD. It had the led tied to > counter[25] where counter = counter + 1 on every posedge clk. I'm > completely ignoring the eeprom at the moment. > > > (604-00033G-ND IC FTDI2232L USB/SERIAL 48-LQFP) > > > Scan chain (reverse order?): > > FTDI2232L - XC95144XL - XC3S400 - XCF01S - FTDI2232L > > It's FTDI tdi -> XCF04S -> XC3S400 -> XC95144XL -> FTDI tdo > > >>> * Lower the clocking frequency, try 50 kHz. > > >>Didn't seem to help. Afaik there's no minimum clock so I even tried it > >>at ~100Hz (which takes forever btw, in case you never tried it) but it > >>still failed. > > > Verify bitstream at TDI+TCK? > > The CPLD verifies so I'm pretty sure it's not the programmer. I'll do a > debug output though and check it by hand tonight. > > > {M0,M1,M2} = 3'b000 (ds099 p45 for mode table) > > > So configuration mode is master serial. Thus CCLK+DIN is the ones that > > dictates programming. Setting M0=1, M1=0, M2=1 gives you jtag programming > > mode. Which might make life easier in the beginning. It's also the mode > > that is smoother to use when developing. > > All documentation seems to say that M[2:0] don't matter at all when you > want to program using JTAG, say, the first line of the chapter "JTAG > Configuration Mode" of ug332 (page 187).http://www.xilinx.com/support/documentation/user_guides/ug332.pdf > > > > > > >>> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B, > >>> CCLK, etc) > > >>M[2:0] are all tied to ground, and changing this would again require > >>some force so I'd rather not. This shouldn't matter afaik, since you can > >>always program using JTAG anyway, right? Likewise, when configuring > >>using JTAG it doesn't matter what CCLK is, does it? I mentioned the > >>state of INIT_B, PROG_B and DONE earlier. > > > M[2:0] = 000 => Master serial mode according to datasheet ds099 page 45. > > So CCLK will matter. Btw, check if CCLK (2.5V) does output a proper waveform > > at the eeprom input (Pin3 CLK). And that eeprom output is correct at the fpga. > > > Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V > > Sorry you lost me - is this a problem? I followed figure 4 of xapp453 to > enable 3.3V powered programming;http://www.xilinx.com/support/documentation/application_notes/xapp453... > Rpar is R24 in case you can't find it in my (unfortunately somewhat > confusing) schematic. > > The only changes I made is the DONE pin connection because I want to > imitate the behavior of Figure 1 of xapp694, which makes it possible to > use parts of the eeprom for user data.http://www.xilinx.com/support/documentation/application_notes/xapp694... > > > Signals: > > INIT_B Shall go high after memory is cleared. And shall not be tied low. > > Is low, goes high when programming starts, goes back to low after that> PROG_B Goes high? > Always high > > DONE Goes high after configuration is complete. > Always low > > HSWAP_EN Is tied low in your schematic => Pullup resistors enabled on all > > pins not activly involved in the configuration process. > > Check that no pullup'ed pin interfere with the configuration process. > > (ds099 p101) > > I wouldn't know which one besides the ones already mentioned. The only > user IO pin that's connected to any of these is P102 (bank 4) which is > tied to CCLK so I can clock out user data at a later point after > configuration. A pull-up on CCLK shouldn't matter afaik. > > > > > You might use these to find out what's going on. > > >>> * You could connect pins to the fpga DIN etc.. back to your PC to verify your > >>> fpga actually get the data you expect. > > >>Would data pushed in through JTAG appear on DIN? I could write something > >>that checks TDO but I'm told the spartan spits out zeroes or other > >>nonsense when I'm shifting data in. > > > My idea was to attach a wire directly to TDI/TDO + TCK back into an INPUT pin > > of the parallell port to verify data. > > Hmm. Not sure if that's possible, I'd need at least a tool to sample the > parallel port correctly. I'll check the data I'm sending to the FTDI > first, maybe something odd is happening in there. > > > > >>Thorsten Trenz wrote: > > >>>Hi, > > >>>Try to switch the modepins to JTAG only. Do you use a PC3 clone? There > >>>seems to be some problems in certain impact versions with PC3 and S3 if > >>>the chip is not in JTAG only mode. > > >>The programmer is an FTDI FT2232 using an homebrew XSVF parser. I > >>believe I've got all the bugs worked out of the software since > >>programming the CPLD goes without a problem. > > > Verify board connections -> Power -> Clocks -> Other. > > > I think also that if you try to program: > > Onboard USB -> XCF01S eeprom > > eeprom -> FPGA > > > You add more steps that may fail. > > That's why I'm not and didn't mention the eeprom at all at first ;) > > > Also you could try to manually read if the contents of the XCF01S is what > > you expect. > > >>it's a XCF04S. I've got some other issues with that one > >>however, it seems that is has some dead banks which is why I'm trying to > >>program the fpga directly in the first place. As far as I can tell these > >>two problems are unrelated. > > > So you need to alter M[0:2] pins to 1-0-1 (ds099 p45). > > And according to table 26 (ds099 p45) you need at least an XCF02S. > > So schematic is contradictive.. :) > > Since I'm using an XCF04S I have twice the space I really need so I'm > not sure why my schematic is contradictive here. :) > > > Your schematic would be easier to follow if you added consistent chip > > identifications ie Ux XC3S400 etc.. > > > Also soldering pads for debug fixes could be something to have in mind for > > later revisions. Assume failure ;) > > Yeah, that's the big lesson out of all this; use busses and name > everything correctly. You're not the first to be confused by the > schematic. Soldering pads is also a good one, I was stubborn enough not > to add any, which is dumb. > > Thanks so far anyway :) > > Cheers, > > Mikehttp://projectvga.orgI would still recommend trying to get the XCF04S out of the loop. As I mentioned before, there are known issues with the serial data stream from the PlatformFlash interfering with JTAG programming. Perhaps you could unsolder the part and just wire from its TDI to TDO pin. You may need to generate new SVF files for the shorter chain, but I think it's worth a try since everything else has failed... Regards, Gabor
Reply by ●February 5, 20082008-02-05
Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:>Still can't program the fpga though.>> Check that your oscillator does have proper power. And outputs a correct >> waveform at the XC3S400 input (Bank5 GCLK2, P76). >> (LVTTL 0.8 - 2.0 swing + flanks)>This is where it gets annoying, I don't have anything to check out the >waveform with. I'll have to drag everything to uni tomorrow if I want to >see what's happening on such lines which is a much bigger effort than >just taking the PCI card - I'll do it anyway, but still. It would be >easier if I was able to program the fpga so I could fling a little >counter-thing on it outputting it to the led.You could also use a "divide by N" approach so you can get an estimate that the oscillator work properly.>> Also use program directly via JTAG mode to start with, only when that works >> try eeprom. The first bitstream ("program") should be something simple like >> pulsing a LED.>Right now the program is exactly (except for pinout of course) the same >as the thing I flashed succesfully into the CPLD. It had the led tied to >counter[25] where counter = counter + 1 on every posedge clk. I'm >completely ignoring the eeprom at the moment.You could try this for an arbitrary divide by N: if( count < 10000000 ) count = count + 1; else begin count = 0; led_buffer = led_buffer ^ 1; end>It's FTDI tdi -> XCF04S -> XC3S400 -> XC95144XL -> FTDI tdoAll TDO/TDIs with all outputs wired to inputs ..?>All documentation seems to say that M[2:0] don't matter at all when you >want to program using JTAG, say, the first line of the chapter "JTAG >Configuration Mode" of ug332 (page 187). >http://www.xilinx.com/support/documentation/user_guides/ug332.pdf"Spartan"-3 Generation FPGAs have a dedicated four-wire IEEE 1149.1/1532 JTAG port that is always available any time the FPGA is powered and regardless of the mode pin settings. However, when the FPGA mode pins are set for JTAG mode (M[2:0] = <1:0:1>), the FPGA waits to be configured via the JTAG port after a power-on event or after PROG_B is pulsed Low." (ug332 p187) The JTAG *interface* is available at all times. But the FPGA will only be configured by JTAG if the mode pins are M[2:0] = 101. (An exception might by with JSTART instruction, but I'm not sure).>> Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V>Sorry you lost me - is this a problem? I followed figure 4 of xapp453 to >enable 3.3V powered programming; >http://www.xilinx.com/support/documentation/application_notes/xapp453.pdf >Rpar is R24 in case you can't find it in my (unfortunately somewhat >confusing) schematic.I might be wrong on this, but CCLK ought to be LVCMOS25 and the XCF04S ought to be LVTTL. Thus voltage levels might mismatch if you'r unlucky. LVCMOS25 Vil=0.7 Vih=1.7 LVTTL Vil=0.8 Vih=2.0 (ds099 p61)>I wouldn't know which one besides the ones already mentioned. The only >user IO pin that's connected to any of these is P102 (bank 4) which is >tied to CCLK so I can clock out user data at a later point after >configuration. A pull-up on CCLK shouldn't matter afaik.You have also set HSWAP_EN to low. This might affect.>> My idea was to attach a wire directly to TDI/TDO + TCK back into an >> INPUT pin of the parallell port to verify data. >> >Hmm. Not sure if that's possible, I'd need at least a tool to sample the >parallel port correctly. I'll check the data I'm sending to the FTDI >first, maybe something odd is happening in there.Ohwell.. it's so easier on the unix side of things ;) But there are free .dll files on the internet that will make it work on win32.>That's why I'm not and didn't mention the eeprom at all at first ;)It's still in the scanchain ;), and in engineering the devil is in the details.>Since I'm using an XCF04S I have twice the space I really need so I'm >not sure why my schematic is contradictive here. :)The schematic have more than one designation for the same chip ;)
