Перейти к содержанию

    

Zwerg_nase

Свой
  • Публикаций

    217
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Zwerg_nase

  • Звание
    Местный

Контакты

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

Информация

  • Город
    г. Москва
  1. У FCOUNTER топ порт RST не используется в архитектуре, потому модуль остаётся в ресете.
  2. У вас, по-моему, в RG написано то же, что и в COMP. Ещё не понятно, почему у SM входы a и b и выход s - однобитовые. По схеме похоже, что должны быть 4-х битовые.
  3. ИМХО, $fwrite / fdisplay не дают возможность вывода чисел со знаком. Я думаю, что проще будет обработать файл в матлабе, чтобы изменить результаты на знаковые. Сложнее, но возможно, будет проверять знаковый бит в самом тестбенче и в зависимости от этого записывать результат со знаком или без.
  4. А я вот вижу: spi_cont_addr <= sspi_cont_addr + '1'; --next address а видимо должно быть: Sspi_cont_addr <= sspi_cont_addr + '1'; --next address
  5. Насколько я понимаю, если холд отрицательный, это значит что следующие данные могут приходить аж на 3,2 нс раньше, чем latch_clock защёлкнет текущие данные. А текущие данные должны приходить не позже чем за 5 нс чем случиться этот же latch_clock, который их и защёлкнет. Т.е. стабильные данные должны держаться не меньше 5-3.2 = 1.8 нс.
  6. Наверно это задержки, чтобы компенсировать слишком маленький data path arival (1,7 нс), чтобы сделать его ближе к 2,3 нс. Скорее всего это какая-то проблема в квартусе. Возможно, они починят её в следующей версии. Я думаю, что это вполне обычная ситуация. Фиттер, плэйсер и рутер в квартусе постоянно оптимизируются и могут значительно отличаться по используемым алгоритмам от версии к версии. Четвёртый циклон довольно давний чип, возможно интел уже не тестирует на нём свой софт начиная с каких-то версий.
  7. Я тоже не разводил клоковые пути вручную. Думаю, что делать это в четвёртом Циклоне как-то уже чересчур) Я бы попробовал включить PLL в Normal Mode. Мне кажется, что Source Syncronous не подходит для center-aligned data.
  8. Я вижу, что принципиальное отличие в значении data_path при расчёте Data Arrival Path для hold: 1.667 (когда slack -0.222) и 2.286 (когда slack +0.398). Это может быть, например, когда в первом случае в проекте задан более скоростной чип.
  9. Я вижу что в 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 в том и другом случае.
  10. Тогда можно убрать `define XILINX из модуля и задавать этот define в скрипте при компиляции. в виваде: "-verilog_define XILINX=1" как я понимаю про это писал RobFPGA.
  11. Можно написать: `define XILINX module foo #( ) (...) fifo fifo_inst `ifdef XILINX ( ... ); `else ( ... ); `endif endmodule
  12. Я бы ещё проверил, какой файл с кодом вашего модуля используется для компиляции. Бывает, что если у вас несколько версий модуля, то Квартус может подхватить старую версию исходника если явно не указать путь к нужной версии.
  13. Я бы убрал led2 <= sum[0]; led1 <= sum[1]; led0 <= sum[2]; из блока always @( ) и написал бы: output led0, output led1, output led2, assign led2 = sum[0], led1 = sum[1], led0 = sum[2];
  14. Цитата(jorikdima @ Sep 1 2017, 19:21) 1. Что делать в самый первый раз? В самом начале после ресета. Получается, что по вышеописанной логике, после спада TXE я должен расчитывать, что у меня на шине фифо данные уже есть с прошлого раза и я должен начать с передачи именно их. Но в самый первый раз их же нету. Мне нужно городить логику, которая позволить отличить самый первый раз от не первого? Да, надо по крайней мере знать, есть ли у вас на шине валидные данные от плис, которые не считал FT600, и если таких данных нет, то надо учитывать задержку на их чтение из плис. Цитата2. Меньшая проблема, но все же. Я расчитываю на использование флага empty от моего локального фифо, чтобы узнать есть непереданные или нету. В этом случае если представить, что я не успел передать только оно слово, то флаг empty стоять уже будет, хотя по факту еще одно слово не передано. Спасибо за ответы. Это конечно сильно зависит от конкретной реализации фифо (какой чип, есть ли доп. выходные регистры, и т.д.), т.е. если вы точно знаете, что empty поднимается, когда вы читаете последнее слово из фифо, и при этом FT600 поднимает TXE_N, то это значит только, что вам надо будет держать это считанное последнее слово на шине данных пока TXE_N не опустится (см. п. 1 выше). Ну и пока empty активно, то из фифо плис не читать.
  15. Цитата(jorikdima @ Sep 1 2017, 18:29) Хорошо, спасибо. Тогда главный вопрос, ради которого и описывал все это. Вот рассмотрим финальную стадию передачи. Предположим, что во время передачи FT600 решил остановить процесс и поднять TXE - имеет право в любой момент. На картинке у меня это происходит на желтом спаде. Проблемя в том, что к этому моменту я уже вычитал данные из моего фифо на красном фронте, в надежде передать их на синем фронте. Но надеждам не суждено сбыться, на синем фронте ФТ600 уже ничего лэтчить не будет. Как быть? Я же не могу назад запихать данные в фифо. Это уже вопрос именно постоения схемы, как фпгашники поступают в таком случае? Получается заранее фт600 не предупреждает о своей беспомощности в приеме данных. У меня сейчас имплементация именно от этого и страдает, при окончании, а точнее временном перерыве передачи данных теряется одно слово, которое из фифо вычитывается, но не передается в ФТ600. Спасибо. Данные прочитанные из плис на красном фронте (назовем их D6) должны остаться на шине данных и ждать, пока FT600 не опустит опять TXE_N. При этом надо перестать читать данные дальше из плис. Например, это можно сделать асинхронно: assign rd_fifo = ! TXE_N; // это без учёта логики которая у вас может управлять rd_fifo в начале передачи; Тогда на синем фронте данные считываться дальше уже не будут. А WR_N нужно задать синхронно: always @(posedge CLK) // без учёта асинхронного ресета и т.д. .... WR_N <= TXE_N; // это без учёта логики которая у вас может управлять WR_N в начале передачи;