Designs implementing BARs of type I/O space will fail to simulate correctly because of a problem when NETGEN produces the simulation model of the core. The PIO example design enables an I/O BAR by default.
How will this problem affect the example design?
This issue will be fixed in the 9.1i software release, which is scheduled for release in early 2007. This is a problem only in simulation and does not affect hardware operation.
Currently, the default CORE Generator configuration of the PIO design enables BAR 0 (IO), BAR 1 (Mem32), BAR2/3 (Mem64), and BAR 6 (Mem32). If a simulation is run, the testbench BAR configuration task will read BAR 0 and identify it incorrectly as a Mem32 BAR because bit 0 is incorrectly cleared. The BAR initialization will continue and correctly determine that BAR 1 is a Mem32 space, but will flag this BAR as unsupported by the PIO Design due to the PIO limitation of only supporting 2 Mem32 BARs - one of which is the EROM. For this reason, BAR 1 will appear disabled to the test program.
When the test program sends Mem32 TLPs to BAR 0, the core will not respond to the Mem32 TLPs because it thinks BAR 0 is an I/O space. An error message is displayed to the output indicating that an unsupported request was transmitted. The test program will timeout because it is expecting to receive a CplD from the core. A completion with UR will not be generated.
However, the default simulation script only enables execution of a simple type 0 configuration read test that does not exercise BAR 0 read and write. But, as soon as any of the tests located in pio_tests.v are run, then this issue will be encountered. Disabling I/O spaces in the CORE Generator GUI will allow customers to work around this issue until NETGEN is fixed.