Решил написать немного более подробно относительно вчерашнего поста про ЭЛВИС.
Все-таки не думаю, что такое ограничение рабочей частоты TCK до 5 кГц – это не проблема самого процессора 1892ВМ14Я. Чтобы не подумали, что я все валю именно на него.
Практика показывает, что процентов 95% нестабильности работы тестов периферийного сканирования вызвана схематикой платы, а не несовершенствами компонентов в части JTAG. Каким бы совершенным не был САПР разработки тестов, видящий все Enable, Disable и тому подобное, всегда найдется какой-то косвенный сигнал, который «через что-то» случайно может все обвалить. И в зависимости от частоты, количества векторов, цепей и драйверов, это событие может произойти, а может не произойти. Такое я наблюдал много раз, сидя с осциллографом на линиях сброса и питания исследуемых плат. А у 1892ВМ14Я еще и 25 Compliance Patterns… И, кстати, пара Compliance не выполнена. Там, где должен быть ноль для обеспечения периферийного сканирования, идет частота с генератора.
В пользу того, что дело не в частоте, как таковой, говорит и то, что тест инфраструктуры (Capture, ID-code и TRST) проходит у 1892ВМ14Я при любой частоте, а значит целостность сигналов JTAG не страдает особо сильно при повышении TCK.
По поводу второй проблемы, как я уже написал вчера, скорее всего, именно так все и реализовано на уровне кристалла, и тут ничего не изменишь. Это я по поводу линий под ОЗУ. Нам раньше встречались «сырые» BSDL, где разработчик, опасаясь некорректной работы «закрывал» те или иные ячейки для работы. Сделать это, не уменьшив длину регистра периферийного сканирования (которую, конечно же, нельзя уменьшать ни в коем случае), иногда бывает просто: ячейки просто объявляются внутренними. Так вот, здесь видно, что нет никаких «закрытых» ячеек.
Все-таки не думаю, что такое ограничение рабочей частоты TCK до 5 кГц – это не проблема самого процессора 1892ВМ14Я. Чтобы не подумали, что я все валю именно на него.
Практика показывает, что процентов 95% нестабильности работы тестов периферийного сканирования вызвана схематикой платы, а не несовершенствами компонентов в части JTAG. Каким бы совершенным не был САПР разработки тестов, видящий все Enable, Disable и тому подобное, всегда найдется какой-то косвенный сигнал, который «через что-то» случайно может все обвалить. И в зависимости от частоты, количества векторов, цепей и драйверов, это событие может произойти, а может не произойти. Такое я наблюдал много раз, сидя с осциллографом на линиях сброса и питания исследуемых плат. А у 1892ВМ14Я еще и 25 Compliance Patterns… И, кстати, пара Compliance не выполнена. Там, где должен быть ноль для обеспечения периферийного сканирования, идет частота с генератора.
В пользу того, что дело не в частоте, как таковой, говорит и то, что тест инфраструктуры (Capture, ID-code и TRST) проходит у 1892ВМ14Я при любой частоте, а значит целостность сигналов JTAG не страдает особо сильно при повышении TCK.
По поводу второй проблемы, как я уже написал вчера, скорее всего, именно так все и реализовано на уровне кристалла, и тут ничего не изменишь. Это я по поводу линий под ОЗУ. Нам раньше встречались «сырые» BSDL, где разработчик, опасаясь некорректной работы «закрывал» те или иные ячейки для работы. Сделать это, не уменьшив длину регистра периферийного сканирования (которую, конечно же, нельзя уменьшать ни в коем случае), иногда бывает просто: ячейки просто объявляются внутренними. Так вот, здесь видно, что нет никаких «закрытых» ячеек.