Raven

Это я понял. Но доступаться таким образом он может только до memory mapped ресурсов, да и то только туда, куда его ядро пустит. Обычно такие критические вещи, как поддержка отладки в ядре, делают на чем-то вроде CSRs, т.е., регистров, доступных только самому ядру (и конечно, с соответствующими привилегиями доступа). Может, конечно, в PPC470S они как-то отображены в адреса памяти, но есть законное сомнение. Скорее можно поверить во взаимодействие с дебажным агентом через разделяемую область памяти.

Думается, что уметь он это может только через посредство ''засланного казачка", то бишь дебажного агента, запущенного на отлаживаемом процессоре. "Здесь вам не тут", это вам не remote debugging via JTAG с аппаратной поддержкой точек останова, пошагивания и т.п.. А упомянутого дебажного агента надо шоб кто-то уже разработал и подготовил. Gaisler для своих SPARC и RISC-V такового написал (см. про программную поддержку отладки у него на сайте). Насчет поддержки PowerPC - не в курсе.

Спасибо за разъяснения, дальше понятно. Похоже, данное решение имеет хождение преимущественно в экосистеме Gaisler's IPLIB. Модуль, 1888ТХ018?

На подъем OS на PowerPC не претендую, но как у работающего в смежной сфере у меня возник вопрос: что есть EDCL? Первый раз такую аббревиатуру встречаю. Ну и да - без JTAG или другого отладочного канала будет тяжело подымать.

Ну, тогда пролить свет сможет только ловля ошибки в анализаторе.

А вот есть у вас такой сигнал dataAready, который тоже проходит через SYNC: Правильно ли я понимаю, что именно по нему происходит запись многобитового dataC в какой-то регистр в домене clkB? А сколько времени в тактах синхронизатора проходит между стабилизацией значений на линиях dataA и выдачей dataAready?

А нет ли у вас зависимости формируемой лог. функции от сразу нескольких сигналов, прошедших через CDC SYNC? Из описания это непонятно. И есть ли зависимость update от такого же рода сигналов? И вообще - сколько таких dataA -> dataB, вместе составляющих, видимо, нечто единое целое? Не нарушается ли именно _сочетание_ значений этого массива?

А почему не дешевую, проверенную, работающую и такую модную плату EBAZ4205 на том же Zynq7010?

Ну, для этой 4-ки комбинировать и химичить с какой-то мультиплексируемой схемой - нерационально, IMHO. Накладных расходов будет больше, чем выгоды. BSR: этот регистр строится вообще из распределенного множества специальных ячеек, для него комбинирование сдвиговой секции противопоказано по определению. IR: стоит и обрабатывается особняком, лучше его с DR-ми не смешивать. IDCODE, BAPASS: из-за разности в размерах и малости второго строить общий для них сдвиговый регистр нецелесообразно. Все это не исключает возможности построить IR, IDCODE и BYPASS в виде инстансов одного и того же параметризуемого блока (TAP shift register), типа того, который вы привели в самом начале темы. Совсем другое дело, если у вас появляются еще какие-то private instructions - вот их то DRs как раз можно было бы скомбинировать друг с другом и с IDCODE.

Почему 4, например? Вы не раскрыли, какие TAPC инструкции собираетесь реализовывать (с деталями типа разрядностей и общей структуры их DR) - так что сложно советовать конкретнее.

Для начала, не надо никаких inout reg на интерфейсе, только раздельные in и out. И уже это сделает решение легче (переосмыслите реализацию с учетом такого разделения, и поймете - например, насчет регистров, где нужно только IN или только OUT). Сюда же относится вопрос - зачем вам ВХОД data_init, а не соответствующий параметр? У вас что, послересетовые значения могут меняться? А дальше - прикиньте, какой набор секций shift регистра удовлетворит всему вашему набору инструкций, и соорудите мультиплексируемую схему. Регистры BYPASS и BSR можно реализовать особняком (слишком отличающиеся случаи).

Да нет же. Все проще. По Update-DR происходят не "выбросы на пины", а ровно то, что заключено в ее названии - обновление регистра DR (читай - его параллельной секции) значением из сдвиговой секции. Для инструкций SAMPLE/PRELOAD, EXTEST, INTEST роль DR играет BSR. Как подключены входы и выходы этой параллельной секции - определяется текущей инструкцией, как интерпретировать события Capture-DR и Update-DR - тоже определяется инструкцией. Именно в момент Update-IR чип становится "в курсе" того, какую инструкцию с этого мгновения ему надлежит выполнять. И именно с этого момента он начинает это делать. Команда EXTEST задает режим коммутации сигналов между BSR, external pins and internal system logic, а именно - делает так, например, что внешние выходы корпуса чипа теперь подключены к выходам определенных разрядов параллельной секции BSR, входы - к определенным входам регистров в BSR и т.п. Этот режим становится действительным по спаду TCK в состоянии Update-IR. Т.е. почти сразу после этого момента, лишь с задержкой распространения сигнала tCQ + tOUT (суммарно это не более 1 нс), состояние параллельной секции регистра BSR (уж какое оно там сложилось к этому моменту) появляется на соответствующем выходе чипа. Вот поэтому и надо, чтобы это самое состояние было не абы каким, а ровно тем, какое надо. И поможет нам в этом PRELOAD (в очень старых чипах это была отдельная инструкция) или ее комбинированный с командой SAMPLE вариант SAMPLE/PRELOAD.

Да, верно. Да, именно BSR, т.к. команда EXTEST работает именно с ним, и только с ним. Стоп! Как же не повлияет? Что было в параллельном каскаде BSR (осталось от предыстории сдвигов и прочей деятельности) - то и будет использовано сразу же командой EXTEST. Для простоты считаем, что это состояние неизвестно/неопределено (хотя оно, конечно же, вполне определяется этой самой предысторией и при большом желании может быть вам известно). Вот именно для того, чтобы обеспечить явным и понятным образом это начальное значение параллельной секции регистра BSR, и нужен PRELOAD - для "сшивки" предыстории и команды EXTEST (или INTEST - там такой же подход, но для тестирования уже внутренней системной логики чипа).

SAMPLE/PRELOAD используется: его SAMPLE часть функционала: для неразрушающего снятия отсчетов всех сигналов (и входов чипа, и его выходов) по фронту TCK в Capture-DR state; его PRELOAD часть: для подготовки начальных, инициализационных значений регистров для использования в последующей команде EXTEST или INTEST (иначе сразу после переключения на одну из этих команд соответствующие сигналы будут в неизвестном состоянии). Загрузка происходит по спаду TCK в Update-DR state. EXTEST используется для тестирования внешней по отношению к данному чипу системы, и в этом режиме внутренняя системная логика чипа полностью изолируется от внешних пинов.

Ну, не знаю, как можно без reset'а жить (IMHO). Если нет внешнего, можно соорудить внутренний - хотя бы тот же Power-On Reset.