RE: Multifunction devices

[dahlin@wa.freei.net]

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