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

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

Patron, делайте с исходниками что хотите и модифицируйте их как сочтёте необходимым. У меня как-то застопорился всякий прогресс в этом деле. Чтобы как-то двигаться дальше, мне необходимо минимум три модели, взаимодействующие между собой через МПИ, две есть: ВМ1 и ВП1-037 (на си пока не переведённая, т.к. простая и это не сложно сделать), а вот с третьей, которой я выбрал ВП1-065 до сих пор ничего не получается.

Цитата:

---

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

А для чего вообще нужно привязываться к неким константам в регистрах?

---

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

Цитата:

---

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

с третьей, которой я выбрал ВП1-065 до сих пор ничего не получается.

---

Предлагаю попробовать скомпилировать адаптер МПИ - исходники CPP-модели там лежат в оригинальном виде в их родном каталоге \MODULES\MPI_module\vm1cpu\.

Эмуляция последовательного порта в адаптере МПИ максимально точная - там можно даже (как в реальном порту) создавать фейковые посылки при помощи программного управления состоянием BREAK.

Решая проблему глюка RPLY, выяснил, что глюк проявляется, если RPLY меняет своё состояние в пределах одного (или 1,5) такта после изменения состояния DIN (по крайней мере DIN, может и с DOUT так же было).
После этого, заменил весь код, где используются reg [3:0] rply_ack кодом из модели Async и глюк пропал. Правда при этом SYNC стал сниматься на 1 такт позже, да и DIN держится на 1 такт дольше , зато теперь работа модели не зависит от фазы ТЧ и опроса периферии через такт или полтакта.
Вообще, заменённый код местами неожиданно отличается от кода в Qsync. Может быть при оптимизациях где-нибудь вкралась ошибка?
Вот что получилось Вложение 55166 код, приводивший удлинение на такт закомментирован, и оставлен тот, что из Qsync, более быстрый.

Цитата:

---

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

глюк проявляется, если RPLY меняет своё состояние в пределах одного (или 1,5) такта после изменения состояния DIN

---

Во всех версиях CPP-модели момент установки RPLY роли не играет - глюк зависит только от момента снятия RPLY. Даже при нулевой задержке снятия RPLY - выравнивание защищает от глюка.

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

Цитата:

---

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

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

---

ЗДЕСЬ утверждается, что в Verilog-версии модели Qsync момент снятия RPLY роли не играет.

Цитата:

---

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

Для моделей Qsync/Wsync проверка RPLY не имеет смысла (хотя Qsync тоже немного погонял, все нормально работает)

---

Как выяснилось - проблема именно в CPP-версии модели Qsync. Если деактивировать сигнал RPLY между eval_p и eval_n - модель не снимает SYNC вплоть до установки DCLO.

В Verilog-версии модели Qsync точно нет такой проблемы ?

Цитата:

---

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

В Verilog-версии модели Qsync точно нет такой проблемы ?

---

Ну... Если ModelSim не шутит, то в модели QSync такой проблемы нету :)
Еще раз снял диаграмму:
http://s005.radikal.ru/i209/1512/68/32c0fbdb0fbdt.jpg

Красным отмечено снятие RPLY при положительном значении CLC, через 2 нс после фронта.
RPLY снимает (и управляет всеми другими внешними сигналами) специальный модуль, называется testbench (файл tbench.v), пишется для тестовых целей и является внешним по отношению к модели. То есть для модели это выглядит как внешнее воздействие, внутри она никак не меняется при тестировании. Заводской тест 401 проходит при любых комбинациях снятия RPLY.

Там была другая проблема, при обращении к 1777хх были очень короткие импульсы DOUT - оно выходило по первому же RPLY, обнаруженному по фронту CLC. Это несовпадало с реальным процессором и я перекинул на второй RPLY на фронте CLC. Схему перепроверял на нескольких процессорах, она верная, поэтому списал на физическую задержку, то есть RPLY при обращении к внутренним регистрам не успевал на первый фронт CLC. Там есть коммент на тему:

Код:

---

assign dout_start = dout_req_rc & qbus_flag_rc & ~rply_ack[2]; // originally ~rply_ack[1]

---

Все остальные циклы - DATI/DATO/DATIO/IAK сначала сверялись на модели Async с реальным процессором. Было достигнуто потактовое совпадение. Потом прошел тест 401, при этом симулятор показывает сколько времени модели затрачено на прохождение теста, ну скажем 544520 нс.

Потом писалась модель Qsync, писалась она путем модификации Async, при этом на ней многократно в ходе разработки прогонялся тест 401 и сверялось в том числе затраченное время, оно должно полностью совпадать с моделью Async (544520нс). Ну и диаграммы тоже сравнивались, их длительности и моменты запуска полностью совпадали.

Потом уже делалась WSync модификацией QSync, там уже времянка немного разошлась, шина же другая, но встроен специальный механизм для медленного режима, при его работе моменты запуска транзакций будут полностью совпадать как это делал бы процессор на родной частоте (до 5МГц). Эта задумка написана, но еще не проверялась - она должна работать в связке с дульным компенсатором эмулятором-замедлителем ВП1-037, которого пока нету.

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

Давно не брал я в руки шашек смотрел в микроскоп :)
Пока игрался с модулем и перетыкал микропроцессоры, определился самый слаборазгоняемый экземпляр 1801ВМ3, к тому же у него ножки немножко в процессе покоцались, пришлось его на мясо пустить открыть.

http://s018.radikal.ru/i516/1512/0a/e4c73e289e53t.jpg

Кристалл незначительно больше по площади чем 1801ВМ1 (на 20-25 процентов), но транзисторов по прикидкам должно быть тысяч 25, значит нормы уменьшили. И действительно - 3 мкм ширина затвора и проводников. У ВМ1 было 5 мкм, у ВМ2 - 4 мкм. Не великий прогресс за 8 лет, но то такое. Стекло на кристалле грязноватое, попробую спиртиком помыть и отфотать на увеличении x10. Но уже мелковато, как бы не пришлось снимать на x20 (а это за 400 снимков выйдет), и у меня уже 16ГБ памяти такую панораму собрать не хватает.

Цитата:

---

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

Кристалл незначительно больше по площади чем 1801ВМ1 (на 20-25 процентов), но транзисторов по прикидкам должно быть тысяч 25, значит нормы уменьшили.

---

На картиночке качества несколько не хватает для понимания.
По сравнению со стройными рядами элементов в ХМ1, выглядит хаотично)

Цитата:

---

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

На картиночке качества несколько не хватает для понимания.

---

Дело не только в качестве, структура нерегулярная, нельзя выделить библиотеку ячеек. А чтобы можно было разобраться - надо шлифовать слой металла и снимать "диффузию", иначе неразбирабельно даже при очень-очень качественной картинке и бОльших проектных нормах (сужу по 580 и 581 сериям).

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

Цитата:

---

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

Как выяснилось - проблема именно в CPP-версии модели Qsync.

---

Ну, я никогда и не утверждал, что CPP модель достоверно работает, она наоборот, в силу каких-то неясных для меня нюансов работает не так, как Verilog модель, хотя казалось бы, всё сделано точь-в-точь как в верилоге.

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" в следующей итерации?