[pci] Re: WISHBONE serial block transfers

["Miha" <mihaPCI@email.si>]

Hi all,

I will reply to most of mails sent to PCI mailing list in turn:

WADE, ANDRAS, RICHARD
   I liked Richard's and Andras' propositions best (they are basically the
same if I am not mistaking). It's exactly what I had in mind but it appears
I didn't know how to say it - well Andras and Richard did it for me (thanks
Andras and Richard ;-))
Their proposition says that serial block transfers would be exactly the same
as normal block transfers, only there would be additional signal indicating
that master attempts an access to sequential addresses. This way slaves
already developed for WISHBONE bus won't have to be modified, since address
will still be provided on each cycle. I don't know about SEL_O signals? I
think normally they are not supposed to change during serial (burst)
transfers?
I think TYPE II BLOCK TRANSFER.is not a good idea, because already developed
slave cores could not connect to masters generating this kind of transfers.
Please comment if you think of any drawbacks of our proposition.
What about cycle terminations? They should be handled the same as in normal
block transfers, so slaves will be compatible with both kind of masters.
While I'm at terminations - can slave interrupt block transfer by asserting
ERR_I or RTY_I instead of ACK_I?

GMP (whoever he or she is ;-) )
   Thanks for your reply. Hardware implementation is surely less complicated
if software takes a bit of responsibility about address mapping.

JASON
   You helped in clarifying some things for me. The only problem is that
this design of ours is supposed to be a bridge not intended for particular
device. PCI specification recommends usage of delayed reads (every read
attempted by initiator or WISHBONE master is retried and executed
independently by the bridge).
When initiator retries this read, the data is ready (preferably
pre-fetched). I think this mechanism complicates things a bit more. If you
have any more suggestions, please feel free to post them.

Thanks again for all your help,

    regards, Miha Dolenc


----- Original Message -----
From: Wade D. Peterson <wadep@silicore.net>
To: Richard Herveille <richard@asics.ws>; <mihaPCI@email.si>
Cc: Damjan Lampret <lampret@opencores.org>
Sent: Wednesday, April 25, 2001 10:57 PM
Subject: WISHBONE serial block transfers


> Hi All:
>
> I'm answering emails from several individuals on the same subject (I'm not
sure,
> as everybody is calling it something different).  At this point it's
getting
> pretty confusing for me, and it would be better to converse with one or
two
> people.  That way I can spend some quality time on Miha's problem.
Richard also
> has some proposals that we need to evaluate.
>
> How about if Miha, Richard and myself figure this out together.  Richard
can
> forward whatever he wants to the OpenCores group.
>
> First, I need to understand the problem...
>
> Early in the WISHBONE development we sketched out the kind of memory
> interface that I think Miha is talking about.  I've attached a diagram
showing a
> WISHBONE TYPE II read cycle that was never implemented.  This is a serial
bus
> cycle similar to that in PCI and VMEbus.
>
> If you look at that cycle, the first transfer includes a starting address
that
> is latched by the slave.  During subsequent cycles, the SLAVE has a local
> counter that generates any addresses that the SLAVE may need.
>
> It would be a fairly simple matter to add this bus cycle to the
specification.
> However, here are some issues that we ran into before on this (I'm working
from
> memory, and there may be more):
>
> 1) This serial block transfer forces each memory mapped MASTER and SLAVE
to
> include local address counters.  In current WISHBONE technology, the
MASTER
> generates an address (using a counter or other device), which is broadcast
to
> all SLAVEs during every bus cycle (regardless of type).  The advantage of
the
> serial block transfer is that the addressing information doesn't need to
be
> moved around.  The disadvantage is that you need to create all of those
counter
> circuits, and counters can slow things down.
>
> 2) In the WISHBONE TYPE II block transfer, the MASTER would have to hold
the
> select lines [SEL_O()] steady during the bus cycle, just like the address
lines.
> This implies that the same type of transfer takes place on every 'beat'
(or data
> transfer).  For example, if we transfer a 16-bit operand to a 32-bit port,
then
> the [SEL_O()] lines would indicate the first transfer.  The SLAVE would
need to
> make some decisions about subsequent transfers.
>
> 3) Serial transfers imply that some method is needed to indicate the exact
> number -OR- the maximum number of data transfers within the block cycle.
> Furthermore, the starting boundary conditions would need to be finalized,
and
> whether data can be transferred over boundary interfaces.  For example, in
> VMEbus the maximum number of serial block transfers is 256, and no
transfers can
> be made over a 256-byte boundary.  The cycle must be stopped and
re-started if
> it goes over a boundary.
>
> 4) When and how are the retry and error acknowledge functions handled.
>
> 5) The state of [TAGN_O] signals would need to be reviewed.  Right now,
[TAGN_O]
> has timing that allows data and/or bus cycles to be tagged.  However, in
the
> serial block transfers we may need to pick one or the other.
>
> 6) Right now, there are three flavors of bus cycles: single read/write,
block
> read/write and read-modify-write.  All three of these use a very similar
bus
> cycle that both MASTER and SLAVE circuits can differentiate.  However, we
would
> possibly need to add one or more tag type signals to differentiate these
types
> of bus
> cycles.
>
> 7) It would also be nice to figure out standard ways of hooking a TYPE I
BLOCK
> TRANSFER cycle MASTER to a TYPE II BLOCK TRANSFER SLAVE.  This may not be
too
> difficult, and I have some ideas about this.  We use a technique here
called
> 'veneering' which allows us to convert between bus cycles.  It works quite
well,
> so the approach may be okay here.
>
> 8) We have solved many of the same problems on VMEbus bridges.  However,
we've
> been able to do it within the WISHBONE framework.
>
> As you can see there are trade-offs on this issue that would need to be
> addressed.  However, I think it's doable.
>
> Miha - Why don't you look at the bus cycle
> that I've attached, and see if it solves your problem.  If it does, we can
> create a proposal to this group to add the cycle.
>
> Wade D. Peterson
> Silicore Corporation
> 6310 Butterworth Lane
> Corcoran, MN  USA  55340
> TEL: (763) 478-3567, FAX: (763) 478-3568
> URL: www.silicore.net  E-MAIL: wadep@silicore.net
>
>