Timing Analysis in Xilinx ISE

For each design which is to be implemented, constraints should be defined to get predictable
results. The first important class of constraints was already introduced in the Synthesis
Tutorial: The definition which input/output of the implemented VHDL component should be
connected to which package pin. The second important class of constraints are timing
constraints of the design and shall be explained in the following in more detail.

Applying Timing Constraints

To have a set of meaningful timing constraints, it is at least necessary to define the required
clock period for all clocks in the design. To do so
Select the top-level entity of your design and start User Contraints -> Create Timing
Constraints in the Processes section.
Make sure that in the Sources section, under Constraint Type, Global is selected.
Then all nets which were recognized as clock in are displayed in the main workspace.
All nets which connect to a flipflop/latch clock input are automatically regarded as
clocks, thus if you use e.g. edge-sensitive contstructs to detect interrupts, the
corresponding nets may be displayed as clock nets, too.

Double-click the Period field for the input clock to define the corresponding
parameters. As it is connected to a 50 MHz clock source, it needs to be constrained to
a period of 20ns with 50% high cycle.

Constrain the other clocks accordingly. You need to constrain clocks created by
dividing the input clock, too, as the division factor is not recognized by the ISE tools
automatically. You can use the section Relative to other PERIOD TIMESPEC in the
clock period definition dialog (please note that for a divided clock, you need to define
a Multiply by factor, as this definition relates to clock period and not clock
frequency). Finally, all (real) clocks should be constrained.

Selecting the Constraint Type Ports (in Sources section), it is additionally possible
to constrain the timing at the in- and outputs. For inputs, the Pad-to-Setup time can
be defined, meaning how long before the triggering clock edge the respective input
signal is valid (this information tells the synthesis tool how much logic can be placed
before the flipflop latching this input). For outputs, the Clock-to-Pad time can be
defined, meaning when after the clock edge the output signal at a FPGA pin needs to
be valid (thus giving the information how much combinational logic can be placed in
front of that output pin).
As it is may be hard to define constraints for our design, these field can also be left
blank and it can be checked after synthesis if the respective timing values lie within
reasonable limits.

Why Applying Constraints?

One may wonder why it is necessary to apply timing constraints before the synthesis
procedure instead of synthesizing the design and then checking for the maximum clock
frequency possible.
The reason for this is that the timing information is an important hint for the synthesis tools
on how to implement the design: There are usually many ways to implement logic with a
given functionality. If the synthesis/mapping/place & route tools recognize that certain blocks
do not fulfil a timing requirement, these blocks may be optimized in terms of placement and
logic design, possibly at the cost of an increased area. This is illustrated in the following
figure which was created by synthesizing a design with different required clock periods, thus
illustrating how the area increases as the clock period decreases.
6

Area [normalized]

5
4
3
2
1
0
1000

1500

2000

2500

3000

3500

4000

4500

5000

Required Clock Period [ns]

Timing Analysis
To identify the critical path in a design and to check whether the timing constraints could be
fulfilled, timing analysis tools are used. There are multiple steps in the design process when
the timing can be checked:
After synthesis: Check the synthesis report (in Processes region: Synthesize XST
-> View Synthesis Report). At the end of the report, the critical path is shown.
After Mapping: Select Implement Design -> Map -> Generate Post-Map Static
Timing -> Analyze Post-Map Static Timing.

After Place & Route: Select Implement Design -> Place & Route -> Generate
Post- Place & Route Static Timing -> Analyze Post- Place & Route Static Timing.
The later in the design process the timing is checked, the more accurate the results are
(because the impact of following design steps otherwise needs to be estimated using statistical
models).
Within the timing analysis tool (started for Post-Map and Post-Place & Route Analysis) the
defined constraints (in our case: the clock periods) are shown, along with the most critical
path for this constraint and the corresponding path slack. The path slack is the difference
between the required time (here: clock period) and the actual path delay. Thus a positive slack
means the design works with the desired clock frequency, whereas a negative slack indicates a
failure (path delay is higher than the desired clock period).
By selecting a specific path in the Sources section, it is possible to inspect which instances
are on this path (displayed in the main window).

Timing Constraints +
crit. Paths for this constraint

Path details

Timed VHDL Simulation of the Synthesized Design

It is often also of interest to be able to check the dynamic timing, i.e. doing a VHDL
simulation of the synthesized model which exhibits approximately the same timing behaviour
as the actual hardware. Internally, this is a process with two steps:

The synthesis tool creates a VHDL netlist which contains all basic cells used in the
synthesized design (Look-Up-Tables, BlockRAMs, Multipliers, etc.) along with all the
interconnects.
Additionally, a SDF (Standard Delay Format) file is created which contains
information on the delay of the design elements and interconnects. This file is read by
the simulation tool (Modelsim) and used during the simulation to apply the correct
delays.

Just like the timing analysis, a timed simulation can also be conducted post-Synthesis, postMap and post-Place & Route with increasing level of accuracy.
For a post-Place & Route timed simulation
Include the testbench for the top-level entity into the ISE environment (with Add
Source). Please note: The instance name for the top-level entity within the
testbench has to be UUT (Unit under Test), otherwise the SDF delay annotation will
fail.

In the Processes section, select Implement Design -> Place & Route -> Generate
Post-Place & Route Simulation Model.
In the Sources section, select Sources for: Post-Route Simulation. The testbench
and the VHDL netlist created by Xilinx ISE is shown. You can open the netlist to get
an idea of the netlist structure created.
Select the testbench in the Sources section and in the Processes section, select
ModelSim Simulator -> Simulate Post-Place & Route Model.
Modelsim automatically starts with the correct model and the timing information. You
can double-check that the SDF model really has been included by choosing Simulate
-> Start Simulation -> Tab SDF. Here a SDF file for your design should be
assigned.

You can simulate your model as usual. You will find that the signals dont change
right after the clock edge anymore but have considerable delays.

Drawbacks of this simulation method are that due to the flattening of the design hierarchy
during synthesis, the signal visibility is reduced, and simulation speed is considerably
reduced due to the increased number of components.
It is therefore advisable to use functional simulation for logic debugging, and employ
timed simulation only to resolve actual timing problems.

Timing Issues in the UKM910

If you follow the UKM910 structure proposed in the lecture closely, it is well possible that the
critical path detected for your design is considerably longer than the required clock period.
Analyzing the critical path more closely, you may notice that it passes the result and B-Bus
several times. The reason for this is the structure of the UKM910:

Regarding only the circuit topology, a signal may travel from the data bus through the B bus
and the ALU to the result bus and back to the data bus. This is called a combinatorial loop,
a warning concerning this is issued during the synthesis step and the loop itself is
automatically broken for timing analysis. Still, a very long path remains from e.g. databus(0)
via the ALU to databus(1) via the ALU to databus(2) to databus(15).
Even though this path topologically exists, it is never used as the control ensures that one
never reads from the result bus and writes to it at the same time. This cannot be detected by
the timing analysis tool, though. Such paths are therefore called False Path.
There are means to tell the timing analysis tool that certain paths are false, so that these paths
are ignored for timing analysis. Unfortunately this does not work very well in Xilinx ISE,
though. The best solution therefore is to topologically break the combinational loop in the
design, e.g. by implementing the write-path to the data bus such that it originates at the
registers which can written to the memory instead of using the result bus as origin.