[SOLVED] DFT DRC - Clock connected to primary output (Design Compiler C17)

[tchisholmuk]

Hi,

I'm using Synopsys Design Compiler for a design which drives an LCD display, where the LCD's clock in (SCLK) is an output from the design.

I'd like to clock the LCD at full speed and therefore use the system clock as the SCLK, effectively passing the system clock in to the design and straight back out of the SCLK port. I'm confident I can mitagate any timing issues with the LCD data.

However, when inserting the scan path, I get a DRC DFT violation - C17 "Clock is connected to primary output". The help section states "A clock should not have a purely combinational path to a primary output", but it doesn't say why.

Can anyone explain to me why this is a bad idea? Is there any way to properly clock the LCD at the speed of the system clock?

I've tried gating the SCLK output with ScanEnable so the output SCLK is disabled when the scan path is active. I am unable to increase the system clock speed (12.8KHz) not because of timing limitations but because of external factors. The LCD supports up to 4MHz. The design could likely support 1MHz+).

Many thanks,

Tom

 

[kungchuking]

Did you use the input clock that you mentioned as a ScanClock?
Maybe you can add a scan mux to bypass it in ScanMode.
By the way, it would be easier if you could provide more information about your DFT architecture (e.g. the script u used for scan stitching).

Thanks.

 

[tchisholmuk]

Did you use the input clock that you mentioned as a ScanClock?

Yes

Maybe you can add a scan mux to bypass it in ScanMode.

Not sure what you mean by this, I've tried using an AND gate to prevent the SLCK signal reaching the output port while scan is active, but this still results in a combinational path to the output. Wouldn't using a scan mux in the path have the same effect?

By the way, it would be easier if you could provide more information about your DFT architecture (e.g. the script u used for scan stitching).

Sure, the dft commands I've used is below -

    set_dft_drc_configuration -internal_pins enable 

    set_dft_signal -view existing_dft -type ScanClock   -hookup_pin PAD_Clock/C  -timing {45 55}
    set_dft_signal -view existing_dft -type Reset       -hookup_pin SYNC_DFC1_2/Q -active_state 0

    set_dft_signal -view spec         -type ScanEnable  -hookup_pin PAD_Test/C -port Test   -active_state 1
    set_dft_signal -view spec         -type ScanDataIn  -hookup_pin PAD_SDI/C -port SDI 
    set_dft_signal -view spec         -type ScanDataOut -port SDO 

    #create test protocol
    create_test_protocol

    #dftdrc
    dft_drc

    #insert scan path
    set_scan_configuration -chain_count 1
    preview_dft
    insert_dft

    dft_drc

Cheers

 

[kungchuking]

Maybe you can try to create a scan mux as follows:

assign SCLK = scan_mode ? 1'b0 : input_clk;

Then, declare the scan_mode port as ScanMode in your dft script:

set_dft_signal -view existing -port scan_mode -active_state 1 -type ScanMode

If you're trying this, pls let me know if it works.

Thx.

 

[tchisholmuk]

set_dft_signal -view existing -port scan_mode -active_state 1 -type ScanMode
Thx.

"ScanMode" is not a valid type for set_dft_signal in Design Compiler (at least the one I'm using).

I've tried to gate the clock with a mux and the Test signal (with type ScanEnable) :

set_dft_signal -view spec         -type ScanEnable  -hookup_pin PAD_Test/C -port Test   -active_state 1

Unfortunately this didn't work.

- - - Updated - - -

Maybe you can try to create a scan mux as follows:

set_dft_signal -view existing -port scan_mode -active_state 1 -type ScanMode

Thx.

Ignore my last post, I believe I've fixed the issue using:

set_dft_signal -view existing_dft         -type TestMode  -hookup_pin PAD_Test/C -port Test   -active_state 1

This re-uses the ScanEnable pin and seems to gate the clock correctly in DC. The DRC error is now gone and the Scan Path simulates correctly with the gated SCLK behaviour as expected.

Thanks for your help!