Перейти к содержанию

    

fguy

Участник
  • Публикаций

    70
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о fguy

  • Звание
    Участник

Посетители профиля

701 просмотр профиля
  1. "СЕ шина" это когда на входе слэйва стоит сигнал ClockEnable и по нему он должен защелнуть данные. Ядра могут иметь право "ложить" на готовность слэйва исключительно по независящим от них причинам, например, ядро приемника GTx для физических интерфейсов не предусматривающих приостановку передаваемого потока данных (например JESD ADC) - все остальные случаи это произвол авторов. И я не спорю с тем что в таком случае слэйв должен обрабатывать каждый такт, но имея только СЕ с его стороны вы не имеете прямых методов контроля за непрерывностью процесса обработки.
  2. Передача данных по СЕ это даже не шина - это тупое навязывание данных мастером слэйву без учета готовности последнего - отсих у "классиков" кошмары на латентность и желание все сделать за один такт. По факту AXI-stream это простое расширение шины фифо с добавлением дополнительных линий (last, user, strb/keep и т.п.). Учет готовности слэйва мастером это уже смена парадигмы - вы перестаете шарахаться от латентности, можно менять интервалы обработки данных, варьируя ширину шины и частоту. Вместо потери данных, которую легко не заметить, получаете тормоза на входе конвейера, которые замечательно отслеживаются.
  3. кзаленс уже и так изменил парадигму в виваде - от антикварных ядер с СЕ перешел на повсеместное использование акси-стримов как для дсп и видео, так и для езернета и в довесок куча ядер для удобств работы со стримами - а для написания ядер обрабатывающих стримы хлс подходит как родной
  4. Уж лет 5 этой новинке и вполне успешно использовался в 2014 году. Понимать как работает железо нужно при любом кодинге под него. Никаких других прагм кроме PIPELINE в цикле я не добавлял, а добавление UNROLL проблему то же не решило в 2018.3 - видимо это очередной косяк синтезатора HLS. Уже заметил что в некоторых случаях 2018.3 требует написание прагм по ресурсам, которые в 2017.4 были само собой разумеющимся. Возможно и этот косяк решается каким либо хитрым сочетанием прагм. Вивадовский симулятор как раз и освоил для симуляции полученных ядер, но как уже писал выше столкнулся с неадекватностью на железе - не часто но случается.
  5. за качество кода коллег в VHDL ни чего не скажу по причине отсутствия опыта, а в HLS иногда приходится писать полный бред на С-ях, т.к. адекватные и красивые конструкции превращаются либо в непотребное по ресурсам, либо в неработоспособное
  6. опыт не маленький и для "классики" на VHDL отладка в альдеке была и остается штатным методом работы многая лета у коллег, но исключения увы бывают и как ни странно ни в каких то огромных проектах, а на сравнительно небольших ядрах, а синтез ядер в HLS это вообще лотерея с полным неадекватом на самом ровном месте, а результаты имплемента его творений иногда (одно радует что редко) жгут просто не по-детски - давеча пару последних вивад стошнило на простом бесконечном цикле с выводом счетчика в стрим - синтезатор hls тупо талдычит невнятную ошибку - поиск ничего не дал - видимо я первым наступил - "непосильную" задачу осилила только версия 2017.4
  7. симуляторы судя по своему опыту с hls и коллег с VHDL имеют сомнительную ценность при текущем положении дел с имплементацией - работоспособность полученного опосля синтеза в симуляторе не дает никаких гарантий что на чипе все будет так же красиво
  8. Как можно отказываться от того чего у нас заменить просто не чем - эти аналоги бородатых плис в наше время ни о чем - максимум на что они годны это заменить вражьи оригиналы в старых "изделиях", которые все еще выпускаются, а хотелки в современной обработке сигналов рассчитаны уже на ультраскэйлы - иногда создается ощущение что заказчики читают анонсы новых чипов у зарубежных производителей и под них пишут свои ТЗ.
  9. У меня окромя штатных ядер еще пара десятков своих на хлс-е и немного VHDL-ядер и все это интенсивно правится без особых проблем. Вивада при открытом БД отслеживает изменения ядер в папке репозитория и оповещает об этом с предложением обновиться, при изменениях в интерфейсах для обновленных ядер выдается предупреждение. Так что работать над проектом вполне себе удобно. Крупный проект разбивается на функциональные блоки Hierarchy, что избавляет от огромной портянки с сотней ядер в одном окне. Косяки конечно же есть как и везде - верификатор видит далеко не все проблемы, при верификации тупо упирается в несоответствие типов данных на входных стримах для IP floating_point - имхо достаточно было бы проверять ширину, жуткие тормоза при конфигурировании IP FFT и т.д.
  10. Пользуюсь только BD с самого появления вивады (2014). Поначалу были неудобства в необходимости "ручками" раскидывать ресеты - в исе для микроблэйза это делалось автоматом. Далее с усложнением проектов стало понятно что древовидная структура в исе превратится в "дикий ужос" когда число ядер в проекте достигнет хотя бы 30-40. Сейчас в проектах число ядер доходит до 200 (по инфе вивады). Соединить это все в виде легко читаемого текста на VHDL просто не реально, а уж оперативно что то поправить и подавно. Ядро AXI Interconnect это не совсем "ядро" - это сборка из ядер которая формируется динамически из более мелких кубиков в зависимости от настроек конфигурации. Вы можете собрать ее сами, но удовольствие будет еще то. "Ядро" гигабитного эзернета это так же такая же сборка. Изменить их ручками нельзя - зато можно легко скопировать копи-пастом в свой Hierarchy. Если вы хотите использовать в БД свои исходники то оформляйте их как ядра вивады и сможете оперировать ими в БД. Сигналы интерфейсов коннектятся по именам с констрэйнами для физических пинов без всяких доп. оберток в виде топа на VHDL, а так же доступны ядра для установки ручками всяких буферов (BUFG и т.п.). Тристэйты во враппере БД автоматом прогоняются через буфера и становятся обычными inout. Копировать БД между проектами штатными средствами (через буфер копи-пастом или вивадой) возможности к сожалению нет, а ручками делается все просто - копируем папку ваш_проект.srcs\sources_1\bd\ваш_бд в другой проект в это же место и добавляем ссылку на него в файл "имя_проекта.xpr" в корне проекта. Далее открываем измененный проект и через буфер копи-пастом переносим что нужно между БД.
  11. Обновил на пробу проект для цинка (кинтекс) с 2018.2 на новую. Проблем особых при конвертации не было. Заметная разница только в фифохах - изменили настройки - можно выбирать ручками как реализовывать - LUT или BRAM (может быть и URAM где есть), убрали ресеты по выходным тактам для асинхронных и добавили отключаемые счетчики, отображает итоговый размер. Так что пройтись по всем фифохам после обновления BD не помешает. Результаты разводки сравнить не получилось - фифохи поставил на автовыбор ресурса, а в результате расклад другой по BRAM и часть перешла в LUTRAM со всеми вытекающими. Время имплемента оказалось меньше минут на 15 с 1.5 часов на старой, а синтез практически не ускорился. Не смотря на отсутствие упоминания в списке обновлений, HLS все же изменился и заметно - из плюсов качество синтеза ядер улучшилось (меньше LUT, FF, времена и латентность), а из минусов теперь обязательно приходится писать прагмы по ресурсам, которые в 2018.2 были типа как само собой разумеющееся, иначе на выходе синтезатора полный неадекват.
  12. сделайте на 3х пинах гпио - дергайте ими в нужной последовательности
  13. Смотрите внимательно настройки ядра qspi - оно работает в одно-, двух- и 4-х канальном режиме. Если ничего не помогает - читайте даташит по ядру.
  14. у Капитанова есть несколько открытых реализаций, но под Xilinx https://github.com/capitanov?tab=repositories