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

Цитата:

---

Сообщение от Patron

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

---

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

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

http://pic.pdp-11.ru/images/dia01.png

[свернуть]

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

Цитата:

---

Сообщение от Vslav

обновление 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

---

Цитата:

---

Сообщение от Patron

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

---

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

Цитата:

---

Сообщение от Vslav

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

---

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

http://pic.pdp-11.ru/images/msim9.png

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

Цитата:

---

Сообщение от Vslav

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

---

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

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

Цитата:

---

Сообщение от Patron

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

---

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

Цитата:

---

Сообщение от Vslav

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

---

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

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

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

Цитата:

---

Сообщение от Patron

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

---

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

Цитата:

---

Сообщение от Patron

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

---

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

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

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

Цитата:

---

Сообщение от Vslav

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

---

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

http://pic.pdp-11.ru/images/msim10.png