Jump to content

    

Zwerg_nase

Свой
  • Content Count

    223
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Zwerg_nase

  • Rank
    Местный

Контакты

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

Информация

  • Город
    г. Москва
  1. Writing Testbenches using System Verilog, J. Bergeron http://read.pudn.com/downloads149/ebook/643578/Writing testbenches using SystemVerilog.pdf SystemVerilog for Verification, C. Spear
  2. В Libero есть бесплатная Silver license с определёнными ограничениями (не все чипы поддерживаются, нет mixed HDL). Возможно, она вам подойдёт.
  3. С этим я не соглашусь. Во-первых, этот код: не синтезируемый, по крайней мере в FPGA, т.к. , например, Вивада вообще не поддерживает синтез while-loop, а только for-loop (см. https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug901-vivado-synthesis.pdf), а Квартус поддерживает, но только если кол-во итераций задано константой (см. https://www.intel.com/content/www/us/en/programmable/quartushelp/current/index.htm#hdl/vhdl/vhdl_list_support_d1537e1623.htm). А в данном случае (while(ready='0')) кол-во итераций совсем не константа. Я полагаю, что --wait for 60 ns; это закоментированная задержка типа wait for time_expression, потому что только с ней этот код имеет смысл, например в тетстбенче для симуляции.
  4. Я имею в виду ваш код, который вы написали в своём первом комменте:
  5. Из вашего кода не следует, что это синхронная логика, т.к. в нём не описан список чувствительности. А Case может использоваться и в ассинхронной. Согласно вашему описанию, должна быть синтезирована схема, которая, по изменению некоего сигнала из списка чувствительности (например, положительному фронту клока) при выполнении условия ST_CHIP_ERASE_2 должна выполнить два оператора: while ... loop и затем, а не параллельно, if...else. В стандарте IEEE 1076 указано, что внутри when указываются sequential-statement: case-statement –› [ case-label ‘:’ ] case expression is when choices ‘=>’ { sequential-statement } { when choices ‘=>’ { sequential-statement } } end case [ case-label ] ‘;’ Про которые раннее в том же стандарте написано, что "Sequential statements differ from concurrent VHDL statements in that they are executed in the order they are written. Sequential statements include the following types of statements: ... - If, case, loop, next, return statements - Wait statements"
  6. Мне кажется, что while(ready..) и if(del..) внутри when ST_CHIP_ERASE_2 будут выполняться последовательною В результате, проверка del=6 будет сделана только после выхода из loop, а не внутри loop, как в исходном варианте.
  7. У FCOUNTER топ порт RST не используется в архитектуре, потому модуль остаётся в ресете.
  8. У вас, по-моему, в RG написано то же, что и в COMP. Ещё не понятно, почему у SM входы a и b и выход s - однобитовые. По схеме похоже, что должны быть 4-х битовые.
  9. ИМХО, $fwrite / fdisplay не дают возможность вывода чисел со знаком. Я думаю, что проще будет обработать файл в матлабе, чтобы изменить результаты на знаковые. Сложнее, но возможно, будет проверять знаковый бит в самом тестбенче и в зависимости от этого записывать результат со знаком или без.
  10. А я вот вижу: spi_cont_addr <= sspi_cont_addr + '1'; --next address а видимо должно быть: Sspi_cont_addr <= sspi_cont_addr + '1'; --next address
  11. Насколько я понимаю, если холд отрицательный, это значит что следующие данные могут приходить аж на 3,2 нс раньше, чем latch_clock защёлкнет текущие данные. А текущие данные должны приходить не позже чем за 5 нс чем случиться этот же latch_clock, который их и защёлкнет. Т.е. стабильные данные должны держаться не меньше 5-3.2 = 1.8 нс.
  12. Наверно это задержки, чтобы компенсировать слишком маленький data path arival (1,7 нс), чтобы сделать его ближе к 2,3 нс. Скорее всего это какая-то проблема в квартусе. Возможно, они починят её в следующей версии. Я думаю, что это вполне обычная ситуация. Фиттер, плэйсер и рутер в квартусе постоянно оптимизируются и могут значительно отличаться по используемым алгоритмам от версии к версии. Четвёртый циклон довольно давний чип, возможно интел уже не тестирует на нём свой софт начиная с каких-то версий.
  13. Я тоже не разводил клоковые пути вручную. Думаю, что делать это в четвёртом Циклоне как-то уже чересчур) Я бы попробовал включить PLL в Normal Mode. Мне кажется, что Source Syncronous не подходит для center-aligned data.
  14. Я вижу, что принципиальное отличие в значении data_path при расчёте Data Arrival Path для hold: 1.667 (когда slack -0.222) и 2.286 (когда slack +0.398). Это может быть, например, когда в первом случае в проекте задан более скоростной чип.
  15. Я вижу что в sdc у вас клок ssync_rx_clk от внешнего устройства сдвинут на 90 градусов, а latch clock в тайминг репорте другой, видимо от вашей pll на которую приходит ssync_rx_clk . И на этом latch clock набегает задержка 2.676 нс и в этом наверно проблема. Если в pll добавить такой фазовый сдвиг, чтобы компенсировать slack 0.22 нс, то тайминг по hold должен сойтись. Конечно, если у вас есть достаточный slack по setup. Ещё одно соображение по задержке 2.676 на latch clock. Возможно квартус разместил pll из которой выходит latch clock в другом месте, т.е. дальше чем было раньше и поэтому появилась дополнительная задержка. Чтобы это проверить, надо посмотреть задержку latch_clock которая была, когда тайминги выполнялись и проверить, где размещается pll в том и другом случае.