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

If you're bringing the signal out only for debug purposes first check out debug tools for the device that you're using, they may give you a way to pull out nodes from within the design out to physical pins for connection to a logic analyzer or scope. After you specify the signals you want to bring out you re-route and the signals are there for you. Once over the initial learning curve of how to do it in the first place, bringing out other signals for debug will go relatively quickly and will generally be the most efficient way of doing this in the future.

If the device software you're using does not have any such capability then you have to either propogate the signal up to the top level by adding the signal(s) as entity ports all the way to the top level (bit of a pain if you're down more than a level or two) or try defining a signal in a package where you assign the signal inside wherever it is you want to pick up the signal and then assign that as an output at the top level (not all tools support this, but support for this is improving...it's definitely less coding if it works).

Sample:

package pkg_xyz is signal My_Debug_Signal: std_ulogic; end package pkg_xyz;

Inside the architecture for where you have the signal that you'd like to monitor... work.pkg_xyz.My_Debug_Signal

messagenews: snipped-for-privacy@q2g2000cwa.googlegroups.com...> Hi,

Hi Kevin, Thank you for your advice.

I don't think following way works, but if it worked, it would have been very nice.

package pkg_xyz is signal My_Global_Error_Signal: std_ulogic; end package pkg_xyz;

In an architecture: if() then My_Global_Error_Signal cause multiple assignment???

I don't think this way works.

It means: If a signal is declared in a package as a global signal, it can be assigned many times without any multiple assignment violations.

Weng

If you're using Xilinx ISE, you can add a "probe" using the "FPGA Editor" to bring any internal signal out to a spare pin. This does not change the placement and routing of your design, so you can track down intermittent / elusive errors which might vanish if you re-synthesize.

You can minimize the work by routing a VHDL record instance from the bottom level to the top. Then you can just vary the record definition to include your debug signals.

You may even have a suitable record defined for another purpose.

-- Tim

messagenews: snipped-for-privacy@q2g2000cwa.googlegroups.com...

Editor" to

Hi, I am not debugging my design, I am designing my design and want a global error signal to indicate there is an overflow or underflow of multiple FIFOs, no matter how many FIFOs are. If one of them meets the situation, it sets the global error signal. In a design, there may be

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.

Thank you.

Weng

As far as I have seen defining global signals in packages and assigning them somewhere in your design is only OK for simulation tools.

Rgds Andre

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)

If you want to connect it to a physical pin on the FPGA infer an output buffer.

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

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