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

demon3200

Свой
  • Постов

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Частый гость
    Частый гость
  • День рождения 30.06.1988

Старые поля

  • skype
    Array

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

2 725 просмотров профиля
  1. Да, кстати. Никак нельзя указать какой-нибудь паттерн на генерируемые командой derive_pll_clocks имена? Они действительно получаются длинные и неудобные. Как-то задавался этим вопросом, но так ничего и не нашел, или может плохо или не там искал...
  2. У меня тоже именно так и происходит. Решаешь в первую очередь задачу, но где-то в ПЗУ держишь мысли о том, что есть две разновидности КА. Академические знания - это фундаментальные знания. Как ни крути, мы всегда их используем, даже не подозревая иной раз. Какой бы КА вы не описали, если посмотреть на него внимательно, то можно увидеть, что это есть КА Мура или КА Мили. У меня чаще получается Мили, т.к. стараюсь описывать все одним автоматом. А если посмотреть темплейты, например, в квартусе, то там дается КА Мура. Но мы же в первую очередь решаем задачу, поэтому делаем, кто как привык, кому как удобнее.
  3. Переделал модуль. Теперь счетчик, вынесенный из автомата, описывается в комбинационной части. Да, если так, то писанины стало меньше. С точки зрения реализации же, по-моему, оба счетчика абсолютно одинаковы. Но теперь читается хуже. Счетчик, который в автомате, сразу виден в одном месте. А вот работа второго счетчика не так очевидна. Для этого надо смотреть на сам автомат, а также на логику, которая управляет счетчом. Причем каждый сигнал описывается отдельно. module cnt_test ( //Global input CLK_i , input nRESET_i , //Input input IN_PULSE_i , //Control input ENA_CNT_i , input CLR_CNT_i , //Output of counter output [31:0] OUT_CNT0_o32 , output [31:0] OUT_CNT1_o32 ); reg [31:0] out_cnt0_o32; reg [31:0] out_cnt1_o32; assign OUT_CNT0_o32 = out_cnt0_o32; assign OUT_CNT1_o32 = out_cnt1_o32; reg [7:0] state; //FSM localparam integer sIDLE = 0, sCOUNT = 1, sSTOP = 2; wire cnt_1_en = (state == sCOUNT) & ENA_CNT_i & IN_PULSE_i; wire cnt_1_clr = (state == sSTOP) & CLR_CNT_i; always @(posedge CLK_i or negedge nRESET_i) begin if(~nRESET_i) begin out_cnt0_o32 <= 0; state <= sIDLE; end else begin case(state) sIDLE: begin if(ENA_CNT_i) state <= sCOUNT; end sCOUNT: begin if(ENA_CNT_i) begin if(IN_PULSE_i) begin out_cnt0_o32 <= out_cnt0_o32 + 1'b1; end end else begin state <= sSTOP; end end sSTOP: begin state <= sIDLE; if(CLR_CNT_i) begin out_cnt0_o32 <= 0; end end endcase end end always @(posedge CLK_i or negedge nRESET_i) begin if(~nRESET_i) begin out_cnt1_o32 <= 0; end else begin if(cnt_1_en) out_cnt1_o32 <= out_cnt1_o32 + 1'b1; else if(cnt_1_clr) out_cnt1_o32 <= 0; end end endmodule Если же делать так, чтобы счетчик считал только в одном конкретном состоянии автомата, тогда надо добавлять состояний. В одном счетчик тикает, в другом простаивает. Однако тогда между автоматом и счетчиком будет минимум логики. Особенно при кодировке One-Hot.
  4. Согласен, если через триггеры не пропускать, то, наверное, особой разницы в реализации не будет. Получается, наоборот. Если счетчик внутри автомата - достаточно просто одной строчкой делать инкремент там, где это надо. Если счетчик выносим, то надо выдать сигнал разрешения, а потом его еще снять. Получается 2 и более строк кода на одну только функцию. А еще есть сброс, загрузка...
  5. Ну вот такой теоретический пример module cnt_test ( //Global input CLK_i , input nRESET_i , //Input input IN_PULSE0_i , input IN_PULSE1_i , //Control input ENA_CNT_i , input CLR_CNT_i , //Output of counter output [31:0] OUT_CNT0_o32 , output [31:0] OUT_CNT1_o32 ); reg [31:0] out_cnt0_o32; reg [31:0] out_cnt1_o32; assign OUT_CNT0_o32 = out_cnt0_o32; assign OUT_CNT1_o32 = out_cnt1_o32; reg [7:0] state; //FSM localparam integer sIDLE = 0, sCOUNT = 1, sSTOP = 2; reg cnt_1_en; reg cnt_1_clr; always @(posedge CLK_i or negedge nRESET_i) begin if(~nRESET_i) begin out_cnt0_o32 <= 0; cnt_1_en <= 0; cnt_1_clr <= 0; state <= sIDLE; end else begin case(state) sIDLE: begin cnt_1_clr <= 0; if(ENA_CNT_i) state <= sCOUNT; end sCOUNT: begin if(ENA_CNT_i) begin if(IN_PULSE_i) begin out_cnt0_o32 <= out_cnt0_o32 + 1'b1; cnt_1_en <= 1'b1; end else cnt_1_en <= 0; end else begin cnt_1_en <= 0; state <= sSTOP; end end sSTOP: begin state <= sIDLE; if(CLR_CNT_i) begin out_cnt0_o32 <= 0; cnt_1_clr <= 1'b1; end end endcase end end always @(posedge CLK_i or negedge nRESET_i) begin if(~nRESET_i) begin out_cnt1_o32 <= 0; end else begin if(cnt_1_en) out_cnt1_o32 <= out_cnt1_o32 + 1'b1; else if(cnt_1_clr) out_cnt1_o32 <= 0; end end endmodule Два счетчика. Один работает напрямую из автомата, второй через сигналы разрешения и сброса. Насчет упрощения кода при выносе счетчика из автомата я ошибся - проще не получилось. Для работы встроенного счетчика достаточно всего двух строк. Выносного счетчика - целых 5. Вынос счетчика усложнил код. Плюс на выносной счетчик будет работать с задержкой в один такт. И это надо учитывать там, где критично. Но с точки зрения времянок выносной счетчик выиграет. Как раз за счет промежуточных триггеров на сигналах разрешения/сброса. На практике я это не проверял, это просто рассуждения. Warning from admin:Используйте codebox для оформления длинных блоков кода. Не загромождайте сообщения!
  6. Здесь, наверное, имелось ввиду то, что если вынести счетчик за пределы автомата и управлять им одним сигналом, то в реализации между автоматом и счетчиком путь сигнала разрешения будет более "компактным", чем если считать прямо в автомате. В этом случае между автоматом и счетчиком будет куча дополнительной логики. По таймингам такое решение будет хуже. Сам грешен, делаю счетчики прямо в автоматах. По таймингам обычно проблем с этим нет. Но что-то подсказывает, что первый вариант более правильный. Во-первых, мы упрощаем описание автомата, делая его более читабельным. Во-вторых, даем синтезатору больше свободы для раскладывания по кристаллу остальной части схемы, там где могут быть более чувствительные к задержкам пути.
  7. ADC1dat_min и ADC1dat_max - так это разные дорожки? Мне показалось, что одна и та же, просто рассчитывается мин. и макс. задержка. Если первая цифра - это длина, а Tpd - погонная задержка, тогда не понятно было, как длина одной и той же дорожки может быть разной... Названия сбили с толку.
  8. Простите за любопытство, а что есть эти магические цифры: 15.893, 42.767
  9. Посмотрите репорты, он там должен писать про все файлы проекта, которые были обработаны. Есть ли среди них тот, в который вносили изменения? Попробуйте специально в этом файле сделать ошибку, прочухает, или нет. Вобщем, надо выяснить, видит ли квартус то, что вы правите, или нет
  10. Тогда правильно, должен изменения отрабатывать. А железка как себя ведет?
  11. Почтой Терасик не доставляет, FedEx оказался самым дешевым. Та же история
×
×
  • Создать...