Reduce delay by understanding Xilinx Synthesis report

Question

I am programming the 8051 instruction set in VHDL in Xilinx. After writing the logic and generating the synthesis report, I saw that the Delay is 13.330ns (frequency of 75.020 MHz) with Levels of Logic = 10.

This value is pretty less (the frequency) and I need to beef it up but I am not able to understand what/where is the delay using the synthesis report.

This is the part of the report which talks about the timing:

=========================================================================
Timing constraint: Default period analysis for Clock 'clk_div1'
  Clock period: 13.330ns (frequency: 75.020MHz)
  Total number of paths / destination ports: 156134 / 3086
-------------------------------------------------------------------------
Delay:               13.330ns (Levels of Logic = 10)
  Source:            SEQ/alu_op_code_1 (FF)
  Destination:       SEQ/alu_src_2L_7 (FF)
  Source Clock:      clk_div1 rising
  Destination Clock: clk_div1 rising

  Data Path: SEQ/alu_op_code_1 to SEQ/alu_src_2L_7
                                Gate     Net
    Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
    ----------------------------------------  ------------
     FDE:C->Q             40   0.591   1.345  SEQ/alu_op_code_1 (SEQ/alu_op_code_1)
     LUT4:I1->O            2   0.643   0.527  ALU1/ci32_SW0 (N2251)
     LUT4:I1->O            1   0.643   0.000  ALU1/adder_comp/C11_F (N1292)
     MUXF5:I0->O           3   0.276   0.531  ALU1/adder_comp/C11 (ALU1/adder_comp/C1)
     MUXF5:S->O           12   0.756   0.964  ALU1/adder_comp/C21 (ALU1/adder_comp/C2)
     LUT4:I3->O            8   0.648   0.760  ALU1/ans_L<5>104 (ALU1/ans_L<5>104)
     LUT4:I3->O           17   0.648   1.054  ALU1/ans_L<7>95_SW0 (N264)
     LUT4:I3->O            1   0.648   0.000  SEQ/alu_src_2H_and000055_SW3_F (N1304)
     MUXF5:I0->O           1   0.276   0.423  SEQ/alu_src_2H_and000055_SW3 (N599)
     LUT4_D:I3->O         15   0.648   1.049  SEQ/alu_src_2L_mux0005<7>121228 (N285)
     LUT4:I2->O            1   0.648   0.000  SEQ/alu_src_2H_mux0007<6> (SEQ/alu_src_2H_mux0007<6>)
     FDE:D                     0.252          SEQ/alu_src_2H_1
    ----------------------------------------
    Total                     13.330ns (6.677ns logic, 6.653ns route)
                                       (50.1% logic, 49.9% route)

Can someone explain what is happening?

Answer 1

A Few definitions:

• Gate delay : For an input to cause a change on the output of a block
• Net delay : Time for signal to get to next block

The 13.33ns is made up of two parts. 6.677ns of Gate delay, and 6.653ns of Net delay

The main factor in gate delay is how complex a function is contained within the cone of logic. The main factor in net delay is how many things are driven by the signals.

Each line in the report is talking about one logic block. So the first line alu_op_code_1 register, and the time it takes from the C pin (Clk) to the Q pin (output). The fanout column says how many logic blocks the Q pin drives. In this case it's 40, which is why the Net delay is quite high. It's quite understandable for a commonly used register like the opcode of an ALU to have a high fanout though.

We can also look at the path as a whole, and see that it goes from the opcode in SEQ, into an ALU. through an adder, back into the SEQ block, and eventually into another register called alu_src_2H_1. What that path is, I can't tell you. Only someone with the source can do that, and then it's a case of trying to see what logic is between those two registers.

What I'm a little confused at is that this path looks like it met timing (13.33ns is the target), but you say you need to "beef it up". Why?

Answer 2

Look at the names in the report and compare to your source code.

Basically, you have just combinational logic flowing in the "SEQ" instance from the ALU op code to an ALU output signal "alu_src_2L":

Source: SEQ/alu_op_code_1 (FF) Destination: SEQ/alu_src_2L_7 (FF)

Looking at the details, you can see that in this particular path, most of the time is used in your ALU "ALU1", and specifically in the adder/comparison logic "adder_comp". If you want to have less delay in this path, you are going to have to either optimize the logic or cut the path with another register (and make the rest of the design still work with that change).

Answer 3

First, when writing HDL or adapting HDL for an FPGA, it really pays off to understand your particular FPGA's capabilities and limitations. Xilinx does an excellent job documenting each FPGA model. Looking at the LUT4 and MUXF5 blocks, your FPGA family might be Spartan 3? By studying the datasheets you can see which hardware constructs are very efficient to implement and which require more resources. In general the closer a piece of hardware maps to what is actually on the chip, the faster it will perform and the less area it will occupy.

For example, a Xilinx LUT can also be used as a shift register, meaning that you don't have to use the flipflops in a slice. This results in a very noticeable improvement if you make sure that your shift registers are mapped to LUTs. XST tries its best with your HDL to infer these efficient mappings, but often there are stupid things that prevent these efficient mappings, like the enable signal being checked before the reset signal. Make sure you study the output of the synthesizer, and the place and route, to spot instances where you can improve the mapping onto your FPGA. The Xilinx documentation gives example VHDL and Verilog that XST can use to infer the more efficient components. Sometimes it is often easier to simply instantiate the component directly. And for complicated components, there are UNIMACROs and the COREGEN wizard, which produce very efficient hardware.

For an extreme example, the PicoBlaze microcontroller was written specifically to take advantage of the Xilinx FPGA architectures. It might be helpful to study the PicoBlaze source code to see examples of this efficient mapping.

Second, if your combinational logic path is too long, then it will limit your maximum clock frequency. Besides rewriting your code either to map better to your FPGA, or rewriting to eliminate unnecessary hardware resources, you can also insert flip flops (registers) somewhere in the middle of your combinational logic chain. In computer architecture this is called pipelining and will cause you to increase the number of cycles per instruction. For example, the PicoBlaze uses two cycles per instruction. The Intel Pentium 4 had about 17 cycles per instruction. If you are clever then you can write your HDL in a way that you start processing one instruction while at the same time finish processing the last instruction. This means that it would still take 2 clock cycles per instruction (latency), but you would be able to retire one instruction per cycle (throughput). Most microcontrollers like the 8051 and the PicoBlaze are concerned with latency and most microprocessors like the x86 architecture are concerned with throughput.