multiprocessor problem

[Jaytersen]

Hello all.

I'm trying to construct a multiprocessoer system using vhdl. The system
consists of a single common bus with multiple processor modules
connected to it. I haven't gotten very far with it yet, but i have
forseen a potential problem. Every module has a bus interface witch is
tristated. The businterfaces of the modules are partly controlled by a
circuit that accepts a busrequest signal (from a module) and gives out a
bus grant if the bus is unoccupied (essentially just a priority based
circuit). This way at most one interface in the entire system will not
be tristated.

now to the problem:

The system is made up of a lot of components, so is it possible to
connect the modules (these modules contains the processor, the
businterface and some other things) to the common bus and have it
synthesize without the synthesizer complaining about "multiple sources
connected to the same signal"?. An argument against this would be that
the syntesis tool won't be intelligent enough to realize that no more
than one module can drive the bus at any one time. Your thougts on this
would be most appreciated.

I'm using the Xilinx web pack 4.2, and the whole thing is supposed to
run on a Spartan 2 kit.

 

[Ralf Hildebrandt]

Jaytersen wrote:

Every module has a bus interface witch is
tristated. The businterfaces of the modules are partly controlled by a
circuit that accepts a busrequest signal (from a module) and gives out a
bus grant if the bus is unoccupied (essentially just a priority based
circuit). This way at most one interface in the entire system will not
be tristated.

This is a "tri-state-mux".

The system is made up of a lot of components, so is it possible to
connect the modules (these modules contains the processor, the
businterface and some other things) to the common bus and have it
synthesize without the synthesizer complaining about "multiple sources
connected to the same signal"?.

Use std_logic(_vector) as signal type for the tri-stated bus. Std_logic
is a resolved signal type (opposite to std_Ulogic, which is unresolved)
and simulators / synthesis tools should not have a problem and should
output a warning.


(I recommend: Don't use std_logic for any other signal. Using std_Ulogic
is always a good test for the case, that you have multiple sources on a
bus, because of a mistake.)




Tri-state-muxes can be synthesized well (on target librarys, where
tri-state drivers are available). They are very flexible to extend,
because adding another component to the bus is very easy. But one
problem occurs: A synthesis tool can handle a heavy load on a normal bus
by inferring buffers or stronger drivers. This is not possible with
tri-state-busses without limit. Every tri-state-driver is a load for the
bus and so it if you connect _many_ tri-state-drivers, the synthesis
tool runs into an unresolvable loop, because it wants to do something
against the heavy load, but it can't - except taking tri-state-buffers
with higher driver strength (if available).


Ralf

 

[Mike Treseler]

The system is made up of a lot of components, so is it possible to
connect the modules (these modules contains the processor, the
businterface and some other things) to the common bus and have it
synthesize without the synthesizer complaining about "multiple sources
connected to the same signal"?.

It's possible if you work out the logic such that all
bus processes except one are driving Z all of the time.
Note that the first thing to complain ought to be
your simulator, not your synthesizer.

An argument against this would be that
the syntesis tool won't be intelligent enough to realize that no more
than one module can drive the bus at any one time.

A fact, not an argument. You must supply the logic
for data direction and enable for all bus users.


-- Mike Treseler