Microcontroller Bus-System

Discussion in 'VHDL' started by Gabriel Schuster, Sep 7, 2006.

  1. Hi there,

    I want to build a microcontroller core using VHDL. Currently I'm
    planning the structure of the system internals and as a matter of fact
    the bus system is a pretty awkward thing: I want to keep the core as
    upgradeable as possible so that it would be an easy thing to add new
    system peripherals - without much effort. Consequently the easiest
    implementation would be using one bus connected to each timer, port, etc
    using a tri-state data-port. New devices would only need to be
    connected to the address- and data-port. Functionality would be defined
    by Special Function Registers inside of each device, which would be
    addressed over the common bus.

    However, I've seen IP Cores developed for ASIC technologies which
    strictly avoid the use of the signal attribute 'Z' and furthermore using
    only 'in' and 'out' ports in all entities. Is that really neccessary?

    If I would do the same in my project it would be quite complex to add
    new stuff, because each device would need to have a separate bus system
    to the control unit.

    I know that there are plenty of uC-Cores in the www, but I do this for
    educational reasons and most important: I want to do it right from the
    beginning, so I would appreciate any help, info or advice.

    Thanks
    Gabriel
    Gabriel Schuster, Sep 7, 2006
    #1
    1. Advertising

  2. Gabriel Schuster wrote:


    > I want to build a microcontroller core using VHDL. Currently I'm
    > planning the structure of the system internals and as a matter of fact
    > the bus system is a pretty awkward thing: I want to keep the core as
    > upgradeable as possible so that it would be an easy thing to add new
    > system peripherals - without much effort. Consequently the easiest
    > implementation would be using one bus connected to each timer, port, etc
    > using a tri-state data-port.


    I agree in terms of easiness - without modifying any other components
    you may add new components to the tri-state bus.


    > However, I've seen IP Cores developed for ASIC technologies which
    > strictly avoid the use of the signal attribute 'Z' and furthermore using
    > only 'in' and 'out' ports in all entities. Is that really neccessary?


    It is not necessary - I have seen a Microcontroller running using such a
    tri-state bus - but not always the best idea.


    Problems arise if you add really many components to the bus. Then the
    wire load of the bus becomes larger and larger. The first thing a
    synthesis tool will do is using not the normal tri-state drivers in your
    library but the ones being capable of driving a bigger load. But again
    there is a border you can't cross with these drivers. You need again
    stronger ones. What will happen if there are no stronger tri-state
    drivers in your library? The synthesis tool will run "infinitely" trying
    to find a solution.

    Your option then would be to use traditional muxes in each component,
    that select one register out of this component and only one tri-state
    driver for each component. Bad luck, if you have many components.


    Not only the wire load itself is a problem but also the power
    dissipation. Because for a big tri-state bus you need strong drivers the
    bus itself consumes a lot of power.


    What are your options? A global multiplexer that selects one out of all
    registers? Well ... in terms of power dissipation, area and speed not a
    disaster as you might think, but not optimal. Furthermore adding new
    components is a mess.


    After comparing several bus systems in terms of area, speed and
    especially power dissipation an AND- or OR-bus is quite a good solution
    for this problem.

    What is an OR-bus? All data outputs from all components are fed to a
    "giant" OR gate. A component is permitted to drive a data value if and
    only if one register out of this component is selected. All other
    components drive '0'. Behind the "giant" OR gate the data will become valid.
    Inside the component I suggest to use again such an OR-multiplexer to
    select one register out of one component. (Classic muliplexers inside
    the components do not perform so well.)
    I have written "giant" OR gate. Well, it is quite small - in many cases
    smaller than a global selector or a tri-state bus. And it consumes less
    power than the other two bus types. A tri-state bus may have the
    advantage of being faster - if and only if the wire load is small enough
    to use weak tri-state drivers, which means if only few components are
    connected.

    What is an AND-bus? As you probably guess it is very similar to the OR
    bus - the only difference is, that all not selected registers drive '1'
    and a "giant" AND gate is used. The AND bus has equal performance to the
    OR bus.

    Why are AND- and OR-bus so good? It is easy to simplify the
    combinational logic for synthesis tools and you get quite a big, but a
    competitive buch of classic combinational logic. Driver strength is not
    a problem - the synthesis tool solves it.

    The big disadvantage: You can't add new components without modifying at
    least the "giant" OR- / AND-gate. But you can separate this mux and add
    new components easily:

    do<=do1 OR do2 OR do3; -- old
    do<=do1 OR do2 OR do3 OR do4; -- new


    The mentioned microcontroller with the tri-state bus had reached its
    limit of wire load and has been modified. After implementing an OR-bus
    it became faster and smaller. We did not test it, but I strongly guess
    it consumes less power now.



    Although I think it is obvious, but let me add: we use two data signals
    for the bus: data-out (from the CPU to the components) and data-in
    (opposite direction).

    Ralf
    Ralf Hildebrandt, Sep 7, 2006
    #2
    1. Advertising

  3. Gabriel Schuster

    Jan Decaluwe Guest

    Gabriel Schuster wrote:
    > Hi there,
    >
    > I want to build a microcontroller core using VHDL. Currently I'm
    > planning the structure of the system internals and as a matter of fact
    > the bus system is a pretty awkward thing: I want to keep the core as
    > upgradeable as possible so that it would be an easy thing to add new
    > system peripherals - without much effort. Consequently the easiest
    > implementation would be using one bus connected to each timer, port, etc
    > using a tri-state data-port. New devices would only need to be
    > connected to the address- and data-port. Functionality would be defined
    > by Special Function Registers inside of each device, which would be
    > addressed over the common bus.
    >
    > However, I've seen IP Cores developed for ASIC technologies which
    > strictly avoid the use of the signal attribute 'Z' and furthermore using
    > only 'in' and 'out' ports in all entities. Is that really neccessary?


    No, but it's a good idea. I'm pretty sure that in addition to the
    date buses, those cores have control outputs which permit to use a
    wide range of interconnection options, including a tristated bus.

    > If I would do the same in my project it would be quite complex to add
    > new stuff, because each device would need to have a separate bus system
    > to the control unit.


    Not necessarily. Given the appropriate control signals, you could
    use the interconnect structure that you want, including a fully
    tristated bus. But you have many other options, including several
    ways without using tristates at all.

    Personally, I have virtually never seen a case where *on-chip* tristates
    were superior, given the problems they cause: power, electrical
    issues, and (often forgotten) testability.

    If you designed your core with a tristate inout bus, you basically
    exclude those other possibilities. If you don't, you still have that
    option, alongside other options that may be superior, by doing it
    outside the core proper. An obvious choice.

    Regards, Jan

    --
    Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Losbergenlaan 16, B-3010 Leuven, Belgium
    From Python to silicon:
    http://myhdl.jandecaluwe.com
    Jan Decaluwe, Sep 11, 2006
    #3
  4. Gabriel Schuster

    radarman Guest

    Gabriel Schuster wrote:
    > Hi there,
    >
    > I want to build a microcontroller core using VHDL. Currently I'm
    > planning the structure of the system internals and as a matter of fact
    > the bus system is a pretty awkward thing: I want to keep the core as
    > upgradeable as possible so that it would be an easy thing to add new
    > system peripherals - without much effort. Consequently the easiest
    > implementation would be using one bus connected to each timer, port, etc
    > using a tri-state data-port. New devices would only need to be
    > connected to the address- and data-port. Functionality would be defined
    > by Special Function Registers inside of each device, which would be
    > addressed over the common bus.
    >
    > However, I've seen IP Cores developed for ASIC technologies which
    > strictly avoid the use of the signal attribute 'Z' and furthermore using
    > only 'in' and 'out' ports in all entities. Is that really neccessary?
    >
    > If I would do the same in my project it would be quite complex to add
    > new stuff, because each device would need to have a separate bus system
    > to the control unit.
    >
    > I know that there are plenty of uC-Cores in the www, but I do this for
    > educational reasons and most important: I want to do it right from the
    > beginning, so I would appreciate any help, info or advice.
    >
    > Thanks
    > Gabriel


    Most modern FPGA architectures no longer contain internal tri-state
    busses, so it really doesn't matter if you implement them that way or
    not. The tools will convert your intended design into something that
    can be done with muxes. I'm not sure about Altera, but I believe the
    Xilinx XC4000 series parts were the last to support true internal
    tristate buffers.

    You can replicate some of the nicer aspects of a tri-state bus, though,
    specifically the smaller area and faster timing, by using a bit-wise OR
    of all the module busses together, and use your output enables to
    either direct an output FF mux, or a combinatorial (AND) mask, instead
    of driving a tri-state buffer.

    The trick is that rather than drive 'Z',s unselected devices should
    drive zero's, while only the selected device drives the addressed data.
    When you OR all the outputs together, you naturally get the addressed
    data. If implemented correctly, you can effectively "mux" many busses
    together, with only a few levels of logic. This bus does have some
    scaling issues, but given it's simplicity, it can be replicated with
    low expense if fan-out becomes a problem.

    Also, I always register the module outputs, so that the combinatorial
    path is as optimal as possible. The enable can either release the
    register from reset, or drive a mux at the input. While this does imply
    a 1-clock latency, this is OK, as the BRAM memory has a minimum
    pipeline latency of 1 (and typically 2 for higher performance systems)
    anyway. (at least in most modern FPGA's)

    This bus style does require careful design and debugging, as nothing
    will warn you of bus contention. (since it is electrically legal) You
    have to ensure that only one enable is valid during any given clock
    cycle. Of course, you would do this for a tri-state system anyway - so
    that shouldn't be an issue. If you do have multiple drivers, you will
    get the bit-wise OR of all the data words.
    radarman, Sep 11, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. SneakerNet
    Replies:
    0
    Views:
    649
    SneakerNet
    Sep 1, 2003
  2. kitkat
    Replies:
    2
    Views:
    2,455
  3. kitkat
    Replies:
    0
    Views:
    428
    kitkat
    Jan 12, 2005
  4. Replies:
    0
    Views:
    575
  5. Thomas Baier

    microcontroller bootloader in C

    Thomas Baier, Aug 16, 2004, in forum: C++
    Replies:
    3
    Views:
    4,100
    Christopher Benson-Manica
    Aug 16, 2004
Loading...

Share This Page