Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > "global" signal in VHDL

Reply
Thread Tools

"global" signal in VHDL

 
 
manu
Guest
Posts: n/a
 
      03-02-2006
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.
 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      03-02-2006
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
 
Reply With Quote
 
 
 
 
Peter
Guest
Posts: n/a
 
      03-02-2006
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

 
Reply With Quote
 
ALuPin@web.de
Guest
Posts: n/a
 
      03-02-2006
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


 
Reply With Quote
 
Peter
Guest
Posts: n/a
 
      03-02-2006
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

 
Reply With Quote
 
Ben Jones
Guest
Posts: n/a
 
      03-02-2006

"manu" <(E-Mail Removed)> wrote in message
news:4406373c$0$12882$(E-Mail Removed)...
> 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-


 
Reply With Quote
 
Charles, NG
Guest
Posts: n/a
 
      03-02-2006
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
 
Reply With Quote
 
Barry Brown
Guest
Posts: n/a
 
      03-08-2006
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" <(E-Mail Removed)> wrote in message
news:4406373c$0$12882$(E-Mail Removed)...
> 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.



 
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
VHDL-2002 vs VHDL-93 vs VHDL-87? afd VHDL 1 03-23-2007 09:33 AM
Re: How to make an internal signal embedded deep in hierarchy to a gloal output signal Weng Tianxiang VHDL 2 01-30-2007 12:58 PM
Aside from delta cycles and/or resolution functions, how can the effective value of a signal differ from a driving signal of its? Colin Paul Gloster VHDL 0 01-11-2007 01:31 PM
threading.Thread vs. signal.signal Jack Orenstein Python 0 09-17-2005 11:24 PM
Async-signal safe functions in signal handlers (unix) Michael Pronath Python 1 01-03-2005 01:10 PM



Advertisments