[fguy 4]

6 часов назад, dxp сказал:

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

Уже можно сказать родная и на подхвате - если приживется, то будет везде в следующих поколениях плис. По факту еще один вариант реализации конвейера с широким потоком обрабатываемых данных (512 бит), что то типа операций SSE и AVX - в плис то же можно так делать, но уж очень сильно скорость зависит от сложности проекта, а здесь этот недостаток отсутствует.

[blackfin 16]

13 hours ago, fguy said:

Блок из 400 процов потребует принятия новых подходов к проектированию и программированию.

А что это за процы? И почему их так много? Может, можно все сделать как-то проще?

[RobFPGA 27]

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

6 minutes ago, fguy said:

По факту еще один вариант реализации конвейера с широким потоком обрабатываемых данных (512 бит), что то типа операций SSE и AVX - в плис то же можно так делать, но уж очень сильно скорость зависит от сложности проекта, а здесь этот недостаток отсутствует.

Зато будут другие недостатки. 
Каждая архитектура  (тем более  если часть  ее выполненная  виде hadr IP)  имеет  как преимущества так и недостатки.  Чем  мельче строительный "кирпич"  тем он универсальнее,  но соответсвенно и тем сложнее  сделать из него  реальный дизайн. 

Хорошо  то что есть  выбор  на  какой архитектуре  делать то или иное решение. 

Удачи! Rob.

[dxp 33]

37 минут назад, blackfin сказал:

А что это за процы? И почему их так много? Может, можно все сделать как-то проще?

Там двумерный массив (условно) мелких процессорных ядер, каждое из которых содержит три вычислительных юнита: один скалярный и два векторных (один с фиксированной точкой, другой с плавающией), память программ 16 кбайт и память данных 32 кбайт. В память данных могут лазить не только свои юниты, но и из прилегающих ядер (специальные мосты там для этого: "север", "юг", "запад", "восток"). Сама память состоит из 8 однопортовых банков, доступ к которым может быть одновременным. Ширина шин доступа: две шины по 256 бит на чтение и одна 256 бит на запись, т.е. два 256-бит чтения и она 256-бит запись за такт. Векторные юниты (собственно, в них вся моща) и дают лютое ускорение (типа 128 умножений 8х8 за такт) вычислений. Тактовая частота 1 ГГц. Можно распределить алгоритм так, что одно ядро делает свою часть алгоритма, перекидывая промежуточные данные в память следующему ядру, то делает свою часть и т.д. Это, вроде, основное отличие от GPU подхода, где вся толпа ядер выполняет одну операцию.

 

Программируется это всё на C/C++. Векторные фичи задействуются через специальный API на интринсиках. Но чтобы с этим эффективно работать, надо прокачивать бэкграунд по параллельным вычислениям.

 

[blackfin 16]

4 minutes ago, dxp said:

Там двумерный массив (условно) мелких процессорных ядер ...

Ужос! Не знал. Спасибо, за ликбез.. :)

[fguy 4]

2 часа назад, dxp сказал:

Тактовая частота 1 ГГц. Можно распределить алгоритм так, что одно ядро делает свою часть алгоритма, перекидывая промежуточные данные в память следующему ядру, то делает свою часть и т.д.

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

[nice_vladi 1]

Итак, закончил упраженения с новой вивадой. Была установлена 2020.2. В ней создан проект с block design, ip. Всё это помещено в git. Опытным путем выяснил, что для корректной сборки проекта достаточно оставить в нём .xci файлы. В реузльтате получил вот такой gitignore:

netlist/*.cache
netlist/*.hw
netlist/*.gen
netlist/*.runs
netlist/*.sim
netlist/.Xil
netlist/*.ip_user_files
netlist/*.srcs/sources*/bd/**
!netlist/*.srcs/sources*/bd/**/*.xci
netlist/*.srcs/sources*/ip/**
!netlist/*.srcs/sources*/ip/**/*.xci

.ioplanning
*.jou
*.log

sim/**/work
sim/**/*.ini

Единственное, что стало хуже - после выгрузки чистого проекта из git, Vivado оооочень долго его открывает. Последующие запуски - нормально.

[blackfin 16]

5 minutes ago, nice_vladi said:

Опытным путем выяснил, что для корректной сборки проекта достаточно оставить в нём .xci файлы.

Тогда, наверное, нужно оставить и файлы *.xcix

[nice_vladi 1]

4 minutes ago, blackfin said:

Тогда, наверное, нужно оставить и файлы *.xcix

У меня их вообще нет.

[Strob 0]

2 minutes ago, blackfin said:

Тогда, наверное, нужно оставить и файлы *.xcix

Эти контейнеры большие. Не очень хорошо их в гит пихать. Я так и не почувствовал на практике, какое преимущество .xcix даёт в плане контроля версий

[1891ВМ12Я 0]

По теме скажу, что в git/hg просто учился по мере изучения Vivado что надо добавлять а что нет, что важно а что нет. Всю тему не смотрел, но удалось ли сформулировать общие правила? Главное что можно делать так называемые reset-ы разных стадий, и тогда я замечал что лишних файлов практически нет. Также я не добавляю файлы симуляций.