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

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,

#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.

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:
> >

<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?

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.

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?

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>

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.

Muzaffer Kal <kal@dspia.com> writes:

> 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.
> 
> 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.

I'm working on building a single board computer using the S3E demo
board.  At present, I've gotten most of the component cobbled
together, and I've reached the point that I can actually write
software for the system.   I'm now working on writing a low-level
driver which will interpret the make & break codes from the PS2
keyboard.

I do not yet use the on-board RAM of the S3E board, but instead have
written a RAM simulator using the serial port on the S3E board which
is hooked up to a program running on my host computer.

When I start the RAM simulator program on the host computer, I give it
a binary file to load (the program I wish to run).

The current program I am running reads data from the keyboard and
outputs the hex values on the screen.  I'm using this information to
figure out how to write the low-level driver.

Finally, to answer your question, when the output port signal is
included in the 'harp_keyboard_controller' entity, the program which
I'm running actually executes until I stop it.

When I remove the 'kbd_leds' output port, the cpu executes a bunch of
instructions (probably a few hundred) and then hangs.

It's pretty obvious that something is wrong, but I just don't
understand how removing a completely unused signal can cause the
Xilinx tools to generate such a radically different output.

> 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?

It makes no difference.  I was originally using index '8' into the
array.  I switched it to '0' and the design still works.

Last night I also made a new signal, 'gungla' in my top level design
and used that instead of the arbitrary index into the array.

The system fails in exactly the same way as if I had removed the
output port from 'harp_keyboard_controller'.

The next test was to remove the 'kbd_leds' output port, and use:

    leds(0) <= (others => '0");

in my top level entity.  In this case, the system also fails in the
same way.

So, somehow the design is now dependent upon using some index into the
16x8 array -- the array is used only for output to the LEDs.

If you're interested in more detail, you can check out the on-going
work at http://www.harp-project.com/

The site deliberately runs behind the work that I've actually
completed, so it's not up-to-date with this issue.

I've trimmed the posting list to just comp.arch.fpga.

-- 
Inconceivable!

John_H <newsgroup@johnhandwork.com> writes:

> 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>
> 
> 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.

All the IO is constrained to specific pins using a constraints file.

-- 
Inconceivable!

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.

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!

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

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:

NET clk_pll TNM_NET = clk_ref_grp_pll;
TIMESPEC TS01 = PERIOD : clk_ref_grp_pll : 12.00 : PRIORITY 1;   # 75.00 MHz

I also added this:
TIMESPEC TS11=FROM:PADS:TO:FFS : 30 ns;
TIMESPEC TS12=FROM:FFS:TO:PADS : 30 ns;

because it was included on a xilinx 3E-board example. I don't know if is 
useful or not.

Ciao!
Alessandro


>
> thutt