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

[Vslav]

В реале данные выставляются на одном полутакте с DOUT, поэтому лучше задержать на полтакта активацию pin_ad_ena.

Нет, просто там была частота высокая (5.0МГц), задержки в кучу смешались.

Диаграмма при 2.5МГц

[свернуть]

При более низкой частоте видно что данные на шине появляются при высоком CLC (после фронта), а nDOUT активируется при низком CLC (после спада). И это правильно для МПИ, ГОСТ 26765.51-86 требует хотя бы 25 нс предустановленных данных перед спадом nDOUT. На диаграмме 100МГц отсчеты, поэтому одно деление - 10нс, требование стандарта успешно выполняется.

[Patron]

обновление 1.4D

В модели ASync фаза генератора тактовой частоты не исправлена.

Правильный код такой:

//_____________________________________________________________________________
//
// Clock generator
//
initial
begin
   ena = 1;
   forever
      begin
         clk = 0;
         #(`SIM_CONFIG_CLOCK_HPERIOD);
         clk = 1;
         #(`SIM_CONFIG_CLOCK_HPERIOD);
      end
end

[Vslav]

В модели ASync фаза генератора тактовой частоты не исправлена.

Да оно непринциально, но ОК, внесу.
В модели Wsync частота с PLL берется, там на начальную фазу повлиять нет возможности.

[Patron]

При более низкой частоте видно что данные на шине появляются при высоком CLC (после фронта), а nDOUT активируется при низком CLC (после спада). И это правильно.

Модель ASync подтверждает:

[Vslav]

Да, Async правильно работает, там qreg является латчем. С исправлением на clk_p в регистре qreg, Qsync тоже так начинает работать, только Fmax падает (времени такта АЛУ не хватает чтобы результат на qreg дать). В Async коррекцию внесу, в Wsync - оно там не нужно, нет Qbus.

[Patron]

Да, Async правильно работает, там qreg является латчем.

Значит ли это, что методически правильно вычислять значение qreg на каждом полутакте ?

Для CPP-модели сто вёрст не крюк, поэтому лишнее вычисление qreg на быстродействие модели не повлияет.

[Vslav]

Значит ли это, что методически правильно вычислять значение qreg на каждом полутакте ?

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

[Patron]

Для Async модели надо вычислять значения всех величин по любому изменению входных сигналов, в том числе и по тактовому.

Но CPP-модель основана на модели Qsync, поэтому вопрос про неё. Не зря ведь там qreg вычислялся именно по P-фронту.

Другими словами вопрос в том, справедливы ли следующие утверждения для модели Qsync:

1. Вычисление qreg по P-фронту имеет смысл.
2. Вычисление qreg по N-фронту имеет смысл.

[Vslav]

Но CPP-модель основана на модели Qsync, поэтому вопрос про неё. Не зря ведь там qreg вычислялся именно по P-фронту.

До недавнего анализа диаграммы записи qreg защелкивалось по clk_n, видимо, когда портировалось это обеспечило хорошую прибавку к Fmax. Вы выложили диаграмму записи, я начал думать что Вас в ней смущает, увидел что данные перед спадом nDOUT выглядят не очень, посмотрел на реальный процессор и решил защелкивать qreg по clk_p, это обеспечивает правильные потакта опережения данных перед nDOUT, но снижает Fmax проекта. Поскольку для синтеза ветка Async не является основным проектом, на Fmax этой ветки можно подзабить. Пока это исправление в релиз не внесено (хотя тест 401 уже прошло). Для Wsync ничего не меняется, там Fmax > 100MГц остается.

1. Вычисление qreg по P-фронту имеет смысл.
2. Вычисление qreg по N-фронту имеет смысл.

В исправленной версии qreg изменяется только по фронту clk_p, тут имеет смысл только eval_p();
В неисправленной (предыдущей) версии qreg изменяется только по фронту clk_n, тут имеет смысл только eval_n();

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

Версия 1.4e
Внес изменения и потестировал Async/qreg, поправил тактовую в тестбенче, окончательно разложил файлы в каталоги согласно шаблона OpenCores - оно хоть и немного громоздко, но обладает самодокументируемостью.

[Patron]

теперь можно перейти в каталог симуляции и запустить в ModelSim файл run.do

После запуска run.do шаг симуляции устанавливается в 100 ps - приходится каждый раз изменять его вручную на 500 ns.