Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


SRAM Based PCI FPGA

OSR_Community_UserOSR_Community_User Member Posts: 110,217
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

Comments

  • Gregory_G._DyessGregory_G._Dyess Member - All Emails Posts: 374
    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: [email protected]
    [mailto:[email protected]]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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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: [email protected] [mailto:[email protected]]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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    >the BIOS has the responsibility of allocating the actual base addresses of
    >all the PCI devices

    No. BIOS has the responsibility of allocating _interrupt vectors_ to PCI
    devices, not base addresses. And even this BIOS feature can be swicthed
    off by setting "PnP OS=yes" in the setup - this can work with OSes which
    have PCI IRQ steering support in their kmode components - like Win9x.
    NT4 is NOT a such OS - so, it requires BIOS to set interrupt vectors.

    Base addresses are assigned by PCI config space code in HAL -
    HalAssignSlotResources function. AFAIK it is also exported to NDIS under
    some name.

    But your device has a PCI bridge. PCI bridges are programmed by HAL at
    kernel startup in some default way - and AFAIK there is no way for the
    driver
    to change this default PCI bridges setup. HAL prohibits it by failing
    HalSetBusData for bridges.
    So, if your brigde is compatible with HAL's default handling of PCI
    brigdes - I
    don't think you will have any problems. If not - a hard thing. Maybe
    hardware
    redesign will be the best solution. Or writing a custom HAL :-)

    Max
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE