Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > A procedure to interconnect components

Reply
Thread Tools

A procedure to interconnect components

 
 
jean-philippea
Guest
Posts: n/a
 
      10-13-2004
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

 
Reply With Quote
 
 
 
 
Paul Uiterlinden
Guest
Posts: n/a
 
      10-14-2004
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/vhd...e/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.
 
Reply With Quote
 
 
 
 
jean-philippea
Guest
Posts: n/a
 
      10-14-2004
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

 
Reply With Quote
 
jean-philippea
Guest
Posts: n/a
 
      10-14-2004
By the way I forgot to mestion, this code will be synthesisable !...

 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      10-15-2004
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

http://www.velocityreviews.com/forums/(E-Mail Removed)
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
 
Reply With Quote
 
Paul Uiterlinden
Guest
Posts: n/a
 
      10-15-2004
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.
 
Reply With Quote
 
jean-philippea
Guest
Posts: n/a
 
      10-21-2004
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
interconnect console port orfe Cisco 1 08-19-2007 09:24 PM
Interconnect connection problem with IE Dave Computer Support 2 05-27-2007 02:22 PM
Interconnect 2 AAH Boxes phil @ home UK VOIP 2 05-06-2006 09:04 AM
Interconnect problems between XP/SP2 and 98SE =?Utf-8?B?RnJhbmsgRA==?= Wireless Networking 0 02-21-2005 09:31 PM
help, two voip network interconnect! Lin Meng VOIP 1 07-18-2003 09:36 AM



Advertisments