UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor karaheart
Visitor
11,836 Views
Registered: ‎11-16-2010

"buffer" and "out" ports in XST for Spartan6

Hello everyone,

 

in last days I try to figure out why there is a general suggestion that ports of mode "buffer" should not be used even if the last VHDL LRM says that they have the same output semantics (VHDL 1076-2008 page 75, Note 7 makes this clear).

 

On the other hand there is also a good explanation, why buffers should not be used, which I think applies to VHDL-1993.

http://books.google.de/books?id=tWkfoAiXpuYC&pg=PA17&lpg=PA17&dq=difference+inout+buffer&source=bl&ots=8RWd720Q86&sig=3u26Lv8kB5kOSzPuj570DjfDS9I&hl=en&sa=X&ei=umMGUbeBH4vMswb934HYBw&ved=0CDsQ6AEwAQ#v=onepage&q=difference%20inout%20buffer&f=false

 

Nevertheless, the XST for Spartan6 is only 1993 compliant and discourages the use of "buffers" with these two statements (UG687 (v.14.1) p.35):

1) Are potential source of errors during synthesis

2) Complicate validation of post-synthesis results through simulation.

Could someone please explain me the reasons for these two points or show some references?

0 Kudos
9 Replies
Scholar austin
Scholar
11,835 Views
Registered: ‎02-27-2008

Re: "buffer" and "out" ports in XST for Spartan6

k,

 

If you are designing an ASIC, you have to make wsure that the wires you add have sufficient drive, and are re-buffered as needed.

 

In the FPGA, the interconnect takes care of this all for you.

 

It is not a verilog issue:  it is a question of how a design gets implemented.


As buffers are not required in a FPGA device (excepting global ones for clocks) it is best to let the tools insert them (or not).

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Historian
Historian
11,826 Views
Registered: ‎02-25-2008

Re: "buffer" and "out" ports in XST for Spartan6


@austin wrote:

k,

 

If you are designing an ASIC, you have to make wsure that the wires you add have sufficient drive, and are re-buffered as needed.

 

In the FPGA, the interconnect takes care of this all for you.

 

It is not a verilog issue:  it is a question of how a design gets implemented.


As buffers are not required in a FPGA device (excepting global ones for clocks) it is best to let the tools insert them (or not).

  


Austin, you are confusing the concept of an electrical buffer (low impedance driving source) with the VHDL buffer port type. They have nothing to do with each other.

----------------------------Yes, I do this for a living.
0 Kudos
Historian
Historian
11,823 Views
Registered: ‎02-25-2008

Re: "buffer" and "out" ports in XST for Spartan6


@karaheart wrote:

Hello everyone,

 

in last days I try to figure out why there is a general suggestion that ports of mode "buffer" should not be used even if the last VHDL LRM says that they have the same output semantics (VHDL 1076-2008 page 75, Note 7 makes this clear).

 

On the other hand there is also a good explanation, why buffers should not be used, which I think applies to VHDL-1993.

http://books.google.de/books?id=tWkfoAiXpuYC&pg=PA17&lpg=PA17&dq=difference+inout+buffer&source=bl&ots=8RWd720Q86&sig=3u26Lv8kB5kOSzPuj570DjfDS9I&hl=en&sa=X&ei=umMGUbeBH4vMswb934HYBw&ved=0CDsQ6AEwAQ#v=onepage&q=difference%20inout%20buffer&f=false

 

Nevertheless, the XST for Spartan6 is only 1993 compliant and discourages the use of "buffers" with these two statements (UG687 (v.14.1) p.35):

1) Are potential source of errors during synthesis

2) Complicate validation of post-synthesis results through simulation.

Could someone please explain me the reasons for these two points or show some references?


The idea behind the VHDL buffer port type is that it's a "readable output" port.  As you probably know, if you declare an output port signal foo, you can only assign to foo in your entity. It can only be on the left-hand-side of a signal assignment. 

 

Of course many signals are used inside an entity as well as being driven out the entity's ports. So if you need to do that, you have to declare an intermediate signal in the architecture, and use that intermediate as the target for the assignment as well as wherever else it's used, and then somewhere put in the simple assignment

 

    foo <= foo_i;

 

where foo is the output port and foo_i is the internal signal.

 

So buffer ports was perhepas intended to deal with that case. You don't need the intermediate, you just assign to foo as you'd like, and also you use foo on the right-hand-side of assignments inside the entity.

 

What's the problem, then? From a quick search, I found the following. It's pretty technical and someone opaque. (That's reason enough to avoid buffer ports.)

 


The Designers Guide to VHDL 2nd Edition, Ashenden, Morgan Kaufamann Pub. Page 617 - This guy was on the IEEE VHDL committee.

VHDL-87 and VHDL-93 impose a number of restrictions on how buffer ports may be interconnected with other ports. First, if the actual object associated with a buffer port of a component instance is a port of the enclosing entity, it must also be a buffer port. Second, if we associate a buffer port as an actual object with some formal port of component
instance, the formal port must also be of mode in, buffer or linkage. It may not be a port of mode out. Thus, the D_flipflop component in Figure 21-1 would have to be a buffer mode output port. Any flipflop entity bound to the flipflop instances in the counter would also require a buffer output port. Third, a buffer port can only have one source. Hence , we cannot resolve a number of sources to determine the value of a buffer port, Finally, while we can associate an actual signal with a buffer port of a component instance, that port must be the only source of the signal. Thus, we cannot use a buffer port of a component as one of a number of contributors to a resolved signal. These restrictions severely limit the uses of buffer ports, so they are not commonly used in VHDL-87 or VHDL-93.


 

 

Put simply, there's no real good reason to use a buffer port. Forget that they exist.

----------------------------Yes, I do this for a living.
0 Kudos
Scholar austin
Scholar
11,819 Views
Registered: ‎02-27-2008

Re: "buffer" and "out" ports in XST for Spartan6

b,

 

"

Port

 

Formal Definition

A channel for dynamic communication between a block and its environment.

Simplified Syntax

port ( port_declaration, port_declaration, &ldots;);

-- port declarations:

port_signal_name : in port_signal_type := initial_value

port_signal_name : out port_signal_type := initial_value

port_signal_name : inout port_signal_type := initial_value

port_signal_name : buffer port_signal_type := initial_value

port_signal_name : linkage port_signal_type := initial_value

Description

Ports are a part of the block interface: external - if defined by a design entity, or internal - if defined by a block statement. Each element listed in a port interface list declares a formal port, which provides a channel for dynamic communication between a block and its environment.

In practice, ports are most often used in entities and components, where they serve for declaring interface signals of a design entity (system design) or component, respectively.

In both cases, each interface element is a signal. It can be preceded by a keyword signal. After the signal's name, a mode is specified. The mode declares the direction of data flow through the port. There are five modes available in VHDL for ports:

  • in input port. A variable or a signal can read a value from a port of mode in, but is not allowed to assign a value to it.

  • out output port. It is allowed to make signal assignments to a port of the mode out, but it is not legal to read from it.

  • inout bi-directional port. Both assignments to such a port and reading from it are allowed.

  • buffer output port with read capability. It differs from inout in that it can be updated by at most one source, whereas inout can be updated by zero or more sources.

  • linkage . The value of the port may be read or updated, but only by appearing as an actual corresponding to an interface object of mode linkage.

If a port is declared with a reserved word bus, then the signal declared by that port is a guarded signal of signal kind bus.

A port can be assigned a default value, which is specified by an expression evaluating to the same type as the port itself.

Examples

Example 1

entity Mux8to1 is
port (
     Inputs : in Std_Logic_Vector(7 downto 0);
     Select_s : in Std_Logic_Vector(2 downto 0);
     Output : out Std_Logic
     );
end Mux8to1;"

 

 

OK -- my mistake.  "port" is a different animal.

 

I saw "buffer" in the title, and was led astray.

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Historian
Historian
11,815 Views
Registered: ‎02-25-2008

Re: "buffer" and "out" ports in XST for Spartan6

Austin,

 


OK -- my mistake.  "port" is a different animal.

 I saw "buffer" in the title, and was led astray.


 

 

No worries. The buffer port type is definitely in one of those dusty corners of VHDL. 

----------------------------Yes, I do this for a living.
0 Kudos
Instructor
Instructor
11,800 Views
Registered: ‎08-14-2007

Re: "buffer" and "out" ports in XST for Spartan6

It's strange that XST would have problems with "buffer" port types in VHDL, when it has no

issue with "output" ports in Verilog, which are essentially the same thing - i.e. output ports that

can be used inside the driving module.  I have seen buffer ports used in synthesizable code,

though not on the top level (you don't really want feedback from your output pins).

 

-- Gabor

-- Gabor
0 Kudos
Historian
Historian
11,777 Views
Registered: ‎02-25-2008

Re: "buffer" and "out" ports in XST for Spartan6


@gszakacs wrote:

It's strange that XST would have problems with "buffer" port types in VHDL, when it has no

issue with "output" ports in Verilog, which are essentially the same thing - i.e. output ports that

can be used inside the driving module.  I have seen buffer ports used in synthesizable code,

though not on the top level (you don't really want feedback from your output pins).

 

-- Gabor


The languages _are_ different.

----------------------------Yes, I do this for a living.
0 Kudos
Newbie ralblas
Newbie
9,535 Views
Registered: ‎06-14-2014

Re: "buffer" and "out" ports in XST for Spartan6

A bit late reaction, but...

I am working now for more than 20 years in a group of about 20 designers using VHDL for ASIC and FPGA design.

From the beginning on we  Always use BUFFER for nearly ALL outputs of blocks. Never had problems.

The only strange thing about BUFFER is its name.

Both mentioned remarks about buffer:

 

1) Are potential source of errors during synthesis

2) Complicate validation of post-synthesis results through simulation.

 

are in my opinion not true. In contrary, using mode OUT in combination with using an intermediate signal to re-use the output signal inside the block may give both mentioned problems!

 

Two outputs of mode BUFFER may not be connected to each other.

An output of mode OUT may not be re-used internally.

Connecting 2 outputs and at the same time reusing the signals internally may give mismatches between synthesis and simulation, that's why there are 2 different outputs defined in vhdl.

Using intermediate signals is a work-around a rule (i.e., neglect a rule), which is not there for nothing.

 

The first one, connecting 2 outputs, normally never occurs (except maybe in CPU like designs with internal tri-state buffers).

The second one, re-using a signal going to an output, occurrs may times.

So always use BUFFER, and step over it's strange name (I also don't like it).

 

Rob Alblas

 

 

0 Kudos
Participant randycason
Participant
4,158 Views
Registered: ‎08-25-2008

Re: "buffer" and "out" ports in XST for Spartan6

I've been using type buffer for outputs on VHDL modules for nearly 20 years.  Much nicer than declaring internal signals just to be able to read them in a module, right?  In fact my whole 10+ person team does as well and we never had a problem. 

 

Well.  I just ported a design from an old Spartan 3 to a Spartan 6, using ISE 14.7 (a bit old as of now, 3/13/2016) and guess what.  It disconnecting nets deep within the design and issuing "unconnected net" warnings.  Not a problem in Spartan 3, only Spartan 6.  Crazy.  After tearing my hair out for many hours, I started looking at those Xilinx warnings about all my buffer outputs everywhere, swapped a few for type "out" and voila it worked.

 

Lesson learned:  listen to tool warnings, they might be right.

0 Kudos