OPENCORES.ORG

Hi,

It seems as though there isn't a lot of support for this extension.
And thinking of it a bit more I'd have to agree. Splitting the bus into
separate read/write sections is basically the same as adding 2 wishbone
(read & write) interfaces on a core.

What would really make sense, instead of a start-of-cycle, is to move to a
pipelined bus. But then we run into patent issues with AMBA and CoreConnect.

Richard

-----Original Message-----
From: cores-bounces@o... [mailto:cores-bounces@o...] On
Behalf Of Robert Finc
Sent: Wednesday, November 22, 2006 10:11 AM
To: cores@o...
Subject: Re: [oc] Suggested extension to wishbone bus

Hi Richard,

First, I must say the Wishbone bus works very well; I'm using it a lot.

Suggestion:
- A 'soc' - 'start of cycle' signal.

As my own customization I added one signal ('soc' - start of cycle) 
which is output by a master, active during the first clock cycle of a bus 
access (first cycle of cyc_o).  This made it a lot easier to build a shared 
memory interface (see below), because then the interface didn't need 
logic to detect when a fresh new access was occurring as opposed to a 
stale one.

A while ago, I made a custom extension to the bus that does a similar 
kind of thing to separate read / write, although the extension was to 
split the bus into separate read/write request and read response 
busses. It improved performance tremendously, as there could then be 
multiple outstanding read requests on the bus from multiple masters, 
rather than have to wait for the ack to come back to complete the cycle.

However, what I eventually realized was that the system needed an 
interface to shared resources (memory). Having built a shared memory 
interface, the Wishbone bus could be used without needing much 
extension.

- 'advanced' versions of signals (signals available just prior to being 
registered for outputs) (eg cyc_nxt_o) .

I've used advanced versions of signals occasionally in order to interface 
to things like block ram resources in the FPGA which have registered 
inputs. Without the advanced signal, an extra clock cycle is needed. 
Note that using advanced signals does have a negative performance 
impact though.

hardware interrupt / exception lines
signals indicating memory reservations / clearing / semaphores
device present signals

Duplexing looks like it could allow simulataneous write and read for 
semaphore operations.

Robert

----- Original Message ----- 
From: Richard Herveille<richard@h...> 
To: 
Date: Tue Nov 21 10:55:55 CET 2006 
Subject: [oc] Suggested extension to wishbone bus 

> Hi, 
> 
> 
> 
> I've been thinking about extending the Wishbone bus. 
> 
> The extension, called Wishbone Duplex, features separate read/write 
> sections; 
> wb_clk_i, 
> wb_rst_i, 
> wb_wcyc_i, 
> wb_wstb_i, 
> wb_wadr_i, 
> wb_wack_o, 
> wb_dat_i, 
> wb_rcyc_i, 
> wb_rstb_i, 
> wb_radr_i, 
> wb_rack_o, 
> wb_dat_o 
> 
> 
> As you can see 'wb_we_i' has been removed, as it's not required 
> anymore. 
> Wishbone Duplex is an extension to the Wishbone standard. A 
> Wishbone Duplex 
> core can be connected to a Wishbone Classic or Wishbone RevB.3 bus 
> using a 
> simple wrapper. 
> 
> Any ideas/suggestions? 
> 
> 
> Richard 
> 
> 
> 
> 
> -------------- next part -------------- 
> An HTML attachment was scrubbed... 
> URL: attachment.html 
> 
> 
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores