Setting VHDL Global Set/Reset Emulation in Functional Simulation

When using the VHDL UniSim library, it is important to control the global signals for reset and output tristate enable. If do not control these signals, your timing simulation results will not match your functional simulation results because the initialization differs.

VHDL simulation does not support test bench driven internal global signals. If the test bench drives the global signal, a port is required. Otherwise, the global net must be driven by a component within the architecture.

Also, the register components do not have pins for the global signals because you do not want to wire to these special pre-laid nets. Instead, you want implementation to use the dedicated network on the chip.

For the HDL synthesis flow, the global reset and output tristate enable signals are emulated with the local reset and tristate enable signals. Special implementation directives are put on the nets to move them to the special pre-routed nets for global signals.

The VHDL UniSim library uses special components to drive the local reset and tristate enable signals. These components use the local signal connections to emulate the global signal, and also provide the implementation directives to ensure that the pre-routed wires are used.

You can instantiate these special components in the RTL description to ensure that all functional simulations match the timing simulation with respect to global signal initializations.

Global Signal Considerations (VHDL)

The following are important to VHDL simulation, synthesis, and implementation of global signals in FPGAs.

• The global signals have automatically generated pulses that always occur even if the behavior is not described in the front-end description. The back-annotated netlist has these global signals, to match the silicon, even if the source design does not.
  
  
• The simulation and synthesis models for registers (flip-flops and latches) and output buffers do not contain pins for the global signals. This is necessary to maintain compatibility with schematic libraries that do not require the pin to model the global signal behavior.
  
  
• VHDL does not have a standardized method for handling global signals that is acceptable within a VITAL-compatible library.
  
  
• LogiBLOX generates modules that are represented as behavioral models and require a different way to handle the global signal, yet still maintain compatibility with the method used for general user-defined logic and LogiCOREs.
  
  
• Intellectual property cores from the LogiCORE product line are represented as behavioral, RTL, or structural models and require a different way to handle the global signal, yet still maintain compatibility with the method used for general user-defined logic and LogiBLOX.
  
  
• The design is represented at different levels of abstraction during the pre- and post-synthesis and implementation phases of the design process. The solutions work for all three levels and give consistent results.
  
  
• The place and route tools must be given special directives to identify the global signals in order to use the built-in circuitry instead of the general-purpose logic.
  
  

GSR Network Design Cases

When defining a methodology to control a device's global set/reset (GSR) network, you should consider the following three general cases.

Table 5_7 GSR Design Cases

Note: Reset-on-Configuration for PLDs is similar to Power-on-Reset for ASICs except it occurs at power-up and during configuration of the PLD.

Case 1 is defined as follows.

• Automatic pulse generation of the Reset-On-Configuration signal
  
  
• No control of GSR through a test bench
  
  
• Involves initialization of the sequential elements in a design during power-on, or initialization during configuration of the device
  
  
• Need to define the initial states of a design's sequential elements, and have these states reflected in the implemented and simulated design
  
  
• Two sub-cases
  
  
  • In Case 1A, you do not provide the simulation with an initialization pulse. The simulation model provides its own mechanism for initializing its sequential elements (such as the real device does when power is first applied).
    
    
  • In Case 1B, you can control the initializing power-on reset pulse from a test bench without a global reset pin on the FPGA. This case is applicable when system-level issues make your design's initialization synchronous to an off-chip event. In this case, you provide a pulse that initializes your design at the start of simulation time, and possibly provide further pulses as simulation time progresses (perhaps to simulate cycling power to the device). Although you are providing the reset pulse to the simulation model, this pulse is not required for the implemented device. A reset port is not required on the implemented device, however, a reset port is required in the behavioral code through which your reset pulse can be applied with test vectors during simulation.
    
    

Using VHDL Reset-On-Configuration (ROC) Cell (Case 1A)

For Case 1A, the ROC (Reset-On-Configuration) instantiated component model is used. This model creates a one-shot pulse for the global set/reset signal. The pulse width is a generic and can be configured to match the device and conditions specified. The ROC cell is in the post-routed netlist and, with the same pulse width, it mimics the pre-route global set/reset net. The following is an example of an ROC cell.

Note: The TPOR parameter from The Programmable Logic Data Book is used as the WIDTH parameter.

library IEEE;

use IEEE.std_logic_1164.all;

use IEEE.std_logic_unsigned.all;

library UNISIM;

use UNISIM.all;

entity EX_ROC is

   port (CLOCK, ENABLE : in std_logic;  

         CUP, CDOWN : out std_logic_vector (3 downto 0));

end EX_ROC;

architecture A of EX_ROC is

   signal GSR : std_logic;

   signal COUNT_UP, COUNT_DOWN : std_logic_vector (3 downto 0);

   component ROC

       port (O : out std_logic);

   end component;

begin

   U1 : ROC port map (O => GSR);



   UP_COUNTER : process (CLOCK, ENABLE, GSR)

   begin

       if (GSR = '1') then

           COUNT_UP <= "0000";

       elsif (CLOCK'event AND CLOCK = '1') then

           if (ENABLE = '1') then

               COUNT_UP <= COUNT_UP + "0001";

           end if;

       end if;

   end process UP_COUNTER;

   DOWN_COUNTER : process (CLOCK, ENABLE, GSR, COUNT_DOWN) 

   begin 

       if (GSR = '1' OR COUNT_DOWN = "0101") then 

           COUNT_DOWN <= "1111"; 

       elsif (CLOCK'event AND CLOCK = '1') then 

           if (ENABLE = '1') then

               COUNT_DOWN <= COUNT_DOWN - "0001"; 

           end if; 

       end if; 

   end process DOWN_COUNTER;

   CUP <= COUNT_UP;

   CDOWN <= COUNT_DOWN;

end A;

Using ROC Cell Implementation Model (Case 1A)

Complementary to the previous VHDL model is an implementation model that guides the place and route tool to connect the net driven by the ROC cell to the special purpose net.

This cell is created during back-annotation if you do not use the -gp or STARTUP block options. It can be instantiated in the front end to match functionality with GSR, GR, or PRLD (in both functional and timing simulation.) During back-annotation, the entity and architecture for the ROC cell is placed in your design's output VHDL file. In the front end, the entity and architecture are in the UniSim Library, requiring only a component instantiation. The ROC cell generates a one-time initial pulse to drive the GR, GSR, or PRLD net starting at time zero for a specified pulse width. You can set the pulse width with a generic in a configuration statement. The default value of the pulse width is 0 ns. This value disables the ROC cell and causes the global set/reset to be held low. (Active low resets are handled within the netlist itself and need to be inverted before using.)

ROC Test Bench (Case 1A)

With the ROC cell you can simulate with the same test bench used in RTL simulation, and you can control the width of the global set/reset signal in your implemented design. ROC cells require a generic WIDTH value, usually specified with a configuration statement. Otherwise, a generic map is required as part of the component instantiation. You can set the generic with any generic mapping method. Set the width generic after consulting The Programmable Logic Data Book for the particular part and mode implemented. For example, an XC4000E part can vary from 10 ms to 130 ms. Use the TPOR parameter in the Configuration Switching Characteristics tables for Master, Slave, and Peripheral modes. The following is the test bench for the ROC example.

library IEEE;

use IEEE.std_logic_1164.all;

use IEEE.std_logic_unsigned.all;



library UNISIM;

use UNISIM.all;



entity test_ofex_roc is end test_ofexroc;



architecture inside of test_ofex_roc is



Component ex_roc

Port ( CLOCK, ENABLE: in STD_LOGIC;

       CUP, CDOWN: out STD_LOGIC_VECTOR (3 downto 0));

End component;

.

.

.



Begin



UUT: ex_roc port map(. . . .);

.

.

.

End inside;

The best method for mapping the generic is a configuration in your test bench, as shown in the following example.

Configuration overall of test_ofexroc is

For inside

      For UUT:ex_roc

            For A

                 For U1:ROC use entity UNISIM.ROC (ROC_V)

                 Generic map (WIDTH=>52 ns);

            End for;

      End for;

End for;

End overall;

This configuration is for pre-NGDBuild simulation. A similar configuration is used for post-NGDBuild simulation. The ROC, TOC, and OSC4 are mapped to the WORK library, and corresponding architecture names may be different. Review the .vhd file created by NGD2VHDL for the current entity and architecture names for post-NGDBuild simulation.

ROC Model in Four Design Phases (Case 1A)

The following figure shows the progression of the ROC model and its interpretation in the four main design phases.

Figure 5.3 ROC Simulation and Implementation

• Behavioral Phase - In this phase, the behavioral or RTL description registers are inferred from the coding style, and the ROC cell can be instantiated. If it is not instantiated, the signal is not driven during simulation or is driven within the architecture by code that cannot be synthesized. Some synthesizers infer the local resets that are best for the global signal and insert the ROC cell automatically. When this occurs, instantiation may not be required unless RTL level simulation is needed. The synthesizer may allow you to select the reset line to drive the ROC cell. Xilinx recommends instantiation of the ROC cell during RTL coding because the global signal is easily identified. This also ensures that GSR behavior at the RTL level matches the behavior of the post-synthesis and implementation netlists.
  
  
• Synthesized Phase - In this phase, inferred registers are mapped to a technology and the ROC instantiation is either carried from the RTL or inserted by the synthesis tools. As a result, consistent global set/reset behavior is maintained between the RTL and synthesized structural descriptions during simulation.
  
  
• Implemented Phase - During implementation, the ROC is removed from the logical description that is placed and routed as a pre-existing circuit on the chip. The ROC is removed by making the output of the ROC cell appear as an open circuit. Then the implementation tool can trim all the nets driven by the ROC to the local sets or resets of the registers, and the nets are not routed in general purpose routing. All set/resets for the registers are automatically assumed to be driven by the global set/reset net so data is not lost.
  
  
• Back-annotated Phase - In this phase, the Xilinx VHDL netlist program assumes all registers are driven by the GSR net; replaces the ROC cell; and rewires it to the GSR nets in the back-annotated netlist. The GSR net is a fully wired net and the ROC cell is inserted to drive it. A similar VHDL configuration can be used to set the generic for the pulse width.
  
  

Using VHDL ROCBUF Cell (Case 1B)

For Case 1B, the ROCBUF (Reset-On-Configuration Buffer) instantiated component is used. This component creates a buffer for the global set/reset signal, and provides an input port on the buffer to drive the global set reset line. During the place and route process, this port is removed so it is not implemented on the chip. ROCBUF does not reappear in the post-routed netlist. Instead, you can select an implementation option to add a global set/reset port to the back-annotated netlist. A buffer is not necessary since the implementation directive is no longer required.

The following example illustrates how to use the ROCBUF in your designs.

library IEEE;

use IEEE.std_logic_1164.all;

use IEEE.std_logic_unsigned.all;



library UNISIM;

use UNISIM.all;

entity EX_ROCBUF is

   port (CLOCK, ENABLE, SRP : in std_logic;  

         CUP, CDOWN : out std_logic_vector (3 downto 0));

end EX_ROCBUF;

architecture A of EX_ROCBUF is

   signal GSR : std_logic;

   signal COUNT_UP, COUNT_DOWN : std_logic_vector (3 downto 0);

   component ROCBUF

       port (I : in std_logic;

             O : out std_logic);

   end component;

begin

   U1 : ROCBUF port map (I => SRP, O => GSR);

   UP_COUNTER : process (CLOCK, ENABLE, GSR)

   begin

       if (GSR = '1') then

           COUNT_UP <= "0000";

       elsif (CLOCK'event AND CLOCK = '1') then

           if (ENABLE = '1') then

               COUNT_UP <= COUNT_UP + "0001";

           end if;

       end if;

   end process UP_COUNTER;

   DOWN_COUNTER : process (CLOCK, ENABLE, GSR, COUNT_DOWN) 

   begin 

       if (GSR = '1' OR COUNT_DOWN = "0101") then 

           COUNT_DOWN <= "1111"; 

       elsif (CLOCK'event AND CLOCK = '1') then 

           if (ENABLE = '1') then

               COUNT_DOWN <= COUNT_DOWN - "0001"; 

           end if; 

       end if; 

   end process DOWN_COUNTER;

   CUP <= COUNT_UP;

   CDOWN <= COUNT_DOWN;

end A;

ROCBUF Model in Four Design Phases (Case 1B)

The following figure shows the progression of the ROCBUF model and its interpretation in the four main design phases.

Figure 5.4 ROCBUF Simulation and Implementation

• Behavioral Phase - In this phase, the behavioral or RTL description registers are inferred from the coding style, and the ROCBUF cell can be instantiated. If it is not instantiated, the signal is not driven during simulation, or it is driven within the architecture by code that cannot be synthesized. Use the ROCBUF cell instead of the ROC cell when you want test bench control of GSR simulation. Xilinx recommends instantiating the ROCBUF cell during RTL coding because the global signal is easily identified, and you are not relying on a synthesis tool feature that may not be available if ported to another tool. This also ensures that GSR behavior at the RTL level matches the behavior of the post-synthesis and implementation netlists.
  
  
• Synthesized Phase - In this phase, inferred registers are mapped to a technology and the ROCBUF instantiation is either carried from the RTL or inserted by the synthesis tools. As a result, consistent global set/reset behavior is maintained between the RTL and synthesized structural descriptions during simulation.
  
  
• Implemented Phase - During implementation, the ROCBUF is removed from the logical description that is placed and routed as a pre-existing circuit on the chip. The ROCBUF is removed by making the input and the output of the ROCBUF cell appear as an open circuit. Then the implementation tool can trim the port that drives the ROCBUF input, as well as the nets driven by the ROCBUF output. As a result, nets are not routed in general purpose routing. All set/resets for the registers are automatically assumed to be driven by the global set/reset net so data is not lost. You can use a VHDL netlist tool option to add the port back.
  
  
• Back-annotated Phase - In this phase, the Xilinx VHDL netlist program starts with all registers initialized by the GSR net, and it replaces the ROC cell it would normally insert with a port if the GSR port option is selected. The GSR net is a fully wired net driven by the added GSR port. A ROCBUF cell is not required because the port is sufficient for simulation, and implementation directives are not required
  
  

Using VHDL STARTBUF Block (Case 2A and 2B)

The STARTUP block is traditionally instantiated to identify the GR, PRLD, or GSR signals for implementation if the global reset on tristate is connected to a chip pin. However, this implementation directive component cannot be simulated, and causes warning messages from the simulator. However, you can use the STARTBUF cell instead, which can be simulated. STARTUP blocks are allowed if the warnings can be addressed or safely ignored.

For Cases 2A and 2B, use the STARTBUF cell. This cell provides access to the input and output ports of the STARTUP cell that direct the implementation tool to use the global networks. The input and output port names differ from the names of the corresponding ports of the STARTUP cell. This was done for the following reasons.

• To make the STARTBUF a model that can be simulated with inputs and outputs. The STARTUP cell hangs from the net it is connected to.
  
  
• To make one model that works for all Xilinx technologies. The XC4000 and XC5200 families require different STARTUP cells because the XC5200 has a global reset (GR) net and not a GSR.
  
  

The mapping to the architecture-specific STARTUP cell from the instantiation of the STARTBUF is done during implementation. The STARTBUF pins have the suffix “IN” (input port) or “OUT” (output port). Two additional output ports, GSROUT and GTSOUT, are available to drive a signal for clearing or setting a design's registers (GSROUT), or for tri-stating your design's I/Os (GTSOUT).

The input ports, GSRIN and GTSIN, can be connected either directly or indirectly via combinational logic to input ports of your design. Your design's input ports appear as input pins in the implemented design. The design input port connected to the input port, GSRIN, is then referred to as the device reset port, and the design input port connected to the input port, GTSIN, is referred to as the device tristate port. The following table shows the correspondence of pins between STARTBUF and STARTUP.

Table 5_8 STARTBUF/STARTUP Pin Descriptions

Note: Using STARTBUF indicates that you want to access the global set/reset and/or tristate pre-routed networks available in your design's target device. As a result, you must provide the stimulus for emulating the automatic pulse as well as the user-defined set/reset. This allows you complete control of the reset network from the test bench.

The following example shows how to use the STARTBUF cell.

library IEEE;

use IEEE.std_logic_1164.all;

use IEEE.std_logic_unsigned.all;

library UNISIM;

use UNISIM.all;

entity EX_STARTBUF is

   port (CLOCK, ENABLE, DRP, DTP : in std_logic;  

         CUP, CDOWN : out std_logic_vector (3 downto 0));

end EX_STARTBUF;

architecture A of EX_STARTBUF is

   signal GSR, GSRIN_NET, GROUND, GTS : std_logic;

   signal COUNT_UP, COUNT_DOWN : std_logic_vector (3 downto 0);

   component STARTBUF

       port (GSRIN, GTSIN, CLKIN : in std_logic; GSROUT, GTSOUT,

             DONEINOUT, Q1Q4OUT, Q2OUT, Q3OUT : out std_logic);

   end component;

begin

   GROUND <= '0';

   GSRIN_NET <= NOT DRP;

   U1 : STARTBUF port map (GSRIN => GSRIN_NET, GTSIN => DTP,

        CLKIN => GROUND, GSROUT => GSR, GTSOUT => GTS);

   UP_COUNTER : process (CLOCK, ENABLE, GSR)

   begin

       if (GSR = '1') then

           COUNT_UP <= "0000";

       elsif (CLOCK'event AND CLOCK = '1') then

           if (ENABLE = '1') then

               COUNT_UP <= COUNT_UP + "0001";

           end if;

       end if;

   end process UP_COUNTER;

   DOWN_COUNTER : process (CLOCK, ENABLE, GSR, COUNT_DOWN) 

   begin 

       if (GSR = '1' OR COUNT_DOWN = "0101") then 

           COUNT_DOWN <= "1111"; 

       elsif (CLOCK'event AND CLOCK = '1') then 

           if (ENABLE = '1') then

               COUNT_DOWN <= COUNT_DOWN - "0001"; 

           end if; 

       end if; 

   end process DOWN_COUNTER;

   CUP <= COUNT_UP when (GTS = '0' AND COUNT_UP /= "0000") else "ZZZZ";

   CDOWN <= COUNT_DOWN when (GTS = '0') else "ZZZZ";

end A;

GTS Network Design Cases

Just as for the global set/reset net there are three cases for using your device's output tristate enable (GTS) network, as shown in the following table.

Table 5_9 GTS Design Cases

Case A is defined as follows.

• Tristating of output buffers during power-on or configuration of the device
  
  
• Output buffers are tristated and reflected in the implemented and simulated design
  
  
• Two sub-cases
  
  
  • In Case A1, you do not provide the simulation with an initialization pulse. The simulation model provides its own mechanism for initializing its sequential elements (such as the real device does when power is first applied).
    
    
  • In Case A2, you can control the initializing Tristate-On-Configuration pulse. This case is applicable when system-level issues make your design's configuration synchronous with an off-chip event. In this case, you provide a pulse to tristate the output buffers at the start of simulation time, and possibly provide further pulses as simulation time progresses (perhaps to simulate cycling power to the device). Although you are providing the Tristate-On-Configuration pulse to the simulation model, this pulse is not required for the implemented device. A Tristate-On-Configuration port is not required on the implemented device, however, a TOC port is required in the behavioral code through which your TOC pulse can be applied with test vectors during simulation.
    
    

Using VHDL Tristate-On-Configuration (TOC)

The TOC cell is created if you do not use the -tp or STARTUP block options. The entity and architecture for the TOC cell is placed in the design's output VHDL file. The TOC cell generates a one-time initial pulse to drive the GR, GSR, or PRLD net starting at time `0' for a user-defined pulse width. The pulse width can be set with a generic. The default WIDTH value is 0 ns, which disables the TOC cell and holds the tristate enable low. (Active low tristate enables are handled within the netlist itself; you must invert this signal before using it.)

The TOC cell enables you to simulate with the same test bench as in the RTL simulation, and also allows you to control the width of the tristate enable signal in your implemented design.

The TOC components require a value for the generic WIDTH, usually specified with a configuration statement. Otherwise, a generic map is required as part of the component instantiation.

You may set the generic with any generic mapping method you choose. Set the WIDTH generic after consulting The Programmable Logic Data Book for the particular part and mode you have implemented. For example, an XC4000E part can vary from 10 ms to 130 ms. Use the TPOR (Power-On Reset) parameter found in the Configuration Switching Characteristics tables for Master, Slave, and Peripheral modes.

VHDL TOC Cell (Case A1)

For Case A1, use the TOC (Tristate-On-Configuration) instantiated component. This component creates a one-shot pulse for the global Tristate-On-Configuration signal. The pulse width is a generic and can be selected to match the device and conditions you want. The TOC cell is in the post-routed netlist and, with the same pulse width set, it mimics the pre-route Tristate-On-Configuration net.

TOC Cell Instantiation (Case A1)

The following is an example of how to use the TOC cell.

Note: The TPOR parameter from The Programmable Logic Data Book is used as the WIDTH parameter in this example.

library IEEE;

use IEEE.std_logic_1164.all;

use IEEE.std_logic_unsigned.all;

library UNISIM;

use UNISIM.all;

entity EX_TOC is

   port (CLOCK, ENABLE : in std_logic;  

         CUP, CDOWN : out std_logic_vector (3 downto 0));

end EX_TOC;

architecture A of EX_TOC is

   signal GSR, GTS : std_logic;

   signal COUNT_UP, COUNT_DOWN : std_logic_vector (3 downto 0);

   component ROC

       port (O : out std_logic);

   end component;

   component TOC

       port (O : out std_logic);

   end component;

begin

   U1 : ROC port map (O => GSR);

   U2 : TOC port map (O => GTS);

   UP_COUNTER : process (CLOCK, ENABLE, GSR)

   begin

       if (GSR = '1') then

           COUNT_UP <= "0000";

       elsif (CLOCK'event AND CLOCK = '1') then

           if (ENABLE = '1') then

               COUNT_UP <= COUNT_UP + "0001";

           end if;

       end if;

   end process UP_COUNTER;

   DOWN_COUNTER : process (CLOCK, ENABLE, GSR, COUNT_DOWN) 

   begin 

       if (GSR = '1' OR COUNT_DOWN = "0101") then 

           COUNT_DOWN <= "1111"; 

       elsif (CLOCK'event AND CLOCK = '1') then 

           if (ENABLE = '1') then

               COUNT_DOWN <= COUNT_DOWN - "0001"; 

           end if; 

       end if; 

   end process DOWN_COUNTER;

   CUP <= COUNT_UP when (GTS = '0' AND COUNT_UP /= "0000") else "ZZZZ";

   CDOWN <= COUNT_DOWN when (GTS = '0') else "ZZZZ";

end A;

TOC Test Bench (Case A1)

The following is the test bench for the TOC example.

library IEEE;

use IEEE.std_logic_1164.all;

use IEEE.std_logic_unsigned.all;



library UNISIM;

use UNISIM.all;



entity test_ofex_toc is end test_ofextoc;



architecture inside of test_ofex_toc is



Component ex_toc

Port ( CLOCK, ENABLE: in STD_LOGIC;

       CUP, CDOWN: out STD_LOGIC_VECTOR (3 downto 0));

End component;

.

.

.



Begin



UUT: ex_toc port map(. . . .);

.

.

.

End inside;

The best method for mapping the generic is a configuration in the test bench, as shown in the following example.

Configuration overall of test_ofextoc is

For inside

      For UUT:ex_toc

            For A

                 For U1:TOC use entity UNISIM.TOC (TOC_V)

                 Generic map (WIDTH=>52 ns);

            End for;

      End for;

End for;

End overall;

This configuration is for pre-NGDBuild simulation. A similar configuration is used for post-NGDBuild simulation. The ROC, TOC, and OSC4 are mapped to the WORK library, and corresponding architecture names may be different. Review the .vhd file created by NGD2VHDL for the current entity and architecture names for post-NGDBuild simulation.

TOC Model in Four Design Phases (Case A1)

The following figure shows the progression of the TOC model and its interpretation in the four main design phases.

Figure 5.5 TOC Simulation and Implementation

• Behavioral Phase - In this phase, the behavioral or RTL description of the output buffers are inferred from the coding style. The TOC cell can be instantiated. If it is not instantiated, the GTS signal is not driven during simulation or is driven within the architecture by code that cannot be synthesized. Some synthesizers can infer which of the local output tristate enables is best for the global signal, and will insert the TOC cell automatically so instantiation may not be required unless RTL level simulation is desired. The synthesizer may also allow you to select the output tristate enable line you want driven by the TOC cell. Instantiation of the TOC cell in the RTL description is recommended because you can immediately identify what signal is the global signal, and you are not relying on a synthesis tool feature that may not be available if ported to another tool.
  
  
• Synthesized Phase - In this phase, the inferred registers are mapped to a device, and the TOC instantiation is either carried from the RTL or is inserted by the synthesis tools. This results in maintaining consistent global output tristate enable behavior between the RTL and the synthesized structural descriptions during simulation.
  
  
• Implemented Phase - During implementation, the TOC is removed from the logical description that is placed and routed because it is a pre-existing circuit on the chip. The TOC is removed by making the input and output of the TOC cell appear as an open circuit. This allows the router to remove all nets driven by the TOC cell as if they were undriven nets. The VHDL netlist program assumes all output tristate enables are driven by the global output tristate enable so data is not lost.
  
  
• Back-annotation Phase - In this phase, the VHDL netlist tool re-inserts a TOC component for simulation purposes. The GTS net is a fully wired net and the TOC cell is inserted to drive it. You can use a configuration similar to the VHDL configuration for RTL simulation to set the generic for the pulse width.
  
  

Using VHDL TOCBUF (Case B1)

For Case B1, use the TOCBUF (Tristate-On-Configuration Buffer) instantiated component model. This model creates a buffer for the global output tristate enable signal. You now have an input port on the buffer to drive the global set reset line. The implementation model directs the place and route tool to remove the port so it is not implemented on the actual chip. The TOCBUF cell does not reappear in the post-routed netlist. Instead, you can select an option on the implementation tool to add a global output tristate enable port to the back-annotated netlist. A buffer is not necessary because the implementation directive is no longer required.

TOCBUF Model Example (Case B1)

The following is an example of the TOCBUF model.

library IEEE;

use IEEE.std_logic_1164.all;

use IEEE.std_logic_unsigned.all;

library UNISIM;

use UNISIM.all;

entity EX_TOCBUF is

   port (CLOCK, ENABLE, SRP, STP : in std_logic;  

         CUP, CDOWN : out std_logic_vector (3 downto 0));

end EX_TOCBUF;

architecture A of EX_TOCBUF is

   signal GSR, GTS : std_logic;

   signal COUNT_UP, COUNT_DOWN : std_logic_vector (3 downto 0);

   component ROCBUF

       port (I : in std_logic;

             O : out std_logic);

   end component;

   component TOCBUF

       port (I : in std_logic;

             O : out std_logic);

   end component;

begin

   U1 : ROCBUF port map (I => SRP, O => GSR);

   U2 : TOCBUF port map (I => STP, O => GTS);

   UP_COUNTER : process (CLOCK, ENABLE, GSR)

   begin

       if (GSR = '1') then

           COUNT_UP <= "0000";

       elsif (CLOCK'event AND CLOCK = '1') then

           if (ENABLE = '1') then

               COUNT_UP <= COUNT_UP + "0001";

           end if;

       end if;

   end process UP_COUNTER;

   DOWN_COUNTER : process (CLOCK, ENABLE, GSR, COUNT_DOWN) 

   begin 

       if (GSR = '1' OR COUNT_DOWN = "0101") then 

           COUNT_DOWN <= "1111"; 

       elsif (CLOCK'event AND CLOCK = '1') then 

           if (ENABLE = '1') then

               COUNT_DOWN <= COUNT_DOWN - "0001"; 

           end if; 

       end if; 

   end process DOWN_COUNTER;

   CUP <= COUNT_UP when (GTS = '0' AND COUNT_UP /= "0000") else "ZZZZ";

   CDOWN <= COUNT_DOWN when (GTS = '0') else "ZZZZ";

end A;

TOCBUF Model in Four Design Phases (Case B1)

The following figure shows the progression of the TOCBUF model and its interpretation in the four main design phases.

Figure 5.6 TOCBUF Simulation and Implementation

• Behavioral Phase - In this phase, the behavioral or RTL description of the output buffers are inferred from the coding style and may be inserted. You can instantiate the TOCBUF cell. If it is not instantiated, the GTS signal is not driven during simulation or it is driven within the architecture by code that cannot be synthesized. Some synthesizers can infer the local output tristate enables that make the best global signals, and will insert the TOCBUF cell automatically. As a result, instantiation may not be required unless you want RTL level simulation. The synthesizer can allow you to select the output tristate enable line you want driven by the TOCBUF cell. Instantiation of the TOCBUF cell in the RTL description is recommended because you can immediately identify which signal is the global signal and you are not relying on a synthesis tool feature that may not be available if ported to another tool.
  
  
• Synthesized Phase - In this phase, the inferred output buffers are mapped to a device and the TOCBUF instantiation is either carried from the RTL or is inserted by the synthesis tools. This maintains consistent global output tristate enable behavior between the RTL and the synthesized structural descriptions during simulation.
  
  
• Implemented Phase - In this phase, the TOCBUF is removed from the logical description that is placed and routed because it is a pre-existing circuit on the chip.
  
  The TOCBUF is removed by making the input and output of the TOCBUF cell appear as an open circuit. This allows the router to remove all nets driven by the TOCBUF cell as if they were undriven nets. The VHDL netlist program assumes all output tristate enables are driven by the global output tristate enable so data is not lost.
  
  
• Back-annotated Phase - In this phase, the TOCBUF cell does not reappear in the post-routed netlist. Instead, you can select an option in the implementation tool to add a global output tristate enable port to the back-annotated netlist. A buffer is not necessary because the implementation directive is no longer required. If the option is not selected, the VHDL netlist tool re-inserts a TOCBUF component for simulation purposes. The GTS net is a fully wired net and the TOCBUF cell is inserted to drive it. You can use a configuration similar to the VHDL configuration used for RTL simulation to set the generic for the pulse width.