Перейти к содержанию
    

Shivers

Свой
  • Постов

    676
  • Зарегистрирован

  • Посещение

Весь контент Shivers


  1. Если с житагом освоитесь, рекомендую в режиме EXTEST эмулировать на пинах вейвформы разной частоты и скважности в циклическом режиме (чтобы на каждом пине уникальная ввейвформа была), а потом смотреть осциллографом на плате, сдирая шелкографию на переходных отверстиях. Лет 15 назад я именно так непропаи в BGA искал. Тесты писал на JAM, jamplayer использовал консольный, из пакета квартуса под виндос.
  2. Виртуальный клок нужен чтобы достроить граф STA на интерфейсах: по входу он создает входную арку, а по выходу - выходную. При этом можно варьировать тип арки, к примеру - выбирать фронт (rise или fall), выбирать тип проверки для этой арки (setup или hold). Но поскольку арка должна иметь два конца (иначе путь будет unconstrained), то виртуальный клок должен быть синхронен принимающему клоку (по входу) и/или запускающему (по выходу). Виртуальных клоков можно создавать сколько угодно. Но и в схеме может быть много асинхронных клоков, и тогда надо следить - какой виртуальный клок синхронен какому внутреннему клоку. Соответственно, при создании виртуальных клоков потребуется задавать дополнительные фалзпасы. Требование алтеры констрейнить интерфейсы виртуальным клоком выглядит странно. Если констрейнить синхронный вход не относительно собственного клока, а относительно виртуального, то действительно - тайминг будет отличаться на величину uncertainty и drive adjustment клокового пина (поскольку к виртуальному клоку эти твики не применяются). Но эту разницу в тайминге куда проще упрятать в величину задержки констрейнта, чем плодить виртуальные клоки. Обычно виртуальный клок используется, чтобы констрейнить асинхронные входы, чтобы они хоть как то контролировались тулом. Либо для каких то тонких моментов вроде DDR, где констрейнить интерфейс надо по обоим фронтам клока, и может оказаться проще задать два виртуальных клока со сдвигом фазы 50%, и написать констрейнт относительно переднего фронта каждого из них. Т.е. виртуальный клок - вещь специфическая, почти как кунгфу (применяется при необходимости). Но, альтере виднее, конечно. Возможно, у них тул так специфически работает, что необходимо заводить виртуальную копию каждому интерфейсному клоку.
  3. RISC-V

    Спасибо!
  4. Пример плохой, потому что мультиплексор клоков в нем описывать не требуется. И виртуальный клок не нужен - все порты достаточно относительно ClkIn констрейнить (кроме DataOut, если он синхронен ClkOut). p.s. Соврал. Нужен констрейнт -генерейтед клок на выходе триггера-делителя, иначе через него latency считаться не будет
  5. RISC-V

    Если кто занимался этим, посоветуйте, плиз, verilog-репозиторий с желательно облегченной (без кэшей и с минимумом периферии) реализацией 16 или 32 бит RISC-V.
  6. Как дети, ей богу. Для РФ закрыты технологии ниже 16нм. Вообще закрыты, за любые деньги. Да и 16нм только по талонам
  7. Если честно, я уже не помню деталей, давно это было: мы купили софт-айпи с отдельным PHY, к которому шел в комплекте шифрованый нетлист (т.е. PHY делался по цифровому маршруту, кроме сердесов, может быть, но нам поставлялся как хард-айпи). Кажется, этот шифрованный файл просто скармливается симулятору, и все, т.е. шифрация производится ключами, зашитыми в тулы кэденс. (у синопсиса свое флоу, и свои ключи, кажется). Так что дешифровывать ничего точно не надо - сразу можно моделировать. p.s. и да, шифрация делалась с помощью ncprotect, но было это еще во времена IUS. Сейчас это может быть уже другая утилита, поскольку от приставок nc они старательно избавляются в новых версиях.
  8. Речь ведь о цифре, верно? Сделайте свои блоки, и передайте их в виде GDS с флатованой до транзисторов иерархией. А цифровой нетлист сконвертируйте в CDL и тоже расфлатуйте: LVS будет проходить. Если заказчику хочется симуляцию на верилоге пускать без задержек, можно обфусцировать и зашифровать нетлист - логика моделироваться будет, а внутрь заглянуть нельзя. Ну и надо понимать, что на 100% защиты не бывает. По GDS можно восстановить CDL, по CDL - логический нетлист. А GDS при желании можно получить послойным стравливанием металлов. Это, если ну очень надо, и есть оборудование, куча денег, людей и времени.
  9. Польза есть только от сильно advanced тренингов. Обычные тренинги - просто пересказывание user manual и methodology guide для ленивых. Самую большую пользу приносят сервисные часы, поскольку можно перенять различные лайфхаки, обход багов в тулах, и прочие приемчики, которые на тренинге не покажут. Конечно, это если знать куда смотреть, на что, и правильные вопросы задавать.
  10. По тулам, опять же со слов саппорта кэденс, цифровое флоу и по сию пору работает на обычных NLDM либах, но уже умеет использовать и CCS. А вот SSTA только в сайнофф режиме доступно. И это про 65-28нм! То, о чем Вы пишете, думаю, не то что не поддерживается тулами, этот формат только в этом году в стандарт ввели! Т.е. я бы вообще не заморачивался ... Другое дело, что у Вас налицо проблема - в либе одни цифры, а в моделировании другие, как я понял. Т.е. надо отделить мух от котлет, а байки от ситуации дэфакто. Или вы в фабричной либе уже видите эти новые конструкции вроде ocv_sigma_cell_rise?
  11. Пессимизм не в либерти моделях, пессимизм в алгоритме STA тулов, которые этот либерти используют. Дело здесь в следующем: пусть есть некая погрешность характеризации задержки в одном элементе, пусть есть погрешность округления промежуточных результатов алгоритма STA (интерполяция дот-либа, дерейты и т.д.). Теперь представьте, что в цепочке стоит 30-40 элементов, и через них считается прохождение сигнала. Какова погрешность расчета для всей цепочки? Скорее всего так эта погрешность и выливается в 10-20% пессимизма, которые я наблюдал на 65нм. Могу только предположить, что приемы (вычисление мин/макс, среднего и отклонения), которые Вы описали, как раз и направлены на повышение точности, и снижение этого самого пессимизма. Потому что 10-20%, это очень много. p.s. ну, собственно, нагуглил, что это за дополнение такое к либерти. Synopsys: Statistical moment-based Liberty Variation Format (LVF) extensions added to Liberty library modeling standard. Cadence: http://www.tauworkshop.com/2016/slides/10_...ussian_POCV.pdf Другими словами, это расширение для SSTA, очень свежее, и для процессов суб 16нм. Удачи! У нас в РФ еще 28нм не все освоили =)
  12. Услышал много нового для себя. Но я и не специалист в характеризации, хотя было дело, приходилось этим заниматься для 65 нм. Все, что я писал выше, касается NLDM. На 65 нм одного рана достаточно, чтобы по двум порогам получить искомое число для LUT. Но я совсем не понимаю, куда приткнуть 4 варианта измерений (мин/макс, мат ожидание), о которых Вы пишете. Возможно, слова сотрудника кэденс - просто пыль в глаза (они так делают иногда, замечено), поскольку на 28нм для проектирования используется все тот же NLDM, а CCS в лучшем случае для сайнофф. Но если на 65 нм сингл-ран тест давал точно такие же цифры как в фабричном либе (т.е. я был уверен, что методика правильная), то на 28нм я таких экспериментов не ставил. И еще пять копеек. Замечено, что тулы цифрового бекэнда сильно загрубляют цифры из либерти: в слоу на 10-20% медленнее, а в фасте на 10-20% быстрее. Это легко проверить, сделав репорт STA в туле для некой схемы, а потом промоделировав эту схему с паразитами для того же угла на спайсе. Получите в спайсе результат на 10-20% быстрее в слоу. Опять же я пишу по своему опыту 65нм. Зачем так делать, я не знаю, видимо перестраховка. В этом ключе гоняться за точностью результатов характеризации дот-либа смысл теряется. И в CCS смысл тоже теряется. К слову, а какой у Вас процесс?
  13. demon_x, Вы правы, цифры должны совпадать до последнего знака. Если Вы правильно задаете транзишн, и вешаете правильную емкость на выход, и PVT совпадают, и пороги, и PDK той же версии, что и либы, и экстракция правильная ... то наверное что то не так в тестбенче или симуляторе. Я бы посоветовал пойти от простого к сложному: собрать спайс-тестбенч (без верилог-А) на одно измерение, и если цифра опять отличается, сменить симулятор (к примеру -спектре) и/или поковыряться в настройках моделирования. Насчет платных консультаций, то если софт легальный, лучше всего обратиться в саппорт кэденса/синопсиса - задорого, но получите 100% результат. А так .. может быть найдется кто то и здесь
  14. Между характеризацией стандарт селлов и заказных блоков лежит пропасть. Если у стандарт селлов их либерти-описание почти полностью описывает логику работы схемы, то для заказных блоков выдумывается схема замещения, которая накладывает ограничения только на тайминг интерфейсов, а внутренность остается черным ящиком. Т.е. либерти описание большого хард-айпи блока, это в каждом случае творческая работа разработчика, который должен этой моделью правильно достроить граф STA, чтобы временные арки на портах блока не обрывались, и тулы правильно считали тайминг. Тулы автоматической характеризации, о которых Вы писали в начале, хорошо работают как раз со стандарт-селлами, т.е. на большом числе примитивных схем. А в случае заказных блоков характеризацию как правило (в знакомых мне фирмах) проводят вручную. Другими словами, если Вы умеете характеризовать вручную стандарт селлы, то также вручную характеризуйте и свой заказной блок - владение тулами автоматической характеризации Вам не поможет, поскольку они не умеют думать за разработчика. Думать - это значит четко понимать где и какие арки Вы хотите заложить в либерти модель, а потом уже характеризовать эти арки. Мне кажется, Вам сейчас больше нужен репетитор по STA, чем по характеризации. Но Вам виднее, конечно
  15. Нет смысла браться за "тулчейн", пока не освоите мат часть. А мат часть здесь - STA. Возьмите любой либерти файл, и разбирайтесь. Когда будете понимать буквально каждую его строку, как она используется потом в STA, только тогда имеет смысл самому начинать делать характеризацию. Да и то, по началу не в либерате/силикон смартах, а вручную - подготовка тестбенча, тестов, симуляция на спайсе, измерение характеристик, ручное заполнение лутов и т.д. При этом желательно пихать эту либу в тулы с STA, и проверять как работает результат. И когда уже поймете как это все работает, только тогда уже брать тулы верхнего уровня. Которые по сути - автоматизированные оболочки к все тому же спайс-моделированию, не более чем приспособа тому, кто точно знает что должно получиться в рез-те.
  16. Читайте харрисов (https://habrahabr.ru/post/306982/), там все популярно разжевывается.
  17. Может немного запоздало. Но да, такие интерфейсы существуют с 70-80х годов. Читайте книги В.И. Варшавского. Если кратко - вводится вторая (служебная) фаза передачи, и (в качестве одного из вариантов) парафазное кодирование сигналов. Данные передаются в рабочей фазе, служебная фаза используются в качестве разделителя. На принимающей стороне фаза определяется по коду в сигнальных линиях. Сигнал сопровождения при таком протоколе передачи не нужен, кодирование в линиях противогоночное - состязания отсутствуют. Из-за второй фазы протокол не самый быстрый, а при парафазном кодировании еще и сильнопотребляющий (переключательная активность проводов 100% за цикл передачи). На практике вроде бы это в TRIMOSBUS применялось, но не уверен.
  18. Я там выше уже писал про систему остаточных классов (СОК). Все что нужно - сконвертировать 8000 битные числа в СОК, а потом уже умножение и сложение будет представлять из себя кучу параллельных схемок с длинной переноса не более 10. И в конце результат еще надо сконвертировать обратно из СОК в бинарный код. Сравните - длинна переноса 8000 и длинна переноса 10, есть разница? Для этого СОК и был придуман.
  19. Погуглите про систему остаточных классов (СОК). Специально придумано для распараллеливания арифметики с разрядностью в сотни и тысячи бит. Придумано кстати уже давно, лет 50 назад, и используется столько же - в спец. задачах. Главный недостаток СОК - хорошо работает только умножение и сложение, с делением проблемы. Но Вам то как раз сложение и нужно, я так понял.
  20. Попробуйте прямо в тело тестбенча вставить команду $sdf_annotate (синтаксис и примеры нагуглите).
  21. Здесь главный вопрос, какое latency Вы хотите получить в рез-те. Могу сказать, что в DSP типа TMS320 сделаны прямые связи управления между блоками периферии чтобы, к примеру, можно было мгновенно отрубить ШИМ по сигналу с АЦП, а не пропускать это все через процессор/программу. В Вашем случае latency это время работы программы + задержка внешнего интерфейса проц-плис (для параллельного - меньше, последовательного - больше). Если latency не критично, можете хоть по rs-232 управлять - всего 2 провода надо. Если наоборот, latency очень критично, то лучший вариант - собрать SoC-FPGA со своей специально под задачу написанной периферией.
  22. Про синтез могу сказать, генус - жутко сырая и глючная вещь: часть ключей или даже команд не работает совсем, либо работает не так как в мануале, документация очень хреновая, не все сообщения тула описаны. Судя по рекламе, дает прирост на больших (10М+) проектах и больших кластерах с десятками ядер. Умеет вызывать плейсер из инновус и как то учитывать ClockSkew. DC даже в топо этого и близко не умеет, но в моих экспериментах показал тот же результат что и генус. При том, что DC - почти не падает, все работает, документация шикарна. ICC и инновус не сравнивал. Тут надо понимать политики фирм. Синопсис на ряд тулов дает лайф-тайм лицензию, и продает некоторые тулы без саппорта. Кэденс продает тулы только с саппортом, и лицензии только на год. О чем это говорит - купили тул синопсиса и не вспомнили про саппорт - все работает и так (об ICC не знаю, но слышал что там не так все гладко). А вот с кэденсом - без общения с саппортом вы и трех дней не протянете, упретесь либо в баг, либо в "белое пятно" в документации. Но! Синопсис стоит в разы дороже кэденса (на западе. у нас может и столько же стоить - как договоришься) -это по большей части тулов. Есть тулы, где кэденс лидер - виртуозо, к примеру. Но с синтезом -к гадалке не ходить, генусу (несмотря на потенциал) до DC еще очень далеко.
  23. Есть еще один путь. Можно задать констрейнт set_clock_latency на тот клоковый пин (скажем, триггера), который вы хотите подвинуть в дереве вверх или вниз. CCOPT учитывает это.
  24. Т.е. это путь reg2cgate? Я замечал, что CCOPT плохо правит reg2cgate, если есть нарушения сетап/холд в путях, которые находятся в дереве с выхода этого клок-гейта. Как только исправляете тайминг в дереве (к примеру, ослаблением констрейнтов, если нарушения в in2reg или reg2out), только тогда тул начинает сам править reg2cgate. На мой взгляд, это баг. Тулы кэденса вообще дико забагованы, как известно.
  25. Посмотрите тайминг до передающего триггера и после принимающего, есть ли там запас по сетапу. Тул ведь сводит всю микросхему/блок, а не один выделенный путь. Если где то совсем плохо с таймингом, тулл попытается вытащить эти места за счет хороших путей. А если все же надо вытащить именно один путь или группу путей на фоне проблем в остальной части дизайна - выделите это в отдельную группу (group_path), и повысьте на ней приоритет (setPathGroupOptions).
×
×
  • Создать...