Поскольку блок управления принимает один вход, который является opCode, Jr и другие инструкции типа R передают 000000 блоку управления. Но для Jr RegWrite должен быть равен 0. Как блок управления различает Jr и другие инструкции R-типа, если они имеют одинаковый opCode? Нужно ли передавать код функции в блок управления?
Я работаю над симулятором Mips Datapath. Я реализовал блок управления, используя логическую схему, которую нашел в конспектах лекций по компьютерной архитектуре в университете. Вы можете пока игнорировать AluOp.
this.outputs[0].changeValue(opCode == "000000"); // regdest
this.outputs[1].changeValue(opCode == "000010" || opCode == "000011"); //jump
this.outputs[2].changeValue(opCode == "000100"); //branch
this.outputs[3].changeValue(opCode == "100011"); //memread
this.outputs[4].changeValue(opCode == "100011"); // memtoreg
this.outputs[5].changeValue(
["000000"].includes(opCode)
? "10"
: ["100011", "101011"].includes(opCode)
? "00"
: opCode == "000100"
? "01"
: "11" //X
); //aluop
this.outputs[6].changeValue(opCode == "101011"); //memwrite
this.outputs[7].changeValue(opCode != "000000" && opCode != "000100"); //alusrc
this.outputs[8].changeValue(
!["101011", "000010", "000100"].includes(opCode)
); //regwrite
Вот актуальная версия симулятора: https://saliherdemk.github.io/Mips-Datapath-Simulator/
Искал более сложную, гениальную логику блока управления, но не нашел. Стандартный путь данных необходимо изменить для инструкции JR, но я ничего не нашел внутри блока управления.
Jr datapath выглядит так. Но поскольку opCode один и тот же, он переходит к адресу в регистре rd для всех инструкций типа R. Нужно ли нам передавать код функции в блок управления?
Пожалуйста, смотрите дополнение к моему ответу относительно опубликованной диаграммы.
Инструкция jr
не использует поле rd
.
Таким образом, для этой инструкции в поле rd
должно быть 0
, поэтому, даже если бы RegWrite
было истинным, записывался бы «нулевой регистр». Я считаю, что это относится ко всем инструкциям R-типа, включая умножение/деление, mfhi, mthi и т. д. — поле rd
будет равно 0, когда инструкция не записывает регистр.
Поскольку вы должны иметь возможность обрабатывать (то есть игнорировать) записи в нулевой регистр, как, например, в add $0, $1, $1
, вы можете просто обрабатывать jr
таким же образом, зная, что поле rd
равно нулю.
Вы можете полагаться на это или не делать этого, спросите свою курсовую работу.
Из https://www.cs.cmu.edu/afs/cs/academic/class/15740-f97/public/doc/mips-isa.pdf, A 4.2 Инструкция по кодированию Изображение:
Кодировка слова инструкции показана в графической форме в верхней части описание инструкции. На этом рисунке показаны значения всех постоянных полей и имена опкодов для полей опкодов в верхнем регистре. Он помечает все переменные поля с помощью имена в нижнем регистре, которые используются в описании инструкции. Поля, которые содержат нули, но не названные, являются неиспользуемыми полями, которые должны быть нулевыми. А краткое изложение форматов инструкций и определение терминов, используемых для описания содержание можно найти в Форматах инструкций ЦП на стр. A-174.
В ответ на диаграмму, которая была отредактирована для поддержки jr
:
Вот такая схема! В нем отсутствует традиционная схема для j
и jal
, и, похоже, он заменил мультиплексор Jump
для jr
. На следующей диаграмме показан более традиционно используемый путь данных MIPS, который включает j
и jal
, но не jr
.
ИМХО, они должны были начать со схемы j
/jal
в соответствии с моей рекомендацией, а затем добавить еще один мультиплексор для jr
— но в любом случае, этот последний мультиплексор должен выбирать между jr
и всем остальным, так что, да, ему понадобятся дополнительные обработки работать должным образом — ваша диаграмма эффективно сломана как есть.
Да, возможно, Control
берет лишние биты (т. е. funct
).
Или — и я, вероятно, выбрал бы это — его можно рассматривать как ALU control
, который уже берет эти биты funct
вместе с ALUOp
из Control
(который имеет указание на инструкции R-Type).
У ALUOp
есть способ сказать ALU control
использовать биты funct
(когда ALUOP
=2, он обращается к битам funct
), что необходимо для проверки jr
по сравнению с любым другим R-Type.
На самом деле, действительно нет причин дублировать ALU control
, я бы просто изменил управляющий сигнал JumpReg
, чтобы он исходил от ALU control
, а не напрямую от Control
, который, как вы указываете, не имеет достаточно информации для правильной работы с этой целью. мультиплекс Тем не менее, у ALU control
есть вся информация, необходимая для понимания jr
по сравнению со всем остальным, поэтому я говорю, что JumpReg
должно исходить из этого.
Jr datapath выглядит так. Но поскольку opCode один и тот же, он переходит к адресу в регистре rd для всех инструкций типа R. Нужно ли нам передавать код функции в блок управления?
Он сломан и ему что-то нужно, поэтому я бы заменил JumpReg
на ALU control
вместо Control
. Что касается внутренностей ALU control
, то для этого потребуется добавить в таблицу ALUOp
новую логику, а именно строку и столбец. Новая строка для сопоставления jr
по ALUOp
=2 и funct
=jr
, а также новый столбец для значения управляющего сигнала мультиплексора JumpReg
, например. вывод нуля, если только jr
, то 1. Я также, вероятно, переименую ALU control
в Secondary Control
или что-то еще более общее.
Я посмотрел несколько видео jr datapath, и все они установили regWrite на 0. но я думаю, что это правильно. На этапе кодирования инструкция jr выглядит так: 000000 00001 00000 00000 00000 001000 ($1 = 5). Поэтому он всегда пытается записать в $0. Я попытаюсь реализовать логику X (не важно) для этих узлов. Вероятно, было бы лучше, если бы Regwrite был инструкцией X for JR. Спасибо!
В этой логике управляющий сигнал JR всегда истинен для инструкций типа R. Допустим, мы выполняем команду добавления. Сигнал управления Jr будет верным. Поскольку Jr истинно, он перейдет к адресу, хранящемуся в rs. Но это должно быть перейти на ПК + 4.
Я не знаком с управляющим сигналом jr
(я знаю о сигнале Jump
и Branch
). Вы имеете в виду какую-то конкретную диаграмму пути данных? Если это так, пожалуйста, поделитесь. Большинство из них неполные и/или содержат ошибки. Например, jalr
и jal
фиксируют обратный адрес и записывают его в $ra
, также известном как $31
, но это никогда не отображается.
Я имею в виду JumpReg. Это позволяет перейти к адресу, полученному из регистра. Я отредактировал вопрос и симуляцию.
Это действительно хороший подход! На самом деле, я действительно хочу, чтобы симуляция была такой же похожей, как и всем известный путь данных. Вот почему я добавил в симуляцию дополнительный мультиплексор (см. ссылку выше). Мне любопытно, какое применение в реальном мире. Если я не смогу найти полную диаграмму пути данных, я, вероятно, выберу второй подход. Большое спасибо!
Мне нравится ваша диаграмма с добавленным мультиплексором для обработки как j
, так и jr
. Однако вы добавили новый мультиплексор между логикой мультиплексора Branch
и мультиплексором Jump
. Это означает, что вам нужно одновременно утверждать Jump
и JumpReg
для jr
. Не уверен, что Control
сможет это сделать, даже переставив JumpReg
на ALU Control
.
Лично я, когда вношу дополнения в проект, мне нравится добавлять их в конец логики принятия решения, чтобы все другие/ранее существовавшие логические условия оставались такими, какие они есть, а новое условие было похоже на общее переопределение. новое поведение — или — старое поведение в точности как было, и точка, старое поведение без изменений.
Если вы добавите этот новый мультиплексор после мультиплексора Jump
, он будет находиться под контролем сигнала JumpReg
только от ALU Control
, и не имеет значения, подтвержден ли Jump
или нет, и все же старое поведение будет сохраняться, когда нет JumpReg
/jr
.
В начале я добавил в конец логику принятия решения. Тогда я занимался вокруг, но вы правы. Это должен быть конец проекта или (возможно) можно переключить последние входы мультиплексора. Я позабочусь о них. Также вывод Alu Control — 011 для Jr, который ведет себя как X (реализация: electronics.stackexchange.com/questions/672873/…). Может быть, мне придет в голову идея использовать этот вывод с кодом func. Но у вас вроде проще.
Схема в посте нечеткая, у вас есть ссылка на нее?