You can do this although you will have some work to do…
A lot depends on you approach. A software only approach would be to have a driver load at boot time, find the bridge, load the FPGA, search for holes in the PCI memory space by scanning all devices on all busses, use IoReportResources() to grab some free address space and apply it to the FPGA config space. Later the NDIS driver will load and use the resources assigned to the FPGA. The problem will be the interrupt assignment if the FPGA uses one. You may not be able to determine it correctly depending on the type of PC you are in. If the device can drive any of the 4 PCI ints you can install 4 handlers, generate each of the four interrupts and see which one gets called. However, in multiprocessor machines this approach starts breaking down.
A better approach would be to have the hardware design improved. Either have the FPGA load from a serial PROM at boot time or use a better bridge. For instance using the PLX9080 you can specify the amount of memory to request from the BIOS through a serial PROM. In this way it could request resources for the PLX and your FPGA. (This assumes your FPGA can be repackaged to live behind the PLX instead of on the PCI bus.) Also the Intel (DEC) 21554 will completely hide a secondary bus from the CPU and allow remapping of address spaces on the primary and secondary sides. This gives you free reign behind the bridge and you can actually hardcode addresses on the backside and use the bridge to translate to the address range assigned by the BIOS. (This allows you FPGA deisng to be a PCI device) A final approach would be to buy the PCI core for an FPGA (Altera or Lucent) and get rid of the bridge. In the cases were things load from serial PROMs, the bridges or your FPGA, will hold off the BIOS by forcing retries of the config cycles until the serial PROM load is done. The BIOS will retry forever until the load is done, then it determines you resource needs and moves on the next device.
If you want to work well in Plug and Play evironments the hardware solution is the way to go. If your sure its only NT4.0 you can probably get away with the software solution in most PCs.
–Todd
----- Original Message -----
From: Gregory G. Dyess
To: NT Developers Interest List
Sent: Friday, February 25, 2000 8:04 AM
Subject: [ntdev] RE: SRAM Based PCI FPGA
There are probably those more knowledgeable about PCI than I, but I will offer my opinion. I don’t think this type of scheme will meet PCI 2.x specs, just because of the reasons you stated. All PCI devices must respond to the configuration address space at all times. Since your FPGA will be acting as a PCI device, it MUST respond to its configuration address space during BIOS config time.
As an alternative, you could use the same config address space as the PCI “bridge” and just as a second function. You could have your interface chip respond to the primary function (used to load the FPGA) and also as a surrogate for the FPGA in the config space. I’m not saying this is going to be easy, but it should be within the specs.
BTW, is it really a PCI “Bridge” or just some type of PCI interface chip, such as PLX Technologies 9050 and 9052?
Greg
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]On Behalf Of Dominick Cafarelli
Sent: Thursday, February 24, 2000 9:22 PM
To: NT Developers Interest List
Subject: [ntdev] SRAM Based PCI FPGA
Our company is currently developing software for a PCI card which has a fixed PCI bridge (with appropriate PCI configuration registers loaded from a ROM) and a soft loadable FPGA that does not have its PCI configuration registers loaded at boot time. There are some I/O pins on the PCI bridge which connect directly to the FPGA configuration load pins. During boot time, a device driver which loads for the PCI bridge will be responsible for loading the image into the soft loadable FPGA. Upon completion of that loading, the soft loadable FPGA (which contains a PCI core) will now have its PCI configuration registers appear on the PCI bus.
I am wondering if any one has implemented such a device. We need to support this type of adapter in Windows NT 4.0. This adapter is a Network card and thus an NDIS Miniport driver will be developed. Will the NDIS driver in Windows NT 4.0 be able to recognize this softloadable FPGA after it has been loaded? I am a bit concerned because the BIOS will not see that FPGA because it is essentially invisiable during BIOS loading. Given that the BIOS has the responsibility of allocating the actual base addresses of all the PCI devices, when this FPGA device appears, it will not be programmed with the appropriate base address.
Can someone help!
Thanks,
Dominick
