Lutovid 1 13 июня, 2018 Опубликовано 13 июня, 2018 · Жалоба Всем привет! Всегда писал автоматы преимущественно одним блоком процесса, сейчас решил попробовать разделение на синхронный и асинхронный блоки так как в текущей задаче это было бы удобно(небольшая экономия строк кода и повышение читаемости). Да и язык для меня новый. Вот написал конечный автомат: (*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. Это нормальное поведение? не усложняет ли этот факт ошибки оценку тайминга(при желании можно проигнорировать эту ошибку и насильно развести) В симуляции работает все корректно. Заранее спасибо! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 13 июня, 2018 Опубликовано 13 июня, 2018 · Жалоба ругается из-за кейса STOP: в нем ничего с переменной не делается, то есть должно сохранятся прошлое значение либо нужно там написать что-то типа sm_state_next <= хххх, либо сверху написать always_comb (надеюсь вивадо такое примет) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Lutovid 1 13 июня, 2018 Опубликовано 13 июня, 2018 · Жалоба ругается из-за кейса STOP: в нем ничего с переменной не делается, то есть должно сохранятся прошлое значение либо нужно там написать что-то типа sm_state_next <= хххх, либо сверху написать always_comb (надеюсь вивадо такое примет) добавил STOP : begin sm_state_next <= STOP; end не помогло Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 13 июня, 2018 Опубликовано 13 июня, 2018 · Жалоба У вас автомат попадает в состояние 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. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Lutovid 1 13 июня, 2018 Опубликовано 13 июня, 2018 · Жалоба У вас автомат попадает в состояние STOP. А дальше куда ? Поскольку САПР не знает, что дальше делать, он делает так, что автомат будет "крутиться" в этом состоянии. А поскольку логика перехода не определена, получается фиг пойми что. Ну вот вам САПР и выкатил предупреждение ;) STOP : begin sm_state_next <= IDLE; end все то же самое =/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 13 июня, 2018 Опубликовано 13 июня, 2018 · Жалоба STOP : begin sm_state_next <= IDLE; end все то же самое =/ Гляньте вот этот документ: http://www.sunburst-design.com/papers/Cumm...undamentals.pdf Да и вообще советую почаще заглядывать на этот сайт. Много интересного там: www.sunburst-design.com Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Lutovid 1 13 июня, 2018 Опубликовано 13 июня, 2018 · Жалоба Гляньте вот этот документ: http://www.sunburst-design.com/papers/Cumm...undamentals.pdf Да и вообще советую почаще заглядывать на этот сайт. Много интересного там: www.sunburst-design.com Спасибо, гляну, но мне все таки кажется, что дело тут не в алгоритмике, все же это простейший автомат без всякой логики< по идее он должен был завестись... попробовал ресет как у вас, не помогло =/ может есть галка какая в настройках синтезатора, которая поможет ему это съесть... Собственно 4 страница вашего документа - я не вижу сильных различий за исключением списка чувствительности и типа присвоения Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Lutovid 1 13 июня, 2018 Опубликовано 13 июня, 2018 · Жалоба Выяснил вот что - если создать проект с одним этим файлом, то вивадо не ругается, если же включить его как дочерний модуль< то возникает критикал варнинг на картинке тот самый луп(один из) - он есть во всех случаях синтеза< просто когда-то на него ругается вивадо, а когда-то нет... вводит в ступор... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 33 13 июня, 2018 Опубликовано 13 июня, 2018 · Жалоба Приветсвую! 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. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Lutovid 1 13 июня, 2018 Опубликовано 13 июня, 2018 · Жалоба Приветсвую! Многие учебники предлагают при таком описании автомата всегда присваивать sm_state_next текущее состояние sm_state в начале комбинаторного блока. Тогда если в case не было смены состояния то автомат остается в текущем состоянии. Что касается лупа - то надо смотреть как Вы назначаете выходные сигналы в автомате и как они влияют на входные сигналы в этом же автомате через внешнюю логику. Скорее всего у Вас выходной сигнал назначается в комбинаторной части в одном из состояний и он же через внешние цепи требует смены этого состояния. Вот Вам и loop. Удачи! Rob. Спасибо! Учел все вышеперечисленные советы и loopы убрались! Возьму за правило такой стиль описания Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться