Re: How to make an internal signal embedded deep in hierarchy to a gloal output signal

Discussion in 'VHDL' started by Weng Tianxiang, Jan 29, 2007.

  1. On Jan 29, 2:10 am, Jonathan Bromley <>
    wrote:
    > On 28 Jan 2007 15:39:20 -0800, "Weng Tianxiang"
    >
    > <> wrote:
    > >I want a global error signal to indicate the situation and I am not
    > >interested in complex design and all FIFO will be called using one
    > >simple module.

    >
    > >The global error signal applies not only to FIFOs, but also to any
    > >module if there is an error situation happening and it will indicate:
    > >Hi, it is error here in this clock !!! Using this signal will greatly
    > >reduce error debugging time also.Weng,

    >
    > If this is for simulation only, then you can use global signals.
    >
    > We have, in the past, suggested using an array of global
    > signals, one for each instance that you are debugging. You can
    > then attach a generic to each instance, and use it to determine
    > which signal is driven by that instance:
    >
    > package DEBUG_SUPPORT is
    > signal s: std_logic_vector(1 to 100);
    > end package DEBUG_SUPPORT;
    >
    > use work.DEBUG_SUPPORT;
    > entity DEBUG_ME is
    > generic (DEBUG_ID: natural := 0);
    > port (....);
    > end;
    > architecture TRACEABLE of DEBUG_ME is
    > -- Internal signal that reflects the error condition
    > signal HIGH_WHEN_ERROR: std_logic;
    > begin
    > ...
    > ... all your other stuff
    > ...
    > DEBUG_TRACING: if DEBUG_ID > 0 generate
    > DEBUG_SUPPORT.s(DEBUG_ID) <=
    > '1' when HIGH_WHEN_ERROR = '1'
    > else '0';
    > end generate;
    > end;
    >
    > However, that's a little messy because you must now use a
    > complicated hierarchical configuration to assign the right
    > generic value to each instance. An alternative possibility
    > is to use a resolved signal for just one global debug signal.
    > I don't have time to sketch that out now, but if the generics
    > method doesn't work for you, reply to this and I'll try to post
    > an example in the next day or two.
    > --
    > Jonathan Bromley, Consultant
    >
    > DOULOS - Developing Design Know-how
    > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
    >
    > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
    > ://www.MYCOMPANY.com
    >
    > The contents of this message may contain personal views which
    > are not the views of Doulos Ltd., unless specifically stated.


    Hi Jonathan,
    Thank you for your help.

    I have used one of your post on how to generate random number such
    that I know your name very well.

    Actually I would like to suggest to add a VHDL language element to
    resolve the similar problem: how to set or reset a global signal
    without consideration of their assertion or deassertion time.

    Why VHDL requires that programmers be allowed to assert or deassert a
    signal only in one process is to keep their clock relationships
    without ambiguity: on which conditions it must first be asserted or
    deasserted and on what other conditions it must be deasserted or
    asserted and so on.

    But in reality, there are times, for example, in global error
    reporting mechanism, the timing to assert or deassert don't matters.
    It will be very convenient for VHDL to have a global signal type a
    signal of which can be asserted or deasserted in any processes many
    times and without consideration of their timing relations.

    There are two global types of signals: assert first and deassert 2nd.

    If above mechanism exists, my design problem can be easily resolved:
    1. In a package, declare a signal of that type(global type with
    assertion first and deassertion 2nd);
    2. In any process, code can be written to assert the signal or
    deassert the signal with adding of package;
    3. Compiler is responsible to collect all assert conditions and all
    deassertion conditions, then generate equations that first assert the
    signal and then deasser the signal. The final equation is as follows:
    if(all assertion conditions are ORed here) then
    the-first-assert-2nd-deassert-global-signal <= '1';
    elsif(all deassertion conditions are ORed here) then
    the-first-assert-2nd-deassert-global-signal <= '0';
    end if;

    This type of definitions will not add any harms to VHDL, but simplify
    programming in some situations dramatically.

    I don't know if the similar definition exists in current VHDL.

    Thank you.

    Weng
     
    Weng Tianxiang, Jan 29, 2007
    #1
    1. Advertising

  2. Weng Tianxiang

    Neo Guest

    Weng Tianxiang wrote:
    > On Jan 29, 2:10 am, Jonathan Bromley <>
    > wrote:
    > > On 28 Jan 2007 15:39:20 -0800, "Weng Tianxiang"
    > >
    > > <> wrote:
    > > >I want a global error signal to indicate the situation and I am not
    > > >interested in complex design and all FIFO will be called using one
    > > >simple module.

    > >
    > > >The global error signal applies not only to FIFOs, but also to any
    > > >module if there is an error situation happening and it will indicate:
    > > >Hi, it is error here in this clock !!! Using this signal will greatly
    > > >reduce error debugging time also.Weng,

    > >
    > > If this is for simulation only, then you can use global signals.
    > >
    > > We have, in the past, suggested using an array of global
    > > signals, one for each instance that you are debugging. You can
    > > then attach a generic to each instance, and use it to determine
    > > which signal is driven by that instance:
    > >
    > > package DEBUG_SUPPORT is
    > > signal s: std_logic_vector(1 to 100);
    > > end package DEBUG_SUPPORT;
    > >
    > > use work.DEBUG_SUPPORT;
    > > entity DEBUG_ME is
    > > generic (DEBUG_ID: natural := 0);
    > > port (....);
    > > end;
    > > architecture TRACEABLE of DEBUG_ME is
    > > -- Internal signal that reflects the error condition
    > > signal HIGH_WHEN_ERROR: std_logic;
    > > begin
    > > ...
    > > ... all your other stuff
    > > ...
    > > DEBUG_TRACING: if DEBUG_ID > 0 generate
    > > DEBUG_SUPPORT.s(DEBUG_ID) <=
    > > '1' when HIGH_WHEN_ERROR = '1'
    > > else '0';
    > > end generate;
    > > end;
    > >
    > > However, that's a little messy because you must now use a
    > > complicated hierarchical configuration to assign the right
    > > generic value to each instance. An alternative possibility
    > > is to use a resolved signal for just one global debug signal.
    > > I don't have time to sketch that out now, but if the generics
    > > method doesn't work for you, reply to this and I'll try to post
    > > an example in the next day or two.
    > > --
    > > Jonathan Bromley, Consultant
    > >
    > > DOULOS - Developing Design Know-how
    > > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
    > >
    > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
    > > ://www.MYCOMPANY.com
    > >
    > > The contents of this message may contain personal views which
    > > are not the views of Doulos Ltd., unless specifically stated.

    >
    > Hi Jonathan,
    > Thank you for your help.
    >
    > I have used one of your post on how to generate random number such
    > that I know your name very well.
    >
    > Actually I would like to suggest to add a VHDL language element to
    > resolve the similar problem: how to set or reset a global signal
    > without consideration of their assertion or deassertion time.
    >
    > Why VHDL requires that programmers be allowed to assert or deassert a
    > signal only in one process is to keep their clock relationships
    > without ambiguity: on which conditions it must first be asserted or
    > deasserted and on what other conditions it must be deasserted or
    > asserted and so on.
    >
    > But in reality, there are times, for example, in global error
    > reporting mechanism, the timing to assert or deassert don't matters.
    > It will be very convenient for VHDL to have a global signal type a
    > signal of which can be asserted or deasserted in any processes many
    > times and without consideration of their timing relations.
    >
    > There are two global types of signals: assert first and deassert 2nd.
    >
    > If above mechanism exists, my design problem can be easily resolved:
    > 1. In a package, declare a signal of that type(global type with
    > assertion first and deassertion 2nd);
    > 2. In any process, code can be written to assert the signal or
    > deassert the signal with adding of package;
    > 3. Compiler is responsible to collect all assert conditions and all
    > deassertion conditions, then generate equations that first assert the
    > signal and then deasser the signal. The final equation is as follows:
    > if(all assertion conditions are ORed here) then
    > the-first-assert-2nd-deassert-global-signal <= '1';
    > elsif(all deassertion conditions are ORed here) then
    > the-first-assert-2nd-deassert-global-signal <= '0';
    > end if;
    >
    > This type of definitions will not add any harms to VHDL, but simplify
    > programming in some situations dramatically.
    >
    > I don't know if the similar definition exists in current VHDL.
    >
    > Thank you.
    >
    > Weng


    Hi,
    The thing which you are talking about is already there in the language
    since its inception. The signals in the larger scope can be assigned
    in multiple processes, you just have to use the appropriate library
    which has the resolved signal types.

    Thanks
    neo
     
    Neo, Jan 30, 2007
    #2
    1. Advertising

  3. On 29 Jan 2007 15:49:03 -0800, "Weng Tianxiang"
    <> wrote:

    >But in reality, there are times, for example, in global error
    >reporting mechanism, the timing to assert or deassert don't matters.
    >It will be very convenient for VHDL to have a global signal type a
    >signal of which can be asserted or deasserted in any processes many
    >times and without consideration of their timing relations.


    Personally I think that you are trying to imagine a mechanism
    that is too much like hardware. This kind of idea makes sense
    only for simulation, and in simulation there are other ways to
    do it.

    One interesting possibility is to use a shared variable, and
    shared procedures, in a package. Note that this needs to
    be compiled using VHDL-93; if your compiler supports
    VHDL-2002 it will expect you to use protected types, which
    is more complicated (but still possible).

    package DEBUG_TOOLS is
    variable debug_flag: boolean := FALSE;
    procedure set_debug_flag(new_value: boolean; ID: integer);
    end;
    package body DEBUG_TOOLS is
    procedure set_debug_flag(new_value: boolean; ID: integer) is
    variable L: line;
    begin
    report "Debug flag was " & boolean'image(debug_flag) &
    ", set to " & boolean'image(new_value) &
    " by ID=" & integer'image(ID);
    debug_flag := new_value;
    end;
    end;

    Now I can "use work.DEBUG_TOOLS.all;" in any design,
    and simply by calling the procedure I can do whatever
    special action I want on reporting an error. I have used
    similar techniques to implement coverage data collection
    in VHDL without using vendor-specific signal probing tools.
    --
    Jonathan Bromley, Consultant

    DOULOS - Developing Design Know-how
    VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

    Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

    http://www.MYCOMPANY.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
     
    Jonathan Bromley, Jan 30, 2007
    #3
    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. Replies:
    4
    Views:
    389
    mlimber
    Dec 20, 2005
  2. dibacco73
    Replies:
    1
    Views:
    700
    joris
    Feb 12, 2009
  3. One Cent
    Replies:
    7
    Views:
    5,425
    ravik
    Sep 10, 2012
  4. Brian Schröder
    Replies:
    15
    Views:
    209
    Chuckl
    Dec 14, 2004
  5. Joshua Muheim
    Replies:
    14
    Views:
    324
    David Masover
    Oct 1, 2009
Loading...

Share This Page