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

On Jan 29, 2:10 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On 28 Jan 2007 15:39:20 -0800, "Weng Tianxiang"
>
> <wtx...@gmail.com> 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
> jonathan.brom...@MYCOMPANY.comhttp://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

Weng Tianxiang wrote:
> On Jan 29, 2:10 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> wrote:
> > On 28 Jan 2007 15:39:20 -0800, "Weng Tianxiang"
> >
> > <wtx...@gmail.com> 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
> > jonathan.brom...@MYCOMPANY.comhttp://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

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