Jump to content

    

RobFPGA

Свой
  • Content Count

    2385
  • Joined

  • Last visited

Everything posted by RobFPGA


  1. Приветствую! Проблема в том что в вашей функции clogb2 возможна ситуация когда calc НЕ вычисляется - например если number <=0 . Соответственно Qu на такое считает что функция неконстантна. Для синтеза в константных функциях важно чтобы все ветки вычислялись или переменные имели дефолтные значения. Ну и если у вас SystemVerilog то почему бы не использовать встроенный $clog2(); Удачи! Rob.
  2. Приветствую! Это понятно, лень матушку надо лелеять и баловать Но увы - массив строковых переменных словами из одной исходной строки без парсера (даже простейшего) не заполнить. Так что "Пилите Шура, пилите ..." (... строку на слова) Удачи! Rob.
  3. Приветствую! Опять вы себе жизнь усложняете Где в задании сказано что инициализировать mystr по умолчанию надо рандомными словами? То есть объявление string mystr = "bla bla bla и еще 18 символов!" как раз укладывается в условие задачи Если же хочется заполнят рандомными словами тогда да - придется в цикле сначала генерировать эти слова а уж затем склеивать их в строку. Ну и получив строку через $value$plusargs (или взяв то что задали по умолчанию) придется парсить выделяя слова в пробелах. По умолчанию массивы инициализируются константами через = `{....}. Удачи! Rob.
  4. Приветствую! Для частотомера можно и ripple counter счетчик использовать. Тогда можно выжать высокую частоту счета близкую к максимально возможной для триггера (да и старт/стоп только для входного триггера делать удобнее). Естественно надо акуратно останавливать его и ждать перед считыванием пока все "успокоится" Удачи! Rob.
  5. Приветствую! Вам же в задании не сказано инвертировать все поля разом? Ну так и инвертируйте поэлементно! Зачем себе жизнь усложнять var1 = '{36, "453", 234, 434}; initial begin var1.field1 = ~var1.field1; var1.field3 = ~var1.field3; var1.field4 = ~var1.field4; ... Удачи! Rob.
  6. Приветствую! Странно - то вы пишете что на холостом ток 130 мА - то что на холостом греется на 100 Вт ? Как то не стыкуются цифры. Приведенный вами движек ДАО 73-16-3-Д33 малой мощности, дешевый по конструкции и ожидать от него высоких характеристик КПД бессмысленно. Такие движки специально проектируются чтобы безопасно эксплуатироваться в быту без применения спец защитных автоматов. Удачи! Rob.В
  7. Приветствую! IMHO в таблице приведены параметры и потребляемая мощность двигателя на холостом ходу, без всякой нагрузки. И макс. ток при максимальной нагрузке. То есть такой двиг. кушает 16 ват сам по себе. Что не удивительно для дешевых двигателей с кпд ~85% . Удачи! Rob.
  8. Приветствую! Ну вот берите и считайте - 16 бит 800х600х25 получается ~24 MB/s. Для 1600x1200 все в 4 раза хуже - ~96 MB/s. Программным чтением через CPU вы такой поток не вытащите, даже с большими буферами и частыми прерываниями. Так что без DMA вам никак. А когда DMA есть то буфера в FPGA нужны (как и говорили выше) небольшие - лишь для сглаживания пиковых провалов на шине PCIe и задержек при пере-инициализации DMA. Ну и прерывания если и нужны будут то только для этого, что как раз можно совместить с размером кадра. Удачи! Rob.
  9. Приветствую! Думаю что универсального рецепта пока нет - где то удобно интерфейсами, где-то структурами, а где-то и голыми портами да еще с потрошками макросами Каждый выбирает как ему более нравится. Хорошо когда есть из чего выбрать! Удачи! Rob.
  10. Приветствую! MSI/MSIx прерывания через PCIe это фактически запись со стороны периферийного устройства (FPGA) 32 бит слова по определенному адресу в PC. Генерировать такое прерывание можно хоть каждую 1 us, НО сомневаюсь что ваша OS потянет обработку прерываний с такой частотой. Поэтому предельная частота прерываний определяется софтом. И в обычных системах редко бывает выше 1...10KHz. Для потока данных прерывание обычно генерят по окончании пересылки данных посредством контроллера DMA в FPGA. Поэтому ван надо внимательней посмотреть на пример PCIeSGDMA скорее всего прерывания там генерируются внутри контроллера DMA. Удачи! Rob.
  11. Приветствую! КомукакМневотнапримернаоборотприятнеесмотретьнаструктуированныййкод. Удачи! Rob.
  12. Приветствую! Хорошо работать хорошими инструментами особенно когда они условно "бесплатны" Но и чисто в тексте RTL, при некой доли организации и самодисциплине получается отнюдь не медленнее и напряжнее. Но зато гораздо универсальнее. Удачи! Rob.
  13. Приветствую! Приведенный проект пережил несколько версий - с 2017.3 до 2018.3. Удачи! Rob.
  14. Приветствую! Вот это как раз и есть вопросы системного проектирования. Надо четко понимать что куда шлется, каким траффиком, что более критично (полоса или latency) и.т.п. и.т.д. 320/300 тактов latency при пакете в 256 слов это значит latency всего 64/44 такта с учетом latency собственно interconect так и самого DDR контроллера. Вполне нормальная цифра. Но запросы на чтение как и на запись можно слать конвеєром чтобы не терять пропускную. Опять же если требуются работать с блоками данных может выгоднее использовать DMA для пересылки в/из PC. Что бы освежить в памяти посмотрел один из своих старых проектов - KintexUS xcku085-2, DDR4-1600 72 бит - шина данных 512 бит 200 MHz, 6 портов interconnect - 2 отдельных только на чтение и запись по 512 бит, один полный 512 бит, один полный 256 бит к interconnect c PCIe (а также с JTAG мастером, подсистемой MCU,...), и два полных на 128 и 32 бит. И я не помню проблем в этом проекте c interconnect. Если есть слаки нужно в любом случае понимать откуда они вылазят. Може вы так "растягиваете" свою логику по кристаллу что физически interconnect не развести. Может на вход interconnect из вашей логики длинная критика идет. Может еще что ... . Удачи! Rob.
  15. DsПриветствую! Ну тогда либо "костыльное" решение - либо работа через PCIe c помощью DMA - что обычно быстрее чем непосредственный доступ к внутренней памяти. Но это уже больше вопросы системного проектирования. Вы не поняли - поднимать разрядность нужно для ядра interconnect, а не портов. Фактически при этом interconnect добавит на входе AXI width converter и затем сделает коммутацию широкой шины. На каждом порте вы можете поставить любую разрядность и частоту, а также задать разрядность и частоту ядра интерконнекта. То есть можно порт в 256 бит коммутировать ядром 8 бит разрядности, а можно 8 бит порт коммутировать ядром с разрядностью в 1024 бит. Конвертор разрядности это просто FIFO и мне трудно представить что обычное FIFO на 250 MHz создает вам такие проблемы в Kintex US. По разному - от пары до десятка, с разной разрядностью и частотой портов. Удачи! Rob.
  16. Приветствую! Не понимаю почему такой подход "костыльный и не правильный"? Когда это за вас это делает корка PCIe это правильно, а самому сделать так же (или еще лучше) это костыльно и неправильно? Вообще то "оконный" доступ к диапазону адресов это пережиток прошлого. Зачем суетится с переключением страниц когда можно выделить для BAR* пространство в несколько GB для всей внутренней памяти и не парится. Если конечно материнка поддерживает такое выделение А то у меня была уже печальная история с таким выделением. Ну а если очень хочется страницы то вы всегда можете добавить свой AXI mapper модуль с нужным функционалом ("костыльным и неправильным" ). Удачи! Rob.
  17. Приветствую! Как куда? - 512, 1024 бит. У меня несколько систем построенных на Kintex и Kintex US c PCIe Gen3 x8 и несколькими DDR4 контроллерами. И ни на одной не помню таких проблем с обычным interconnect. Ядро interconnect обычно на частоте PCIe 250 MHz. Разрядность ядра выбирается чтобы был запас по общей пропускной полосе. Если получается много портов то не|слабо-связанные порты выделяются в отдельный interconnect. Удачи! Rob.
  18. Приветствую! Простой совет - не разобравшись не ругайте, мне вот наоборот - после перехода с Vivado на Qu тоже иногда выть хочется Много работал с PCIe, Interconnect, DDR, DMA, ... в Vivado. И не могу сказать что там все так плохо. Естественно (как в любой системе) есть свои особенности и их нужно понимать чтобы не было неприятных "сюрпризов". Вы ваш дизайн моделировали в симе? Потому как в симе гораздо легче понять почему что то не так работает. Чаще всего проблемы с interconnect-ом в том что забываешь правильно работать с протоколом AXI. По поводу таймингов с DDR шины - можно/нужно включить/добавить AXI register или FIFO данных на входе/выходе interconnect, но простейший способ упростить себе жизнь это увеличить разрядность шины данных в interconnect ядре с соответствующим понижением частоты шины. Удачи! Rob.
  19. Приветствую! Свой контроллер (или модификация стандартного) делаешь если стандартный не удовлетворяет тебя по каким либо критериям и надо их оптимизировать под свои запросы. Например из моей практики надо было выжать 100% пропускной при записи больших непрерывных блоков данных. Или объединить 2 контроллера в "один" с широкой шиной и жесткой синхронизацией между ними чтобы все refresh и другие внутренние процессы были строго синхронны. А так вопрос слишком общий. Опять же - FIFO для данных обычно не есть часть непосредственно контроллера DDR*, а обычно часть логики user interface между непосредственно контроллером и пользователем. Удачи! Rob.
  20. Приветствую! Vivado хороша тем что позволяет итеративно работать с разными стратегиями. Можно результат работы одной стратегии прогнать через другую. Можно делать P&R дизайна по частям разными стратегиями, можно удалить размещение и разводку только проблемных по времянке цепей и по новой сделать их P&R с дугой стратегией, и.т.д. Ну и делать тайминг анализ чуть ли не после каждого этапа для ранней диагностики проблем. Для сложных проектов это позволяет значительно сократить общее время достижения результата. Удачи! Rob.
  21. Приветствую! Чудеса - Очень хотелось бы увидеть хоть парочку примеров кода когда подобные конструкции не оптимизируется, что бы понять как такие чудеса самому не повторять Удачи! Rob.
  22. Приветствую! Вопрос о неочевидности не стоит - нет разницы будет ли эта неочевидность получатся эта через условие с parameter или чисто руками. Опять же особой разницы нет - крупные изменения логики просто удобнее и нагляднее делать через generate, а для мелких достаточно и просто if(...). Но с точки зрения оптимизации при синтезе разницы нет. Удачи! Rob.
  23. Приветствую! В том то и дело что размер не всегда известен. Размер части полей структур зависит от внешних параметров, которые задаются пользователем при инстанцирование модуля. К тому же таких разных интерфейсов нужно под три десятка и почти все они проходят через разного типа FIFO. Вот и возникла идея упростить жизнь себе ленивому выработав единый шаблон таких интерфейсов. Удачи! Rob.
  24. Приветствую! Спасибо вам и вашему товарищу! Увы, у меня другая комбинация проблем - Modelsim AE и Qu Standard. Qu к сожалению не поддерживает передачу type через parameter. К тому же как оказывается с точки зрения Ms это разные ситуации - когда тип структуры передан как параметр в interface или когда тип структуры определен внутри interface. В первом случае (в коде вашего товарища) действительно функцию можно использовать как константную, во втором (в моем) увы – Ms ругается на не-константность функции. Чертовщина однако какая-то Это и понятно что есть какая-то гонка констант в процессе инициализации сима. Но я с таким еще не сталкивался. Правда давно было что то похожее, связанное с неопределенностью работы константной функций если она использует parameters напрямую в теле функций, а не через аргументы. Но чтобы вот так - присвоенное значения locаlparam было неравно тому что присваивали встретил в первый раз. Удачи! Rob.