xc3sprog-users — Generic user and developer list

Re: [Xc3sprog-users] ioxpc.cpp buffer size and burst read details

[Raul F. <rfa...@gm...>]

Hello Joris,

sorry, the last e-mail was still a draft and was sent by mistake. I'm
re-issuing it here with this initial words and a link below.

I'm answering inline...

On Sun, Feb 12, 2012 at 9:02 PM, Raul Fajardo <rfa...@gm...> wrote:

>
> Am 12.02.2012 17:41 schrieb "Joris van Rantwijk" <jor...@jo...>:
>
> >
> > Hi Raul,
> >
> > Thanks for your information about the DLC9 programming cable.
> > Unfortunately I know very little about the inner workings of the XPC
> > driver. I hope that someone with hands-on experience will comment on
> > your email.
> > Uwe?
> >
> > Indeed, our projects should keep in touch in order to benefit from each
> > others improvements. It may even be useful to have a common library
> > which handles the various types of programming cables and offers basic
> > JTAG operations as an API. If UrJTAG, XC3SPROG, adv_jtag_bridge and
> > others bundle forces, we could share the burden of cable driver
> > development.
>
I totally agree that we should share the burden. I am not maintainer of
adv_jtag_bridge but Im probably its biggest user. But I have noticed
problems with xpc usb for too long and decided thus to take the matter in
my own hands.

Its maintainer explicitly stated that he would switch to a libjtag
implementation which used to be a goal of urjtag. I dont know the libjtag
status though.

I also dropped an email to urjtag forum about my findings to allow us all
to progress at the same pace.

>  >
> > On 2012-02-09, Raul Fajardo wrote:
> > > You considered an amount of read bits of more than 32 bits to be
> > > automatically aligned. That is true if you keep a base 32 number
> > > while a received transfer of 35 bits will not be aligned as I noticed.
> >
> > Our XPC code came from the UrJTAG project. Their code is consistent
> > with your interpretation, i.e. transfers larger than 32 bits also need
> > re-alignment of the final partial block.
> >
> > However, it seems that we have seen some evidence that transfers larger
> > than 32 bits must NOT be re-aligned:
> >
> http://xc3sprog.svn.sourceforge.net/viewvc/xc3sprog?view=revision&revision=476
>
That is also stated as a comment in the code. It could be that transfers
longer than 32 bits ended up having lengthes of multiple of 32 bits.
Different usages of the driver will end up exercising the driver ib
different ways and maybe xpc3sprog uses mostly transfer lengthes multiple
of 32 bits.

However, adv_jtag_bridge did not do that. Thus, I noticed that the
remaining bits of a modulo 32 operation on the bit length always have to be
realigned. All earlier bits dont however.

I tried to restate (in comments) the behavior of the cable in order to
explain this. From a hardware designer perspective, it would be extremely
unusual if alignment of data would dynamically depend on the length of the
data. As said before, every 32 bit block is aligned, following a last block
aligned if 32 or unaligned if something else.

> >
> > > *Issue 2)* Your defined buffer level of the CPLD could not be used on
> > > my cable.
> >
> > UrJTAG uses #define XPC_A6_CHUNKSIZE (4)
> > which is even more conservative than what you recommend.
> >
> > I'm not sure where we picked up our version of CHUNKSIZE.
> > Again, I hope a more experienced developer can help out ...
>
Of course, more testing is always good. But people often skip feedback.

Again, fortunatelly, adv_jtag_bridge usage of the driver was indeed going
on the limits of the buffer. Thus, it was blocking the cable on lengths
exactly above 4096 bytes and working fine for less/equal.

>  >
> > Is it possible that there are subtle differences between
> > cables/firmwares? What is the exact type of cable that you tested with?
>
I believe it was exactly the one your driver should work on, DLC9. But I
will take a look again tomorrow.

Answering Uwe's request about allowance to use the code. You are very
welcone to use my adaptations as you please. The code can be found under
the link below.

http://opencores.org/websvn,filedetails?repname=adv_debug_sys&path=%2Fadv_debug_sys%2Ftrunk%2FSoftware%2Fadv_jtag_bridge%2Fcable_xpc_dlc9.c

I am sorry that I dont have a patch for you. I never used your software, so
it would be difficult for me to test.

Kind regards,

Raul


>
> > Kind regards, Joris.
>

Re: [Xc3sprog-users] ioxpc.cpp buffer size and burst read details

[Raul F. <rfa...@gm...>]

Am 12.02.2012 17:41 schrieb "Joris van Rantwijk" <jor...@jo...>:
>
> Hi Raul,
>
> Thanks for your information about the DLC9 programming cable.
> Unfortunately I know very little about the inner workings of the XPC
> driver. I hope that someone with hands-on experience will comment on
> your email.
> Uwe?
>
> Indeed, our projects should keep in touch in order to benefit from each
> others improvements. It may even be useful to have a common library
> which handles the various types of programming cables and offers basic
> JTAG operations as an API. If UrJTAG, XC3SPROG, adv_jtag_bridge and
> others bundle forces, we could share the burden of cable driver
> development.

I totally agree that we should share the burden. I am not maintainer of
adv_jtag_bridge but Im probably its biggest user. But I have noticed
problems with xpc usb for too long and decided thus to take the matter in
my own hands.

Its maintainer explicitly stated that he would switch to a libjtag
implementation which used to be a goal of urjtag. I dont know the libjtag
status though.

I also dropped an email to urjtag forum about my findings to allow us all
to progress at the same pace.

>
> On 2012-02-09, Raul Fajardo wrote:
> > You considered an amount of read bits of more than 32 bits to be
> > automatically aligned. That is true if you keep a base 32 number
> > while a received transfer of 35 bits will not be aligned as I noticed.
>
> Our XPC code came from the UrJTAG project. Their code is consistent
> with your interpretation, i.e. transfers larger than 32 bits also need
> re-alignment of the final partial block.
>
> However, it seems that we have seen some evidence that transfers larger
> than 32 bits must NOT be re-aligned:
>
http://xc3sprog.svn.sourceforge.net/viewvc/xc3sprog?view=revision&revision=476

That is also stated as a comment in the code. It could be that transfers
longer than 32 bits ended up having lengthes of multiple of 32 bits.
Different usages of the driver will end up exercising the driver ib
different ways and maybe xpc3sprog uses mostly transfer lengthes multiple
of 32 bits.

However, adv_jtag_bridge did not do that. Thus, I noticed that the
remaining bits of a modulo 32 operation on the bit length always have to be
realigned. All earlier bits dont however.

I tried to restate (in comments) the behavior of the cable in order to
explain this. From a hardware designer perspective, it would be extremely
unusual if alignment of data would dynamically depend on the length of the
data. As said before, every 32 bit block is aligned, following a last block
aligned if 32 or unaligned if something else.

>
> > *Issue 2)* Your defined buffer level of the CPLD could not be used on
> > my cable.
>
> UrJTAG uses #define XPC_A6_CHUNKSIZE (4)
> which is even more conservative than what you recommend.
>
> I'm not sure where we picked up our version of CHUNKSIZE.
> Again, I hope a more experienced developer can help out ...

Of course, more testing is always good. But people often skip feedback.

Again, fortunatelly, adv_jtag_bridge usage of the driver was indeed going
on the limits of the buffer. Thus, it was blocking the cable on lengthes
exactly above 4096 bytes and working fibe for less/equal.

>
> Is it possible that there are subtle differences between
> cables/firmwares? What is the exact type of cable that you tested with?

I believe it was exactly the one your driver should work on, DLC9. But I
will take a look again tomorrow.

You are very welcone to use my adaptations as you please. The code can be
found under the link below. I am sorry that I dont have a patch for you.

>
> Kind regards, Joris.

Re: [Xc3sprog-users] XCFP does not yet support bitfile subranges

[Joris v. R. <jor...@jo...>]

Hello Mirko,

On 2012-02-12, Mirko Ciecinski wrote:
> I realized, that we are using a special patched xc3sprog version 0.5
> with a new file progalgxcfxxp.cpp, based on progalgxcf.cpp.

Are you saying that this special version of XC3SPROG programs your
board successfully, while the main version of XC3SPROG does not?

Just out of curiosity, where did you get the special version?

> If you won't include mode pin set-up in xc3sprog, could you give me a
> hint, how to add it.

It is not so much a matter of pin set-up.

XCFP devices can be used in a number of modes, including either serial
or parallel, and either master or slave. The PROM contains a CCB
register which determines the mode for which it is configured.

This register is documented in Xilinx ug161:
 CCB<0>    1 = external clock, 0 = internal PROM clock
 CCB<2:1>  11 = serial output, 00 = parallel output
 CCB<3>    1 = PROM slave (FPGA master), 0 = PROM master
 CBC<5:4>  11 = 40 MHz clock, 01 = 20 MHz clock

Currently, XC3SPROG programs XCFP devices in FPGA Master Serial mode
(CCB=0xffff). XCFS devices don't have a CCB register; they always
operate in FPGA Master Serial mode. 

It would be a good idea to add support for different modes. This could
be done by adding an XCFP-specific command-line option which then gets
translated into the proper value for the CCB register.

Regards, Joris.

Re: [Xc3sprog-users] ioxpc.cpp buffer size and burst read details

[Joris v. R. <jor...@jo...>]

Hi Raul,

Thanks for your information about the DLC9 programming cable.
Unfortunately I know very little about the inner workings of the XPC
driver. I hope that someone with hands-on experience will comment on
your email.
Uwe?

Indeed, our projects should keep in touch in order to benefit from each
others improvements. It may even be useful to have a common library
which handles the various types of programming cables and offers basic
JTAG operations as an API. If UrJTAG, XC3SPROG, adv_jtag_bridge and
others bundle forces, we could share the burden of cable driver
development.

On 2012-02-09, Raul Fajardo wrote:
> You considered an amount of read bits of more than 32 bits to be
> automatically aligned. That is true if you keep a base 32 number
> while a received transfer of 35 bits will not be aligned as I noticed.

Our XPC code came from the UrJTAG project. Their code is consistent
with your interpretation, i.e. transfers larger than 32 bits also need
re-alignment of the final partial block.

However, it seems that we have seen some evidence that transfers larger
than 32 bits must NOT be re-aligned:
http://xc3sprog.svn.sourceforge.net/viewvc/xc3sprog?view=revision&revision=476

> *Issue 2)* Your defined buffer level of the CPLD could not be used on
> my cable.

UrJTAG uses #define XPC_A6_CHUNKSIZE (4)
which is even more conservative than what you recommend.

I'm not sure where we picked up our version of CHUNKSIZE.
Again, I hope a more experienced developer can help out ...

Is it possible that there are subtle differences between
cables/firmwares? What is the exact type of cable that you tested with?

Kind regards, Joris.

[Xc3sprog-users] Antwort: Re: XCFP does not yet support bitfile subranges

[Mirko C. <mir...@ki...>]

Hi Joris,

Sorry for late response (I was out of town).

>You could try reading
>back the contents of the PROM with   xc3sprog -v -c ftdi
>dump.bit:r  The read-back BIT file should be equivalent to the
>original, although the header may be different and 0xFF padding
>may be truncated from the end.
>From section "e" the contents are 100% identically. It works perfect.

>for example with multiple data wires
>between PROM and FPGA, the PROM would need to be set up
>differently. xc3sprog currently can not do this (although it
>would not be very hard to implement it). You can deduce the boot
>method of your board by looking at the level of the mode pins
>M0,M1,M2 of the FPGA.
As far as I know today, that's exactly what we are doing.

But I don't have more information about levels of mode pins M0, M1 and M2.

I realized, that we are using a special patched xc3sprog version 0.5 with a new file progalgxcfxxp.cpp, based on progalgxcf.cpp.

I'll send it to you separatly.

I think, if it is also useful for other users to set-up mode pin, it would be a great idea to include this option in xc3sprog.
(especially for non-experienced user like me)

If you won't include mode pin set-up in xc3sprog, could you give me a hint, how to add it.

Thanks in advance!
Mirko

Re: [Xc3sprog-users] XCFP does not yet support bitfile subranges

[Joris v. R. <jor...@jo...>]

On 2012-02-07, Mirko Ciecinski wrote:
> I applied your 2nd patch and now it seems to work.:-)

Great, thanks for testing.
 
> But after rebooting ePC, FPGA does not load its program from
> EEPROM. :-( Programming FPGA directly with command line parameter "-p
> 1" is working fine, but of course after shutdown my system does not
> work again.

xc3sprog sets up the PROM in slave serial mode. This means that the
FPGA must boot in master serial mode to make it work. I.e. one data
wire from PROM to FPGA, FPGA generates configuration clock for PROM.

If your board is wired differently, for example with multiple data
wires between PROM and FPGA, the PROM would need to be set up
differently. xc3sprog currently can not do this (although it would not
be very hard to implement it). You can deduce the boot method of your
board by looking at the level of the mode pins M0,M1,M2 of the FPGA.

> Anyway, if you are sure, that XC3SPROG message "Success!" is correct,
> I think there is another problem (hardware). And you can commit your
> patches to xc3sprog-project.

xc3sprog performs (most of) the status checks that are prescribed by
the XCFP programming algorithm, and Success means that all of these
passed.

You could try reading back the contents of the PROM with
  xc3sprog -v -c ftdi dump.bit:r

The read-back BIT file should be equivalent to the original, although
the header may be different and 0xFF padding may be truncated from the
end. But you should be able to directly configure the FPGA with the
read-back BIT file, for example.

Joris.

[Xc3sprog-users] Antwort: Re: XCFP does not yet support bitfile subranges

[Mirko C. <mir...@ki...>]

Hi Joris,

>There is a mistake in the XCFP
>code which only affects devices larger than XCF08P. Apparently
>you are the first one to program a big XCFP device since then.
>Could you try the attached patch?
I applied your 2nd patch and now it seems to work.:-)
=====================================
# ./xc3sprog.patch2 -v -c ftdi OCA_0x0000006F_HwBoardRev01.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 646 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
        http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
        http://sourceforge.net/projects/xc3sprog/develop

Cable ftdi type ftdi VID 0x0403 PID 6010 dbus data 00 enable 0b cbus data 00 data 00
Using Libftdi, Using JTAG frequency 1200000
Using devlist.txt
JTAG chainpos: 0 Device IDCODE = 0xe5058093     Desc: XCF16P
Erasing...............................done
Erase time 15.765 s
Programming frames 0x1fffe0 to 0x1fffff
Programming BTC , CCB , SUCR , DONE finished
Programming time 327.427 s
Verifying frames 0x195060 to 0x19506f
Verifying BTC  = 0xffffffe4
Verifying CCB  = 0xffff
Verifying SUCR = 0xfffc
Verifying DONE = 0xcc
Success!
Verify time 258.978 s
USB transactions: Write 235070 read 117611 retries 235257
=====================================

But after rebooting ePC, FPGA does not load its program from EEPROM. :-(
Programming FPGA directly with command line parameter "-p 1" is working fine, but of course after shutdown my system does not work again.

=====================================
./xc3sprog.patch2 -v -c ftdi -p 1 OCA_0x0000006F_HwBoardRev01.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 646 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565 
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop

Cable ftdi type ftdi VID 0x0403 PID 6010 dbus data 00 enable 0b cbus data 00 data 00
Using Libftdi, Using JTAG frequency 1200000
Using devlist.txt
JTAG chainpos: 1 Device IDCODE = 0x01450093Desc: XC3S5000
Created from NCD file: top.ncd
Target device: 3s5000fg900
Created: 2010/10/27 10:48:04
Bitstream length: 13271936 bits
done. Programming time 11745.1 ms
USB transactions: Write 821 read 8 retries 1508/10/2007-Alviso-6A79GTZ0C-16Phoenix - AwardBIOS v6.00PG ...
=====================================

Anyway, if you are sure, that XC3SPROG message "Success!" is correct, I think there is another problem (hardware). And you can commit your patches to xc3sprog-project.

Tomorrow I'll have a meeting with a hardware specialist, trying to use XILINX USB adapter and iMPACT to flash it again.
I'll keep you informed about the results.
Thanks again for your valuable support!

Best regards,
Mirko

Re: [Xc3sprog-users] XCFP does not yet support bitfile subranges

[Joris v. R. <jor...@jo...>]

On 2012-02-07, Mirko Ciecinski wrote:
> thanks for your quick reply. I applied your patch.
> Now xcs3prog starts programming, but after 2 min it aborts.

> Programming frames 0x1000000 to 0x100001f
> Programming failed! Aborting

Ok, one problem solved and now you hit the next issue.

There is a mistake in the XCFP code which only affects devices larger
than XCF08P. Apparently you are the first one to program a big XCFP
device since then.

Could you try the attached patch?

And thanks for reporting these issues. We really depend on good bug
reports to keep xc3sprog working accross a wide range of hardware.

Regards, Joris.

[Xc3sprog-users] Antwort: Re: XCFP does not yet support bitfile subranges

[Mirko C. <mir...@ki...>]

<font face="Vorgabe Sans Serif,Verdana,Arial,Helvetica,Sans-Serif" size="2">Hi Joris,<br><br>thanks for your quick reply. I applied your patch.<br>Now xcs3prog starts programming, but after 2 min it aborts.<br>======================================<br><pre style="font-family: Vorgabe feste Breite,Courier New,Courier,Feste Breite;">./xc3sprog.patch1 -v -j -c ftdi
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 646 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
        <a class="moz-txt-link-freetext" href="http://sourceforge.net/mail/?group_id=170565">http://sourceforge.net/mail/?group_id=170565</a>
Check Sourceforge for updates:
        <a class="moz-txt-link-freetext" href="http://sourceforge.net/projects/xc3sprog/develop">http://sourceforge.net/projects/xc3sprog/develop</a>

Cable ftdi type ftdi VID 0x0403 PID 6010 dbus data 00 enable 0b cbus data 00 data 00
Using Libftdi, Using JTAG frequency 1200000
Using devlist.txt
JTAG chainpos: 0 Device IDCODE = 0xe5058093     Desc: XCF16P
JTAG loc.: 0    IDCODE: 0xe5058093      Desc:          XCF16P   Rev: O  IR length: 16
JTAG loc.: 1    IDCODE: 0x01450093      Desc:        XC3S5000   Rev: A  IR length: 6
USB transactions: Write 6 read 4 retries 8
# ./xc3sprog.patch1 -v -c ftdi OCA_0x0000006F_HwBoardRev01.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 646 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
        <a class="moz-txt-link-freetext" href="http://sourceforge.net/mail/?group_id=170565">http://sourceforge.net/mail/?group_id=170565</a>
Check Sourceforge for updates:
        <a class="moz-txt-link-freetext" href="http://sourceforge.net/projects/xc3sprog/develop">http://sourceforge.net/projects/xc3sprog/develop</a>

Cable ftdi type ftdi VID 0x0403 PID 6010 dbus data 00 enable 0b cbus data 00 data 00
Using Libftdi, Using JTAG frequency 1200000
Using devlist.txt
JTAG chainpos: 0 Device IDCODE = 0xe5058093     Desc: XCF16P
Erasing...................................done
Erase time 17.799 s
Programming frames 0x1000000 to 0x100001f
<span style="font-weight: bold;">Programming failed! Aborting</span>
Programming time 163.790 s
USB transactions: Write 65753 read 32904 retries 65815</pre><br>======================================<br>FYI: It's a customer device I received in non-operating condition --&gt; FPGA could not load program from EEPROM.<br>Maybe EEPROM is defect?<br>Is there anything I can do to provide more information to you?<br><br>Here are information about BIT-file<br>./bitinfo &lt; OCA_0x0000006F_HwBoardRev01.bit<br><br>Bit file created on 2010/10/27 at 10:48:04.<br>Created from file top.ncd for Xilinx part 3s5000fg900.<br>Bitstream length is 1658992 bytes.<br><br><br>Thanks!<br>Mirko<br><span><br></span><br><div></div></font>

[Xc3sprog-users] Fw: XCFP does not yet support bitfile subranges

[Joris v. R. <jor...@jo...>]

Hi Mirko,

On 2012-02-06, Mirko Ciecinski wrote:
> I'm trying to flash XCF16P with xc3sprog version 646.
> Erasing is working fine, but starting flashing there is an exception

Right, it looks like XCFP is not working.
It used to work, but I probably broke it while fixing something else.

I don't currently have a test setup available with XCFP.
Could you please test the attached patch?

If this works, I will commit it to SVN. Otherwise if you still have
problems we can try to dig a bit deeper.

Kind regards, Joris.

[Xc3sprog-users] XCFP does not yet support bitfile subranges

[Mirko C. <mir...@ki...>]

<font face="Vorgabe Sans Serif,Verdana,Arial,Helvetica,Sans-Serif" size="2"> <span>Hello,<br><br>I'm trying to flash XCF16P with xc3sprog version 646.<br>Erasing is working fine, but starting flashing there is an exception (see below):<br><br><span style="font-weight: bold;">XCFP does not yet support bitfile subranges</span><br><br>Do you have any hints for me? Is there a workaround?<br>Thank you in advance!<br>===============</span><br><pre style="font-family: Vorgabe feste Breite,Courier New,Courier,Feste Breite;">./xc3sprog.mirko -v -c ftdi -j 
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 646 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
        <a class="moz-txt-link-freetext" href="http://sourceforge.net/mail/?group_id=170565">http://sourceforge.net/mail/?group_id=170565</a>
Check Sourceforge for updates:
        <a class="moz-txt-link-freetext" href="http://sourceforge.net/projects/xc3sprog/develop">http://sourceforge.net/projects/xc3sprog/develop</a>

Cable ftdi type ftdi VID 0x0403 PID 6010 dbus data 00 enable 0b cbus data 00 data 00
Using Libftdi, Using JTAG frequency 1200000
Using devlist.txt
JTAG chainpos: 0 Device IDCODE = 0xe5058093     Desc: XCF16P
JTAG loc.: 0    IDCODE: 0xe5058093      Desc:          XCF16P   Rev: O  IR length: 16
JTAG loc.: 1    IDCODE: 0x01450093      Desc:        XC3S5000   Rev: A  IR length: 6
USB transactions: Write 6 read 4 retries 8

./xc3sprog.mirko -v -c ftdi OCA_0x0000006F_HwBoardRev01.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 646 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
        <a class="moz-txt-link-freetext" href="http://sourceforge.net/mail/?group_id=170565">http://sourceforge.net/mail/?group_id=170565</a>
Check Sourceforge for updates:
        <a class="moz-txt-link-freetext" href="http://sourceforge.net/projects/xc3sprog/develop">http://sourceforge.net/projects/xc3sprog/develop</a>

Cable ftdi type ftdi VID 0x0403 PID 6010 dbus data 00 enable 0b cbus data 00 data 00
Using Libftdi, Using JTAG frequency 1200000
Using devlist.txt
JTAG chainpos: 0 Device IDCODE = 0xe5058093     Desc: XCF16P
Erasing...............................done
Erase time 15.766 s
<span style="font-weight: bold;">terminate called after throwing an instance of 'std::invalid_argument'
  what():  XCFP does not yet support bitfile subranges
Aborted</span></pre>===================================<br><br>Best regards,<br>Mirko<br><br><span>Mit freundlichem Gruss / Best regards / Cordiali saluti<br><br>Mirko Ciecinski<br>Product Manager Systems<br> <br><a class="moz-txt-link-abbreviated" href="mailto:mir...@ki...">mir...@ki...</a><br>___________________________________<br>Kistler Instrumente GmbH<br>Daimlerstraße 6, D-73760 Ostfildern, Germany<br>Tel   +49 (711) 34 07 - 139<br>Fax   +49 (711) 34 07 - 161<br>Mobil +49 (172) 9 14 12 16<br><br><a class="moz-txt-link-freetext" href="http://www.kistler.com">http://www.kistler.com</a><br><br>Geschäftsführung: Dr. Daniel Weschenfelder<br>HRB 210182 - Amtsgericht Stuttgart<br>Sitz der Gesellschaft: Ostfildern<br>___________________________________</span><div></div></font>

[Xc3sprog-users] Vertex 6

[Matthew L. <li...@bu...>]

Hi everybody.
I'm new to the forum... Has anybody had any success in using xc3sprog with
Xilinx Vertex 6 devices? I notice that Vertex 5 is on the list of
supported hw...
Cheers,
--  Matt

Re: [Xc3sprog-users] Programming PROM

[Uwe B. <bo...@el...>]

>>>>> "Mark" == Mark de Jong <mar...@gm...> writes:
  
    Mark> Hello, I was wondering if anybody could help me with programming
    Mark> my Spartan-3 Starter Board with XC3S400 chip. Downloading a
    Mark> bitfile with xc3sprog on Ubuntu works great, but I was wondering
    Mark> if I did something wrong when downloading a .mcs file. 
    Mark The XCF02S
    Mark> PROM is in position 1, so I used the following command:

    Mark> xc3sprog -c pp -v -p 1 filename.mcs * * However, this gave all
    Mark> kinds of errors. Am I doing something wrong here?
    Mark> Any solution to
    Mark> get the program into the PROM would be great!

    Mark> Thanks in advance for all comments.

Post the relevant error messages, but try to minimize repetions.

-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

[Xc3sprog-users] Programming PROM

[Mark de J. <mar...@gm...>]

Hello,

I was wondering if anybody could help me with programming my Spartan-3
Starter Board with XC3S400 chip. Downloading a bitfile with xc3sprog on
Ubuntu works great, but I was wondering if I did something wrong when
downloading a .mcs file.
The XCF02S PROM is in position 1, so I used the following command:

xc3sprog -c pp -v -p 1 filename.mcs
*
*
However, this gave all kinds of errors. Am I doing something wrong here?
Any solution to get the program into the PROM would be great!

Thanks in advance for all comments.

Kind regards,

Mark de Jong

Re: [Xc3sprog-users] Compile xc3sprog Windows version on opensuse linux

[Go L. Go <go...@ya...>]

Thanks Uwe.

Now I have this output:

-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /opt/mingw32/bin/i386-mingw32-gcc
-- Check for working C compiler: /opt/mingw32/bin/i386-mingw32-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /opt/mingw32/bin/i386-mingw32-g++
-- Check for working CXX compiler: /opt/mingw32/bin/i386-mingw32-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Could NOT find LIBFTDI (missing:  LIBFTDI_LIBRARIES LIBFTDI_INCLUDE_DIR) 
-- Could NOT find LIBFTD2XX (missing:  LIBFTD2XX_LIBRARIES LIBFTD2XX_INCLUDE_DIR) 
-- Found Subversion: /usr/bin/svn (found version "1.6.17")
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LIBFTDI_INCLUDE_DIR
   used as include directory in directory /root/xc3prog/xc3sprog.win
   used as include directory in directory /root/xc3prog/xc3sprog.win/javr
   used as include directory in directory /root/xc3prog/xc3sprog.win/packages
LIBFTDI_LIBRARIES
    linked by target "detectchain" in directory /root/xc3prog/xc3sprog.win
    linked by target "readdna" in directory /root/xc3prog/xc3sprog.win
    linked by target "xc3sprog" in directory /root/xc3prog/xc3sprog.win
    linked by target "javr" in directory /root/xc3prog/xc3sprog.win/javr

-- Configuring incomplete, errors occurred!


I downloaded libftdi from:

http://code.google.com/p/picusb/downloads/detail?name=libftdi1_devkit_MinGW32_31August2011.zip&can=2&q=

and unzipped to:

/root/lib/libftdi1-win-dev/libftdi1_devkit_MinGW32_31August2011

then modified Findlibftdi,cmake:

find_path(LIBFTDI_INCLUDE_DIR
        NAMES
            ftdi.h
        HINTS
            ${LIBFTDI_PKG_INCLUDE_DIRS}
        PATHS
            /root/lib/libftdi1-win-dev/libftdi1_devkit_MinGW32_31August2011/include
    )

    if(USE_STATIC_FTDI)
        set(_save ${CMAKE_FIND_LIBRARY_SUFFIXES})
        set(CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_STATIC_LIBRARY_SUFFIX})
    endif(USE_STATIC_FTDI)

    find_library(LIBFTDI_LIBRARIES
        NAMES
            ftdi
        HINTS
            ${LIBFTDI_PKG_LIBRARY_DIRS}
        PATHS
            /root/lib/libftdi1-win-dev/libftdi1_devkit_MinGW32_31August2011/lib


it does not fix my problem,

so I had to run:

cmake -DCMAKE_TOOLCHAIN_FILE=../Toolchain-mingw32.cmake -DLIBFTDI_LIBRARIES=/root/lib/libftdi1-win-dev/libftdi1_devkit_MinGW32_31August2011/lib/libftdi.a  -DLIBFTDI_INCLUDE_DIR=/root/lib/libftdi1-win-dev/libftdi1_devkit_MinGW32_31August2011/include ..


not, Libftdi error is gone but libftd2xxx error is still there.

Now this is the error:

Scanning dependencies of target avrfuseparse
[  1%] Building CXX object CMakeFiles/avrfuseparse.dir/avrfuseparse.cpp.obj
[  3%] Building CXX object CMakeFiles/avrfuseparse.dir/avrfusefile.cpp.obj
Linking CXX executable avrfuseparse.exe
[  3%] Built target avrfuseparse
Scanning dependencies of target bitparse
[  5%] Building CXX object CMakeFiles/bitparse.dir/bitrev.cpp.obj
[  7%] Building CXX object CMakeFiles/bitparse.dir/bitfile.cpp.obj
[  9%] Building CXX object CMakeFiles/bitparse.dir/bitparse.cpp.obj
Linking CXX executable bitparse.exe
[  9%] Built target bitparse
[ 11%] Generating cables.h
[ 13%] Generating devices.h
Scanning dependencies of target xc3sproglib
[ 15%] Building CXX object CMakeFiles/xc3sproglib.dir/ioparport.cpp.obj
/root/xc3prog/xc3sprog.win/ioparport.cpp: In member function `virtual int IOParport::Init(cable_t*, const char*, unsigned int)':
/root/xc3prog/xc3sprog.win/ioparport.cpp:310: warning: unused variable 'res'
[ 17%] Building CXX object CMakeFiles/xc3sproglib.dir/ioftdi.cpp.obj
In file included from /root/xc3prog/xc3sprog.win/ioftdi.cpp:27:
/root/xc3prog/xc3sprog.win/ioftdi.h:27:17: usb.h: No such file or directory
make[2]: *** [CMakeFiles/xc3sproglib.dir/ioftdi.cpp.obj] Error 1
make[1]: *** [CMakeFiles/xc3sproglib.dir/all] Error 2
make: *** [all] Error 2



Any suggestions?

I am afraid that cmake couldn't locate my lifftdi and libft2xx is the root cause of the problem.

thanks!




________________________________
 From: Uwe Bonnes <bo...@el...>
To: Go Leafs Go <go...@ya...> 
Cc: "xc3...@li..." <xc3...@li...> 
Sent: Friday, December 9, 2011 3:55 AM
Subject: Re: [Xc3sprog-users] Compile xc3sprog Windows version on opensuse linux
 
>>>>> "Go" == Go Leafs Go <go...@ya...> writes:

    Go> Hi Just wondering if anyone has any suggestions on how to build
    Go> windows executables xc3sprog on opensuse?

    Go> I installed mingw32, cross compiler, downloaded precompiled libftdi

    Go> I can successfully build linux exeuctables.  However I am having
    Go> problems building windows executables.

    Go> any suggestions?

In theory:
Readme.Cmake
In practice:
mkdir win32
cd win32/
cmake -DCMAKE_TOOLCHAIN_FILE=../Toolchain-mingw32.cmake ..
/spare/bon/xc3sprog/co/xc3sprog/trunk/ioftdi.cpp: In member function `unsigned int IOFtdi::readusb(unsigned char*, long unsigned int)':
/spare/bon/xc3sprog/co/xc3sprog/trunk/ioftdi.cpp:573: error: invalid conversion from `unsigned int*' to `DWORD*'
/spare/bon/xc3sprog/co/xc3sprog/trunk/ioftdi.cpp:573: error:   initializing argument 4 of `FT_STATUS FT_Read(void*, void*, DWORD, DWORD*)'
mak

Try again after SVN update. And be sure to have the import libraries
available.

Bye
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Xc3sprog-users] Compile xc3sprog Windows version on opensuse linux

[Uwe B. <bo...@el...>]

>>>>> "Go" == Go Leafs Go <go...@ya...> writes:

    Go> Hi Just wondering if anyone has any suggestions on how to build
    Go> windows executables xc3sprog on opensuse?

    Go> I installed mingw32, cross compiler, downloaded precompiled libftdi

    Go> I can successfully build linux exeuctables.  However I am having
    Go> problems building windows executables.

    Go> any suggestions?

In theory:
Readme.Cmake
 In practice:
mkdir win32
cd win32/
cmake -DCMAKE_TOOLCHAIN_FILE=../Toolchain-mingw32.cmake ..
/spare/bon/xc3sprog/co/xc3sprog/trunk/ioftdi.cpp: In member function `unsigned int IOFtdi::readusb(unsigned char*, long unsigned int)':
/spare/bon/xc3sprog/co/xc3sprog/trunk/ioftdi.cpp:573: error: invalid conversion from `unsigned int*' to `DWORD*'
/spare/bon/xc3sprog/co/xc3sprog/trunk/ioftdi.cpp:573: error:   initializing argument 4 of `FT_STATUS FT_Read(void*, void*, DWORD, DWORD*)'
mak

Try again after SVN update. And be sure to have the import libraries
available.

Bye
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

[Xc3sprog-users] Compile xc3sprog Windows version on opensuse linux

[Go L. Go <go...@ya...>]

Hi

Just wondering if anyone has any suggestions on how to build windows executables xc3sprog on opensuse?

I installed mingw32, cross compiler, downloaded precompiled libftdi

I can successfully build linux exeuctables.
However I am having problems building windows executables.

any suggestions?

thanks

Re: [Xc3sprog-users] Project web page

[Joris v. R. <jo...@sr...>]

Hi Uwe, Vasek,

Thank you both for your feedback.

The site is now functional. I'll try to keep things up to date with 
future xc3sprog developments. Of course the other project admins are 
also welcome to make changes.

There is still some missing information in the list of supported JTAG 
cables.

On Tuesday 04 October 2011, Uwe Bonnes wrote:
> - CPLD have Jedec as default files.

Ok, added.

> - Impact has nothing like devlist.txt. With non-Xilinx parts in the
> chain, you need to supply the BSDL files manual with every chain
> detection. With xc3sprog, you can add the new device to the list and
> later runs and, when supplying the patch to the list, for all other
> users.

Ok.

> - Urjtag is another "competitor"

Right. I have looked at urjtag before, but I don't completely understood 
what it's for and how it relates to xc3sprog. What they are doing seems 
pretty different.

Regards, Joris.

[Xc3sprog-users] Project web page

[Joris v. R. <jo...@sr...>]

Hi,

I'm working on a web page for xc3sprog.
A prototype is online here: http://xc3sprog.sourceforge.net/n/

The current version only provides information which is also on the 
sourceforge summary. However, I plan to add the manual page and a table 
of supported hardware. The page is mostly intended for new users who are 
trying to decide if xc3sprog could be useful for them.

In any case, this should be an improvement over the default sourceforge 
project site http://xc3sprog.sourceforge.net/

Suggestions and criticism are welcome. Otherwise I will just continue 
this and move it in place of the default project site.

Joris.

[Xc3sprog-users] [PATCH] Fix XC6SLX4 device ID

[Álvaro L. <alv...@al...>]

Hi,

The device ID listed in "devlist.txt" for XC6SLX4 is wrong (it's the same as XC6SLX9). The attached patch fixes it.

The ID can be confirmed using Xilinx ISE provided BSDL file:

attribute IDCODE_REGISTER of XC6SLX4 : entity is
	"XXXX" &	-- version
	"0100000" &	-- family
	"000000000" &	-- array size
	"00001001001" &	-- manufacturer
	"1";		-- required by 1149.1

XXXX 0100000 000000000 00001001001 1 => XXXX_0100_0000_0000_0000_0000_1001_0011 => 0xX4000093

Best,
Álvaro

Re: [Xc3sprog-users] SPI programming - delayed reads

[Uwe B. <bo...@el...>]

>>>>> "Álvaro" == Álvaro Lopes <alv...@al...> writes:

    Álvaro> Uwe Bonnes wrote:
    >> Looking at the protocoll in S71296_05.pdf, I think you won't gain
    >> much. Polling in the 10 us timeframe required for the Byte
    >> programming time (TBP) is always slow if USB round trips are
    >> involved.
    >> 
    >> Combining AAI/ trigger Read software status/ read software status to
    >> one single USB transfer will probably always return "not ready" as
    >> the 10 us TBP wait time has not yet elapsed and so you have to go
    >> another USB round trip for the next poll cycle.
    >> 
    >> What about adding the hardware poll mechanism to the BSCAN-SPI core?

    Álvaro> That would add much complexity to the core, I'd prefer to avoid
    Álvaro> that (of course a specific bscan part can be provided).

    >> Or perhaps you add dummy SCK cycles with CE high to fullfill the
    >> "wait TBP" requirement? No need to poll then.

    Álvaro> This is indeed interesting. The only problem I see right now is
    Álvaro> that there seems not to be a way to figure out TCK frequency.

SCK frequency for the BSCAN SPI core is the TCK frequency. But we have only
control on the tck frequency of the FTDI...

    >>  Remember that every POLL needs at least 125 us USB round trip (to my
 ...

    Álvaro> I did implement with non-busy check, meaning no wait for tBP
    Álvaro> (works well for low speeds), and I can erase+program+verify in
    Álvaro> about 6 seconds (increasing the FTDI JTAG frequency to its
    Álvaro> maximum). Other approaches (except for TCK one, which adds about
    Álvaro> 2 seconds) are painfully slow.

    Álvaro> While doing so, I have found some bugs on read and verify which
    Álvaro> I'll address later on this mailing list.

    Álvaro> The current implementation is an exception to the rule, like
    Álvaro> AT45 parts. I wonder if it would be best to have a separate
    Álvaro> class, with override-able methods, and implement the generic
    Álvaro> case on base class, and have AT45 and SST derive from it and
    Álvaro> implement the specifics on their classes.

If you still need to load BSCAN-SPI, it's an exception to the rule. If
BSCAN-SPI isn't loaded, it's a seperate class, in my opinion. But at last,
it is your implementation...

Bye
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Xc3sprog-users] SPI programming - delayed reads

[Álvaro L. <alv...@al...>]

Álvaro Lopes wrote:
> I did implement with non-busy check, meaning no wait for tBP (works well for low speeds), and I can erase+program+verify in about 6 seconds (increasing the FTDI
> JTAG frequency to its maximum). Other approaches (except for TCK one, which adds about 2 seconds) are painfully slow.

Some clarification here: I did program a s3e250 bitfile (about 1.2Mbit), not the entire 4Mbit flash. Also erase is sector erase, not bulk.

Álvaro

Re: [Xc3sprog-users] SPI programming - delayed reads

[Álvaro L. <alv...@al...>]

Uwe Bonnes wrote:
> Looking at the protocoll in S71296_05.pdf, I think you won't gain
> much. Polling in the 10 us timeframe required for the Byte programming time
> (TBP) is always slow if USB round trips are involved.
> 
> Combining AAI/ trigger Read software status/ read software status to one
> single USB transfer will probably always return "not ready" as the 10 us TBP
> wait time has not yet elapsed and so you have to go another USB round trip
> for the next poll cycle. 
> 
> What about adding the hardware poll mechanism to the BSCAN-SPI core?

That would add much complexity to the core, I'd prefer to avoid that (of course a specific bscan part can be provided).

> Or perhaps you add dummy SCK cycles with CE high to fullfill the "wait TBP"
> requirement? No need to poll then.

This is indeed interesting. The only problem I see right now is that there seems not to be a way to figure out TCK frequency.
>
> Remember that every POLL needs at least 125 us USB round trip (to my
> experience).  Transferring big blocks of data ist the only valid approach to
> speed up things. Doing ping pong between FTDI and PC is slow.

You are absolutely right.

> Or did you already implement your approch with the FTDI and achieve decent
> average byte programming times?

I did implement with non-busy check, meaning no wait for tBP (works well for low speeds), and I can erase+program+verify in about 6 seconds (increasing the FTDI
JTAG frequency to its maximum). Other approaches (except for TCK one, which adds about 2 seconds) are painfully slow.

While doing so, I have found some bugs on read and verify which I'll address later on this mailing list.

The current implementation is an exception to the rule, like AT45 parts. I wonder if it would be best to have a separate class, with override-able methods, and
implement the generic case on base class, and have AT45 and SST derive from it and implement the specifics on their classes.

Best,
Álvaro

Re: [Xc3sprog-users] SPI programming - delayed reads

[Álvaro L. <alv...@al...>]

Uwe Bonnes wrote:
>>>>>> "Álvaro" == Álvaro Lopes <alv...@al...> writes:
> 
>     Álvaro> Hi all, This is my first post to this list, and I'd like to
>     Álvaro> thank all of you for the excellent work you are doing with this
>     Álvaro> project. I've been using it (actually variants of it) for a long
>     Álvaro> time, and I feel it's time to go mainline and contribute my
>     Álvaro> changes for the project benefit.
> 
>     Álvaro> Right now I'm porting SST SPI flash programming algorithms to
>     Álvaro> upstream. They are based on very old source code, and there were
>     Álvaro> significant changes to BSCAN based approach - right now there is
>     Álvaro> no way to do a full transfer (write+read) on same transaction.
> 
>     Álvaro> SST uses AAI programming (Auto Address Increment), and they
>     Álvaro> support busy reply at end of each command.
> 
> Could you give a part number, so that we can have a look at teh datasheet
> and the algorithm used. What FPGA parts can use these parts as configuartion
> memory? 

Sure.

SST25VF040B : http://ww1.microchip.com/downloads/en/DeviceDoc/S71295_06.pdf
SST25VF080B : http://ww1.microchip.com/downloads/en/DeviceDoc/S71296_05.pdf

As these SPI flash use standard read commands, I think all devices which support SPI bitstream load support these parts. At least S3E (250 and 500) do.

> 
>     Álvaro> The latest BSCAN
>     Álvaro> approach stores the last scanned-in result in BRAM, and we have
>     Álvaro> to do another request in order to fetch last buffer reply (at
>     Álvaro> least, that's how I understood it from the HDL sources). In
>     Álvaro> order to speed up writes (each AAI command only programs 2 bytes
>     Álvaro> at a time) having to check status register, or do another
>     Álvaro> transaction, has a huge impact on write performance.
> 
>     Álvaro> My first suggestion (and I'll do implementation) is to have two
>     Álvaro> modes when using BSCAN+SPI: one where SPI output is directly
>     Álvaro> mapped to TDO output, and other which uses the current BRAM
>     Álvaro> buffer. This can easily be implemented by a bit-mangling on the
>     Álvaro> 32-bit header. So, at every request, you can specify whether you
>     Álvaro> want the current value to be output, or the last scanned in
>     Álvaro> value (as in current implementation)
> 
> Do both areas overlap in more items? If overlap is few, I would propose to
> write a whole new progalgspixxx class and not touch progalgspiflash.

They are a small exception, like current AT45. In fact, perhaps creating two new classes for these devices would be a good thing.

>     Álvaro> Questions, thoughts ?
> 
> Does any other project already cover that task, e.g. coreboot, openocd or
> urjtag? There is a similar area with AVR direct SPI programming. This is
> already done in avrdude.

Not sure. We have been using this project for long now, because of its versatility (and because it's not very complex).

> But even if there is a similar approach elsewere, your contribution is
> welcome. But try to not add to much more command line options and think
> about encapsulation and reuse.

No new command line options. All things are reused and properly encapsulated. Actually there are also some other changes I made you might be interested in
(which target code cleanup, reuse and understanding).

Best,
Álvaro

Re: [Xc3sprog-users] SPI programming - delayed reads

[Uwe B. <bo...@el...>]

>>>>> "Álvaro" == Álvaro Lopes <alv...@al...> writes:

    Álvaro> Hi all, This is my first post to this list, and I'd like to
    Álvaro> thank all of you for the excellent work you are doing with this
    Álvaro> project. I've been using it (actually variants of it) for a long
    Álvaro> time, and I feel it's time to go mainline and contribute my
    Álvaro> changes for the project benefit.

    Álvaro> Right now I'm porting SST SPI flash programming algorithms to
    Álvaro> upstream. They are based on very old source code, and there were
    Álvaro> significant changes to BSCAN based approach - right now there is
    Álvaro> no way to do a full transfer (write+read) on same transaction.

    Álvaro> SST uses AAI programming (Auto Address Increment), and they
    Álvaro> support busy reply at end of each command.

Could you give a part number, so that we can have a look at teh datasheet
and the algorithm used. What FPGA parts can use these parts as configuartion
memory? 

    Álvaro> The latest BSCAN
    Álvaro> approach stores the last scanned-in result in BRAM, and we have
    Álvaro> to do another request in order to fetch last buffer reply (at
    Álvaro> least, that's how I understood it from the HDL sources). In
    Álvaro> order to speed up writes (each AAI command only programs 2 bytes
    Álvaro> at a time) having to check status register, or do another
    Álvaro> transaction, has a huge impact on write performance.

    Álvaro> My first suggestion (and I'll do implementation) is to have two
    Álvaro> modes when using BSCAN+SPI: one where SPI output is directly
    Álvaro> mapped to TDO output, and other which uses the current BRAM
    Álvaro> buffer. This can easily be implemented by a bit-mangling on the
    Álvaro> 32-bit header. So, at every request, you can specify whether you
    Álvaro> want the current value to be output, or the last scanned in
    Álvaro> value (as in current implementation)

Do both areas overlap in more items? If overlap is few, I would propose to
write a whole new progalgspixxx class and not touch progalgspiflash.

    Álvaro> Questions, thoughts ?

Does any other project already cover that task, e.g. coreboot, openocd or
urjtag? There is a similar area with AVR direct SPI programming. This is
already done in avrdude.

But even if there is a similar approach elsewere, your contribution is
welcome. But try to not add to much more command line options and think
about encapsulation and reuse.

Bye

-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------