Принципы оптимизации по времени, ресурсам, пропускной способности Опции

[Goose]

Всем доброго времени суток,
недавно увидел в одной из вакансий такие требования, и хотелось бы четко понимать, что имеется в виду:
-понимание принципов оптимизации по времени, ресурсам, пропускной способности;
-опыт разработки высокоскоростных схем (от 100 MHz), timing constraints;

так вот, что это за принципы, и что нужно понимать? (надеюсь на развернутый ответ)

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

[Goose]

осознание на этапе написания кода, как то что вы пишете ляжет на целевую платформу, с учетом ее архитектуры. Ну например полного использования возможности LCELL/ALM в альтере или SLICE у хилых.

Можете привести пример как учитывать при проектировании структуру Slice?

осознание на этапе проектирования системы, как ее нужно строить исходя из требований к производительности на целевой платформе. Ну например, если вас просят сделать устройство с эквивалентной тактовой частотой 1ГГц на плис класса сыклон 3, то вы должны понимать что это выльется в мегадикий ресурс (хотя это и возможно). А вот на каком нить стратиксе или виртексе ляжет с приемлемыми затратами.

Вот, каким образом я могу это понимать? (для этого конкретного примера)

А вообще больше интересует то, что есть в ваших статьях про "Synopsys Design Constraint — язык задания временных ограничений на примере Altera TimeQuest". Собственно это то, что я искал, только если бы это было для хилых я был бы вообще безгранично счастлив , а так пока узнал много нового, а как можно перенести новые знания на xilinx? Timing Analyzer хилых аналогичен TimeQuest'y альтеры? sdc файл можно прикрутить к ISE?

Я, честно говоря, с меньшими частотамми за 7 лет и не сталкивался. Основные проблемы с частотой касаемо синхронной логики:
1. Схемы с обратными связями, типа БИХ фильтрами или CRC, где результат предыдущей операции должен быть доступен к следующему такту и алгоритм заменить нельзя. Тут требуется знание целевой ПЛИС и осознание каким образом все это уложится - сколько слоев логики будет.
2. Знание самих алгоритмов. Если, скажем, простейший многоразрядный счетчик не проходит по частоте, то его можно просто разбить на несколько более простых счетчиков или вообще при необходимости заменить на сдвиговый регистр. Сюда же отнесу и мультиплексоры - когда из-за незнания схемоты описывается вместо одного case куча последовательных if-else.
3. Знание настроек компилятора и понятие конвейерности, дублирование логики.
4. Ошибки по холдам. Скажем, создается контроллер памяти, но частота на приеме приходит позже данных - требуется полный анализ и ручное размещение регистров - дальше/ближе от пинов.
5. Иногда возникают ситуации, что отдельный кусок дизайна по частоте проходит, но при большой заполненности в топовом модуле все сыплется имеено из-за временных ошибок - приходится отдельно закреплять и вставлять разведенные нетлисты.

1. Как узнать сколько используется слоев логики? в отчете PAR? и как количественно тогда оценить сколько слоев много, а сколько приемлемо?
2. это прочитал в статье, тут понятно
3. под компиллятором вы понимаете синтезатор?
4. тоже примерно понятно
5. это круто, никогда не представлял, что такое бывает, спасибо