ЛР 6 для ИВТ. Ошибка на рисунке реализации CSR

[BROsandr]

Правильно ли я понимаю, что есть опечатка в методичке, и операнды в выражении нужно поменять, чтобы привести выражение в соотсетствие со схемой

[gr33nka]

Да, все правильно, тут опечатка, должно быть ~WD & RD потому, что на WD приходит значение из регистрового файла rs1, а RD это значение регистра из CSR, всё это нужно для операции

csrrc rd, csr, rs1   # rd = csr, csr = csr & ~rs1

[mrz25]

а зачем демультиплексор по поседжу цлк делать, если слк к нему даже не подведен? Или я чего-то не понимаю в объяснении ниже?

[BROsandr]

Снял метку ответа с поста @gr33nka, чтобы было видно, что в треде есть неотвеченные вопросы.

[HepoH3]

а зачем демультиплексор по поседжу цлк делать, если слк к нему даже не подведен? Или я чего-то не понимаю в объяснении ниже?

Тактовый сигнал подведен к регистрам, в которые демультиплексируется сигнал. Сам демультиплексор — схема комбинационная. Эта схема описывается конструкцией case. Однако поскольку сигнал из этой схемы пойдет на входы регистры, используется always @(posedge clk).
Иначе реализацию можно было бы сделать следующим образом:

reg mie_wire, mtvec_wire, mepc_wire; // сигналы будут проводами не смотря на тип reg
always @(*) begin
 case(ctrl_sig)
   `number : mie_wire = `smthng;
   `number2: mtvec_wire = `smthng2;
...
 endcase
end

always @(posedge clk) begin
 mie <= mie_wire
 mtvec <= mtvec_wire;
...
end

Но для упрощения используется синтаксический сахар, два always сливаются в один и в результате получается тоже самое.

[HepoH3]

Снял метку ответа с поста @gr33nka, чтобы было видно, что в треде есть неотвеченные вопросы.

Лучше вообще разносить разные вопросы по разным тредам, а на треды вешать метку с названием лабы.

[BROsandr]

MPSU/APS#41 (comment), может, я не нашел, но я не могу ставить теги к тредам.

[BROsandr]

Можете пояснить, в какой набор эти инструкции входят?

image

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

image

, но в самой таблице их нет

image

Ну и не понятно, как обработывать mret, например. Его код, вообще кажется, совпадает с ecall

[gr33nka]

В методичке ошибка. Правильнее говорить не

являются частью базового набора инструкций RV32I

, а

являются стандартным расширением набора инструкция RV32 Zicsr

На набор Zicsr можно посмотреть в документации на странице 131.

Что касается mret, то тут упрощение, оно не противоречит спецификации у нас нет необходимости использовать ecall, поэтому инструкция, закодированная таким образом должна приводить к записи значения из регистра mepc в регистр PC.

[BROsandr]

Но вообще я посмотрел и mret и ecall не одинаковые

[gr33nka]

Да, все верно, они разные, в этом и заключается упрощение – мы не смотрим на старшие 12 бит инструкции, дифференцируя команды ecall, ebreak, или разные return'ы (машинный, юзер, гипер- или супервизора). Для нас все эти команды ведут себя одинаково - mret.

Пожалуй, стоит вставить в методичку корректную инструкцию, чтобы не вызывало вопросов и больше соответствовало стандарту, не могу вспомнить почему решил сделать это допущение.

[mrz25]

да, с Readme.md файлами было бы проще)

[BROsandr]

И еще вопрос. В методичке сказано, что аппаратные прерывания асинхронные. То есть, как я понимаю, они должны прерывать выполнение текущей инструкции и обрабатываться немедленно, но у нас, тк PC вытаскивает новые инструкции по clk, то обработка прерывания( загрузка первой инструкции из обработчика прерывания ) может начаться только после окончания обработки текущей инструкции. И получается, что прерывать мы можем только многотактные инстукции load/store.

[gr33nka]

Под асинхронностью в данном случае понимается, что само событие прерывания никак не синхронизированно с внутренними сигналами процессора, условно клавишу на клавиатуре я наживаю в рандомный момент времени относительно внутреннего CLK процессора. Это может произойти в любой момент. А вот, к примеру, исключение (exception) при делении на ноль произойдет синхронно, потому что оно будет вызвано синхронными действиями самого ядра.
Безусловно, до ядра асинхронный сигнал прерывания приходит уже синхронизированным и его обработка начинается в момент, определенный особенностями реализация конкретного ядра и этот момент синхронизирован по CLK. Но само событие прерывания же асинхронно. Имеется ввиду это, а не то, что прерывание будет "асинхронно обработано".

[BROsandr]

А load/store инструкции нужно прерывать тогда? Или можно подождать, когда они выполнятся, и только после этого загружать инструкции обработчика?

[gr33nka]

Явного требования тут нет, как будет проще, так и реализуй. Главное, чтобы работало правильно и никакие данные во время процесса прерывания и восстановления не были потеряны.

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