Во время своей работы
процессор полностью "занимает" шины и адреса, и данных (является мастером на шине). С помощью отдельных управляющих
сигналов ему можно сообщить, что какому-то другому устройстве на шине тоже необходим доступ к адресной шине и шине
данных и процессор их "уступит". При этом, все остальные устройства так же должны иметь механизм отслеживания подобных
запросов от процессора, чтобы не "вступить в спор" за шины и не устроить конфликт - bus contention. Конечно, можно
описать (программно) эти механизмы отслеживания состояний управляющих линий процессора и предусмотреть необходимое
поведение, но нужно будет всегда об этом помнить и учитывать. При этом, с каждым новым добавленным устройством на общие
шины, учитывать это придётся на всех остальных без исключения.
Механизмы разрешения и предотвращения таких конфликтов шины называются арбитражом. И могут быть выполнены несколькими разными способами.
Арбитр шины
Децентрализованный арбитраж
Это ситуация где все устройства на шине (любой общей) должны "договариваться" со всеми остальными тем или иным образом.
Например, на основе приоритетов, когда у каждого устройства есть свой код (ID), который оно выставляет, когда
устройству необходимо что-то передать по шине. Определённым образом сравнивая получившийся результат (после выставления
ID на шину) и определяется приоритет. Если чужой приоритет выше (активно ещё какое-то передающее устройство) -
устройство прекращает передачу и слушает. Например, так работают устройства на шине CAN в автомобилях.
Централизованный арбитраж
При таком способе арбитража на шине присутствует отдельный аппаратный узел (блок, специальная микросхема или набор микросхем), который принимает запросы от всех остальных и принимает решение, кому выдать разрешение.
Поэтому я выбрал для своей архитектуры централизованный арбитраж. Во-первых, перестаёт быть нужным программирование каждого устройства на шине на определённую "вежливость" по отношению к соседним, во-вторых, появляется одна центральная точка управления всеми доступами к шине, а в-третьих, такая топология отлично подходит для изучения FPGA и Verilog - FPGA идеально подходит для отслеживания запросов со всех сторон и быстрым (за такт) решением, кому отдать шину в текущий момент.
Расширение роли арбитра в Z-Frame
Сам по себе арбитр в подобных системах находится некоторым образом "сбоку", т.е. отслеживает только управляющие
сигналы "запрос шины", "разрешение доступа" и подобные. В Z-Frame я решил завести все сигналы и данные в арбитр
целиком. Что сразу же расширило функциональность и возможности - так арбитр становится и коммутатором (bus arbiter +
interconnect). Все шины - адреса, данных, управления - заходят в FPGA и выходят из неё. Активные устройства не
ведут шину напрямую друг к другу, всё коммутирует FPGA. Фактически она и есть шина: кто с кем и в какой момент
"разговаривает", в каждый такт решает она.
Отсюда же вытекает и тактирование процессора: раз всё завязано на ПЛИС, логично и удобно возложить на неё же генерацию тактов для Z80. Чем это хорошо и какие возможности открывает опишу отдельно в соответствующих записях.
Если проводить параллель с "обычными" компьютерами - FPGA здесь берёт на себя роль, которую в классических x86-совместимых PC 90-х–2000-х играл чипсет (в первую очередь северный мост): узел, стоящий между процессором, памятью и остальной системой и коммутирующий их между собой. С тем лишь отличием, что в Z-Frame это один узел, а не связка из двух мостов (чипов).
Ещё из параллелей с "обычными" компьютерами - видеовывод. Видеоподсистема (VDP) - пассивный слушатель шины, который стоит в этой схеме обособленно - как отдельный вычислитель со своей собственной видеопамятью.
Она подключена к шинам адреса и данных процессора физически параллельно, рядом с FPGA. Но, в отличие от остальных,
она только слушает шину: перехватывает адресованные ей обращения к портам ввода-вывода и никогда сама ничего не
выставляет на линии в сторону процессора. Поэтому она и не участвует в арбитраже - конкурировать за владение шиной ей не
нужно, она пассивный наблюдатель (bus snooper).
А тяжёлую работу с картинкой видеоподсистема ведёт уже в своей видеопамяти, не нагружая общий тракт. Это тот же принцип, к которому пришли и "большие" машины, вынося графику сначала на отдельный порт, а потом и вовсе в отдельное устройство со своей видеопамятью. Это - отдельный большой пласт работ и подробно он будет описан по мере "дорастания" системы до этого уровня.