Цифровая археология: 1801 и все-все-все

[Vslav]

ВМ3 - это уже КМОП или еще НМОП?

Все тот же n-МОП.

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

Vslav, вот есть такая штука "always @(posedge pin_clk_p)", в ней регистр mjres меняет своё значение, допустим с 0 на 1.
Как в таком случае должен выполняться "always @(posedge pin_clk_p or posedge mjres)"? Сперва часть кода в соответствии с "posedge pin_clk_p", как и для предыдущего alwaysа, а затем в этой же итерации - часть кода в соответствии с вновь возникшим "posedge mjres", затирая результаты выполнения этого alwaysа для "posedge pin_clk_p" или всё таки обрабатывать "posedge mjres" в следующей итерации?

При положительном фронте clk_p для always @(posedge pin_clk_p or posedge mjres) надо сначала обработать событие положительного фронта. Там в блоке стоит обычно сразу if (mjres), если он ненулевой на момент наступления фронта, то объект и останется в сбросе. Если же mjres нулевой, то отрабатывается смысловая часть объекта, на выходе получается набор каких-то значений, которые еще не перенесены в основное состояние, а находятся в промежуточном буфере, то есть оно ни на что еще не повлияло. Потом вычисляется mjres, и оказывается что его состояние изменилось с 0 в 1, и возникло событие posedge mjres, тогда снова обрабатывается объект, он переходит в состояние сброса, но значения на выходе опять-таки попадают в промежуточный буфер. Когда в процессе итераций всякие изменения закончились - можно считать что событие фронта clk_p полностью обработано, можно переносить новые состояния всех сигналов в постоянный буфер. Поэтому порядок обработки событий posedge pin_clk_p и posedge mjres никак не должен влиять на результат.

Еще есть особенность что новый mjres находится в промежуточном буфере и ни на что вроде бы не должен влиять, но поскольку он упомянут в posedge, то для него надо делать исключение. Там собственно всего четыре исключительных сигнала - reset, mjres, abort и qbus_tena (и в ВЕ-таймере еще парочка). Возможно их надо вычислить в начале обработки clk_p (они фиксируются по clk_p и более не изменяются), а дальше вычислять все остальное, учитывая новые значения 'исключительных'.

[Advertiser]

[gid]

С регистрами в условии чувствительности разобрался, даже вроде как реализовал рабочий вариант.
А вот с wireм в условии чувствительности возникли проблемы. Возьмём этот always

always @(posedge pin_clk_n or negedge qbus_tena)
begin
    if (~qbus_tena)
        qbus_timer <= 6'o00;
    else
        if (~qbus_tovf)
            qbus_timer <= qbus_timer + 6'o01;
end

допустим, где-то между фронтами частоты, произошло событие "qbus_tena 1->0", при этом этот always сработал, выполнилась часть

qbus_timer <= 6'o00;

затем случилось событие "posedge pin_clk_n", но qbus_tena остался равен 0, должен ли при этом выполняться код

if (~qbus_tovf)
            qbus_timer <= qbus_timer + 6'o01;

игнорируя условие "if (~qbus_tena)" или нет?
У меня работает только такой вариант:

void C1801VM1::eval_all_n()
{
...
	if (wire.qbus_tena) 
	{
		if (!snap_reg.qbus_tovf)
	        {
		        reg.qbus_timer = (snap_reg.qbus_timer + 1) & 077;
	        }
	}
...
}

т.е. код по событию "posedge pin_clk_n" выполняется только если qbus_tena == 1, а иначе, если закомментировать строку "if (wire.qbus_tena)" перестаёт работать команда RESET, т.е. она становится бесконечной, и вызывает ошибку зависания на шине.

[Vslav]

допустим, где-то между фронтами частоты, произошло событие "qbus_tena 1->0"

Это событие не может произойти между фронтами частоты. Находим источник qbus_tena:

assign qbus_tena = dout_out | din_out;

и видим что он зависит от двух регистров dout_out и din_out, которые, в свою очередь
меняются по clk_p и mjres, последний меняется тоже только по clk_p.
Поэтому оптимальный порядок при событии clk_p такой:
- вычислили значение mjres, abort, reset
- занесли, в виде исключения эти три новых значения в исходное состояние, на базе которого
будет вычисляться все остальное
- вычислили din_out, dout_out и производный qbus_tena
- для qbus_tena опять сделали исключение, сразу заносим в исходное
- тут можно повычислять еще "исключительные" сигналы, типа tve_reset
- вычисляем все остальное

В исходное состояние можно не заносить (если там есть какой анализ изменения ил чего еще),
но вычисление зависимых блоков надо делать на основе нового значения "исключительных" сигналов.

Если делать совсем правильно, то считать несколько событий:
- posedge clk_p
- posedge reset
- posedge abort
- posedge mjres
- negedge qbus_tena

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

затем случилось событие "posedge pin_clk_n", но qbus_tena остался равен 0, должен ли при этом выполняться код

if (~qbus_tovf)
            qbus_timer <= qbus_timer + 6'o01;

игнорируя условие "if (~qbus_tena)" или нет?

Не должен, почему следует игнорировать условие ~qbus_tena? Оно как раз выполняется при qbus_tena==0, там же инверсия ~. А код стоит в ветке else и он не выполняется.

У меня работает только такой вариант:

	if (wire.qbus_tena) 
	{
		if (!snap_reg.qbus_tovf)
	        {
		        reg.qbus_timer = (snap_reg.qbus_timer + 1) & 077;
	        }
	}

Да, тут все правильно, соответствует исходному Верилогу. Если qbus_tena нулевой, то таймер удерживается в сбросе, если ненулевой - идет счет до появления флага переполнения, на нем счет останавливается.

[balu_dark]

Тут еще важно не путать Верилог с его параллельным исполнением всего и С с его последовательной обработкой. С никогда не будет при одинаковом написании вести себя как модель VHDL или Verilog. И если честно - я даже не представляю как реальную параллельность процессов представить в С.

[Patron]

Если ModelSim не шутит, то в модели QSync такой проблемы нету

Но есть проблема с запуском модели QSync под голым ModelSim ( без квартуса и альтеровских библиотек ) - во всяком случае с ModelSim SE 10.2c такое не получилось. Предлагаю попробовать поставить на виртуальную машину голый ModelSim, создать в нём родной проект, запустить симуляцию теста команд в модели QSync и выложить получившийся тестовый комплект.

[Vslav]

Но есть проблема с запуском модели QSync под голым ModelSim

Какая именно проблема? Модель зависает на снятии RPLY? Или проблемы создания/запуска собственно проекта?

Но есть проблема с запуском модели QSync под голым ModelSim
( без квартуса и альтеровских библиотек)

Нет понятия "голый ModelSim", Квартус просто создает файлы проекта для ModelSim и запускает его. Далее MS работает самостоятельно, Квартус на него никак не влияет - вся связь между программамми через файлы.
ModelSim-ы тоже бывают разные, можно в Квартусе указать какой именно запускать, раньше использовал ModelSim 10.1 Altera Starter Edition, но там включается ограничение на скорость симуляции после достижения предела ячеек, перешел на полный Altera Edition. Библиотеки, кстати, тоже нужны, там есть файл vm1_alib.v куда вынесены зависимые от альтеры модули, чтобы их можно было легко заменить при переходе на другую платформу.

Предлагаю попробовать поставить на виртуальную машину голый ModelSim, создать в нём родной проект, запустить симуляцию теста команд в модели QSync и выложить получившийся тестовый комплект.

Это бесполезная трата времени, вероятность что проблема в ModelSim невелика, лучше время потратить на поиск ошибки в C++, может быть, смогу разобраться.
Кстати, есть более простые симуляторы - например, Icarus Verilоg, с ним можно намного быстрее разобраться. Он, правда, больше текстовый, но диаграммы тоже можно получить.

[Patron]

Какая именно проблема?

Проблема не одна.

Для начала добавление папки source в проект ModelSim не позволяет искать в ней включаемые файлы, поэтому проект не компилируется:



Решается перемещением содержимого папок в корень проекта.

Но запуск симуляции всё равно не идёт :



Решается исключением из проекта de0top.v и vm1_alib.v и редактированием vm1_qbus.v.

После этого модель загружается для симуляции, хотя макрос wave.do и ругается на отсутствие исключённых объектов.

Теперь запускаем симуляцию и получаем:

[Vslav]

Для начала добавление папки source в проект ModelSim не позволяет искать в ней включаемые файлы, поэтому проект не компилируется:

Хорошо, тут надо видимо мне собрать проект для ModelSim "с нуля". Правда мне до сих пор этого делать ни разу не приходилось.

Решается исключением из проекта de0top.v и vm1_alib.v и редактированием vm1_qbus.v.

de0top можно безболезнено исключить, он нужен только квартусу для успешного синтеза и совсем не нужен для симуляции.
vm1_alib.v можно попытаться исключить если в config.v определить нулевое CONFIG_VM1_CORE_REG_USES_RAM.

Там оно еще не нашло файл с программой - test.mem, получается после компиляции тестов из папки Ztest.

[Patron]

надо видимо мне собрать проект для ModelSim "с нуля"

Об том и речь - надо бы сделать тестовый комплект для запуска модели QSync на голом ModelSim.

Библиотеки, кстати, тоже нужны, там есть файл vm1_alib.v куда вынесены зависимые от альтеры модули

А есть ли эти библиотеки в комплекте ModelSim SE 10.2c :



И если да, то как их использовать при симуляции ?

[Vslav]

Об том и речь - надо бы сделать тестовый комплект для запуска модели QSync на голом ModelSim.

А почему бы не запускать симуляцию одной кнопкой из Квартуса?

Архив для ModelSim Altera Edition.
- отредактировать пути в vm1_run.do
- запустить ModelSim
- перейти в каталог с проектом (->File->Change Directory)
- запустить vm1_run.do
- удалить диаграммы по умолчанию в окне диаграмм
- запустить wave.do
Дальше симулировать
В test.mem - исполняемая программа