A procedure to interconnect components

Discussion in 'VHDL' started by jean-philippea, Oct 13, 2004.

  1. 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
     
    jean-philippea, Oct 13, 2004
    #1
    1. Advertising

  2. 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.
     
    Paul Uiterlinden, Oct 14, 2004
    #2
    1. Advertising

  3. 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
     
    jean-philippea, Oct 14, 2004
    #3
  4. By the way I forgot to mestion, this code will be synthesisable !...
     
    jean-philippea, Oct 14, 2004
    #4
  5. jean-philippea

    rickman Guest

    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


    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
     
    rickman, Oct 15, 2004
    #5
  6. 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.
     
    Paul Uiterlinden, Oct 15, 2004
    #6
  7. 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, Oct 21, 2004
    #7
    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. Dickie Black
    Replies:
    0
    Views:
    1,213
    Dickie Black
    Aug 6, 2003
  2. Raghunath
    Replies:
    0
    Views:
    485
    Raghunath
    Sep 15, 2003
  3. Mickey Segal
    Replies:
    0
    Views:
    899
    Mickey Segal
    Feb 2, 2004
  4. Mike P
    Replies:
    0
    Views:
    3,313
    Mike P
    Jun 19, 2006
  5. AlexWare
    Replies:
    2
    Views:
    764
    Paul Uiterlinden
    Oct 23, 2009
Loading...

Share This Page