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: http://www.opencores.org/forums.cgi/cores/attachments/20061121/ac728c5f/attachment.htm

Hello, | From: cores-bounces at opencores.org | I've been thinking about extending the Wishbone bus. | | The extension, called Wishbone Duplex, features separate | read/write sections; | 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? What is the expected benefit of doing this? I can see splitting out just the rd and wr lines as wb_re_i and wb_we_i, but I don't see the value in splitting out all of interface ports. It doesn't seem simplify the interconnect or improve performance that I can see. It's also somewhat of a divergence from standard interfaces with rd/wr lines. What exactly are you trying to address with the extension? Thanks, ./ks

It allows for separate read/write buses in an SOC. This does improve performance, at the cost of increased area. Providing a separate wb_re_i does not provide any benefits and is utterly redundant. Richard -----Original Message----- From: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of Kevin Somervill Sent: Tuesday, November 21, 2006 2:58 PM To: 'Discussion list about free open source IP cores' Subject: RE: [oc] Suggested extension to wishbone bus Hello, | From: cores-bounces at opencores.org | I've been thinking about extending the Wishbone bus. | | The extension, called Wishbone Duplex, features separate | read/write sections; | 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? What is the expected benefit of doing this? I can see splitting out just the rd and wr lines as wb_re_i and wb_we_i, but I don't see the value in splitting out all of interface ports. It doesn't seem simplify the interconnect or improve performance that I can see. It's also somewhat of a divergence from standard interfaces with rd/wr lines. What exactly are you trying to address with the extension? Thanks, ./ks _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

| From: Richard Herveille [mailto:richard at herveille.net] | It allows for separate read/write buses in an SOC. I got that part, but to what end is my question. | This does improve performance, at the cost of increased area. How do you figure it increases performance? If device A is reading device B, can device C also write to it? Not many cores support concurrent access nor do typical bus structures. Are you implying a cross bar type functionality where device C would write to device D while A is reading B? You don't need to separate the bus out to get that. Is there a particular application you envision for this? | Providing a separate wb_re_i does not provide any benefits | and is utterly | redundant. I wouldn't say that (else I wouldn't have made the comment). I'd bet a lot folks generate (implicitly or explicitly) read enable and write enable lines from the single we_i signal. Synthesis tools as well will optimize a signal to a bunch of inverters to a signal to a single inverter that is fanned out. ./ks

How do you figure it increases performance? If device A is reading device
B, can device C also write to it?
[rih] That's the basic idea

Not many cores support concurrent access
[rih] Fully agreed, therefore most cores will be non Wishbone Duplex core.
But those few that benefit from the enhanced bus structure can use it.


nor do typical bus structures. Are you implying a cross bar type
functionality where device C would write to device D while A is reading B?
[rih] That's up to the system architect. Wishbone does not specify the bus
interconnect. It merely specifies the basic bus architecture.
What kind of interconnect (x-bar, mux, ...) is used is up to the system
architect.


Richard

| From: Richard Herveille [mailto:richard at herveille.net] | How do you figure it increases performance? If device A is | reading device | B, can device C also write to it? | [rih] That's the basic idea So what about a core that does support concurrent access and it (say A) is writing B, but C tries to read A? A's dat_o line is taken so rty? I can see where a few dual_ported cores could use this, but why not just implement two wb interfaces. That's what we've done. And if I can find the funding, I'm hoping to build a xbar switch for our application, but chances are slim. Now would the extension address requirements on decoupling the interface for the example mentioned above? | Not many cores support concurrent access | [rih] Fully agreed, therefore most cores will be non Wishbone | Duplex core. | But those few that benefit from the enhanced bus structure can use it. As an optinal extension, I can see some benefit, but couldn't this also be addressed in a reference design using the standard interface, just dual ported? Is it just a convenience issue, or is there something fundamental that merits a formal extension to the spec? | nor do typical bus structures. Are you implying a cross bar type | functionality where device C would write to device D while A | is reading B? | [rih] That's up to the system architect. Wishbone does not | specify the bus | interconnect. It merely specifies the basic bus architecture. | What kind of interconnect (x-bar, mux, ...) is used is up to | the system | architect. Agreed. ./ks

Hi all! One thought below. ----- Original Message ----- From: "Richard Herveille" richard at herveille.net> To: kevin.m.somervill at nasa.gov>; "'Discussion list about free open source IP cores'" cores at opencores.org> Sent: Tuesday, November 21, 2006 4:31 PM Subject: RE: [oc] Suggested extension to wishbone bus

You can implement one wishbone classic interface for reading and one for
writing in device
B. DAT_I and DAT_O signals are optional, so it should be allowed. Than it is
up to interconnect
to allow simultaneous access to both ports.

Regards,
Miha Dolenc

Hi Miha,

| You can implement one wishbone classic interface for reading
| and one for
| writing in device
| B. DAT_I and DAT_O signals are optional, so it should be
| allowed. Than it is
| up to interconnect
| to allow simultaneous access to both ports.

That's my point. I don't see a need to define an extension considering what
you can already do with the current spec. Unless it addresses some
fundamental functionality.

How are dat_i and dat_o optional? Without them, there's not much bandwidth?
;)

./ks

Hi Miha, | You can implement one wishbone classic interface for reading | and one for | writing in device | B. DAT_I and DAT_O signals are optional, so it should be | allowed. Than it is | up to interconnect | to allow simultaneous access to both ports. That's my point. I don't see a need to define an extension considering what you can already do with the current spec. Unless it addresses some fundamental functionality. [rih] Fully agreed, you can achieve the same with 2 wishbone interfaces. The extension is merely meant to directly support an architecture with split read/write buses. How are dat_i and dat_o optional? Without them, there's not much bandwidth? ;) [rih] dat_i and dat_o are optional. Some cores need only read or write access to the wishbone bus. I can even imagine cores that don't need any data at all. For example a watch-dog that monitors bus activity would only check CYC (and STB) and assert ERR_O if there isn't any activity for a long time. Richard ./ks _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Kevin Somervill wrote:

FWIW I'm siding with Kevin on this one. Extending the specification for 'convenience' just complicates matters IMHO when the standard interface is perfectly adequate for the task. BTW couldn't the 'Duplex' interface simply be implemented as a wrapper around two standard interfaces? Respectfully, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266

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 Herveillerichard at h...> To: Date: Tue Nov 21 10:55:55 CET 2006 Subject: [oc] Suggested extension to wishbone bus

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 at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of Robert Finc Sent: Wednesday, November 22, 2006 10:11 AM To: cores at opencores.org 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 Herveillerichard at h...> To: Date: Tue Nov 21 10:55:55 CET 2006 Subject: [oc] Suggested extension to wishbone bus _______________________________________________ http://www.opencores.org/mailman/listinfo/cores