flash programming times


Felix

Recommended Posts

using the commandline :

papilio-prog.exe -v -f final.bit -b bscanBLAH500.bit -sa -r

 

programming something as simple as invaders takes forever. (183426.7ms <-- ~3 mins)

 

is that the right way to program it to flash?

how do you get the fpga to reboot or whatever afterwards?

 

i would have thought that -r would do it, but if it does, its taking forever.

unplugging the p500 from the usb and plugging it back in starts the

bitstream that was programmed to the flash.

 

(papilio-prog.exe -j  will work to reset/reboot/whatever the fpga instead of unplugging it/plugging it back in)

[edit::: seems that papilio-prog.exe -c will also do that according to the arcade blaster source, assuming i read it right]

 

i dont remember the arcade blaster app taking that long to program to flash...

i could be mistaken tho.

 

i wonder if its something with windows 8

Link to comment
Share on other sites

papilio-prog.exe -j alone does not reset the FPGA. The only way I've found to script an FPGA reload is with

papilio-prog.exe -r

which will trigger the reconfiguration but cause the FPGA to remain stuck, then either

papilio-prog.exe -c

or

papilio-prog.exe -j

to release the FPGA so it runs again.

 

EDIT: I had a look Jack, in file progalgxc3s.cpp it seems if you duplicate the BYPASS command as below, the -r option will trigger a reconfiguration then release the FPGA again so it runs, perhaps you can test and patch the code on github if you're happy with this.

void ProgAlgXC3S::Reconfigure(){    jtag->shiftIR(&JPROGRAM);    jtag->shiftIR(&BYPASS);    jtag->shiftIR(&BYPASS);}
Link to comment
Share on other sites

thanks for the reply :)

i may just check out the source and fork it if its in github.

[edit: seems it is https://github.com/GadgetFactory/Papilio-Loader/tree/master/papilio-prog

looking at the source, it seems that the -r switch sends the same command to the fpga as -c

but it sends it right after another command.  i will see about recompiling it with a second or so delay

between commands and see if that fixes -r.

if that made sense.  i have been up all night @ work.

]

 

[edit 2::

Forked and made the change. now to either compile or let someone else compile and test for me..

]

Link to comment
Share on other sites

papilio-prog.exe -j alone does not reset the FPGA. The only way I've found to script an FPGA reload is with

papilio-prog.exe -r

which will trigger the reconfiguration but cause the FPGA to remain stuck, then either

papilio-prog.exe -c

or

papilio-prog.exe -j

to release the FPGA so it runs again.

 

EDIT: I had a look Jack, in file progalgxc3s.cpp it seems if you duplicate the BYPASS command as below, the -r option will trigger a reconfiguration then release the FPGA again so it runs, perhaps you can test and patch the code on github if you're happy with this.

void ProgAlgXC3S::Reconfigure(){    jtag->shiftIR(&JPROGRAM);    jtag->shiftIR(&BYPASS);    jtag->shiftIR(&BYPASS);}

Yeah, the reconfigure code in papilio-prog is basically a NOP.

 

It's been corrected in the Pipistello version of papilio-prog.  You can see the code here:

http://www.saanlima.com/download/fpgaprog-win.zip

 

The updated code to make reconfigure work is in the Reconfigure function in file progalgxc3s.cpp

 

 Magnus

Link to comment
Share on other sites

Good work Magnus, I took a look at your code and I have a question (I can't test it because I'm at work currently). While the comments in your code agree with xtp038.pdf the actual command you're sending to the FPGA differs.

 

In the commands you're sending, the sync word doesn't match, and the commands don't look right.

    byte xc6sbuf[12]= {0xff, 0xff, 0x55, 0x99, 0xaa, 0x66, 0x0c, 0x85, 0x00, 0x70, 0x04, 0x00};

Whereas the comments indicate you should be sending:

    byte xc6sbuf[12]= {0xff, 0xff, 0x99, 0xaa, 0x66, 0x55, 0xa1, 0x30, 0x0e, 0x00, 0x00, 0x20};

EDIT: Oops I missed your post where you mentioned you copied this from xc3sprog, I guess then you might not be able to answer the question. I have a feeling that simply shifting a certain command into IR then moving junk into the DR causes the FPGA to reset due to the DR data sync word mismatch. Hence why it appears to work even when sending BYPASS twice (0x3F, 0x3F). More guessing, but it looks like the FPGA needs at least a word (two bytes) shifted into DR at a time, hence why it hung there when sending just one BYPASS command, it expected one more byte. After receiving two bypass commands it realises that 0x3f3f is not a valid sync word and exits and resets.

Link to comment
Share on other sites

I didn't notice the difference between the comments and the actual sequence of bytes,  I just did a copy-and-paste, recompiled, and it did reconfgure the parts after the flash programming so I was happy.  Maybe this is some kind of alternate way of doing it, the sequence is the same as for xc3 but it has two sync words instead of one like xtp038.pdf but the nybbles in the sync words are scrambled.

Link to comment
Share on other sites

I'll muck around with this during Easter for my own curiosity, I'll need to research what JTAG commands and data the FPGA understands.

 

EDIT: UG380 page 130 & 159 looks like a good start.

 

EDIT 2: Oh grrr, all the fields are byte swapped and bit reversed, now it all makes sense.

 

Each 16 bit configuration data packet that is not a dummy or a sync word consists of a certain bit field.
Packet format, pages 92, 93:TYPE     - OP    - REGISTER     - WORDCOUNT15 14 13 - 12 11 - 10 9 8 7 6 5 - 4 3 2 1 0Where TYPE can be binary 001 or 010 (type 1 or type 2), page 93OP only 3 defined, binary 00 NOP, 01 READ, 10 WRITE, as per page 92REGISTER defined on page 94, 95, too many to list here. Valid range 0x00 - 0x22 (6 bits)WORDCOUNT is the number of data words expected to follow this word

Here's my interpretation of the data according to the info in UG380.

byte xc3sbuf[12]= { 0xff, 0xff, byte swapped & bit reversed is FFFF dummy word 0x55, 0x99, byte swapped & bit reversed is AA99 sync word 0x0c, 0x85, byte swapped & bit reversed is 30A1 = 001 10 000101 00001 = type 1, WRITE, CMD register, 1 word follows (see below) 0x00, 0x70, byte swapped & bit reversed is 000E = IPROG command 0x04, 0x00, byte swapped & bit reversed is 0020 = 001 00 000000 00000 = type 1, NOP command, n/a, n/a 0x04, 0x00  byte swapped & bit reversed is 0020 = 001 00 000000 00000 = type 1, NOP command, n/a, n/a};byte xc6sbuf[12]= { 0xff, 0xff, byte swapped & bit reversed is FFFF dummy word 0x55, 0x99, byte swapped & bit reversed is AA99 sync word 0xaa, 0x66, byte swapped & bit reversed is 5566 sync word 0x0c, 0x85, byte swapped & bit reversed is 30A1 = 001 10 000101 00001 = type 1, WRITE, CMD register, 1 word follows (see below) 0x00, 0x70, byte swapped & bit reversed is 000E = IPROG command 0x04, 0x00  byte swapped & bit reversed is 2000 = 001 00 000000 00000 = type 1, NOP command, n/a, n/a};
Link to comment
Share on other sites

  • 2 weeks later...
using the commandline :

papilio-prog.exe -v -f final.bit -b bscanBLAH500.bit -sa -r

 

programming something as simple as invaders takes forever. (183426.7ms <-- ~3 mins)

 

...

 

i dont remember the arcade blaster app taking that long to program to flash...

i could be mistaken tho.

 

i wonder if its something with windows 8

 

On my Linux Mint machine, it takes 21 s to write and verify a 278 kB bit file, so there may be something strange there.

There's two FTDI libraries, and IIRC papilio-prog can be compiled with either one. Try recompiling it with the other one?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.