Jump to content

    

RobFPGA

Свой
  • Content Count

    2475
  • Joined

  • Last visited

Community Reputation

0 Обычный

1 Follower

About RobFPGA

  • Rank
    Гуру

Контакты

  • ICQ
    Array

Recent Profile Visitors

12495 profile views
  1. Приветствую! Можно много чего еще поставить - но получился бы дорогой стандартный девкит. А тут основная задача толкнуть готовые недорогие решения в массы. Чтобы было чем кошечкам по мордочке двери открывать. Удачи! Rob. P.S. Кстати похожий модуль от Trenz на ZU5EV стоит ~1К Euro
  2. Приветствую! Обычно reordering работает с разными банками, то-есть по сути с разными адресами и работает внутри самого контроллера. Обычно при этом в контроллере еще и должна отслеживается такая ситуация с доступом к одному и тому же адресу находящемуся в конвейере контроллера. Но естественно это надо смотреть доки конкретного контроллера. Но опять же - чтобы начать что то читать надо сначала получить прерывание О каких "жирных" FIFO вы говорите? Задержки на пути шины AXI для случая TC на это не влияют - ведь генерировать прерывание он будет только получив последний bresp. Другое дело если генерировать транзакции чтения не дожидаясь окончания или одновременно с записью. Тут даже сложно сказать как арбитраж самой AXI шины сработает. Ну или если цепочка шины AXI заканчивается не в контроллере памяти, а в каком либо меж-шинном bridge в котором неправильно реализовано подтверждение записи. Типа раз сюда данные добрались то и ладно, можно сразу отправлять bresp. Ну тут уж от разработчика все зависит. Удачи! Rob.
  3. Приветствую! Окончанием транзакции записи по шине AXI является прием подтверждения по каналу bresp/bvalid/bready. Это подтверждение генерируется в конечном получателе транзакции, в данном случае в контроллере памяти, и по цепочке шины возвращается в источник транзакции. На сколько помню (давно уже datamover нe пользовал) только получение последнего bresp сигнализирует что вся DMA пересылка окончена. Так что скорее всего когда прерывание сгенерировано данные уже давно лежат в памяти. Но неплохо бы вам это проверить на симе чтобы быть в этом уверенным. Удачи Rob.
  4. Приветствую! Это понятно но по разным соображениям не всегда фирма захочет "светит" доками наружу. Да и текущий пример конвертора SystemRDL -> pdf пока еще очень сырой. Поэтому не хочется делать двойную взгонку по форматированию pdf, а затем еще и правки доков, это же не виски все таки Поэтому пока идет изучение существующих возможностей, различных инструментов и вялотекущие эксперименты с питоном. Удачи! Rob
  5. Приветствую! Ну это было еще не решение а лишь часть его, и отнюдь не экономное. Удачи! Rob.
  6. Приветствую! Получилось что? Удачи! Rob.
  7. Приветствую! Если не получается делить на 6 в процессе счета первого счетчика (как выше предлагали, IMHO самый простой вариант) то деление на 6 можно заменить умножением на К и делением результата (сдвигом) на 2**N. где (2**N)/K=1.33...., К и N выбираются в зависимости от разрядности счетчика для обеспечения нужной точности. А так как К будет константой то разложив на множители умножение можно будет заменить суммой сдвинутых значение вашего счетчика. Удачи! Rob.
  8. Приветствую! Вопрос конечно очень расплывчато поставлен, что значит передать? В этом стандарте вроде как до ~5Gbit/s на линию идет. Если имеется ввиду "передать по проводами" то можно попробовать напрямую через медные кабели для 10G (или что похожее) передавать если сенсор потянет. Удачи! Rob.
  9. Приветствую! Спасибо, но это действительно совсем не то Тут основная идея в том что спецификация регистров иерархически описывается своим языком (ну либо импортом из различных форматов) типа А затем по такому описанию генерируется красивые таблички в доки, .h, .vh, .svh файлы и даже исходники RTL и тестов для автоматической верификации этого RTL. При определенной организации и сноровке получается уменьшения объема писанины и легче вносить изменения. Удачи! Rob.
  10. Приветствую! Озадачили вот меня красивым оформление доков на регистры с прицелом на автоматизацию всех процессов работы с ними. Естественно чтобы значит были opensource и функционал можно расширять. С ходу нарыл 2.5 варианта - один из которых собственно PeakRDL. Сделано на Python, позволяет компилировать описание регистров на SystemRDL и генерировать сорцы для верификации и доки в разных форматах. Увы выход доков есть пока есть лишь в .html и .pdf, а хотелось бы еще и в привычный .doc. Кто набудь имел опыт с этим (или похожим софтом)? Интересно что еще есть похожего? Удачи! Rob.
  11. Приветствую! Правильно все же делать EN длительностью в 1 такт как для источника так и для получателя (с соответствующей задержкой). Так как мультицикл задает ограничение время за которое данные (как выше указал @des00) должны устаканится на входе получателя. Соответственно источник должен гарантировать стабильные данные требуемое число тактов. При этом если EN для получателя будет активным все время (распространения данных) то возможна ситуация возникновения метастабильности получателя, когда изменяющиеся данные на входе попадут на фронт CLK. Понятно что следующим тактом эта метастабильности схлопнется, так как буду защелкнуты стабильные данные, но куда и как распространится последствия этой метастабильности зависит от структуры конкретного дизайна, и о последствиях такого судить сложно. Удачи! Rob.
  12. Приветствую! Приведенный вами код не эквивалентен моему так как делить на значение DIVIDER+1; С таким же успехом можно и в +1 делить ... if (rst || ov) {ov, cnt} <= {1'b0, ~DIVIDER}; else {ov, cnt} <= {ov, cnt} + 1'b1; ... А если уж хочется все и сразу - переменный делитель, точный и минимум логики то тогда надо так ... input [WH-1:0] div; ... logic ov ; logic [WH-1:0] cnt; always_ff @(posedge clk) begin {ov, cnt} <= ( (rst || ov) ? {1'b0, ~div} : {ov, cnt} ) + 1'(rst || ov) + 1'b1; //{ov, cnt} <= ( (rst || ov) ? {1'b0, div} : {ov, cnt} ) - 1'(rst || ov) - 1'b1; end В Vivado (при таком описании делителя) варианты что +1 что с -1 занимают одинаковое число ресурсов - по одному LUT, REG, CARRY на каждый разряд счетчика и ov. Естественно в других синтезаторах и в других архитектурах FPGA все может быть по другому. Удачи! Rob.
  13. Приветствую! Думаю все же это больше регулируется внутренними правилами к оформлению кода в компании. Но тут надо аккуратно смотреть на удобства и недостатки которые такие улучшения могут привнести. Был у меня опыт работы с кодом с похожими константами типа TRUE|FALSE|HI|LO ... вместо 1'b1, 1'b0. Не сказал бы что читаемость и понимание кода были лучше. В результате от такого кодирования примитивов отказались оставив лишь значимые для логики дизайна константы, типа `define BUS_ENABLE 1'b1 some_reg <= `BUS_ENABLE; Для чистого Verilog есть единственный практичный способ для таких определений - include файл с определением нужных констант. Удачи! Rob.
  14. Приветствую! Скорее всего потому то выгоды от этого никакой. Удачи! Rob.
  15. Приветствую! Константные выражения оптимизируются на этапе компиляции. Счетчик вниз выглядит так же как и вверх за исключением константы которая прибавляется. То есть это сумматор и регистр. Если счет идет непрерывно (как для делителя) то в этом случае константа -1 тоже оптимизируется. А вот если требуется управлять (старт/стоп) счетом то в этом случае +1 выгоднее (по ресурсам роутинга) чем -1. Так как в большинстве случаев управление счетом делается через изменение значения константы (0 или +-1) на входах LUT сумматора, а не через порт ena на триггере. Понятное дело подобное "крохоборство" оптимизации имеет смысл если это действительно припекает. Удачи! Rob.