|
Message
From: Martin Schoeberl<martin@j...>
Date: Mon Nov 28 11:42:30 CET 2005
Subject: [oc] lack of pipeline in wishbone (resend)
That's exact the point I stumbeld over in the last two weeks
when I changed the memory interface of JOP to be WB compliant.
Here is a comment I posted in another group:
>After implementing the Wishbone interface for main memory access
>from JOP I see several issues with the Wishbone specification that
>makes it not the best choice for SoC interconnect.
>
>The Wishbone interface specification is still in the tradition of
>microcomputer or backplane busses. However, for a SoC interconnect,
>which is usually point-to-point, this is not the best approach.
>
>The master is requested to hold the address and data valid through
>the whole read or write cycle. This complicates the connection to a
>master that has the data valid only for one cycle. In this case the
>address and data have to be registered *before* the Wishbone connect
>or an expensive (time and resources) MUX has to be used. A register
>results in one additional cycle latency. A better approach would be
>to register the address and data in the slave. Than there is also
>time to perform address decoding in the slave (before the address
>register).
>
>There is a similar issue for the output data from the slave: As it
>is only valid for a single cycle it has to be registered by the
>master when the processor is not reading it immediately. Therefore,
>the slave should keep the last valid data at it's output even when
>wb.stb is not assigned anymore (which is no issue from the hardware
>complexity).
>
>The Wishbone connection for JOP resulted in an unregistered Wishbone
>memory interface and registers for the address and data in the
>Wishbone master. However, for fast address and control output (tco)
>and short setup time (tsu) we want the registers in the IO-pads of
>the FPGA. With the registers buried in the WB master it takes some
>effort to set the right constraints for the Synthesizer to implement
>such IO-registers.
>
>The same issue is true for the control signals. The translation from
>the wb.cyc, wb.stb and wb.we signals to ncs, noe and nwe for the
>SRAM are on the critical path.
>
>The ack signal is too late for a pipelined master. We would need to
>know it *earlier* when the next data will be available --- and this
>is possible, as we know in the slave when the data from the SRAM
>will arrive. A work around solution is a non-WB-conforming early ack
>signal.
>
>Due to the fact that the data registers not inside the WB interface
>we need an extra WB interface for the Flash/NAND interface (on the
>Cyclone board). We cannot afford the address decoding and a MUX in
>the data read path without registers. This would result in an extra
>cycle for the memory read due to the combinational delay.
>
>In the WB specification (AFAIK) there is no way to perform pipelined
>read or write. However, for blocked memory transfers (e.g. cache
>load) this is the usual way to get a good performance.
>
>Conclusion -- I would prefer:
>
> * Address and data (in/out) register in the slave
> * A way to know earlier when data will be available (or
> a write has finished)
> * Pipelining in the slave
>
>As a result from this experience I'm working on a new SoC
>interconnect (working name SimpCon) definition that should avoid the
>mentioned issues and should be still easy to implement the master
>and slave.
>
The proposed SoC interconnect standard SimpCon with pipelining
support is available at operncores:
http://www.opencores.org/projects.cgi/web/simpcon/overview
>As there are so many projects available that implement the WB
>interface I will provide bridges between SimpCon and WB. For IO
>devices the former arguments do not apply to that extent as the
>pressure for low latency access and pipelining is not high.
>Therefore, a bridge to WB IO devices can be a practical solution for
>design reuse.
>
See it as an 'extension' to the open Wishbone specification
and not as a substitute.
Martin
----- Original Message -----
From: "Tim Tait" <tim.tait1@g...>
To: <cores@o...>
Sent: Monday, November 28, 2005 7:30 AM
Subject: [oc] lack of pipeline in wishbone (resend)
Does anyone else see it as a serious shortcoming that Wishbone does not
support Address/Data pipelining?
When connecting Wishbone to standard synchronous SRAM's (that register
all address/control inputs) it makes it impossible to maintain
throughput at full clock rate on random address sequences, even for
those with flow-through data.
The "FASM" Synchronous RAM model that is discussed in the spec if not
actually synchonrous during read, only during write. This does not match
any SSRAM IC I have encountered, or the SSRAM's inside recent Altera FPGA's.
Is anyone working on an extension to WB to support pipelining?
Tim
|
 |
Browse
