Jump to content

    

nice_vladi

Свой
  • Content Count

    280
  • Joined

  • Last visited

Community Reputation

0 Обычный

1 Follower

About nice_vladi

  • Rank
    Местный

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

3022 profile views
  1. +++ Пока дизайн не очень большой и сложный, я бы перетряхнул всё с чистого листа. Изначально задавшись ограничениями: - на передельную частоту: скажем, 200 МГц, хотя и это для циклона5 не сильно комфортно - на концепцию использования тактовой частоты: только положительный фронт, одна тактовая в проекте, в случае необходимости понижения - использовать clock enable Ну и как следует отсимулять всё это. Тогда соблюдайте парадигму: для 200 все сигналы формируйте на 200, для 100 - все сигналы на 100. Нужно понимать, как он соотносится с остальными сигналами в дизайне. Да и слепо верить TQ не стоит. Он показывает только то, о чем вы просите. Где-то у @des00 были годные статьи на эту тему. Зацепился взглядом за то, что вы входной сигнал (с пина) протащили через логику и только потом щелкнули в регистр. С учетом того, что у вас 100+ МГц в дизайне, я бы не стал так делать. Он есть, просто был очень глубоко в списке слаков. По умолчанию TQ показывает только первые 200 худших путей. ЗЫ. Либо, если "и так сойдёт" и не нужно будет всё это развивать и поддерживать, просто забить на все предупреждения TQ. Мб и не имеет смысл тратить время на перетряхивание проекта о котором больше вы никогда не вспомните...
  2. Тоже решил заглянуть, проходя мимо. Развернул проект - не нашел слаков, связанных со счетчиками. Только куча addr_mem_b[...], связанных с разными тактовыми доменами и т.д. А зачем на 200МГц по отрицательному фронту какие-то данные перекладывать? Там такая анархия творится... Мне кажется, дело не столько в счетчиках, сколько в этом. Перейдите в единый тактовый домен, уберите работу по заднему фронту тактовой. ЗЫ. Во всех RAM на порт А подана тактовая 100 МГц, а addr_mem_b защёлкивается на 200 МГц. mem0: RAM2P PORT map ( address_a => addr_mem_b, address_b => adr_b, --BUS clock_a => clk100_s, clock_b => nlk200_s,--clk200_s, --clk200_s, --BUS data_a => DATAspi_b, data_b => dat_b, --BUS wren_a => wsw0_s, wren_b => ww0_s, --BUS q_a => rim0_b, q_b => bus0_bus --BUS ); ... ... aaa: process (clk200_s) begin if clk200_s'event and clk200_s = '0' then addr_mem20t_b <= addr_mem200_b;--тут конвейер по адресу addr_mem2tt_b <= addr_mem20t_b; addr_mem_b <= addr_mem2tt_b; end if; end process aaa; Тоже самое с "address_b => adr_b, --BUS". Входной сигнал через комбинаторику засовывается в порты RAM на 200 МГц. Тоже самое с сигналом wt_s - формируется на 200 МГц, используется для записи в порт RAM, работающий на 100 МГц
  3. А на картинке импульса с конденсатора какая цена деления по оси Х? Объясню: тоже видел спектрометр на детекторе мощности. Примерно такая же схема, немного больше рассыпухи. Так вот, в нём импульс приходил на АЦП с частотой 1 МГц. И из-за маленькой длины импульса АЦП не всегда "попадало" на импульс. Период тактовой АЦП 1/1е6 = 1 мкс. Если пик импульса, приходящего на АЦП короче периода тактовой АЦП, то АЦП просто физически не может его всегда правильно оцифровывать, оно не видит пик. В вашем случае, для тактовой АЦП 500 кГц (худший случай) длина импульса должна быть не менее 2 мкс.
  4. Здравствуйте, Если аналоговый тракт в порядке - надо грешить на цифру. Осциллограмы импульса - это входной импульс? Или тот, который уже на входе АЦП? Какая тактовая у АЦП?
  5. Уже не первую вакансию вижу, где одновременно с требованием опыта работы 3+ лет предъявляют требования к оценкам в дипломе. Всегда думал, что при наличии релевантного опыта работы по специальности в диплом универа вообще никто никогда не смотрит. Это прям требование работодателя? Либо какая-то формальность от вашей фирмы?
  6. Сначала всё в одном модуле лепил. Потом начал выносить в отдельные таски. Последний этап до UVM - собрал некоторое подобие UVM. С внешними классами, интерфейсами и т.д. Посмотрел внимательно, понял, что изобретаю велосипед, и решил попробовать UVM. Пока решил следующим образом. В тесте: for (int i = 0; i < pN_PORTS; i++) begin eth_seq[i] = eth_sequence::type_id::create($sformatf("eth_seq[%0d]", i)); eth_seq[i].randomize(); eth_seq[i].dmac = pMAC_DST[i]; end ... eth_seq[i].start(m_env.m_agent[idx].m_sqr); ... В sequence: virtual task body(); frame_h = eth_frame_broad::type_id::create("frame_h"); start_item(frame_h); assert(frame_h.randomize()); frame_h.set_dmac(dmac); finish_item(frame_h); endtask : body И внутри самого uvm_sequnce_item: function set_dmac (bit [47:0] mac); this.dmac = mac; this.fcs_upd(); endfunction : set_dmac На мой взгляд, достаточно коряво. Но, в целом, приемлемо. Все изменения будут сделаны в высокоуровневых файлах тестов, в глубь лезть не надо. В мануалах не нашел ничего интереснее. uvm_config_db более громоздко и менее производительно (основываясь на рекомендациях из док).
  7. Я буквально недавно начал серьезно погружаться. После того, как разрабатываемое тестовое окружение выросло до неприличных размеров и стало не управляемо и не масштабируемо. Здесь, конечно, есть проблема и кривых рук. Но отлаживать и, самое главное, верифицировать Н-портовый Ethernet коммутатор стало почти физически больно. От UVM ожидаю получить более-менее структурированное окружение, облегчение описания и проведения наборов тестов, упрощение работы с недетерминированным порядком передачи и задержками в данных. Плюс встроенные инструменты подсчета ошибок, репортов и т.д. Насколько это всё спасёт и упростит верификацию - пока не знаю, время покажет.
  8. Всем здравствуйте, Разбираюсь с UVM. В какой-то момент перешел к "боевому" проекту. Задача следующая: Нужно передать в GMII порт(-ы) набор Ethernet пакетов. В каждом пакете существуют поля mac destination и mac source. Поле mac source допускается задавать статично на этапе сборки, с этим проблем нет. Я хочу динамически менять поле mac destination. На текущем этапе в классе uvm_sequence_item я состряпал функцию set_dmac (bit [47:0] mac). Не уверен, что это правильный способ. Да и не слишком удобно - приходится вызывать эту функцию в uvm_sequence, куда, в свою очередь, опять нужно динамически передавать нужный MAC адрес. Собственно, вопрос: как, с точки зрения UVM, правильно изменять значения в uvm_sequence во время runtime? ЗЫ. Открыл для себя `uvm_do_with, поэтому часть вопроса снимается) ЗЗЫ. Пока писал, немного посветлело в голове. Пришел к выводу, что под каждый порт должны создаваться несколько sequence со статичными MAC source. И уже в них передавать MAC destination. Выглядит логично, хотя и очень громоздко
  9. Цели и задачи всегда важны. Смотрите: Хотите ускорители на ПЛИС реализовать? Тогда hdl/hls. Хотите на видеокартах считать? Тогда python/C + CUDA и иже с ними. Хотите на серверах что-то делать? Там python массово распространён. В общем, на чем хотите - на том и пишите. Хоть на Deplhi, никто же не ограничивает. Сделать-то что надо?)
  10. Слышал, их даже на *HDL пишут. Все зависит от целей.
  11. Тоже руками крутил delay в IO портах. И тоже *иногда* собиралось так, что паттерн передавался без ошибок. После кучи убитого времени пришел к тому, что всё это самообман, и "рабочие" сборки - просто удачно разложенные регистры, чисто случайно. Но, может быть, у вас получится чего-то добиться. Будет интересно прочесть про рабочий вариант. ЗЫ. А тестовый паттерн сколько времени проверяли? Сколько бит тестового паттерна принимается подряд без ошибок? 10^5? 10^9?
  12. Встречался с подобной проблемой - сигналы были заведены на низкоскоростные ноги ПЛИС, и все танцы с бубном вокруг констрейнов ни к чему не приводили. Поэтому сначала надо посмотреть, на какие ноги заведены сигналы. Кстати, а тестовый паттерн верно принимается? Нет ошибок?
  13. Есть неплохая статейка от ребят fpga-systems.ru: https://fpga-systems.ru/publ/jazyki/systemverilog/uvm_test_tablicy_sin_cos/13-1-0-120 Там на пальцах создание tb + UVM как раз для вивадовского симулятора, мб что-то почерпнете оттуда. В конце есть ссылка на репозиторий, можно качнуть и запустить. У меня на Vivado 2020.1 проект запустился сразу, без проблем.
  14. В генераторе IP ядра на последней вкладке можно поставить галочку, которая отвечает за генерацию .bsf/.bdf файла, который и будет блоком-символом