Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Re: How to make an internal signal embedded deep in hierarchy to a gloal output signal

Reply
Thread Tools

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

 
 
Weng Tianxiang
Guest
Posts: n/a
 
      01-29-2007


On Jan 29, 2:10 am, Jonathan Bromley <(E-Mail Removed)>
wrote:
> On 28 Jan 2007 15:39:20 -0800, "Weng Tianxiang"
>
> <(E-Mail Removed)> 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
> (E-Mail Removed)://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



 
Reply With Quote
 
 
 
 
Neo
Guest
Posts: n/a
 
      01-30-2007

Weng Tianxiang wrote:
> On Jan 29, 2:10 am, Jonathan Bromley <(E-Mail Removed)>
> wrote:
> > On 28 Jan 2007 15:39:20 -0800, "Weng Tianxiang"
> >
> > <(E-Mail Removed)> 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
> > (E-Mail Removed)://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

 
Reply With Quote
 
 
 
 
Jonathan Bromley
Guest
Posts: n/a
 
      01-30-2007
On 29 Jan 2007 15:49:03 -0800, "Weng Tianxiang"
<(E-Mail Removed)> 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.velocityreviews.com/forums/(E-Mail Removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
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
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
How to force an internal wire which is deep inside DUT hierachy attop level testbench using VHDL design? One Cent VHDL 7 09-10-2012 10:53 PM
Assignment to output signal from internal signal not istantaneous dibacco73 VHDL 1 02-12-2009 11:28 PM
Hierarchy of objects, object "deep down below" needs to access one high up lars.uffmann@rwth-aachen.de C++ 4 12-20-2005 09:00 PM
Deep Freeze In Deep Trouble johntangelo@gmail.com Computer Security 3 10-25-2005 11:49 PM



Advertisments