RE: Multifunction devices

[dahlin@wa.freei.net]

Brooks,
Thanks for the reference.  I figured it was specified somewhere, but I didn't
see it.  I didn't think about the checklist.  Oh well, I hope we can fix it
in metal!

Thanks again,
Dahlin

>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
>> >> 
>> >
>> >
>> 
>
>