Some questions about interpreting Synthesis results.

P

pallav

Guest
Hi,

This is not a post related to Verilog but more on interpreting
synthesis results. I have built the RTL of a 5-stage pipelined MIPS 1
processor in Verilog. Now, I am trying to synthesize it using Synopsys
DC Compiler. I downloaded the 'reference methodology' scripts and the
Synopsys educational 90nm technology library.

I wrote my synthesis scripts modeled after the reference methodology
scripts. To start off, I set the clock period to 10 ns (100 MHz).
Nothing too exciting. I created some group path like this:

set ports_clock_root [get_ports [all_fanout -flat -clock_tree -level
0]]
group_path -name REGOUT -to [all_outputs]
group_path -name REGIN -from [remove_from_collection [all_inputs]
$ports_clock_root]
group_path -name FEEDTHROUGH -from [remove_from_collection
[all_inputs] $ports_clock_root] -to [all_outputs]

So FEEDTHROUGH is just the delay of the logic block.The synthesis ran
OK and I'm looking at the result - mainly the timing part. The longest
delay in all three groups is reported and I notice that the Critical
Path Slack is 0 indicating no timing violation (pre place-and-route).
However, two things concern me.

Timing Path Group 'clk'
-----------------------------------
Levels of Logic: 68.00
Critical Path Length: 8.36
Critical Path Slack: 0.00
Critical Path Clk Period: 10.00
Total Negative Slack: 0.00
No. of Violating Paths: 0.00
Worst Hold Violation: -0.05
Total Hold Violation: -0.66
No. of Hold Violations: 21.00
-----------------------------------

First. the number of logic levels is 68 (mainly in the execute stage
where there is a adder (sign extension) + multiplier) (which seems
very large, but given the design is set for 100 MHz, it seems
plausible to have these many logic stages. And given the 90nm library
(fast gates), it makes sense that even with these many stages the 10ns
clock period suffices. I can try experimenting with different clock
periods). But more importantly there are 21 Hold violations.

My questions are:

1. How do hold violations arise? And what is the way to fix them?
2. If the clock period is 10 and the max delay is 8.36, why are hold
violations arising? I know that if the delay had been 10 or more, then
it would be necessary to relax the clock period.
3. Does this indicate that the RTL needs to be adjusted or is there a
way in DC compiler to fix these violations?

I also tried running DC compiler in topographical mode (where if I'm
correct, it does a rough placement/routing to extract RC values for
the wires) and even then there were 30 or so hold violations.

I was next going to run Formality (formal verification) on the
original RTL and the mapped verilog file to compare and then run my
functional test regression suite on the mapped netlist. Is there
anything else that needs to be done before attempting place-and-route
with IC compiler on the Verilog netlist?

Thanks for your time/help.

Kind regards
 
On Jul 24, 5:01 pm, pallav <pallavgu...@gmail.com> wrote:
Hi,

This is not a post related to Verilog but more on interpreting
synthesis results. I have built the RTL of a 5-stage pipelined MIPS 1
processor in Verilog. Now, I am trying to synthesize it using Synopsys
DC Compiler. I downloaded the 'reference methodology' scripts and the
Synopsys educational 90nm technology library.

I wrote my synthesis scripts modeled after the reference methodology
scripts. To start off, I set the clock period to 10 ns (100 MHz).
Nothing too exciting. I created some group path like this:

set ports_clock_root [get_ports [all_fanout -flat -clock_tree -level
0]]
group_path -name REGOUT -to [all_outputs]
group_path -name REGIN -from [remove_from_collection [all_inputs]
$ports_clock_root]
group_path -name FEEDTHROUGH -from [remove_from_collection
[all_inputs] $ports_clock_root] -to [all_outputs]

So FEEDTHROUGH is just the delay of the logic block.The synthesis ran
OK and I'm looking at the result - mainly the timing part. The longest
delay in all three groups is reported and I notice that the Critical
Path Slack is 0 indicating no timing violation (pre place-and-route).
However, two things concern me.

 Timing Path Group 'clk'
  -----------------------------------
  Levels of Logic:              68.00
  Critical Path Length:          8.36
  Critical Path Slack:           0.00
  Critical Path Clk Period:     10.00
  Total Negative Slack:          0.00
  No. of Violating Paths:        0.00
  Worst Hold Violation:         -0.05
  Total Hold Violation:         -0.66
  No. of Hold Violations:       21.00
  -----------------------------------

First. the number of logic levels is 68 (mainly in the execute stage
where there is a adder (sign extension) + multiplier) (which seems
very large, but given the design is set for 100 MHz, it seems
plausible to have these many logic stages. And given the 90nm library
(fast gates), it makes sense that even with these many stages the 10ns
clock period suffices. I can try experimenting with different clock
periods). But more importantly there are 21 Hold violations.

My questions are:

1. How do hold violations arise? And what is the way to fix them?
2. If the clock period is 10 and the max delay is 8.36, why are hold
violations arising? I know that if the delay had been 10 or more, then
it would be necessary to relax the clock period.
3. Does this indicate that the RTL needs to be adjusted or is there a
way in DC compiler to fix these violations?

I also tried running DC compiler in topographical mode (where if I'm
correct, it does a rough placement/routing to extract RC values for
the wires) and even then there were 30 or so hold violations.

I was next going to run Formality (formal verification) on the
original RTL and the mapped verilog file to compare and then run my
functional test regression suite on the mapped netlist. Is there
anything else that needs to be done before attempting place-and-route
with IC compiler on the Verilog netlist?

Thanks for your time/help.

Kind regards
The 8.5 ns paths are clearly not the ones creating hold time
violations. Is there an option for the timing report to include
the fastest paths in each time group? That's where your hold
time violations will be. Also it's not obvious how the hold
time is calculated before routing. The clock buffering will
be the critical factor, since you don't have hold time violations
without clock path skew.

HTH,
Gabor
 
On Jul 24, 5:28 pm, gabor <ga...@alacron.com> wrote:
<snip>
The 8.5 ns paths are clearly not the ones creating hold time
violations.  Is there an option for the timing report to include
the fastest paths in each time group?  That's where your hold
time violations will be.  Also it's not obvious how the hold
time is calculated before routing.  The clock buffering will
be the critical factor, since you don't have hold time violations
without clock path skew.

HTH,
Gabor
Hi,

Thanks for your response. I will look into this in more detail and see
if the timing report commands has more options to print out the
fastest paths in each group. I've been reading a bit more about back-
end design and yes, CTS would be necessary to calculate hold times.
Also there is a set_fix_hold [all_clocks] command in Synopsys IC
Compiler that might do more optimization on the clock tree to fix
these problems. I'll have to investigate that further.

Thanks


Kind regards.
 

Welcome to EDABoard.com

Sponsor

Back
Top