Устройство выборки команд и управления шинами

На этом месте должна была быть статья о моделировании инструкций из диапазона 0x60-0x6f. Однако, открылись некоторые обстоятельства, о которых пойдёт дальнейшее повествование. Именно поэтому статья попадает в блог, а не в раздел новостей. Для демонстрации поведения должна была использоваться следующая программа на макро-ассемблере «Эверест»:

Поведение программы должно было демонстрировать копирование части кода из внутреннего ПЗУ устройства в блок статической оперативной памяти и передача ему управления. Скопированный блок, в свою очередь, производит процедуру «касания» — пословно читает свой код, делает операцию «Логическое ИЛИ» с нулём и записывает обратно. С точки зрения практического смысла этот код делает пустую работу, но может быть полезен при отладке. При трансляции этого кода в машинные инструкции попутно создаётся вспомогательный отладочный файл с расширением mif_dbg. Этот файл получается в результате дизассемблирования сгенерированного машинного кода. Пример программы выше транслируется в следующий машинный код:

Приблизительно так должна была начинаться статья о переводе новых инструкций на конвейер. Для моделирования устройства был описан блок, повторяющий «ALTERA RAM 1-PORT». Сама тестируемая программа, показанная на предыдущих скриншотах, до последнего момента располагалась в следующем устройстве:

reg [7:0] firmware[2047:0];
initial begin
`include "firmware.vh"
end


а непосредственно доступ к памяти был реализован следующим образом:

wire [39:0] rom_data = o_ack ? {
firmware[ actual_bus_address[8:0] ],
firmware[ actual_bus_address[8:0] + 1 ],
firmware[ actual_bus_address[8:0] + 2 ],
firmware[ actual_bus_address[8:0] + 3 ],
firmware[ actual_bus_address[8:0] + 4 ]
} : 40'hz;


Такой подход  удобен для моделирования и благодаря ему удалось сократить время условных переходов и возврата из подпрограмм до одного такта. Проблема возникает при использовании этого подхода при переносе проекта в ПЛИС. Например, самая очевидная — избыточное использование ресурсов ПЛИС. При попытке перенести этот код в ПЛИС будет сформирована сложная схема из сотен триггеров и мультиплексоров — это цена за доступ в один такт. Но есть решение проблемы — Quartus предоставляет мегафункцию ROM. Одна из форм сгенерированного Квартусом устройства ROM показана ниже:

Использование мегафункции позволяет задействовать встроенную память ПЛИС, не использовав при этом ценные логические элементы. Однако, обратите внимание на схему ROM-2PORTS — входы адреса защищены регистрами, а это значит что при установке адреса актуальные данные, соответствующие этому адресу, появятся на выходе ROM только в следующем такте. Вытекающая из этого проблема — наше устройство выборки инструкций оказалось не готово к такому повороту событий — сломались «предсказатели переходов».

И вот, когда приведённая в начале статьи программа уже почти-почти заработала, были внесены конструктивные изменения в блок выборки инструкций и, как результат, этот блок требует переделки. Традиционно мы следуем принципу, согласно которому превращаем все проблемы в новые решения. Если описанный нами протокол взаимодействия блока выборки инструкций и исполнительного устройства позволяет организовать сложные схемы синхронизации, то конструктивные изменения в блоке выбора инструкций не должны повлиять на схематику исполнительного устройства. Если это предположение верное, то исполнительное устройство остаётся неизменным при любом варианте реализации блока выборки инструкций. Например, реализация памяти «на регистрах» не целесообразна при использовании ПЛИС, но может использоваться при переносе устройства в ASIC — при этом исполнительное устройство будет универсальным.

Реализация с использованием эмуляции ROM является серьёзным испытанием интерфейса взаимодействия исполнительного устройства и блока выборки команд и управления шинами. О результатах этого испытания мы надеемся рассказать в следующей статье.