Possible CRC error on XC3S400 - now what?

Michael Meeuwisse prototype but I'm getting some weird results back while programming it.

• Check power for any dips or transients.

• Connect directly with a parallell port jtag adapter. Like this:
  formatting link

(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.

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.

best regards Thorsten Trenz

--

your

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.

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

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.

The thing is, the programmer is embedded on the board itself so connecting a different programmer would require me to start cutting pcb traces.

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.

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.

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, >

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

wrote:

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.

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.

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.

As 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

XC3S400-PQ208

(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

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:

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)

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

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.

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.

My idea was to attach a wire directly to TDI/TDO + TCK back into an INPUT pin of the parallell port to verify data.

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.

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 ;)

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.

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.

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.

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.

It's FTDI tdi -> XCF04S -> XC3S400 -> XC95144XL -> FTDI tdo

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.

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).

Sorry you lost me - is this a problem? I followed figure 4 of xapp453 to enable 3.3V powered programming;

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.

Is low, goes high when programming starts, goes back to low after that

Always high

Always low

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.

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.

That's why I'm not and didn't mention the eeprom at all at first ;)

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. :)

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

On Feb 5, 3:04 pm, Michael Meeuwisse >>really know what's causing this (it's just below the minimum required,

187).

fpga.

programming;

data.http://www.xilinx.com/support/documentation/application_notes/xapp694...

Goes high?

process.

your

I 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

Michael Meeuwisse

You could also use a "divide by N" approach so you can get an estimate that the oscillator work properly.

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

All TDO/TDIs with all outputs wired to inputs ..?

"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] = ), 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).

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)

You have also set HSWAP_EN to low. This might affect.

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.

It's still in the scanchain ;), and in engineering the devil is in the details.

The schematic have more than one designation for the same chip ;)

I'll try it the moment I can program it ;)

I keep on arguing that it shouldn't matter, but to be absolutely on the safe side I'll make it possible tomorrow to set M2 and M0 to 2.5V. I really hope I'm wrong and changing this makes the problems go away.

Good point, it seems the XCF04S wants at least 2.0V according to ds123 when in 3.3V operation. This might be a problem if the fpga can't fully pull CCLK up to 2.5V. I'll have to check tomorrow.

It only seems to affect other IO pins not used during configuration and when tied low it enables the pull-ups. So only P102 is interesting here, but shouldn't cause problems. Again, I'll have to see tomorrow what CCLK is actually doing.

Har har :) I'll see what I can do. I haven't gotten to checking the FTDI output yet.

I've been looking at this schematic for a few months now and it's the first time I'm noticing it. X__x I'll change it ASAP.

Cheers,

Mike

Gabor schrieb:

Regards Falk

I checked the datasheet again, and you'r in the clear because: Output of LVCMOS25: Vol=0.4 Voh=Vcco-0.4 => Voh=2.1 (ds099 p62)

Input of LVTTL: Vil=0.8 Vih=2.0 Input of LVCMOS33: Vil=0.8 Vih=2.0

But with a 0.1V margin by definition! So good signal is a must.

Btw, I'm going to check if JTAG configuration works in non-jtag mode. Might be useful to know.

Hi,

Maybe, but our experience shows, that this is not always true. We had a board, which programmed fine with HW-USB, but failed in a similar way like yours with PC3. Choosing JTAG only solved the problem.

best regards Thorsten Trenz

--

There have been a number of issues over the years with JTAG configuration and mode select lines in various PROM/FPGA families; common symptoms are failed JTAG configuration, failed FPGA startup, failed DCM startup, etc.

Sometimes these have been patched in Impact, sometimes with a die revision of the PROM or FPGA.

For Spartan-3, try these:

AR #22255 - Spartan-3 Configuration - JTAG configuration completes successfully, but the device is not fully operational or a verify fails

AR #9013 - Spartan-3/-E/-A - JTAG configuration might fail when the PROM is loaded with data different from the bit file

Other possibly useful things :

AR #20047 - Spartan-3/-3E/-3A Configuration - The DONE pin goes High,but the device does not start up (I/Os are inactive/3-stated)

AR #11778 - Virtex/-E/-II/-II Pro, Spartan-II/-IIE/-3 - Device configures correctly after PROG is pulsed, but DLL/DCM/DCI does not function correctly when reconfigured

AR #24862 - PROM-XCF00P - When playing an SVF file to the XCF00P device, pulsing PROG after file completion does not cause a configuration

AR #16829 - Virtex and Spartan FPGAs - How does the JTAG JPROGRAM instruction work?

AR #14444 - XC18V00/XC1700/XCFxx - PROM frozen after the power cycling test; configuration fails after power-on reset/initial power up. What are the requirements for power cycling XC1700/XC18V00/XCFxx PROM?

AR #4219 - 9.1i BitGen - Why does Virtex not pass data to DOUT? What is the purpose of the "-g DebugBitstream" option? How does a "debug bitstream" differ from a normal bitstream?

have fun, Brian

The only scope available was a 20MHz one (the clock should be running at

50) which didn't help. I'm seeing a DC voltage ~1.10V and AC voltage of ~2.3V on my (rather embarrassingly cheap) multimeter which makes me believe there's a clock running on that pin.

Well I'll be damned. It scared the hell out of me to unsolder a few of the fpga pins but I can now select between mode 101 (JTAG) and 000 (Master Serial) with a simple pin header. This results in a status register (before programming) of 0x30B00000 and 0x31B00000 or in other words;

0011 0001 1011 - no CRC error, DCM locks, DCI Matches, GHIGH_B deasserted, Mode 101 JTAG, INIT pin high.

I especially like the last one, if I measure it on the print it is indeed still high after programming - afaik this means that the chip is programmed correctly without any CRC errors. The values of the configuration pins are;

INIT_B: 3.3V (high) PROG_B: 2.5V (high) DONE: 0V (low)

So why isn't it starting up after that? I've tried doing a runtest (go to RTI state, output a 1000 clockticks) directly after programming and the startup clock is set to JTAG in ISE. Didn't seem to help, so suggestions are once again welcome.

Cheers,

Mike

I think DC voltage is the right one considering it's pulsed signal and that the frequency is way above what the multimeter can detect. Btw, Average of LVTTL threesholds 0.8 and 2.0 is 1.4V :)

20 MHz scope might be doable. Select the fastest timebase and enable 10x timebase. Adjust for higher intensity. And you should see a *tiny* weak signal. Probes matter too ofcourse ;)

If you don't have money/equipment then you got to use your mind+time instead ;)

Shouldn't INIT_B be pull-up to 2.5V ? (R22 68R) Though the XCF04S eeprom might have another opinion on this :)

My suggestion is program that blinks a led (P77,P78) with help of the

50 MHz oscillator (P76).

According to your schematic:

You haven't wired anything to the 'DONE' pin (P103).

In ds099.pdf p103: "A Low-to-High output transition on this bidirectional pin signals the end of the configuration process. The FPGA produces a Low-to-High transition on this pin to indicate that the configuration process is complete. The DriveDone bitstream generation option defines whether this pin functions as a totem-pole output that actively drives High or as an open-drain output. An open-drain output requires a pull-up resistor to produce a High logic level."

So IF you have defined DONE as TOTEM-pole, you must NOT attach a PULL-up. If you have defined DONE as OPEN-drain, you must attach a PULL-up to 2.5V.

ds099.pdf p47 have an illustration on this.

Example .ut file: -g CclkPin:PULLUP -g TdoPin:PULLNONE -g M1Pin:PULLDOWN -g DonePin:PULLUP -g StartUpClk:JTAGCLK -g M0Pin:PULLUP -g M2Pin:PULLUP -g ProgPin:PULLUP -g TckPin:PULLUP -g TdiPin:PULLUP -g TmsPin:PULLUP -g LCK_cycle:NoWait -g Security:NONE -m -g Persist:No

And don't forgett that pesky Electrostatic-Sensitive-Devices during rework ;)

I've set "Configuration pin done" to Float and checked "Drive done pin high" as suggested by table 2.6 of ug332.

The thing is that I'm not getting CRC errors now, but Done won't go high either. Since this sounded like an entirely new problem I once again started hunting google and found some similar errors where it seemed like the byte order of the programmer was incorrect but nothing definitive.

So I'm wondering if I'm interpreting the XSVF file correct. It has a command like this;

0D...data like...800633554CAAFFFF

If I understand the docs (xapp503 is helpful, the example implementation of xapp058 as well) correctly, I have to output it as this; FFFFAA4C55330680 with (for example) 06 being "clock out a 0, then 11, then another 5x 0".

Also, if the first byte in after a command like 0D says for example 3F and I've got to clock out x bytes + 6 bits, I'm clocking out the x bytes, then 5x a 1, and the last 1 while switching to a new state. Or when the next command is more data (like another 0D command) I just clock out 6x a 1. This last bit would be the '2' in '3'.

In iMPACT I program the XC3S400 directly with the .bit file so if the bit file requires any bit/byte flipping I assume iMPACT does it.

Is this all correct? It seems to work without an hitch for XSIR commands and the like but I'm worried the bit file shouldn't be flipped like this.

Cheers,

Mike

You can use this software to program .bit files directly from the parallel port:

And this parallel cable hardware:

At least I know this works.

Mike, I am jumping on this subject now but I may have few words on it. These FPGAs are very easy to configure. They allways work well. There are several simple and common mistakes that can prevent of having it working properly. Maybe you have already passed them but here they are:

1) be sure the BIT file generated has the correct option for innitialization clock source. The default option is the CCLK for Master or Slave Serial mode. When you configure using JTAG you must change it to JTAG CLOCK. The IMPACT tool normally does it for you with a warning when you are going to configure the device. But in some cases it may not do the bit change and the FPGA won't innitialize even if it configures correctly. 2) The DONE pin must have a pull-up. In your schematic it is floating. The internal DONE circuit requires a very fast rising time and the pin must have a strong pull-up externaly. Something like 220 or 330ohms to the 2.5V supply rail (for your FPGA). Sometimes driving the DONE pin HIGH (BIT file option) may help but leaving it floating is not a good design practice. A LED in the DONE pin is always a must because then you can see the FPGA is correctly configured whenever you make a change in the bit file stored in the PlatformFLASH.

When the system starts to work don't forget that you will need a power cycle every time you re-write the PlatformFLASH with a new design in order to have it downloaded to the FPGA. It is a common mistake doing the update in the FLASH but forgeting the FPGA will get it only after a reset in the PROGRAM_B pin.

You do not need to change the mode pins to gain JTAG control and configuration. You can keep them at 000 (Master Serial) and it will work perfectly. If you had difficulties with JTAG before it was because some hardware problem or because the USB code translation to JTAG tha may not use the proper commands. When you use a Xilinx cable it works.

For a reference on how to do the circuitry for the configuration part I would recommend to download the Spartan-3 Demo Board schematic. I believe you can find it at Xilinx or at Digilent website.

-Augusto