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

fsm timing loop

Всем привет!

 

Всегда писал автоматы преимущественно одним блоком процесса, сейчас решил попробовать разделение на синхронный и асинхронный блоки так как в текущей задаче это было бы удобно(небольшая экономия строк кода и повышение читаемости). Да и язык для меня новый.

 

Вот написал конечный автомат:

    (*keep = "true"*)enum logic[5:0] {IDLE, READ_HEADER, READ_CALIB_DATA, STOP} sm_state, sm_state_next;

    always_ff @(posedge clk) begin
        sm_state <= sm_state_next;
    end

    always @(*)begin// специально поставил именно * так как входных сигналов управления fsm предполагается много
          if(rst==1'b1)begin
            sm_state_next <= IDLE;
        end
        else begin
            case (sm_state)
                IDLE : begin
                    sm_state_next <= READ_HEADER;
                end
                READ_HEADER : begin
                        sm_state_next <= READ_CALIB_DATA;
                end
                READ_CALIB_DATA : begin
                            sm_state_next <= STOP;
                end
                STOP : begin
                    
                end
                default: begin
                    sm_state_next <= IDLE;
                end
            endcase
        end
    end

Как я понял - так же предлагают многие учебники(может я не внимателен?).

Проблема в том, что вивадо(17.1) ругается, что там появляется timing loop. Это нормальное поведение? не усложняет ли этот факт ошибки оценку тайминга(при желании можно проигнорировать эту ошибку и насильно развести)

В симуляции работает все корректно.

 

Заранее спасибо!

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ругается из-за кейса STOP:

в нем ничего с переменной не делается, то есть должно сохранятся прошлое значение

либо нужно там написать что-то типа sm_state_next <= хххх, либо сверху написать always_comb (надеюсь вивадо такое примет)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
ругается из-за кейса STOP:

в нем ничего с переменной не делается, то есть должно сохранятся прошлое значение

либо нужно там написать что-то типа sm_state_next <= хххх, либо сверху написать always_comb (надеюсь вивадо такое примет)

добавил

                STOP : begin
                    sm_state_next <= STOP;
                end

не помогло

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У вас автомат попадает в состояние STOP. А дальше куда ?

Поскольку САПР не знает, что дальше делать, он делает так, что автомат будет "крутиться" в этом состоянии. А поскольку логика перехода не определена, получается фиг пойми что. Ну вот вам САПР и выкатил предупреждение ;)

                STOP : begin
                    sm_state_next <= STOP;
                end

не помогло

А вот это уже странно. В VHDL обычно такое описание прокатывает. И у Quartus не вызывает ругани.

Вот только я синхронный сброс описываю в состоянии в блоке

    always_ff @(posedge clk) begin
        sm_state <= sm_state_next;
    end

Примерно так:

    always_ff @(posedge clk) begin
        sm_state <= sm_state_next;
       if(rst==1'b1)begin
            sm_state_next <= IDLE;
        end
    end

Хотя тут я даже не знаю. Может есть какой нюанс в Verilog.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
У вас автомат попадает в состояние STOP. А дальше куда ?

Поскольку САПР не знает, что дальше делать, он делает так, что автомат будет "крутиться" в этом состоянии. А поскольку логика перехода не определена, получается фиг пойми что. Ну вот вам САПР и выкатил предупреждение ;)

 

                STOP : begin
                    sm_state_next <= IDLE;
                end

 

все то же самое =/

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
                STOP : begin
                    sm_state_next <= IDLE;
                end

 

все то же самое =/

Гляньте вот этот документ:

http://www.sunburst-design.com/papers/Cumm...undamentals.pdf

Да и вообще советую почаще заглядывать на этот сайт. Много интересного там: www.sunburst-design.com

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Гляньте вот этот документ:

http://www.sunburst-design.com/papers/Cumm...undamentals.pdf

Да и вообще советую почаще заглядывать на этот сайт. Много интересного там: www.sunburst-design.com

 

Спасибо, гляну, но мне все таки кажется, что дело тут не в алгоритмике, все же это простейший автомат без всякой логики< по идее он должен был завестись...

попробовал ресет как у вас, не помогло =/ может есть галка какая в настройках синтезатора, которая поможет ему это съесть...

 

Собственно 4 страница вашего документа - я не вижу сильных различий за исключением списка чувствительности и типа присвоения

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Выяснил вот что - если создать проект с одним этим файлом, то вивадо не ругается, если же включить его как дочерний модуль< то возникает критикал варнинг

post-80661-1528920852_thumb.png

на картинке тот самый луп(один из) - он есть во всех случаях синтеза< просто когда-то на него ругается вивадо, а когда-то нет... вводит в ступор...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветсвую!

always_ff @(posedge clk) begin

sm_state <= sm_state_next;

end

 

always @(*)begin// специально поставил именно * так как входных сигналов управления fsm предполагается много

sm_state_next <= sm_state;

...

end[/code]

Многие учебники предлагают при таком описании автомата всегда присваивать sm_state_next текущее состояние sm_state в начале комбинаторного блока. Тогда если в case не было смены состояния то автомат остается в текущем состоянии.

Что касается лупа - то надо смотреть как Вы назначаете выходные сигналы в автомате и как они влияют на входные сигналы в этом же автомате через внешнюю логику. Скорее всего у Вас выходной сигнал назначается в комбинаторной части в одном из состояний и он же через внешние цепи требует смены этого состояния. Вот Вам и loop.

 

Удачи! Rob.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Приветсвую!

 

Многие учебники предлагают при таком описании автомата всегда присваивать sm_state_next текущее состояние sm_state в начале комбинаторного блока. Тогда если в case не было смены состояния то автомат остается в текущем состоянии.

Что касается лупа - то надо смотреть как Вы назначаете выходные сигналы в автомате и как они влияют на входные сигналы в этом же автомате через внешнюю логику. Скорее всего у Вас выходной сигнал назначается в комбинаторной части в одном из состояний и он же через внешние цепи требует смены этого состояния. Вот Вам и loop.

 

Удачи! Rob.

 

Спасибо! Учел все вышеперечисленные советы и loopы убрались!

Возьму за правило такой стиль описания

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация