[dima_spb 0]

просто любопытство - у Вас ПО официально купленное?

Если webpack, я бы так не писал :smile3009:

[SM 0]

А что это за примитив и куда его вставлять? Мой проект написан на Verilog'е.

Это примитив из альтерской библиотеки, такой же, как DFF, DFFE, и прочие физические сущности. Этот означает в контексте FPGA один LUT. От того, на каком языке написан проект, использование примитивов по сути не меняется. Смотрите хелп на него, там есть примеры на всех языках.

 

Зачем вообще используется LUT если нету промежуточной логики?

Видимо, ресурсы разводки так разлеглись, что надо было тут подключить через LUT, а напрямую не склалось у роутера.

 

[Viwon 0]

Да, трюк с LCELL вроде работает, непонятные feeder’ы заменились user_cell’ами, и наверное эта картина теперь будет постоянна, понаблюдаю…

 

В Verilog-описание схемы LCELLы пока не вводил, удалось обойтись изменениями в qsf-файле:

#Вставляем LCELL между источником и триггером
set_instance_assignment -name LCELL_INSERTION 1 -from "VIRTUALPAL:inst4|LOCKPOSa~0" -to "POSCOUNTER:inst2|SYNCHRONIZER:m_lockpos_sync[0]|sync[0]"
#Фиксируем LCELL в LUTе LE
set_location_assignment LCCOMB_X14_Y6_N0 -to "inst4|LOCKPOSa~0user_cell0"
#Фиксируем регистр в LE
set_location_assignment LCFF_X14_Y6_N1 -to "POSCOUNTER:inst2|SYNCHRONIZER:m_lockpos_sync[0]|sync[0]"

Минус этого способа убогие автогенерируемые имена LCELLов

Изменено 21 марта, 2014 пользователем Viwon

[SM 0]

Кстати, к вопросу "почему". Вторая причина появления этих фидеров - нарушение hold time в пути, и разводчик вставляет их для исправления этого нарушения. Причем тут достаточно одной пикосекунды, чтобы в один путь его вставили, в другой - нет.

[o_khavin 0]

То есть Вы хотите сказать, что один и тот же код (не меняющийся), с одними и теми же констрейнами, настройками компиляции и seed, будет каждый раз разодиться по разному? Да ну, не может такого быть, ведь начальными условиями для синтеза и разводки как раз и являются настройки, констрейны, код, а они не меняются. А раз не меняются начальные условия, то и результат не должен меняться... По идее...

Конечно же, при сохранении всех исходных условий, будет разводиться одинаково. Но вот если что-то изменить - строчку кода, параметр синтезатора, версию софта и т.п. - могут появиться лавинообразные изменения результатов.

Изменено 21 марта, 2014 пользователем o_khavin

[DASM 0]

С чего Вы решили, что разводка будет одинаковой ? Я пруф не приведу сейчас, читал немного - они разводку начинают со случайных ячеек (ну грубо говоря). Плюс достоверно наши разводчики говорили - не совпадает разводка от раза к разу.

[SM 0]

со случайных ячеек (ну грубо говоря).

С псевдослучайных. Для этого SEED и задается...

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

[DASM 0]

Ну а если ничего не задавать - SEED нулевой будет всегда ? Я более про Квартус

[SM 0]

SEED нулевой будет всегда ?

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

[DASM 0]

Ну значит наши плисоводы с бодуна на работе были всегда - говорят нифига, разводка от разводки отличаются, битстримы правда не сравнивали, мне лень, а они не умеют. Но работало кардинально разно, хотя ничего не меняли. ПС - раз работало по-разному - то ясно, что они констрейны толком задать не могли, да чего говорить - они в свои 50 лет Верилог так и не освоили, на схематике все рисовали. Но, надо однать должное, в отличии от нас, молодых-горячих все работало и работает.

[o_khavin 0]

С чего Вы решили, что разводка будет одинаковой ? Я пруф не приведу сейчас, читал немного - они разводку начинают со случайных ячеек (ну грубо говоря). Плюс достоверно наши разводчики говорили - не совпадает разводка от раза к разу.

В софте Xilinx-а я уже много лет наблюдаю, что разводка на 100% воспроизводится при неизменных стартовых условиях.

[Viwon 0]

Кстати, к вопросу "почему". Вторая причина появления этих фидеров - нарушение hold time в пути

Не подходит, пути к этим триггерам исключены из временного анализа с помощью set_false_path.

 

[fpgaz 0]

От чего зависит реализация, и как сказать Quarus’у чтобы определенные триггеры имели одинаковую реализацию?

Картинки есть, а где HDL-код для триггера и для того, что рядом с ним?

 

[Мур 1]

С чего Вы решили, что разводка будет одинаковой ? Я пруф не приведу сейчас, читал немного - они разводку начинают со случайных ячеек (ну грубо говоря). Плюс достоверно наши разводчики говорили - не совпадает разводка от раза к разу.

Верно! Фиттер реализует вероятностный подход в своей работе. И только LLR (Logic Lock Regions) он не трогает. Оставляет прежним от старой компиляции. При инкрементной компиляции это неизбежно (и удобно!). Все что вы зафиксировали в проекте будет прежним, а вот остальное он будет разводить каждый раз по-разному. Единственный критерий,- требования констрейнов. Воспроизводимость проектов разная, но дизайн - рабочий!

[Viwon 0]

Картинки есть, а где HDL-код для триггера и для того, что рядом с ним?

В Verilog-коде нет ни чего мудреного и навряд ли даст какую-нибудь зацепку, тем не менее:

module SYNCHRONIZER(SIGNALa, SIGNAL, CLK);
output	SIGNAL;

input	SIGNALa;// внешний асинхронный сигнал
input	CLK;

reg	[1:0]	sync;
always @(posedge CLK)
	sync[1:0] <= {sync[0], SIGNALa};

assign SIGNAL = sync[1];

endmodule

Это синхронизатор из двух последовательных триггеров. В 0ом посте приведена картинка для пути от внешней комбинаторной схемы до регистра sync[0]. Но уверяю Вас внутри этого модуля, путь от sync[0] к sync[1] подвержен тойже проблеме (регистр sync[1] реализуется, то с feeder’ом, то без), с той лишь разницей, что это синхронная схема и ее временные характеристики обеспечивает Quartus, мне до них нет дела.

 

Думаю, изучив триггеры в своем проекте с помощью Technology Map Viewer(Post-Fitting), также обнаружите, что они реализуются по-разному, в RTL Viewer они идентичны.

Изменено 25 марта, 2014 пользователем Viwon