RE: Delayed Transactions-Role in Target

[Olaf.Reichenbaecher@sci-worx.com]

naveen,

I have been doing a PCI core design some time ago.
most of your questions do sound very familiar to me,
I used to asked them as well during that time.

> 1. When will delayed transactions occur generally?

assume your application your PCI target is hooked
to is very slow. it needs more than the specified 16
PCI clock cycles to respond to a transaction request.
your PCI target is required to retry the access on the
bus while your application is still busy to provide
the transaction response. the requesting master will
repeat the transaction (it is required to do so by
PCI specification) until your application is ready
to respond. thus a transaction becomes a "delayed
transaction". usually read transactions are candidates
to become "delayed transactions".

> Suppose if our PCI Core is only Target core, will only
> single delayed transactions occur or is it possible to
> design our core such that it can handle multiple delayed
> transactions?

that is a question of how much effort you are going to spend
on your target design. a target which manages a delayed
transaction has to "remember" the parameters of
this transaction in order to recognize it when it is repeated
on the bus (usually address and byte enables for read trans-
actions to non-prefetchable address space). all other transactions
which do not match the stored parameters usually are retried.
now imagine a target which handles multiple delayed transactions.
first of all the target needs multiple channels to it's
application on which the application can provide transaction
responses. the target needs to manage these channels, it has to
store the parameters of the transactions that are handled as
delayed transactions on these channels and it has to manage
the assignment of transactions and channels. you do the math ...

> 2. Delayed transactions - suppose if we have PCI
> Target core, what role should it play in delayed transactions?

see my answers above, i hope they explain a bit.

> 3. Suppose if we are implementing delayed transactions, and target
> issued retry, in that case if master hasnt responded
> with same transaction or other masters wants to access the
> target with different transactions - I think without latching
> the data and address, target needs to give retry. In that case,
> i think some of the clock cycles will be wasted until the delayed
> transaction is completed? what will be the advantage of this delayed
> transactions?

first, implementing delayed transaction handling is from my point
of view not a question of "wanting". only and only if you are 100%
sure the application behind your target is able to fullfill the 
"16-clock-rule" you might abandon delayed transaction handling.
if there is a chance you application / target combination might need
longer to respond you must implement delayed transaction handling.

anyway, if your target can deal with other transactions while
a delayed transaction is still pending you don't need to issue
retry on these transactions. that's again a matter of how much
effort you are going to spend on the target design.
if your target can handle only one read transaction at a time
while it is still able to accept (posted) write transactions
you might decide to retry just read transactions that do not
match the parameters of the pending read transaction.
again, handling delayed transactions is not only a question
of advantages, they are required by PCI spec under certain
conditions.
but, for instance, if you know for sure your application will
never be able to provide a response in time to meet the "16-clock-rule",
you can issue a retry immediately and handle the transaction
as delayed internally. this will save 16 clock cycles the
target would hold the bus in wait state otherwise.
and this is the major advantage from my point of view which
outweighs the few cycles that are lost when the requesting master
needs to repeat the transaction.

> 4. Do we need to keep a prefetched buffer memory in
> our core for delayed transactions?

this should not differ from the managing of non-delayed transactions.
you just need to make sure the content of your prefetched buffer memory
is presented to the correct transaction, i.e the transaction which has
initiated the prefetching.

i hope this helps.

best regards

olaf

p.s.: there are a lot of companies that do offer ready-to-use
PCI core IPs on the market. and they became quite affordable in
comparison to the effort one needs to spend on a design process
for a PCI core.
you should consider giving them a try.

-- 
Olaf Reichenbaecher
Senior Design Engineer
_____________________________
sci-worx GmbH
Hannover
Germany
www.sci-worx.com

This e-mail may contain trade secrets or privileged, undisclosed or
otherwise confidential information. If you have received this e-mail
in error, you are hereby notified that any review, copying or distribution
of it is strictly prohibited. Please inform us immediately and destroy
the original transmittal. Thank you for your cooperation.