Просмотр полной версии : Чем отличались КА1515ХМ1-031 и 1515ХМ2-001?
А тыкать многотысячевентеливые ПЛМ в схему проще? Могли бы из них кусочек использовать.
Та же 1515ХМ1-031 имеет вывод 25, называемый AR, и не используемый в УКНЦ. Возможно хотели, но что-то не срослось.
Та же 1515ХМ1-031 имеет вывод 25, называемый AR, и не используемый в УКНЦ. Возможно хотели, но что-то не срослось.
Для чего он?
Для чего он?
Каков вопрос, таков и ответ. Titus, неужто Вы думаете у меня есть информация по всем этим БМК, а я на ней сижу и никому не даю.
Каков вопрос, таков и ответ. Titus, неужто Вы думаете у меня есть информация по всем этим БМК, а я на ней сижу и никому не даю.
Ну может быть раскопали)
---------- Post added at 17:33 ---------- Previous post was at 17:31 ----------
По хорошему, надо бы уговорить нашего друга Феликса сфотать кристал крупненько, и срисовать его.
Только так выяснится все досканально.
Ну может быть раскопали)
Могу предполагать только по названию. У процессора есть вход AR - подтверждение приема адреса по SYNC, да и тут AR называется... Ассоциации однако.
---------- Post added at 17:37 ---------- Previous post was at 17:33 ----------
По хорошему, надо бы уговорить нашего друга Феликса сфотать кристал крупненько, и срисовать его.
Только так выяснится все досканально.
Все БМК 1515ХМ1 на одно лицо, имеется ввиду по библиотеке логических элементов. Разный в разных прошивках только последний слой металлизации, соединяющий эти логические элементы. Естественно понятно, что таким образом БМК на полную катушку не использовать, где-то останутся невостребованные элементы, где-то может нельзя соединить нужные элементы из-за пересечения проводников.
Все БМК 1515ХМ1 на одно лицо, имеется ввиду по библиотеке логических элементов. Разный в разных прошивках только последний слой металлизации, соединяющий эти логические элементы.
Вот этот слой метализации и сфоткать.
---------- Post added at 18:19 ---------- Previous post was at 17:39 ----------
По поводу этих глюков сказать ничего не могу, нет исходного текста, не видно как делается.
Вот отрывок кода, который тестирует:
GetDump:
MOVB #6,@#TMRSTATE ;0x06-> TMRSTATE (остановить таймер, шаг 16мкс)
MOV #99,@#TMRBUF ;99 -> TMRBUF (записать значение в буферный регистр)
MOV PC,R1 ;R1 = Buffer (PPU)
ADD #Buffer-.,R1 ;
MOV #TMRCURR,R0 ;R0 - TMRCURR
MOV #5,R2 ;R2 = 5
MOV #7,@#TMRSTATE ;Запустить таймер
1$: CMP R2,(R0) ;Ждем появления в регистре значения
BNE 1$ ;числа 5
MOV (R0),(R1)+ ;64 такта / команду (100 тактов шаг таймера)
MOV (R0),(R1)+ ;блок 8 * 64 = 512 тактов (~5 шагов таймера)
MOV (R0),(R1)+
MOV (R0),(R1)+
MOV (R0),(R1)+
MOV (R0),(R1)+
MOV (R0),(R1)+
MOV (R0),(R1)+
Перед вызовом прерывания запрещены вообще.
Как видно, в буферный регистр заносится число 99, затем таймер запускается, ждется число 5 в регистре текущего значения, и начинается протоколирование в память, где оказывается соответственно 5, 4, 3, 2, 1, 0, 98, 97 и т.д.
Так вот, иногда там оказывается 5, 4, 3, 2, 1, 0, 4095, 4094, что может означать ТОЛЬКО ОДНО, что число 99 НЕ прописалось в буферный регистр, а прописалось число 0. Иных вариантов предположить не могу.
Вот отрывок кода, который тестирует:
GetDump:
MOVB #6,@#TMRSTATE ;0x06-> TMRSTATE (остановить таймер, шаг 16мкс)
MOV #99,@#TMRBUF ;99 -> TMRBUF (записать значение в буферный регистр)
Перед вызовом прерывания запрещены вообще.
Как видно, в буферный регистр заносится число 99, затем таймер запускается, ждется число 5 в регистре текущего значения, и начинается протоколирование в память, где оказывается соответственно 5, 4, 3, 2, 1, 0, 98, 97 и т.д.
Так вот, иногда там оказывается 5, 4, 3, 2, 1, 0, 4095, 4094, что может означать ТОЛЬКО ОДНО, что число 99 НЕ прописалось в буферный регистр, а прописалось число 0. Иных вариантов предположить не могу.
А если в коде переменить две строчки:
GetDump:
MOV #99,@#TMRBUF ;99 -> TMRBUF (записать значение в буферный регистр)
MOVB #6,@#TMRSTATE ;0x06-> TMRSTATE (остановить таймер, шаг 16мкс)
А если в коде переменить две строчки:
Это не играет роли, т.к. в буферный регистр число должно записываться по-любому. Да и сложно проверить, т.к. поймать эту ситуацию вообще очень сложно.
Это не играет роли, т.к. в буферный регистр число должно записываться по-любому. Да и сложно проверить, т.к. поймать эту ситуацию вообще очень сложно.
А как же вероятность незаписи буферного регистра в счетчик? Проценты-то вон какие получаются.
А как же вероятность незаписи буферного регистра в счетчик? Проценты-то вон какие получаются.
Незапись при прямой загрузки намеренно КОРОТКИМ импульсом 36-40 тактов. А при переполнении таймера, из буферного регистра в счетчик загрузится автоматом по такту предделителя.
Я требую продолжения банкета !
(C) И.о.царя Бунша И.В.
На сцену выходит УКНЦ КВАНТ литеры 7 с 1515ХМ2-001.
Загрузка на холодную с дисковода:
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR01.jpg
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR02.jpg
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR03.jpg
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR04.jpg
Перезагрузили с дисковода по кнопке СБРОС:
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR05.jpg
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR06.jpg
Выключили. Включили. Снова загрузка с дисковода:
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR07.jpg
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR08.jpg
Загрузили с IDE-Flash:
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR09.jpg
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR10.jpg
Перезагрузили с IDE-Flash по кнопке СБРОС:
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR11.jpg
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR12.jpg
Уже нагрелись, уже горячие. Выключили. Включили. Загрузка с IDE-Flash:
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR13.jpg
http://kisly-alexey.pisem.net/TSTMR3/XM2/TSTMR14.jpg
Ну, в общем, все правильно, ничего нового)
Итак, обновленная версия теста таймера с новыми возможностями!
Теперь он тестирует ошибку записи в буферный регистр. Причем пишет два числа в процентах. Первое - это сколько процентов записей в буферный регистр в последствии прочлись, как ноль. Второе - сколько записей в буферный регистр в последствии прочлись, как мусор (и в скобках все сложенные мусорные числа по OR).
В общем, подтвердилась теория, что чип 1-031 у нас глючный :v2_conf2:
Т.е. при записи в буферный регистр она всегда проходит (предыдущее число там никогда не остается), но в итоге записываемое новое число может быть потеряно и вместо него может быть записан либо ноль, либо неизвестного типа мусор.
Обязательно тестируем на чипе 2-001, и выкладываем результаты.
Замечу, что даже на 1-031 результаты могут быть разные, и даже быть одни нули. Так что тестируем много раз.
p.s.: Не исключено, что глюк регистра текущего состояния тоже каким-то образом связан с ошибкой, но уже чтения.
http://s08.radikal.ru/i181/1302/72/d8964741ebf1.png
Итак, обновленная версия теста таймера с новыми возможностями!
Итак, обновленная версия на УКНЦ КВАНТ литеры 7 с 1515ХМ1-031.
Пока загрузился с дисковода, УКНЦ уже очень горячая:
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/TSTMR01.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/TSTMR02.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/TSTMR03.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/TSTMR04.jpg
Надо бы исходники теста, а то делаем как слепые котята, а что делаем - не понимаем.
Надо бы исходники теста, а то делаем как слепые котята, а что делаем - не понимаем.
Я же все подробно обьясняю, что в нем к чему)
Надо его сперва довести до ума.
А эти вероятности незаписи в буферный регистр часто возникают, или один раз из тысячи?
А эти вероятности незаписи в буферный регистр часто возникают, или один раз из тысячи?
Делается 1000 измерений, и если, скажем 150 из них ошибка, то результат 15.0%.
А если имеется в виду в конкретном запуске теста, то зависит так же, как и предыдущие вероятности от фазы тактирования при ресете компьютера.
Делается 1000 измерений, и если, скажем 150 из них ошибка, то результат 15.0%.
Я имел ввиду TSTMR сколько раз надо запускать, чтобы такое получить?
---------- Post added at 23:51 ---------- Previous post was at 23:34 ----------
Ну вот, Titus похоже будет доволен.
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/TSTMR05.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/TSTMR06.jpg
А вот теперь мои наблюдения. Вышеприведенная ситуация возникает только при первом включении (подачи напряжения) УКНЦ. Если УКНЦ сбросить кнопкой СБРОС, то ситуация нормализуется, как на приведенных еще выше четырех скриншотах.
Так что еще все дело может быть в инициализации чипа при включении питания, там напряжение повышается плавно, да еще идут сигналы DCLO и INIT, при сбросе напряжение уже стабильно, подаются только сигналы DCLO и INIT.
А вот теперь мои наблюдения. Вышеприведенная ситуация возникает только при первом включении (подачи напряжения) УКНЦ. Если УКНЦ сбросить кнопкой СБРОС, то ситуация нормализуется, как на приведенных еще выше четырех скриншотах.
Так что еще все дело может быть в инициализации чипа при включении питания, там напряжение повышается плавно, да еще идут сигналы DCLO и INIT, при сбросе напряжение уже стабильно, подаются только сигналы DCLO и INIT.
Да, результаты такие же, как и у меня, только число в скобках не плавает у меня, а всегда стабильно 3144.
Действительно, такой результат у меня только после включения питания)
Да, результаты такие же, как и у меня, только число в скобках не плавает у меня, а всегда стабильно 3144.
Действительно, такой результат у меня только после включения питания)
Число у меня тоже всегда стабильное, это просто скриншоты с загрузок с разных устройств, по промтеру RT-11 видно же.
Теперь надо посмотреть, будет ли такое на 2-001.
СЭМЗъ, слегка прогретый после попыток запустить TSPSPD :)
Ура. Т.е. не ура, но понятно, что на 2-001 тоже глючит запись в буферный регистр, причем более стабильно.
А нельзя ли позапускать этот тест, несколько раз, чередуя запуски сбросом по 'ресет'?
Получается, что в 2-001 исправили только неснятие бита готовности.
...
Интересно, что стабильный глюк только после ресетов, а после сброса его нет. Тогда как на других машинках (или с 1-031) наоборот.
1. при запуске TSTMR после вывода строки "Тест работы таймера УКНЦ v0.1d (c) by dr.Titus" курсор на какое-то время замирает (перестает мигать)
2. после тестов power_on (первого нажатия reset) два или три раза тест зависал после вывода строки "Тест работы таймера УКНЦ v0.1d (c) by dr.Titus". При этом как минимум раз курсор на экране не отображался (пропал)
Такие дела...
1. То, что курсор не мигает, это вполне возможно, т.к. он может выключаться системой.
2. То, что подвисает - это тоже возможно, т.к. в тесте до сих пор сохранилась циклическая конструкция типа:
а) записываем значение в буферный регистр
б) читаем значение из регистра текущего состояния
в) если не совпало, то идем на пункт а.
И, возможно, на данной машинке ее цикл кратен периоду работы предделителя, таким образом она может попасть в вечный цикл.
Titus, а можете допилить ещё два теста? :) Нужно:
Тест 1
1. Прочитать порт 177704, запомнить что прочитали
2. Записать в порт 177704 абракадабру, что-то вроде 0xF05A
3. Установить разряд 8 порта 177700 в 1
4. Снова прочитать порт 177704, запомнить что прочитали
5. Установить разряд 8 порта 177700 в 0
6. Повторить пункты 3-5
7. напечатать три сохраненных слова
Тест 2
В течении допустим десяти секунд считывать значение порта 177704 и делать OR и AND с предыдущим результатом, потом вывести два получившихся слова.
Тест клавиатуры? Каково его назначение?
В принципе, исходник теста я выкладывал (теста скорости), можете и сами сделать)
Тест 1 - проверить сохраняется ли содержимое регистра 177704 после вывода в линии Y и можно ли прочитать состояние линий Y когда на ним подключены выходы регистра 177704.
Тест 1 по быстренькому склепал.
Второй можешь и сам на основе него сделать.
Добрался наконец-то до УКНЦ КВАНТ литеры 7 с 1515ХМ2-001. Тест TSTMR.
Загрузка на холодную с дисковода:
http://kisly-alexey.pisem.net/TSTMR4/XM2/TSTMR01.jpg
Далее перезагрузки при нажатии СБРОС, загрузка с дисковода:
http://kisly-alexey.pisem.net/TSTMR4/XM2/TSTMR02.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM2/TSTMR03.jpg
Нагрев ни на что не влияет. При включении картина, как на первом скриншоте, при перезагрузках по СБРОСу немного скачут проценты, но картина в общем плане остается такой же.
---------- Post added at 20:26 ---------- Previous post was at 20:09 ----------
Продолжение эпопеи с УКНЦ КВАНТ литеры 7 с 1515ХМ2-001. Тест TSTMR.
Загрузка после включения питания с IDE-Flash:
http://kisly-alexey.pisem.net/TSTMR4/XM2/TSTMR04.jpg
Далее перезагрузки при нажатии СБРОС, загрузка с IDE-Flash:
http://kisly-alexey.pisem.net/TSTMR4/XM2/TSTMR05.jpg
После долгих перезагрузок по СБРОСу удалось поймать ситуацию, как после включения питания:
http://kisly-alexey.pisem.net/TSTMR4/XM2/TSTMR06.jpg
И что удивительно, что получаемое число по XOR одинаковое для разных УКНЦ, но разное в зависимости от того, откуда загрузились. Загадка однако.
И что удивительно, что получаемое число по XOR одинаковое для разных УКНЦ, но разное в зависимости от того, откуда загрузились. Загадка однако.
По OR оно получается.
Не знаю, откуда берется оно в буферном регистре, загадка. Может порождение каких-то иных глюков, но предположений у меня нет.
Т.к. последовательность теста такова:
1) Остановили таймер
2) Записали в буферный регистр число 1000
3) Подождали, прочитали из регистра текущего значения
4) Если ноль, то добавляем к первой группе процентов
5) Если не 1000, но и не ноль, то добавляем к второй группе процентов, и суммируем по OR все неправильно прочитавшиеся числа.
6) Записываем в буферный регистр число 2000
7) И идем на пункт 3.
И так по кругу, то 1000, то 2000, и каждый раз проверяем оно ли читается. Еще можно списать чтение нуля на то, что заблокирован регистр текущего состояния (хотя не должен, т.к. применяются методы для его разблокировки), но ЛЕВЫЕ числа уж никак не могут попасть в таймер случайно, тем более, что он стоит, а не считает.
По OR оно получается.
Не знаю, откуда берется оно в буферном регистре, загадка.
Надо бы узнать, какие числа были, а какие должны быть.
И что удивительно, что получаемое число по XOR одинаковое для разных УКНЦ, но разное в зависимости от того, откуда загрузились. Загадка однако.
По OR оно получается.
Не знаю, откуда берется оно в буферном регистре, загадка. Может порождение каких-то иных глюков, но предположений у меня нет.
Надо бы узнать, какие числа были, а какие должны быть.
Ну вот решил поделать тесты с таймером и узнать, почему получаются левые числа и какова их закономерность. Вроде бы удалось это понять. Но сначала несколько скриншотов для последующего объяснения ситуации.
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR1/SCR01.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR1/SCR02.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR1/SCR03.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR1/SCR04.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR1/SCR05.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR1/SCR06.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR1/SCR07.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR1/SCR08.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR1/SCR09.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR1/SCR10.jpg
Titus, ну что могу сказать. Вы оказались правы насчет записи и чтения регистров таймера. По поводу привязки этих событий к тактам делителя информация подтвердилась. На скриншотах видно, что обычно ошибки бывают только на 8 и 16 мкс, т.к. в данном варианте между импульсами после делителя проскакивает 50 и 100 тактов процессора соответственно. Ну а теперь начнем анализ ситуации. Процессор, как известно, выставляет на шине данные для записи и сопровождает это сигналом DOUT. В ответ на этот сигнал, устройство должно записать данные в свой регистр и выдать сигнал RPLY. В ответ на RPLY процессор снимает сигнал DOUT и данные с магистрали. Соответственно устройство снимает RPLY, а процессор SYNC, всё, адресный обмен завершился. Ну а теперь предположим, что интерфейс связи с QBUS в БМК работает нормально, а вот запись в буферный регистр производится по сигналам с делителя. Что при этом может произойти? Правильно, процессор завершает адресный обмен, приготавливается к очередному, шина адреса-данных будет в третьем состоянии, читаться с нее будет ноль - вот и ноль в буферном регистре. Но ситуация может ухудшиться и процессор уже выставил новый адрес на шине - значит в буфер запишется новый адрес.
Посмотрим внимательно на скриншоты. Для вывода содержимого ОЗУ ПП используется утилита PMEM, которая показывает размер блока данных памяти, занимаемой резидентом, для полного объема надо прибавить шесть (размер заголовка). Загрузка произведена с IDE-Flash и резидентом у нас сидит только драйвер WD. Левое число равно 3598. Загрузим модуль KBS, его объем 144+6=150 байт, левое число стало 3748=3598+150. Загрузим модуль ALTNUM, его объем 192+6=198 байт, левое число стало 3946=3748+198. Загрузим модуль RBTRON, его объем 102+6=108 байт, левое число стало 4054=3946+108. Загрузим модуль ESCFG, его объем 490+6=496 байт, левое число должно стать 4550=4054+496, но буфер 12-разрядный, вычитаем 4096, получаем 454.
Вроде бы все сходится, но на 8 мкс иногда проскакивает постоянное значение 976, в восьмеричном это 001720, либо это код команды, либо смещение, кода нет, не могу сказать.
Как видно на 4 мкс и 2 мкс ошибок нет. Отсюда вывод - останавливать таймер только на 2 мкс и записывать новое значение в буфер, должно обязательно записаться.
А так для полного анализа нужен ассемблерный листинг, именно листинг MACRO с восьмеричными значениями и мнемониками команд, хотя бы для того, чтобы узнать откуда у 001720 ноги растут.
Ну а теперь предположим, что интерфейс связи с QBUS в БМК работает нормально, а вот запись в буферный регистр производится по сигналам с делителя. Что при этом может произойти? Правильно, процессор завершает адресный обмен, приготавливается к очередному, шина адреса-данных будет в третьем состоянии, читаться с нее будет ноль - вот и ноль в буферном регистре. Но ситуация может ухудшиться и процессор уже выставил новый адрес на шине - значит в буфер запишется новый адрес.
Как может завершиться обмен, пока таймер не выставил сигнал RPLY? А выдать его он должен только после защелкивания результата в своем регистре по такту предделителя, если уж на то пошло.
Как может завершиться обмен, пока таймер не выставил сигнал RPLY? А выдать его он должен только после защелкивания результата в своем регистре по такту предделителя, если уж на то пошло.
А вот получается так, что сигнал RPLY по всей видимости выдает часть схемы, ответственная за обмен с шиной QBUS, а защелкивается по сигналу с делителя, но данные беруться с шины адреса-данных.
А вот получается так, что сигнал RPLY по всей видимости выдает часть схемы, ответственная за обмен с шиной QBUS, а защелкивается по сигналу с делителя, но данные беруться с шины адреса-данных.
Это было бы очень грубой ошибкой.
Да и если бы было так, то на периодах 16мкс (96 тактов), сбоили бы 23 из 24 записей, т.к. цикл шины весьма мал, скажем 4 такта, и если бы таймер мог воспринимать информацию на шине всего лишь раз в 96 тактов (по такту с предделителя), почти все записи улетали бы мимо.
Тут явно глюк другого плана.
Это было бы очень грубой ошибкой.
Да и если бы было так, то на периодах 16мкс (96 тактов), сбоили бы 23 из 24 записей, т.к. цикл шины весьма мал, скажем 4 такта, и если бы таймер мог воспринимать информацию на шине всего лишь раз в 96 тактов (по такту с предделителя), почти все записи улетали бы мимо.
Тут явно глюк другого плана.
Вот какой глюк и какого плана надо думать. С разрешения Titus-а воспользовался его исходником теста и получил листинг. Доказательства насчет адреса.
Первоначально адрес загрузки в ОЗУ ПП неизвестен, поэтому п/п пользователя может быть загружена по любому адресу, но с помощью утилиты PMEM можно определить адрес загрузки. Сперва, когда был загружен только драйвер WD, свободная область начиналась с адреса 024566, прибавим размер заголовка в 6 байт, получим 024574. Так глючное число в этом случае было равно 3598, или 07016 в восьмеричном представлении. Так как счетчик в программируемом таймере 12-разрядный, то уместно предположить, что это часть адреса, и предположительно, с учетом начального адреса загрузки полный адрес будет равен 027016. Разница между ними составляет 027016-024574=02222.
Теперь глянем на листинг, вот начало программы, загружаемой в ОЗУ ПП:
707 ;================================================= ==================================
708 ;
709 ; nA^ALO PEREME]AEMOJ OBLASTI
710 ;
711 ;================================================= ==================================
712 002340 PPUTBeg:
713
714 ;================================================= ==================================
715 ;
716 ; fUNKCIQ TESTIROWANIQ SKOROSTI RABOTY TAJMERA
717 ;
718 ; wYHODNYE DANNYE: PSTATE - ZNA^ENIE TAJMERA
719 ;
720 ;================================================= ==================================
721 002340 SPDPPU:
722 002340 106427 000340 MTPS #^O340 ;zAPRETITX PRERYWANIQ
723
Как видно при трансляции она получила адрес 02340. Прибавим к нему полученное ранее значение 02222, получается 04562. Глянем в листинг:
1373 ;===============================================
1374 004550 TBErrProc:
1375 004550 010701 MOV PC,R1 ;R1 = TEMP2
1376 004552 062701 000310 ADD #TEMP2-.,R1 ;
1377 004556 011137 177712 MOV (R1),@#TMRBUF ;(TEMP2) -> TMRBUF
1378
1379 004562 011010 MOV (R0),(R0) ;pAUZA >= 480 TAKTOW
1380 004564 011010 MOV (R0),(R0) ;(DLQ TO^NOJ ZAPISI BUFERNOGO REGISTRA
1381 004566 011010 MOV (R0),(R0) ;W S^ET^IK)
1382 004570 011010 MOV (R0),(R0) ;
1383 004572 011010 MOV (R0),(R0) ;
1384 004574 011010 MOV (R0),(R0) ;
1385 004576 011010 MOV (R0),(R0) ;
1386 004600 011010 MOV (R0),(R0) ;
1387
1388 004602 012701 177714 MOV #TMRCURR,R1 ;tO^NOE ^TENIE REGISTRA TEKU]EGO ZNA^ENIQ
1389 004606 011100 MOV (R1),R0 ;TAJMERA S RAZBLOKIROWKOJ
1390 004610 051100 BIS (R1),R0 ;R0 - REGISTR TEKU]EGO ZNA^ENIQ
1391 004612 010000 MOV R0,R0 ;
1392 004614 051100 BIS (R1),R0 ;
1393 004616 051100 BIS (R1),R0 ;
1394 004620 010000 MOV R0,R0 ;
1395 004622 051100 BIS (R1),R0 ;
1396 004624 051100 BIS (R1),R0 ;
1397 004626 010000 MOV R0,R0 ;
1398 004630 051100 BIS (R1),R0 ;
1399
1400 004632 010701 MOV PC,R1 ;R1 = TEMP2
1401 004634 062701 000226 ADD #TEMP2-.,R1 ;
1402
1403 004640 005700 TST R0 ;
1404 004642 001002 BNE 1$ ;
1405 004644 005215 INC (R5) ;eSLI R0 = 0, TO PRIRA]IWAEM S^ET^IK NULEJ
1406 004646 000406 BR 2$ ;--> 2$
1407
1408 004650 1$:
1409 004650 021100 CMP (R1),R0 ;eSLI R0 <> (TEMP2), TO
1410 004652 001404 BEQ 2$ ;PRIRA]IWAEM ^ISLO PROMAHOW
1411 004654 005265 000002 INC 2(R5) ;
1412
1413 004660 050065 000004 BIS R0,4(R5) ;zAPISYWAEM S^ITANNOE ^ISLO W PAMQTX PO OR
1414 004664 2$:
1415
1416 004664 011100 MOV (R1),R0 ;(R1) <-> (R1 + 2)
1417 004666 016111 000002 MOV 2(R1),(R1) ;(OBMENQTX MESTAMI KONSTANTY PROWERKI)
1418 004672 010061 000002 MOV R0,2(R1) ;
1419
1420 004676 000207 RETURN
Здесь как раз та самая подпрограмма, которая проверяет вероятность незаписи в буферный регистр. Как раз по адресу 04562 находится следующая команда, которая следует за командой MOV (R1),@#TMRBUF, осуществляющей запись в буферный регистр. Как ведет себя процессор при исполнении этой команды. Т.к. предыдущая команда состоит из двух слов, поэтому условие предвыборки нарушено. Процессор по адресу 027012 читает код команды 011137. Во время ее дешифрации читается следующее слово из памяти по предвыборке - адрес 027014, значение 177712. Во время дешифрации читается значение из памяти по значению регистра R1, это источник. Далее по адресу 027014 у нас уже прочитано значение 177712, по этому адресу происходит запись, это приемник. Т.к. предвыборка нарушена, то процессору остается выставить на шину адрес 027016 для чтения следующей команды. Вот это значение иногда и попадает в буферный регистр.
Попадающее иногда значение 976 при 4 мкс я пока объяснить не могу, ясно, что это не адрес, т.к. оно постоянно, вне зависимости от того, сколько загружено резидентов в ОЗУ ПП. Единственно, что могу предположить, это то, что процессор в это время снимает собственно данные с шины, а снятие немного проходит неравномерно, то часть битов становится битами данных, а часть нулями. Пока только так.
Жду комментариев и критики.
Т.к. предыдущая команда состоит из двух слов, поэтому условие предвыборки нарушено. Процессор по адресу 027012 читает код команды 011137. Во время ее дешифрации читается следующее слово из памяти по предвыборке - адрес 027014, значение 177712. Во время дешифрации читается значение из памяти по значению регистра R1, это источник. Далее по адресу 027014 у нас уже прочитано значение 177712, по этому адресу происходит запись, это приемник. Т.к. предвыборка нарушена, то процессору остается выставить на шину адрес 027016 для чтения следующей команды. Вот это значение иногда и попадает в буферный регистр.
Учитывая предвыборку кода команды, которая работает всегда, кроме функций ветвления и самомодификации кода, можно предположить несколько иную последовательность на начало выполнения команды
011137 177712 MOV (R1),@#TMRBUF
1) 011137 уже находится в буфере предвыборки, поэтому первая ступень - это дешифрация кода команды и предвыборка следующего слова из памяти 177712
2) Слово смещения читается из буфера предвыборки и идет вычисление исполнительного адреса
3) Тут сложно сказать, идет ли предвыборка следующего слова из адреса 4562, и потом выполняется команда, либо же сперва команда, а потом уже чтение кода следующей команды с адреса 4562. Надо почитать доки.
До сих пор остается открытым вопрос поднятый мною в предыдущем посте.
Учитывая предвыборку кода команды, которая работает всегда, кроме функций ветвления и самомодификации кода, можно предположить несколько иную последовательность на начало выполнения команды
011137 177712 MOV (R1),@#TMRBUF
1) 011137 уже находится в буфере предвыборки, поэтому первая ступень - это дешифрация кода команды и предвыборка следующего слова из памяти 177712
2) Слово смещения читается из буфера предвыборки и идет вычисление исполнительного адреса
3) Тут сложно сказать, идет ли предвыборка следующего слова из адреса 4562, и потом выполняется команда, либо же сперва команда, а потом уже чтение кода следующей команды с адреса 4562. Надо почитать доки.
Предвыборка на следующую команду работает если только предыдущая команда состояла из одного слова, т.е. не было модификации одно из счетчиков команд (а теперь из документации мы знаем, что их целых три), естественно это не команда перехода и не было модификации адреса, прочитанного по предвыборке. А так как команды состояли из двух слов, то предвыборка на следующую команду и не работала. Это еще было показано мной при тесте регистра ловушки адреса при использовании команд, состоящих из одного и нескольких слов.
До сих пор остается открытым вопрос поднятый мною в предыдущем посте.
Вопрос, насколько я понимаю, почему попадает не то что пишется, а другое? Что это другое, это вроде выяснили. Теперь остается понять почему запись происходит в этот момент.
Кстати а вероятность незаписи регистра состояния и управления 0177710 вроде не проверялась? Вдруг там делитель не прописывается или режим ПУСК не запускается?
Кстати а вероятность незаписи регистра состояния и управления 0177710 вроде не проверялась? Вдруг там делитель не прописывается или режим ПУСК не запускается?
Думаю, что он всегда работает исправно, т.к. никогда случайно замечен в этом не был, в отличие от других регистров.
Да и специфика у него иная, при которой его нелогично было бы тактировать способом, подобным буферному регистру и регистру текущего значения. Это как бы управляющий регистр, стоящий над ними.
---------- Post added at 00:13 ---------- Previous post was at 00:11 ----------
Попадающее иногда значение 976 при 4 мкс я пока объяснить не могу, ясно, что это не адрес, т.к. оно постоянно, вне зависимости от того, сколько загружено резидентов в ОЗУ ПП. Единственно, что могу предположить, это то, что процессор в это время снимает собственно данные с шины, а снятие немного проходит неравномерно, то часть битов становится битами данных, а часть нулями.
Если б это было из-за пограничного значения между неуспеванием одного, и успеванием другого, оно бы не было так стабильно.
Кстати, надо заметить, что все значения складываются по OR, следовательно это вполне может быть логической суммой каких-либо чисел.
Если б это было из-за пограничного значения между неуспеванием одного, и успеванием другого, оно бы не было так стабильно.
Кстати, надо заметить, что все значения складываются по OR, следовательно это вполне может быть логической суммой каких-либо чисел.
Кстати для информации - 1515ХМ1-031(да и 1515ХМ2-001) расположены за буфером 1801ВП1-055, так что задержки на линии есть, и обычно они постоянны. Если бы задержки были непостоянны, то числа получались бы разными, а тут все время одно и тоже число. С адресом-то понятно, по мере загрузки резидентов число менялось и менялось на размер загруженного резидента. А вот здесь неясно. Можно 0177777 позаписывать, посмотреть, чего получится.
Думаю, что он всегда работает исправно, т.к. никогда случайно замечен в этом не был, в отличие от других регистров.
Да и специфика у него иная, при которой его нелогично было бы тактировать способом, подобным буферному регистру и регистру текущего значения. Это как бы управляющий регистр, стоящий над ними.
Еще почему считаю его нормально работающим, т.к. в тесте незаписи буферного регистра в счетчик по короткому импульсу, на периодах 8 и 16мкс все четко подтверждает теорию четкой работы системного регистра, и тактовой работы перезаписи буферного регистра в счетчик. Если б это было иначе, числа бы тоже плавали в очень большом диапазоне, так же, как и в тестах буферного регистра.
Включил холодную УКНЦ КВАНТ литеры 7 с 1515ХМ1-031, позапускал тест таймера. Вероятность незаписи в буферный регистр на 4 мкс стала скакать, на 8 мкс оставалась постоянной (как и было описано ранее).
Скриншоты прилагаются:
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR2/SCR01.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR2/SCR02.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR2/SCR03.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR2/SCR04.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR2/SCR05.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR2/SCR06.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR2/SCR07.jpg
http://kisly-alexey.pisem.net/TSTMR4/XM1-7/ERR2/SCR08.jpg
3) Флаг нуля счетчика формируется по отрицательному фронту PCLK, если в РЕГИСТРЕ ТЕКУЩЕГО ЗНАЧЕНИЯ, а не в счетчике содержится ноль, не зависимо от режима пуск/стоп. Таким образом можно получить счет от нуля до нуля без переполнения, т.к. пройдя счетчик мы сразу получим значение 0xFFF.
4) Если в регистре текущего значения в режиме останова находится число 0, то он будет блокироваться вновь и вновь по фронту PCLK, независимо от содержимого счетчика. Таким образом, чтение регистра текущего значения совпавшее с очередным фронтом PCLK, мешает разблокировке регистра текущего значения, с вероятностью тем большей, чем меньше период PCLK.
В свете новых тестов несколько изменил теорерическую подоплеку работы регистра текущего значения.
1) Флаг нуля счетчика формируется все же если в регистре счетчика ноль, а не в регистре текущего значения. А вся путаница происходит из-за того, что периодически некорректно выполняется чтение из регистра текущего значения. А именно:
а) Иногда из регистра текущего значения считывается не текущее, а предыдущее значение счетчика, т.к. некоторые значения подолгу задерживаются в регистре текущего значения. Причем, чем больше период таймера, тем этот эффект проявляется сильнее. Кроме того, даже на малых периодах (2мкс) в районе переходного момента 0->BUF, так же иногда идет застревание предыдущего числа в регистре текущего значения.
б) Так же схема разблокировки регистра текущего значения не всегда получает импульс разблокировки (формируемый чтением из регистра), таким образом регистр остается заблокированным, хотя значение из него читается (возможно, так же предыдущее, но т.к. предыдущее тоже ноль, определить сложно).
Эти предположения появились в свете того, что предыдущая теория рассыплась в пух и прах, т.к. запись нуля из остановленного счетчика в регистр текущего значения должна была бы навечно его заблокировать до появления нового числа в буферном регистре, однако такое не происходит.
Тогда как при наличие явной ошибки записи в буферный регистр, логично предположить, что такого же типа ошибка, но уже по чтению, присутствует в регистре текущего значения.
Кажется, я раскрыл загадку таймера) Итак новая теория:
1. Программируемый предделитель находится не после делителя тактовой частоты на 12, а до него. Итого, после предделителя можем получить 4 программируемых частоты с периодами 1, 2, 4 и 8 тактов ПП, соответственно. Назовем этот сигнал PCLK.
2. Делитель на 12 на самом деле не совсем обычный делитель. Длительность его положительного импульса равна одному периоду PCLK. Назовем этот сигнал P12CLK.
http://s45.radikal.ru/i108/1302/78/913ee8a6ae74.png
3. Декремент счетчика происходит по фронту P12CLK.
4. Чтение из буферного регистра в счетчик происходит во время положительного импульса P12CLK. При этом невозможно одновременное чтение из буферного регистра счетчиком и запись в него процессором. Если эти циклы наложились друг на друга,
то запись откладывается до окончания цикла чтения, таким образом задерживаясь на 1, 2, 4 или 8 тактов, в зависимости от периода PCLK. Для периодов 2, 4 или 8 тактов, сопоставимых с циклом работы шины ПП (4 такта), возможно защелкивание данных, появившихся на шине спустя 2, 4 или 8 тактов, соответственно.
5. Запись информации из счетчика в регистр текущего значения на 1515ХМ1-031 происходит по положительному импульсу P12CLK. При этом невозможна одновременная запись в регистр текущего значения, и чтение его содержимого процессором. В результате, если цикл чтения процессором регистра текущего значения совпадет с импульсом записи значения таймера в этот регистр, запись значения таймера в регистр не пройдет, и мы прочитаем предыдущее, не изменившееся значение. Кроме того, так же не пройдет разблокировка регистра текущего значения, если он был заблокирован. Таким образом, чем чаще приходит положительный импульс P12CLK, тем выше вероятность прочтения предыдущего значения счетчика, а так же неразблокировки регистра текущего значения.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot