Subversion Repositories openrisc_2011-10-31

Wishbone arbiter RTL source

The current implementation of these arbiters for the design is a hard-coded 
slightly configurable set up, rather than a configurable one-size-fits-all 
approach. It is assumed a Harvard architecture is in use, and therefore there 
are seperate busses for both instruction and data busses of the processor. The 
data bus arbiter also has a peripheral, or byte (wide) bus, attached to it.

The busses have ports following the Wishbone B3 standard. They are a cross-bar 
switch setup, ie only one master can be controlling the bus at a time. A simple 
priority-based arbitration system is used, however this only really matters for 
the data bus, which has multiple masters.

The addresses for each slave are configured through parameters. It is expected 
the instantiation of the arbiter will define these parameters also.

The arbiters have the option of passing the signals through with or without any 
sequential logic (registering) however they _DO NOT_ yet support registered 
bursting (ie, where wb_cti indicates anything other than a Wishbone classic 
cycle.) Do not enable registering, via the defines, and expect bursting to work!

There is an optional watchdog counter which will assert wb_err if a request is 
not serviced within the counting period of the clock. The width of the timer 
is defined.

The arbiters depend on the design's top level define file. The options for 
registering and the watchdog timer should be set there.

arbiter_ibus.v:
        This has only one master input and two slaves - a ROM and a main memory.
        This is the simplest of the arbiters. It has 32-bit wide data ports.


arbiter_dbus.v:
        This has two masters ports and several slave ports. It has 32-bit wide 
        data ports. It has a default slave it selects if none of the other 
        slaves are selected, allowing daisy-chaining of another arbiter onto it 
        (used for the peripheral byte-bus.)

        Increasing or reducing the slaves here requires:
        1. Altering the module() declaration, adding the required ports.
        2. Altering the input/output declaration, adding the required ports.
        3. Add/remove(comment-out) the appropriate line in the section under the
           commend "Slave selects". Ensure to alter the final slave, or 
           "default" slave's select logic to include/exclude the slave being 
           added/removed.
        4. Alter the inputs from the master going to the slave
        5. Alter the inputs from the slave (wb_ack, wb_dat_i, etc.) going to the
           master
        6. When instantiating, be sure that the address for the new slave is 
           defined.
        7. Be sure to update the appropriate parameters in design-params.v with
           the correct total number of slaves, and the address of the new slave.

        For most of this slave configuration change, it should be as easy as 
        following the example of the structure already in the file, and 
        potentially just moving the open block-comment marker "/*" past the 
        lines for the new slave.

arbiter_bytebus.v:
        This is a single-master arbiter, connecting to multiple slaves. It has 
        single byte-wide data ports. The data port back to the master maps read 
        bytes to the correct position in a 32-bit wide word, consistent with a 
        big-endian representation of data. There is no default slave. The 
        procedure for adding new slaves is the same as for the main data-bus 
        arbiter, except for the default slave selection considerations.