Jump to content

    

Почему в JTAG сброс в регистр происходит по заднему фронту?

Recommended Posts

flammmable

Не пойму кое-какой детали в работе с фронтами в JTAG.

Согласно стандарту
1) ...изменение логического уровня на линии TMS происходит по заднему фронту - здесь нет вопросов, какой-то из двух фронтов должен был быть выбран.
2) ...изменение состояния конечного автомата TAP происходит по переднему фронту - опять же понятно: TMS выставился синхронно с задним фронтом и, чтобы не устраивать гонку фронтов, его состояние следует считать по противоположному фронту - то есть по переднему.
3) ...сдвиг регистра и "затягивание" в него очередного бита - также по переднему фронту, что, опять же логично.
4) ...в состоянии Capture-XX cброс в сдвиговый регистр DR идентификационного кода, либо сброс в сдвиговый регистр IR значения по умолчанию - также по переднему фронту.
5) ...изменение на TDO - по заднему фронту - вынужденная мера, так как следующая в цепочке микросхема должна к переднему фронту уже иметь установившееся значение на своём TDI.

Но зачем в состоянии Update-DR/Update-IR сброс в параллельный регистр происходит по заднему фронту, а не по переднему (в середине самого состояния Update) - абсолютно непонятно.

Может кто-нибудь выдвинуть предположение, почему так было сделано? В чём преимущество?

Share this post


Link to post
Share on other sites

Aleх

Там внутри есть принимающие защелки, работающие по прямому клоку, а есть - по инвертирующему. Т.е. работают по обоим фронтам.

Почему так сделали? Интерфейсу 40 лет, кто ж теперь вспомнит. Но, тогда все проектировали на защелках, работающих по обоим уровням. Вероятно, такой интерфейс казался проще в реализации

p.s.

Если мне память не изменяет, в тап-контроллере еще есть пути с переднего фронта на задний - фактически удвоенная частота. Но поскольку реально делают мегагерц 50, не больше, то это не проблема.

Edited by Aleх

Share this post


Link to post
Share on other sites

flammmable
2 hours ago, Aleх said:

Там внутри есть принимающие защелки, работающие по прямому клоку, а есть - по инвертирующему. Т.е. работают по обоим фронтам.
<...>
Вероятно, такой интерфейс казался проще в реализации

Не, я не сомневаюсь, что технически так можно сделать. Но вопрос: зачем? В чём простота? Ладно бы там посередине Update, на восходящем фронте было бы что-то ТАКОЕ, что ни в коем случае нельзя в этот момент сбрасывать данные в параллельный регистр. Но нет же!

Share this post


Link to post
Share on other sites

Aleх

Замечу, что почти вся начинка тап контроллера описана в стандарте с помощью схем, дабы не возникало вопросов при реализации (HDL, схематик, или сразу топология)

 

Что касается, зачем так было сделано, почему сдвиговый регистр фактически работает на переднем и заднем фронтах, с чередованием через один флоп. Выскажу свое мнение

Как уже писал, интерфейсу 40 лет. В то время тулы были очень примитивные, цифру делали фулл-кастом. Далее, как работает сдвиговый регистр с тактированием один клоком, вы знаете особенность? Дерево клока должно быть идеальным, иначе сразу получаем проблему с холдом. Как можно выявить проблемы с холдом, если у вас тул даже STA делать не умеет? Так вот, работа конвейера по двум фронтам решает эту проблему: у вас получится примерно T/2 запас по сетап, и T/2 запас по холд. Т.е. удвоенная частота, но зато нет проблем с холдом. Если проектировать топологию аккуратно, с таким тактированием заработает и без всяких STA. Кандово, но надежно

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.