| |
|
  |
 Почему один и тотже триггер реализуется по-разному?, как с этим бороться? |
|
|
|
|
 Mar 21 2014, 10:03
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(Viwon @ Mar 21 2014, 11:23)  А что это за примитив и куда его вставлять? Мой проект написан на Verilog'е. Это примитив из альтерской библиотеки, такой же, как DFF, DFFE, и прочие физические сущности. Этот означает в контексте FPGA один LUT. От того, на каком языке написан проект, использование примитивов по сути не меняется. Смотрите хелп на него, там есть примеры на всех языках. Цитата(Viwon @ Mar 21 2014, 11:23) Зачем вообще используется LUT если нету промежуточной логики? Видимо, ресурсы разводки так разлеглись, что надо было тут подключить через LUT, а напрямую не склалось у роутера.
|
|
|
|
|
|
|
|
Mar 21 2014, 11:26
|
Участник
Группа: Участник
Сообщений: 45
Регистрация: 18-03-14
Пользователь №: 80 976
|
Да, трюк с 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ов
Сообщение отредактировал Viwon - Mar 21 2014, 11:27
|
|
|
|
|
|
|
|
Mar 21 2014, 13:41
|
Местный
Группа: Участник
Сообщений: 230
Регистрация: 29-08-09
Пользователь №: 52 094
|
Цитата(spectr @ Mar 21 2014, 09:20) То есть Вы хотите сказать, что один и тот же код (не меняющийся), с одними и теми же констрейнами, настройками компиляции и seed, будет каждый раз разодиться по разному? Да ну, не может такого быть, ведь начальными условиями для синтеза и разводки как раз и являются настройки, констрейны, код, а они не меняются. А раз не меняются начальные условия, то и результат не должен меняться... По идее... Конечно же, при сохранении всех исходных условий, будет разводиться одинаково. Но вот если что-то изменить - строчку кода, параметр синтезатора, версию софта и т.п. - могут появиться лавинообразные изменения результатов.
Сообщение отредактировал o_khavin - Mar 21 2014, 13:44
|
|
|
|
|
|
|
|
Mar 22 2014, 10:43
|
Гуру
Группа: Свой
Сообщений: 3 644
Регистрация: 28-05-05
Пользователь №: 5 493
|
Ну значит наши плисоводы с бодуна на работе были всегда - говорят нифига, разводка от разводки отличаются, битстримы правда не сравнивали, мне лень, а они не умеют. Но работало кардинально разно, хотя ничего не меняли. ПС - раз работало по-разному - то ясно, что они констрейны толком задать не могли, да чего говорить - они в свои 50 лет Верилог так и не освоили, на схематике все рисовали. Но, надо однать должное, в отличии от нас, молодых-горячих все работало и работает.
|
|
|
|
|
|
|
|
Mar 22 2014, 12:14
|
Местный
Группа: Участник
Сообщений: 230
Регистрация: 29-08-09
Пользователь №: 52 094
|
Цитата(DASM @ Mar 22 2014, 13:57) С чего Вы решили, что разводка будет одинаковой ? Я пруф не приведу сейчас, читал немного - они разводку начинают со случайных ячеек (ну грубо говоря). Плюс достоверно наши разводчики говорили - не совпадает разводка от раза к разу. В софте Xilinx-а я уже много лет наблюдаю, что разводка на 100% воспроизводится при неизменных стартовых условиях.
|
|
|
|
|
|
|
|
Mar 25 2014, 04:23
|
Участник
Группа: Участник
Сообщений: 45
Регистрация: 18-03-14
Пользователь №: 80 976
|
Цитата(SM @ Mar 21 2014, 16:34) Кстати, к вопросу "почему". Вторая причина появления этих фидеров - нарушение hold time в пути Не подходит, пути к этим триггерам исключены из временного анализа с помощью set_false_path.
|
|
|
|
|
|
|
|
Mar 25 2014, 06:30
|
Участник
Группа: Участник
Сообщений: 30
Регистрация: 9-02-14
Пользователь №: 80 406
|
Цитата(Viwon @ Mar 20 2014, 09:23) От чего зависит реализация, и как сказать Quarus’у чтобы определенные триггеры имели одинаковую реализацию? Картинки есть, а где HDL-код для триггера и для того, что рядом с ним?
|
|
|
|
|
|
|
|
Mar 25 2014, 09:09
|
Участник
Группа: Участник
Сообщений: 45
Регистрация: 18-03-14
Пользователь №: 80 976
|
Цитата(FPGAz @ Mar 25 2014, 10:30) Картинки есть, а где HDL-код для триггера и для того, что рядом с ним? В Verilog-коде нет ни чего мудреного и навряд ли даст какую-нибудь зацепку, тем не менее: CODE 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 они идентичны.
Сообщение отредактировал Viwon - Mar 25 2014, 09:10
|
|
|
|
|
|
|
|
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0
|
|
|
