|
|
|
|
|
VHDL requires ports for all signals to be controlled by a testbench. There are VHDL specific components that can be instantiated in the RTL and post-synthesis VHDL description in order to enable the simulation of the global signals for Global Set/Reset and Global Tri-state. NGD2VHDL creates a port on the back-annotated design entity for stimulating the global set/reset or tri-state enable signals. This port does not actually exist on the configured part.
You do not need to use the -gp switch to create an external port if you instantiated a STARTUP block in the implemented design. In this case, the port is already identified and connected to the global set/reset or tri-state enable signal. If you do not use the -gp option or a STARTUP block, you will need to use a special cell. Detailed directions for specific emulation cells and their uses follow.
Note: The term “STARTUP” refers to the STARTUP block for all device families, including the Virtex STARTUP block, STARTUP_VIRTEX. The term “STARTBUF” refers to the STARTBUF cell for all device families, including the Virtex STARTBUF cell, STARTBUF_VIRTEX.
The STARTUP block is traditionally instantiated to identify the GR, PRLD, or GSR signals for implementation. However, the only time simulation is enabled in the traditional method is when the net attached to the GSR or GTS also goes off chip, because the STARTUP block does not have simulation models. You can use the following new cells to simulate global set/reset or tri-state nets in all cases, whether or not the signal goes off chip.
Note: The Virtex STARTUP block, STARTUP_VIRTEX, is a subset of the XC4000 STARTUP block. It differs from the XC4000 STARTUP block in that is has no outputs, as shown in the following figure.
Figure 21.2 STARTUP and STARTUP_VIRTEX BlocksThe STARTBUF cell passes a reset or tri-state signal in the same way that a buffer allows simulation to proceed, and it also instantiates the STARTUP block for implementation. STARTBUF is a more simulation friendly version of a typical STARTUP block. There is one version that works for all technologies, even though the XC5200 and the XC4000 STARTUP blocks have different pin names. Implementation with the correct STARTUP block is handled automatically. An instantiation example for the STARTBUF cell follows.
U1: STARTBUF port map (GSRIN => DEV_GSR_PORT, GTSIN =>DEV_GTS_PORT, CLKIN => `0', GSROUT => GSR_NET, GTSOUT => GTS_NET, Q2OUT => open, Q3OUT => open, Q1Q4OUT => open, DONEINOUT => open):
One or both of the input ports GSRIN and GTSIN of the STARTBUF component and the associated output ports GSROUT and GTSOUT can be used. The pins that are left “open” can be used to pass configuration instructions down to implementation, just as on a traditional STARTUP block. You can do this by connecting the appropriate signal to the port instead of leaving it in an “open” condition.
Note: The STARTBUF_VIRTEX cell is similar to the STARTBUF cell, but GSROUT is not available.
Global Set/Reset and Global Tristate for the Virtex STARTUP block, STARTUP_VIRTEX, and STARTBUF cell, STARTBUF_VIRTEX, operate as described in the preceding sections with the following qualifications.
This cell is created during back-annotation if you do not use the -gp option or STARTUP block options. It can be instantiated in the front end to match functionality with GSR, GR, or PRLD. (This is done in both functional and timing simulation.) During back-annotation, the entity and architecture for the ROC cell is placed in the design's output VHDL file. In the front end, the entity and architecture are in the UniSim Library, and require only a component instantiation.
The ROC 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. You can set the pulse width with a generic in a configuration statement. The default value of “width” is 0 ns, which disables the ROC cell and results in the global set/reset being held Low. (Active-Low resets are handled within the netlist itself and require you to invert this signal before using it.)
The ROC cell allows you to simulate with the same testbench as in the RTL simulation, and also allows you to control the width of the global set/reset signal in the implemented design.
The ROC 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 can 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, a XC4000E part can vary from 10 ms to 130 ms. The value to look for is the TPOR (Power-ON Reset) parameter found in the Configuration Switching Characteristics tables for master, slave, and peripheral modes.
One of the easiest methods for mapping the generic is a configuration for the user's testbench. An example testbench configuration for setting the generic is as follows.
CONFIGURATION cfg_my_timing_testbench OF my_testbench IS
FOR my_testbench_architecture
FOR ALL:my_design USE ENTITY work.my_design(structure);
FOR structure
FOR ALL:roc ENTITY USE work.roc (roc_v)
Generic MAP (width => 100 ms);
END FOR;
END FOR;
END FOR;
END FOR;
END cfg_my_timing_testbench;
The following is an instantiation example for the ROC cell.
U1: ROC port map (0 =>GSR_NET);
The ROCBUF allows you to provide stimulus for the Reset on Configuration signal through a testbench but the port connected to it is not implemented as a chip pin. The port can be brought back in the timing simulation with the -gp switch on NGD2VHDL. An example of instantiation of the ROCBUF cell follows.
U1: ROCBUF port map (I => SIM_GSR_PORT, O +> GSR_NET);
Note: This cell is not available for Virtex.
This 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 value of “width” is 0 ns, which disables the TOC cell and results in the tri-state enable being held Low. (Active-Low tri-state enables are handled within the netlist itself and require you to invert this signal before using it.)
The TOC cell allows you to simulate with the same testbench as in the RTL simulation, and also allows you to control the width of the tri-state enable signal in the 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, a XC4000E part can vary from 10 ms to 130 ms. The value to look for is the TPOR (Power-ON Reset) parameter found in the Configuration Switching Characteristics tables for master, slave, and peripheral modes.
One of the easiest methods for mapping the generic is a configuration for the user's testbench. An example testbench configuration for setting the generic is as follows.
CONFIGURATION cfg_my_timing_testbench OF my_testbench IS
FOR my_testbench_architecture
FOR ALL:my_design USE ENTITY work.my_design(structrue);
FOR structure
FOR ALL:toc ENTITY USE work.toc (toc_v)
Generic MAP (width => 100 ms);
END FOR;
END FOR;
END FOR;
END FOR;
END cfg_my_timing_testbench;
An instantiation example of the TOC cell follows.
U2: TOC port map (O => GTS_NET);
The TOCBUF allows you to provide stimulus for the global tri-state signal (GTS) through a testbench but the port connected to it is not implemented as a chip pin. The port can be brought back in the timing simulation with the -tp switch on NGD2VHDL. An example of the instantiation of the TOCBUF cell follows.
U2: TOCBUF port map (I =>SIM_GTS_PORT, O =>GTS_NET);
Oscillator output can vary within a fixed range. The cell is not included in the SimPrim library, because you cannot drive global signals in VHDL designs. Schematic simulators can define and drive global nets so the cell is not required. Verilog has the ability to drive nets within a lower level module as well. Therefore the oscillator cells are only required in VHDL. After back-annotation, their entity and architectures are contained in the design's VHDL output.
For functional simulation, they may be instantiated and simulated with the UniSim Library.
The period of the base frequency must be set in order for the simulation to proceed, because the default period of 0 ns disables the oscillator. The oscillator's frequency can very significantly with process and temperature.
Before you set the base period parameter, consult The Programmable Logic Data Book for the particular part you are using. For example, the section in The Programmable Logic Data Book for the XC4000 Series On-Chip Oscillator states that the base frequency can vary from 4MHz to 10 MHz, and is nominally 8 MHz. This means the base period generic “period_8m” in the XC4000E OSC4 VHDL model can range from 250 ns to 100ns. An example of this follows.
Note: This cell is not available for Virtex.
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
library UNISIM;
use UNISIM.all;
entity test1 is
port (DATAIN: in STD_LOGIC;
DATAOUT: out STD_LOGIC);
end test1;
architecture inside of test1 is
signal RST: STD_LOGIC;
component ROC
port(O: out STD_LOGIC);
end component;
component OSC4
port(F8M: out STD_LOGIC);
end component;
signal internalclock: STD_LOGIC;
begin
U0: ROC port map (RST);
U1: OSC4 port map (F8M=>internalclock);
process(internalclock)
begin
if (RST='1') then
DATAOUT <= '0';
elsif(internalclock'event and internalclock='1') then
DATAOUT <= DATAIN;
end if;
end process;
end inside;
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
library UNISIM;
use UNISIM.all;
entity test_oftest1 is end test_oftest1;
architecture inside of test_oftest1 is
component test1
port(DATAIN: in STD_LOGIC;
DATAOUT: out STD_LOGIC);
end component;
signal userdata, userout: STD_LOGIC;
begin
UUT: test1 port map(DATAIN=>userdata,DATAOUT=>userout);
myinput: process
begin
userdata <= '1';
wait for 299 ns;
userdata <= '0';
wait for 501 ns;
end process;
end inside;
configuration overall of test_oftest1 is
for inside
for UUT:test1
for inside
for U0:ROC use entity UNISIM.ROC(ROC_V)
generic map (WIDTH=> 52 ns);
end for;
for U1:OSC4 use entity UNISIM.OSC4(OSC4_V)
generic map (PERIOD_8M=> 25 ns);
end for;
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.