multi-voltage synthesis problem

Hi
I'm doing multi-voltage synthesis with upf with no luck since timing violations are huge..
the strange thing is if I use buttom-up method, say synthrsis submodule A first and set dont_touch on module A
then sythesis the whole chip, timing is perfect.
Can anyone gave a clue or pointing me a direction? any advice will be appreciated.

more details needed, hard to understand what is going on. I assume timing passes at nominal voltage but fails at low VDD?!

Hi,

Apologize for not proving details at the first time.

My design, chip-top, containing 2 major sub-module, A & B.

Whole chip is in 5V power domain always on except module A is in 1.5V and

It can be shutdown for saving power.

Foundry provides two sets of Std. cell:

1.5V base.

5V base, level-shifter with isolation.



Method 1: synthesis whole chip top-down

read_rtl

load_upf

current_design chip_top

Compile_ultra



Above did not pass timing, lots of violation.



Method 2: synthesis 1.5V module A first then do the whole chip



read_rtl

load_upf

current_design A

compile_ultra // synthesis sub-module A

current_design chip_top

set_dont_touch A

compile_ultra // synthesis whole chip



no violation, timing pass



Can anyone advice what I was missing in Method 1(top-down)? Any inputs will be appreciated.

it's not clear to me what could have gone wrong. some things I would check
- log from load_upf. there might be some hints there for what went wrong
- timing debug on the failing paths, see where they start and where they end. do they always cross domains? or are they internal to block A?
- for both cases, count number of level shifter inserted. if it doesn't match, it is a hint by itself.

Hi ThisIsNotSam,

thanks for advice

per your suggestion:

load_upf did not show any suspicious message in either case, neither error nor warning found.

and number of level shifters are the same in both cases.

While failing path of timing violations did not cross domains, all start and end within block A. Violations are all internal to block A.

Any idea? Thanks again.

Most of EDA tools QOR optimization depends on how good is ur starting point dB, in crude terms its like a typical TSP algo. In methods2 , since sub-modules (block A) are already optimized. It presents a better starting point for chip_top synthesis optimization.

Just a quick trial, can u try 2 or 3 compile_ultra on method_1 as an experiment ?

Hi navpics1,

Per your suggestion on method_1,

Method_1: synthesis whole chip top-down

:
read_rtl
load_upf
:
current_design chip_top
:
compile_ultra
compile_ultra
compile_ultra -scan -no_autogroup
:

Timing violation, on same path for example, improves 0.2 from -12.11 to -11.09

Really appreciate for your inputs, thanks again.

paste the entire violating path here.

Hi ThisIsNotSam,
sure, for debug timing issue, reported same path on both method.

method_1:
kindly refer to attached

method_2:
kindly refer to attached

Many thanks.

the timing conditions appear to be correct for both cases. the big difference I noticed is the presence of a 14-bit adder when you utilize method1. it does not appear in method 2. as another user suggested, it might be an optimization issue that drove the tool not to look at this adder with the care it should have.

maybe there is something else going on, but I don't see it right away.