On Apr 2, 9:06=A0am, Uwe Bonnes <b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:
> Andy Ross <andy.ross...@gmail.com> wrote:
> > emeb wrote:
> > > I'm pretty sure that the Digilent 8051 code is loaded from flash at
> > > power-up and this process reloads new open-source code from USB
> > > which is lost at the next power down or reset. You should be OK
> > > using this with Adept as long as you cycle power.
> > Yes, that's exactly right. =A0The FX2 chip has a built-in loader that
> > works irrespective of what the boot configuration was. =A0Once the
> > device reboots (you have to unplug it from the USB bus, it's not
> > controlled by the FPGA power switch) it restreams its firmware from
> > the I2C EEPROM and acts like a Digilent device again.
>
> I have a modified version of the USRP FX2 firmware and a modified version=
 of
> xc3sprog(Linux) to directly programm Spartan3/XCF and XC95XL via a
> Bit/Jedecfile. Probably the firmware needs some adapations, as the JTAG P=
ins
> will differ. However I don't have a Digilent adapter available, to someon=
e
> interested must do this changes by himself.
>
> Some nearly recent verison is uploaded to the patches section of
> xc3sprog at sourceforge.
>
> --
> Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-dar=
mstadt.de
>
> Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

I've got one of the low-end Digilent USB/JTAG cables that uses the FX2
chip at the JTAG end. If you could point me at your app source I'd
like to give this a try.

Eric

Andy Ross wrote:

> 
> Hopefully this will help other newbies with the learning curve.  Let
> me know if something doesn't work, or if there are questions.





< bitgen ${PROJ}_par.ncd $PROJ.bit $PROJ.pcf
---
 > bitgen $PROJ_par.ncd $PROJ.bit $PROJ.pcf

On Apr 10, 2:51=A0pm, John Eaton <nos...@spam.com> wrote:
> < bitgen ${PROJ}_par.ncd $PROJ.bit $PROJ.pcf
> ---
> =A0> bitgen $PROJ_par.ncd $PROJ.bit $PROJ.pcf

Good catch.  Fixed in the tarball (didn't bother with versioning).

FWIW: your diff order is swapped.  And, dude: non-unified diff output?
Raised in a barn?

Andy

Andy Ross wrote:
> On Apr 10, 2:51 pm, John Eaton <nos...@spam.com> wrote:
>> < bitgen ${PROJ}_par.ncd $PROJ.bit $PROJ.pcf
>> ---
>>  > bitgen $PROJ_par.ncd $PROJ.bit $PROJ.pcf
> 
> Good catch.  Fixed in the tarball (didn't bother with versioning).
> 
> FWIW: your diff order is swapped.  And, dude: non-unified diff output?
> Raised in a barn?
> 
> Andy

Hate to show my ignorance but what is "unified diff output"? All I did 
was to diff the fixed script against the original.

I don't have a nexys2 board but will try to get this working with a 
basys and a nexys board.


John Eaton

On Sat, 11 Apr 2009 12:49:07 -0700, John Eaton <n...@spam.com>
wrote:

>Andy Ross wrote:
>> On Apr 10, 2:51 pm, John Eaton <nos...@spam.com> wrote:
>>> < bitgen ${PROJ}_par.ncd $PROJ.bit $PROJ.pcf
>>> ---
>>>  > bitgen $PROJ_par.ncd $PROJ.bit $PROJ.pcf
>> 
>> Good catch.  Fixed in the tarball (didn't bother with versioning).
>> 
>> FWIW: your diff order is swapped.  And, dude: non-unified diff output?
>> Raised in a barn?
>> 
>> Andy
>
>Hate to show my ignorance but what is "unified diff output"? All I did 
>was to diff the fixed script against the original.
>
>I don't have a nexys2 board but will try to get this working with a 
>basys and a nexys board.
>
>
>John Eaton

http://en.wikipedia.org/wiki/Diff#Unified_format

On Mar 30, 4:46=A0pm, Andy Ross <andy.ross...@gmail.com> wrote:
> I recently bought a Digilent Nexys 2 board, and after a few days of
> research got to the point where I can successfully program it over USB
> from a Linux host without the use of a separate (and expensive!) JTAG
> interface...

Hi, Andy --

Thanks for posting this Perl script, Andy -- it makes a nice self-
documenting summary of the hoops to jump through.  I've been playing
with the same board as well over the past week or so, attempting to
build a C API that's just enough to support standalone PC-hosted FPGA
apps (data acquisition, SDR, and so forth).  I'm working in Win32 but
there's nothing really OS-specific about it.

The API is actually running OK in a limited fashion (see below), and
is relatively short and to the point:

   int N2LoadFX2Image(CCyUSBDevice *device, char *image, int
image_bytes)
   void N2SetFX2ClockMHz(CCyUSBDevice *device, int MHz)
   int N2LoadSpartan3EImage(CCyUSBDevice *device, char *image, int
image_bytes)

The whole thing lives in just two C files -- fx2_ctrl.c which sdcc
turns into an image file suitable for passing to the N2LoadFX2Image()
function, and nexys2.cpp which is the USB-over-JTAG host API.

An application built with this API doesn't need any external projects,
libraries, scripts, tools, shells, or whatever.  I'm using the stock
CyUSB driver from the Cypress FX2 devkit, which can talk to the Nexys2
if you cut the JP6 trace and install a jumper to disable the EEPROM
that the FX2 normally boots from.  (I had problems trying to override
the EEPROM code, hence the need for the jumper to switch between "API
mode" and "Adept mode," and it didn't seem vital to pursue the issue
too far given the jumper pads provided by Digilent.)

I also have it working under the older EzUSB driver from the same
devkit; presumably it wouldn't be hard to support libusb as well.

So: I'm fine with putting the API and its source out there for anyone
else who wants to play with it, but I'm hoping to deal with one
troubling issue first.  Currently, JP9 has to be in the ROM (Master
Serial/Platform Flash) position, not the JTAG position, and you have
to use -StartupClk:CClk to build the .bit file.  If you set JP9 to
JTAG and use -StartupClk:JtagClk, the .bit upload fails, and the DONE
light never comes on.  I don't feel comfortable releasing the code
until I have a better understanding of what's up with that.  My
questions come down to these:

1) Regardless of the M2:M0 bits resulting from a given JP9 setting,
I'm still considered to be using "JTAG configuration" as long as I'm
sending the .bit image via the JTAG TAP state machine, correct?

2) Assuming that's true, I understand that the M2:M0 bits are ignored
during a boundary-scan upload... but then, why does -StartupClk:CClk
work OK for JTAG configurations if, and only if, M2:M0 are set for
Master Serial mode (000)?  Page 250 of Xilinx's UG332 v1.5 suggests
that it won't work at all -- it's JtagClk or nothing if you're
performing JTAG configuration.

3) Most, but not all, of the Xilinx documentation says that a a
successful upload with the JTAG jumper setting and -StartupClk:JtagClk
requires a JSTART instruction followed by >=3D 12 TCK ticks after
the .bit image is transferred.  I've spent quite a bit of time trying
to get JSTART to do something, following the guidelines in various
Xilinx manuals, with no luck.  No state-machine sequences I've tried
have yielded a successful configuration with JP9=3DJTAG/-
StartupClk:JtagClk.

The JSTART thing bugs me because of how flaky its documentation is.
In fact, newer versions of XAPP058 no longer mention JSTART at all,
while various open-source USB-JTAG implementations still use it with
various chips.   I'm fine with including a readme note that says "You
must set JP9 to the 'ROM' position and use -StartupClk:CClk," but
clearly there's *some* way to use the JTAG/StartupClk:JtagClk
technique, since Adept can use it.  Any opinions on whether it's safe/
smart to ignore this issue?

Finally, apologies for hijacking your Linux-specific thread with some
lower-level minutiae, but this seems to be a good place to catch the
attention of people who're more familiar with Spartan3E config
topics.  Would be nice to hear from anyone with a clue stick.

> Hopefully this will help other newbies with the learning curve. =A0Let
> me know if something doesn't work, or if there are questions.

More than you bargained for, I'm sure!

-- john, KE5FX

John,

 Not a detailed answer ( I don't have a NEXSYS2 board ), but perhaps
some clues you haven't found yet, in these old posts summarizing
similar JTAG vs. mode pin vs. PROM conflicts:

JTAG/mode/PROM configuration problems:
  http://groups.google.com/group/comp.arch.fpga/msg/5b79a99163d5282e
  http://groups.google.com/group/comp.arch.fpga/msg/b06ca9faf716c347

Digilent Spartan3 ( original, non-E ) JTAG download issues:
  http://groups.google.com/group/comp.arch.fpga/msg/8b2144041295cd24
  http://groups.google.com/group/comp.arch.fpga/msg/63162b2622926fa9


Random Thoughts:

>
> If you set JP9 to JTAG and use -StartupClk:JtagClk, the .bit upload fails,
> and the DONE light never comes on.
>
 Try doing an extra JTAG operation after config ( e.g. read the PROM
ID )

 Does JTAG configuration work properly when using :
  - Digilent's Adept suite through the USB config port ?
  - an external Xilinx ( USB/parallel ) JTAG cable through IMPACT ?

>
> 1) Regardless of the M2:M0 bits resulting from a given JP9 setting,
> I'm still considered to be using "JTAG configuration" as long as I'm
> sending the .bit image via the JTAG TAP state machine, correct?
>

 As mentioned in the above links, there are longstanding (and
regularly
recurring ) issues involving dueling configuration modes interrupting
one another and fouling up the configuration and/or FPGA startup
process.

 Is there a spare I/O bit on the micro to force the FPGA mode pins
to JTAG during a JTAG download ?

>
> why does -StartupClk:CClk work OK for JTAG configurations if,
> and only if, M2:M0 are set for Master Serial mode (000)?
>
 Master mode is the only one that normally generates CCLK from the
FPGA;
CCLK might be turning back on after the JTAG config completes, giving
the
FPGA the extra clocks it needs to finish startup.

>
> The JSTART thing bugs me because of how flaky its documentation is.
>
 Have you searched the Answer Records for JSTART and JPROGRAM ?

Xilinx search engine tips:
>
>  - Go to the Xilinx webpage
>  - click the "advanced search" link (below the search button)
>  - enter your search terms
>  - check what to search ( answer records, archive, etc. )
>
> Note that although the search terms are filled in again
> on the results page, that is just the plain-old-search,
> not the advanced one; you have to back up to the advanced
> search page again to properly modify your search terms.
>

have fun,
Brian