Заметки учащегося: неоднозначные моменты

[tedichol]

Здравствуйте!
Сейчас изучаю этот курс, в процессе накопилось некоторое количество предложений о правках, которые сделали ли бы текст немного чище и точнее, на мой взгляд.
Чтобы вам ознакомиться с ними, прикрепляю ниже ссылку на онлайн-документ, в нем собраны мои находки разной степени важности. Можете их удалять(предоставил права на редактирование) по мере внесения изменений или просто, если считаете их не существенными или некорректными, так как я где-то ошибся.
По мере прочтения/выполнения новые находки я тоже думаю добавлять в документ.

Ссылка: https://disk.yandex.ru/i/XdnZNQK7bPSuNA

[HepoH3]

Добрый день!
В первую очередь, большое спасибо за то что так подробно все задокументировали, я пока по диагонали пробежал по вашим примечаниям и почти все можно исправить сразу без каких-либо вопросов! Мне понадобится некоторое время, чтобы все перепроверить, исправить в репозитории и отметить к исправлению в будущем издании, постараюсь в течение недели все отработать.

[tedichol]

Понял, хорошо, я совсем не тороплю с исправлениями, как будет удобно, но еще такой вопрос: это обсуждение будет закрыто, когда изменения будут внесены вместе с новым коммитом, или нет? Просто какое-то время я буду продолжать чтение и выполнение, фиксируя новые места находок, если понадобится. Не считаю нужным писать комментарии здесь и issue по каждому поводу до того момента, пока не накопится еще достаточного количества предложений о правках или я не закончу изучение. Или что будет уместнее, на ваш взгляд? В данный момент закончил 2-ую ЛР.

[HepoH3]

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

[tedichol]

Хорошо, вас понял, но вам нет необходимости проверять, я напишу здесь еще, когда, как мне кажется, придет момент привлечь ваше внимание.

[HepoH3]

Я правильно понял, что на каждую лабораторную нужно будет создавать отдельный проект Vivado? Я пошел именно по этому пути. Возможно, было бы полезно маленькое уточнение, хотя может быть я где-то его и пропустил.

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

---

Касательно ссылок — мне известна эта проблема, но я пока не знаю как подступиться к её решению. Судя по всему, вы читаете курс со страницы https://mpsu.github.io/APS. В этом представлении ссылки на разделы чувствительны к регистру (иными словами, ссылка Labs/02%20ALU#задание будет работать только если в документе будет раздел "задание" именно с маленькой буквы). При этом, если читать материалы со страницы самого репозитория, чувствительности к регистру нет. Эта проблема вскрылась на довольно поздних этапах написания курса и я пока не нашел в себе силы исправить все такие ссылки).

---

Помимо прочего я хотел бы ещё раз выразить свою признательность за такой обширный фидбэк и предложить отправить вам экземпляр печатного издания в качестве благодарности. Если вас это заинтересует, мне потребуется ваш почтовый адрес и ФИО (их можно прислать на почту hepoh3@gmail.com).

[tedichol]

1. Понял, спасибо за уточнение.

---

2. да, я читаю с https://mpsu.github.io/APS , то есть такие уточнения нерелевантны и не упоминать их?

---

3. Огромное спасибо за такое предложение! Очень ценю ваше отношение и саму возможность изучить данный курс посредством github, но все-таки возьму паузу подумать над этим, если только в печатном варианте нет какого-то секретного раздела😄 или существенных отличий.

[HepoH3]

2. — да, в этом нет смысла, я с помощью регулярных выражений смогу найти такие места быстрее чем вы будете их фиксировать.
3. Нет проблем, секретного раздела в печатной версии никакого нет. Если вдруг решитесь, дайте знать)

[HepoH3]

вопрос по "теории памяти": корректно ли сравнивать распределенную память, которая реализуется через лут, с регистровой, если одна может менять свое значение в процессе работы(это я про DFF), а вторая - нет(это я про LUT), так как определяется на этапе прошивки/конфигурирования плис перед работой?

Распределенная память тоже может менять свое значение в процессе работы, для этого логика ПЛИС, которая используется для программирования памяти на этапе конфигурации переопределяется таким образом, чтобы она работала и в процессе работы дизайна.

как реализуется многопортовая память на DFF, если входы a,b,c идут через LUT(что в нем записывается тогда), а потом еще и через несколько настраиваемых мультиплексоров?

Можно просто сконфигурировать логический блок таким образом, чтобы он выполнял только роль 1-битной ячейки памяти (подробней о комбинациях функционала ЛБ)

Затем, собрав набор таких ячеек, добавим поверх них логику мультиплексирования адресов для записи, и демультиплексирования адресов для чтения:

[HepoH3]

51. Раздел 8 "Лабораторная №3. Регистровый файл и внешняя память. Задание по реализации памяти. 1. Память инструкций": если есть побайтовая адресация, которая использует 9 бит(с 10 по 2), а процессор RISC-V умеет в побайтовую адресацию, то не будет ли реальная разрядность его адреса памяти меньше, чем 2^32, и на самом деле равняться 2^(32-n), так как мы отбрасываем n=2 младших бита, в данном случае. И хоть нами и используются 9 бит адреса для обычной 32-битной адресации, на самом деле будут использованы 11 для обеспечения побайтовой адресации в реальном процессоре. Или я что-то упускаю в этих рассуждениях?

Сложный для восприятия вопрос, попробую объяснить то как его понял.

В задании предлагается реализовать память с 512-ю 32-битными ячейками. Для того чтобы индексироваться по такому массиву 32-битных ячеек, требуется 9 бит (т.к. 2^9=512). Но 512-ть 32-битных ячеек занимают 512*4=2048 байт, поэтому для байтовой адресации нам необходимо уже 11 бит. Процессор обязан использовать именно такие байтовые адреса. Допустим процессор хочет обратиться к 5-му байту. Этот байт будет находиться в 1-й ячейке памяти (счёт ведется с нуля, в 0-ой ячейке хранятся 0-3 байты, в первой ячейке: 4-7). Получается, чтобы понять, к какой ячейке памяти нам нужно обратиться, мы должны разделить пришедший от процессора адрес на 4.

Спецификация RISC-V использует байтовую адресацию, 32-битный RISC-V процессор использует 32-битный адрес для указания любого из 2^32 байт (не 32-битных ячеек) памяти.

[tedichol]

Да, хорошо, я понимаю написанные разъяснения. Этот вопрос скорее был вызван тем, что в моем (не)понимании индексация, в основном, производилась(-тся) по машинным словам(в данном случае, 32-битным), а не байтам. Соответственно, когда я услышал про побайтовую, у меня сложилось мнение, что есть 2 вида индексации адресного пространства, которые используются одновременно что ли. После чего появилось это рассуждение про то, что нам, на самом деле, требуется 11 бит для побайтовой адресации, а, в общем случае, для адресации 2^32 32-битных кусочков памяти побайтово нам бы уже не хватало 32 бит и понадобилось бы 34 бита.
Что ж, как говорится, все уже придумано до нас.

[HepoH3]

кстати страница 15, на которую дана ссылка во фрагменте:

Дело в том, что в этом документе используется "своеобразная" нумерация страниц:

Страницы оглавления нумеруются римскими цифрами (стр. i-xix). После оглавления идут страницы, нумерующиеся арабскими цифрами. PDF поддерживает такие нумерации (т.е. можно перейти на страницу "X" и на страницу "10" и это будут разные страницы). Но видимо ваш просмотрщик такой функционал не тянет и просто перенумеровал все страницы. Вас интересует та страница, которая обозначена номером 15 в колонтитуле:

[tedichol]

Добрый день, выполнял 4-ую лабораторную работу, запустил симуляцию, добавил внутренние сигналы инстанцированного модуля CYBERcobra (DUT), но они не отображаются, в чем может быть проблема? У меня Vivado 2022.1

Программа работает(увеличивается значение регистра 1, которое выводится через OUT, до того момента, пока он не сравняется со значением, пришедшим в sw_i )

[HepoH3]

Если добавлять сигналы на времянку после старта симуляции, они начинают логироваться с момента добавления (т.е. есть продолжить симуляцию, они будут отрисовываться дальше, но все что было во времени до их добавления так и останется пустым). Поэтому после добавления сигналов нужно выполнить сброс симуляции, и повторный ее запуск (последовательно нажать кнопки 1 и 2):

(подробней об этом говорится тут).

[tedichol]

Да, вспомнил, спасибо!

[HepoH3]

зачем процессору побайтовая адресация, если память инструкций хранит данные в 32-битном виде и сам процессор обрабатывает информацию по 32 бита(инструкция + данные к ней)?

Я сперва начну издалека, а потом перейду к памяти инструкций.
Спецификация RISC-V (а мы стараемся делать процессор максимально удовлетворяющим спецификации), равно как и все другие современные архитектуры используют побайтовую адресацию по нескольким причинам.
Во-первых, так проще работать с данными. К примеру, архитектура RISC-V — это Load and Store архитектура, т.к. для того чтобы обработать какие-то данные из основной памяти, их сперва необходимо загрузить в регистровый файл, выполнить обработку и потом записать обратно в память. Т.е. RISC-V "заточена" под то что процессору придется постоянно гонять данные между памятью и регистровым файлом. Для этого используется 5 инструкций:

• lw — загрузка слова,
• lh — загрузка полуслова, интерпретируемого как знаковое число,
• lhu — загрузка слова, интерпретируемого как беззнаковое число,
• lb — загрузка байта, интерпретируемого как знаковое число,
• lbu — загрузка байта, интерпретируемого как беззнаковое число,
• sw — загрузка слова,
• sh — сохранение полуслова,
• sb — сохранение байта.

Поскольку мы используем кучу инструкций доступа к памяти с разными объемами данных, при вычислении адреса будет куда проще, если мы будем представлять память как массив байт, нежели чем массив другой гранулярности (например 32-битных слов). В этом случае достаточно указать адрес начального байта загружаемой единицы (байта/слова/полуслова) и указать какую порцию данных мы хотим получить. Если бы была пословная адресация, в случае инструкции lb приходилось бы считать, в каком слове памяти находится искомый байт (делить нацело адрес на 4).

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

Возвращаясь к памяти инструкций. Во-первых, хоть в нашем процессоре инструкции и будут только 32-битные, спецификация RISC-V поддерживает расширение в виде набора сжатых инструкций, где каждая инструкция занимает только 16-бит.
Во-вторых, хоть в нашем процессоре используется гарвардская архитектура, где память инструкций и память данных являются физически разными блоками процессора, в реальных системах память инструкций и память данных обычно находятся в одном блоке памяти, а значит, процессорной системе будет куда проще, если она будет работать с инструкциями по таким же правилам, как и с данными (видеть память в виде массива байт).

[tedichol]

Хорошо, с пояснением, что мы можем загружать разные порции данных(байт/полуслово/слово) стало понятнее, для какой цели требуется побайтовая адресация, но тогда такой вопрос: если посмотреть на формат кодирования инструкций, становится немного непонятно, зачем может понадобиться загружать байт и полуслово(при длине инструкции в 32 бита), ведь это нарушает целостность инструкции или данных в ней(т.к. константы длиннее байта, а opcode или другие служебные поля короче него)? В итоге при выполнении мы получаем некие данные(набор битов), которые представляют собой либо часть нужных + сторонний довесок, либо обрезанное значение не вмещающегося значения.

И еще: я понимаю различия гарвардской и принстонской архитектуры в общих чертах. Но все-таки видимо не понимаю достаточно на уровне реализации хранения программ. Пояснение для иллюстрации: в фон-неймановской архитектуре инструкции и данные хранятся в едином месте, то есть (использован оператор повторения SystemVerilog) {N {32-битная инструкция} } {N {32-битные данные} } или в перемешку {N {32-битная инструкция} {32-битные данные} }, в гарвардской они соответственно разделены на физические разные области памяти инструкций {N {32-битная инструкция} } и памяти данных {N {32-битные данные} } . Они организованы подобным образом или нет? Нигде в интернете не хватает примеров на уровне нулей и единиц для иллюстрации хранения одной и той же программы, всё про шины, да преимущества и недостатки, хотя возможно я не искал достаточно долго и упорно.

Ладно, пока я это все формулировал, то немного преисполнился, видимо, и могу предположить, что для извлечения инструкций из общей памяти или памяти инструкций, в частности, не используются операции с полусловами и байтами. Они находят свое применение только для извлечения данных. (После написания этого фрагмента я задумался, а откуда мы узнаем адрес данных, которые нужны для выполнения инструкций? через передачу в константах immediate? потому что в самих инструкциях мы указываем только порядковые номера регистров)

Надеюсь, не слишком утомляю такими километровыми вопросами)

[HepoH3]

для какой цели требуется побайтовая адресация, но тогда такой вопрос: если посмотреть на формат кодирования инструкций, становится немного непонятно, зачем может понадобиться загружать байт и полуслово(при длине инструкции в 32 бита), ведь это нарушает целостность инструкции или данных в ней(т.к. константы длиннее байта, а opcode или другие служебные поля короче него)? В итоге при выполнении мы получаем некие данные(набор битов), которые представляют собой либо часть нужных + сторонний довесок, либо обрезанное значение не вмещающегося значения.

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

Принстонская (фоннеймоновская) архитектура: память инструкций и память данных расположены физически в одном блоке процессора и делят общее адресное пространство. Возвращаясь к картинке из той презентации:
диапазон адресов памяти 0x68FF-E5FF относятся к области, где хранятся инструкции, а диапазон 0x08FF-0x68FF относится к памяти данных. Но этот диапазон условный. Просто мы так договорились, и программа будет компилироваться из рассчета на эту договоренность. Процессор при желании может сделать загрузку слова из диапазона адресов инструкций, и получит инструкцию (хранящуюся в памяти как некоторое число), которую он может интерпретировать как данные.

В гарвардской архитектуре память инструкций и данных разделены, у них разное адресное пространство и нельзя считать инструкцию операцией load, просто указав адрес инструкций.

Пример:

Это гарвардская архитектура. У процессора есть два интерфейса:

1. Интерфейс памяти данных
2. Интерфейс памяти инструкций
   Даже если процессор захочет считать инструкцию в регистровый файл (интерпретируя как какие-то данные), он не сможет это сделать. Даже если он выставит какой-то адрес, где как он считает есть нужная инструкция, этот адрес пойдет через блок LSU в Data Memory, пути до Instr Mem у него нет.

В принстонской же архитектуре был бы единый блок памяти Instr/Data Mem и процессор, выставив правильный адрес мог бы считать инструкцию в регистровый файл.

[HepoH3]

а откуда мы узнаем адрес данных, которые нужны для выполнения инструкций

В инструкциях load/store используется так называемая "косвенно-регистровая адресация со смещением". Звучит очень сложно, но это означает лишь то, что адрес памяти, куда пытается обратиться инструкция вычисляется следующим образом:

• берется базовый адрес из регистрового файла (аргумент rs1 инструкции, rs1 означает "возьми значение из такого-то регистра)
• к нему прибавляется смещение (константа инструкции)
  Это косвенная адресация, потому что в инструкции указывается адрес регистра, в котором находится адрес в памяти, и это адресация со смещением, потому что к адресу еще прибавляется константа.

К примеру инструкция lw x2, 0xC(x1) ("считай слово из памяти по адресу, для расчёта которого нужно сложить 0xC со значением из регистра x1, и сохрани результат в регистр x2)
Здесь:

• rd (регистр, куда запишут результат инструкции) — это x2
• rs1 (регистр, где хранится базовый адрес) — это x1
• смещение — константа 0xC

Допустим в регистре x1 хранится число 0x1000. Тогда процессор сделает обращение в память по адресу: 0x1000+0xC=0x100C. Допустим, начиная с этого адреса хранится слово 0xDEAD_BEEF. Значит после выполнения инструкции в регистре x2 окажется значение 0xDEAD_BEEF.

[HepoH3]

Добавил иллюстрацию к гарвардской архитектуре

[HepoH3]

Насчет слайда из презентации. Картинка в методичке иллюстрирует то, как будет накладываться байтовое представление памяти, какой ее видит процессор на реальный блок памяти, который хранит данные в виде 32битных ячеек.
Картинка из презентации иллюстрирует карту памяти процессорной системы (как раз то что память и данные видятся процессором в едином адресном пространстве, что первые адреса системы отводятся для системных нужд, затем под стек, RAM, память инструкций и mmio. Смущает только что стек находится посреди адресного пространства, спецификация RISC-V назначает стеку самые старшие адреса RAM.
Сам курс выглядит интересно, но он как будто проходит на довольно высоком уровне абстракции. В лекциях нашего курса, к примеру разбираются поэтапно однотактная, многотактная и конвейерная микроархитектуры.

[tedichol]

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

[HepoH3]

Раздел 10 "Лабораторная № 5. Декодер инструкций. Предлагаемая микроархитектура...": так какая же все-таки архитектура процессора? Первый скрин из лабораторной 4, второй из данной

В ЛР№4 предлагается в качестве контрольной точки остановиться и реализовать простейший процессор из тех блоков, что были сделаны на первых 3-х лабораторных работах. Это еще не процессор архитектуры RISC-V, у него нет памяти данных, только регистровый файл, и он может выполнять только 16 инструкций, но этого уже достаточно, чтобы писать простенькие программы по обработке данных.

Начиная с ЛР№5 уже происходит подготовка в реализации полноценного однотактного процессора архитектуры RISC-V. Несмотря на то, что показанная в этой лабораторной микроархитектура будет реализованна только к ЛР№11, в ЛР№5 уже нужно знать как будет устроен будущий процессор, чтобы понять какие сигналы декодера за что будут отвечать в будущем.

[tedichol]

да, хорошо, я понимаю, но не совсем это имел ввиду, на картинках показано, что в ЛР 4 и ЛР 5 упоминаются разные архитектуры CYBERcobra 3000 Pro в одной 2.0, в другой 2.1. Меня немного это смутило

[HepoH3]

А, это просто опечатка, я все унифицировал теперь. Раньше просто была версия 2.0, потом немного изменилась архитектура, и стало 2.1, но не везде поправили)