topor_topor

SOURCE_INSERTION_DELAY это задержка от выхода осцилятора до точки где задан клок (create_clock) - "Clock Latency" Задержка отрицательная, т.к. отсчёт идёт от точки задания клока. Негативный инсершин делей возможен, если используется PLL, которая собственно вставляет "негативную задержку" (фазовый сдвиг) так чтобы компенсировать инсершин делей и сделать клок как в декларации. В первом репорте мы видим в соурс дата пасе: Clock Rise Edge 0.000 + Source Insertion Delay -2.154 = Beginpoint Arrival Time -2.154 Timing Path: А в клок пасе: Clock Rise Edge 0.000 = Beginpoint Arrival Time 0.000 Other End Path: Т.е. Source Insertion Delay тут отсутствует. При этом клок пас совпадает до /clock_manager/g516__5795. Во втором репорте всё совпадает как и ожидалось (также оно и при моделировании с SDF). В этом похоже и проблема. Почему так мне трудно ответить... Я не знаю что и из чего ви дизайните. А из какой тулзы репорты? Если это FPGA, то тул сам подставляет "невидимые задержки" в SDC. Есть конечный SDC?. Если это XILINX то вот возможное объяснение почему исершин делей разное: This becomes a problem when you want to cross synchronously between a small domain and a large domain - the insertion latencies are different, and hence you get timing problems. У вас как вообще клок три построены? ---- P.S Задание set_clock_latency не поможет если в SDC стоит set_propagated_clock (вы указали пропагейтид клок в SDC?). Попробуйте задать set_clock_latency -source. В клоковом дереве я вижу два логических гейта. Для ASIC тулзы это не проблема по дефолту, а вот в FPGA "просто тупо вписать это в RTL" не лучший путь...GATED CLOCK in FPGA

Если втупую задать с запасом input/output_delay ну никак низя (ну нету явного полпериода запаса и нужно наносекунды ловить или заказчик сильно требует доказать тайминг) то можно по умному - строите TOP блок цифры так чтобы туда все ети внешние роутинги входили и делаете честный екстракт SPEF. Для этого ещё нужно создать LIB файли всех аналоговых блоков, буферов, падов итп. (входные ёмкости, сетап/холд тайм...) Некоторые заморачиваются и этим. Пользы от этого обычно 0. Так получится честный екстракт паразитов и честный STA/ Попроще решение - сделать с аналогового топа CAP екстракт и задать его как нагрузку выходов (как задержка в линии)... При этом правда задержки в буферах, запасы на сетап/холд итп. всё равно придётся вручную через input/output_delay задавать. Подтяжка под корнеры через -min/-max в input/output_delay задаётся. Можно ещё задать сетап/холд виртуального тригера (внешнего) относительно виртуального клока. Тут есть пример: Input and Output Delays with Multiple Clocks

Название дает примерную классификацию библиотек указивая под что они оптимизировались. А что ето в цифрах значит (площадь, вольти, миливати итп. ) смотрите в дейташите вашей библиотеки. UltralowVoltage обично надо там где питание от батареек.... ---- Я так понимаю ето у вас компилятор IP регистров. Periphery тут скорее относится к тому какие схеми на входе/виходе етого IP

Зачем так заморачиваться? У меня все и всегда тулзи сами по умолчанию останавливаются и печатаеют Warning/Error в логе... Дальше баг фиксится и можно продолжать скрипт. Да есть опция, включив которую тулза попитается игнорировать Error и пойдет дальше, но смисл имеет если рантайм скрипта больше чем полдня. Чтоби словить побольше багов за один раз и пофиксить.

Симуляцию криптованогоRTL/netlist в nc-sim я делал. Тут все ясно. Но как скрить нетлист при P&R ума не приложу. При етом позаимствовать ip в виде нетлиста уже большое дело. Ктонить в курсе какие тут возможности есть? Думаю что если есть что скривать, то надо защищать на уровне ноухау, те. никому не показивать....

Как я понял глобально, задача следующая: Реализовать транзишин делей тест типа LOS. Трудность в том, что некоторие паси проходят через клок домени и чтоби мерять транзишени на них, нужни соответствующие ухишрения. Принцип LOS на пальцах описан тут: https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.ee.nthu.edu.tw/~syhuang/testing/ch6.delay_test.pdf&ved=2ahUKEwjM74fOoKDrAhVoiYsKHVh4DL0QFjADegQIAhAB&usg=AOvVaw1CfunRH81ngZgctqDASZAw

У них полно супер доков. Очень внятних. Називаются тренингами :) плюс куча RAK

OPCG on product clock generator Зачем оно надо и как оно с клок доменами связано? Путано както задача сформулирована... DFT вставляет скан чейни между доменами автоматом и по дефолту правильно. Че сделать то надо?

А ето много или мало? Для мирових компаний из области микросхемостроения, продажи в россию порядка пари процентов всего....

Пожалуй стоит уточнить что ви понимаете под дебагом скриптов? Конструкции тикла дебагать? Или понять проблемму, почему командм тулзи не то делает что надо? В любом случае, для дебага есть следующие инструменти в иулзе: - командная строка для пошагового виполнения - команда print - команда report_, get_ - log file - встроений хелп на каждую команду - gui для просмотра схеми, есче кое чего... Пошагового дебагера с брейкпоинтами нет :(

regexp посложнее... Но не в тикле главная проблемма.... Тулзу нужно изучить

В данном случае нужно начать с освоения типичного фло - скачать у каденса соответствующий RAK. Чтоби в принципе представлять что делается. Два дня на тикл маловато будет... Да и главное команди тулзи нужно знать. Скачайте command guide. Что делает ваш конкретний скрипт смотрите лог файли в рабочей директории. Comnand.log особенно. Очень силино помогает спросить у автора скриптов или того кто их часто юзает что там происходит и зачем. Учтите, что скрип без багов не гарантирует отсутствие sta/drc ошибок, которие надо уметь понять и пофиксить. Лично я думаю что такое самостоятельное изучение бек-енд путь лбом в стену, но пожелаю удачи.

"Например. Разработать вертолетный радар 12ГГц. Ну представляете, там все чудеса электроники от простого транзистора до FPGA сигнальная обработка. Срок реализации проекта 1.5 года. Бюджет проекта 15млн стартовый, далее все корректируется в сторону увеличения. Спец приступает к работе (аванс 50%), разрабатывается идеология и структурная схема. Обсуждение с заказчиком. Далее параллельно. Стартует разработка харда и по мере роста нагрузки нанимаются по минимуму спецы узкого профиля, рабочие (монтаж...). К середине срока полная загрузка + 2-3 спецов, один монтажник" Оказивается много гениев ходит-бродит по стране.. 2 спеца за 1.5 года вертолетний радар могуть.... От антенни до софта! Завидую! Мейл для связи с таким не дадите?

Так ети есче в 2000 ASIC сами целенаправлено делали. Триумф вроде називался.. Помоему даже весь бекенд сами. Может и прототипировали ченить но ето не fpga в asic. Да и контора из сан жозе (производство и маркетинг) .....

Всем доброго дня. Чисто интересно - ктонить смог таки перевести fpga в asic и начать его производить? Или на етапе економики все потеряло смисл?

Насколько знаю ATPG тулза типа Енкаунтер Тест может автоматом RAM ROM захавать но... Для того чтоби увеличить фолт кавередж остальной цифри за счет дополнительних контролируемих шин через память. Типа DOUT, DIN. Но ето не годится для теста самой памяти, плюс замедляет ATPG... Потому не особо используется. Для памяти обично нужен спец алгоритм которий сделан в Bist блоке или просто 'в ручную' через тест порт

... Много ви понимаете в hi-end звуковой технике и ее маркитенге....

-—-------------- .... А вообще, злие ви все троли..... У меня вот подшивки журнала Радио аж с 1976года... Я и 6Н1П в руках держал и КТ315Б паял (кстати схемка више какраз на них класно получалась) ... ... Прям понастальгировал наночь.... Передо мно сейчас 2 справочника Полякових: 60х и 80х годов... В первом схема УЗЧ на 6Н1П а во втором на КТ315Б. Теория одинакова - АВ режим, но схемки несколько другие. Там дроссели а там резистори.... Так вот, по тойже причине схемка приведенная више не очень подходит для того чтоби стать микросхемкой.... ----------------- В случае с автором топика, яби не схемку предлагал, а 'експертние услуги" в области звуковой техники. Тут скорее надо уметь нарисовпть АЧХ/ФЧХ " той самой с ламповим звучанием" схемки. А уш в силикон ето ляпнуть много умних найдется.... Нифига подобного. Если с вас тупо требуют детальний спек то бегите от таких подальше.... У всех адекватних компаний, спек - ето совместная работа с заказчиком. А заказчик вообще часто не очень внятно способен виразить свои мисли....

Могу предложить команду опитних аналогових дизайнеров. Сделают звуковой уселок любой. Layout, DFT, характеризейшен, тестирование, демо плати итд. готовое под ключ. Тулзи свои, фаб на вибор. Думаю и по 0.5дол получится.... Даже за наш счет разработка. С вас - гарантии на закупку партий от 100млн.шт. /месяц :)

Я так понимаю вопрос "а что ми верифицируем" не ставится.... А начинать надо именно с етого.... Ато с пушки по воробьям получится. Долго и не ефектмвно.

A у меня каденс сапортил тулы поверх центоса аж бегом.

Рад за вас, что нашли команду которая ваше приложение так чисто исполняет. Держитесь за них :) Из опыта миксид сигнала разное было. Аналог не работает по причине: - ошибка в DFT аналога и нельзя померять, проинвертирован ресет, токи по подложке сбивают уровни с флешки, шумит бендгеп неизвестно от чего, из-за паразитов осцилятор выдаёт PRBS итп. Всё изза разгельдяйской верификации, сжатых сроков и студентов. - в другом проекте дизайн через пень-колоду вне маршрута и быстро с верификацией процентов 20, но всё работает с первого раза благодаря экспертам-дизайнерам - в третьем супер верификация, трекинг багов, ревью, кавереджи, намаз после каждого недельного релиза итп. В результате закоротка в супер реюзнутом IP из-за аккуратного фикса варнинга DRC :) - пробой ESD. Ну не могут люди этот секретный супер блок сдизайнить.

Ok. LCD висит на I2C. На нем же висят AUDIO, EEPROM итд. Если один из них занял порт то ви прави - остальние курят.... Но зачем другим полезним функциям MAIN липнуть? Например можно продолжать реагировать на кнопки, усреднять измерения АЦП итд.

LCD драйвер реализует программный I2C. Соответственно если он идёт в MAIN то забивает надолго любую другую активность. А в отдельном потоке он работает паралельно и не видимо.

Спасибо за дельный совет. Решение красивое и полностью в концепте ООП. Пробую реализовать. Планирую передать объект Command (объект практически та-же структура). Это прекрасно сработает для передачи команды с параметром (данными) от MAIN в таск драйвера. ++++++++++++++++++++++++++++++++++++++ А что делать для команды чтения (типа ReadID например)? Думаю в обратную сторону можно очередь только для голых прочитанных данных использовать. В неё драйвер вложит результат после приёма объекта Command::ReadID. Соответственно со стороны MAIN нужно выдать в командную очередь объект Command::ReadID и делать периодический поллинг появления данных в приёмной очереди (это и будет ID). После получения данных команду ReadID можно считать завершенной. Подскажите пожалуйста если есть другие варианты.