Re: [oc] Re: WISHBONE serial block transfer

["Andras Tantos" <andras_tantos@yahoo.com>]

Hi!

IMHO it's not a good idea to restrict block transfers to be
sequential. AFAIK arbiter mechanism on the WB bus based on the CYC
signals thus it wouldn't be possible for example to perform a
read-modify-write cycle (without the risk of being interrupted...).

On the other hand sequential block transfers *are* identified on WB
bus: the address is incremental. Of course it does not give any info
on the length of the burst prior the last access nor it's trivial (and
fast) to detect but possible. However I think it's not worth building
a WB master capable of bursting, than hide the bust in normal accesses
and then build a WB salve capable of bursting and force it to extract
the hidden burst information. I would also suggest an additional
signal - for example named BST_I/BST_O - which identifies a burst
cycle. However addresses should be generated for each access in a
burst and all control signals should be handled correctly (WB is not a
multiplexed bus unlike PCI). This way a slave, not capable of bursting
(i.e. not implementing the BST_I pin) would be able to respond burst
requests. You can consider it as a TAG pin, already in the WB
specification, however it would be wise to standardize it.

Other cores, like cache memories, SD-RAM and burst-SRAM controllers,
high-performance external CPU bus interfaces would also benefit from
such an interface extension.

Correct me if I'm wrong!

Best regards,
Andras Tantos


> I think Wishbone should solve this problem in one way or another.
Why? Since
> PCI will be WB compatible core, and as such will be used with other
WB
> cores, it shouldn't [pci core] have any problems connecting to other
WB
> cores when they are acting as masters. This means if you want to use
PCI
> core and take advantage of PCI bursts [which are very important for
system
> performance], interconnect between PCI core and other WB cores
should take
> care of this problem instead of inventing non-standard ways how a WB
master
> signals to the PCI core that WB Block transfer guarantees sequential
> addresses [so that PCI can perform a burst on PCI side].
>
> At the moment PCI core could assume that block transfers are always
with
> sequential addresses. However in a system where one of the WB
masters breaks
> this convention, PCI bursts will fail.
>
> I see two solutions (I'm sure there are more):
> 1) Define a WB signal that defines block transfer with sequential
addresses
> 2) Define some standard tags that WB master generates (one standard
tag
> would be that started block transfer will have sequential addresses)
>
> I'm interested to hear your comments.
>
> regards,
> Damjan
>
> ----- Original Message -----
> From: "Miha" <mihaPCI@email.si>
> To: <wadep@silicores.net>
> Cc: <rherveille@opencores.org>; "Damjan Lampret"
<lampret@opencores.org>
> Sent: Wednesday, April 25, 2001 8:29 PM
> Subject: WISHBONE serial block transfer
>
>
> > Hi,
> > it's me again. As I said, I'm developing PCI bridge core for
OpenCores and
> I
> > would really like to see serial block transfers being identified
on
> WISHBONE
> > bus. That's because PCI bus protocol requires only one address
phase and
> > multiple data phases for block transfers. If I can't explicitly
identify
> > sequential block transfer, than I have to break up block writes
into
> single
> > writes for PCI bus (every write with its own address), which is
slowing
> down
> > the system and taking up space in FIFO.
> > Another problem is read cycle. I intended to support pre-fetched
reads.
> That
> > means that initial request will be retried, bridge will perform
burst read
> > on PCI and wait for a read to be repeated by WISHBONE master.
Every burst
> > read on PCI is serial. Bridge only latches starting address of a
read and
> > performs a burst read from this address up. When WB master repeats
this
> read
> > with block transfer, bridge will have pre-fetched data ready. If
addresses
> > are serial, then WB master can read as much data as it was
pre-fetched. If
> > WB master changes the address in a non-serial manner, than it will
be
> > retried and bridge will take up bandwidth of PCI bus for nothing.
> > What are advantages of identifying serial block transfers for PCI
> interface:
> > - Serial block writes from WB to PCI can be bursted, if we can
identify
> them
> > - a read can be pre-fetched (performed by a burst read on PCI), if
WB
> master
> > identifies a transfer as serial
> >    and is treated as single read in all other cases (doesn't take
up
> > bandwidth for data which will be discarded).
> >
> > Maybe serial block transfers are not that important for other
devices but
> > PCI bridge can surely improve system performance by identifying
them.
> >
> > What do you guys think about this?
> >
> > Regards,
> >     Miha