Всем доброго времени суток,
недавно увидел в одной из вакансий такие требования, и хотелось бы четко понимать, что имеется в виду:
-понимание принципов оптимизации по времени, ресурсам, пропускной способности;
-опыт разработки высокоскоростных схем (от 100 MHz), timing constraints;
так вот, что это за принципы, и что нужно понимать? (надеюсь на развернутый ответ)
и я уже задавал какой-то подобный вопрос: но когда приходится применять какие-либо тайминг констрейны, кроме указания частоты клоков?
только в асинхронных дизайнах? и чем конкретно отличается разработка схем с тактовой от 100мгц от меньших? - тем что проект может не собраться из-за больших задержек в цепях? каждый раз видя такие формулировки, я чувствую что мне ничего не понятно, поясните пожалуйста.
Полная версия этой страницы: Принципы оптимизации по времени, ресурсам, пропускной способности
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Цитата(Goose @ Feb 26 2013, 10:06) 
-понимание принципов оптимизации по времени, ресурсам, пропускной способности;
осознание на этапе написания кода, как то что вы пишете ляжет на целевую платформу, с учетом ее архитектуры. Ну например полного использования возможности LCELL/ALM в альтере или SLICE у хилых.
Цитата
-опыт разработки высокоскоростных схем (от 100 MHz), timing constraints;
осознание на этапе проектирования системы, как ее нужно строить исходя из требований к производительности на целевой платформе. Ну например, если вас просят сделать устройство с эквивалентной тактовой частотой 1ГГц на плис класса сыклон 3, то вы должны понимать что это выльется в мегадикий ресурс (хотя это и возможно). А вот на каком нить стратиксе или виртексе ляжет с приемлемыми затратами.
Цитата(Goose @ Feb 26 2013, 18:06)
и чем конкретно отличается разработка схем с тактовой от 100мгц от меньших? - тем что проект может не собраться из-за больших задержек в цепях? каждый раз видя такие формулировки, я чувствую что мне ничего не понятно, поясните пожалуйста.
Я, честно говоря, с меньшими частотамми за 7 лет и не сталкивался. Основные проблемы с частотой касаемо синхронной логики:
1. Схемы с обратными связями, типа БИХ фильтрами или CRC, где результат предыдущей операции должен быть доступен к следующему такту и алгоритм заменить нельзя. Тут требуется знание целевой ПЛИС и осознание каким образом все это уложится - сколько слоев логики будет.
2. Знание самих алгоритмов. Если, скажем, простейший многоразрядный счетчик не проходит по частоте, то его можно просто разбить на несколько более простых счетчиков или вообще при необходимости заменить на сдвиговый регистр. Сюда же отнесу и мультиплексоры - когда из-за незнания схемоты описывается вместо одного case куча последовательных if-else.
3. Знание настроек компилятора и понятие конвейерности, дублирование логики.
4. Ошибки по холдам. Скажем, создается контроллер памяти, но частота на приеме приходит позже данных - требуется полный анализ и ручное размещение регистров - дальше/ближе от пинов.
5. Иногда возникают ситуации, что отдельный кусок дизайна по частоте проходит, но при большой заполненности в топовом модуле все сыплется имеено из-за временных ошибок - приходится отдельно закреплять и вставлять разведенные нетлисты.
Цитата(des00 @ Feb 26 2013, 19:03)
осознание на этапе написания кода, как то что вы пишете ляжет на целевую платформу, с учетом ее архитектуры. Ну например полного использования возможности LCELL/ALM в альтере или SLICE у хилых.
Можете привести пример как учитывать при проектировании структуру Slice?
Цитата(des00 @ Feb 26 2013, 19:03)
осознание на этапе проектирования системы, как ее нужно строить исходя из требований к производительности на целевой платформе. Ну например, если вас просят сделать устройство с эквивалентной тактовой частотой 1ГГц на плис класса сыклон 3, то вы должны понимать что это выльется в мегадикий ресурс (хотя это и возможно). А вот на каком нить стратиксе или виртексе ляжет с приемлемыми затратами.
Вот, каким образом я могу это понимать? (для этого конкретного примера)
А вообще больше интересует то, что есть в ваших статьях про "Synopsys Design Constraint — язык задания временных ограничений на примере Altera TimeQuest". Собственно это то, что я искал, только если бы это было для хилых я был бы вообще безгранично счастлив
, а так пока узнал много нового, а как можно перенести новые знания на xilinx? Timing Analyzer хилых аналогичен TimeQuest'y альтеры? sdc файл можно прикрутить к ISE? Цитата(bogaev_roman @ Feb 26 2013, 22:42)
Я, честно говоря, с меньшими частотамми за 7 лет и не сталкивался. Основные проблемы с частотой касаемо синхронной логики:
1. Схемы с обратными связями, типа БИХ фильтрами или CRC, где результат предыдущей операции должен быть доступен к следующему такту и алгоритм заменить нельзя. Тут требуется знание целевой ПЛИС и осознание каким образом все это уложится - сколько слоев логики будет.
2. Знание самих алгоритмов. Если, скажем, простейший многоразрядный счетчик не проходит по частоте, то его можно просто разбить на несколько более простых счетчиков или вообще при необходимости заменить на сдвиговый регистр. Сюда же отнесу и мультиплексоры - когда из-за незнания схемоты описывается вместо одного case куча последовательных if-else.
3. Знание настроек компилятора и понятие конвейерности, дублирование логики.
4. Ошибки по холдам. Скажем, создается контроллер памяти, но частота на приеме приходит позже данных - требуется полный анализ и ручное размещение регистров - дальше/ближе от пинов.
5. Иногда возникают ситуации, что отдельный кусок дизайна по частоте проходит, но при большой заполненности в топовом модуле все сыплется имеено из-за временных ошибок - приходится отдельно закреплять и вставлять разведенные нетлисты.
1. Схемы с обратными связями, типа БИХ фильтрами или CRC, где результат предыдущей операции должен быть доступен к следующему такту и алгоритм заменить нельзя. Тут требуется знание целевой ПЛИС и осознание каким образом все это уложится - сколько слоев логики будет.
2. Знание самих алгоритмов. Если, скажем, простейший многоразрядный счетчик не проходит по частоте, то его можно просто разбить на несколько более простых счетчиков или вообще при необходимости заменить на сдвиговый регистр. Сюда же отнесу и мультиплексоры - когда из-за незнания схемоты описывается вместо одного case куча последовательных if-else.
3. Знание настроек компилятора и понятие конвейерности, дублирование логики.
4. Ошибки по холдам. Скажем, создается контроллер памяти, но частота на приеме приходит позже данных - требуется полный анализ и ручное размещение регистров - дальше/ближе от пинов.
5. Иногда возникают ситуации, что отдельный кусок дизайна по частоте проходит, но при большой заполненности в топовом модуле все сыплется имеено из-за временных ошибок - приходится отдельно закреплять и вставлять разведенные нетлисты.
1. Как узнать сколько используется слоев логики? в отчете PAR? и как количественно тогда оценить сколько слоев много, а сколько приемлемо?
2. это прочитал в статье, тут понятно
3. под компиллятором вы понимаете синтезатор?
4. тоже примерно понятно
5. это круто, никогда не представлял, что такое бывает, спасибо
Цитата(Goose @ Feb 27 2013, 02:04)
Можете привести пример как учитывать при проектировании структуру Slice?
под хилых давно ничего не делал, а вот под альтеровский LCELL
Код
wire acc_noverflow = acc[cACC_W-1];
wire acc_poverflow = (acc.exp >= pPOW_W);
assign acc_overflow_value.sign = 1'b0;
assign acc_overflow_value.exp = pPOW_W-1;
assign acc_overflow_value.mant = '1;
assign acc_next = acc + (err2acc >>> cERR_SCALE);
always_ff @(posedge iclk) begin
acc_val <= err2acc_val;
if (acc_noverflow | acc_poverflow | err2acc_val) begin
if (acc_noverflow)
acc <= '0;
else if (acc_poverflow)
acc <= acc_overflow_value;
else
acc <= acc_next;
end
end
wire acc_poverflow = (acc.exp >= pPOW_W);
assign acc_overflow_value.sign = 1'b0;
assign acc_overflow_value.exp = pPOW_W-1;
assign acc_overflow_value.mant = '1;
assign acc_next = acc + (err2acc >>> cERR_SCALE);
always_ff @(posedge iclk) begin
acc_val <= err2acc_val;
if (acc_noverflow | acc_poverflow | err2acc_val) begin
if (acc_noverflow)
acc <= '0;
else if (acc_poverflow)
acc <= acc_overflow_value;
else
acc <= acc_next;
end
end
Вот такое описание позволяет поднять быстродействие аккумулятора с ограничителем до частот ~220 МГц (32 бита) на сыклоне 7ке. Если взять классическое описание типа
Код
always_ff @(posedge iclk) begin
acc_val <= err2acc_val;
if (acc_noverflow)
acc <= '0;
else if (acc_poverflow)
acc <= acc_overflow_value;
else if (err2acc_val)
acc <= acc_next;
end
end
acc_val <= err2acc_val;
if (acc_noverflow)
acc <= '0;
else if (acc_poverflow)
acc <= acc_overflow_value;
else if (err2acc_val)
acc <= acc_next;
end
end
то 150-160 МГц предел. Объяснение почему лучше смотреть в хендбуке на сыклон
Цитата
Вот, каким образом я могу это понимать? (для этого конкретного примера)
Вопрос не до совсем понял. Тут понимание очень просто, если требуется тактовая в 1ГГЦ, то можно сделать как 2*500, 4*250, 8*125. Если брать среднюю логику, то для того же сыклона надо закладывать 8ми фазную обработку, со всеми вытекающими. Если взять какой нить 6 ой виртекс, то можно уложиться в 4 фазы или постараться втиснуться в 2 %)
Цитата
как можно перенести новые знания на xilinx? Timing Analyzer хилых аналогичен TimeQuest'y альтеры? sdc файл можно прикрутить к ISE?
ИМХО главное понять физику процесса, а платформа это уже вторично
Цитата(Goose @ Feb 27 2013, 11:04)
1. Как узнать сколько используется слоев логики? в отчете PAR? и как количественно тогда оценить сколько слоев много, а сколько приемлемо?
3. под компиллятором вы понимаете синтезатор?
3. под компиллятором вы понимаете синтезатор?
1. Полностью расписывается путь сигнала от точки A до точкти B (в пределах одного клокового домена ) - тут нужно смотреть какая задержка сигнала на логике LCELL (задержка на элементе логики - ее изменить нельзя) и IC (задержка на соединениях), обычно производители пишут, что 50% хороший с лучай, но в реальности грамотный дизайнер может уменьшить IC в разы.
3. Проблема часто именно в fan out. Есть, скажем, у Вас управляющий сигнал, о готовности устройства, и этот единственный сигнал готовности в чистом виде подается как сигнал разрешение работы на всю логику ПЛИС, временная гонка в данном случае обеспечена.
Цитата(des00 @ Feb 27 2013, 13:05)
Правильно ли я понимаю, что в стандартном примере за один такт проверяется 3 условия по очереди, а у Вас всего 2 и поэтому можно увеличить частоту? это что-то вроде слоев логики и нужно стараться уменьшить их количество?
Я правда сначала думал, что Вы имеете ввиду учитывание количества входов lut'a разных микросхем или что-то в этом духе
Цитата(bogaev_roman @ Feb 27 2013, 22:38)
1. Полностью расписывается путь сигнала от точки A до точкти B (в пределах одного клокового домена ) - тут нужно смотреть какая задержка сигнала на логике LCELL (задержка на элементе логики - ее изменить нельзя) и IC (задержка на соединениях), обычно производители пишут, что 50% хороший с лучай, но в реальности грамотный дизайнер может уменьшить IC в разы.
3. Проблема часто именно в fan out. Есть, скажем, у Вас управляющий сигнал, о готовности устройства, и этот единственный сигнал готовности в чистом виде подается как сигнал разрешение работы на всю логику ПЛИС, временная гонка в данном случае обеспечена.
3. Проблема часто именно в fan out. Есть, скажем, у Вас управляющий сигнал, о готовности устройства, и этот единственный сигнал готовности в чистом виде подается как сигнал разрешение работы на всю логику ПЛИС, временная гонка в данном случае обеспечена.
1. А где он расписывается? во временном анализаторе?
3. А избежать гонки можно каким образом? если пропустить его через триггер на входе?
Цитата(Goose @ Feb 28 2013, 00:06)
Правильно ли я понимаю, что в стандартном примере за один такт проверяется 3 условия по очереди, а у Вас всего 2 и поэтому можно увеличить частоту? это что-то вроде слоев логики и нужно стараться уменьшить их количество?
нет неправильно. вам лучше всего посмотреть хендбук на сыклон 3, из рисунка что такое LCELL видно объснение.
Цитата
Я правда сначала думал, что Вы имеете ввиду учитывание количества входов lut'a разных микросхем или что-то в этом духе
есть и такая оптимизация, иногда приходится не только учитывать кол-во входов но и доп.функции входов
выскажу ортогональную точку зрения - все эти LCELLы SLICEы и прочие VersaTile нужны в малом кол-ве проектов.
если возникают часто, то что-то не так в методологии разработки
у меня, например, больше проблем вызывают задержки в трассировке, чем в логике, и это не только в АЗИКах но и в ПЛИС современных
---------
то есть разработчик прежде всего должен понимать констрейны, настройки тулов, уметь пользоваться тулзами типа Planehead-а, для удовлетворения timing closure
а знание SLICE-ов это конечно не недостаток, но указание как требования свидетельствует о недостаточном понимании самим работадателем процедуры разработки дизайнов
---------
у Xilinx-а свой, не sdc формат констрейнов, в последних версиях они вроде бы сделали конвертор, но я им еще не пользовался
если возникают часто, то что-то не так в методологии разработки
у меня, например, больше проблем вызывают задержки в трассировке, чем в логике, и это не только в АЗИКах но и в ПЛИС современных
---------
то есть разработчик прежде всего должен понимать констрейны, настройки тулов, уметь пользоваться тулзами типа Planehead-а, для удовлетворения timing closure
а знание SLICE-ов это конечно не недостаток, но указание как требования свидетельствует о недостаточном понимании самим работадателем процедуры разработки дизайнов
---------
у Xilinx-а свой, не sdc формат констрейнов, в последних версиях они вроде бы сделали конвертор, но я им еще не пользовался
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.