impact bug or wrong interpretation of xsvf layout?

Hi,

While debugging my xsvf parser for ft2232 jtag programmers I experience some really odd behavior; if I swapped my buffer and then send (essentially) 'junk' to my device it would actually boot, but, without any sensible configuration and it would keep GHIGH asserted. It didn't detect a CRC error however and completed the rest of the bootcycle, which was really odd. So I dug a little further and found this;

The data in the .rbt, since it's rbt we have to read from left to right in bits;

00000000 00000000 01011111 01010111 00110000 00000000 10000000 00000001

The associated .bit, should be interpreted as MSB first;

00 00 5F 57 30 00 80 01 gives 00000000 00000000 01011111 01010111 00110000 00000000 10000000 00000001 which is a perfect match with the rbt, thus so far so good.

Now, 1.xsvf is generated using iMPACT with just the fpga in the chain, no other devices. Program with .bit while exporting to xsvf;

80 01 00 0C EA FA 00 00 read as LSB first (because it's xsvf) gives 00000001 10000000 00000000 00110000 01010111 01011111 00000000 00000000 which is indeed a flipped buffer (as it should be with xsvf) and matches the .bit.

Then, 2.xsvf, LSB first, flipped buffer with more devices in the chain (FPGA = 2nd out of 3, so shift 1 bit right)

40 00 80 06 75 7D 00 00 gives 00000010 00000000 00000001 01100000 10101110 10111110 00000000 00000000 Compensate 1 bit x0000001 00000000 00000000 10110000 01010111 01011111 00000000 00000000 What the @#$? We've got some bits going all over the place. The only explanation I can think of it this; Take the MSB first .bit; 00 00 5F 57 30 00 80 01 00000000 00000000 01011111 01010111 00110000 00000000 10000000 00000001 Compensate -1 bit 00000000 00000000 10111110 10101110 01100000 00000001 00000000 0000001x Which then reads, LSB first; 40 00 80 06 75 7D 00 00 Familiar, no?

If we take more devices (say, FPGA being 3th out of 4) gives in the xsvf; 20 00 40 03 3A BE 80 00 which means the .bit has been compensated

-2 before being byte swapped.

So really what iMPACT does is take the bit file, shift it, and _then_ byte swaps, while it should byte swap first and only after that shift the data to compensate for the other devices in the chain.

Am I a crackpot or is this a bug?

Cheers,

Mike

formatting link

Reply to
Michael Meeuwisse
Loading thread data ...

Did you try xc3sprog? I think it is working with ft2232 (I haven't tried it myself). It reads the bitstream and I've used it with parallel port w/o problems with XC3S50, XC3S200, XC3S400 and XC3S500E.

Another path could be xil_up, I think it supports ft2232 too.

If you try a software known to be working you'll be able to find out if it's the hardware or the software.

[Again, I haven't used any of the above ft2232, I have a proto board but I didn't have time to solder the wires ... :-(]

Hope this helps.

-- mmihai

Reply to
mmihai

No I haven't. I tried getting openOCD and UrJTAG but the first didn't even understand the XSVF files completely - and failed to even clock out the idcodes succesfully when it's done using an XSVF file. After a day of fighting with UrJTAG I gave up on that too, it didn't want to select my programmer and it's documentation on ft2232 support is well.. missing afaik.

The reason I was asking here is only partly because I want to program the fpga, it's equally important to get the programmer to work. So suggesting a different programmer or piece of software isn't really helping. :) I'll see if I can get xc3sprog to work, if it's capable of programming the fpga at least I know the problem lies in the parser.

However if somebody has the patience + windows/cygwin + an Amontec programmer + a xilinx dev board available please drop me a line

Back to the XSVF, I did find the culprit in my rambling, the data from

2.xsvf; 40 00 80 06 75 7D 00 00 00000010 00000000 00000001 01100000 10101110 10111110 00000000 00000000 Compensate 1 bit x0000001 00000000 00000000 10110000 01010111 01011111 00000000 00000000

That's in fact correct, but what makes it look wrong is that I'm compensating the shift without first flipping the entire buffer. My code already did that and outputs;

00 00 7D 75 06 80 00 40 00000000 00000000 10111110 10101110 01100000 00000001 00000000 00000010 And if you compensate that 1 bit you get; x0000000 00000000 01011111 01010111 00110000 00000000 10000000 00000001 Which is exactly the same as the original rbt; 00000000 00000000 01011111 01010111 00110000 00000000 10000000 00000001

So iMPACT is right, my programmer is right, but it still doesn't work, which kicks me back to square 1.

The status register of the xc3s400 after programming it with above (probably correct) sequence is; 0x0301D000 thus it has GHIGH_B deasserted and INIT high. I don't know what this state is supposed to mean; with GHIGH_B deasserted it seems that there's no configuration loaded at all, and the configuration sequence hasn't completed. Or maybe it did load a configuration correctly (which is why it deasserted GHIGH_B) but it still didn't complete the configuration sequence for some reason.

If I flip the bits of every byte (too see if MSB first output might do the trick) just before I output them the xc3s400 jumps to this state;

0x036D0000. GHIGH_B is asserted and the configuration sequence is completed. I have no idea what this means, with GHIGH_B asserted it effectively disables the internal logic afaik, which could mean (again) that no configuration is loaded - but it does start up. I can also get to this state if I shift/swap/mangle the data in other ways - it seems that if you send rubbish to the fpga it jumps to this state after you send an JSTART command.

Is anybody recognising these states? What do they mean?

Cheers,

Mike

formatting link

Reply to
Michael Meeuwisse

I have now, had to patch it somewhat to get it working with the D2XX drivers but it programmed the FPGA correctly while using the bit file. So it's definitely a software issue.

I noticed I misread the status register, the states look like;

0x031D0000 - 0011 0001 1011 0 0x036D8000 - 0011 0110 1011 1

Anybody seen this before?

Cheers,

Mike

formatting link

Reply to
Michael Meeuwisse

Good news! From your posts it looked like you had a new board and new software. Hard do debug, what's wrong, sw or hw? Now you know were to look for problems.

-- mmihai

Reply to
mmihai

Michael Meeuwisse wrote: ...

Go to the xc3prog sourceforge site and look for the pending patches there. These are my changes to get my FT2232 layout running to programm XC3S and XCF.

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

Hi, we'd really like to help, maybe it's just lack of documentation, maybe there's something wrong in UrJTAG... FT2232 support is still work in progress - please report your problems at

formatting link
! Or by mail to one of the authors, e.g. me. Otherwise we maybe don't even know that something's wrong.

Kolja

Reply to
Kolja Waschk

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.