[Manvel 0]

Здравствуйте, уважаемые товарищи! 
Эти вопросы я задавал на форуме интела но исчерпывающих для себя ответов не получил (https://community.intel.com/t5/FPGA-SoC-And-CPLD-Boards-And/Parallel-sum-frequency/m-p/1286075#M19982), поэтому решил повторить вопросы на данном форуме. 

И так, у меня есть задача смоделировать хаотическую систему, которая по сути из себя представляет 2 цифровых БИХ фильтра с нелинейным элементом в обратной связи. В процессе ознакомления с Verilog и с Quartus я решил, что высокой скорости можно добиться при использовании для этой задачи мегафункции от Квартуса - Parallel sum. В целом, на том железе, что у меня сейчас есть в распоряжении (DE10-lite и ice40-dac) все нормально работает на частотах тактирования 100 МГц, но имеется необходимость поднять частоты.
 

На форуме интела мне подсказали, что надо задавать временные ограничения. Я прочитал немножко литературы (в частности https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug-qpp-timing-analyzer.pdf) и у меня возникли вопросы.
1. Нужно ли задавать дополнительные временные ограничения для синхронной логики, кроме ограничений на частоту клока, например "set_max_delay -from [get_registers {x_1_3*}] -to [get_registers x_2_1d*] X ns"? Когда я задаю эти дополнительные ограничения, это почти никак не влияет на скорость собранного проекта, может эти ограничения надо задавать по другому? 

2. Второй вопрос относится к быстрой и медленной модели проекта в Таймквесте. Для медленной модели Таймквест оценивает максимальную частоту около 200 МГц при этом для быстрой модели частота достигается до 340 МГц, что как бы разница существенная. По их документам (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/wp/wp-01139-timing-model.pdf) не понятно, скорость быстрой модели больше зависит от напряжения подаваемого на кристалл или от качества кристалла, эти два параметра занесены под одну модель, а железа на такие скорости пока не имеются для экспериментальной проверки, ну и покупка железа будет зависеть именно от возможных максимальных частот. 

Изменено 20 июня, 2021 пользователем Manvel

[Lmx2315 2]

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

Чтобы делать схему быстрее надо мудрить с реализацией, делать конвеер например, или искать более оптимальные решения проблемных частей.

[Nick_K 0]

9 hours ago, Manvel said:

Для медленной модели Таймквест оценивает максимальную частоту около 200 МГц при этом для быстрой модели частота достигается до 340 МГц, что как бы разница существенная.

Обычно скорость работы зависит от трёх параметров: Напряжения, Температуры и Техпроцесса.

Если говороить про напряжение, то скорее всего вы никаким образом не сможете влиять на значение скорости, т.к. в ФПГА встроены стабилизаторы, а архитектурные параметры мощности предопределены семейством. В данном случае играться можно с плотностью/величиной проекта - чем меньше задействовано флопов, тем быстрее будет работать чип.

С температурой всё просто: будет греться - охлаждайте. Можно просто хороший радиатор, иногда куллер. При большом проекте - жидкий азот тоже будет работать 

И вопрос техпроцесса решается обычным Спидгрейдом на кристалле. Не вдаваясь в детали - самый быстрый спидгрейд позволит работать на большей частоте, при прочих равных

Итого если взять маленький проект (минимально необходимый с небольшой утилизацией), повесить радиатор с куллером и залить в самый быстрый чип выбранного семейства Вы вполне можете получить рабочий проект в железе на 340 MHz

[des00 25]

2. Slow/Fast это разборс таймингов внутри семейства одного спидгрейта, анализ делается в наихудших условиях по времянке для каждого из вариантов.

[RobFPGA 27]

'nj  Приветствую!

2 hours ago, Nick_K said:

Обычно скорость работы зависит от трёх параметров: Напряжения, Температуры и Техпроцесса.

В этом вы правы 

2 hours ago, Nick_K said:

Если говороить про напряжение, то скорее всего вы никаким образом не сможете влиять на значение скорости, т.к. в ФПГА встроены стабилизаторы, а архитектурные параметры мощности предопределены семейством.

А вот это уже фантазии   -   в большинстве семейств FPGA напряжения питания задаются внешними источниками  и при некоторой доле риска позволяют как разгонять  так и снижать быстродействие (равно как и потребление)   

Но  вот  TC думать  о таких  вещах как разгон  напряжением  смысла нет.   
Изначально ему  надо решить  чисто дизайнерскую задачу  -  конвейеризировать  вычисления таким образом чтобы  минимизировать длину критических путей. С учетом того что у него в дизайне присутствует 7-входовой  параллельные сумматоры (сплошная комбинаторика) там есть  пространство для оптимизаций. 

12 hours ago, Manvel said:

2. Второй вопрос относится к быстрой и медленной модели проекта в Таймквесте.

Slow corner и Fast corner  это анализ задержек  для двух   крайних  случаев работы FPGA в пределах одного Speed Grade 
Fast - минимальная допустимая рабочая температура, максимально допустимое  рабочее напряжение,  (минимальные задержки) 

Slow- максимально допустимая рабочая температура, минимальное допустимое  рабочее напряжение,  (максимальные задержки) 

 

Удачи!  Rob.

[des00 25]

2 hours ago, RobFPGA said:

Slow corner и Fast corner  это анализ задержек  для двух   крайних  случаев работы FPGA в пределах одного Speed Grade 

Fast - минимальная допустимая рабочая температура, максимально допустимое  рабочее напряжение,  (минимальные задержки) 

Slow- максимально допустимая рабочая температура, минимальное допустимое  рабочее напряжение,  (максимальные задержки)

вот тут не соглашусь. штатно, в квартусе, ЕМПН, делается анализ на 3 slow варианта(при разных температурах и напряжениях) и на один fast.

[new123 0]

5 hours ago, des00 said:

вот тут не соглашусь. штатно, в квартусе, ЕМПН, делается анализ на 3 slow варианта(при разных температурах и напряжениях) и на один fast.

может от чипа зависит?
у меня на StratixV 2 Slow + 2 Fast, а на 10 черт ногу сломит, сколько они тут режимов наделали

[yes 5]

12 hours ago, RobFPGA said:

 в большинстве семейств FPGA напряжения питания задаются внешними источниками  и при некоторой доле риска позволяют как разгонять  так и снижать быстродействие (равно как и потребление)   

баловался с самосинхронными схемами на актеле - так там явно зависит частота работы от напряжения - начинало дергаться при 0.6В и где-то к 1.5В (по-моему такой там был максимум) уже вполне бодро - раза в 3 больше частота.

там наверно встроенного детектора напряжения/супервизора не было, поэтому такой диаппазон.

 

=========================

ну и FAST SLOW еще учитывают (должны) разброс самого кремния - в SLOW "плохой" 

==========================

а по поводу корненов - если сейчас FDSOI технологии пойдут в массы (пока вроде только GF) то там корнеров будет вообще дофига (можно еще разные напряжения подавать на подложку) кроме обычных процесс/температура/напряжение.

ну и еще могут быть специфические углы - для оценки потребления или инверсион феномена и т.п. - это у технологов надо спрашивать - то есть не получается все самое плохое собрать в один угол, а самое хорошее в другой

 

 

4 hours ago, new123 said:

может от чипа зависит?

от технологии производства (ноды) ну и желания вендора (Интеля) грузить этим всем юзера

для того же FDSOI продвигают адаптивное напряжение(я) на карманы - тогда вообще от температуры и напряжения тайминг не зависит (по их рекламке, по крайней мере)

[vt313 0]

20.06.2021 в 22:16, Manvel сказал:

Здравствуйте, уважаемые товарищи! 
Эти вопросы я задавал на форуме интела но исчерпывающих для себя ответов не получил (https://community.intel.com/t5/FPGA-SoC-And-CPLD-Boards-And/Parallel-sum-frequency/m-p/1286075#M19982), поэтому решил повторить вопросы на данном форуме. 

И так, у меня есть задача смоделировать хаотическую систему, которая по сути из себя представляет 2 цифровых БИХ фильтра с нелинейным элементом в обратной связи. В процессе ознакомления с Verilog и с Quartus я решил, что высокой скорости можно добиться при использовании для этой задачи мегафункции от Квартуса - Parallel sum. В целом, на том железе, что у меня сейчас есть в распоряжении (DE10-lite и ice40-dac) все нормально работает на частотах тактирования 100 МГц, но имеется необходимость поднять частоты.
 

На форуме интела мне подсказали, что надо задавать временные ограничения. Я прочитал немножко литературы (в частности https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug-qpp-timing-analyzer.pdf) и у меня возникли вопросы.
1. Нужно ли задавать дополнительные временные ограничения для синхронной логики, кроме ограничений на частоту клока, например "set_max_delay -from [get_registers {x_1_3*}] -to [get_registers x_2_1d*] X ns"? Когда я задаю эти дополнительные ограничения, это почти никак не влияет на скорость собранного проекта, может эти ограничения надо задавать по другому? 

2. Второй вопрос относится к быстрой и медленной модели проекта в Таймквесте. Для медленной модели Таймквест оценивает максимальную частоту около 200 МГц при этом для быстрой модели частота достигается до 340 МГц, что как бы разница существенная. По их документам (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/wp/wp-01139-timing-model.pdf) не понятно, скорость быстрой модели больше зависит от напряжения подаваемого на кристалл или от качества кристалла, эти два параметра занесены под одну модель, а железа на такие скорости пока не имеются для экспериментальной проверки, ну и покупка железа будет зависеть именно от возможных максимальных частот. 

 

А можно формулу порождающую этот проект?

[Manvel 0]

21.06.2021 в 11:06, RobFPGA сказал:

'nj  Приветствую!

В этом вы правы 

А вот это уже фантазии   -   в большинстве семейств FPGA напряжения питания задаются внешними источниками  и при некоторой доле риска позволяют как разгонять  так и снижать быстродействие (равно как и потребление)   

Но  вот  TC думать  о таких  вещах как разгон  напряжением  смысла нет.   
Изначально ему  надо решить  чисто дизайнерскую задачу  -  конвейеризировать  вычисления таким образом чтобы  минимизировать длину критических путей. С учетом того что у него в дизайне присутствует 7-входовой  параллельные сумматоры (сплошная комбинаторика) там есть  пространство для оптимизаций. 

Slow corner и Fast corner  это анализ задержек  для двух   крайних  случаев работы FPGA в пределах одного Speed Grade 
Fast - минимальная допустимая рабочая температура, максимально допустимое  рабочее напряжение,  (минимальные задержки) 

Slow- максимально допустимая рабочая температура, минимальное допустимое  рабочее напряжение,  (максимальные задержки) 

 

Удачи!  Rob.

Конверизацию устроить не получится, так как система с обратной связью, пока n-ое значение не посчитаешь, нельзя посчитать n+1 -ое. 

 

 

Всем спасибо за ваши ответы, они, кончено, частично расходятся) но мне стало яснее)

12 часов назад, vt313 сказал:

А можно формулу порождающую этот проект?

Это не совсем формула, и на картине проект неполный. Если вас заинтересовало явление динамического хаоса предлагаю прочитать книжку Кузнецов С. П. "Динамический хаос", ближе к тому, что я именно делаю, будет статья прикрепленная к ответу 

Kuznetsov-SP-Dinamicheskii-haos.djvu Ustanovlenie_haoticeskogo_sinhronnogo_otklika_pri_.pdf

Изменено 22 июня, 2021 пользователем Manvel

[vt313 0]

17 часов назад, Manvel сказал:

Конверизацию устроить не получится, так как система с обратной связью, пока n-ое значение не посчитаешь, нельзя посчитать n+1 -ое. 

 

 

Всем спасибо за ваши ответы, они, кончено, частично расходятся) но мне стало яснее)

Это не совсем формула, и на картине проект неполный. Если вас заинтересовало явление динамического хаоса предлагаю прочитать книжку Кузнецов С. П. "Динамический хаос", ближе к тому, что я именно делаю, будет статья прикрепленная к ответу 

Kuznetsov-SP-Dinamicheskii-haos.djvu 2 MB · 2 скачивания Ustanovlenie_haoticeskogo_sinhronnogo_otklika_pri_.pdf 289 kB · 3 скачивания

 

Нет, вникать глубоко, это слишком. Просто там сгенерировано что-то довольно сложное. 

На практике, генераторы различных фильтров далеки от оптимальных. Если скорость не устраивает, напишите их сами. 

[RobFPGA 27]

Приветствую!

22 hours ago, Manvel said:

Конверизацию устроить не получится, так как система с обратной связью, пока n-ое значение не посчитаешь, нельзя посчитать n+1 -ое. 

На  первый взгляд не оптимально распределены задержки  - выхода регистров сумматора (регистры x_1_d, x_2_D) используются  лишь для распределения  кода на следующий слой регистров, а наверное можно было бы часть сумм перенести на этот слой.  Ну и выход этого модуля  лучше  брать не непосредственно с сумматора а опять же с выхода   регистров x_1_d, x_2_D, меньше fanout - выше  частота. 

Опять же  на картинке чисто цифровая система  которая имеет детерминированное  поведение. Соответвенно  зная предыдущее состоянии можно вычислить следующее.
А раз так то можно попытается распараллелить вычисления состояний  на 2,3..N и более  веток  вычисляя в  каждой ветке N-е значение последовательности даже  за счет небольшого увеличения числа  тактов  в каждой ветке  суммарная  частота генерации отсчетов за счет параллелизма будет больше.

  

Удачи! Rob. 

[vt313 0]

23.06.2021 в 15:39, RobFPGA сказал:

Приветствую!

На  первый взгляд не оптимально распределены задержки  - выхода регистров сумматора (регистры x_1_d, x_2_D) используются  лишь для распределения  кода на следующий слой регистров, а наверное можно было бы часть сумм перенести на этот слой.  Ну и выход этого модуля  лучше  брать не непосредственно с сумматора а опять же с выхода   регистров x_1_d, x_2_D, меньше fanout - выше  частота. 

Опять же  на картинке чисто цифровая система  которая имеет детерминированное  поведение. Соответвенно  зная предыдущее состоянии можно вычислить следующее.
А раз так то можно попытается распараллелить вычисления состояний  на 2,3..N и более  веток  вычисляя в  каждой ветке N-е значение последовательности даже  за счет небольшого увеличения числа  тактов  в каждой ветке  суммарная  частота генерации отсчетов за счет параллелизма будет больше.

  

Удачи! Rob. 

Скорее всего тут следующее.

Есть некий генератор, он, по своему алгоритму, создал схему. Там все уже распараллелено.

Вариаций у вас , - только выбрать другой алгоритм генерации. 

Или попробовать написать самому. Тогда есть возможность менять. 

[Manvel 0]

23.06.2021 в 13:40, vt313 сказал:

Нет, вникать глубоко, это слишком. Просто там сгенерировано что-то довольно сложное. 

На практике, генераторы различных фильтров далеки от оптимальных. Если скорость не устраивает, напишите их сами. 

То что я делаю, по сути из себя представляет систему из двух диф уравнений 2 порядка (приближенно можно сказать, что 2 фильтра 2-го порядка ФНЧ и ФВЧ) с нелинейной обратной связью. Далее вместо того, чтобы решать методом Рунге Кутта эти уравнения я делаю билинейное преобразования и получаю цифровое представление этой системы. В приведенной выше статье все эти шаги достаточно подробно описаны. Я не использую Альтеровсике библиотеки цифровых фильтров, потому что они относительно медленные из-за использования блоков перемножения, в данном случае, чтобы максимально ускорить систему я даже перемножения не использую, а просто суммирование со смещением максимум по первым трем битам коэффициентов цифрового фильтра. Скоро я должен буду приготовить семинар по тому что я сделал, если вам интересно, скину презентацию.

23.06.2021 в 15:39, RobFPGA сказал:

Приветствую!

На  первый взгляд не оптимально распределены задержки  - выхода регистров сумматора (регистры x_1_d, x_2_D) используются  лишь для распределения  кода на следующий слой регистров, а наверное можно было бы часть сумм перенести на этот слой.  Ну и выход этого модуля  лучше  брать не непосредственно с сумматора а опять же с выхода   регистров x_1_d, x_2_D, меньше fanout - выше  частота. 

Опять же  на картинке чисто цифровая система  которая имеет детерминированное  поведение. Соответвенно  зная предыдущее состоянии можно вычислить следующее.
А раз так то можно попытается распараллелить вычисления состояний  на 2,3..N и более  веток  вычисляя в  каждой ветке N-е значение последовательности даже  за счет небольшого увеличения числа  тактов  в каждой ветке  суммарная  частота генерации отсчетов за счет параллелизма будет больше.

  

Удачи! Rob. 

То что вы предлагаете я ранее обдумывал, но у меня не вышло это никак реализовать, но я еще подумаю над этим, спасибо за совет!

[yes 5]

4 hours ago, Manvel said:

То что я делаю, по сути из себя представляет систему из двух диф уравнений 2 порядка (приближенно можно сказать, что 2 фильтра 2-го порядка ФНЧ и ФВЧ) с нелинейной обратной связью

извините за любопытство, а где, в какой организации, вы этим занимаетесь? если не секрет