Jump to content

    

Bad0512

Свой
  • Content Count

    871
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Bad0512

  • Rank
    Знающий
  • Birthday 12/05/1972

Контакты

  • MSN
    Array
  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

4299 profile views
  1. Делал когда-то подобные штуки с помощью атрибутов синтеза. max_fanout для вивады и syn_maxfan для синплифая. Вставлял эти атрибуты прямо в верилоговские исходники, но это очевидно плохой способ - надо аналогичные директивы писать в XDC/SDC файлы чтобы переносимость исходников не страдала.
  2. Я возможно странный вопрос задам, однако : Чем обусловлено наличие двух независимых мастеров в ПЛИС, которые даже не знают о существовании друг друга, то есть не могут договориться об очередности доступа к слейву программно? Может тут надо на системном уровне в начале проблемы порешать? З Ы Вы конечно можете реализовать честный арбитр, который реализует данную схему доступа, но при этом вам придется добавить интерфейс между мастерами и арбитром (добавить сигналы REQ и GNT в каждый инстанс мастера и "научить" мастера начинать транзакцию только после получения ответа от арбитра. Не такая уж сложная штука вроде бы, но об этом надо помнить.
  3. биты внутри байта можно переставлять как удобно для разводки. В том числе и нулевой - он ничем от остальных не отличается. Ничего править в UCF (а точнее в XDC) не нужно, так как порядок бит будет нарушен как на запись, так и на чтение, поэтому ПЛИС об этой перестановке ничего даже не узнает.
  4. Самый неприятный (и не очевидный для вас) косяк вашей схемы - это разгон джиттера. В случае каскадного (последовательного) соединения подобных каналов связи ситуация с джиттером будет ухудшаться и в пределе CDR на самом дальнем в цепочке приемнике перестанет входить в захват. При увеличении длины оптического линка ситуация также будет ухудшаться. Подобные проблемы решаются в сетях SyncE с помощью специальных внешних джитееродавов, но у них тоже есть проблемы с низкочастотным джиттером (называют "вандером"). Этот шум невозможно отфильтровать петлёй ФАПЧ, поэтому это - отдельная проблема.
  5. Как версия (я бы сделал так) прошивка как-то вяжется к уникальному ID проца для защиты от нелегального тиражирования. Меняешь проц - прошивка с новым не работает. З Ы Вообще FSBL может находиться и не в NAND - надо смотреть схему на ваш девайс.
  6. Коллеги, посоветуйте годной литературы по Vivado HLS. По служебной необходимости есть задача освоить это кунг-фу. Хотелось бы сделать это наиболее приятным способом, без рака мозга. З Ы Стандартные доки от Xilinx предлагать нет смысла - они в любом случае в списке на изучение.
  7. возьмите еще один экземпляр своей платы и проверьте на нем. Если эффект не повторяется, то видимо дело в конкретном экземпляре. Если повторяется - надо копать дальше. З Ы выходных стробов также может не быть вообще из-за отсутствующих констрейнов на клок.
  8. 112 МГц - это частота сэмплирования, правильно? Сигнал оцифровываемый у вас какого типа? На нуле или на несущей? Какова несущая частота если ненулевая? З Ы Возможно у вас там тупо третья гармоника пролазит, и тут только фильтрами можно побороть... Ещё неплохо бы понять каким образом организовано у вас тактирование АЦП и ПЛИС. Там есть нюансы.
  9. Проблема номер один - отчеты по таймингу описывают проблемы в другом дизайне. В этом дизайне модуль design_1 вообще никак не участвует.
  10. Я поглядел ваш изначальный проект, и не увидел в нём никаких ошибок в тайминге. Возможно вы сделали в проекте какие-то критические для тайминга изменения. Не могли бы вы выложить текущий проект ещё раз? А то получается что мы разные версии проекта смотрим.
  11. трудно гадать на кофейной гуще. Тайминг может расползтись по самым разным причинам. Приложите отчет по таймингу, хотя бы самые критичные цепи.
  12. Мои 5 копеек в тему. 1. Микроблейз вам скорее всего не нужен. Если есть встроенный АРМ - зачем ещё плодить сущности? 2. АРМ можно легко запрограммить самому, тут (о боже!!!) можно обойтись без "программистов высокого уровня". Достаточно собрать под sdk (снейчас это называется Vitis) своё небольшое bare metal приложение. Если ваша цель - доказать работоспособность железа, то этот путь очень даже подходит. 3. Всякие унылые мосты SPI-I2C - очень неплохая задачка для скучающих студентов, но у вас, наверняка, время ограничено.Все эти неспешные протоколы гораздо проще реализовывать в софте. На отладку всех этих мелких корок (с учетом диалектов протоколов под разные мелкие девайсы) вы угробите гораздо больше времени, чем на отладку bit bang драйвера. Ну то есть идея проста как валенок - заводите все ноги от низкоскоростных протоколов на Zynq GPIO и дергаете ими как вам захочется. 4. Посчитатйте потоки данных с ваших АЦП/ЦАП и убедитесь, что производительности присоединенных AXI stream шин достаточно для вашей задачи. Если недостаточно - примите меры. 5. Ваше bare metal application может потом быть использовано для factory testing. В отличие от линуха, оно может спокойно уместиться во внутренней RAM и тестировать внешнюю DDR на предмет исправности.
  13. А за жирный шрифт тут занете что бывает? И зачем одну и ту же вакансию дважды переписывать? Не идёт никто за 70к деревянных в дефолт-сити плисоводом горбатиться? Да неужели???