SCAN-CHAINS Опции

[-=Vitaly=-]

Здравствуйте!

Хочу сгенерировать скан-цепочки типа multiplexed_flip_flip в DC.
Есть 2 вопросика.

1. У меня в дизайне есть клок CLK, он же будет использоваться для скан-цепочки.
это опция -clock_mixing no_mux?

2. На что влияет опция -methodology например full_scan?

Спасибо!

[grigorik]

Здравствуйте!

Хочу сгенерировать скан-цепочки типа multiplexed_flip_flip в DC.
Есть 2 вопросика.

1. У меня в дизайне есть клок CLK, он же будет использоваться для скан-цепочки.
это опция -clock_mixing no_mux?

2. На что влияет опция -methodology например full_scan?

Спасибо!

1. У меня в дизайне есть клок CLK, он же будет использоваться для скан-цепочки.
это опция -clock_mixing no_mux?

-clock_mixing don't have option "no_mux" the right is no_mix.
no_mix is the default: and it means that all cells must be clocked by the same edge of the same clock. You have one clock if all triggers are working with the same egdes you have no problem.
Otherwies if you want both types of triggers (rise edge and fall edge) to be included in scan chain use "-clock_mixing mix_edges".

2. На что влияет опция -methodology например full_scan?
This is from user guide:

In the full-scan methodology, DFT Compiler replaces all sequential cells in your design with their scannable equivalents during scan insertion.

If a sequential cell cannot be made scannable because of test design rule violations or because you have explicitly excluded the cell from the scan chain, DFT Compiler classifies the cell as a black box sequential cell during test design rule checking. Black box sequential cells lower fault coverage results. See “Scan Design Techniques” for more information on sequential cell classifications.

Because it is a more predictable methodology, full scan typically provides higher fault coverage in a shorter period of time than partial scan. Full scan also provides improved diagnostic capabilities compared to partial scan.

Because full scan substitutes scannable equivalents for all sequential cells, however, it increases design area and decreases design performance. Integration with synthesis minimizes the area and performance impact of full scan. In most cases, performance can be maintained in a full-scan design, but at the cost of additional area.

Maybe it will help you.

[-=Vitaly=-]

Спасибо, помогло.

А если в исходном верилоге заложена ручками скан-цепочка надо ли указывать синтезатору что она есть или нет?

Если да, то чем это чревато.

[-=Vitaly=-]

Делюсь простеньким скриптом, может кому надо:

Код

#Top-level synthesis script with adding scan chain
#Reads in core and lower level designs,
#compiles, adds scan.
#read lower-level designs
remove_design -all
set TOP_LEVEL div

analyze -f verilog ./src/$TOP_LEVEL.v
elaborate $TOP_LEVEL

link
create_clock SCLK -period 60 -waveform {0 50}

#Prevent changes to pads
#set_dont_touch BDR*
#set_dont_touch IBUF*
#set scan parameters & check test rules


# Use if exist scan-chain
set test_default_scan_style multiplexed_flip_flop
set_scan_configuration -style multiplexed_flip_flop -clock_mixing no_mix -chain_count 1
set_dft_signal -view existing_dft -type ScanClock -port SCLK -timing {45 55}
set_dft_signal -view existing_dft -type reset -port RSTB -active_state 0
set_dft_signal -view existing_dft -type ScanDataIn -port SCAN_IN
set_dft_signal -view existing_dft -type ScanDataOut -port SCAN_OUT
set_dft_signal -view existing_dft -type ScanEnable -port SCAN_EN -active_state 1
create_test_protocol
dft_drc

compile_ultra -scan
preview_dft
#===============================================================================
=================================

# Use for automatic scan-chain generation
#set test_default_scan_style multiplexed_flip_flop
#set_scan_configuration -style multiplexed_flip_flop -clock_mixing no_mix -chain_count 1
#set_dft_signal -view existing_dft -type ScanClock -port SCLK -timing {45 55}
#set_dft_signal -view existing_dft -type reset -port RSTB -active_state 0
#set_dft_signal -view spec -type ScanDataIn -port SCAN_IN
#set_dft_signal -view spec -type ScanDataOut -port SCAN_OUT
#set_dft_signal -view existing_dft -type ScanEnable -port SCAN_EN -active_state 1
#create_test_protocol
#dft_drc

#compile_ultra -scan
#preview_dft
#insert_dft

change_names -rules verilog -hier
write -hier -format verilog -output ./synth/dc_$TOP_LEVEL.v

[grigorik]

Спасибо, помогло.

А если в исходном верилоге заложена ручками скан-цепочка надо ли указывать синтезатору что она есть или нет?

Если да, то чем это чревато.

да,
чтобы скан-цепочка была опознана DFTC исползуй эти команды:

set_scan_state scan_existing
set_scan_path

[-=Vitaly=-]

да,
чтобы скан-цепочка была опознана DFTC исползуй эти команды:

set_scan_state scan_existing
set_scan_path

Спасибо, а в каком месте их использовать.

У меня при попытке написать

Код

set_dft_signal -view existing_dft -type ScanDataIn -port SCAN_IN
set_scan_path -scan_data_in  SCAN_IN my_chain

DFT сообщает, что порт SCAN_IN is not type of ScanDataIn в чем проблема?
при это при команде report_dft_signal он показывает табличку где этот сигнал есть и ему присвоен тип ScanDataIn

И можно ли до Тетрамакса оценить покрытие тестом в DC?

Сообщение отредактировал -=Vitaly=- - Jan 15 2008, 14:47

[grigorik]

Спасибо, а в каком месте их использовать.

У меня при попытке написать

Код

set_dft_signal -view existing_dft -type ScanDataIn -port SCAN_IN
set_scan_path -scan_data_in  SCAN_IN my_chain

DFT сообщает, что порт SCAN_IN is not type of ScanDataIn в чем проблема?
при это при команде report_dft_signal он показывает табличку где этот сигнал есть и ему присвоен тип ScanDataIn

И можно ли до Тетрамакса оценить покрытие тестом в DC?

после read_verilog, constraints

не нужно set_dft_signal -view existing_dft -type ScanDataIn -port SCAN_IN
попробуй так
set_scan_path my_chain \
-view existing \
-scan_data_in [get_ports SCAN_IN] \
-scan_data_out [get_ports SCAN_OUT] \
-scan_enable [get_ports SCAN_EN \
-infer_dft_signals

create_test_protocol -infer_clock -infer_async
report_dft_signal -view existing

оценить покрытие тестом в DC
dft_drc -coverage_estimate

[-=Vitaly=-]

после read_verilog, constraints

не нужно set_dft_signal -view existing_dft -type ScanDataIn -port SCAN_IN
попробуй так
set_scan_path my_chain \
-view existing \
-scan_data_in [get_ports SCAN_IN] \
-scan_data_out [get_ports SCAN_OUT] \
-scan_enable [get_ports SCAN_EN \
-infer_dft_signals

create_test_protocol -infer_clock -infer_async
report_dft_signal -view existing

оценить покрытие тестом в DC
dft_drc -coverage_estimate

Огромное спасибо!
Заработало, правда синтезит странно все обычные флопы поменяло на флопы со сканом и повесило на вход SE этих флопов логический 0 , а мой скан енейбл SCAN_EN замешало на комбинационную логику.
Это проблема в коде или в скрипте?

Код

/*Functional description*/    
/*disabled reset in SCAN mode*/
wire rb=RSTB | SCAN_EN;    

/*Create logic finding */
always@(divisor)  
    begin
        max=0;    
        for(i=7;i>0;i=i-1)
            if(divisor[i]==1'b1 && i>max)
                max=i;        
    end        
    
wire [7:0] tmp_div=divisor<<(7-max);    
/*Division*/
always@(negedge rb or posedge SCLK)  
begin
if(!rb)    
    begin
        cur_divident<=8'd0;
        cur_divisor<=8'd0;  
        bit_count<=3'd0;
        result<=7'd0;
    end    
else
    casex(SCAN_EN)
        1'b1:begin
            cur_divident<={cur_divident[7:0],SCAN_IN};  
            cur_divisor<={cur_divisor[6:0],cur_divident[8]};
            bit_count<={bit_count[1:0],cur_divisor[7]};
            result<={result[5:0],bit_count[2]};
            end
        1'b0:if(we)
                begin
                    cur_divident<=9'd255-tmp_div;
                    cur_divisor<=tmp_div>>1;  
                    bit_count<=8-max;
                    result<=7'd0;
                end
            else if (bit_count!=0)
                begin
                    if (cur_divident[8]==1'b0)
                        begin
                            cur_divident <= cur_divident-cur_divisor;
                            result[bit_count-1'b1]<=1'b1;    
                        end    
                    else
                        begin
                            result[bit_count-1'b1]<=1'b0;
                            cur_divident <= cur_divident+cur_divisor;
                        end
                    
                    bit_count<=bit_count-1;      
                    cur_divisor<= cur_divisor>>1;
                end         
        default: cur_divident<={8{1'bx}};    
    endcase    
end    
assign SCAN_OUT=result[6];

endmodule

[-=Vitaly=-]

Может кто-то может выложить в закрома толковые доки по SYNOPSYS, а то у меня только UG на Physical Compiler и то 2002 года. Или подскажите где качнуть по-свеже. Я позже документов 2004 года почти ничего не встречал. Во всех остальных то уже таких комманд нету, то еще чего.

Спасибо

[-=Vitaly=-]

Мини вопрос по Formality.

Когда он проверяет гейтед клок я задал set verification_clock_gate_hold_mode low. Он при матчинге выдает 1 точку несовпадения - элемент гейтед-клок. А при верификации все отлично. Я так понял так и должно быть или я большой оптимист

Спасибо!

[grigorik]

думаю из-за этой части


casex(SCAN_EN)
1'b1:begin
cur_divident<={cur_divident[7:0],SCAN_IN};
cur_divisor<={cur_divisor[6:0],cur_divident[8]};
bit_count<={bit_count[1:0],cur_divisor[7]};
result<={result[5:0],bit_count[2]};
end

[-=Vitaly=-]

думаю из-за этой части
casex(SCAN_EN)
1'b1:begin
cur_divident<={cur_divident[7:0],SCAN_IN};
cur_divisor<={cur_divisor[6:0],cur_divident[8]};
bit_count<={bit_count[1:0],cur_divisor[7]};
result<={result[5:0],bit_count[2]};
end

Спасибо, так а как иначе сделать скан-цепочку вручную?
Каденсе понимает такую конструкцию, я говорю синтезировать с опцией -don't scan и он заменяет флопики на скан флопики, правда почему-то все кроме 2х (мистика)...

Сообщение отредактировал -=Vitaly=- - Jan 16 2008, 10:00

[-=Vitaly=-]

Спасибо, так а как иначе сделать скан-цепочку вручную?
Каденсе понимает такую конструкцию, я говорю синтезировать с опцией -don't scan и он заменяет флопики на скан флопики, правда почему-то все кроме 2х (мистика)...

Пардон ошибнулся, он тоже не понимает, просто меняет флопы на флопы со сканом а Скан_енейбл заводит на логику.

[-=Vitaly=-]

Все вроде разобрался для дизайна который выше я сделал 2 скрипта

Код

#Top-level synthesis script with adding scan chain
remove_design -all
set TOP_LEVEL div

analyze -f verilog ./src/$TOP_LEVEL.v
elaborate $TOP_LEVEL

link
create_clock SCLK -period 60 -waveform {0 50}

# Use if exist scan-chain
set_dft_signal -view existing_dft -type ScanClock -port SCLK -timing {45 55}
set_dft_signal -view existing_dft -type reset -port RSTB -active_state 0
set_dft_signal -view existing_dft -type ScanEnable -port SCAN_EN -active_state 1
set_scan_parh my_chain -view existing  -scan_master_clock SCLK -scan_enable SCAN_EN /
                                     -scan_data_in SCAN_IN -scan_data_out -SCAN_OUT -infer_dft_signals
create_test_protocol -infer_clock -infer_async

report_dft_signal -view existing
dft_drc

compile_ultra
preview_dft

dft_drc -coverage estimate
report_scan_path

Этот для случая когда у вас ручная скан-цепочка, например как в моем примере.
При синтезе у меня получились обычные флопы и логика которая реализует скан-цепочку, зато порядок регистров в скан-цепочке свой - это плюс, но зато больше площади занимает. Главное не написать сompile_ultra -scan, т.к синтезатор заменяет все флопы на скан-флопы и вешает на входа SE этих регистров 0, т.е использует их как обычные регистры.

Теперь второй скрипт для автоматической генерации из обычного верилога без всяких заморочек.
Когда в тексте отсутсвует ручное задание скан-цепочек.

Код

casex(SCAN_EN)
        1'b1:begin
            cur_divident<={cur_divident[7:0],SCAN_IN};  
            cur_divisor<={cur_divisor[6:0],cur_divident[8]};
            bit_count<={bit_count[1:0],cur_divisor[7]};
            result<={result[5:0],bit_count[2]};
            end

Код

#Top-level synthesis script with adding scan chain
remove_design -all
set TOP_LEVEL div

analyze -f verilog ./src/$TOP_LEVEL.v
elaborate $TOP_LEVEL

link
create_clock SCLK -period 60 -waveform {0 50}

#===============================================================================
=================================

# Use for automatic scan-chain generation
set test_default_scan_style multiplexed_flip_flop
set_scan_configuration -style multiplexed_flip_flop -clock_mixing no_mix -chain_count 1
set_dft_signal -view existing_dft -type ScanClock -port SCLK -timing {45 55}
set_dft_signal -view existing_dft -type reset -port RSTB -active_state 0
set_dft_signal -view spec -type ScanDataIn -port SCAN_IN
set_dft_signal -view spec -type ScanDataOut -port SCAN_OUT
set_dft_signal -view existing_dft -type ScanEnable -port SCAN_EN -active_state 1
create_test_protocol
dft_drc

compile_ultra -scan
preview_dft
insert_dft

dft_drc -coverage estimate
report_scan_path

В этом случае синтезатор автоматически заменяет все флопики на флопики со сканом, на входа всех скан-флопов SE вешает сигнал SCAN_EN. Причем больше этот сигнал никуда не заходит в отличие от предыдущего варианта где он был замешан с логикой. Порядок в скан-цепочке такой как синтезатору угодно. Схема получается меньше по размеру и покрытие тестом немного выше.

Огромное спасибо grigorik .
Единственное что так и осталось загадкой это как написать верилог и скрипт, чтобы был свой порядок в скан-цепочке и скан-флопы в одно и то же время.
И еще может кто-то знает как посадить порт TE гейтед-клок елемента на SCAN_EN.

Сообщение отредактировал -=Vitaly=- - Jan 16 2008, 15:03

[grigorik]

Огромное спасибо grigorik .
Единственное что так и осталось загадкой это как написать верилог и скрипт, чтобы был свой порядок в скан-цепочке и скан-флопы в одно и то же время.
И еще может кто-то знает как посадить порт TE гейтед-клок елемента на SCAN_EN.
[/quote]


пожалуйста!

[KMC]

Может кто-то может выложить в закрома толковые доки по SYNOPSYS, а то у меня только UG на Physical Compiler и то 2002 года. Или подскажите где качнуть по-свеже. Я позже документов 2004 года почти ничего не встречал. Во всех остальных то уже таких комманд нету, то еще чего.

вся документация по Синопсису уже давно лежит на сервере - Sold2006.06

[yes]

Единственное что так и осталось загадкой это как написать верилог и скрипт, чтобы был свой порядок в скан-цепочке и скан-флопы в одно и то же время.
И еще может кто-то знает как посадить порт TE гейтед-клок елемента на SCAN_EN.

может я и чего-то недопонимаю, но на этапе логического синтеза (DC) скан цепочки не создаются. в смысле реальные цепочки и патерны. в этом есть и смысл - DC ведь не знает где-какой триггер окажется после размещения, и с какими соседями его надо объединять в цепочку...

это все делается на этапе генерации патернов после размещения.
так как мы все время работаем с одним back-end-ом, мое представление, наверно, однобокое - но они не очень доверяют автоматическим вставлялкам сканов и много работы делают вручную

возможно у DC синтез сканов нужен тогда, когда в библиотеке нет аналогов со сканами. а в нашем случае (библиотека есть) бэк-энд говорит - хотите вставляйте скан флопы (более реальные времянки), хотите невставляйте (меньше геммора) - нам пофиг
upd: да, ес-сно для синтеза нужно запретить DC использовать скан флопы (что бы он не попытался какую-либо логику в их мультиплексоры засунуть)

[-=Vitaly=-]

может я и чего-то недопонимаю, но на этапе логического синтеза (DC) скан цепочки не создаются. в смысле реальные цепочки и патерны. в этом есть и смысл - DC ведь не знает где-какой триггер окажется после размещения, и с какими соседями его надо объединять в цепочку...

это все делается на этапе генерации патернов после размещения.
так как мы все время работаем с одним back-end-ом, мое представление, наверно, однобокое - но они не очень доверяют автоматическим вставлялкам сканов и много работы делают вручную

возможно у DC синтез сканов нужен тогда, когда в библиотеке нет аналогов со сканами. а в нашем случае (библиотека есть) бэк-энд говорит - хотите вставляйте скан флопы (более реальные времянки), хотите невставляйте (меньше геммора) - нам пофиг
upd: да, ес-сно для синтеза нужно запретить DC использовать скан флопы (что бы он не попытался какую-либо логику в их мультиплексоры засунуть)

При автоматической генерации схема получается меньше это - раз. Можно раньше выловить ошибки ДФТ чекером. Во-вторых цепочки создаются на этапе логического синтеза см. мой пример, но в дальнейшем могут перегенерироваться в целях более компактной укладки. Могу вам для сравнения предоставить оба скрипта и исходника для сравнения или сгенерированные схемы. И если вы используете мультиплексированные скан-цепочки, я хотел бы попросить вас предоставить небольшой модулечек с ручными скан-цепочками для анализа.

[yes]

Могу вам для сравнения предоставить оба скрипта и исходника для сравнения или сгенерированные

спасибо, сейчас не надо. я тоже поигрался с DC и какое-то представление получил. уточнять/расширять сейчас нет интереса/энтузиазма - хочеться сдать проект и отдохнуть....

схемы. И если вы используете мультиплексированные скан-цепочки, я хотел бы попросить вас предоставить небольшой модулечек с ручными скан-цепочками для анализа.

не представляю, как предоставить цепочки ? есть единый нетлист (~6MGate), который был отправлен back-end-у без цепочек (и без скан-инсершина), потом для sign-off-а мы получили нетлист со скан цепочками (там же тактовые деревья, BIST-ы, всяческие буффера коррекции hold|setup и т.п.)
но цепочки мы никак не проверяли (управляющая нога во всех наших тестах в режиме scan-disable), это проверяли там

я могу скриптом вытащить какую-либо цепочку - но какой смысл?

мультиплексор цепочек (входы/выходы) также вставлялся back-end-ом, мы выделяли только ножки (как цепочек, так и управления (dedicated) )
тем более применялась метода сжатия патернов и OCC (то есть capture выполняется не по скан клоку (10МГц), а по боевому (200) )

со всем этим разбираться не было времени - какие-то презентации я посмотрел (они под соглашением, и ничего интересного там нет - очень общие), что-то китайцы рассказали вербально
но в деталях (до вентилей) я на это не смотрел

[-=Vitaly=-]

не представляю, как предоставить цепочки ?

Посмотрите мой пример в этом топике по-выше. Где на в RTL описании последовательного делителя заложена скан-цепочка. Это наверное скорее больше атавизм, но нас так заставляют и все бы ничего, но как я говорил мне не нравится как она синтезируется.

Вот к примеру синтезированная схема со скан-цепочкой вставленной DFT и скан-флопами.
Белым выделены флопы (здесь со сканом и SCAN_EN заведен на входы SE сканирующих флопов)



А вот ручная вставка. DFT нашло цепочку, оценило приблизительно покрытие ATPG, но нету скан флопов.
Белым выделены флопы (здесь без и SCAN_EN заведен на логику)


Понятно что первая лучше.
А вот сделать ручную со скан-флопами это уже навязчивая идея

[yes]

Посмотрите мой пример в этом топике по-выше. Где на в RTL описании последовательного делителя

ну вот, я не поленился и кусок от АЗИКа отданого (!) в производство прорисовал
длинная колбаса буферов это скан енабле
вторая колбаска - это от входа (PAD) до начала цепочки
ну и несколько триггеров со сканами (тянуть всю цепь - не охота , там больше 100 флопов)



здесь поближе - тригер без скана - это кусок тестирующего IP
далее, интересный момент - первый триггер в цепочке - синхронизатор и его рабочий путь совпал с сканцепочкой (то есть тупость тула вставляющего сканы проявляется D==SI и мультиплексор не нужен)




вобщем - мое мнение, что по этим картинкам ничего не поймешь (но может я их готовить не умею) , поэтому я их и не рисовал , но вроде как назвался груздем...

может интересно интересно будет
--------------------
когда сами делаете размещение - возможно Ваша задача имеет смысл, но нас бэкендовцы уверяют, что автоматический time-driven P&R сильно лучше (я в этом сильно сомневаюсь, но нет возможности проверить)

[-=Vitaly=-]

бэкендовцы уверяют, что автоматический time-driven P&R сильно лучше (я в этом сильно сомневаюсь, но нет возможности проверить)

так и я тоже пришел к этому выводу.
Кстати у вас правильно сделано, тот же результат я получил при автоматической вставке скан-цепочек.
А при ручной немного лажовато, но я смотрю что иначе сделать не получится.

[grigorik]

так и я тоже пришел к этому выводу.
Кстати у вас правильно сделано, тот же результат я получил при автоматической вставке скан-цепочек.
А при ручной немного лажовато, но я смотрю что иначе сделать не получится.

Вообше-то в стандартной АСИК дизайне делается так:
1. Во время синтеза скан цепочки вставляются автоматически и очерёдность тригеров в цепочке определят DC по alphanumeric принципе (честно говоря я не понимаю что это значит). И генерируется так называемый SCAN DEF фаил для бак-енд тулов.
2. Бек-енд тулом читается SCAN DEF. Перед плайсмента все цепочки отрываются поскольку они будут мешать оптимизации схемы тулом для функциональной работы. После плайсмента и синтеза клок деревев и перед роутингом скан цепочки восстоновливаттся но уже очередность не тот как был после синтеза. В цепочке те же тригера но очередность другой. Для очередности уже учитываются местоположения тригеров. Тут цель роутинг ресурсы. Таким образом роутинг ресурсы использованными скан цепочками будут минимальны и это даст возможность более оптимальной реализации (роутинга) общей схемы. Вот по-этому time-driven P&R сильно лучше.

[-=Vitaly=-]

Делюсь скриптом для автоматической генерации скан-чейнов в Кыденсе. Может кому надо будет.

Код

set_message_verbosity VLOGPT-035 off

read_verilog ./src/${RTL_FILE}


issue_message -type info "--> Start synthesis"
do_build_generic -module ${TOP_LEVEL}

set_current_module ${TOP_LEVEL}
set_top_timing_module ${TOP_LEVEL}

#PKS insert scan_chains

#Select scan_type
set_scan_style mux_scan

set_global dft_scan_avoid_control_buffering true

set_global dft_scan_path_connect tieback

set_scan_mode SCAN_EN 1

report_dft_assertions -all_modules

check_dft_rules

report_dft_registers

check_netlist

set_clock SCLK -period 80 -waveform {0 50}

do_optimize

set_global dft_scan_path_connect chain

set_number_of_scan_chains 1

set_scan_data -clock SCLK -rise  SCAN_IN  SCAN_OUT -enable SCAN_EN

do_xform_connect_scan

Верилог в аттаче.

Прикрепленные файлы

 frame_counter_no_scan.v ( 2.72 килобайт ) Кол-во скачиваний: 60