Jump to content

    

Aleх

Участник
  • Content Count

    54
  • Joined

  • Last visited

Everything posted by Aleх


  1. Латч, по опредлению, это бистабильный триггер, управляемый уровнем. Класическая схема - два инвертора во встречном включении, плюс управление (вспоминаем 6Т память), но может быть вырожден в RS триггер на двух NAND/NOR или во что то другое, в примеру - в синхронный латч, о которых здесь идет речь. Синхронный латч как правило имеет один вход управления, а его тайминг-модель содержит синхронные арки. Поэтому он подходит для STA. А вот, к примеру, модель RS-латча не имеет синхронных арок, и для классического STA не подходит. Далее. Если замкнуть два синхронных латча с разнополярным управлением в кольцо, то действительно получается луп. Просто потому, что фазы клока немного расходятся, и образуется окно времени, где оба латча открыты. Это классическое нарушение Hold. Однако на практике, задержки цепей и логических элементов (представим, что между латчами есть логика) это нарушение исправляют - переходной процесс посто не успевает добежать с выхода одного латча до входа другого. Из чего следует, что луп из двух латчей с разнополярным управлением - уже вовсе не луп, и разрывать его с помощью disable_timing не нужно. Если STA показывает нарушение холд в такой схеме, просто добавьте буферов :-)
  2. Важно понимать, что в случае раздвоения клока на две ветки, переходные процессы в ветвях уже не протекают одинаково - всегда в одной ветке сигнал распостраняется быстрее чем в другой на некую величину, которая может варьироваться от миллионных долей процента до величины, сопоставимой с перидом клока. Т.е. в природе не бывает такого, что клок дошел в две точки одновременно, всегда есть некое скью, которое может быть и большим и малым, в зависимости от задачи, и при этом все работает, не ломается. Прэтому присоединяюсь к колегам - вопрос поставлен некорректно, чего то не хватает.
  3. Лупам неоткуда взяться, если не делать асинхронный автомат записи/чтения. Просто, блок латчей, дешифратор адреса, регистры(латчи) по входу адреса и данных, можно еще по выходу поставить регистры (латчи). Все синхронно, и нет здесь никаких лупов. Другое дело, если вы хотите асинхронную память сделать (где из фронта сигнала записи делается импульс, к примеру). Но ведь и здесь никто не мешает автомат на флопах спроектировать, а сам массив памяти - на латчах. Что касается BIST, то для такой памяти он не обязателен. Это ведь не та память, что делается на пределе DRC норм (или даже по особым правилам, недоступным разработчикам), это ведь обычные штатные латчи, обычныая логика. Если чип не содержит DFT, то и BIST для такой памяти делать нет резона.
  4. Абсолютно нормальный вариант. Особенно когда компилятора памяти нет, либо он стоит слишком дорого. Создать массив латчей, дешифратор адреса, и т.д. - можно аккуратно все расплейсить и развести даже в P&R туле. Встречал полукастомные блоки памяти и вовсе на флопах - когда процесс нестабилен, параметры транзисторов плывут от партии к партии, и надо сделать максимально кандово. Потому что иначе просто работать не будет. За давностью лет могу даже назвать эту фабрику - Зеленоградский Микрон :-) Не знаю как у них сейчас, а раньше совсем беда была, годами не могли процесс настроить, вывести на серию
  5. На латчах вполне себе делают блоки и памяти и фифо, да и автоматы, и просто в дизайне используют. Латчи занимают в два раза меньше места, поэтому для заказных ИС использовать латчи выгодно. Скорость у них та же самая, но площадь и ликедж лучше. Из минусов - больше дерево клоков, и еще с латчами сложнее в STA работать. Другой важный момент, следует помнить что в большинстве ПЛИС (которые часто используют для макетирования на пол пути к эсику) защелок какбы и нет физически, а вот массив флопов часто можно смэпить во внутренний массив памяти, что удобно. Поэтому ленивые все делают на фопах - так проще.
  6. На мой взгляд, для стартапа и двух человек хватит - очень опытные цифровик и аналоговик. Тулы продадут с 99% скидкой на первый запуск - если очень поплакаться. А запуск по какой нибудь древней технологии типа иксфабовской 180нм не так уж и дорог, можно из своих сбережений наскрести. Не так страшен черт .. был бы клиент :-)
  7. Понял. Проиллюстрирую. Возможно, у вас своя кастом либа, поскольку как правило присутствуют такие флопы, использующиеся для скана: Теперь, что такое самая простая скан-селла BC_2, использующаяся в баундари скан житага Здесь datain dataout это провод, в разрыв котрого вставлена селла. Если этот провод - вход цифры, то наверно можно второй флоп заменить на скановский, но придется ему на вход D поставить что то вроде мультиплексора , чтобы завести сигнал из контролируемой сканом области. Если же это вход аналога, то такой фокус не пройдет. ps хотя .. по входу аналога, можно заменить на скановский - первый флоп. Цепочка баундари порвется на время скана, но ведь ее никто не дергает в это время?
  8. Шутите? У скан флопов расширенный состав пинов (встроен мультиплексор по входу). Может быть скан можно и на обычных флопах сделать, но я ни разу такого не видел, имел дело только со стандартными библиотеками, где скан флопы обязательно присутствуют.
  9. Баундари скан джитага содержит не скан-флопы, а любые. В общем случае это обычные флопы. И принцип работы совсем другой: одна житаговская скан ячейка состоит из двух флопов, один из которых работает на шифт, а второй на апдейт, плюс - комбинационная логика для работы ячейки в двух (или трех) режимах. Поэтому все немного сложнее, чем вы пишете. Надо очень постараться, чтобы какой то флоп из житаговского баундари чейна заменить на скановый, получить с этого профит, и при этом не поломать работу самого житага. Но, вам виднее, пробуйте.
  10. К сожалению, в моих чипах аналог не тестировался вообще, и проблема не до конца понятна. Возвращаясь к вопросу покрытия. Давайте рассуждать логически. Баундари цепочка житага работает в режимах intest и extest. Очевидно, что если вы хотите задавать константы на аналог, то 1. нужен extest, 2. прошивать сканами тап контроллер и саму баундари скан чейн - нельзя, и триггеры, входящие в эти структуры нельзя сделать скановыми. Однако, можно задействовать в скане триггеры из баундари цепи, которые смотрят внутрь и используются в инструкции intest. Придется вмешаться в логику работы этих BC7(или что вы используете) ячеек, и синтезнуть их на скан флопах. Так вы увеличите покрытие по входам ядра. Что касается выходов ядра, то подобный фокус не пройдет, поскольку нельзя вмешиваться в работу extest баундари ячеек, и нужно искать другие приемные скан-флопы. Я бы их вписал вручную в ртл - просто флопы, чей вход подключен к выходам кор, а выход ... куда нибудь. Можно их в цепочку обьединить, подавая на вход каждого флопа выход предыдущего флопа, заXORеный с одним из выводов ядра. Получается альтернатива решению на мультиплексорах со входа на выход ядра.
  11. Таки, а что же вы хотите генерить с помощью ЕТ? Чтобы просто получить вектор, который задвигает в житаг баундари скан некое состояние на линиях, можно написать простенькую прогу. На входе у нее будет желаемое состояние входов аналога, а на выходе полный вектор для тестера. Когда я занимался этой темой, то подобные проги и отдельные вектора для джем-плеера писал за 20-30 минут. Полученный вектор грузите тестером в качестве инициализации, а потом гоните свой скан тест. Непонятно, чего вы хотите от ЕТ. Хотитет генерить скан векторы с учетом тап контроллера? Боюсь, это не получится. Но никто но мешает написать маленькую прогу, которая патчит вектора, просто дописывая в начало небольшие самописные фрагменты. Это несложная задача, на мой взгляд. Проект со сканом через житаг порт, про который я писал выше, использовал в т.ч. и патчинг векторов после atpg, сгенеренных для уровня кор. И таких микросхем у нас было сделано несколько. К сожалению, один скан порт годится только для очень маленьких микросхем, и не дает высокго покрытия. Поэтому от использования житага подобным образом в последствии отказались. p.s. на самом деле, я никогда не имел дела с iddq так что вероятно просто не понимаю задачи. Прошу извинить, если так.
  12. Я не понимаю, почему в тестовом режиме нельзя заизолировать входы аналога так же, как это делается в лоу паэр флоу? Просто пропускаете логические входы аналога через and или or (в зависимости от безопасного лог. уровня в цепи), второй вход которых заведен на testmode. Это как если бы цифровая часть являлась отключаемым пауер доменом, и ее выходы надо было безопасно заизолировать, а testmode служил бы сигналом отключения питания. p.s. rs232 допускает очень большие отклонения несущей частоты. В то же время, точность осциллятора на инверторах очень высокая, и можно добиться маленького джиттера. Для коммерческих применений такие генераторы успешно используется, и работают в кремнии на частотах свыше гигагерцах. Это вполне рядовая вещь, не надо ее недооценивать. Хотя, для военных температур и, скажем, микронного процесса может и правда будут проблемы - я не специалист в аналоге.
  13. Был еще один вариант, про который я забыл за давностью лет. Суть сводилась к тому, что если скан цепочка одна, то ее можно подключить к тап контроллеру в виде инструкции пользователя, и гонять тест покрытия используя интерфейс житаг. Т.е. не atpg дергает житагом, а наоборот. Детали помню смутно, но в целом это выглядело так: в тетрамаксе в командном файле менялся протокол махания управляющими сигналами для совместимости с управлением стандартной житаг цепочкой (сигналы шифт,скан, апдейт и пр.). Далее, тулом генерились векторы покрытия для уровня кор. Затем, на верхнем уровне проекта вставлялся тап контроллер, и к нему подключался интерфейс скан цепи в виде отдельной инструкции. При этом сгенеренные тетрамаксом вектора удлиннялись на один бит. В результате, на тестере тап контроллер сначала переводился в пользовательскую инструкцию, а потом запускались скан векторы. Как то так, в общих чертах. Было это больше 10 лет назад, тулы были древние, а микросхемы маленькие - им достаточно было одной цепочки.
  14. Выводы скан обычно либо шарят общий пин с выводами логики(кроме TESTMODE), либо имеют собственные пины, которые просто не развариваются (тест можно прогнать только на пластине). Я так понимаю, вы хотите тестировать закорпусированый чип. Jtag, это совсем другая штука, которая изначально была разработана для теста паек на печатной плате, и обязана иметь свой интерфейс - 4 вывода. Итого, если всего выводов у микросхемы 8, из которых 2 - земля/питание (или запитка от сигнальных входов идет?), то в оставшиеся 6 надо впихнуть житаг (4 вывода), TESTMODE для отбраковки закорпусированых микросхем, аналог (?) .. очень любопытная микросхема получается. Я бы житаг вообще выкинул, и оставил бы только скан (serial in, out, testmode) - 3 вывода, которые в режиме test паркуют интерфейс с аналогом, и сканируют только цифру, а в рабочем режиме на этих же выводах организовал бы что то вроде логического RS-232 интерфейса с возможностью тестировать аналог - перехватывать управление, считывать данные с ацп и т.д. (вы не написали, что подразумеваете под аналогом, могу только гадать). Тогда можно было бы на тестере и покрытие проверить, и прогнать функциональный тест аналога через rs232. Если честно, я так и не понял что нужно для теста аналога. То ли только провода дергать, то ли еще логическое состояние считывать, то ли ставить первое в зависимость от второго (селф-тест).
  15. Добавлю только, что при такой характеризации блока лучше дампить sdc файл, чуть поджимать констрейнты на интерфейсы и затем обратно зачитывать - получается запас. Если же из блока выходит сорс-синхронный интерфейс, то надо довести этот блок до лейаута, выписать либу и уже ее использовать в синтезе верхнего уровня - так синтезатор учтет летенси клока внутри блока, и синтез будет более корректный. Хотя если грубо, то лейаут можно не делать, а летенси клока задать констрейнтами (характеризация этого сама не сделает). Что касается p&r тулов, то по понятным причинам они требуют унифицированный нетлист. Исключение - когда повторяемый блок был сделан отдельно, и присутствует в проекте в виде леф/либ/ilm.
  16. Для проверки каких то специфичных вещей через джитаг, в нем предусмотрены инструкции пользователя в качестве дополнения к стандартным id/intest/extest/sample/preload. Адресное пространство и ширина регистров почти не ограничены. Пишете свой BIST для проверки аналога, командные и статусные регистры этого BIST располагаете в адресном пространстве житаг, пишете спецификацию для подключения этих регистров к тап контроллеру с помощью синтезатора. И получаете фактически бэкдор внутрь миикросхемы. Через этот бэкдор можно организовать доступ к чему угодно: к регистрам процессора, чтения содержимого ОЗУ, или отсыл пакетов по PCIE. Все упирается в вашу фантазию и скорость интерфейса житаг. Вектора для таких регистров пользователя придется писать руками, поскольку кроме машины состояний тап контроллера появляются еще состояния ваших BIST. Можно делать не BIST, а просто командные и статусные регистры для дерганья проводками, но в любом случае - алгоритм работы этой структуры знает только автор. Через адаптер житаг можно не просто гонять одиночные вектора, а организовать целый мониторинг с контролем в реальном времени (нужно писать свой софт). Ну и наверно можно эти вектора гонять на вафертестере вместе с обычным Atpg в целях отбраковки. Что касаетается увеличения покрытия, то первое, как уже писал - прошить все сканом, включая джитаг. Поскольку сканы - это браковочные тесты, а джитаг предназначен скорее для отладки на плате, а не браковки. Второй вариант - прямо в RtL выходы ядра завести на его же входы через мультиплексор, управляемый TESTMODE. Получится, что выходы ядра могут тестировать входы. Третий вариант - специально созданый для таких целей стандарт IEEE 1500 shadowrapper (сам никогда это не делал)
  17. Исключительно из любопытства: как вы сoбираетесь задействовать эту цепочку? Ведь чтобы использовать ее неинвазивно, надо прокрутить машину состояний тап-контроллера в режим INTEST, а потом ходить по состояниям, в которых переключаются режимы shift и update. Получается, что длины векторов будут намного больше числа элементов в цепи, а определенные фрагменты вектора (хождение по машине состояний житаг) придется писать вручную - слабо верится, что atpg генератор такое умеет. К тому же, одного сигнала tdi недостаточно, чтобы ходить по машине состояний; надо еще управлять и tms. Принимая все это во внимание, существуют куда более простые способы увеличить покрытие на интерфейсах, чем развлечения с баундари скан и житагом.
  18. Рецепт простой. Сначала добавлять житаг/баундари скан, а потом прошивать все atpg скан цепями
  19. Бандари скан в основном нужен для теста паек на PCB, ну и для отладки. В микросхемах эту штуку очень часто делают, годов с 80х.
  20. Возможно, это зависит от вендора тула. У меня опыт синопсиса и кеденса. Синопсис требует пады, и делает проверку того, что вставил (может отругаться, к примеру, что на tdo стоит тип пада просто выход, а не тристейт, может на отсутствие пуллапа отругаться). У кеденса как обычно все либеральней, практически без проверки и с кучей багов, но и там спецификация требует наличия падов. А вот с ментором не работал. Впрочем, допускаю, что и без падов можно както баундари скан вставить, но не представляю как. Никогда так не делал.
  21. DFT в части баундари скан очень даже зависит от наличия падов. Тул из либы вычисляет функции портов пада, и окружает их соотв. тестовыми структурами. Конечно, можно и в слепую написать баундари спецификацию, но лучше все же иметь тайминг либы на пады, и генерить баундари структуры на автомате. На внутренний скан пады конечно же никак не влияют.
  22. Первое что приходит в голову - отдельно констрейните-синтезируете этот модуль, получаете нетлист, потом подгружаете его в большой проект, накладываете на этот модуль атрибут preserve=true, и пускаете синтез. Альтернатива - можно дополнительно этот модуль довести до конца в инновусе, отдельно от проекта, выписать либу и использовать ее в синтезе большого проекта. А в P&R использовать ILM модель + LEF модуля.
  23. С падами, конечно. Логика здесь следующая. Есть ТЗ, в нем указана спецификация интерфейса - тайминги, нагрузки, наклоны фронта. Все это аккуратно перекладывается в sdc (set-input-delay, set-load, set-transition и т.д.). Разумеется, эти констрейнты должны накладываться на выводы микросхемы, а не коре. А значит, пады должны быть обязательно. Уберете пады - не сможете правильно обконстрейнить интерфейс - не попадете в ТЗ. К тому же, систему моделирования у верификаторов тоже надо сразу делать в расчете на топ уровень с падами. Добавлять потом уровень иерархии бывает сложно, лучше сразу все делать правильно. Для верификации вместо падов используют либо модели из библиотеки, либо самодельные поведенческие модели. Но для синтеза лучше иметь инстансами вызовы реальных библиотечных падов, которые выбираются исходя из ТЗ. Вписывают их ртльщики. Хотя для SoC часто все сложнее - бьют дизайн на блоки, делают их отдельно, но в конечном счете все равно синтезируют топ-уровень с падами.
  24. Бондпады, к слову, не всегда клеят. Бывает, что их целый набор под разную разварку - медь, люминий, разная толщина проволоки. А пады идут отдельно. Что до клампов, то их тоже не всегда с питанием ставят. Правило - кламп не далее чего то, и по току - не более чего то. А если правило соблюдено, то кламп хоть между айошками ставь. Хотя, может гдето и рядом ставить надо, не встречал. Отвечая прямо на вопрос - нет, не знаю такой команды. Сам расстановку падов всегда скриптую. На входе таблица в экселе, где пады, филлеры, клампы, рингкаты, корнеры и т.д. - все расположено по порядку расстановки, против часовой стрелки, скажем. В каждой строке инстанс (для айо), название селла и сторона кристалла, можно еще ширину добавить. Потом таблица экспортируется в ascii, затем обрабатывается тиклевским парсером, который на каждую строчку высчитывает координату, ориентацию, и делает placeIO чтото там. Поскольку все координаты известны, можно заодно и бондпады приклеивать, если они отдельно. Этим же алгоритмом можно в несколько рядов пады ставить, если надо, или - сразу координаты центров пятаков в файл сбрасывать - для последующего айрдропа и лвс. Работает так - накатил скрипт, посмотрел результат, не понравилось - все грохнул, подправил эксель и снова накатил. В минуту одна итерация - легко. Скрипт легко переносится на другую технологию. Дизайн аутомейшн наше все, рекомендую :-)
  25. Если честно, не уверен, что понял задачу. Понял так: Есть макро, с него выходит шина асинхронных сигналов, и есть приемный клоковый домен для этих сигналов. Нужно обеспечить равные задержки. Что получается. Разряды в шине расползаются на +/- 1 такт в любом случае (поскольку сигналы асинхронные), и Ваша задача их потом выровнять с помощью фифо. Возникает вопрос - а на сколько выравнивать фазы? Полагаю, что допустимый разброс не должен превышать одного такта за вычетом сетапа и холда флопа, а так же разброса по температуре и питанию - в этом случае будет ошибка не более +/- 1 такт, а не, скажем, +/-2 такта. В зависимости от частоты это может быть и большой разброс и маленький, частоту Вы не указали. На мой взгляд, здесь надо все плейсить руками, включая клоковые буферы. Вероятно, эту часть схемы лучше выделить в отдельный уровень иерархии, и построить для нее Н-дерево или фишбон, а может еще и развести клок руками. Другой вариант - не заморачиваться с плейсом, но организовать выравнивание +/-2 клока с помощью фифо :-) Что касается сдвигания флопов, я это делаю скриптами. Для выходного пина первого флопа узнаете его координаты (через атрибуты). Далее , через placeinstance (или как то так - нет мануала под рукой) плейсите в эту координату второй флоп, а потом выполняете refineplace. Получаете два флопа рядом. Но это медленно работает, особенно на больших обьемах. Если же нужно аккуратно расставить целый массив (фифо, к примеру) из флопов, то очень рекомендую почитать про SDP - техника специально для расстановки структурированых массивов селлов.