Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP

HP.com home

PCI Pamette FAQ


HP Labs

» Research
» News and events
» Technical reports
» About HP Labs
» Careers @ HP Labs
» Worldwide sites
» Downloads
Content starts here

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
SYM, _block253, MD1
  PIN, O, I, rdbk_data_pad
SYM, _block254, OBUFT
  PIN, I, I, rdbk_data
  PIN, T, I, rdbk_data_pad-E0
  PIN, O, O, rdbk_data_pad
SYM, _block255, BUF
PIN, I, I, _GND_
PIN, O, O, rdbk_data_pad-E0
SYM, _block256, MD0
  PIN, I, O, _PAD_MD0
SYM, _block257, IBUF
  PIN, I, I, _PAD_MD0
  PIN, O, O, rdbk_trig

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
Privacy statement Using this site means you accept its terms Feedback to HP Labs
© 2009 Hewlett-Packard Development Company, L.P.