xc3sprog-users — Generic user and developer list

Re: [Xc3sprog-users] How to program a PROM memory (XCFxxS).?

[Luis A. G. <gua...@gm...>]

2013/9/15 Joris van Rantwijk <jor...@jo...>:
> Hi Luis,
>
Hi Joris,

> On 2013-09-15, Luis Alberto Guanuco wrote:
>> The output xc3sprog write the message "Programming does not end at
>> block boundary (nbits = 1047616), padding".
>
> It is not an error message.
> XC3Sprog has noticed that the BIT file does not precisely fill a number
> of blocks in the PROM, so it adds 0xff in the last block. This is normal.
>
> Is the FPGA booting correctly from the PROM?
>

I can not to program the PROM correctly but I can to program the FPGA
directly. I was read the "manual page site" and I try to program the
memory...

luis@luis-laptop:build$ ./xc3sprog -v -c ftdiphr
s3board_prom.mcs:W:0:MCS: -p 1 -R
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 747 $ OS: Linux
...
Using devlist.txt
Using cablelist.txt
Cable ftdiphr type ftdi VID 0x0403 PID 0x6010 dbus data 00 enable 0b
cbus data 00 data 00
Using Libftdi, Using JTAG frequency   6.000 MHz from undivided clock
JTAG chainpos: 1 Device IDCODE = 0x05045093 Desc: XCF02S
Programming does not end at block boundary (nbits = 1047616), padding
Programming block    255/   256 at XCF frame 0x1fe0.done
Programming time 2817.2 ms
Verify block    255/   256 at XCF frame 0x1fe0
Success! Verify time 792.9 ms
USB transactions: Write 779 read 772 retries 1762

but when I change the FPGA boot mode (M[2:0] from JTAG to Master
Serial) seems that the PROM doesn't load to the FPGA.


Any suggestions?

Regards,

Luis
> Joris.



-- 
P Antes de imprimir, piense en su responsabilidad y compromiso con el
MEDIO AMBIENTE

Re: [Xc3sprog-users] Programming Spartan-II

[Arnim L. <arn...@gm...>]

Am 15.09.2013 13:04, schrieb bo...@el...:
>>>>>> "Arnim" == Arnim Läuger <arn...@gm...> writes:
> 
>     Arnim> Hi, I'm trying to configure a Spartan-II XC2S100 device usinc
>     Arnim> xc3sprog.  The FPGA is included in the scan chain together with
>     Arnim> an XCF01S and it's config mode pins are set to Master Serial.
> ...
> 
> What happens if you un- and repower the board?

The FPGA automatically loads the image that's currently stored in the PROM.

> What happens with the -R option?

# ./xc3sprog -c olimex -p 1 -R
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 747 $ 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

Using Libftdi,
Device does not support reconfiguration.


Did some further trials targetting the PROM:
* xc3sprog can erase the PROM. After a power cycle the FPGA remains
unconfigured.
* xc3sprog can store the mcs-file to the PROM. FPGA configures properly
upon a power cycle.

But in both cases I can't download the bit-file directly to the xc2s100.
It won't come up with the new configuration.


Cheers,
Arnim

Re: [Xc3sprog-users] Programming Spartan-II

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

>>>>> "Arnim" == Arnim Läuger <arn...@gm...> writes:

    Arnim> Hi, I'm trying to configure a Spartan-II XC2S100 device usinc
    Arnim> xc3sprog.  The FPGA is included in the scan chain together with
    Arnim> an XCF01S and it's config mode pins are set to Master Serial.
...
    Arnim> Especially the configuration mode "Master Serial" might cause
    Arnim> some headaches on this device when (re)configuring with JTAG -
    Arnim> the docs are not quite clear on how this scenario should be
    Arnim> addressed.  What is your experience with the Spartan-II?

What happens if you un- and repower the board?

What happens with the -R option?


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

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

Re: [Xc3sprog-users] How to program a PROM memory (XCFxxS).?

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

Hi Luis,

On 2013-09-15, Luis Alberto Guanuco wrote:
> The output xc3sprog write the message "Programming does not end at
> block boundary (nbits = 1047616), padding".

It is not an error message.
XC3Sprog has noticed that the BIT file does not precisely fill a number
of blocks in the PROM, so it adds 0xff in the last block. This is normal.

Is the FPGA booting correctly from the PROM?

Joris.

[Xc3sprog-users] How to program a PROM memory (XCFxxS).?

[Luis A. G. <gua...@gm...>]

Hi All,

How to program a PROM memory (XCFxxS) in the chain JTAG ( e.g.: FPGA+PROM).?

I programmed directly the FPGA using the command:

luis@luis-laptop:build$ ./xc3sprog -v -c ftdiphr S3demo.bit -p 0

XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 747 $ OS: Linux
....
Using devlist.txt
Using cablelist.txt
Cable ftdiphr type ftdi VID 0x0403 PID 0x6010 dbus data 00 enable 0b
cbus data 00 data 00
Using Libftdi, Using JTAG frequency 857.142 kHz from undivided clock
JTAG chainpos: 0 Device IDCODE = 0x01414093 Desc: XC3S200
Created from NCD file: S3demo.ncd;UserID=0xFFFFFFFF
Target device: 3s200ft256
Created: 2013/09/15 02:28:25
Bitstream length: 1047616 bits
done. Programming time 1251.0 ms
USB transactions: Write 73 read 8 retries 16


When I used the same command line with the change  "-p 1". The
xc3sprog has a problem,

luis@luis-laptop:build$ ./xc3sprog -v -c ftdiphr S3demo.bit -p 1

XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 747 $ OS: Linux
...
Using devlist.txt
Using cablelist.txt
Cable ftdiphr type ftdi VID 0x0403 PID 0x6010 dbus data 00 enable 0b
cbus data 00 data 00
Using Libftdi, Using JTAG frequency 857.142 kHz from undivided clock
JTAG chainpos: 1 Device IDCODE = 0x05045093 Desc: XCF02S
Erasing......done
Erase time 3159.1 ms
Programming does not end at block boundary (nbits = 1047616), padding
Programming block    255/   256 at XCF frame 0x1fe0.done
Programming time 3894.9 ms
Verify block    255/   256 at XCF frame 0x1fe0
Success! Verify time 1652.0 ms
USB transactions: Write 792 read 779 retries 1900

The output xc3sprog write the message "Programming does not end at
block boundary (nbits = 1047616), padding".

I should run another command? Can I to use the mcs files generated by
iMPACT tool? How to could do it?

Regards,

Luis





-- 
P Antes de imprimir, piense en su responsabilidad y compromiso con el
MEDIO AMBIENTE

[Xc3sprog-users] Programming Spartan-II

[Arnim L. <arn...@gm...>]

Hi,

I'm trying to configure a Spartan-II XC2S100 device usinc xc3sprog.
The FPGA is included in the scan chain together with an XCF01S and it's
config mode pins are set to Master Serial.

xc3sprog detects the parts in the chain:
# ./xc3sprog -c olimex
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 747 $ 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

Using Libftdi,
JTAG loc.:   0  IDCODE: 0xd5044093  Desc:                         XCF01S
Rev: M  IR length:  8
JTAG loc.:   1  IDCODE: 0x30614093  Desc:                        XC2S100
Rev: C  IR length:  5


But when I download the generated bit-file (ISE 10.1.03) nothing changes
in the FPGA. Meaning I don't observe that the FPGA is configured and
starts from "power-on". LEDs don't fall back to reset start etc.
Though the logs look ok:

# ./xc3sprog -c olimex -p 1 -v test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 747 $ 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

Using devlist.txt
Using cablelist.txt
Cable olimex type ftdi VID 0x15ba PID 0x0003 dbus data 00 enable 1b cbus
data 00 data 08
Using Libftdi, Using JTAG frequency   1.200 MHz from undivided clock
JTAG chainpos: 1 Device IDCODE = 0x30614093     Desc: XC2S100
Created from NCD file: test.ncd
Target device: 2s100tq144
Created: 2013/ 9/14 22: 5:11
Bitstream length: 781216 bits
USB transactions: Write 52 read 4 retries 4


Especially the configuration mode "Master Serial" might cause some
headaches on this device when (re)configuring with JTAG - the docs are
not quite clear on how this scenario should be addressed.
What is your experience with the Spartan-II?


Best regards,
Arnim

Re: [Xc3sprog-users] xc3sprog didn't find a device in the multiple devices chain

[Luis A. G. <gua...@gm...>]

2013/9/12  <bo...@el...>:
>>>>>> "Luis" == Luis Alberto Guanuco <gua...@gm...> writes:
>
>     Luis> 2013/9/11 <bo...@el...>:
>     >>>>>>> "Luis" == Luis Alberto Guanuco <gua...@gm...> writes:
>     >>
>     >>
>     Luis> I did do it but the problem continues. I tried to lower the
>     Luis> frequency more but the OOCDLink-s board doesn't can find the FPGA
>     Luis> in the JTAG chain.
>     >>
>     >> Strange. What oocdlink ist that?
>     >>
>     >> Openocd in interface/ftdi/oocdlink.cfg claims that OOCDLink has VID
>     >> 0x0403 and PID 0xbaf8. "xc3sprog -c ftdi" shouldn't find the
>     >> device. Is your part a clone with PID unprogrammed? Where did you get
>     >> it from, is there a schematic?
>     >>
>
>     Luis> The OOCDLink-s version that I used is based in a FT2232D[0]. This
>     Luis> device has VID 0x0403 and PID 0x0610. I developed a board
>     Luis> OOCDLink-s in the KiCAD's format. The original schematic can show
>     Luis> here[1] and my version here[2].
>
> Is ADBUS6 directly connected to VCCIO? So if by chance ADBUS6 is used as
> low output it will short VCCIO? Not good.

Yes, ADBUS6 is connected to VCCIO. I checked this pin in the
oscilloscope but it never falls to LOW level.

>
> I think SRST should also be OUTPUT High, so the config line changes to:
>
> oocdlink-s      ftdi    1500000 0x0403:0xbaf8::1:0:0x80:0x80:0x05:0x0f
>
> When using the default VID:PID, It think it is a good idea to program some
> own iSerial, like "OOCDLINK-S" and a unique serial. That way, a config line
> like
> oocdlink-s      ftdi    1500000 0x0403:0xbaf8:OOCDLINK-S:1:0:0x80:0x80:0x05:0x0f
> called with "xc3sprog -c OOCDLINK-S"  would only try to open those devices.
>

I did do it but still XC3SPROG doesn't detect the FPGA.

I will check the connections on my schematic (OOCDLink-s board)
particulary at ADBUS pins that are not JTAG port  (TMS,TCK,TDI,TDO).

[another question] Does anybody know about any  JTAG interace
published as a free/open project?

Regards,

Luis


> Bye
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------



-- 
P Antes de imprimir, piense en su responsabilidad y compromiso con el
MEDIO AMBIENTE

Re: [Xc3sprog-users] xc3sprog didn't find a device in the multiple devices chain

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

>>>>> "Luis" == Luis Alberto Guanuco <gua...@gm...> writes:

    Luis> 2013/9/11 <bo...@el...>:
    >>>>>>> "Luis" == Luis Alberto Guanuco <gua...@gm...> writes:
    >> 
    >> 
    Luis> I did do it but the problem continues. I tried to lower the
    Luis> frequency more but the OOCDLink-s board doesn't can find the FPGA
    Luis> in the JTAG chain.
    >> 
    >> Strange. What oocdlink ist that?
    >> 
    >> Openocd in interface/ftdi/oocdlink.cfg claims that OOCDLink has VID
    >> 0x0403 and PID 0xbaf8. "xc3sprog -c ftdi" shouldn't find the
    >> device. Is your part a clone with PID unprogrammed? Where did you get
    >> it from, is there a schematic?
    >> 

    Luis> The OOCDLink-s version that I used is based in a FT2232D[0]. This
    Luis> device has VID 0x0403 and PID 0x0610. I developed a board
    Luis> OOCDLink-s in the KiCAD's format. The original schematic can show
    Luis> here[1] and my version here[2].

Is ADBUS6 directly connected to VCCIO? So if by chance ADBUS6 is used as
low output it will short VCCIO? Not good.

I think SRST should also be OUTPUT High, so the config line changes to:

oocdlink-s      ftdi    1500000 0x0403:0xbaf8::1:0:0x80:0x80:0x05:0x0f

When using the default VID:PID, It think it is a good idea to program some
own iSerial, like "OOCDLINK-S" and a unique serial. That way, a config line
like
oocdlink-s      ftdi    1500000 0x0403:0xbaf8:OOCDLINK-S:1:0:0x80:0x80:0x05:0x0f
called with "xc3sprog -c OOCDLINK-S"  would only try to open those devices.

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

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

Re: [Xc3sprog-users] xc3sprog didn't find a device in the multiple devices chain

[Luis A. G. <gua...@gm...>]

2013/9/11  <bo...@el...>:
>>>>>> "Luis" == Luis Alberto Guanuco <gua...@gm...> writes:
>
>
>     Luis> I did do it but the problem continues. I tried to lower the
>     Luis> frequency more but the OOCDLink-s board doesn't can find the FPGA
>     Luis> in the JTAG chain.
>
> Strange. What oocdlink ist that?
>
> Openocd in interface/ftdi/oocdlink.cfg claims that OOCDLink has VID 0x0403
> and PID 0xbaf8. "xc3sprog -c ftdi" shouldn't find the device. Is your part a
> clone with PID unprogrammed? Where did you get it from, is there a schematic?
>

The OOCDLink-s version that I used is based in a FT2232D[0]. This
device has VID 0x0403 and PID 0x0610. I developed a board OOCDLink-s
in the KiCAD's format. The original schematic can show here[1] and my
version here[2].

> It also is not a plain ftdi adapter, as there are more lines connected than
> the pure JTAG lines TDI,TDO, TMS and TCK. Is your adapter like the one on
> http://www.mikrocontroller.net/topic/174413?
>

The design has a few resistors that were used as pullup/pulldown (JTAG
lines) in channel A. The channel B is used as a UART mode. The
JTAG-adapter published in the mikrocontroller site is similar but no
the some.

> This would need in cablelist.txt a line like
> oocdlink      ftdi    1500000 0x0403:0xbaf8::1:0:0x00:0x00:0x05:0x0f
> to drive the two tristate buffers driving TRST and RST. With the default "-c
> ftdi" these lines float. There are external pullups in the schematic above
> that would drive /RESET and TRST to a save value. Maybe they start with the right value but than
> drift to an invalid value disturbing the scan. Look in the manpage how to
> get xc3sprog to read a custom cablelits.txt

I will try do it.

>
> Think on the DBUS_DATA:DBUS_EN:CBUS_DAT:ACBUS_EN values in cablelist as the
> hex value you would send to DDR and PORT of an AVR port. Cablelist.txt
> automatically adds the definitions needed for TDI,TDO, TMS and TCK.
>
> What is the output from "lsusb -v -d 0403:". Is a custom idProduct provided?
> If we get a valid oocdlink cablelist definitions, I will add it on
> sourecforge.

"luis@luis-laptop:trunk$ lsusb -d 0403:" --> output the command here[3].

>
> Bye
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Regards,

Luis.


[0] http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232D.pdf
[1] http://opencores.org/websvn,filedetails?repname=phr&path=%2Fphr%2Ftrunk%2Fdoc%2Freferences%2FJTAG-doc%2FOOCDLink-s%2Foocdlinks-04_schematic.pdf
[2] http://opencores.org/websvn,filedetails?repname=phr&path=%2Fphr%2Ftrunk%2Fplacas%2FOOCD_placa%2Foutput%2FOOCD_placa.pdf
[3] http://pastebin.com/1BcupwhK


-- 
P Antes de imprimir, piense en su responsabilidad y compromiso con el
MEDIO AMBIENTE

Re: [Xc3sprog-users] xc3sprog didn't find a device in the multiple devices chain

[Luis A. G. <gua...@gm...>]

2013/9/11  <bo...@el...>:
>>>>>> "Luis" == Luis Alberto Guanuco <gua...@gm...> writes:
>
>
>     Luis> I am newer user. I ran the basic command ./xc3sprog -c ftdi
>
> As you can see in the cablelist, this runs with 1.5 MHz Jtag clock. This may
> be too high.
>
>     Luis> Should I run another command, add some arguments?
>
> Lower the JTAG frequency like
>
> ./xc3sprog -c ftdi -J 500000
>

I did do it but the problem continues. I tried to lower the frequency
more but the OOCDLink-s board doesn't can find the FPGA in the JTAG
chain.

luis@luis-laptop:build$ ./xc3sprog -c ftdi -J 500000
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 747 $ OS: Linux
...
Using Libftdi,
Probably a broken Atmel device in your chain!
No succeeding device can be identified
Cannot find device having IDCODE=f3fffff Revision P
JTAG loc.:   0  IDCODE: 0xff3fffff  not found in 'built-in device list'.
JTAG loc.:   1  IDCODE: 0x05045093  Desc:
XCF02S Rev: A  IR length:  8


> What frequency does OOCDLink use. Try that freuency as a start.

Thanks very much! I do will continue searching any solutions for this problem.

Regards,

Luis.

>
> Bye
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

-- 
P Antes de imprimir, piense en su responsabilidad y compromiso con el
MEDIO AMBIENTE

Re: [Xc3sprog-users] xc3sprog didn't find a device in the multiple devices chain

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

>>>>> "Luis" == Luis Alberto Guanuco <gua...@gm...> writes:


    Luis> I am newer user. I ran the basic command ./xc3sprog -c ftdi

As you can see in the cablelist, this runs with 1.5 MHz Jtag clock. This may
be too high.

    Luis> Should I run another command, add some arguments?

Lower the JTAG frequency like

./xc3sprog -c ftdi -J 500000

What frequency does OOCDLink use. Try that freuency as a start.

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

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

Re: [Xc3sprog-users] xc3sprog didn't find a device in the multiple devices chain

[Luis A. G. <gua...@gm...>]

2013/9/11  <bo...@el...>:
>>>>>> "Luis" == Luis Alberto Guanuco <gua...@gm...> writes:
>
>     Luis> Hi All, I have a S3Board (by Digilent)[0]. The board has a FPGA
>     Luis> (XC3S200) and a PROM (XCF02S). This devices are connected a JTAG
>     Luis> chain (JTAG[TDI]
>     --> FPGA --> PROM --> JTAG[TDO]).
>
>     Luis> I use the OOCDLink-s[1] board which is a FT2232D based JTAG
>     Luis> interface.
>
>     Luis> The problem is when I run xc3sprog it didn't find the
>     Luis> FPGA(0x01414093). It found only the PROM(0x01414093) memory. In
>     Luis> fact, xc3sprog detect other unknown device but sure it's wrong
>     Luis> value.
>
>     Luis> /home/luis/sourceforge/xc3sprog-code/build luis@luis-laptop:build$
>     Luis> ./xc3sprog -c ftdi XC3SPROG (c) 2004-2011 xc3sprog project $Rev:
>     Luis> 747 $ OS: Linux ...  Using Libftdi, Probably a broken Atmel device
>     Luis> in your chain!  No succeeding device can be identified Cannot find
>     Luis> device having IDCODE=f7fffff Revision P JTAG loc.: 0 IDCODE:
>     Luis> 0xff7fffff not found in 'built-in device list'.  JTAG loc.: 1
>     Luis> IDCODE: 0x01414093 Desc: XCF02S Rev: A IR length: 8
>
>
>     Luis> I probed to connect the JTAG chain with the Cable USB II (Xilinx)
>     Luis> and it works! (I can program the FPGA and PROM with the iMPACT
>     Luis> software).
>
>     Luis> I used xc3sprog with a CPLD (XC9572XL) and I didn't have any
>     Luis> problem in detected it. But I don't know how solved the problem
>     Luis> with multiple devices.
>
>     Luis> luis@luis-laptop:build$ ./xc3sprog -c ftdi XC3SPROG (c) 2004-2011
>     Luis> xc3sprog project $Rev: 747 $ OS: Linux ...  Using Libftdi, JTAG
>     Luis> loc.: 0 IDCODE: 0x59604093 Desc: XC9572XL Rev: E IR length: 8
>
>     Luis> Anybody used xc3sprog with a multiple Xilinx devices
>     Luis> (FPGA,PROM,CPLD)?
>
> Yes, I do.
> Problems like yours are often chain integrity problems
> - excessive ringing on cables giving ghost impulses
> - to few ground connections between dongle and target
> - JTAG speed to high
> - bad or unsoldered pins or shorts/open with some JTAG pins
>

The S3Board works. The board was programmed with the Cable USB II
(Xilinx). And I used the OOCDLink-s interface with a CPLD and another
board (e.g.: ARM-based board).

> Please look carefully for these problems. What command line did you use?
>

I am  newer user. I ran the basic command
./xc3sprog -c ftdi

Should I run another command, add some arguments?

Regards,

Luis

> Bye
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------



-- 
P Antes de imprimir, piense en su responsabilidad y compromiso con el
MEDIO AMBIENTE

Re: [Xc3sprog-users] xc3sprog didn't find a device in the multiple devices chain

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

>>>>> "Luis" == Luis Alberto Guanuco <gua...@gm...> writes:

    Luis> Hi All, I have a S3Board (by Digilent)[0]. The board has a FPGA
    Luis> (XC3S200) and a PROM (XCF02S). This devices are connected a JTAG
    Luis> chain (JTAG[TDI]
    --> FPGA --> PROM --> JTAG[TDO]).

    Luis> I use the OOCDLink-s[1] board which is a FT2232D based JTAG
    Luis> interface.

    Luis> The problem is when I run xc3sprog it didn't find the
    Luis> FPGA(0x01414093). It found only the PROM(0x01414093) memory. In
    Luis> fact, xc3sprog detect other unknown device but sure it's wrong
    Luis> value.

    Luis> /home/luis/sourceforge/xc3sprog-code/build luis@luis-laptop:build$
    Luis> ./xc3sprog -c ftdi XC3SPROG (c) 2004-2011 xc3sprog project $Rev:
    Luis> 747 $ OS: Linux ...  Using Libftdi, Probably a broken Atmel device
    Luis> in your chain!  No succeeding device can be identified Cannot find
    Luis> device having IDCODE=f7fffff Revision P JTAG loc.: 0 IDCODE:
    Luis> 0xff7fffff not found in 'built-in device list'.  JTAG loc.: 1
    Luis> IDCODE: 0x01414093 Desc: XCF02S Rev: A IR length: 8


    Luis> I probed to connect the JTAG chain with the Cable USB II (Xilinx)
    Luis> and it works! (I can program the FPGA and PROM with the iMPACT
    Luis> software).

    Luis> I used xc3sprog with a CPLD (XC9572XL) and I didn't have any
    Luis> problem in detected it. But I don't know how solved the problem
    Luis> with multiple devices.

    Luis> luis@luis-laptop:build$ ./xc3sprog -c ftdi XC3SPROG (c) 2004-2011
    Luis> xc3sprog project $Rev: 747 $ OS: Linux ...  Using Libftdi, JTAG
    Luis> loc.: 0 IDCODE: 0x59604093 Desc: XC9572XL Rev: E IR length: 8

    Luis> Anybody used xc3sprog with a multiple Xilinx devices
    Luis> (FPGA,PROM,CPLD)?

Yes, I do.
Problems like yours are often chain integrity problems
- excessive ringing on cables giving ghost impulses
- to few ground connections between dongle and target
- JTAG speed to high
- bad or unsoldered pins or shorts/open with some JTAG pins

Please look carefully for these problems. What command line did you use?

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

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

[Xc3sprog-users] xc3sprog didn't find a device in the multiple devices chain

[Luis A. G. <gua...@gm...>]

Hi All,
I have a S3Board (by Digilent)[0]. The board has a FPGA (XC3S200) and
a PROM (XCF02S). This devices are connected a JTAG chain (JTAG[TDI]
--> FPGA --> PROM --> JTAG[TDO]).

I use the OOCDLink-s[1] board which is a FT2232D based JTAG interface.

The problem is when I run xc3sprog it didn't find the
FPGA(0x01414093). It found only the PROM(0x01414093) memory. In fact,
xc3sprog detect other unknown device but sure it's wrong value.

/home/luis/sourceforge/xc3sprog-code/build
luis@luis-laptop:build$ ./xc3sprog -c ftdi
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 747 $ OS: Linux
...
Using Libftdi,
Probably a broken Atmel device in your chain!
No succeeding device can be identified
Cannot find device having IDCODE=f7fffff Revision P
JTAG loc.:   0  IDCODE: 0xff7fffff  not found in 'built-in device list'.
JTAG loc.:   1  IDCODE: 0x01414093  Desc:
XCF02S Rev: A  IR length:  8


I probed to connect the JTAG chain with the  Cable USB II (Xilinx)
and it works! (I can program the FPGA and PROM with the iMPACT
software).

I used xc3sprog with a CPLD (XC9572XL) and I didn't have any problem
in detected it. But I don't know how solved the problem with multiple
devices.

luis@luis-laptop:build$ ./xc3sprog -c ftdi
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 747 $ OS: Linux
...
Using Libftdi,
JTAG loc.:   0  IDCODE: 0x59604093  Desc:
XC9572XL Rev: E  IR length:  8

Anybody used xc3sprog with a multiple  Xilinx devices (FPGA,PROM,CPLD)?

Thanks in advance!

Luis
[0] http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD
[1] http://opencores.org/websvn,filedetails?repname=phr&path=%2Fphr%2Ftrunk%2Fplacas%2FOOCD_placa%2Foutput%2FOOCD_placa.ps

P.S.: I am developing a Reconfigurable Hardware Platform (hardware and
software development). The PHR (acronym in spanish "Plataforma de
Hardware Reconfigurable") is a free/open project. It's a board with a
FPGA with a PROM memory and several devices connected to IO ports of
the FPGA. The hardware design has a GPL licence and I want used a free
software to program the devices (FPGA and PROM).
The project is hosted on opencores.org server. For more informations
you can visit http://opencores.org/project,phr

-- 
P Antes de imprimir, piense en su responsabilidad y compromiso con el
MEDIO AMBIENTE

Re: [Xc3sprog-users] Programming Virtex 7 devices

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

>>>>> "Joris" == Joris van Rantwijk <jor...@jo...> writes:

    Joris> Hi, I just committed a small change to enable programming Virtex
    Joris> 7 FPGAs.  It seems to work well with XC7VX690T.

    Joris> My first attempt was to follow the IEEE 1532 data from
    Joris> Xilinx. Our usual XC3S programming flow (Xilinx calls it the
    Joris> "legacy" flow) is not documented for Virtex 7 devices. I thus
    Joris> used flow_array_program instead, but could not get it to work. In
    Joris> the end I went back to our usual XC3S flow and it just works
    Joris> without any problems, documented or not.

    Joris> I have not yet committed my changes to devlist.txt because there
    Joris> seem to be some conflicts. We already carried a few Virtex 7
    Joris> entries in devlist.txt, but some of those entries are for part
    Joris> numbers that Xilinx does not currently seem to support, and some
    Joris> of those entries have IDCODEs that Xilinx is now using for other
    Joris> part numbers.

    Joris> As show below, I'd like to remove the entries that are not backed
    Joris> by current Xilinx documentation while adding entries for the
    Joris> Virtex 7 parts that we can actually program.

    Joris> Any objections?

Back from holidays, sorry for the delay.

I have no access to Virtex devices, so anything about Virtex is either taken
from the documentation at some time or contributed by others. So I think you
have put some thoughts in your additions and the contribution is welcome.

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

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

[Xc3sprog-users] Programming Virtex 7 devices

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

Hi,

I just committed a small change to enable programming Virtex 7 FPGAs.
It seems to work well with XC7VX690T.

My first attempt was to follow the IEEE 1532 data from Xilinx. Our
usual XC3S programming flow (Xilinx calls it the "legacy" flow) is not
documented for Virtex 7 devices. I thus used flow_array_program
instead, but could not get it to work. In the end I went back to our
usual XC3S flow and it just works without any problems, documented or
not.

I have not yet committed my changes to devlist.txt because there seem
to be some conflicts. We already carried a few Virtex 7 entries in
devlist.txt, but some of those entries are for part numbers that Xilinx
does not currently seem to support, and some of those entries have
IDCODEs that Xilinx is now using for other part numbers.

As show below, I'd like to remove the entries that are not backed by
current Xilinx documentation while adding entries for the Virtex 7
parts that we can actually program.

Any objections?

Regards,
Joris.

--- devlist.txt	(revision 746)
+++ devlist.txt	(working copy)
@@ -5,13 +5,14 @@
 03651093      6    0x9 XC7K325T
 03656093      6    0x9 XC7K410T
 
-03667093      6    0x9 XC7V285T
-0366C093      6    0x9 XC7V450T
+03667093      6    0x9 XC7VX330T
 03671093      6    0x9 XC7V585T
-03676093      6    0x9 XC7V855T
+03682093      6    0x9 XC7VX415T
+03687093      6    0x9 XC7VX485T
+03691093      6    0x9 XC7VX690T
+03692093      6    0x9 XC7VX550T
+03696093      6    0x9 XC7VX980T
 
-03687093      6    0x9 XC7VX4855T
-
 04244093     10  0x3c9 XC6VLX75T(L)
 0424a093     10  0x3c9 XC6VLX130T(L)
 0424c093     10  0x3c9 XC6VLX195T(L)

Re: [Xc3sprog-users] bscan 59a6 bug

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

>>>>> "joosteto" == joosteto  <joo...@gm...> writes:

    joosteto> Now with Verilog patch.  I just verified it, and when using
    joosteto> the original bscan/xc3s500e_godil.v verilog to generate a .bit
    joosteto> file, and using it to write my papilio flash, I get
    joosteto> verification errors (the same as before).

    joosteto> But when I reset the header as suggested in my previous post
    joosteto> (and below diff), the verification errors disappear.

    joosteto> (when using xc3s500e_godil.v, I don't have to apply any other
    joosteto> changes to the source, it compiles without problems, unlike
    joosteto> the bscan_s3_spi_isf.vhd VHDL file, that clearly was written
    joosteto> for Spartan 3A, not 3E).

    joosteto> Uwe, if/when you decide to aply this fix, I wouldn't mind
    joosteto> writing patches for the other .vhd and .v files (but I will
    joosteto> not be able to test them).

I have factored out  the common verilog to a single file and applied your
patch.

Will try to verify in the next days. Thanks!

VHDL is not my language, so I rely on others to send patches. Should I scan
my mail folder for the work you already did on the VHDL code or can you send
me a clean patch? Probably also for the VHDL code, the common code should be
factored out.

Thanks again.

Bye

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

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

Re: [Xc3sprog-users] bscan 59a6 bug

[joosteto <joo...@gm...>]

Now with Verilog patch.

I just verified it, and when using the original bscan/xc3s500e_godil.v
verilog to generate a .bit file, and using it to write my papilio flash, I
get verification errors (the same as before).

But when I reset the header as suggested in my previous post (and below
diff), the verification errors disappear.

(when using xc3s500e_godil.v, I don't have to apply any other changes to
the source, it compiles without problems, unlike the bscan_s3_spi_isf.vhd
VHDL file, that clearly was written for Spartan 3A, not 3E).

Uwe, if/when you decide to aply this fix, I wouldn't mind writing patches
for the other .vhd and .v files (but I will not be able to test them).

--- /tmp/xc3s500e_godil-orig.v  2013-06-25 00:03:19.757431074 +0200
+++ xc3s500e_godil.v    2013-06-25 00:02:18.073428249 +0200
@@ -41,6 +41,7 @@
    wire        RAM_DO;
    wire        RAM_DI;
    reg                RAM_WE = 0;
+   reg         reset_header = 0;

 //   assign dac_cs = 1;
 //   assign amp_cs = 1;
@@ -125,14 +126,21 @@
          RAM_WADDR <= 0;
          RAM_RADDR <=0;
          RAM_WE <= 0;
+          reset_header <= 1;
        end
      else
        begin
          RAM_RADDR <= RAM_RADDR + 1;
          RAM_WE <= !CSB;
          if(RAM_WE)
-           RAM_WADDR <= RAM_WADDR + 1;
-         header <= {header[46:0], TDI};
+            RAM_WADDR <= RAM_WADDR + 1;
+          reset_header <=0;
+          //For the next if, the value of reset_header is probed at rising
+          //clock, before "reset_header<=0" is executed:
+          if(reset_header)
+             header <={47'h000000000000, TDI};
+          else
+             header <= {header[46:0], TDI};
          CS_GO <= CS_GO_PREP;
          if (CS_GO && (len == 0))
            CS_STOP_PREP <= 1;



On 19 June 2013 12:19, joosteto <joo...@gm...> wrote:

> > Two problems:
> > - "I had to change a lot more to make it work" doesn't sound good. Please
> >   explain the problems or explain why they don't generally apply
>
> Well, all the other changes were to make the original bscan_s3_spi_isf.vhd
> work for my Xilinx ISI 14.5 /  xc3s500e:
>  * Orignial had an emtpy "entity" header; my ISE didn't like that, so I
> added a port definition (with ports list), and removed those signals from
> the signal list.
>  * It apears the original was for a Spartan-3A, as the "BSCAN_SPARTAN3A"
> component wasn't accepted when building for my xc3s500e, so changed it to
> "BSCAN_SPARTAN3"; this change then also meant I had to remove TCK, TMS from
> the port list.
>  * the SPI_ACCESS component wasn't known; simply removing it altogether
> worked.
>
> So non of those changes had any relation to the bug we're discussing here.
>
> > - I have to rewrite your patch for Verilog, so can you explain what
> "header <= (0=> TDI, others=>'0');" does?
>
> It does the same as it did in the original; the Verilog equivalent must be
>  header <= {header[46:0], TDI};
>
> I suppose the full section of the verilog code will be:
> //add one line to the declarations:
>    reg         RAM_WE = 0;
> //and then, in the last process
>    always @(posedge DRCK1 or posedge rst)
>      if (rst)
>        begin
>           CS_GO <= 0;
>           CS_STOP_PREP <= 0;
>           RAM_WADDR <= 0;
>           RAM_RADDR <=0;
>           RAM_WE <= 0;
> //add one line:
>           reset_header <= 1;
>        end
>      else
>        begin
>           RAM_RADDR <= RAM_RADDR + 1;
>           RAM_WE <= !CSB;
>           if(RAM_WE)
>
>             RAM_WADDR <= RAM_WADDR + 1;
> //change:
>           reset_header <=0;
>           //I assume in Verilog the next if statment also tests
>           //the value of reset_header at time of clock, so it will test
> true
>           //the first clock after a reset:
>           if(reset_header)
>             header <=48'h000000000000;  //is this how verilog sets all
> bits to 0?
>           else
>             header <= {header[46:0], TDI};
> //end change
>           CS_GO <= CS_GO_PREP;
>           if (CS_GO && (len == 0))
>             CS_STOP_PREP <= 1;
>        end // else: !if(CAPTURE || RESET || UPDATE || !SEL1)
>
>
>
> On 19 June 2013 11:49, Uwe Bonnes <bo...@el...
> > wrote:
>
>> >>>>> "joosteto" == joosteto  <joo...@gm...> writes:
>>
>> ...
>>     joosteto> I actually proposed two fixes (maybe I sent too many emails
>> to
>>     joosteto> the list...), the second was to fix the scan*.vhdl FPGA
>> code,
>>     joosteto> and reset the header data whenever it sets have_header to 0.
>>
>> Probably other thing draw my attention.
>>
>>     joosteto> The advantage of that fix is that old scan*.bit files will
>>     joosteto> still work (just not with the 59a6 data), and no fix to the
>>     joosteto> .cpp files need to be applied.
>>
>>     joosteto> Here's the relavant part of my email from june the 6th again
>>     joosteto> (reworded):
>>
>>     joosteto> Another (more backward compatible) fix would be making the
>>     joosteto> bscan code reset the read header each time it sets
>>     joosteto> "have_header<='0'".
>>
>>     joosteto> I modified my bscan_s3_spi_isf.vhdl as described below (with
>>     joosteto> the old 59a659a6 magic); and now I can upload files with
>> 59a6
>>     joosteto> in them (and any other data I tried).
>>
>>     joosteto> Here's my bscan_s3_spi_isf.vhdl:
>>     joosteto>
>> http://tech.komputilo.org/images/1/12/Bscan_s3_spi_isf-reset.vhdl
>>
>>     joosteto> The relevant part (I had to change a lot more to make it
>> work
>>     joosteto> for my xcs3s500e FPGA) of the patch is:
>>
>> Two problems:
>> - "I had to change a lot more to make it work" doesn't sound good. Please
>> explain the problems or explain why they don't generally apply
>> - I have to rewrite your patch for Verilog, so can you explain what
>> "header <= (0=> TDI, others=>'0');" does?
>>
>> Bye
>>
>> --
>> Uwe Bonnes                bo...@el...
>>
>> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
>> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>>
>
>

Re: [Xc3sprog-users] bscan 59a6 bug

[joosteto <joo...@gm...>]

Ah, forgot one bit!
The code I sent before forgot to write the TDI after a reset.

So this should be better (not tried to build, have no access to an ISE at
the moment)

//add one line to the declarations:
   reg         RAM_WE = 0;
//and then, in the last process
   always @(posedge DRCK1 or posedge rst)
     if (rst)
       begin
          CS_GO <= 0;
          CS_STOP_PREP <= 0;
          RAM_WADDR <= 0;
          RAM_RADDR <=0;
          RAM_WE <= 0;
//add one line:
          reset_header <= 1;
       end
     else
       begin
          RAM_RADDR <= RAM_RADDR + 1;
          RAM_WE <= !CSB;
          if(RAM_WE)

            RAM_WADDR <= RAM_WADDR + 1;
//change:
          reset_header <=0;
          //I assume in Verilog the next if statment also tests
          //the value of reset_header at time of clock, so it will test true
          //the first clock after a reset:
          if(reset_header)
            header <={47'h000000000000, TDI};  //is this how verilog sets
all bits to 0 + TDI?
          else
            header <= {header[46:0], TDI};
//end change
          CS_GO <= CS_GO_PREP;
          if (CS_GO && (len == 0))
            CS_STOP_PREP <= 1;
       end // else: !if(CAPTURE || RESET || UPDATE || !SEL1)



On 19 June 2013 12:19, joosteto <joo...@gm...> wrote:

> > Two problems:
> > - "I had to change a lot more to make it work" doesn't sound good. Please
> >   explain the problems or explain why they don't generally apply
>
> Well, all the other changes were to make the original bscan_s3_spi_isf.vhd
> work for my Xilinx ISI 14.5 /  xc3s500e:
>  * Orignial had an emtpy "entity" header; my ISE didn't like that, so I
> added a port definition (with ports list), and removed those signals from
> the signal list.
>  * It apears the original was for a Spartan-3A, as the "BSCAN_SPARTAN3A"
> component wasn't accepted when building for my xc3s500e, so changed it to
> "BSCAN_SPARTAN3"; this change then also meant I had to remove TCK, TMS from
> the port list.
>  * the SPI_ACCESS component wasn't known; simply removing it altogether
> worked.
>
> So non of those changes had any relation to the bug we're discussing here.
>
> > - I have to rewrite your patch for Verilog, so can you explain what
> "header <= (0=> TDI, others=>'0');" does?
>
> It does the same as it did in the original; the Verilog equivalent must be
>  header <= {header[46:0], TDI};
>
> I suppose the full section of the verilog code will be:
> //add one line to the declarations:
>    reg         RAM_WE = 0;
> //and then, in the last process
>    always @(posedge DRCK1 or posedge rst)
>      if (rst)
>        begin
>           CS_GO <= 0;
>           CS_STOP_PREP <= 0;
>           RAM_WADDR <= 0;
>           RAM_RADDR <=0;
>           RAM_WE <= 0;
> //add one line:
>           reset_header <= 1;
>        end
>      else
>        begin
>           RAM_RADDR <= RAM_RADDR + 1;
>           RAM_WE <= !CSB;
>           if(RAM_WE)
>
>             RAM_WADDR <= RAM_WADDR + 1;
> //change:
>           reset_header <=0;
>           //I assume in Verilog the next if statment also tests
>           //the value of reset_header at time of clock, so it will test
> true
>           //the first clock after a reset:
>           if(reset_header)
>             header <=48'h000000000000;  //is this how verilog sets all
> bits to 0?
>           else
>             header <= {header[46:0], TDI};
> //end change
>           CS_GO <= CS_GO_PREP;
>           if (CS_GO && (len == 0))
>             CS_STOP_PREP <= 1;
>        end // else: !if(CAPTURE || RESET || UPDATE || !SEL1)
>
>
>
> On 19 June 2013 11:49, Uwe Bonnes <bo...@el...
> > wrote:
>
>> >>>>> "joosteto" == joosteto  <joo...@gm...> writes:
>>
>> ...
>>     joosteto> I actually proposed two fixes (maybe I sent too many emails
>> to
>>     joosteto> the list...), the second was to fix the scan*.vhdl FPGA
>> code,
>>     joosteto> and reset the header data whenever it sets have_header to 0.
>>
>> Probably other thing draw my attention.
>>
>>     joosteto> The advantage of that fix is that old scan*.bit files will
>>     joosteto> still work (just not with the 59a6 data), and no fix to the
>>     joosteto> .cpp files need to be applied.
>>
>>     joosteto> Here's the relavant part of my email from june the 6th again
>>     joosteto> (reworded):
>>
>>     joosteto> Another (more backward compatible) fix would be making the
>>     joosteto> bscan code reset the read header each time it sets
>>     joosteto> "have_header<='0'".
>>
>>     joosteto> I modified my bscan_s3_spi_isf.vhdl as described below (with
>>     joosteto> the old 59a659a6 magic); and now I can upload files with
>> 59a6
>>     joosteto> in them (and any other data I tried).
>>
>>     joosteto> Here's my bscan_s3_spi_isf.vhdl:
>>     joosteto>
>> http://tech.komputilo.org/images/1/12/Bscan_s3_spi_isf-reset.vhdl
>>
>>     joosteto> The relevant part (I had to change a lot more to make it
>> work
>>     joosteto> for my xcs3s500e FPGA) of the patch is:
>>
>> Two problems:
>> - "I had to change a lot more to make it work" doesn't sound good. Please
>> explain the problems or explain why they don't generally apply
>> - I have to rewrite your patch for Verilog, so can you explain what
>> "header <= (0=> TDI, others=>'0');" does?
>>
>> Bye
>>
>> --
>> Uwe Bonnes                bo...@el...
>>
>> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
>> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>>
>
>

Re: [Xc3sprog-users] bscan 59a6 bug

[joosteto <joo...@gm...>]

> Two problems:
> - "I had to change a lot more to make it work" doesn't sound good. Please
>   explain the problems or explain why they don't generally apply

Well, all the other changes were to make the original bscan_s3_spi_isf.vhd
work for my Xilinx ISI 14.5 /  xc3s500e:
 * Orignial had an emtpy "entity" header; my ISE didn't like that, so I
added a port definition (with ports list), and removed those signals from
the signal list.
 * It apears the original was for a Spartan-3A, as the "BSCAN_SPARTAN3A"
component wasn't accepted when building for my xc3s500e, so changed it to
"BSCAN_SPARTAN3"; this change then also meant I had to remove TCK, TMS from
the port list.
 * the SPI_ACCESS component wasn't known; simply removing it altogether
worked.

So non of those changes had any relation to the bug we're discussing here.

> - I have to rewrite your patch for Verilog, so can you explain what
"header <= (0=> TDI, others=>'0');" does?

It does the same as it did in the original; the Verilog equivalent must be
 header <= {header[46:0], TDI};

I suppose the full section of the verilog code will be:
//add one line to the declarations:
   reg         RAM_WE = 0;
//and then, in the last process
   always @(posedge DRCK1 or posedge rst)
     if (rst)
       begin
          CS_GO <= 0;
          CS_STOP_PREP <= 0;
          RAM_WADDR <= 0;
          RAM_RADDR <=0;
          RAM_WE <= 0;
//add one line:
          reset_header <= 1;
       end
     else
       begin
          RAM_RADDR <= RAM_RADDR + 1;
          RAM_WE <= !CSB;
          if(RAM_WE)
            RAM_WADDR <= RAM_WADDR + 1;
//change:
          reset_header <=0;
          //I assume in Verilog the next if statment also tests
          //the value of reset_header at time of clock, so it will test true
          //the first clock after a reset:
          if(reset_header)
            header <=48'h000000000000;  //is this how verilog sets all bits
to 0?
          else
            header <= {header[46:0], TDI};
//end change
          CS_GO <= CS_GO_PREP;
          if (CS_GO && (len == 0))
            CS_STOP_PREP <= 1;
       end // else: !if(CAPTURE || RESET || UPDATE || !SEL1)



On 19 June 2013 11:49, Uwe Bonnes
<bo...@el...>wrote:

> >>>>> "joosteto" == joosteto  <joo...@gm...> writes:
>
> ...
>     joosteto> I actually proposed two fixes (maybe I sent too many emails
> to
>     joosteto> the list...), the second was to fix the scan*.vhdl FPGA code,
>     joosteto> and reset the header data whenever it sets have_header to 0.
>
> Probably other thing draw my attention.
>
>     joosteto> The advantage of that fix is that old scan*.bit files will
>     joosteto> still work (just not with the 59a6 data), and no fix to the
>     joosteto> .cpp files need to be applied.
>
>     joosteto> Here's the relavant part of my email from june the 6th again
>     joosteto> (reworded):
>
>     joosteto> Another (more backward compatible) fix would be making the
>     joosteto> bscan code reset the read header each time it sets
>     joosteto> "have_header<='0'".
>
>     joosteto> I modified my bscan_s3_spi_isf.vhdl as described below (with
>     joosteto> the old 59a659a6 magic); and now I can upload files with 59a6
>     joosteto> in them (and any other data I tried).
>
>     joosteto> Here's my bscan_s3_spi_isf.vhdl:
>     joosteto>
> http://tech.komputilo.org/images/1/12/Bscan_s3_spi_isf-reset.vhdl
>
>     joosteto> The relevant part (I had to change a lot more to make it work
>     joosteto> for my xcs3s500e FPGA) of the patch is:
>
> Two problems:
> - "I had to change a lot more to make it work" doesn't sound good. Please
> explain the problems or explain why they don't generally apply
> - I have to rewrite your patch for Verilog, so can you explain what
> "header <= (0=> TDI, others=>'0');" does?
>
> Bye
>
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>

Re: [Xc3sprog-users] bscan 59a6 bug

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

>>>>> "joosteto" == joosteto  <joo...@gm...> writes:

...
    joosteto> I actually proposed two fixes (maybe I sent too many emails to
    joosteto> the list...), the second was to fix the scan*.vhdl FPGA code,
    joosteto> and reset the header data whenever it sets have_header to 0.

Probably other thing draw my attention.

    joosteto> The advantage of that fix is that old scan*.bit files will
    joosteto> still work (just not with the 59a6 data), and no fix to the
    joosteto> .cpp files need to be applied.

    joosteto> Here's the relavant part of my email from june the 6th again
    joosteto> (reworded):

    joosteto> Another (more backward compatible) fix would be making the
    joosteto> bscan code reset the read header each time it sets
    joosteto> "have_header<='0'".

    joosteto> I modified my bscan_s3_spi_isf.vhdl as described below (with
    joosteto> the old 59a659a6 magic); and now I can upload files with 59a6
    joosteto> in them (and any other data I tried).

    joosteto> Here's my bscan_s3_spi_isf.vhdl:
    joosteto> http://tech.komputilo.org/images/1/12/Bscan_s3_spi_isf-reset.vhdl

    joosteto> The relevant part (I had to change a lot more to make it work
    joosteto> for my xcs3s500e FPGA) of the patch is:

Two problems:
- "I had to change a lot more to make it work" doesn't sound good. Please
explain the problems or explain why they don't generally apply
- I have to rewrite your patch for Verilog, so can you explain what
"header <= (0=> TDI, others=>'0');" does?

Bye

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

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

Re: [Xc3sprog-users] bscan 59a6 bug

[joosteto <joo...@gm...>]

Uwe Bonnes wrote:
> joosteto posted a possible cure, however I have not verified yet.
Applying the fix however will void all .bit files we have.

I actually proposed two fixes (maybe I sent too many emails to the
list...), the second was to fix the scan*.vhdl FPGA code, and reset the
header  data whenever it sets have_header to 0.

The advantage of that fix is that old scan*.bit files will still work (just
not with the 59a6 data), and no fix to the .cpp files need to be applied.

Here's the relavant part of my  email from june the 6th again (reworded):



Another (more backward compatible) fix would be making the bscan code
reset the read header each time it sets "have_header<='0'".

I modified my bscan_s3_spi_isf.vhdl as described below (with the old
59a659a6 magic); and now I can upload files with 59a6 in them (and any
other data I tried).

Here's my bscan_s3_spi_isf.vhdl:
http://tech.komputilo.org/images/1/12/Bscan_s3_spi_isf-reset.vhdl

The relevant part (I had to change a lot more to make it work for my
xcs3s500e FPGA) of the patch is:

@@ -34,6 +38,7 @@
     signal RAM_DO: std_logic_vector(0 downto 0);
     signal RAM_DI: std_logic_vector(0 downto 0);
     signal RAM_WE: std_logic := '0';
+  signal reset_header:std_logic:='0';
 begin

     DRCK1_INV <= not DRCK1;
@@ -142,6 +145,7 @@
             -- disable CSB
             CS_GO <= '0';
             CS_STOP_PREP <= '0';
+      reset_header<='1';  --reset header at next rising clock

             RAM_WADDR <= (others => '0');
             RAM_RADDR <= (others => '0');
@@ -157,7 +161,12 @@
                 RAM_WADDR <= RAM_WADDR + 1;
             end if;

+      reset_header<='0';  --make reset_header 0 the next clock
+      if reset_header='0' then
             header <= header(46 downto 0) & TDI;
+      else
+        header <= (0=> TDI, others=>'0');
+      end if;

             -- enable CSB?
             CS_GO <= CS_GO_PREP;



On 19 June 2013 10:55, Uwe Bonnes
<bo...@el...>wrote:

> Hello,
>
> as joosteto <joo...@gm...> pointed out, there are patterns where our
> bscab_spi code fails. joosteto posted a possible cure, however I have not
> verified yet. Applying the fix however will void all .bit files we have.
>
> How should we cope with that situation?
>
> Any opionions?
>
> Thanks
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Xc3sprog-users mailing list
> Xc3...@li...
> https://lists.sourceforge.net/lists/listinfo/xc3sprog-users
>

[Xc3sprog-users] Possible switch to GIT

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

Hello,

sourceforge changed their server setup in the last month and so xc3sprog
location changed. I used "git svn" to access the old repository and now I
would need a new checkout. What about switching the repository to git
instead?

Any opinions?

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

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

[Xc3sprog-users] bscan 59a6 bug

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

Hello,

as joosteto <joo...@gm...> pointed out, there are patterns where our
bscab_spi code fails. joosteto posted a possible cure, however I have not
verified yet. Applying the fix however will void all .bit files we have.

How should we cope with that situation?

Any opionions?

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

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

Re: [Xc3sprog-users] Can you program the Dragon PCI FPGA with this software?

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

>>>>> "Jovan" == Jovan Trujillo <jov...@gm...> writes:

    Jovan> Hi everyone, Has anybody tried programming this board:
    Jovan> http://www.knjn.com/FPGA-PCI.html with xc3sprog? What would I
    Jovan> need to do to get it to work?

You need to identify the chip used for USB communication and the way it is
connected to the JTAG chain. With the board, you should have the
documentation.


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

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