XST: suppressing incorrect optimizations in VHDL code

Hi all,

The following VHDL code does not synthesize using XST 6.2.03:

----- start of fragment

-- The challenge is to define an entity that replicates
-- an input port (push button) to an output port (LED),
-- without declaring them in the entity's ports.

library ieee, unisim;

use ieee.std_logic_1164.all, unisim.vcomponents.all;

entity toplevel is
  -- wire input button to output LED
  -- without using a port declaration
end entity toplevel;

architecture arch of toplevel is

  signal BUTTON     : std_logic;
  signal LED        : std_logic;
  signal sig_led    : std_logic;
  signal sig_button : std_logic;

  attribute LOC : string;

  attribute LOC of BUTTON : signal is "P22";
  attribute LOC of LED    : signal is "P20";

  component OBUF is
    port (O: out std_ulogic; I: in std_ulogic);
  end component OBUF;

  component IBUF is
    port (O: out std_ulogic; I: in std_ulogic);
  end component IBUF;

begin

  button_buf : component IBUF port map(O => sig_button , I => BUTTON);
  led_buf    : component OBUF port map(O => LED        , I => not
sig_led);

  sig_led <= sig_button;
  
end architecture arch;

----- end of fragment

The following problem seems to be causing this. When a signal is used
that does not correspond to a top-level in/out port, it seems that XST
makes the following inferences:

(1) if a signal does not drive anything, it doesn't need to be
synthesized.
(2) if a signal is not assigned a value, it may be safely tied to a
constant (GND)

While most of the time, these are valid assumptions, this isn't always
the case.

In case (1), if the signal is directed to a hardware pin (using an
OBUF component), the signal is visible from the outside world, which
must count as a side effect - implying the net must be syntesized.

In case (2), if the signal is comping from a hardware pin (uning an
IBUF component), the value need not be GND (or even constant).

Having these inferences made anyway leads to all kinds of warnings,
errors (e.g. "Multiple Drivers" errors in the second case), and in
general an inability to synthesize what are (should be) completely
valid models.

Any help would be greatly appreciated.

Best regards,
  Sidney Cadot
  The Netherlands

Sidney Cadot wrote:
> 
> Hi all,
> 
> The following VHDL code does not synthesize using XST 6.2.03:
> 
> ----- start of fragment
> 
> -- The challenge is to define an entity that replicates
> -- an input port (push button) to an output port (LED),
> -- without declaring them in the entity's ports.
> 
> library ieee, unisim;
> 
> use ieee.std_logic_1164.all, unisim.vcomponents.all;
> 
> entity toplevel is
>   -- wire input button to output LED
>   -- without using a port declaration
> end entity toplevel;
> 
> architecture arch of toplevel is
> 
>   signal BUTTON     : std_logic;
>   signal LED        : std_logic;
>   signal sig_led    : std_logic;
>   signal sig_button : std_logic;
> 
>   attribute LOC : string;
> 
>   attribute LOC of BUTTON : signal is "P22";
>   attribute LOC of LED    : signal is "P20";
> 
>   component OBUF is
>     port (O: out std_ulogic; I: in std_ulogic);
>   end component OBUF;
> 
>   component IBUF is
>     port (O: out std_ulogic; I: in std_ulogic);
>   end component IBUF;
> 
> begin
> 
>   button_buf : component IBUF port map(O => sig_button , I => BUTTON);
>   led_buf    : component OBUF port map(O => LED        , I => not
> sig_led);
> 
>   sig_led <= sig_button;
> 
> end architecture arch;
> 
> ----- end of fragment
> 
> The following problem seems to be causing this. When a signal is used
> that does not correspond to a top-level in/out port, it seems that XST
> makes the following inferences:
> 
> (1) if a signal does not drive anything, it doesn't need to be
> synthesized.
> (2) if a signal is not assigned a value, it may be safely tied to a
> constant (GND)
> 
> While most of the time, these are valid assumptions, this isn't always
> the case.
> 
> In case (1), if the signal is directed to a hardware pin (using an
> OBUF component), the signal is visible from the outside world, which
> must count as a side effect - implying the net must be syntesized.
>
> In case (2), if the signal is comping from a hardware pin (uning an
> IBUF component), the value need not be GND (or even constant).

But you must actually connect it to an outside pin.  All you have done
is name the net on the other side of the IBUF or OBUF, you have not
connected it to the outside world.  That is what the port definition is
for.  Look at it from the perspective of the VHDL compiler.  Your signal
button has no driver specifed for it.  You are expecting the compiler to
figure out that an IBUF connects to the outside world.  You have to tell
it that by using a port definition.   

 
> Having these inferences made anyway leads to all kinds of warnings,
> errors (e.g. "Multiple Drivers" errors in the second case), and in
> general an inability to synthesize what are (should be) completely
> valid models.
> 
> Any help would be greatly appreciated.
> 
> Best regards,
>   Sidney Cadot
>   The Netherlands

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

rickman <spamgoeshere4@yahoo.com> wrote in message news:<4183C855.1CF5E35E@yahoo.com>...

> > In case (2), if the signal is comping from a hardware pin (uning an
> > IBUF component), the value need not be GND (or even constant).

> But you must actually connect it to an outside pin.  All you have done
> is name the net on the other side of the IBUF or OBUF, you have not
> connected it to the outside world.
> That is what the port definition is
> for.  Look at it from the perspective of the VHDL compiler.  Your signal
> button has no driver specifed for it.

I have specified that BUTTON is connected to P22, using the "LOC"
attribute, and I hoped that XST would infer that P22 would act as a
driver for the BUTTON net.

The IPAD documentation (Libraries Guide) says: "An IPAD can be
inferred by  NGDBUILD if one is missing on an IBUF or IBUFG input". I
would have expected this implicit IPAD to be flagged as a driver for
the net.

Still, I will try to instantiate an IPAD by hand, perhaps it helps.
Alternatively, I would be perfectly happy to attach another attribute
to the BUTTON to convey to XST that BUTTON is driven by P22 - if only
I knew of such an attribute.

> You are expecting the compiler to figure out that an IBUF connects to the outside world.

Yes. and I fail to see why that is a strange expectation. Surely you
must agree that, in principle, this could be the case? The compiler is
smart enough to infer IPADs (this is special-cased) - why wouldn't it
at the same time flag the inferred IPAD as a driver?

> You have to tell it that by using a port definition.

That is the easy way for sure - and the only one that currently works
as far as I can tell. However, It would help me if this wasn't so.
Allow me to provide some context on why this would help:

I am implementing a Spartan-3 based SoC, using a softcore 6502
processor; I have implemented memory-mapped I/O to the devices
available on my development board (RS232, LEDs, BUTTONS, and so on).

However, I have three types of development boards (digilent,
nuhorizons, memec), that I want to be able to use - all have different
strengths and weaknesses (well, the nuhorizons board has only
weaknesses - but that's a different matter altogether).

I would like to keep the things that are different for each of the
boards concentrated in my "memory mapped I/O" VHDL source,  for which
I have three versions - one for each board.

However, since XST needs toplevel ports for all external ports, I am
currently forced to have three different versions for two hierarchical
levels of design above the "memmapped-io.vhdl" as well, namely my
toplevel design (toplevel.vhdl) and the MMU (mmu.vhdl) that routes
between the CPU and the RAM, ROM, and I/O apertures. The only reason I
need three versions of my toplevel and mmu entities is that I must
hook up some external pins into the mmapped_io entity.

So this is the background of this. I would be pleased if I could
concentrate the development board dependencies in just one VHDL file,
which I am currently prevented from doing, since I have to thread all
I/O's from toplevel, via the MMU, to the mmapped-io component.

Regards, Sidney

Sidney Cadot wrote:
> 
> I would like to keep the things that are different for each of the
> boards concentrated in my "memory mapped I/O" VHDL source,  for which
> I have three versions - one for each board.
> 
> However, since XST needs toplevel ports for all external ports, I am
> currently forced to have three different versions for two hierarchical
> levels of design above the "memmapped-io.vhdl" as well, namely my
> toplevel design (toplevel.vhdl) and the MMU (mmu.vhdl) that routes
> between the CPU and the RAM, ROM, and I/O apertures. The only reason I
> need three versions of my toplevel and mmu entities is that I must
> hook up some external pins into the mmapped_io entity.

Maybe I am being a little dense today, but I still don't understand.  If
your IO functions are the same why would you need different ports?  What
is different between the boards that you can't just describe the
differences in the IO pin assigments in the UCF file?  Even if you don't
use a port, don't you still need different top level files?  

Instantiating the IO pads is a good idea.  If that doesn't work nothing
will.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

sidney@jigsaw.nl (Sidney Cadot) wrote in message 
<snip>
> > You have to tell it that by using a port definition.
> 
> That is the easy way for sure - and the only one that currently works
> as far as I can tell. However, It would help me if this wasn't so.
> Allow me to provide some context on why this would help:
> 
<snip>
The Designer's Guide To VHDL 2'nd Edition
Peter J. Ashenden
Page 8
"Using VHDL terminology, we call the module reg4 a design entity, and
the inputs and outputs are ports.  Figure 1-7 shows a VHDL description
of the interface to the entity. This is an example of an entity
declaration. It introduces a name for the entity and lists the input
and output ports, specifying that they carry bit values ('0' or '1')
into and out of the entity. From this we see that an entity
declaration describes the external view of the entity."

If one were to be able to snake a signal out, without mapping it thru
a port, then the entity declaration would not describe the external
view of the entity.

Newman

sidney@jigsaw.nl (Sidney Cadot) wrote in message
>
> I would like to keep the things that are different for each of the
> boards concentrated in my "memory mapped I/O" VHDL source,  for which
> I have three versions - one for each board.
> 
> However, since XST needs toplevel ports for all external ports, I am
> currently forced to have three different versions for two hierarchical
> levels of design above the "memmapped-io.vhdl" as well, namely my
> toplevel design (toplevel.vhdl) and the MMU (mmu.vhdl) that routes
> between the CPU and the RAM, ROM, and I/O apertures. The only reason I
> need three versions of my toplevel and mmu entities is that I must
> hook up some external pins into the mmapped_io entity.
> 

This isn't the perfect solution, but in verilog you could do something
like use a define to set the board type and then a bunch of ifdef's to
monkey with the port lists on the higher level modules.  You could
even use an ifdef to instantiate the correct hardware specific
low-level module.  If you don't want to contaminate the top-level
files, you can include the portions that are different out of other
files.  Basically, the idea is to use the pre-processor rather than
the HDL's abstraction model to hide the hardware details.  I'm sure
there's a similar mechanism in VHDL?

Okay, it's not perfect, but it works for C programmers writing
multi-platform code...   (What's really cool is if you run the whole
thing with a makefile, you can pass the matching parameters not only
to the hdl complier, but also to the compiler of the software that
runs on your SoC)

Chris

PS - these spartan 3 kits are fun... with the addition of one chip and
a bunch of resistors, I have one of the digilent ones pulling pictures
off an IDE hard drive and generating a color composite NTSC signal to
drive a little LCD tv...

rickman <spamgoeshere4@yahoo.com> wrote in message news:<4185154A.25EEDBE0@yahoo.com>...
> Sidney Cadot wrote:
> > 
> > I would like to keep the things that are different for each of the
> > boards concentrated in my "memory mapped I/O" VHDL source,  for which
> > I have three versions - one for each board.
> > 
> > However, since XST needs toplevel ports for all external ports, I am
> > currently forced to have three different versions for two hierarchical
> > levels of design above the "memmapped-io.vhdl" as well, namely my
> > toplevel design (toplevel.vhdl) and the MMU (mmu.vhdl) that routes
> > between the CPU and the RAM, ROM, and I/O apertures. The only reason I
> > need three versions of my toplevel and mmu entities is that I must
> > hook up some external pins into the mmapped_io entity.
> 
> Maybe I am being a little dense today, but I still don't understand.  If
> your IO functions are the same why would you need different ports?  What
> is different between the boards that you can't just describe the
> differences in the IO pin assigments in the UCF file?

I failed to make that particularly clear (sorry). There are hardware
differences, e.g.

* The number of seven-segment displays 0/1/4
* The number of LEDs 4/8/8
* The number of push-buttons: 2/3/4
* The number of sliding switches: 0/4/8
* The availability of AD/DA's on the development board
* The interface to memory residing on the memory board

> Even if you don't use a port, don't you still need different top level files?

I don't see why that would be necessary.
 
> Instantiating the IO pads is a good idea.

Unfortunately, it didn't work - apparently the IPAD components are not
contained in the UNISIM library, and just instantiated implicitly.
This rhymes with another tidbit I found in the IPAD docs (Library
Guide):

"For HDL, it is not necessary to use these elements in the design.
They will be added  automatically."

> If that doesn't work nothing will.  

Why are you so sure? I still have some hope :)

Regards, Sidney

newman5382@aol.com (newman) wrote in message news:

> The Designer's Guide To VHDL 2'nd Edition
> Peter J. Ashenden
> Page 8
> "Using VHDL terminology, we call the module reg4 a design entity, and
> the inputs and outputs are ports.  Figure 1-7 shows a VHDL description
> of the interface to the entity. This is an example of an entity
> declaration. It introduces a name for the entity and lists the input
> and output ports, specifying that they carry bit values ('0' or '1')
> into and out of the entity. From this we see that an entity
> declaration describes the external view of the entity."

> If one were to be able to snake a signal out, without mapping it thru
> a port, then the entity declaration would not describe the external
> view of the entity.

There are two answers to this: a philosophical one and a practical
one.

(1) Philosophical

The "external view" (VHDL wise) of my "mmapped_io" component is
basically that it acts like a RAM block, i.e., it has a data bus and
an address bus, and R/W control bits. The fact that these happen to do
some interesting things to hardware, should be of no concern to the
VHDL modules that instantiate an "mmapped_io" component, that's the
whole point of having memory mapped I/O.

My mmapped I/O defines a 4K aperture to hardware. My "RAM" components
describe a 4K aperture to RAM. At a higher level in my design, I
should be able to interchange them without any changes except for the
instantiated component name I think.

(2) Practical

Ashenden notwithstanding, the VHDL program shown below demonstrates
that XST can in fact bypass ports, at least for outgoing signals.
Despite the fact that it is not declared in the entity's port section,
the LED does blink when I synthesize and upload this.

All I am asking is for a way to coerce XST to handle input signals in
a similar way.

Regards, Sidney

----------------------------------- blingbling.vhdl
library ieee, unisim;

use ieee.std_logic_1164.all,
    ieee.std_logic_unsigned.all,
    unisim.vcomponents.all;

entity toplevel is
  port(CLK: in std_logic);
end entity toplevel;

architecture arch of toplevel is

  signal LED     : std_logic;
  signal sig_led : std_logic;

  attribute LOC : string;

  attribute LOC of CLK : signal is "P184";
  attribute LOC of LED : signal is "P20";

  component OBUF is
    port (O: out std_ulogic; I: in std_ulogic);
  end component OBUF;

  signal counter: std_logic_vector(23 downto 0);
  
begin

  led_buf: component OBUF port map (O => LED, I => not sig_led);
  
  process (CLK) is
  begin
    if rising_edge(CLK) then
      counter <= counter + 1;
    end if;
  end process;

  sig_led <= counter(23);
  
end architecture arch;

Sidney Cadot wrote:
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<4185154A.25EEDBE0@yahoo.com>...
> 
>>Sidney Cadot wrote:
>>
>>>I would like to keep the things that are different for each of the
>>>boards concentrated in my "memory mapped I/O" VHDL source,  for which
>>>I have three versions - one for each board.
>>>
>>>However, since XST needs toplevel ports for all external ports, I am
>>>currently forced to have three different versions for two hierarchical
>>>levels of design above the "memmapped-io.vhdl" as well, namely my
>>>toplevel design (toplevel.vhdl) and the MMU (mmu.vhdl) that routes
>>>between the CPU and the RAM, ROM, and I/O apertures. The only reason I
>>>need three versions of my toplevel and mmu entities is that I must
>>>hook up some external pins into the mmapped_io entity.
>>
>>Maybe I am being a little dense today, but I still don't understand.  If
>>your IO functions are the same why would you need different ports?  What
>>is different between the boards that you can't just describe the
>>differences in the IO pin assigments in the UCF file?
> 
> 
> I failed to make that particularly clear (sorry). There are hardware
> differences, e.g.
> 
> * The number of seven-segment displays 0/1/4
> * The number of LEDs 4/8/8
> * The number of push-buttons: 2/3/4
> * The number of sliding switches: 0/4/8
> * The availability of AD/DA's on the development board
> * The interface to memory residing on the memory board

You could select between these with active internal logic, or if you 
know the difference at compile time, with generate statements or by 
passing generic values into the entities, right?

I still must be missing something... I don't see how pushing the pin 
location assignments deep into the hierarchy makes anything easier.  You 
can always make the bus wider need it needs to be to the top level - the 
tools will optimized it down to the correct width.

>>Even if you don't use a port, don't you still need different top level files?
>  
> I don't see why that would be necessary.

Unless it is necessary because some tools require it.  :-)   I don't 
pretend to know if VHDL requires the ports to be at the top level or 
not, but it would not surprise me if some of the tools don't handle it 
correctly.

Have fun,

    Marc

Sidney Cadot wrote:
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<4185154A.25EEDBE0@yahoo.com>...
> 
> > Even if you don't use a port, don't you still need different top level files?
> 
> I don't see why that would be necessary.

I am missing something.  Are you planning to instantiate your IO ports
in low level modules or in the top module?  The example you gave is
using the top module, but I guess that was a simplification.  

If you are trying to put the IOs into lower level modules, you may find
this is a bit difficult to keep track of.  But that is just a style
preference.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX