Microcontroller Bus-System
 

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

Re: Microcontroller Bus-System
 

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

Re: Microcontroller Bus-System
 

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

Re: Microcontroller Bus-System
 

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.