Результаты сканирования шин Вектора

[KTSerg]

После сканирования шин Вектора на разъёме "ВУ", (графики сканов в другой теме):
https://zx-pk.ru/threads/22217-combo...=1#post1149543
пытался вычислить реальную частоту сканирования по полученным графикам сигналов, т.к. не сканировал ни какой несущей частоты, то вычислить не получалось.
В результате, завёл на сканер дополнительно частоту 6МГц, и по меандру подтвердились предполагаемые частоты сканирования 100МГц и 25МГц.

Сейчас немного размышлений о том, почему не получалось вычислить частоты по сигналам...
Я начал с предположения, что по длительности (количеству пикселей) между импульсами сигнала "Строб сост." (43 на ВУ) смогу измерить на графике длительности выполнения команд и по ним вычислить частоту...
Исходя из информации, что на Векторе длительность выполнения команд в тактах округляется до ближайшего значения кратного 4, ожидал, что команды PUSH, POP и JMP будут иметь на графике одинаковую длительность (в пикселях), т.к. PUSH и POP по справочнику выполняются 11 тактов, а JMP - 10 тактов, округляем до 12 тактов...
Но если POP и JMP длятся примерно 400 пикселей (на графике), то PUSH длится около 533 !!! и это даже не погрешность.
Далее, команды SHLD и LHLD по справочнику 16 тактов, на графике 668 пикселей.

Считаем для POP и JMP: 400(пикселей на графике) / 12(тактов по справочнику) = 33,33 пикселя/такт.
Для PUSH считаем в обратную сторону: 533(пикселя) / 33,33 = 16 тактов !!! а в справочнике 12 !!!
Для SHLD и LHLD: 668(пикселей) / 33,33 = 20 тактов !!! а в справочнике 16 !!!

Я в ауте... или у меня справочник кривой с ошибками и очепятками ?

[Advertiser]

[ivagor]

Округляется вверх до кратности 4 тактам не вся команда, а каждый ее цикл с доступом к памяти. Классическая справка по растактовкам для вектора в Вектор-User 15 (но там есть ошибки). svofski выкладывал у себя (все время забываю - где) исправленную таблицу. Есть такая таблица (надо проверить, исправленная или нет). Или такая, где расписано по циклам.

[KTSerg]

Округляется вверх до кратности 4 тактам не вся команда, а каждый ее цикл с доступом к памяти. ...

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

Отклоняясь от темы.

Скрытый текст

Снова сталкиваюсь с глюками. При минимальном изменении кода модуля для Альтеры, перестаёт корректно работать сканер. В данном случае ровно через один такт все 24 бита (или только 8 бит) имеют значение "0". Пока не выяснил сбрасываются они до записи в М9К, или коряво читаются, или ошибка появляется при передаче в комп.
Главное смущает, что к глюкам приводят изменения кода, которые вообще ни как не связаны с функциями сканера, процессами сканирования, чтения и передачи.
Главное, что с подобным уже сталкивался. Заподозрил, что глючит Альтера, купил новую плату, залил "глючный" код в новую плату, и на ней все глюки сразу пропали. Сейчас и эта плата похоже начала выёживаться...

[свернуть]

[ivagor]

Оффтоп про ПЛИС

При сравнительно высоких частотах проект может начать вести себя странно, начиная реагировать на изменения в казалось бы совершенно левых вещах. По хорошему надо пользоваться TimeQuestом.

[свернуть]

[HardWareMan]

Продолжаем про ПЛИС

Главное смущает, что к глюкам приводят изменения кода, которые вообще ни как не связаны с функциями сканера, процессами сканирования, чтения и передачи.

Следует подучить теорию по ПЛИС. В отличии от программы, где не изменённый код в исходниках не поменяется и в бинаре, синтезатор xHDL пересоберёт всё, на это наложится оптимизация и полирнётся фиттером. Т.е., результат будет полностью новым артефактом без единого куска от старого. Чтобы на это повлиять, можно задать, какому модулю в каком регионе ПЛИС находится и это может положительно повлиять как на характеристики модуля, так и на стабильность сборки. Так что правильно вам советуют: смотрите в TimeQuest, забивайте туда свои требования и выучите уже настоящий синхронный дизайн.

[свернуть]

[KTSerg]

На плату сопряжения допаял микросхем, расширил шину сканера до 36-ти бит.
Сейчас сканируется почти вся шина разъёма "ВУ". Не стал сканировать только один сигнал - "сбр.системы", т.к. это шина клавиши "СБР", и управлять сбросом Вектора со своего устройства я пока не собираюсь, а сброс Вектора можно отследить по сигналу "сброс" сформированному самим Вектором.
Девайс постепенно превращается из просто сканера, в борду для экспериментов с навесным оборудованием

Отсканил состояние сразу после перезапуска 02-го Вектора...
Как грустно, что шина данных "глушится" (FFh) на время активности сигнала "ЧТЗУ".
И пока нет активного "БЛК", на внешней шине не увидеть CAS. Хотя некоторые вроде-бы и без него пытались обойтись.

[KTSerg]

Не знаю в какую тему лучше кинуть, в эту или в тему про подключение внешнего ПЗУ к шине разъёма "ВУ".
Но пока ситуация больше касается шины чем непосредственно ПЗУ на этой шине.

Итак, на основе сканера шины, начал тестировать схему подключения внешнего ПЗУ к разъёму "ВУ".
Ни чего особенно сложного, схема простая.
Механизм активации ПЗУ решил сделать следующим:
1. "тумблером" разрешаем работу схемы внешнего ПЗУ.
2. на Векторе жмём ВВОД + БЛК - схема внешнего ПЗУ "сбрасывается" в режим ожидания, работает штатное ПЗУ с загрузчиком.
3. на Векторе жмём БЛК + СБР - Вектор отключает своё ПЗУ, активируется внешнее ПЗУ - выполняется программа с внешнего ПЗУ.
4. на Векторе жмём БЛК + СБР - внешнее ПЗУ отключается и деактивируется до следующего ВВОД + БЛК, выполняется программа из памяти Вектора.

Так подробно написал алгоритм работы внешнего ПЗУ, для того, чтобы было понятно, что работа схемы зависит от сигнала "сброс" приходящего с Вектора.
Так вот... целый вечер бился, не мог понять, почему внешняя ПЗУ сначала начинает работать, а потом отключается, всегда в одном и том-же месте (с точностью до семпла), когда адрес программы добирается до 0005h.
Но так и не понял.
Анализ показал, что ПЗУ отключается именно сигналом "сброс". Но сканер, при частоте семплирования 100МГц, так ни разу и не зафиксировал импульса в этот момент на сигнале "сброс".
Каюсь конечно, что на сканер все сигналы с шин "ВУ" приходят через цепочку регистров, а вот на "модуль" ПЗУ завёл сразу со входа основного модуля проекта.
Вылечилось конечно регистрами. Когда прокинул сигналы на "модуль" ПЗУ через цепочку регистров, то "внешнее ПЗУ" сразу заработало.

Меня вот мучают жуткие сомнения, не могу понять, что за "шум" был на сигнале "сброс", которого не видел сканер... приходил он с Вектора, с платы конвертора 5В->3.3В, или это Альтера "шумела".

Я читал про метастабильность (если правильно термин помню), что может быть не определённое состояние регистра при фиксации в нём значения.
Просто схема использования сигнала "сброс" не предусматривает явной фиксации его значения в регистре, если только Альтера чего-то не вставляет, чего её не просили.
Да и я понял бы "метастабильность" этого сигнала в момент перехода его значения из 1 в 0 или из 0 в 1 - т.е. во время собственно Сброса Вектора.
А тут, так сказать "на ровном месте", когда сбросом и не пахнет, при гипотетически стабильном состоянии сигнала...

Альтера подбрасывает очередной сюрприз...

PS. а с работой внешнего ПЗУ, не долго радовался... когда увидел, что внешнее ПЗУ работает, подключил параллельно свой "бутерброд" из КД+HDD... и внешнее ПЗУ перестало работать... отключил "бутерброд", а ПЗУ так и не работает...
Что там в таких случаях говорят: "- как же так, ни чего ведь не делал, просто в сторонке стоял...".
Буду дальше разбираться, о результатах уже в соответствующей теме.
Тут было про странный невидимый сканером "шум" на шине.

[ivagor]

svofski писал, что в лешадоке делал антидребезговую обработку для части (или для всех?) сигналов. Подробности лучше он сам расскажет.

[KTSerg]

svofski писал, что в лешадоке делал антидребезговую обработку для части (или для всех?) сигналов. Подробности лучше он сам расскажет.

Лешадок я когда-то изучал, возможно брожу по тем-же граблям.

[Sandro]

Так подробно написал алгоритм работы внешнего ПЗУ, для того, чтобы было понятно, что работа схемы зависит от сигнала "сброс" приходящего с Вектора.

А зря. Всё твое сообщение можно свести к фразе "у меня ничего не работает, почему -- не знаю". Вместо расписывания нужно было выложить исходники проекта. Без них ничего сказать нельзя.

Альтера подбрасывает очередной сюрприз...

Альтера 100% тут не виновата. Ищи ошибки в проекте.

PS: Как легко понять, мифический "шум" тут ни при чём. Цифровая схема либо работает, либо нет. Если не работает, то она либо неправильно спроектирована, либо неправильно собрана, либо в ней есть негодные компоненты. Вариантов немного.