New Release!

[Chris McClelland]

OK, after a lot of silly delays, I finally have a beta-test version of
the new FPGALink release. I still need to update the documentation and
do a load more testing, but I'm reasonably happy with it. If you can
spare the time, please give it a go and let me know if you run into
problems and/or bugs!

New in this release:
* Completely redesigned modular HDL build infrastructure.
* Moved to quad-buffered endpoints on FX2LP, giving ~43MiB/s.
* Support JTAG on FX2LP port A in addition to C & D.
* Switch to libusb-1.0 APIs for better performance and future work.
* Added checksum & throughput option to flcli.
* Added Windows x64 build.
* Separated the two ARM ABIs: armhf and armel.
* Support use of DeviceID to distinguish between several devices.
* Add support for 1Mib EEPROMs.
* Add AVR build for atmega32u2 (e.g minimus32).
* Made port access protocol saner (can access individual bits now).
* Added support for ~$40 custom OSHW Spartan-6 FPGA board.

Platforms:
* Linux x86, x64, armel, armhf, ppc.
* Windows x86, x64.
* MacOSX x86, x64.

Download:
http://www.swaton.ukfsn.org/bin/fpgalink-20121216/fpgalink-bin.tar.gz

API docs:
http://www.swaton.ukfsn.org/bin/fpgalink-20121216/api/libfpgalink_8h.html

The HDL build infrastructure change is one of the most significant
changes, and stems from the fact that the current Makefile-based
approach was getting unwieldy, and the layout did not lend itself to
interface abstraction (i.e using the same "application" HDL in several
different platforms/contexts) or modularity (separation of features into
separate GitHub repositories), instantiation of vendor IP (e.g invoking
COREgen and QMegaWiz), or behavioural testing. Unfortunately it does
require a Python interpreter, but since that comes as standard on Linux
and it's a straightforward installation on Windows, I hope that's not a
showstopper for anyone. I will naturally write a proper user manual for
it, but in the meantime I posted a brief introduction here:
https://plus.google.com/116069803225736590944/posts/eG4dXHg9hue

The design for the custom Open-Source Hardware FPGA board I mentioned is
here: https://github.com/makestuff/lx9

Unfortunately a couple of minor board-level modifications are needed for
it to work with this sofware/firmware release; I will update the
schematics and layout soon. Here are some relevant posts about it:

https://plus.google.com/116069803225736590944/posts/HQ2XZ7K1a2x
https://plus.google.com/116069803225736590944/posts/Pg59sVoj8Fq
https://plus.google.com/116069803225736590944/posts/Ud7ZdHiXFAH

Have fun!

Chris

[David glover]

Hello Chris,

Thanks again for this great resource. I know it is just a beta at the moment, and documentation
is still on the way, but I couldn't find any references to determine how to use the Device ID when using multiple devices. Currently I am using your previously suggested option of changing the VID:PID after powering each board and it works, but if the Device ID selection is available I would like to switch to that.
I thought it would be in flOpen, but did not see any place to add it, unless it is just added to the vid:PID string?

I am also looking forwards to trying the new build infrastructure when I get a chance, hopefully by this coming weekend.

Thanks,
David

Sent from my iPad

> --
> You received this message because you are subscribed to the "FPGALink Users" mailgroup (see http://www.makestuff.eu/wordpress/software/fpgalink/).
>
> To post to this group, send email to fpgalin...@googlegroups.com
> To unsubscribe from this group, send email to
> fpgalink-user...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/fpgalink-users?hl=en
>
>
>

[Chris McClelland]

Hi David,

You can just plug in the first board and append a nonzero four-digit hex
number to the target VID:PID, like this:

flcli -i 04B4:8613 -v 1D50:602B:0002 ...

You can then connect the second board and append a different ID:

flcli -i 04B4:8613 -v 1D50:602B:0003 ...

You can now refer to each board:

flcli -v 1D50:602B:0002 ... # first board
flcli -v 1D50:602B:0003 ... # second board

Leaving the DeviceID off is the same as explicitly setting it to zero,
which has a special meaning. In this case the library won't consider the
DeviceID when matching, so it will just connect to the first device with
matching VID:PID which it discovers, irrespective of its DeviceID.

I have set the DeviceID of the pre-built AVR firmware to 0001, which is
why I start from 0002 here. Also, the 1D50:602B VID:PID has now been
uniquely assigned to FPGALink devices by those nice people at OpenMoko.

Chris

[David glover]

Thanks Chris,

I will try that out this afternoon. I already did a build of my hardware with the new hdl code, but have not connected to the boards yet. I have 2 boards now to test together. Will try all 9 after the Holiday break in two weeks.

Thanks,
David


Sent from my iPad

[Kellen]

Hi Chris, 

I'm very pleased to be able to participate in this fpgalink's project.

This is very good scheme for FPGA and USB communicate. 

Now, I'm run the new version of fpgalink-20121216.

I'm working in x86 system and run at Atlys board,so use the \win.x86\rel command to download hdl example ( \libfpgalink-20121216\hdl\apps\makestuff\swled\fifo\verilog\csvf\fx2all-atlys.csvf ).

But it can't download now and rel command show the message is:

Attemping to open connection to FPGALink device 1443:0007...

Loading firmware into 1443:0007...

flLoadStandardFirmware(): usbOpenDevice(): LIBUSB_ERROR_ACCESS

It's seem to be the USB driver does not match?

The new release version use libusb1.0 API,so must be use Libusb1.0 drive?

I use the libusb-win32 can drive previous fpgalink version, but new version can't work.

So, How to fix this problem?

Thanks.

BR,

Kellen

Chris McClelland於 2012年12月17日星期一UTC+8上午8時55分32秒寫道：

[Peter Stuge]

Hi Kellen,

Kellen wrote:
> Attemping to open connection to FPGALink device 1443:0007...
> Loading firmware into 1443:0007...
> flLoadStandardFirmware(): usbOpenDevice(): LIBUSB_ERROR_ACCESS
>
> It's seem to be the USB driver does not match?
> The new release version use libusb1.0 API,so must be use Libusb1.0 drive?
> I use the libusb-win32 can drive previous fpgalink version, but new version

> can work.

>
> So, How to fix this problem?

You are exactly right: when using libusb-1.0 on Windows the
WinUSB.sys kernel driver from Microsoft is currently required.

There is an open ticket[1] for libusb to also support libusb0.sys
from the libusb-win32 project, and while there is an early
implementation which somehow functions that code needs more work
before being included in libusb.

Meanwhile, I recommend using the zadig.exe[2] tool from the libwdi
project to easily switch drivers for your device. Note that in more
recent versions they've chosen to support Windows XP only with a
separate build of the tool[3].

I'm the libusb maintainer, so please let me (or Trac on
https://libusb.org/ ) know about any problems you run into,
regardless of platform. The Windows support isn't nearly as
good as the Linux, Mac OS X, or BSD support but I believe that
FPGALink will work well once you install WinUSB.sys.

Chris, if you're distributing a libusb-1.0.dll then please use libusb
git source rather than the 1.0.9 release. Another release in on the
way, and I'll make sure to have some easy Windows binaries for that.


Kind regards

//Peter


[1] https://libusb.org/ticket/48
[2] http://sourceforge.net/projects/libwdi/files/zadig/zadig_v2.0.1.160.7z/download
[3] http://sourceforge.net/projects/libwdi/files/zadig/zadig_xp_v2.0.1.160.7z/download

[Chris McClelland]

Peter,

This beta release actually bundles libusbx-1.0.14, which comes from the
binary download (i.e I don't build it myself).

Kellen,

Peter's right, in general you should use Zadig: this gives you a choice
of three different driver back-ends. However, as a short-cut I made a
driver bundle for the VID:PIDs commonly used with FPGALink. This will
install a libusbK driver:

http://www.swaton.ukfsn.org/bin/libusbx-windows/

I don't have recent benchmark numbers, but I seem to recall libusbK
gives the best throughput (~38MiB/s on my PC; YMMV).

Chris

[fitzsnaggle]

I was planning on printing one of the lx9 boards. Can the changes to the board you mention be made easily on the board after it has been printed, or should I wait for the new schematic? I'm guessing it is some of the connections for the ports. Can you tell which ones if they can be added easily?

[Chris McClelland]

fitzsnaggle,

I actually have a few spare LX9 prototype PCBs if you want one. I will
only charge for the postage. The same goes for anyone else who's
interested in the LX9 board. You should aim to pay ~$11 for the FPGA, ~
$4 for the FX2LP, ~$1.50 for the EEPROM, ~$3 for the SDRAM plus ~$1 for
the various passives & connectors.

There are two mods necessary:

1) Use the EP2OUT and EP6IN FIFO pair (which can be quad-buffered)
rather than the EP6OUT & EP8IN FIFO pair (which can only be
double-buffered).

Connect fx2FifoSel_out on the FPGA (pin 104) to FIFOADR1 on the FX2LP
(pin 45) rather than FIFOADR0 (pin 44), and connect FIFOADR0 (pin 44) to
ground.

To achieve this it's necessary to scrape the soldermask off a 5mm length
of track, then cut it and solder wires to the exposed copper on either
side of the cut, and omit the pull-up R1:

http://i.imgur.com/U8CSt.jpg

http://i.imgur.com/4dlRV.jpg

(white arrow marks the track-cut)

2) If you want to use a 1Mib (128KiB) EEPROM, it's necessary to lift the
leg of pin 3 and connect it to 3.3V rather than solder it down onto the
board (pin 3 pad is grounded). Actually, the necessary Microchip
24LC1025 part is not common and quite expensive (~$3), and it's only
really necessary if you want the board to boot an FPGA design on
power-up independently of a host PC. The board will accept the cheaper
(~$1.50) and more common 512Kib (64KiB) EEPROMs without modification.

The board is home-solderable provided you have a decent soldering
station with an SMD tip. I ruined a couple of boards and FPGAs before I
learned how to do the drag-soldering method on the 0.5mm-pitch FPGA.

Chris

[fitzsnaggle]

I've got the board assembled but I am getting LIBUSB_ERROR_BUSY whenever I try to run one of the examples:

./flcli -i 04B4:8613 -j A7031 -v 04B4:8613:0002 -x top_level.xsvf
Attempting to open connection to FPGALink device 04B4:8613:0002...
Loading firmware into 04B4:8613...
flLoadStandardFirmware(): usbOpenDevice(): LIBUSB_ERROR_BUSY

This is an attempt to run the readback example, but other examples have failed with the same error.

The device is detected and I registered the vendor id and product id in  /etc/udev/rules.d/10-local.rules as indicated in the manual. I followed all of your instructions concerning modifying the board to use different endpoints. I also shorted j1 and jumped the others correctly. Can I rule out a hardware error?

Is the board stuck configuring? Do I need some kind of hard reset, or to send a particular -j argument? I have tried restarting, and using two computers (both with 32 bit linux). I have restarted udev and left one usb rule in the /etc file just in case.

Not sure if this is significant, but I had a similar trouble getting my nexys2 to load the examples. However, I got it to work by using the -v argument with the ids (eg. 1443:0005:0002). I tried that with this board to no avail.

[Chris McClelland]

That error sounds like something else in the system has grabbed the
USB device. The most common cause is the USB device has been
automatically allocated by a virtualization platform (e.g on VMware,
VirtualBox, Parallels) on behalf of a running guest OS and is
therefore no longer available for use by the host OS.

Another likely possibility (specifically for Linux systems and the
default FX2LP device 04B4:8613) is the usbtest.ko kernel module, which
appears to be provided with most modern Linux distributions, and will
auto-load when a vanilla FX2LP is connected. You can avoid this by
blacklisting the usbtest.ko kernel module: create /etc/modprobe.d/
blacklist-custom.conf and add a single line "blacklist usbtest" to it,
then reboot (there are ways to avoid the need for reboot but it's the
simplest way).

Chris

[fitzsnaggle]

Right on! Work like a charm. The sdram example is running well. I had to use the ids again. It seems like if you try to switch examples the ids will hold the state of previously loaded ones.

Can you explain when the -j option is used? Is it always used on the lx9? Do you always use 'A7031'?

[Chris McClelland]

You can think of the flcli options as being grouped into independent
phases: (1) Firmware load, (2) FPGA program and (3) FPGA interaction.
The -v, -i and -j options occupy the first phase. In this phase, a
connection is made to the VID:PID given by -i, and then a firmware
binary prepared by applying appropriate patches to set the
renumeration VID:PID (given by -v) and to choose which port lines to
use for JTAG (given by -j). Finally the prepared firmware is loaded
and the device renumerated. The -j A7031 means literally "this board
uses PA7, PA0, PA3 and PA1 for JTAG". It will always be the same for a
given PCB (unless you physically rewire the JTAG connections by
cutting tracks etc).

You only need to repeat phase 1 when you power-cycle the board. In
your case, since you're using a custom LX9 PCB anyway, you can just
load that firmware into your board's EEPROM so it will power on ready
to accept phase 2 commands (for FPGA programming). There is an example
of how to do this in the python example directory[1]. Note that this
example also bootstraps an FPGA design and does some I/O as part of
the boot process, which you probably don't need: you can omit the
xsvfFile parameter to the flFlashStandardFirmware() function.

[1]https://github.com/makestuff/libfpgalink/blob/master/examples/
python/flashFirmware.sh