|
Message
From: Kevin Somervill<kevin.m.somervill@n...>
Date: Tue Nov 21 16:56:37 CET 2006
Subject: [oc] Suggested extension to wishbone bus
| From: Richard Herveille [mailto:richard@h...]
| 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
|
 |
Browse
