"global" signal in VHDL

[manu]

Hello,
I'm currently working on a XILINX FPGA-based design and I'd like to
connect some signals buried deep inside the hierarchy to debug pins for
visualisation on a logic analyser.
Is there a way in VHDL to define some kind of "global signal" to pick
these signals I want to observe without having to add debug ports all
accross my design hierarchy to propagate them to the top-level debug pins ?
Thanks for your help !

Manu

note : please don't suggest me to use chipscope. My design has severe
timing constraints which prevent me from using such intrusive methods.

 

[Mike Treseler]

manu wrote:

Is there a way in VHDL to define some kind of "global signal" to pick
these signals I want to observe without having to add debug ports all
accross my design hierarchy to propagate them to the top-level debug pins ?

No, but adding a top architecture signal and OUT port
per testpoint doesn't sound too hard.

note : please don't suggest me to use chipscope. My design has severe
timing constraints which prevent me from using such intrusive methods.

I wouldn't suggest that, but I would suggest
getting a simulator and writing a testbench.
Then you can look at whatever you want from
the comfort of your cubicle.


-- Mike Treseler

 

[Charles, NG]

Have you tries something like below. It works for simulation purposes
and I'm sure it should also work for synthesis (although I have never
tried it yet):

# Globals Package
package globals_pkg is
signal observe_1 : std_logic;
end globals_pkg;

# Low Level Arch
use WORK.globals_pkg.all;
architecture bhv of deep_down is
signal what_to_watch : std_logic;
. . .
Begin
observe_1 <= what_to_watch;
End Bhv;

# Top Level Arch
use WORK.globals_pkg.all;
architecture Bhv of top_design is
. . .
Begin
trace_pin <= observe_1;
End;

Hope this helps,
Charles

 

[Barry Brown]

You can use Xilinx FPGA Editor to add "probes" to connect signals to pins.
This is done after your design's place and route is complete, so it
shouldn't tear up your routing and effect timing. These instructions are
for ISE 5.2 so the process may not be exactly the same for your version.

***************** ADDING PROBES IN XILINX ********************

* From the Xilinx Project Navigator, double-click "View/Edit Routed
Design (FPGA Editor)".
* The Xilinx FPGA Editor window will now open.
* In the File menu, select "Main Properties".
* In the dialog box, change Edit Mode to "Read Write", and unselect
"Delay Based Routing".
* In the Tools Menu, select "Probes".
* In the dialog box, click "Add".
* Choose a net, set "Select Pin Number Method" to "Manual", choose a pin
number and click the right arrow, and (optionally) enter a pin name.
* Repeat adding probes as needed.
* Click the "Save Probes" button and save for next time.
* Close, Save, Close.


"manu" <manuel.pezzin@free.fr> wrote in message
news:4406373c$0$12882$626a54ce@news.free.fr...

Hello,
I'm currently working on a XILINX FPGA-based design and I'd like to
connect some signals buried deep inside the hierarchy to debug pins for
visualisation on a logic analyser.
Is there a way in VHDL to define some kind of "global signal" to pick
these signals I want to observe without having to add debug ports all
accross my design hierarchy to propagate them to the top-level debug pins
?
Thanks for your help !

Manu

note : please don't suggest me to use chipscope. My design has severe
timing constraints which prevent me from using such intrusive methods.

 

[Peter]

manu skrev:

Hello,
I'm currently working on a XILINX FPGA-based design and I'd like to
connect some signals buried deep inside the hierarchy to debug pins for
visualisation on a logic analyser.
Is there a way in VHDL to define some kind of "global signal" to pick
these signals I want to observe without having to add debug ports all
accross my design hierarchy to propagate them to the top-level debug pins ?

Hi,

I can't say if it's useful in your case, but may I suggest using
records in port definitions on submodules and in the signals connecting
them together?
Its much easier to add or remove signals in a common record than adding
ports in the entities, the component declarations, the port mapping
etc.

/Peter

 

[ALuPin@web.de]

Hi Peter,

can you give more details on how you use these records to lead
signals out into the top level ?

Rgds
André

Hi,

I can't say if it's useful in your case, but may I suggest using
records in port definitions on submodules and in the signals connecting
them together?
Its much easier to add or remove signals in a common record than adding
ports in the entities, the component declarations, the port mapping
etc.

/Peter

 

[Peter]

Records cant be used at the top level but on lower levels.

Lets say you have an extensive interface between two submodules. Define
some records in an interface package:

type control_type is record
my_signal1 : std_logic;
my_signal2 : std_logic;
...
my_signalN: std_logic;
end record;

type status_type is record
...
...
end record;

Include the package in your design file with:
Use work.iface.all; -- Assuming the package is called iface...

Instead of using a lot of signals going in and out from each entity you
need just one in and one out:

Port(
control : In control_type;
status : Out status_type
);

Define signals of the same type to connect the port to other entities.
Inside the entity you access the signal according to the example below:

internal_sig <= control.my_signal1;

Lets say you want to add a signal between the entities. Instead of

1: Adding a new signal in the port declaration for entity 1
2: Adding a new signal in the port declaration for entity 2
3: Adding a new signal in the component declaration for entity 1
4: Adding a new signal in the component declaration for entity 2
5: Defining a new signal to connect entity 1 & 2
6: Adding the new signal to the port map for the first entity
7: Adding the new signal to the port map for the secon entity

you just add one signal to the record. Much easier...

/Peter

 

[Ben Jones]

"manu" <manuel.pezzin@free.fr> wrote in message
news:4406373c$0$12882$626a54ce@news.free.fr...

Hello,
I'm currently working on a XILINX FPGA-based design and I'd like to
connect some signals buried deep inside the hierarchy to debug pins for
visualisation on a logic analyser.

note : please don't suggest me to use chipscope. My design has severe
timing constraints which prevent me from using such intrusive methods.

If you have severe timing constraints then may I suggest being *very*
careful with the signals that you "pull out" in this way... ideally slap a
couple of levels of FFs on them before you route them to the pin, and/or
apply the appropriate timing ignore (TIG) constraints. Otherwise, you will
very likely have trouble meeting timing on your design.

Chipscope is actually very good in this respect, since the probing logic is
embedded and can therefore be closer to your pins-under-test. It is usually
good for up to 300MHz. Much less soldering/clipping required too.

Another poster suggested using a record type for breakout - I would second
that. What you need, in essence, is this (not syntax checked):

package breakout is
type debug_signals_t is record
interesting_pin : std_logic;
interesting_bus : std_logic_vector(WIDTH-1 downto 0);
more_stuff : std_logic_whatever(YOU_HAPPEN to NEED)
end record;
end package;


Then in your design files:

use work.breakout.all;

entity mydesign_top_level is
port
(
debug_trace : out debug_signals_t;

...All your other stuff...
);
end mydesign_top_level;

architecture rtl of mydesign_top_level is
begin
mdnl : mydesign_next_level
port map
( debug_trace => debug_trace,
... etc, etc...
);
end rtl;

....and so on down the hierarchy until...

architecture rtl of mydesign_interesting_level is
begin

debug_trace.interesting_pin <= internal_state_net_42;
debug_trace.interesting_bus <= internal_widget_bus_data;
... etc.

end rtl;

This reduces the amount of hacking required to change your set of breakout
signals by an order of magnitude. Essentially you use the record type as a
kind of "wormhole" to snake all your other signals through. It's not quite
"global", but it's the next best (or worst) thing.

Cheers,

-Ben-