Re: Delayed (initial) IRDY

[Tom Keaveny <tak@core.rose.hp.com>]

> 
> Currently my chip would fail i.e. I would deassert TRDY/DEVSEL/STOP
> not together with IRDY but one cycle later:
> 
>            _|       |       |       |       |_______|
> FRAME       |_______|_______|_______|_______|       |-------
>             |       |       |       |       |       |
>             |_______|_______|_______|_______|_______|
> AD          X_______X_______X_______X_______X_______X-------
>             |       |       |       |       |       |
> IRDY       _|_______|_______|_______|_______|       |_______
>             |       |       |       |       |_______|
>             |       |       |       |       |       |
>            _|_______|_______|       |       |       |       
> TRDY        |       |       |_______|_______|_______|_______|
>             |       |       |       |       |       |
>            _|_______|_______|       |       |       |       
> DEVSEL      |       |       |_______|_______|_______|_______|
>             |       |       |       |       |       |
>            _|_______|_______|       |       |       |       
> STOP        |       |       |_______|_______|_______|_______|
> 
> 
> This is a violation of the spec.
> 
> I have three questions:
> 
> (1) How common is the above scenario i.e. how many chip sets
>     would delay the initial assertion of IRDY ?

Note, that you might want to expand the list to add-on pci agents, as well,
if you ever plan to allow "card to card" transfers for your device.

In general, for write operations (which I assume is what you have
shown), I would expect that IRDY# to be  asserted immediately after frame.
The reason for this is as follows.  It usually takes 1-2 cycles from
the detection of a local bus -> PCI access to assertiong REQ#.
By the time that
the bridge has won bus access, the processor on the local bus has 
usually issued the data, as well.  Assuming a fixed frequency 
and phase relationship (i.e., no need for syncrhonizers) you would see
the following sort of events

		time	local bus	internal	PCI bus
		----	---------	-------		-----------
		0	PCI address	--		GNT# (assume parked)
		1	data1		address		REQ#,GNT#
		2	wait		data1		FRAME#,"C/BE==write"
		3	wait		data1		IRDY,data1

Things that could delay IRDY# would include:

	- some processors allow wait states between address and data
	- asynchronous local and PCI clocks 
	- internal bridge architecture (multiplexor delays, embedded
	  DMA controllers...)


> 

> (2) Am I the only one that would get 'confused' in case of the above scenario ?
> 
> (3) What would happen if I responded the latter way (in the real 'world')
> 

First, it would appear that you might be delayed by one cycle in managing
the sustained-tri-state (s-t-s) and "turn-cycle" for your signals.  This
could risk some bus contention if another PCI cycle immediately follows
the one that you have illustrated.  The downside of the contention is
that it may lead to a waveform that effectively violates either the
electrical or bus timing specs.


> Thanks in advance !!!
> 
> 
> ----------------------------------------------------------------------------
> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
>         ROBERT STREITENBERGER (Engineer)     Phone:  +81 727 84 7345
>    /\   Image Processing VLSI Design    /\   FAX:    +81 727 84 7439
>   _\/_  LSI Development Department B   _\/_  E-mail: robert@lsi.melco.co.jp
>  /_/\_\ System LSI Laboratory         /_/\_\                              
>         MITSUBISHI ELECTRIC Co.              *** THIS SPACE`s FOR RENT ***
> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
> ---------------------------------------------------------------------------
>   Snail-Mail:  4-1, Mizuhara  -  Itami City  -  Hyogo, 664  -  JAPAN        
> ---------------------------------------------------------------------------
> 
> 

==
tom keaveny
hewlett packard		"disclaimer:	opinions are my own an not necessarily
					that of Hewlett Packard Co."
p
4'$'