Are Xilinx tools that bad, or am I missing something?

T

thutt

Guest
Hi,

I've got a design that is in working order, albeit with a little more
diagnostic signals still in the source than I really want. I am using
the Xilinx Spartan 3E board, and I tend to use the on-board LEDs for
diagnostic purposes.

To that end, I have an entity which controls the PS/2 keyboard
connected to my home brew computer with the following declaration:

entity harp_keyboard_controller is
generic (clock_rate : natural); -- clock speed in Hz
port(clk : in std_logic;
--->>> kbd_leds : out std_logic_vector(7 downto 0);
kbd_clk : inout std_logic; -- keyboard clock signal
kbd_data : inout std_logic; -- keyboard data signal
interrupt : out boolean;
reset : in std_logic;
enable : in boolean;
write : in boolean;
address : in std_logic_vector(1 downto 0);
data_size : in ram_types.memory_size_t;
data_write : in std_logic_vector(7 downto 0);
data_read : out std_logic_vector(7 downto 0);
ready : out boolean);
end entity harp_keyboard_controller;

The 'kbd_leds' output signal was used for diagnostics, but is no
longer needed. Because I've been burned so many times by making large
changes to my source and then having the Xilinx tools generate
something that no longer functions properly, I took a stepwise
approach and first just removed the assignments to 'kbd_leds' in the
'harp_keyboard_controller' entity.

I rebuilt my project and it still worked.

At this point, 'kbd_leds' is not assigned inside
'harp_keyboard_controller', so then I tried to remove the signal from
the entity declaration, and the corresponding assignment in the
instantiation of the 'harp_keyboard_controller' entity.

I rebuilt my project and it fails to function properly.

I added both of the latter two removed items, rebuilt and the project
works.

I then removed the assignment to the 'kbd_leds' signal in my top-level
entity and rebuilt. The project still functions properly.

It's only when I remove the signal declaration from
'harp_keyboard_controller' that the project fails to function
properly.

I'm a software guy trying to do things with hardware, and while I've
learned a lot in the past 18 months, I am confounded by what appears
to be lack of quality in the Xilinx toolchain. It doesn't seem to me
that removing a completely unused signal should have an affect on the
resulting synthesized hardware.

Am I misunderstanding something, or is the Xilinx software really that
bad? In other words, should removing a completely unused signal cause
my design to be synthesized in a way so that it no longer works?

If that's the case, then can you explain to me how that can be?

thanks for any help or advice
--
Hot glass looks just like cold glass.
 
On 06 Sep 2008 17:04:58 -0700, thutt <thutt151@comcast.net> wrote:

Hi,

I've got a design that is in working order, albeit with a little more
diagnostic signals still in the source than I really want. I am using
the Xilinx Spartan 3E board, and I tend to use the on-board LEDs for
diagnostic purposes.

To that end, I have an entity which controls the PS/2 keyboard
connected to my home brew computer with the following declaration:

entity harp_keyboard_controller is
generic (clock_rate : natural); -- clock speed in Hz
port(clk : in std_logic;
--->>> kbd_leds : out std_logic_vector(7 downto 0);
kbd_clk : inout std_logic; -- keyboard clock signal
kbd_data : inout std_logic; -- keyboard data signal
interrupt : out boolean;
reset : in std_logic;
enable : in boolean;
write : in boolean;
address : in std_logic_vector(1 downto 0);
data_size : in ram_types.memory_size_t;
data_write : in std_logic_vector(7 downto 0);
data_read : out std_logic_vector(7 downto 0);
ready : out boolean);
end entity harp_keyboard_controller;

The 'kbd_leds' output signal was used for diagnostics, but is no
longer needed.
[snip...snip...]
It's only when I remove the signal declaration from
'harp_keyboard_controller' that the project fails to function
properly.

I'm a software guy trying to do things with hardware,
Click to expand...
#include <std_disclaimer>

Me too, so maybe some of my own recent faux pas may be relevant.

and while I've
learned a lot in the past 18 months, I am confounded by what appears
to be lack of quality in the Xilinx toolchain. It doesn't seem to me
that removing a completely unused signal should have an affect on the
resulting synthesized hardware.
Click to expand...
This is somewhat of a swag but I note that kbd_leds isn't a signal, it's
one of the black box's I/O ports and hooked up to the device pins (I
guess "to its balls" is more correct, still ...). Are they still
floorplanned in your user constraints file after removing them from the
port definition?

--
Rich Webb Norfolk, VA
 
Rich Webb <bbew.ar@mapson.nozirev.ten> writes:

On 06 Sep 2008 17:04:58 -0700, thutt <thutt151@comcast.net> wrote:

Hi,

I've got a design that is in working order, albeit with a little more
diagnostic signals still in the source than I really want. I am using
the Xilinx Spartan 3E board, and I tend to use the on-board LEDs for
diagnostic purposes.

To that end, I have an entity which controls the PS/2 keyboard
connected to my home brew computer with the following declaration:
Click to expand...
<snip>

and while I've
learned a lot in the past 18 months, I am confounded by what appears
to be lack of quality in the Xilinx toolchain. It doesn't seem to me
that removing a completely unused signal should have an affect on the
resulting synthesized hardware.

This is somewhat of a swag but I note that kbd_leds isn't a signal,
it's one of the black box's I/O ports and hooked up to the device
pins (I guess "to its balls" is more correct, still ...). Are they
still floorplanned in your user constraints file after removing them
from the port definition?
Click to expand...
The 'signal' at the top level isn't removed, it's still present and
quasi-used. It works like this:

-- S3E demo board has 4 slider switches & 8 LEDs.
-- I combine the switches and the LEDs to get 16 banks of 8 LEDs.
-- I have an array, 16 x 8 of std_logic which corresponds to the
LED values.
-- The bank of LEDs which is actively connected to the actual
on-board LEDs is selected by the slider switches.

The signal which was assigned to the output port of the
'harp_keyboard_controller' entity was one element of the 16-element
array. That element of the array was not used for anything else in
the design -- it's just for outputting the most recent byte received
from the attached PS2 keyboard.

At the point that I removed the assignment to the output port in the
top level design, the 'harp_keyboard_controller' did not use the port
at all -- it did not assign anything to it at all; it was completely
unused.

So, I just don't understand why removing a port that it unused can
make the design fail.

--
Hot glass looks just like cold glass.
 
On 06 Sep 2008 20:12:16 -0700, thutt <thutt151@comcast.net> wrote:
The 'signal' at the top level isn't removed, it's still present and
quasi-used. It works like this:

-- S3E demo board has 4 slider switches & 8 LEDs.
-- I combine the switches and the LEDs to get 16 banks of 8 LEDs.
-- I have an array, 16 x 8 of std_logic which corresponds to the
LED values.
-- The bank of LEDs which is actively connected to the actual
on-board LEDs is selected by the slider switches.

The signal which was assigned to the output port of the
'harp_keyboard_controller' entity was one element of the 16-element
array. That element of the array was not used for anything else in
the design -- it's just for outputting the most recent byte received
from the attached PS2 keyboard.

At the point that I removed the assignment to the output port in the
top level design, the 'harp_keyboard_controller' did not use the port
at all -- it did not assign anything to it at all; it was completely
unused.

So, I just don't understand why removing a port that it unused can
make the design fail.
Click to expand...
I have one question and a suggestion. What exactly do you mean by
"project ... fails to function properly" ? What parts of it break
down? That may help to figure out what's going on.
The suggestion is based on an assumption. If you left the switch
selection still at the keyboard output, does it help to change it to
another of the 16 possibilities?

--
Kal
 
thutt wrote:
Am I misunderstanding something, or is the Xilinx software really that
bad? In other words, should removing a completely unused signal cause
my design to be synthesized in a way so that it no longer works?

If that's the case, then can you explain to me how that can be?
Click to expand...
What you describe very often happens when there are constraints missing,
usually timing constraints.

When certain paths are not constrained, they tools just lay them out so
it's most convenient for them. In many cases and with slow clocks this
is not a problem. Modern FPGAs are fast, and if it's a slow clock and a
small FPGA you can basically go around the entire chip twice and not
have any timing issues.

If it's a faster clock, you eventually get to the point where a design
sometimes works and sometimes not, depending on how the tools lay out
everything. It might happen that between different synthesis runs some
paths are layed out differently, in one case just short enough that you
don't get any timing issues and in another case just too long. Things
like that happen easily if you change the code. It doesn't have to be a
major change, but every tiny change is enough to modify the starting
conditions for all the algorithms the tools implement, and then it might
happen that i.e. the placer decides it's better to place some register
in the top left instead of the bottom right, and suddenly everything
around it changes position as well.

That's what timing constraints are for: the tools should check every
path and make sure all paths are short enough so you don't get any
timing issues.

So I suggest you check if all the clocks in your design are properly
constrained. The same problems you describe can occur not only if you
don't constrain at all but also if you under-constrain, i.e. set the
clock to 25 MHz when it's actually 40 MHz or something similar.

Xilinx' Timing Analyzer can also help there, there's an option to
display all unconstrained paths in your design. Ideally, there shouldn't
be any. Plus, there shouldn't be any timing violations in the Xilinx
report files, of course.

HTH,
Sean
 
thutt wrote:
<snip>
At this point, 'kbd_leds' is not assigned inside
'harp_keyboard_controller', so then I tried to remove the signal from
the entity declaration, and the corresponding assignment in the
instantiation of the 'harp_keyboard_controller' entity.

I rebuilt my project and it fails to function properly.
snip
Click to expand...

Are you certain that all the *other* I/O in your design are properly
constrained to the pins you want? An unconstrained pin will often move
when other I/O are removed with unpredictable results.

Please let me know if you regularly visit *both* newsgroups or if only
one is your normal place to search for responses. Cross-posting to
multiple newsgroups often causes more troubles than it solves.
 
Sean Durkin <news_sep08@durkin.de> writes:

thutt wrote:
Am I misunderstanding something, or is the Xilinx software really that
bad? In other words, should removing a completely unused signal cause
my design to be synthesized in a way so that it no longer works?

If that's the case, then can you explain to me how that can be?

What you describe very often happens when there are constraints missing,
usually timing constraints.

When certain paths are not constrained, they tools just lay them out so
it's most convenient for them. In many cases and with slow clocks this
is not a problem. Modern FPGAs are fast, and if it's a slow clock and a
small FPGA you can basically go around the entire chip twice and not
have any timing issues.
Click to expand...
All the I/O is actually constrained, but I have not done anything with
timing yet. I guess I'll try to check out information about timing.
Thanks for the info. Hopefully this will pan out.

thutt
--
Inconceivable!
 
"Alessandro" <apoppi@email.it> writes:

thutt wrote:

All the I/O is actually constrained, but I have not done anything with
timing yet. I guess I'll try to check out information about timing.
Thanks for the info. Hopefully this will pan out.

I totally agree with what Sean said.

I recently ran into *exactly* the same type of problem, on a project based
on the "small" 100K gates 3E fpga.

Just assigning a signal or not to an output spare pin for debug purposes had
the power to make the entire design totally inusable. The SPI port
communicating to an external device used to crash within a few seconds after
power-on.

I've been instructed to add a "timing constraint" and now is seems (it
seems!) that the design is more stable and changing that assignment no
longer affects reliability. This is what I've added:

NET clk_pin TNM_NET = clk_ref_grp;
TIMESPEC TS01 = PERIOD : clk_ref_grp : 20.00 : PRIORITY 1; # 50.00 MHz
Click to expand...
It turned out that my problem was due to my own stupidity in trying to
delay a clock signal; I do a bit of work before I want the CPU 'turned
on', so I was delaying the clock signal to the CPU until a state
machine reached a certain state.

Bad idea. (Hey, I'm a software person learning hardware....)

I should've just used the system clock and added an 'enable' to the
CPU. In fact, that's what I did and that timeing error went away.

I'm quite curious about your timing constraint information. I spent
time on the weekend trying to find out how to do that, but the Xilinx
docs, IMHO, are just as bad as their software -- and I couldn't find
anything useful.

Where did you find this information about 'NET clk_pin'? To what do
you add it? In the VHDL? In the user constraints? I try to avoid
using ISE as much as possible, so please tell me what document you
found this information in, and then I think I can extrapolate to how
to control the command line programs (which I drive from a Makefile).

This was for the main 50MHz clock. "clk_pin" is the name of the net where
the 50MHz osc is attached. This did not bring any improvement. But when I
added another constraint, to the signal output from DCM (75MHz) then the
problem disappeared:
Click to expand...
75MHz? On a Spartan 3E board? What pin is that? Do you have the
UCF name?

<snip>

thutt
 
thutt wrote:
All the I/O is actually constrained, but I have not done anything with
timing yet. I guess I'll try to check out information about timing.
Thanks for the info. Hopefully this will pan out.
Click to expand...
If you have not created timing constraints and checked that they are met
with the static timing analysis tools, then the design can be broken
in all possible ways. Getting the timing correct is usually a big task
of the design, might be much bigger than coding the design. And the
timing closure phase usually requires loops back to the RTL and code
changes to meet the timing.

Timing is the biggest difference to software in HW, timing phase is the
phase where SW guys notice that everything that you code can not be
realized in HW in a sane way.

--Kim
 
On 09 Sep 2008 20:56:04 -0700, thutt <thutt151@comcast.net> wrote:

"Alessandro" <apoppi@email.it> writes:

thutt wrote:

All the I/O is actually constrained, but I have not done anything with
timing yet. I guess I'll try to check out information about timing.
Thanks for the info. Hopefully this will pan out.

NET clk_pin TNM_NET = clk_ref_grp;
TIMESPEC TS01 = PERIOD : clk_ref_grp : 20.00 : PRIORITY 1; # 50.00 MHz

I'm quite curious about your timing constraint information. I spent
time on the weekend trying to find out how to do that, but the Xilinx
docs, IMHO, are just as bad as their software -- and I couldn't find
anything useful.

Where did you find this information about 'NET clk_pin'? To what do
you add it? In the VHDL? In the user constraints? I try to avoid
using ISE as much as possible, so please tell me what document you
found this information in, and then I think I can extrapolate to how
to control the command line programs (which I drive from a Makefile).
Click to expand...
You can add most constraints in either the VHDL code or the user
constraints.

In practice things like pin allocations and timing constraints are
usually best added in the user constraint file (.ucf) which is easily
handled in a text editor. It's as important to your project as the VHDL
files, whether you are using the GUI or the command line.

(This keeps the VHDL cleaner and more portable for one thing. There are
a few valid uses for constraints in the VHDL code, but IMO no essential
ones. If you're curious, google for "Death of the RLOC")

It's not a bad idea to try the graphical constraints tool - once - for
adding a few constraints then use these as prototypes for the rest.
Or reading the .ucf for sample projects. Also build the project once
using the GUI, look for the "command_log" file, and extract command
lines from it.

- Brian
 
I'm quite curious about your timing constraint information.  I spent
time on the weekend trying to find out how to do that, but the Xilinx
docs, IMHO, are just as bad as their software -- and I couldn't find
anything useful.
Click to expand...
does THIS help ?

http://toolbox.xilinx.com/docsan/xilinx10/books/docs/cgd/cgd.pdf
http://toolbox.xilinx.com/docsan/xilinx10/books/docs/qst/qst.pdf

/Jochen
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top