Does XST support global signals?
EM
I searched this newsgroup, Xilinx's website, and the XST user's guide,
but I couldn't find what I was looking for.
Does anyone know if XST supports global nets?
In my last project I used Synplicity, which allowed me to use global
nets / buses. In this new project I'm using XST. XST itself doesn't
complain, but I'm getting goofy errors with NGDBUILD. I'm just
wondering if any else has tried this.
Thanks in advance,
EM
P.S. I'm using VHDL, if that matters.
Brian Davis
>
> Does anyone know if XST supports global nets?
>
> In my last project I used Synplicity, which allowed me to use global
> nets / buses. In this new project I'm using XST. XST itself doesn't
> complain, but I'm getting goofy errors with NGDBUILD. I'm just
> wondering if any else has tried this.
>
XST has supported signals in packages for a few years now.
http://www.xilinx.com/support/answers/13895.htm
I've used a record of signals in a package as global 'probes'
in both simulation and with XST 9.x, assigned in one spot
and read in another.
Without a code snippet to illustrate your error, nor the NGDBUILD
error messages, it's tough to make any meaningful suggestions.
Are you doing anything funky with the global signal, like trying
to write to it from two places?
I'd also suggest tinkering with XST/PAR options to see whether
that affects the NGDBUILD error; e.g., turn off global optimization
and turn on the keep_hierarchy flags in XST and PAR option settings.
Brian
EM
I guess my Usenet reader was slow to update, because it didn't look
like anyone replied within 24 hours, so I stopped checking.
> http://www.xilinx.com/support/answers/13895.htm
I really appreciate the link. I experimented with their search
engine, to see if I could find the article you linked to, but no
luck. I even used the same terms they put in their description:
"signal declaration package vhdl"
and it still couldn't find the article! I guess software hasn't
completely replaced a knowledgeable, experienced human being ;)
> Are you doing anything funky with the global signal, like trying
> to write to it from two places?
Nothing that funky. We basically want a quick way to lay down probes,
to hook up to ChipScope. Our Xilinx FAE didn't seem to understand why
we wanted to use global signals. He recommended using the Chipscope
Inserter thing instead :p
> I'd also suggest tinkering with XST/PAR options to see whether
> that affects the NGDBUILD error; e.g., turn off global optimization
> and turn on the keep_hierarchy flags in XST and PAR option settings.
Great pointers. I'll have to give them a try later. Right now
there's a ton of other things on my plate.
Thanks again for the speedy and easy to understand response, Brian.
It's good to know someone else has managed to use global signals with
XST. Now we know it's worth the effort to making it work.
Brian Davis
> Thanks for the quick reply, Brian. Sorry for not responding sooner.
> I guess my Usenet reader was slow to update, because it didn't look
> like anyone replied within 24 hours, so I stopped checking.
I don't read the newsgroup using a newsreader, but just check
the google news archives from time to time; my replies sometimes
are a bit delayed.
> I experimented with their search engine, to see if I could find
> the article you linked to, but no luck. I even used the same
> terms they put in their description:
That one was old enough that it's in the archived answers.
- Go to the Xilinx webpage
- click the "advanced search" link (below the search button)
- enter your search terms
- check what to search ( answer records, archive, etc. )
Note that although the search terms are filled in again
on the results page, that is just the plain-old-search,
not the advanced one; you have to back up to the advanced
search page again to properly modify your search terms.
>
> It's good to know someone else has managed to use global signals with
> XST. Now we know it's worth the effort to making it work.
>
I'll try to extract a working example from some old code
in the next week or few if I have the time.( My from-scratch
hack at it just now got me a bunch of XST "undriven signal"
errors if I try reading the signal for synthesis outside
the level of hierarchy it's assigned in. )
I think these links originally got me pointed in this direction:
http://groups.google.com/group/comp.arch.fpga/msg/d52079ad3378b452
http://www.eda.org/comp.lang.vhdl/FAQ1.html#monitor
Brian
Brian Davis
>> It's good to know someone else has managed to use global signals
>> with XST. Now we know it's worth the effort to making it work.
>
> I'll try to extract a working example from some old code
> in the next week or few if I have the time.( My from-scratch
> hack at it just now got me a bunch of XST "undriven signal"
> errors if I try reading the signal for synthesis outside
> the level of hierarchy it's assigned in. )
>
After looking at this again, XST's support of globals
doesn't seem robust enough to use for general in-circuit
probing; in order to read a global signal that's been
assigned, the read seems to need to be within the same
entity as the assignment.
( That said, this technique does work well for simulation,
and XST will happily process those probe assignments without
needing any translate on/off directives or other code edits)
I went back and looked at the code where I'd used this
before; it had a global record with a couple dozen signals
that were used by a processor verification testbench in
simulation. That same global record was then brought out
as a port at the top level of the processor in the
synthesized design; but, as it turns out, the only signals
I hooked up to I/O for in-circuit tracing had also been
assigned at that same level of the code.
I put together a quick example below; note that this code
hasn't been simulated, so there may be silly errors.
If you synthesize it with XST 9.2i or 10.1i, only the
"probe_a" signal is actually hooked up at the top level;
"probe_b", assigned lower down, is silently deleted.
Note that XTS's RTL viewer doesn't show either probe
port in the internal schematic, but the Technology view
and report files show "probe_a" connected to a pin.
Using a signal instead of a record signal causes XST errors.
If your hierarchy isn't too deep, passing probe records
up to the top using ports may be workable as an alternative
to global signals.
Brian
--
-- <probe_pkg.vhd>
--
-- probe package
--
library ieee;
use ieee.std_logic_1164.all;
package probe_pkg is
type probe_type is record
probe_a : std_logic;
probe_b : std_logic;
end record;
signal probes : probe_type;
end probe_pkg;
--
-- <up_count.vhd>
--
-- lower level counter module
--
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use ieee.std_logic_unsigned."+";
library work;
use work.probe_pkg.all;
entity up_count is
port
(
clk : in std_logic;
count_out : out std_logic_vector(7 downto 0)
);
end up_count;
architecture arch1 of up_count is
signal count : std_logic_vector(7 downto 0) := ( others => '0');
begin
process(clk)
begin
if rising_edge(clk) then
count <= count + 1;
end if;
end process;
count_out <= count;
-- try driving global signal in probe record
probes.probe_b <= count(0);
end arch1;
--
-- <probe_top.vhd>
--
-- top level probe test
--
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.probe_pkg.all;
entity probe_top is
port
(
clk : in std_logic;
data_out : out std_logic_vector(7 downto 0);
probe_a_out : out std_logic;
probe_b_out : out std_logic
);
end probe_top;
architecture arch1 of probe_top is
signal data : std_logic_vector(7 downto 0);
begin
I_DATA : entity work.up_count
port map
(
clk => clk,
count_out => data
);
data_out <= data;
-- probe_a is assigned at the same level
probes.probe_a <= data(1);
--
-- assign probe signals to ports
--
-- probes.probe_a
-- assigned within this selfsame entity,
-- gets connected in the synthesized design
--
-- probes.probe_b
-- assigned lower down, in entity up_count,
-- is unconnected in the synthesized design
--
probe_a_out <= probes.probe_a;
probe_b_out <= probes.probe_b;
end;