AZ для БК-0010(01) и БК-0011М

[Sandro]

upd: точнее это не баг, а следствие действий оптимизатора, который делает автомат в onehot и как следствие у него появляются запрещенные состояния, в которые он и влетает
лечится явной установкой кодирования автомата или установкой safe

Макс, а ты на каком языке пишешь? В VHDL для этого есть ветка others, в Verilog -- default. Нормальные компиляторы ругаются на их отсутствие.

[SuperMax]

Макс, а ты на каком языке пишешь? В VHDL для этого есть ветка others, в Verilog -- default. Нормальные компиляторы ругаются на их отсутствие.

verilog
ветка конечно описана, но (!) оптимизатору на нее пофиг

[Hunta]

лечится

Мне помогало никогда не проверять на то значение, которое onehot.

[SuperMax]

Мне помогало никогда не проверять на то значение, которое onehot.

тут речь немного о другом - изначально автомат обычный:

localparam STATE_STM_WAIT	= 3'd0; 	// ждем =0 на STM_U_QBUS_IN_L
localparam STATE_STM_CLANK1= 3'd1; 	// антизвон
localparam STATE_STM_CLANK2= 3'd2; 	// антизвон
localparam STATE_STM_CLANK3= 3'd3; 	// антизвон
localparam STATE_STM_FLAG	= 3'd4;	// ждем установки флагов операции
localparam STATE_STM_DATA	= 3'd5;	// запоминаем данные для команды
localparam STATE_STM_OPER	= 3'd6;	// выполняем операцию
localparam STATE_STM_END	= 3'd7;	// ждем завершения - снятия синка 


reg [2:0] state_stm			/* synthesis syn_encoding="safe" */;
reg [2:0] next_state_stm;	

 
always @ (posedge CLK)
begin
	state_stm<=next_state_stm;
end
//

wire stm_sync=STM_DA_OUT[8];

always @ *
begin
	case (state_stm)
		STATE_STM_WAIT:
			if(STM_U_QBUS_IN_L==0)
				next_state_stm=STATE_STM_CLANK1;
			else
				next_state_stm=STATE_STM_WAIT;
				
		STATE_STM_CLANK1:
				next_state_stm=STATE_STM_CLANK2;
		
....
			
		default:
				next_state_stm=STATE_STM_WAIT;
	endcase
end

но оптимизатор переделывает автомат в onehot

и если работать без /* synthesis syn_encoding="safe" */;
и так как управляющие сигналы - асинхронщина, то шанс влететь в запрещенное состояние становится очень большим

соответственно можно или сказать
/* synthesis syn_encoding="safe" */; - те сделать защитную логику

или вообще указать тип кодирования явно


да, собирая грабли я таки вычистил тормозящие куски и теперь оперативка на 130MHz полноценно пашет

[Sandro]

c палитрой будет так:
нумерация кодов цветов
палитра коды цветов (адреса ячеек палитры)
256 0-256
(---)

А зачем? Зачем прибивать разрядность палитры к диапазону адресов? Я бы просто сделал начальный адрес палитры и разрядность цвета. И пусть программист сам делит доступный ему бюджет регистров палитры, как хочет.

Зачем это прокрустово ложе?

- - - Добавлено - - -

тут речь немного о другом - изначально автомат обычный:

но оптимизатор переделывает автомат в onehot

и если работать без /* synthesis syn_encoding="safe" */;
и так как управляющие сигналы - асинхронщина, то шанс влететь в запрещенное состояние становится очень большим

Интересные дела. То есть, почему onehot -- понятно, в большинстве случаев это сильно упрощает автомат. Но вот такое поведение -- это явно некорректная опимизация при указанном default.

Я предполагал классические косяки с casex, но для них тут нет места. Хм. Про комбинаторику даже не знаю, что сказать, это какой-то позор в синтезаторе.

Тем не менее, я бы переписал на синхронный код. Тут у синтезатора гораздо меньше шансов проявить свободу своей хулиганской воли.

PS: Вообще, когда я только начал работать на реальный кремний (2004), мне было сразу сказано, что /* synthesis ... */ в коде -- это заметание мусора под ковёр. Ни одного опровержения по сей день не видел.

[SuperMax]

А зачем? Зачем прибивать разрядность палитры к диапазону адресов? Я бы просто сделал начальный адрес палитры и разрядность цвета. И пусть программист сам делит доступный ему бюджет регистров палитры, как хочет.

Зачем это прокрустово ложе?

поясни идею

чем плохо наличие персональной палитры у каждого цвета у каждого видеорежима и штатной палитры?

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

или (что более вероятно) будет добивка кода в старое ПО где будет задаваться расширенная палитра и режим отображения
к примеру в land вставить явное переключение в мнохром и сделать фон не черным а темнокрасным
и менять его от уровня к уровню

Интересные дела. То есть, почему onehot -- понятно, в большинстве случаев это сильно упрощает автомат. Но вот такое поведение -- это явно некорректная опимизация при указанном default.
Я предполагал классические косяки с casex, но для них тут нет места. Хм. Про комбинаторику даже не знаю, что сказать, это какой-то позор в синтезаторе.
Тем не менее, я бы переписал на синхронный код. Тут у синтезатора гораздо меньше шансов проявить свободу своей хулиганской воли.
PS: Вообще, когда я только начал работать на реальный кремний (2004), мне было сразу сказано, что /* synthesis ... */ в коде -- это заметание мусора под ковёр.
Ни одного опровержения по сей день не видел.

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

[SuperMax]

Занялся разработкой стартовой "ПЗУ"

Возникли вопросы:
1. есть ли готовый код определения типа БК ?

2. правильно ли я насчитал варианты:
;БК-10
;- с неотключаемым фокалом
;- с отключаемым бейсиком
;- с отключаемым бейсиком и монитором
;БК-11
;?
;БК-11М
;- обычная
;- новодел с отключаемым монитором

или есть еще варианты ?

особо волнует новодел БК11 тк его у меня нет

[Sandro]

поясни идею

В смысле? Что тут пояснять? rgb = palette[colorIndex + paletteOffset];

чем плохо наличие персональной палитры у каждого цвета у каждого видеорежима и штатной палитры?

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

это явно дает гибкость

Наоборот, это даёт жёсткость. Гибкость -- это то, что предлагаю я.

и сохраняет полную совместимость с легаси

Мой вариант -- тоже сохраняет полную совместимость.

к примеру новое ПО использует штатный видеорежим, и штатные палитры

Напоминаю, что штатно в БК НЕТ программного выбора видеорежима. Вообще нет. Это не УКНЦ.

[SuperMax]

В смысле? Что тут пояснять? rgb = palette[colorIndex + paletteOffset];

оно еще проще:

цвет на выходе = VideoModeOffset + PaletteOffset + ColorIndex ;

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

поясни в чем ограничение

Напоминаю, что штатно в БК НЕТ программного выбора видеорежима. Вообще нет. Это не УКНЦ.

штатно - нет и это недостаток который я устраняю

[gid]

1. есть ли готовый код определения типа БК ?

Есть, классика - запись в регистр 177662:

BK10=0  ;флаг машины БК10
BK11=1  ;флаг машины БК11
        mov #bk10, @#4
        mov #40000, @#177662    ;на БК10 будет trap to 4
        mov #BK11, Machine
        br go_next
bk10:   mov #BK10, Machine
go_next: ...

или есть еще варианты ?

обычная БК11М с отключаемым монитором, в принципе и обычная БК11 с отключаемым монитором, т.к. это - необходимая доработка для работы с любым контроллером АльтПро. (то, что на БК11 без М работать с контроллерами АльтПро неудобно и сложно, но можно, другой вопрос)