Чем отличались КА1515ХМ1-031 и 1515ХМ2-001?

Цитата:

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

И что удивительно, что получаемое число по XOR одинаковое для разных УКНЦ, но разное в зависимости от того, откуда загрузились. Загадка однако.

Цитата:

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

По OR оно получается.
Не знаю, откуда берется оно в буферном регистре, загадка. Может порождение каких-то иных глюков, но предположений у меня нет.

Цитата:

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

Надо бы узнать, какие числа были, а какие должны быть.

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

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

http://kisly-alexey.pisem.net/TSTMR4...ERR1/SCR01.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR1/SCR02.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR1/SCR03.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR1/SCR04.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR1/SCR05.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR1/SCR06.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR1/SCR07.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR1/SCR08.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR1/SCR09.jpg
http://kisly-alexey.pisem.net/TSTMR4...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 ноги растут.

Цитата:

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

Ну а теперь предположим, что интерфейс связи с QBUS в БМК работает нормально, а вот запись в буферный регистр производится по сигналам с делителя. Что при этом может произойти? Правильно, процессор завершает адресный обмен, приготавливается к очередному, шина адреса-данных будет в третьем состоянии, читаться с нее будет ноль - вот и ноль в буферном регистре. Но ситуация может ухудшиться и процессор уже выставил новый адрес на шине - значит в буфер запишется новый адрес.

Как может завершиться обмен, пока таймер не выставил сигнал RPLY? А выдать его он должен только после защелкивания результата в своем регистре по такту предделителя, если уж на то пошло.

Цитата:

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

Как может завершиться обмен, пока таймер не выставил сигнал RPLY? А выдать его он должен только после защелкивания результата в своем регистре по такту предделителя, если уж на то пошло.

А вот получается так, что сигнал RPLY по всей видимости выдает часть схемы, ответственная за обмен с шиной QBUS, а защелкивается по сигналу с делителя, но данные беруться с шины адреса-данных.

Цитата:

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

А вот получается так, что сигнал RPLY по всей видимости выдает часть схемы, ответственная за обмен с шиной QBUS, а защелкивается по сигналу с делителя, но данные беруться с шины адреса-данных.

Это было бы очень грубой ошибкой.
Да и если бы было так, то на периодах 16мкс (96 тактов), сбоили бы 23 из 24 записей, т.к. цикл шины весьма мал, скажем 4 такта, и если бы таймер мог воспринимать информацию на шине всего лишь раз в 96 тактов (по такту с предделителя), почти все записи улетали бы мимо.
Тут явно глюк другого плана.

Цитата:

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

Это было бы очень грубой ошибкой.
Да и если бы было так, то на периодах 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 мкс я пока объяснить не могу, ясно, что это не адрес, т.к. оно постоянно, вне зависимости от того, сколько загружено резидентов в ОЗУ ПП. Единственно, что могу предположить, это то, что процессор в это время снимает собственно данные с шины, а снятие немного проходит неравномерно, то часть битов становится битами данных, а часть нулями. Пока только так.

Жду комментариев и критики.

Цитата:

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

Т.к. предыдущая команда состоит из двух слов, поэтому условие предвыборки нарушено. Процессор по адресу 027012 читает код команды 011137. Во время ее дешифрации читается следующее слово из памяти по предвыборке - адрес 027014, значение 177712. Во время дешифрации читается значение из памяти по значению регистра R1, это источник. Далее по адресу 027014 у нас уже прочитано значение 177712, по этому адресу происходит запись, это приемник. Т.к. предвыборка нарушена, то процессору остается выставить на шину адрес 027016 для чтения следующей команды. Вот это значение иногда и попадает в буферный регистр.

Учитывая предвыборку кода команды, которая работает всегда, кроме функций ветвления и самомодификации кода, можно предположить несколько иную последовательность на начало выполнения команды

Код:

011137 177712 MOV (R1),@#TMRBUF

1) 011137 уже находится в буфере предвыборки, поэтому первая ступень - это дешифрация кода команды и предвыборка следующего слова из памяти 177712
2) Слово смещения читается из буфера предвыборки и идет вычисление исполнительного адреса
3) Тут сложно сказать, идет ли предвыборка следующего слова из адреса 4562, и потом выполняется команда, либо же сперва команда, а потом уже чтение кода следующей команды с адреса 4562. Надо почитать доки.

До сих пор остается открытым вопрос поднятый мною в предыдущем посте.

Цитата:

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

Учитывая предвыборку кода команды, которая работает всегда, кроме функций ветвления и самомодификации кода, можно предположить несколько иную последовательность на начало выполнения команды

Код:

011137 177712 MOV (R1),@#TMRBUF

1) 011137 уже находится в буфере предвыборки, поэтому первая ступень - это дешифрация кода команды и предвыборка следующего слова из памяти 177712
2) Слово смещения читается из буфера предвыборки и идет вычисление исполнительного адреса
3) Тут сложно сказать, идет ли предвыборка следующего слова из адреса 4562, и потом выполняется команда, либо же сперва команда, а потом уже чтение кода следующей команды с адреса 4562. Надо почитать доки.

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

Цитата:

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

До сих пор остается открытым вопрос поднятый мною в предыдущем посте.

Вопрос, насколько я понимаю, почему попадает не то что пишется, а другое? Что это другое, это вроде выяснили. Теперь остается понять почему запись происходит в этот момент.

Кстати а вероятность незаписи регистра состояния и управления 0177710 вроде не проверялась? Вдруг там делитель не прописывается или режим ПУСК не запускается?

Цитата:

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

Кстати а вероятность незаписи регистра состояния и управления 0177710 вроде не проверялась? Вдруг там делитель не прописывается или режим ПУСК не запускается?

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

---------- Post added at 00:13 ---------- Previous post was at 00:11 ----------

Цитата:

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

Попадающее иногда значение 976 при 4 мкс я пока объяснить не могу, ясно, что это не адрес, т.к. оно постоянно, вне зависимости от того, сколько загружено резидентов в ОЗУ ПП. Единственно, что могу предположить, это то, что процессор в это время снимает собственно данные с шины, а снятие немного проходит неравномерно, то часть битов становится битами данных, а часть нулями.

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

Цитата:

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

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

Кстати для информации - 1515ХМ1-031(да и 1515ХМ2-001) расположены за буфером 1801ВП1-055, так что задержки на линии есть, и обычно они постоянны. Если бы задержки были непостоянны, то числа получались бы разными, а тут все время одно и тоже число. С адресом-то понятно, по мере загрузки резидентов число менялось и менялось на размер загруженного резидента. А вот здесь неясно. Можно 0177777 позаписывать, посмотреть, чего получится.

Цитата:

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

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

Еще почему считаю его нормально работающим, т.к. в тесте незаписи буферного регистра в счетчик по короткому импульсу, на периодах 8 и 16мкс все четко подтверждает теорию четкой работы системного регистра, и тактовой работы перезаписи буферного регистра в счетчик. Если б это было иначе, числа бы тоже плавали в очень большом диапазоне, так же, как и в тестах буферного регистра.

Включил холодную УКНЦ КВАНТ литеры 7 с 1515ХМ1-031, позапускал тест таймера. Вероятность незаписи в буферный регистр на 4 мкс стала скакать, на 8 мкс оставалась постоянной (как и было описано ранее).
Скриншоты прилагаются:

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

http://kisly-alexey.pisem.net/TSTMR4...ERR2/SCR01.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR2/SCR02.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR2/SCR03.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR2/SCR04.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR2/SCR05.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR2/SCR06.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR2/SCR07.jpg
http://kisly-alexey.pisem.net/TSTMR4...ERR2/SCR08.jpg

[свернуть]

Цитата:

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

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, тем выше вероятность прочтения предыдущего значения счетчика, а так же неразблокировки регистра текущего значения.