Вот я процессор проектирую, в нём будет машина состояний (конечный автомат). Устроен он просто: несколько флип-флопов обозначают конкретное состояние и автомат может переключаться в другие состояния согласно комбинационной логике, зависящей от этих флип-флопов и других факторов. То есть, всё обычно, как я понимаю, именно так их и делают.
И так получается по логике работы процессора, что в каждом состоянии автомата делается много нужных, но не связанных между собой по смыслу вещей. Например, в некоторых стадиях его работы сбрасывается АЛУ чтобы начать считать (АЛУ 4-битый, поэтому чтобы обсчитать слово происходит цикл, который требует предварительной инициализации). При этом в этой же стадии происходит сохранение каких-то данных, полученных на предыдущем состоянии (не связанных с АЛУ). Всё это приводит как запутанности кода и ошибкам.
Вопрос: как такое грамотно организовывать в коде? Как тестировать?
Пока предполагаю (но не уверен) что надо бы сделать несколько параллельных конечных автоматов, у которых будут совпадать значения некоторых состояний. Тогда можно будет по смыслу разбить деятельность по разным модулям.
Надо мыслить на верилоге (или сразу на SystemVerilog, который ещё более универсальный), предоставляющем несколько стандартных подходов программирования, которые все используют - сразу иметь ввиду, что будет общее тактирование, и что будут регистры, которые защёлкивают новое состяние в каждом такте и т.д. При этом всякие процессоры и многоуровневые конвейеры строятся легко и непринуждённо...
Я тут за главного - если что шлите мыло на me собака shaos точка net
Shaos wrote:Надо мыслить на верилоге (или сразу на SystemVerilog, который ещё более универсальный), предоставляющем несколько стандартных подходов программирования, которые все используют - сразу иметь ввиду, что будет общее тактирование, и что будут регистры, которые защёлкивают новое состяние в каждом такте и т.д. При этом всякие процессоры и многоуровневые конвейеры строятся легко и непринуждённо...
У меня нет конвееров, все стадии зависимы между собой. Это одна из причин этой сложности. Пишу на SystemVerilog
С другой стороны, непонятно также как тестировать правильность переходов по состояниям (покрытие). Сейчас есть только общий тест всех команд ну и вскоре подключу уже исполнение бинарников из файлов
Я когда свой RISC-V городил 5 лет назад (с конвейером в 1.5 ступени), то чисто по программистки всё компилировал через Verilator и нахлобучивал на это свой тестовый код, написанный на родимом C++
А "настоящие железячники" прям на том же верилоге (да даже и на VHDL) городят тесты...
Я тут за главного - если что шлите мыло на me собака shaos точка net
Shaos wrote:Я когда свой RISC-V городил 5 лет назад (с конвейером в 1.5 ступени), то чисто по программистки всё компилировал через Verilator и нахлобучивал на это свой тестовый код, написанный на родимом C++
А "настоящие железячники" прям на том же верилоге (да даже и на VHDL) городят тесты...
О, значит я настоящий
Просто не понял как ещё там можно тесты сделать внешние на С++. Делаю "как по книжке" - получается. Кроме beans (накопления заходов) и ещё каких-то мелочей - верилятор этого не умеет
(Код покажу когда полностью заработает)
Last edited by belfegor96 on 02 Mar 2024 15:11, edited 1 time in total.