RE: Multifunction devices

[Lame Brooks-G14738 <brooks.lame@motorola.com>]

Sorry for using an ambiguous term - didn't realize PC98 gave it a specific
definition.  I use 'ghost' to refer to something that appears to be there,
but is not functional.  For this case, refer to the PCI Compliance Checklist
(available from www.pcisig.com), item CO13: "If the device is multifunction,
are config space accesses to unimplemented functions ignored?"  This is also
pointed out in the PCI Compliance Workshop presentations under "PCI Do's and
Don'ts (Mostly Don'ts)".  Yes, I realize "ignored" might be debated, but if
you assert DEVSEL#, aren't you  responding by claiming the cycle?
-- BrooksL

> Actually, I believe (technically) this mistake does not meet 
> the definition
> of a ghost device.  The description of a ghost device that 
> was shown in the
> PC98 spec follows:
> 	"A computer must not include any ghost devices, which 
> are devices that do not
> decode the type 1/type 0 indicator. Such a device will appear 
> on multiple PCI
> buses."
> 
> The mistake we made will not show up on other buses, instead 
> there will be config
> spaces present where there is no device.
> 
> (I'll admit that this isn't the "right" way to deal with 
> this.  The "right"
> way is to simply fix it.  But engineering is a discipline 
> full of trade-offs
> between what is "right" and what is expedient.)
> Thanks,
> Dahlin
> 
> >If I recall correctly, 'ghost' config spaces on multifunction devices
> >violates the PCI spec and PC'99 requirements.  This problem 
> is should not be
> 
> >expected in any new silicon.
> >-- BrooksL
> >
> >> -----Original Message-----
> >> From: dahlin@wa.freei.net [mailto:dahlin@wa.freei.net]
> >> Sent: Thursday, 25 May, 2000 02:22
> >> To: pci-sig@znyx.com
> >> Subject: Multifunction devices
> >> 
> >> 
> >> We have a custom IC that just had first silicon show up in 
> >> our lab.  It is a
> >> multifunction device with two functions.  So far we have 
> >> found one problem in
> >> the PCI interface
> >> 
> >> That problem is that the device issues a DEVSEL# for config 
> >> space accesses to
> >> all 8 possible functions.  The result is that we have 2 
> >> functioning config spaces
> >> and 6 config spaces that have read-only registers that 
> contain 0's.  
> >> 
> >> This is not a good thing, but I think it is a problem that 
> >> can be lived with.
> >>  The BARs return all 0's when read so the system won't 
> >> allocate any space to
> >> the 6 extra devices, and we won't conflict with any other 
> >> config spaces.
> >> 
> >> Does anyone see a problem with not spending the time and 
> >> money on fixing this
> >> if it remains that only bug?
> >> 
> >> Thanks,
> >> Dahlin
> >> 
> >
> >
>