Heirarchy Jumping

[Altera_Forum]

Can anyone recommend a technique in VHDL or Quartus (generic VHDL is always preferable) for debugging where I could run signals from any part of my heirarchy up to the top level of my design to turn on some debug monitoring LEDs ? Currently I just have a bus that runs from top to bottom of the design heirarchy and I sort of just tap lines on that as I need them. This seems like a lot of work, when sometimes I only want to run one line out say three levels deep. Is there some sort of ( and I know this is breaking vhdl heirarchy, but I think it would be pragmatic for debugging) global device or VHDL trick that I could use to quickly tap a signal, for example, three levels deep in my heirarchy and connect to the top level pins directly? I know about signal tap, and it's handy, but not always practical. Anyway, I can live with what I'm doing but I hate cleaning up the bussing mess later :) . 

 Thanks!

[Altera_Forum]

It sounds like you need SignalProbe. The most extensive documentation for it is probably in the Quartus handbook. There are also other debug features documented in the handbook.

[Altera_Forum]

I have heard of that, and a co-worker of mine uses that, so I have a resource for that. I was hoping for something more generic and less dependent on quartus/altera so that it might be portable to other platforms. My guess is that this may not exist however, as it sort of breaks a protective feature of VHDL of heirarchy/compartmentalization :) .

[Altera_Forum]

Hello, 

 a very general method would be to connect a debugvar: inout debugtype through the hierarchies. The type should be defined in a package used by all design files, the debugvar can be either a signal or a collection of physical pins in design top.  Obviously, each debugvar bit can be driven only from one design location.  Regards, Frank

[Altera_Forum]

I was thinking something similar to what Frank proposed. In Frank's example, you could make debugtype a record and make it really easy to add signals to the record as needed. You could then at the top level include a generate statement based on a boolean in the package file to compile with or without the debug logic. This would allow you to not have to strip out the debug code when you get it working. In the package file, you would just have to change a generic to compile with or without the added debug logic. The generate for debug would drive the outputs based on the desired signals, and the generate without debug would drive those outputs to '0' or '1' and the logic would get optimized away.