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

kyb

Участник
  • Постов

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Участник
    Участник
  1. Сохранение проектов в виде текта самое удачное решение; еще бы при выпуске релизов система контроля сама подставляла бы номер версии в удобном для синтеза виде. CVS этого делеать не умеет. Может другие умеют?
  2. А не подскажете до какого года действует этот патент? Информацию о Российском патенте можно посмотреть на www.fips.ru (бесплатно доступен автореферат) нзавание "НЕЙРОПРОЦЕССОР, УСТРОЙСТВО ДЛЯ ВЫЧИСЛЕНИЯ ФУНКЦИЙ НАСЫЩЕНИЯ, ВЫЧИСЛИТЕЛЬНОЕ УСТРОЙСТВО И СУММАТОР" приоритет с мая 1999 года.
  3. Вопрос между прочим. Неужели указанные средства не позволяют пользоваться скриптами? Они как раз самое оно для контроля версий.
  4. :bb-offtopic: Так, ради общего развития ... Интересно, чем вызван интерес к сему творению отечественных мастеров, ведь на архитектуру патент имеется. Проблемы могут быть с использованием ....
  5. А поподробнее сообщения компилятора не приведете? Потому как есть вероятность, что ненравится тип integer, а не список чувствительности. И еще, есть определенные сомнения в том, что адекватно будет ссинтезировано умножение (если вообще будет).
  6. блин или я читать разучился или конец недели ... :smile3046:
  7. to sazh Я решил, что перед тем как задать вопрос лучше найти три своих решения ;) А суть проблемы в следующем. Работать мне приходится только с Xilinx, а раньше у SpartanXL (есть у нас на поддержке система с такой ПЛМ) установка и сброс триггера были асинхронными и совпадали. При синтезе FPGAExpress очень сильно ругался и поэтому для всех триггеров мы заводили глобальный сброс через список чувствительности (как я и нарисовал в примере). Сейчас приходится тащить один их проектов так, чтобы сохранить хоть бы общую совместимость. Да и, честно говоря, момент когда появилась возможность использовать синхронные сброс и установку я пропустил. Поэтому я и выразил в более ранних постах свои взляды на описание сброса триггеров. А с глобальным сбросом идея такова, чтобы сделать общий глобальный сброс, но не выводить его через отдельный контакт наружу. Сброс схемы делать через перепрограммирование или, ну если уж очень надо, вывести GSR через STARTUP (спасибо за указание) наружу. Ну это так, философия.
  8. С синхронным сбросом все понятно. Вопрос снят.
  9. Так ведь я совсем о другом. Отсутствие глобального сброса при описании триггеров может несколько озадачивать синтезаторы, что ведет к явному использованию ресурсов для этого не предназначенных. Ваши примеры могут выглядеть следующим образом module intervala_scl (reset, global_clk, ce, interval); parameter dlitelnost = 4'd14; // больше или равно 1 parameter width = 4; input reset; input global_clk; input ce; // длитеьностью в один такт глобального клока output interval; reg [width-1:0] ct, ct_; reg fdse_enable, fdse_enable_; assign interval = fdse_enable; always @ ( ce or ct) if (ce == 1'b1) ct_ = dlitelnost; else if (fdse_enable == 1'b1) ct_ = ct - 1'b1; always @ (posedge global_clk or posedge reset) if ( reset) ct <= dlitelnost; else ct <= ct_; always @ ( ce or ct ) if (ce == 1'b1) fdse_enable_ = 1'b1; else if (ct == 4'd1) fdse_enable_ = 1'b0; always @ (posedge global_clk or posedge reset) if ( reset) fdse_enable <= что-то начальное; else fdse_enable <= fdse_enable_; endmodule ////////////////////////////////////// module intervala_acl (global_clk, ce, interval, reset); parameter dlitelnost = 4'd14; // больше или 2 (Note Gate Push-Back == OFF) parameter width = 4; input reset; input global_clk; input ce; // длительностью в один такт глобального клока output interval; reg [width-1:0] ct, ct_; reg fd_ce; reg fdpe_enable; assign interval = fdpe_enable; always @ (posedge global_clk or posedge reset) if ( reset) fd_ce <= 0; else fd_ce <= ce; always @ ( fd_ce or ct) if ( fd_ce == 1'b1) ct_ = dlitelnost; else if (fdse_enable == 1'b1) ct_ = ct - 1'b1; always @ (posedge global_clk or posedge reset) if ( reset) ct <= dlitelnost; else ct <= ct_; always @ ( fd_ce or ct ) if (fd_ce == 1'b1) fdse_enable_ = 1'b1; else if (ct == 4'd2) fdse_enable_ = 1'b0; always @ (posedge global_clk or posedge reset) if ( reset) fdse_enable <= что-то начальное; else fdse_enable <= fdse_enable_; endmodule Функционально ничего не изменилось, а reset в данном случае глобальный сброс всей схемы и для его разводки будут использованы специально отведенные для этого трассы. Другое дело что использовать для сброса схемы этот сигнал или повторить программирование - это дело вкуса. Использование явного глобального сброса это скорее дело вкуса, лично для меня такой стиль более прозрачен. А использование совсем асинхронных сигналов в ПЛМ дело совсен неблагодарное, лучше уж синхронизовать на рассыпухе где-то снаружи, чтобы внутри все было хорошее и синхронное.
  10. В принципе, все зависит от конкретной задачи и стиля описания. Синхронный сброс тащит за собой дополнительную комбинационную логику. Кроме того, нет полных гарантий, что системный сброс организованный таким образом будет использовать трассы GSR.
  11. sazh>>> И правильно. что используете синхронный ресет Спорное утверждение.
  12. Если под компилятором понимать средсво синтеза, то синтезироваться эти схемы не будут в силу наличия явных задержек. С точки зрения моделирования поведение описаний должно быть разным. Формально, в первом случае Divider12 принимает значения от 0 до 12, однако 12 существует только в течение задержки присвоения Divider12 = #1 4'b0, так как блокирующее присваивания выполняются сразу, последовательность присваиваний прерывается только явными задержками. Во втором случае значение 12 действует в течение такта FastCLK + задержка на смену значения 1. И еще одно мелкое наблюдение - лучше асинхронный сброс добавлять в список чувствительности блока.
  13. А не проще ли поставить внешнюю пару приема-передачи DVB-ASI (типа cy7c924). И будут 200 мбит/с и последовательная шина и другие вкусности. Или проект уже готов и на плате ничего не изменить?
  14. Совершенно верно. Строки будут рассмотрены по порядку и каждое изменение, вызванное присваиванием, породит новое событие для моделирования. И здесь начинается самое интересное: стандат не гарантирует последовательность извлечения событий из очереди моделирования. Поэтому весьма вероятно запаздание сигнала на такт там, где этого совсем не ждали. Отличие присваиваний с оператором => (неблокирующие) заключается в том, что события порожденные этими операциями рассматриваются в последнюю очередь. В итоге, описание соответствует ожидаемой схеме (подробнее см. пункт 5 стандарта). Я в так наелся последствиями использования в описаниях триггеров оператора `=`, что сейчас всех агитирую использовать только `<=` для триггеров, а `=` для комбинационной логики. :maniac:
  15. Опаньки. С синтезом я погарячился. А вот моделирование действительно может отличаться, ведь никто не гарантирует в каком порядке будут рассмотрены строки с `=`. В разных моделяторах последовательность отличается.
×
×
  • Создать...