Jump to content

    

Vengin

Свой
  • Content Count

    105
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Vengin

  • Rank
    Частый гость

Контакты

  • Сайт
    http://
  • ICQ
    438549118

Информация

  • Город
    Беларусь, г. Минск

Recent Profile Visitors

1245 profile views
  1. Vivado после синтеза/имплемента показывает окошко с опциями типа: Открыть синтезированный/имлементированный дизайн Показать репорты Что-то ещё (точно не помню)… И checkbox: «Запомнить выбранную опцию и больше не показывать это окно» Допустим выбрали опцию «Показать репорты» и запомнили этот выбор (галочку в checkbox). Больше окошко напоминание не показывается. Потом, появилась необходимость изменить на другую опцию (скажем «Открыть синтезированный дизайн»). Т.к. окно больше не показывается, то в нём этого сделать не можем. А где ещё эту настройку поменять? Перерыл GUI менюшки самого Vivado – вроде не нашлось таких опций. Может знает кто, в каких недрах (конфигурационный файл, реестр или ещё где) эти настройки хранятся, чтобы хи можно было бы изменить? Или может есть какие Tcl команды для чтения/изменения этих настроек.
  2. Если примменительно к симуляции в Modelsim, то можно передавать VHDL packages в Verilog/SystemVerilog (с некоторыми ограничениями и конвертацией типов). Называется это всё "Sharing User-Defined Types". Необходимый VHDL package нужно компилить с флагом -mixedsvvh. Пример из user manual:
  3. Понятное дело, что при желании можно соорудить скрипты, которые всё будут причёсывать. Но меня интересовало, можно ли в Vivado изначально убрать это "тасование" (думал может какой простой настрокой можно сделать), чем городить огород. Опять таки для "ревизионности" это было бы полезно. Но судя по всему это невозможно.
  4. Конкретно для одного случая, мне так было бы проще добавлять исходные файлы (и в дальнейшем с ними работать). Т.к. был уже готовый список в тектсовом формате и в нужном порядке.
  5. Ладно, надо сделать перерыв, пока понятнее не становится. Но по крайней мере есть надежда, что раз кому-то это понятно, значит не всё потеряно . Ещё раз, спасибо за разъяснения.
  6. Нет я не прикалываюсь, я недоумеваю. Да, периодически при симуляции начинаешь ломать голову, когда же этот момент синхронизации происходит. И после долгих мучений вроде приходишь к некому консенсусу. Но в данном случае я решительно не понимаю, как абсолютно одинаковые входные данные могут трактоваться по разному. Это у меня в голове пока не укладывается... И как может добавление одного регистра увеличивать задержку на 2 такта?
  7. За точку отсчёта в обоих случаях берётся фронт rd_en (T=585ns). Как это получается, что если FIFO сконфигурировано без выходного регристра, то rd_en защёлкивается при T=585ns (и выход появлятеся через 1 такт на T=595ns), а если сконфигурировано с выходным регистром, то абсолютно тот же rd_en защёлкивается на такт позже T=595ns? Как-то могут одни и те же одинаковые входные сигналы тактироваться в FIFO по разному?
  8. Ну вот, как только кажется, что появилась ясность, и всё начало становиться на свои места, появляются новые затыки. Вот диаграмма чтения Common Clock FIFO 32x1024 Standard, без выходных регистров (т.е. выходная задержка 1 такт): Задержка между rd_en и dout как и ожидается =1 такт. Переконфигурировал FIFO и добавил выходной регистр (Output Registers = Embedded Registers). Ожидается, что задержка выходных данных увеличится на 1 такт, и будет составлять 2 такта (о чём и говорится в Summary на корку "Read latency = 2"). Однако в симуляции поджидает неприятный сюрприз: Как видим значение на выходе dout появляется через 2 такта + 100ps, т.е. 3 такта для синхронной логики. Как же так?
  9. Действительно логично... Благодарю за "разжевывание".
  10. Хм, действительно во 2-ом случае запись в момент T=16300ns, хотя я был уверен что на такт раньше, при T=16100. Пойду разбираться. Но при всё при этом, мне не понятно, почему при чтении из FIFO выходные данные не имеют эту задержку 100ps: Тут значение 0x1B появляется в момент 20300ns. Это для FIFO без выходных регистров. Ведь сама BRAM память синхронна и её выход должен быть с задержкой хотя бы в 1 такт (как это и указано в параметрах).
  11. Я описал лишь один случай, но это применимо абсолютно ко всем выходным статусным сигналам FIFO (в том числе full и empty - они точно также задержаны на 100ps). Так что проблема не исчезает, если просто "закрыть на глаза". Тем более, что описываемый случай касается синхронного FIFO. И ни о каких передачах в другой домен речи не идёт. И ещё я упоминал, что стоит задача читать как можно раньше, чуть позже не вариант.
  12. И всё-таки мне совершенно непонятно как работать с ядром. Вот для примера остановлюсь только на одном случае. Это диаграмма записи из первого сообщения, сгенерированного Vivado тестбенча с "искусственной" задержкой входных сигналов (wr_en, din) "after 50 ns": Насколько я понимаю, задержка между wr_en и data_count будет 1 такт. Т.е. синхронная логика "видит" значение сигнала wr_en на такте клока T=16300ns, а новое значение data_count=0x1 на следующем клоке T=16500ns. А теперь возьмём это ядро, и из Vivado тестбенча с "искусственными" задержками вставим в "реальный" проект. Входные сигналы wr_en, din и прочие контролируются синхронной логикой, и в функциональной симуляции не имеют никаких "искусственных" задержек "after XX ns". Тем не менее, т.к. ядро по прежнему выходные сигналы задерживает на 100ps получается что latency увеличивается. Т.е. получается, что (с точки зрения синхронной логики) задержка между wr_en и data_count будет 2 такта! Т.е. синхронная логика "видит" значение сигнала wr_en на такте клока T=16100ns, а новое значение data_count=0x1 по преженму клоке T=16500ns, т.е. через 2 такта. Обясните пожалуйста, где я не прав, или как это всё понимать.
  13. Звучит логично, надо будет принять на вооружение. Правда не совсем понятно, как, скажем, поступать для Common Clock FIFO с общим сигналом data_count. Ведь в данном случае нет отедльных rd_data_count и wr_data_count для каждого клокового домена, т.к. клок общий. Искусственно создавать такие идентичные сигналы с "прицелом на асинхронное FIFO"? Согласен, для симуляции не важно, на сколько сигнал задержан. Если изменения произошли после фронта клока - то и защёлкиваться они будут на следующем клоке. Т.к. визуально эти 100ps заметить крайне сложно (поначалу я их просто не видел), это и приводит к ощущению, что данные защёлкиваются не на том клоке. Мне например по прежнему не понятно, почему для функциональной модели для задержки сигнала на 1 такт xilinx где-то использует эти 100ps (а где-то вроде полноценный такт).