Reprogramming FPGA over PCI???

Hello,
I am working on a new project with a Xilinx FPGA (Virtex 2 or Virtex
4...TBD) on a PCI card (actually, a PCI Mezzanine Card (PMC), which is
the PCI interface in a slightly different form factor).  Anyway, in
architecting this project, we are discussing how to re-configure the
FPGA from the host machine (in this case, a Processor PMC card running
Linux that will be doing the PCI bus enumeration).  Solutions we have
discussed would be to have the ability to write to a PROM through
custom logic through the PCI bus, and then allow the FPGA to boot from
this PROM.  We have also big-banged the serial-loading protocol in the
past from an ARM processor directly connected to the FPGA, but not over
PCI.

However, with our forray into PCI, being able to load the FPGA through
the PCI bus is quite attractive.  Obviously, if the FPGA is providing
the PCI bus interface, we would have the chicken-before-the-egg
syndrome (i.e., no PCI interface to load the FPGA since the PCI
interface is IN the FPGA).  So what about using dedicated PCI bus
interface chips?  These seem to provide a PCI interface on one end, and
a memory-interface on the other, making them pretty simple to use.  But
I still don't see how this will bring the ability to re-program the
FPGA image.

I don't need to do it on the fly while the system is up and running; I
would simply like to be able to, at power up, have the Processor PMC
card open a bitstream file it has on its local file system, dump the
bitstream down to the FPGA over the PCI interface, and then have the
FPGA start in its normal user mode.

I've looked around a bunch and people are certainly doing this.  But I
can't find many good explanations as to how its working.  Are they
bit-bangging JTAG???

Any help is appreciated...

TIA,
John O.

john.orlando@gmail.com <john.orlando@gmail.com> wrote:

> Hello,

Hi!

> the PCI interface in a slightly different form factor).  Anyway, in
> architecting this project, we are discussing how to re-configure the
> FPGA from the host machine (in this case, a Processor PMC card running

Though I cannot help you, your problem reminds me of firmware upgrades
for my RME Hammerfall HDSP (www.rme-audio.com)

Wouldn't it be possible to let the FPGA write to its own PROM/Flash?
You can still handle the PCI-interface with the FPGA-logic while
uploading the firmware to non-volatile memory. Afterwards you'll
have to reboot or reload (reconfigure) the FPGA from the flash.

Just my $0.02, never done anything like this...

-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Was lacostet die Welt?

john.orlando@gmail.com wrote:

> These seem to provide a PCI
> interface on one end, and a memory-interface on the other, making
> them pretty simple to use.  But I still don't see how this will bring
> the ability to re-program the FPGA image.

In the past we used a small CPLD hanging off the back end of a PLX 9054 
to bit-bash (not JTAG) the FPGA from an image embedded in the host 
driver for our card (no reason it couldn't be read from a file).

We could also program the CPLD itself by bit-bashing JTAG from a 
DOS-based JAM player.

Regards,
Mark

john.orlando@gmail.com schrieb:
> Anyway, in
> architecting this project, we are discussing how to re-configure the
> FPGA from the host machine (in this case, a Processor PMC card running
> Linux that will be doing the PCI bus enumeration).  Solutions we have
> discussed would be to have the ability to write to a PROM through
> custom logic through the PCI bus, and then allow the FPGA to boot from
> this PROM.  We have also big-banged the serial-loading protocol in the
> past from an ARM processor directly connected to the FPGA, but not over
> PCI.
> 
> However, with our forray into PCI, being able to load the FPGA through
> the PCI bus is quite attractive.  Obviously, if the FPGA is providing
> the PCI bus interface, we would have the chicken-before-the-egg
> syndrome (i.e., no PCI interface to load the FPGA since the PCI
> interface is IN the FPGA).  So what about using dedicated PCI bus
> interface chips?  These seem to provide a PCI interface on one end, and
> a memory-interface on the other, making them pretty simple to use.  But
> I still don't see how this will bring the ability to re-program the
> FPGA image.
> 
> I don't need to do it on the fly while the system is up and running; I
> would simply like to be able to, at power up, have the Processor PMC
> card open a bitstream file it has on its local file system, dump the
> bitstream down to the FPGA over the PCI interface, and then have the
> FPGA start in its normal user mode.
> 
> I've looked around a bunch and people are certainly doing this.  But I
> can't find many good explanations as to how its working.  Are they
> bit-bangging JTAG???

If you have a PCI-interface in your FPGA it is relatively easy to add a
few I/O-pins to be able to write the configuration flash via PCI.
You can indeed bit bang JTAG using an SVF player with SVFs generated
with Impact.
However, if this process is interrupted somehow you need to physically
access the board to bootstrap it again. You really need to make sure
that your programming logic works before programming it into the FPGA.

Using a dedicated interface chip solves this problem. Most chips have a
few general purpose IO pins that can be used for bit banging. Or you add
a small CPLD to hook the select map port to the backend bus of the
interafce chip. Or you use one 5V tolerant FPGA for the PCI-interface,
and another modern FPGA for your user logic. This is the most flexible
solution.

Kolja Sulimma

Kolja Sulimma =D7=9B=D7=AA=D7=91:
> john.orlando@gmail.com schrieb:
> If you have a PCI-interface in your FPGA it is relatively easy to add a
> few I/O-pins to be able to write the configuration flash via PCI.
> You can indeed bit bang JTAG using an SVF player with SVFs generated
> with Impact.


This is exactly what I am trying to do (after the PCI jtag idea
failed).
Unfortunately as I begin the SVF sequence (i.e read IDCODE) the prom
seems to erase my fpga ......
then I am stucked with no way continue to configure the flash cause my
design is gone.


The documentation on the usage of SVF is very poor and I dont
understand why, since we payed the money purchase the devices  / sw and
do legal usage with it.






> However, if this process is interrupted somehow you need to physically
> access the board to bootstrap it again. You really need to make sure
> that your programming logic works before programming it into the FPGA.
>
> Using a dedicated interface chip solves this problem. Most chips have a
> few general purpose IO pins that can be used for bit banging. Or you add
> a small CPLD to hook the select map port to the backend bus of the
> interafce chip. Or you use one 5V tolerant FPGA for the PCI-interface,
> and another modern FPGA for your user logic. This is the most flexible
> solution.
>=20
> Kolja Sulimma

> I don't need to do it on the fly while the system is up and running; I
> would simply like to be able to, at power up, have the Processor PMC
> card open a bitstream file it has on its local file system, dump the
> bitstream down to the FPGA over the PCI interface, and then have the
> FPGA start in its normal user mode.
>
> I've looked around a bunch and people are certainly doing this.  But I
> can't find many good explanations as to how its working.  Are they
> bit-bangging JTAG???


I'm doing something similar-ish with an Altera Cyclone and an EPCS4
(serial prom).

The board this is on is connected to an SBC via a PC104+ interface.

The SBC can re-program the EPCS4 over the PCI interface, but you have
to re-boot the system to get the updated config file to be used. It's
then used on every power on until it's updated again. The risk is that
if the system's powered down during config you've got to get in with a
programming cable to recover the box, but so far it's been very reliable.

I've managed to do this using just the standard serial configuration
interface.



Nial


-------------------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk 

On Mon, 19 Sep 2005 12:51:28 -0700, john.orlando wrote:

 FPGA, but not over PCI.
> 
> However, with our forray into PCI, being able to load the FPGA through
> the PCI bus is quite attractive.  Obviously, if the FPGA is providing
> the PCI bus interface, we would have the chicken-before-the-egg syndrome
> (i.e., no PCI interface to load the FPGA since the PCI interface is IN
> the FPGA).  So what about using dedicated PCI bus interface chips? These
> seem to provide a PCI interface on one end, and a memory-interface on
> the other, making them pretty simple to use.  But I still don't see how
> this will bring the ability to re-program the FPGA image.

Its possible to use the PLX9054 PCI bridge chip to load Xilinx FPGA in 8
bit slave mode with no added hardware except a resistor or three. We do
this on some or our cards.

Peter Wallace

There are two scenarios, and I don't know which you are going to be doing.
One is to not use the FPGAas the PCI interface chip, which means you can
program the FPGA through the PCI interface chip, either something like a PLX
or a CPLD...  Or, you want to put the PCI interface in the FPGA.  If you
want to do that, you will need to provide a configuration PROM...which can
be programmed through the FPGA by hooking up it's programming pins to a
register inside the FPGA and writing software (or attempting to use some
that already exist) to reprogram it.

Regards,

Austin

<john.orlando@gmail.com> wrote in message
news:1127155888.358108.107850@g44g2000cwa.googlegroups.com...
> Hello,
> I am working on a new project with a Xilinx FPGA (Virtex 2 or Virtex
> 4...TBD) on a PCI card (actually, a PCI Mezzanine Card (PMC), which is
> the PCI interface in a slightly different form factor).  Anyway, in
> architecting this project, we are discussing how to re-configure the
> FPGA from the host machine (in this case, a Processor PMC card running
> Linux that will be doing the PCI bus enumeration).  Solutions we have
> discussed would be to have the ability to write to a PROM through
> custom logic through the PCI bus, and then allow the FPGA to boot from
> this PROM.  We have also big-banged the serial-loading protocol in the
> past from an ARM processor directly connected to the FPGA, but not over
> PCI.
>
> However, with our forray into PCI, being able to load the FPGA through
> the PCI bus is quite attractive.  Obviously, if the FPGA is providing
> the PCI bus interface, we would have the chicken-before-the-egg
> syndrome (i.e., no PCI interface to load the FPGA since the PCI
> interface is IN the FPGA).  So what about using dedicated PCI bus
> interface chips?  These seem to provide a PCI interface on one end, and
> a memory-interface on the other, making them pretty simple to use.  But
> I still don't see how this will bring the ability to re-program the
> FPGA image.
>
> I don't need to do it on the fly while the system is up and running; I
> would simply like to be able to, at power up, have the Processor PMC
> card open a bitstream file it has on its local file system, dump the
> bitstream down to the FPGA over the PCI interface, and then have the
> FPGA start in its normal user mode.
>
> I've looked around a bunch and people are certainly doing this.  But I
> can't find many good explanations as to how its working.  Are they
> bit-bangging JTAG???
>
> Any help is appreciated...
>
> TIA,
> John O.
>

> Its possible to use the PLX9054 PCI bridge chip to load Xilinx FPGA in 8
> bit slave mode with no added hardware except a resistor or three. We do
> this on some or our cards.
>
> Peter Wallace

Interesting...I just downloaded the datasheet for the PLX9054 to look
it over to see how it is possible accomplish this.  Can you give some
more details about how you actually set this up?  Did you need a CPLD
sitting between the PLX's local bus interface and the slave-mode
programming interface?

Any info here would be helpful...thanks!

John

john.orlando@gmail.com writes:

> I've looked around a bunch and people are certainly doing this. But
> I can't find many good explanations as to how its working. Are they
> bit-bangging JTAG???

I've done this. I could write data through my PCI driver to control
the JTAG chain to program an 18V04 (this was long time ago on a
Virtex-E device) in which my FPGA was loaded from.

The tricky part is do to write the software to generate the JTAG
patterns. Once you done this the rest is pretty straightforward.

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?