( ESNUG 200 Item 6 ) ---------------------------------------------- [10/28/94]
From: d_pinvidic@qlc.com (Dan Pinvidic)
Subject: Concerns About SolvIt Solution To CMOS2 Long Runtimes Issue
John,
I am seeing excessively long compile times with ver. 3.1b for sequential
logic. The suggested workaround (SolvIt QA-008611):
> Workaround:
>
> /* Sample Script File */
>
> read -f vhdl design.vhd
> read h4c.db
> set_attribute find(library, h4c) delay_model "generic_cmos"
> link -all
> compile
> remove_design h4c
> read h4c.db
> link -all
> compile -incremental
> write -f db -hier -o design.db
>
> The above example script reads a library called "h4c" into memory.
> The delay model is then changed from CMOS2 to generic cmos
> using the set_attribute command. This step forces Design
> Compiler to use the Generic CMOS delay model although the
> library uses the CMOS2 modelling attributes.
>
> Compile the design with the generic CMOS model. The timing
> values will not be correct during the first compile since a
> different delay model is being used. However, they are close,
> because the intrinsic and transition delays are similar
> between the Generic CMOS and CMOS2 delay models.
>
> Then do an incremental compile with the original library (using
> the CMOS2 delay model) to clean up any remaining violations.
This is a method of reverting back to 3.0 compatability and it makes me
wonder what the new release brings to the party. The following variables
(that weren't mentioned in this SolvIt write-up) reduce the compile time,
but I wonder if there's some unseen penalty I'm paying using them...
Workaround #1
compile_use_low_timing_effort = "true"
new_seqmap_effort = 1
Workaround #2 (This reduced it from 5 1/2 hrs to 50 minutes)
hdlin_seq_device_v30_mode = true
improved_seqmap = 0
disable_sequential_degeneration = 0
- Dan Pinvidic
QLogic Corp
|
|
