Повтор темы: выравнивание задержки глобального клока, Из темы ПЛИС Опции

[a123-flex]

да простят меня админы
так как в ПЛИС-ах никто не отвечает, спрошу здесь:

В проекте Virtex2 c фаноутом на опорном клоке 1050 цепей skew по отчету составил 240 пс. Клок заведен через bufg. Подскажите, как реализован механизм выравнивания skew на кристале ?
в глобальной матрице ведь нет pll, и если даже просто клок задерживать во всех узлах кроме загруженных, по моему получится хрень. Кроме того, насколько я понимаю процесс выравнивания должен быть динамическим (ведь триггеры каждого квадранта щелкают не в каждом такте ... ) Значит, механзмы синхронизации в матрице должны быть динамическими и реализованными в аналоге ?

[Shivers]

Вы говорите о clock tree, а в ПЛИС он фиксированный. Обычно в ПЛИС выделяют некие быстрые клоки для регионов, и глобальные клоки для всего дизайна. У глобальных большая нагрузочная способность и лучший охват i/o банков и внутренней логики. Итого, если вы завели тактирование правильно (в самую быструю pll, выход которой и есть глобальный клок для ПЛИС), и у вас тем не менее плохая времяннка, значит самое время заняться оптимизацией дизайна - выискивать мультисайкл пути, уменьшать нагрузку на ключевые триггера и т.д. В общем, ваша проблема - в схематехнике дизайна, есть над чем работать

[kondensator42]

Вы говорите о clock tree, а в ПЛИС он фиксированный. Обычно в ПЛИС выделяют некие быстрые клоки для регионов, и глобальные клоки для всего дизайна. У глобальных большая нагрузочная способность и лучший охват i/o банков и внутренней логики. Итого, если вы завели тактирование правильно (в самую быструю pll, выход которой и есть глобальный клок для ПЛИС), и у вас тем не менее плохая времяннка, значит самое время заняться оптимизацией дизайна - выискивать мультисайкл пути, уменьшать нагрузку на ключевые триггера и т.д. В общем, ваша проблема - в схематехнике дизайна, есть над чем работать

Не совсем понятно кому вы отвечаете/комментируете, но вообще это не столь важно, вы по-моему не поняли сути вопроса. Сlock tree или без Сlock tree (честно признаюсь, что не знаю что такое фиксированный) ни в этом суть вопроса. У вас, кстати говоря, и получается дерево - ствол это глобальные, а веточки внутри блоков (регионов, по-вашему). Регионы/блоки/иерархия все это естественно и понятно и нужно, и если между этими блоками нет перекрёстных и обратных с связей то почти и никаких вопросов с глобольной синхронизацией. А если эти связи есть? - Вот здесь и получается "петруха-андрюха". Это на глобальном уровне, а на уровне блоков (внутри блоков) хоть и в меньшей степени, но вопрос остаётся тоже. На сколько это опасно - это нужно считать, а для считать нужна информация. Но вот что-то я при беглом просмоте мануала так и не нашел данных по задержкам на шинах и соответствующих расчетных формул (может и не заметил). Эти вопросы, думаю (да вроде и читал когда-то какой-то ноут), это часть работы ихнего синтезатора. Но на бога надейся, но и сам не плошай.
"и у вас тем не менее плохая времяннка, значит самое время заняться оптимизацией дизайна - выискивать мультисайкл пути, уменьшать нагрузку на ключевые триггера и т.д. В общем, ваша проблема - в схематехнике дизайна, есть над чем работать " - работать всегда есть над чем, кто-то, например, круглое таскает, а кто-то плоское катает и оптимизировать можно до бесконечности.

kondensator42

[Shivers]

Не совсем понятно кому вы отвечаете/комментируете, но вообще это не столь важно, вы по-моему не поняли сути вопроса. Сlock tree или без Сlock tree (честно признаюсь, что не знаю что такое фиксированный) ни в этом суть вопроса. У вас, кстати говоря, и получается дерево - ствол это глобальные, а веточки внутри блоков (регионов, по-вашему). Регионы/блоки/иерархия все это естественно и понятно и нужно, и если между этими блоками нет перекрёстных и обратных с связей то почти и никаких вопросов с глобольной синхронизацией. А если эти связи есть? - Вот здесь и получается "петруха-андрюха". Это на глобальном уровне, а на уровне блоков (внутри блоков) хоть и в меньшей степени, но вопрос остаётся тоже. На сколько это опасно - это нужно считать, а для считать нужна информация. Но вот что-то я при беглом просмоте мануала так и не нашел данных по задержкам на шинах и соответствующих расчетных формул (может и не заметил). Эти вопросы, думаю (да вроде и читал когда-то какой-то ноут), это часть работы ихнего синтезатора. Но на бога надейся, но и сам не плошай.
"и у вас тем не менее плохая времяннка, значит самое время заняться оптимизацией дизайна - выискивать мультисайкл пути, уменьшать нагрузку на ключевые триггера и т.д. В общем, ваша проблема - в схематехнике дизайна, есть над чем работать " - работать всегда есть над чем, кто-то, например, круглое таскает, а кто-то плоское катает и оптимизировать можно до бесконечности.

kondensator42

В предыдущем посте я отвечал топикстартеру, теперь отвечу вам: под фиксированным clock tree
имелось ввиду одно большое дерево. и несколько дублирующих и региональных деревьев, причем у каждого дерева могут быть разные источники (две или три pll). Конкретику читайте в доке на ПЛИС, это все должно быть описано. Далее, по задержкам: сделайте backannotate нетлиста с задержками и моделируйте - это единственный вариант увидеть глазами как распределились задержки внутри ПЛИС. И последнее - работа над оптимизацией не может быть бесконечной, т.к. алгоритм предельно простой: берете самый плохой триггер в списке, который можно переписать, правите и переразводите. Затем правите следующий и т.д.-алгоритм конечный, и иногда он приводит к переписыванию целых блоков.
Если же конечная цель- asic, то иногда можно остановиться и на пониженных частотах, т.к. проект работающий в ПЛИС на конкретной частоте, будет работать на той же частоте в asic сделанном по тех процессу примерно в три раза лучше. Т.е. если работает в плис по 90нм, то можно смело синтезировать asic 28нм. Правило (в три раза) естественно чисто эмпирическое, но некая корреляция между тех процессами плис и asic прослеживается.

[Torpeda]

....если работает в плис по 90нм, то можно смело синтезировать asic 28нм. ....

А я всегда думал наоборот - если FPGA работает на 28нм то ASIC можно вытянуть на 90нм.
Ибо в ASIC нету ничего лишнего что есть в LUT. Ну и конце концов, FPGA делается в ASIC тулзах....

Подскажите, как реализован механизм выравнивания skew на кристале ?

Что касается FPGA, то Shivers Вам о тветил - клок три фиксировано.
Дополню просто для понимания как это можна в ASIC....

1) skew тул выравнивает: вставляя буфера, меняя их розмер, делая оптимальний плейсмент, меняя точки подключение листьев, строя физически симетричную или несиметричную структуру.

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

2) Вэтом случае будет не хрень а Useful Skew
При этом можно как буферы вставлять так и подключать флопы кудато в середину дерева

Кроме того, насколько я понимаю процесс выравнивания должен быть динамическим (ведь триггеры каждого квадранта щелкают не в каждом такте ... ) Значит, механзмы синхронизации в матрице должны быть динамическими и реализованными в аналоге ?

3) Динамика тригеров (сколько и когда щёлкает) не учитывается при построении клок три.