4-bit minimal

Lavr · Post by **Lavr** » 08 Sep 2012 21:24

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

Но что-бы был какой-либо адекватный "дискасс", как ты предложил, надо хоть
немного понимать как это "взлетит".

Извини - я немного дополнил исходную блок-схему, как это понимаю я.

И я представляю, согласно рисунку, что это работает так:

Из ПЗУ или ОЗУ через мультиплексор под действием сигнала dsel поступает
КОП - 4-битный код операции.

(Сразу непонятно, почему ПЗУ и ОЗУ детализированы отдельно, управляются
по-разному и коммутируются через мультиплексор - у них же высокоимпедансный
выход, они не мешают по выходу друг другу и мультиплексор вроде как и нафиг
не нужен...)

Я надеюсь, ты это уточнишь...

Значит 4-битный код операции поступил-таки на вход регистра состояния.
На линиях ADDR_NEXT - адреса следующей команды - должный быть нулевые
значения, чтобы мы нашли однозначно первую микрокоманду в ПЗУ микрокоманд,
соответствующую КОДУ ОПЕРАЦИИ.

(Здесь непонятно, почему ПЗУ микрокоманд объеденено с АЛУ, и куда на диаграмме идут
флаги.)

Я надеюсь, ты это уточнишь... Но продолжу по сути:

КОП и начальный ADDR_NEXT=0 выдадут 1-е состояние на выходе
ПЗУ микрокоманд, ADDR_NEXT укажет на следующую микрокоманду,
и далее микрокоманды должны перебираться в ПЗУ микрокоманд последовательно
все, сколько их надо для исполнения ЭТОЙ ОПЕРАЦИИ - верно?

Поскольку я не видел на блок-схеме механизма перебора микрокоманд,
я предположил, что это работает так:
Регистр состояния - это счётчик с предзагрузкой. Первая микрокоманда, соответствующая
КОП-у, разрешает работу Тактовому генератору, который начинает перебирать последовательно
адреса (младшие) в ПЗУ микрокоманд, инкрементируя (декрементируя?) регистр состояния .
ADDR_NEXT-даёт реальный адрес микрокоманд, поскольку все операции, соответствующие
разным Кодам ОПераций, выполняются за разное число тактов.

Последний код микрокоманды, соответствующий конкретному КОП-у, выполняемому
в отдельный момент, должен выставить ADDR_NEXT=0 и выключить Тактовый генератор.

В этот момент на младшие 4 линии регистра состояния, согласно логике работы,
должен поступить следующий КОП из программы.

ADDR_NEXT=0 и КОП снова укажут первую микрокоманду для этого уже КОП-а, и весь
процесс повторится.

Я правильно понял весь принцип работы?
Если да - то я не пойму как:

b2m wrote:Все регистры в ОЗУ.

Как манипулировать в ОЗУ таким вот Регистром состояния - мне совсем непонятно...

Если я всё понял неверно, то поясни процесс, как ты его задумал, и как представляешь.

b2m · Post by **b2m** » 09 Sep 2012 01:39

Lavr wrote:Из ПЗУ или ОЗУ через мультиплексор под действием сигнала dsel поступает
КОП - 4-битный код операции.

Не обязательно КОП. Это может быть и содержимое регистра. Сразу после сброса это значение вообще не используется. Конечно, использовать 16 слов микрокода для одной микрокоманды расточительно, но это попытка обойтись меньшим количеством микросхем за счёт более жирной ПЗУ микрокода.

Lavr wrote:Сразу непонятно, почему ПЗУ и ОЗУ детализированы отдельно, управляются
по-разному

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

Lavr wrote:чтобы мы нашли однозначно первую микрокоманду в ПЗУ микрокоманд,
соответствующую КОДУ ОПЕРАЦИИ.

ПЗУ микрокоманд начинается с отработки сброса - т.е. занесения начального значения счётчика команд в ОЗУ (в области регистров).

Lavr wrote:Здесь непонятно, почему ПЗУ микрокоманд объеденено с АЛУ, и куда на диаграмме идут
флаги.)

Мне лень было отрисовывать все линии управления, я просто отметил их красным цветом. Понятно, что они идут из ПЗУ микрокоманд.

Lavr wrote:далее микрокоманды должны перебираться в ПЗУ микрокоманд последовательно
все, сколько их надо для исполнения ЭТОЙ ОПЕРАЦИИ - верно?

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

Lavr wrote:Регистр состояния - это счётчик с предзагрузкой.

Нет. Это просто защёлка, тактируется тактовым генератором, который работает постоянно, нет никакого разрешения/запрещения работы.

Lavr wrote:Я правильно понял весь принцип работы?

Нет. Регистр состояний + ПЗУ микрокоманд - это автомат, имеющий на входе данные, и на выходе данные. Он переходит из одного состояния в следующее в зависимости от входных данных, которые он может иногда игнорировать.

Надо будет дополнить схему ещё одним регистром адреса (только младшие 4 бита) для адресации ещё одного регистра. Таким образом, в распоряжении микрокода будет два указателя на память для модификации. Одного явно нехватает.

Lavr · Post by **Lavr** » 09 Sep 2012 02:50

b2m wrote:
Lavr wrote:Я правильно понял весь принцип работы?
Нет. Регистр состояний + ПЗУ микрокоманд - это автомат, имеющий на входе данные, и на выходе данные. Он переходит из одного состояния в следующее в зависимости от входных данных, которые он может иногда игнорировать.

Вобщем-то это весьма уклончивый и абстрактный ответ...

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

Из блок-схемы никак не видно, что заставляет этот "автомат переходить
из одного состояния в следующее"? Это всё же синхронная схема.
Я попытался это уточнить, но ясности не возникло.

b2m wrote:
Lavr wrote:далее микрокоманды должны перебираться в ПЗУ микрокоманд последовательно
все, сколько их надо для исполнения ЭТОЙ ОПЕРАЦИИ - верно?
Не последовательно, а так, как укажет ADDR_NEXT. Но это не исключает последовательного перебора. Просто ADDR_NEXT будет указывать на следующую микрокоманду.

А вот этот момент мне показался интересным.
Я побоялся использовать команды разной длины в тактах, поскольку мне казалось
это сильно усложнит всё схемотехнически. Но сейчас, глядя на твою схему, вижу,
как мне кажется, решение элегантное.
Ну, во-первых, после перехода на адрес, где начинается последовательность
микрокоманд для отдельного КОП, ADDR_NEXT меняется скорее всего последовательно.
Согласись - нет особого смысла разбрасывать микрокоманды по ПЗУ?
Во-вторых, выходы ПЗУ микрокоманд приходится фиксировать, т.к. есть "иголки"
при переключении.
Отсюда решение вот какое: на младшие 4 разряда ПЗУ микрокоманд подключаем
счётчик микрокоманд со входом сброса.

На следующие 4 разряда ПЗУ микрокоманд подключаем Регистр команды - просто
защелка КОП-а.
На все остальные старшие разряды ПЗУ микрокоманд подключаем выходы регистра-
защелки значения ADDR_NEXT.
А вот входы регистра-защелки значения ADDR_NEXT - непосредственно на
управляющие выходы ПЗУ микрокоманд.
Подчеркиваю - на управляющие выходы ПЗУ микрокоманд.

И процесс "перехода из одного состояния в следующее в зависимости от входных данных" (КОП-а)
будет выглядеть так:
после сброса счётчик микрокоманд = 0, ADDR_NEXT =0, КОП- на своих адресных линиях.
По этому адресу 00...00.КОП_0000 находится адрес последовательности микрокоманд
для этого КОП-а. Он выдаётся на выходы ПЗУ микрокоманд и фиксируется в регистре-защелке
значения ADDR_NEXT. После этого на следующих тактах состояния на выходах ПЗУ микрокоманд
меняются под воздействием счётчика микрокоманд, но фиксируются в другой регистр-защелку,
на выходах которого уже формируются управляющие импульсы.

Таким образом, ADDR_NEXT фиксируем 1 раз - в начале, а потом, начиная с него микрокоманды
выводятся последовательно.
Длина команды (здесь максимальная - 16 тактов) регулируется выдачей сигнала СБРОС на
счётчик микрокоманд и регистр ADDR_NEXT.
В этот момент в Регистре команды - новый КОП, снова состояние - 00...00.КОП_0000 .
И весь процесс повторяется.
Но! Нам не нужны отдельные выходы для ADDR_NEXT у ПЗУ микрокоманд !!!

b2m wrote:
Lavr wrote:Здесь непонятно, почему ПЗУ микрокоманд объеденено с АЛУ, и куда на диаграмме идут
флаги.)
Мне лень было отрисовывать все линии управления, я просто отметил их красным цветом. Понятно, что они идут из ПЗУ микрокоманд.

Может быть тебе уточнить подробнее свою блок схему? Обсуждаем - то мы то, что ты предложил,
и трудно гадать, где тебе было лень, а где ты думал по-другому, но от лени оставил как уж вышло?

b2m · Post by **b2m** » 09 Sep 2012 08:01

Lavr wrote:Из блок-схемы никак не видно, что заставляет этот "автомат переходить из одного состояния в следующее"?

Ладно. Допустим, что регистр состояния защёлкивается по переднему фронту тактового генератора, а остальные регистры - по заднему.

Lavr wrote:Согласись - нет особого смысла разбрасывать микрокоманды по ПЗУ?

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

Lavr wrote:А вот входы регистра-защелки значения ADDR_NEXT - непосредственно на управляющие выходы ПЗУ микрокоманд.
Подчеркиваю - на управляющие выходы ПЗУ микрокоманд.

А сейчас разве не так? Могу перерисовать, чтобы ПЗУ микрокоманд находилось над регистром-защёлкой.

Lavr · Post by **Lavr** » 09 Sep 2012 08:18

b2m wrote:
Lavr wrote:А вот входы регистра-защелки значения ADDR_NEXT - непосредственно на управляющие выходы ПЗУ микрокоманд.
Подчеркиваю - на управляющие выходы ПЗУ микрокоманд.
А сейчас разве не так? Могу перерисовать, чтобы ПЗУ микрокоманд находилось над регистром-защёлкой.

Ну я вижу, что не так: 16 разрядов (по блок-схеме) - чисто ADDR_NEXT,
а ещё - выходы на регистры адреса.

А я предлагаю - их всего 16, но они используются в мультиплексном режиме.
То в регистр ADDR_NEXT защелкнутся, то - в регистры адреса.

Ну вобщем-то блок-схема - вещь в значительной мере неконкретная...
У нас на работе есть почти поговорка:"Когда мне показывают эквивалентную
схему, я чувствую, что меня хотят в чём-то обмануть..."

b2m · Post by **b2m** » 10 Sep 2012 06:35

Обновил картинку в соответствии с мыслями на данный момент.

Формат слова ПЗУ микрокоманд теперь такой:

Code: Select all

nnnnnnnn h l ww dddd 

nnnnnnnn - адрес следующего состояния (дополнится справа 4-мя битами из ОЗУ) 
h - выбор старших бит адреса hsel
l - выбор младших бит адреса lsel
ww - разрешение записи (we) одного из 4-х устройств 
  00 - регистр адреса L1
  01 - регистр адреса L2
  10 - регистр адреса H
  11 - ОЗУ
dddd - выходные данные

При помощи FASM сгенерил микрокод, который может выбирать КОП и есть одна команда с кодом 1 r d записывающая в регистр r значение d.

Code: Select all

macro op code,data,lbl {
	local next
	if lbl eq
		next = ($/2+10h) shl 4
	else
		next = (lbl/2) shl 4
	end if
	repeat 16
		dw next+code+data
	end repeat
}

macro INC lbl {
	local next
	next = ($/2+10h) shl 4
	repeat 15
	  dw 30h+%+((lbl/2) shl 4)
	end repeat
	dw 30h+next
}

macro SWITCH [list] {
	forward
		dw ((list/2) shl 4)
}

JMP   fix op 0,0,
STAL1 fix op 0h,
STAL2 fix op 10h,
STAH  fix op 20h,
STR1  fix op 30h,
STR2  fix op 70h,
STM1  fix op 0B0h,
STM2  fix op 0F0h,

macro fetch {
	local lbl
	STAL1 0Eh
	INC lbl
	STAL1 0Fh
	INC lbl
lbl:	STAL1 0Fh
	STAH %-1
	STAL1 0Eh
	STAL1 %-1+80h
}

; Start of microcode

	STAL1 0Eh
	STR1  0Fh
	STAL1 0Fh
	STR1  0Fh
L1:	fetch
	SWITCH  L1,_LDI,L1,L1, \
		L1,L1,L1,L1, \
		L1,L1,L1,L1, \
		L1,L1,L1,L1

_LDI:	fetch
	STAL2 %-1
	fetch
	STR2 %-1,L1

we на ОЗУ надо наверное тоже через триггер пустить (чтобы по заднему фронту тактового сигнала записывался), а то иголки могут всё испортить...

b2m · Post by **b2m** » 10 Sep 2012 08:34

b2m wrote:we на ОЗУ надо наверное тоже через триггер пустить (чтобы по заднему фронту тактового сигнала записывался), а то иголки могут всё испортить...

Не, лучше нулевой фазой тактового сигнала простробировать

Lavr · Post by **Lavr** » 10 Sep 2012 08:40

b2m wrote:Не, лучше нулевой фазой тактового сигнала простробировать

Я так и делал в 4-битном ЦПУ.

VituZz · Post by **VituZz** » 22 Dec 2012 08:08

Не то чтобы прямо по теме, но в связи с минимализмом 4-битных процессоров.

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

Lavr · Post by **Lavr** » 26 Dec 2012 21:42

VituZz wrote:Не то чтобы прямо по теме, но в связи с минимализмом 4-битных процессоров.
Интересны соображения по поводу того, что должен уметь делать такой процессор практически (вернее, устройство на его основе). Для чего вообще такие процессоры "рожают" в наше время? Какие задачи на него можно возложить? Ведь от этого в значительной степени зависит "степень минимализма" нашего подопечного.

Я прогуглил очень много 4-битных устройств, чтобы "велосипедов" не изобретать...
Так вот основная мысль их создания, на мой взгляд, такая же, как и у нас здесь:
Значительно сократить объём элементов на кристалле.

Это, на мой взгляд, - основная причина их существования.

А применяются он в основном как контроллеры. В частности, как драйверы LCD дисплеев -
весьма популярны...

А так, если широко окинуть взглядом, они весьма сложные и развитые бывают.
Но упор всё-таки больше - на управление периферией.