A procedure to interconnect components

J

jean-philippea

Guest
Hi,

I'm trying to automate the building of a firmware. For that I'm taking a
C++ type approch.
I'd like to know if it is possoble to create a function oe a procedure to
interconnect 2 components together. Basically, the signals connected the
ports of both components will be passed to the procedure which will then
connect them together.
Note that signals comming from components are INOUT!

Thanks
JP
 
Thanks for the quick answer.

Unfortunatly having a direction signal is not possible.

I define my own types for the I/O ports of the component. And actually all
my components only have 1 INOUT port in which all the signals coming in
and out are gathered. Signals are unidirectional but as they are grouped
in the same type the port needs to be INOUT, which confuses my simulator
and I guess will confuse my synthesiser too...

The idea is to define a set of components and the rules/methods to
interconnect them.
This way I can have a code that will look like the following.
Note that function Connect could be overloaded for the various types of
signals.

This create a simple easy to read code. It also make it very easy to
automate generation of code using generate statement or automatic code
generation tools for example.

signal u0_io: MyTypeA;
signal u1_io: MyTypeB;

u0 : MyCompA
port map(
io => u0_io,
);

u1 : MyCompB
port map(
io => u1_io,
)

Connect (u0_io, u1_io)

Thanks
JP
 
By the way I forgot to mestion, this code will be synthesisable !...
 
jean-philippea wrote:

Thanks for the quick answer.

Unfortunatly having a direction signal is not possible.

I define my own types for the I/O ports of the component. And
actually all my components only have 1 INOUT port in which all the
signals coming in and out are gathered. Signals are unidirectional
but as they are grouped in the same type the port needs to be INOUT,
which confuses my simulator and I guess will confuse my synthesiser
too...
Reason the more to abandon this approach, if you ask me. Or at least
separate the IN and OUT parts.

The idea is to define a set of components and the rules/methods to
interconnect them.
This way I can have a code that will look like the following.
Note that function Connect could be overloaded for the various types
of signals.

This create a simple easy to read code. It also make it very easy to
automate generation of code using generate statement or automatic
code generation tools for example.
Generating the code without the connect function will be just as easy,
more straight forward and on top of that synthesizable. Just my two
cents.

Paul.
 
Hi guys,

Thanks for the advises.
Actually I gave up with the INOUT signal. I split the inout part and the
output part and I made a type for each of them. It works!
The resulting code is very very simple, which was my objective.

To answer to remark concerning the differences between types: I was
thinking of overloading the operator "<=" to be able to interconnec any
type together.

Once again, thank you very much!

JP
 
jean-philippea wrote:
Hi,

I'm trying to automate the building of a firmware. For that I'm taking a
C++ type approch.
I'd like to know if it is possoble to create a function oe a procedure to
interconnect 2 components together. Basically, the signals connected the
ports of both components will be passed to the procedure which will then
connect them together.
You could do that by using a concurrent procedure call. That means that
the procedure should be called (or rather instantiated) outside a
process. It will become a process itself. The declaration of the formal
parameters should be of class signal.

Note that signals comming from components are INOUT!
Hmm, that would be a problem, unless you also have a signal indicating
the direction. Then you could do something like:

IF dir_1to2 THEN
io1 <= 'Z';
io2 <= io1;
ELSE
io2 <= 'Z';
io1 <= io2;
END IF;

If you don't have such a signal, then have a look at
http://members.aol.com/vhdlcohen/vhdl/Models.html and particularry
http://members.aol.com/vhdlcohen/vhdl/vhdlcode/zohm0_ea.vhd

Having said all this, I'm wondering why you want to try to use a
procedure in the first place. You still have to connect the signals to
the procedure. In fact, using such a procedure doubles the amount of
signals and interconnections.

Paul.
 
jean-philippea wrote:
Thanks for the quick answer.

Unfortunatly having a direction signal is not possible.

I define my own types for the I/O ports of the component. And actually all
my components only have 1 INOUT port in which all the signals coming in
and out are gathered. Signals are unidirectional but as they are grouped
in the same type the port needs to be INOUT, which confuses my simulator
and I guess will confuse my synthesiser too...

The idea is to define a set of components and the rules/methods to
interconnect them.
This way I can have a code that will look like the following.
Note that function Connect could be overloaded for the various types of
signals.

This create a simple easy to read code. It also make it very easy to
automate generation of code using generate statement or automatic code
generation tools for example.

signal u0_io: MyTypeA;
signal u1_io: MyTypeB;

u0 : MyCompA
port map(
io => u0_io,
);

u1 : MyCompB
port map(
io => u1_io,
)

Connect (u0_io, u1_io)

I think this can be summed up with the quote that things shoud be "as
simple as possible, but no simpler". I think you are trying to make the
IO of signals so simple that it won't work. Signals are not exactly
wires. Signals have drivers and receivers. Although ports can be
INOUT, an assignment to a signal must be directional.

So why can't you break the INOUT ports into IN and OUT? On the other
hand, why do you need a "connect" procedure instead of just using the
same signal for both port mappings?

BTW, if MyTypeA and MyTypeB are not compatible types, you won't be able
to connect them anyway... I must say that what you are trying to do is
not very clear at all...

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
 

Welcome to EDABoard.com

Sponsor

Back
Top