1. The software package
1.1. Contents
Q: What exactly do I find in the package (Unix and
Windows)?
A: The actual content of the packages available on the web
are shown in another page.
However, here is a summary description:
- Parts of the documentation (the rest of the documentation is
available separately on the download page).
- PamDC (C++ design library) headers and library file.
- PamRT (run-time library) headers library file, utilities and
sources.
- Device Driver binaries and sources.
- Design and run-time samples.
1.2. Installation
Q: How do I install the Unix package on my Alpha
workstation ?
A: The kit is distributed as a compressed tar of a
standard Tru64 Unix setld kit. Unpack the archive to an empty
directory and run the command "setld -l ." in that directory. Note
that setld must be run as root.
Q: How do I install the PC package on my machine?
A: Get the pamnti.exe (or pamnta.exe for
the Alpha version) auto-extractible file and launch it either by
double-clicking on it in an explorer or a file manager window, or by
typing its name on the command-line. A wizard will help you go
through the complete installation. The default options install all
the components in default directories. You can choose which
components you want by checking them in the list. Depending on your
choice, some files will be installed in some user-chosen directory
(samples, source code, executables), and the others will be
installed in your standard include and library directories (the
installation program tries to guess them from the environment
variables). It should be OK if you have Visual C++ 4.0 installed on
your system. The installation process modifies the system-wide
PATH variable to allow the user to call the different utilities
directly on the command line. If the option is chosen (it is by
default), the device driver gets installed during the process, and
the installer tries to open a board on the system to validate the
setup.
Q: How do I upgrade the PC package on my machine?
A: Follow the installation procedure above. The installer
will propose you to uninstall automatically the previous version to
avoid conflicts. This is the recommanded way to proceed. The
uninstallation is harmless for the files added by the user, so it
will not remove any data which were not part of the kit.
1.3. Uninstallation
Q: How do I uninstall the Unix package from my Alpha
workstation ?
A: Any subset can be removed by setld with "-d" option
followed by the subset name. "setld -i" lists all subsets on the
machine.
Q: How do I uninstall the software kits from my PC?
A: If you have Windows 95 or Windows NT 4.0 or later, go
to the Add/Remove Programs applet in the Control Panel, and choose
Pam Kits. On all the PC systems, an Uninstall icon is added to the
"Pam Software Kits" menu or program group, and can be used to start
the uninstallation process.
Q: How do I prevent the driver on NT from starting
automatically?
A: When there is no board in the system, at boot time, you
will have a message saying that at least one service could not
start. This is because the driver refuses to load itself if there is
no board plugged into the system. By the way, if you just want to
stop the driver, or restart it, go to the Devices applet of the
Control Panel, find the PCI Pamette item, and Start or Stop it (NB:
the driver is dynamically loadable/unloadable, so you are not
obliged to start it automatically at boot time, and you can start
and stop it as much as you want). You can also prevent it from
loading itself at boot time, or re-enable this feature by pressing
the Startup button on the Devices applet for hte PCI Pamette, and
choosing either Automatic or Manual.
2. Supported platforms
2.1. CAD tools
Q: Which tools do I need, on which platform?
A: You should first note that you can use the tools you
prefer, on the platform you prefer, as long as they provide you with
.rbt (Xilinx raw bitstream format) files. You will then need to
package them with a command-line application provided in our
run-time tools (PamRT). The two standard ways to build designs are
either to use any commercial CAD system, with any input type
(schematics, HDL), which compile to Xilinx chips, or to use our C++
front-end (PamDC) and Xilinx command-line tools to place and route.
Depending on your design tools option, you will be constrained on
the platform you can use. Please also note that the platform on
which the board is installed does not need to be the same as your
CAD system platform.
2.2. PamDC
Q: On which platforms does PamDC work?
A: PamDC is available and tested on Tru64 Unix/Alpha,
Windows NT/Intel, Windows 95/Intel (32 bit code only) and Windows
NT/Alpha. All the versions are identical and released at the same
time. There is only one Windows version, wich is a win32 library,
and which works on both Windows NT and Windows 95 on Intel machines.
It is compiled and tested with Microsoft Visual C++ 4.0. The
software kit contains the source code of PamDC which permits it to
be used with more recent versions of Microsoft Visual C++.
An unsupported source code kit for Linux is also available.
2.3. Xilinx Tools
Q: Which version of the Xilinx back-end tools can be used
to compile circuits for the PCI Pamette board?
Note: The links
Alliance
Series or
Foundation Series are no longer available
A: The
Alliance
Series or
Foundation Series (a.k.a. M1) tools from Xilinx are capable of
compiling designs for all the kinds of circuits used on PCI Pamette
boards (if using PamDC, we only rely on the backend tools which are
common to Alliance and Foundation). Alternatively, one can use XACT
V5.2.1/6.0.1 (the last release) to compile the boards based on
XC4000E circuits only.
Q: On which platforms are the Xilinx tools available?
A: They are available on some Unix systems, and on PC
(Windows and Windows NT), see the
Xilinx site for more information. Note that the old XACT tools
are supported on MS-DOS and Windows 3.x. Running them under NT is
possible but difficult and the performance are not that good. There
is a nice Xilinx
Support page on using XACT on Windows NT that contains more
information on this issue.
2.4 PamRT, the Device Driver and the Board
Q: On which platforms do PamRT and the Driver work? On
Which platform can I put the PCI Pamette?
A: The PCI Pamette can be pugged in any system with a PCI-compliant
32-bit or 64-bit bus and a free full-size slot. Of course, to
actually use it, you need a driver and a run-time library. We have
developed and ported a Device Driver and a run-time library (PamRT)
for the following systems: Tru64 UNIX/Alpha, Windows NT/Intel,
Windows NT/Alpha. The Windows NT version is a win32 library,
compiled and tested with Visual C++ 4.0. It requires Windows NT 4.0
or later. PamRT could work on Windows 95, but we have no plan to
port the driver to this system. Note that if you need it and have
experience in Windows 95 device drivers, we are willing to help you
port it, maintain it, and make it available to other users. Please
contact me for more
details. On the Unix kit, the device driver has been developed for
Tru64 UNIX V4.0 or higher and has been tested up to V4.0E. The
unsupported Linux source code kit contains a driver for Linux.
3. The Run-Time Library and the Hardware Interface
Q: What is the device name of the PCI Pamette?
A: The device name is platform dependent, and can be
changed by the user, but by default, it is /dev/pam# on Tru64
Unix and \\.\PAM# on Windows NT where # corresponds to
the number of the board. On a system containing only one PCI Pamette,
this number is 0. On a multi-PCI Pamette system, the first board is
numbered 0, and the other ones in sequence 1, 2, 3... Note that the
device name is used only by the PamOpen function, and one can
pass NULL as the device name argument. In that case, PamRT chooses
the standard default device name on the platform (i.e. /dev/pam0 or
\\.\PAM0). This is how we use PamOpen in the Samples, because the
code is identical across platforms.
Q: How do I access the PCI Pamette registers from my
user-mode code? How do I talk to these registers in the hardware?
A: When PamOpen is used, it returns a Pam-typed
value, which is actually a pointer to the beginning of the board
address space mapped in the application virtual address space. You
can thus cast this value into a pointer (usually a pointer to an int),
and access the board through that pointer. Among the board's CSRs,
one is particularly useful to user applications: the 32-bit wide
link register (seePamRegs.h). The low 16 bits from the pif to
the user area, the high 16 bits are from the user area to the pif.
When you write to link register (from software) the high 16 bits
must be zero (there are some hidden config bits in the high 16 bits
that you don't want to set). The low 16 bits that you write will
appear on EBus[0..15] When you read the link register (from
software) the high 16 bits contain the current value of EBus[16..31]
the low 16 bits are whatever you last wrote to the link register.
The link resgister is accessible in the default mode of the PCI
interface. There are other modes that allow high-performance data
transfers. Please refer to the PIF documentation for more
information on the different modes.
Q: Which privileges do I need to have to use the PCI
Pamette board?
A: Most of the standard tasks can be done by simple users.
However, you need to have special privileges to perform certain
actions like installing new software, upgrading the firmware,
changing the serial number, setting up a DMA... On a Unix system,
you need to be super-user (root) to perform these actions.
On Windows NT, you will need to have two special privileges: the
Memory Locking privilege to lock memory (for DMAs) and the Driver
Loading privilege for all the other privileged operations. Note that
the first privilege is not granted to anyone by default, whereas all
the administrators have the second one by default. In order to
grant/revoke privileges for specific users, go to the User Manager,
in Policies/User Rights; check the "Show Advanced User Rights" mark,
choose your privilege and manage the list of users associated to it.
Q: How do I use PamRT, and is PamRT multithread safe?
A: To use PamRT, you'll need to include its include files,
which should be in your standard compiler include directory. The
PamRT binary code itself is in a shared library, and so you'll need
special link option to use it. You'll need to use libPamRT.so
on Unix on your link line. On Windows NT, the file PamRT.dll
is the actual library and should be in the standard Pam binary path;
you'll need to use PamRT.lib to link your application
against PamRT. This file should have been put in your compiler
library directory by the installer.
On both Unix and Windows NT, PamRT has been compiled with the
multithreading options turned on. You should thus use these same
option for your runtime applications to avoid any conflict with
PamRT. Although PamRT is compiled with the multithreading options,
it is not yet multithread safe, so you should be careful when using
multiple threads.
4. Firmware updates
All communication between the host and PCI Pamette passes through
the PCI interface LCA (PIF). At power-up this chip is configured
from from proms located on the pamette. We refer to contents of
these proms containing the initial PIF configuration as the board
firmware.
Q: How is the firmware prom organized?
A: In fact there are two distinct sets of firmware. The
normal board firmware is kept in Atmel EEPROMs. This firmware may be
upgraded in system. The board also has failsafe firmware in a
socketed Xilinx XC17256D one-time programmable PROM. The prom used
at power-up is determined by the position of the failsafe jumper
located in the top left hand corner of the board. With the jumper
removed or in the off position the PIF configuration is taken
from the Atmel prom. With the jumper in the on position the
PIF configuration is taken from the Xilinx prom.
Q: How do I determine the current PCI Pamette firmware
revision?
A: The command PamControl readConfig reports
various information about the default pamette, including firmware
revision. The following sample output shows the output from a board
running firmware revision 1.5:
Type 2, Version 1, Firmware 1.5
Configuration: 4010E 4010E 4010E 4010E
Q: How do I upgrade PCI Pamette firmware?
A: The utility program prom (called ppam_prom
on Unix) is used to read the current contents of either prom, to
write the contents of the Atmel prom, or copy the contents of Xilinx
prom to the Atmel prom. Run ppam_prom with no arguments to
see a synopsis of the command line arguments it accepts.
Q: Where do I find the latest PCI Pamette firmware?
A: The latest PCI Pamette firmware is distributed with PCI
Pamette software package in the file prefetch.rbt. On
Windows NT assuming you installed the kit in D:\Pam, the
firmware is in the file D:\Pam\lib\prefetch.rbt, so you
should type "prom write D:\Pam\lib\prefetch.rbt". On Tru64
UNIX the firmware is in the file /usr/lib/Pam/prefetch.rbt,
so you should type "ppam_prom write /usr/lib/Pam/prefetch.rbt".
You will need to power-cycle your machine for the firmware change to
take effect.
Q: What are the caveats concerning old firmware?
A: Firmware prior to 1.5 had a bug that could cause PCI
parity errors, particularly on Alpha systems. This bug can interfere
with firmware upgrade. To upgrade firmware on a board running
firmware prior to 1.5 first disable PCI parity checking (on UNIX
workstations this is done by entering the command set pci_parity
off in the SRM console) then perform the firmware upgrade. Once
the board is running revision 1.5 or later, parity checking may be
reenabled.
Q: What if the contents of the Atmel prom become
corrupted?
A: Power-up the system with the failsafe jumper in the
on position to use the Xilinx prom. Then upgrade the Atmel prom
in the usual way (the upgrade will complain that the board has no
serial number--you can safely ignore these warnings), shut your
system down, put the failsafe jumper back to its normal off
position, and restart your machine. Once the board is running
current firmware you can restore the serial number and the type of
the board with "PamControl setConfig". After this is done,
repeat the Atmel upgrade procedure to commit the serial number and
the type of the board to non-volatile memory (the Atmel).
Q: I have a V1R2 board that thinks it is a V1R1 board. How
do I change its firmware to say V1R2?
A: To do this use a backdoor in PamControl. The exact
sequence of steps is as follows. Each step is important as is the
order.
In the example below we relabel a board which thinks it is a V1R1
populated with 4010E and with hexadecimal serial number 1001 to be a
V1R2 board populated with 4085XLA and serial number BEEF.
# PamControl
(PamControl) readconfig
PCI Pamette V1R1, Firmware 2.0 , Serial Number 1001
Configuration: 4010E 4010E 4010E 4010E
(PamControl) d 10040 2
set 10040: 00000002
(PamControl) setconfig
PCI Pamette V1R1, Firmware 2.0 , Serial Number 1001
Serial number (hex) [1001] ? BEEF
Lca0 [4010E] ? 4085XLA
Lca1 [4010E] ? 4085XLA
Lca2 [4010E] ? 4085XLA
Lca3 [4010E] ? 4085XLA
PCI Pamette V1R2, Firmware 2.0, Serial Number BEEF
Configuration: 4085XLA 4085XLA 4085XLA 4085XLA
(PamControl) readconfig
PCI Pamette V1R2, Firmware 2.0, Serial Number BEEF
Configuration: 4085XLA 4085XLA 4085XLA 4085XLA
(PamControl) quit
To store this new configuration in non-volatile storage you maust
now update the firmware in the manner described earlier in the
section using the prom utility.
5. Making your own mezzanine boards
The mezzanine board format used by PCI Pamette V1 is IEEE P1386
also known as CMC/PMC. IEEE Standards can be ordered from the
IEEE.
P1386 compatible connectors are available from both Molex and
AMP.
The Molex references when we built the board were:
- 53483-0649 with locating pegs
- 53508-0648 without locating pegs
But at the molex web site the refernce seems to now be:
It may depend what country you are in, so above you have both.
For low volume assembly you probably want the variant with
locating pegs.
6. Board variants
Q: Do you have any larger boards than the current XC4010E
based board?
A: PCI Pamette is designed to support any 5V Xilinx 4000
series device that is available in a PQ208/HQ208 package. For Compaq
internal use we have built variants of the board based on XC4020E
and XC4028EX devices. A revised version of the board (PCI Pamette
V1R2) using 3.3V Xilinx 4000XL device also exists and is supported
by the software kit. This board has been populated with devices up
to XC4044XL and could be populated with XC4085XLA. For customer
availability of these and other variants
contact us.
7. How do I make readback work?
To verify that you have correctly working hardware run:
PamTest readback.
If PamTest works but you can't readback your bitstream, look more
closely at the way you created it.
Firstly you must set the appropriate makebits options to enable
the internal readback circuit. The relevant makebits options are:
- ReadCapture:Enable
- ReadAbort:Enable
- ReadClk:Cclk
You'll find these (plus other required options) in any of the
Makefiles in the */design/src directories of the sample designs.
Secondly look for problems in the netlist itself. How do you
generate your netlist? If it is not made using PamDC then your
problem is probably that you have not wired-up readback. In the
Xilinx 4000 series the readback facility is an *internal* circuit
element that the user must connect in a user determined way.
To be consistent with the way the Pamette PCB is wired you must
connect RDBK.TRIG to MD0 and RDBK.DATA to MD1, RDBK.RIP may be left
unconnected. An xnf fragment pulled from the Pamette sram example
design appears below. You can verify that the readback circuit is
configured by taking the placed and routed design into epic
(or xact, its pre-M1 equivalent). The readback block and the
MD0/MD1 pins are in the lower left corner.
PWR, 0, _GND_
SYM, _block252, RDBK
PIN, RIP, O, rdbk_rip
PIN, DATA, O, rdbk_data
PIN, TRIG, I, rdbk_trig
END
SYM, _block253, MD1
PIN, O, I, rdbk_data_pad
END
SYM, _block254, OBUFT
PIN, I, I, rdbk_data
PIN, T, I, rdbk_data_pad-E0
PIN, O, O, rdbk_data_pad
END
SYM, _block255, BUF
PIN, I, I, _GND_
PIN, O, O, rdbk_data_pad-E0
END
SYM, _block256, MD0
PIN, I, O, _PAD_MD0
END
SYM, _block257, IBUF
PIN, I, I, _PAD_MD0
PIN, O, O, rdbk_trig
END
8. Can I partially reconfigure PCI Pamette?
The PCI Pamette is partially reconfigurable on a per chip basis.
To get partial reconfiguration you have to use the low level
interface PamDownloadLcas, not the normal
PamDownloadBitstream or PamDownloadFile interfaces. The
normal interfaces deconfigure all FPGAs on the board before starting
the configuration. The PamDownloadLcas interface only
deconfigures those FPGAs for which there is a corresponding Xilinx
bitstream in the merged Pamette bitstream you are downloading.
If this sounds confusing please keep in mind that we are using
bitstream to refer to two different things. A Xilinx
bitstream is a bitstream produced by Xilinx CAD tools that
contains the configuration of a single FPGA -- usual filename
extension is .bit. A Pamette bitstream bit-interleaves
several Xilinx bitstreams for parallel download into the Pamette
board -- usual filename extension is .pam or _pam.c.
PamDownloadLcas will not change the configuration of those
FPGAs that correspond to empty positions in the Pamette bitstream.
To create a Pamette bitstream containing empty positions use "-" in
place of the .bit filename in the .mergebit file. For
instance to create a Pamette bitstream that when downloaded with
PamDownloadLcas will reconfigure FPGA#1 with the contents of
foo.bit and leave other FPGAs untouched, an appropriate .mergebit
file is:
# .mergebit file for reconfiguration of FPGA#1 with foo.bit
# preserving configuration of other FPGAs
- foo - -
(see documentation of the PCI Pamette command "mergebit" for
details).
Note 1. Since both usrlca0 and usrlca1 communicate with the PCI
Pamette PCI interface it is possible to maintain a running
application in the board that is communicating with the host
throughout the reconfiguration process. However the download process
does not return until the board is reconfigured so a host software
process that wishes to access an application running in the board
during the download process will need to be multithreaded.
Note 2. There is no dedicated hardware mechanism that prevents
both usrlca0 and usrlca1 from driving the EBus concurrently. It is
up to the application programmer to construct a handshake between
usrlca0 and usrlca1 to pass control of the host communications from
one chip to the other when partial reconfiguration is used. Many
schemes are possible. Here are a couple of ideas:
- Usrlca0 and usrlca1 can rely on the fact that most FPGA I/Os
are tristate pulled-up during reconfiguration and can arbitrate
with each other using a protocol of their own devising on SBus.
- Perhaps the application can use HDC and LDC pins (SBus.D[0]
and SBus.D[3]) to signal reconfiguration in progress.
- In a purely software scheme applicable to transaction mode the
host can use different address ranges to communicate with usrlca0
and usrlca1.
9. Still find your questions unanswered?
Ask us.
| 
Printable version
