Can XP embedded re-enumerate the PCI bus when a system has booted?

I'm about to design a PC104+ board for a client with a largish FPGA
on it, this will be driven by an SBC running XP embedded.

A couple of factors mean there could be a delay of ~1 second until the
FPGA has fully configured and I'm worried the SBC could have enumerated
the PCI bus before the FPGA is ready to respond.

I know in Linux you can force the system to re-enumerate the bus fairly
easily, can this be done in XP embedded too?


Thanks for any pointers,


Nial. 

Nial Stewart wrote:
> I'm about to design a PC104+ board for a client with a largish FPGA
> on it, this will be driven by an SBC running XP embedded.
> 
> A couple of factors mean there could be a delay of ~1 second until the
> FPGA has fully configured and I'm worried the SBC could have enumerated
> the PCI bus before the FPGA is ready to respond.
> 
> I know in Linux you can force the system to re-enumerate the bus fairly
> easily, can this be done in XP embedded too?

I've never seen it done.

Nial Stewart wrote:
> I'm about to design a PC104+ board for a client with a largish FPGA
> on it, this will be driven by an SBC running XP embedded.
> 
> A couple of factors mean there could be a delay of ~1 second until the
> FPGA has fully configured and I'm worried the SBC could have enumerated
> the PCI bus before the FPGA is ready to respond.
> 
> I know in Linux you can force the system to re-enumerate the bus fairly
> easily, can this be done in XP embedded too?

I don't run XP <anything> so take this for what it's worth...

In W2K, the *user* can force a SCSI bus to be re-enumerated
under Device Manager (scan for hardare changes).  Have you tried
something like this?

Can you also just have your BIOS pause for a second or two
during the boot sequence?  Or, other similar tricks to
delay when the enumeration happens (is this process documented
in detail anywhere that you could examine)?

On Dec 8, 9:42=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> I'm about to design a PC104+ board for a client with a largish FPGA
> on it, this will be driven by an SBC running XP embedded.

The simple way out of your predicament - which will not be broken by
future OS updates or driver incompatibilities - is to have the FPGA
hold the system in reset until it is ready for action.

Having said that, yes, XPe *should* support doing this, but I do not
know exactly how you would do it programmatically.

On Dec 8, 11:12=A0am, larwe <zwsdot...@gmail.com> wrote:
> On Dec 8, 9:42=A0am, "Nial Stewart"
>
> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > I'm about to design a PC104+ board for a client with a largish FPGA
> > on it, this will be driven by an SBC running XP embedded.
>
> The simple way out of your predicament - which will not be broken by
> future OS updates or driver incompatibilities - is to have the FPGA
> hold the system in reset until it is ready for action.

The FPGA would not be able to hold the system in reset before it's
loaded, without external hardware.  It could be a simple capacitor,
timer or micro.  A micro can also handle the FPGA loading if necessary.

On Dec 8, 2:24=A0pm, linnix <m...@linnix.info-for.us> wrote:

> The FPGA would not be able to hold the system in reset before it's
> loaded, without external hardware. =A0It could be a simple capacitor,

The "external hardware" to which you refer could be as little as a
resistor and a FET connected to a spare FPGA pin, to keep the system
in reset until the FPGA's output goes from tristate to asserted.

On Dec 8, 2:33=A0pm, larwe <zwsdot...@gmail.com> wrote:
> On Dec 8, 2:24=A0pm, linnix <m...@linnix.info-for.us> wrote:
>
> > The FPGA would not be able to hold the system in reset before it's
> > loaded, without external hardware. =A0It could be a simple capacitor,
>
> The "external hardware" to which you refer could be as little as a
> resistor and a FET connected to a spare FPGA pin, to keep the system
> in reset until the FPGA's output goes from tristate to asserted.

(BTW we can safely infer that there is hardware loading the FPGA- it's
not being loaded from Windows - no way could Windows start and init
the FPGA within 1 second!)

On Dec 8, 11:38=A0am, larwe <zwsdot...@gmail.com> wrote:
> On Dec 8, 2:33=A0pm, larwe <zwsdot...@gmail.com> wrote:
>
> > On Dec 8, 2:24=A0pm, linnix <m...@linnix.info-for.us> wrote:
>
> > > The FPGA would not be able to hold the system in reset before it's
> > > loaded, without external hardware. =A0It could be a simple capacitor,
>
> > The "external hardware" to which you refer could be as little as a
> > resistor and a FET connected to a spare FPGA pin, to keep the system
> > in reset until the FPGA's output goes from tristate to asserted.
>
> (BTW we can safely infer that there is hardware loading the FPGA- it's
> not being loaded from Windows - no way could Windows start and init
> the FPGA within 1 second!)

But we don't know if the reset signal will also reset the FPGA.  If
depends on the design.

Thanks for the feedback guys.

> (BTW we can safely infer that there is hardware loading the FPGA- it's
> not being loaded from Windows - no way could Windows start and init
> the FPGA within 1 second!)


Aye, I'm planning on Active Serial config for simplicity so the FPGA
self loads from a serial flash device.


Nial. 

> In W2K, the *user* can force a SCSI bus to be re-enumerated
> under Device Manager (scan for hardare changes).  Have you tried
> something like this?

This is early days of the project, I'm just thinking ahead.

Is the SCSI bus not a special case to allow hot swapping of
drives?

> Can you also just have your BIOS pause for a second or two
> during the boot sequence?  Or, other similar tricks to
> delay when the enumeration happens (is this process documented
> in detail anywhere that you could examine)?

This might be an option if we did have a problem.

Hopefully with a bit of forward planning we won't.


Nial.