topor_topor

1) Какого клока нет в report_clocks? 2) Что из себя представляет i_clk_div? 3) А Warning Енкаунтер какой выдавал на "пропущенный" клок?

1) "clk2 нет в клоковом дереве, для энкаунтера это цепь." - точнее, CLK2 не виден в CTE (common timing engine) во время STA. До постройки клокового дерева, Вы скорее не дошли.... 2) "Каким образом clk2 задефайнить? В исходном sdc clk1 и clk2 определены через set_generated_clock." Схему как клоки с осцилятора выходят и в MUX заходят + всё с SDC что к ним относится можно увидеть? 3) "Отчеты у меня сейчас нет, я rtl и лог. синтезом занимаюсь, " - раз вы видите результаты команд - значит есть: Либо копируем текст с экрана, Либо в конце команды добавляем > report.txt 4) Вы синтез Енкаунтером делаете?

1) "Вход выбора не константный, case_analysis не использую" - а репортик report_case_analysis всётаки чё говорит (репорт по выходных AND2)? 2) "report_timing -clock_from ..." - а дальше опции.... Полагаю, репорт -clock_from СК1 даёт результат, а -clock_from СК2 не даёт.... Также предположим что "report_clocks" выдал только СК1... Это так? Тогда ответ простой - Encounter выдает пути лишь по СК1 потому что СК2 не существует. 3) Задефайните СК2 и делов-то.... 4) Если я увижу результаты репортов что просил, будет меньше гаданий и может быстрее.... P.S. "безглитчевый на триггерах " - стрёмно звучит... тут должно быть "безглитчевый на gated_clock_component" .... а иначе только неправильно задай глобальные переменные Encounter ....

1) Как сделан клоковый мультиплексор? Простой МUХ2? 2) Если так, то ч то даёт report_case_analysis по этому МUХ2? Нет ли константы по входу S? 3) видит ли report_clocks ВСЕ Ваши клоки на входе МUХ2? 4) Какой репорт Вам выдает пути лишь по одному клоку? 5) Какая версия Encounter?

Ну если это для синтеза, то надо шдето так (схемой надо думать, а не C++): wire SEL = 1; wire [N:0] D_OUT, dout; // Сдвигаем всё время.... always @(posedge sample ) begin if (!sample_cnt) begin sample_cnt<= 1'b1; dout<=dout<<1; end end // Вставляем когда надо.... assign D_OUT[N:0] = (SEL) ? {dout[N:1], 1} : dout[N:0];

A что это должно быть по смыслу? Либо счётчик, либо сдвиговый регистр?

Они и без особых усилий сами плодяться..... Посмотрите результат синтеза (конечно если синтезатору СЕ флопы загрузили и розрешили) Но ежели розработчик тулзе есчё и поможет - ну тода ваще....

Это 4х от rx_clk=rx_s^rx_d имелось в виду?

1) Это делает САПР 2) Это элементарно.... где 10 флопов имеют одинаковый СЕ, то вместо 10 флопов с СЕ, ставится гейтыд-клок компонент с этим СЕ и 10 обычных флопов. 3) за одно и площадь меньше, ибо флоп с СЕ больше чем без

Судя по картинке, фронты rx_s и rx_d не совпадают и близко не стоят. Судя по всему - это заложено в протоколе.

1) "...сдвинуты на половину длительности информационного символа.." - ну дак инвертор поставьте, в комуникации это любимый способ.... 2) Если Ваш приёмник имеет максимальный клок равный передатчику то выход один - используйте полученный на XOR клок для всей схемы Вашего приёмника. Можно есчё PLL-м привязать врутренний клок к XOR клоку. 3) При этом, приёмник должен успевать забирать входные данные (data rate). Напр. за счёт того, что данные входят последовательно, а обрабатываються паралельно.

"Самая лучшая оптимизация по потреблению - это минимизация схемы (площади), чем меньше сделаешь, тем меньше будет потребление..." - частично правильно но... 1) чем меньше площадь - тем меньше токи утечки - меньше потрибление в спящем режиме (когда клок отключен) 2) основная мощность потребления - это динамический ток, обусловленный частотой переключения тригеров и их количеством. В реальных схемах меняет состояние только порядка 10% тригеров, а это значит что на остальные тригера фронт клока подавать не надо. Тригер на который не подаётся фронт клока потребляет меньше, даже если не меняет состояние. Для этого гейтыд клоки и используются.

1) Я имелл в виду стоимость всего необходимого набора Back End: RCCompiler+SOCEncounter+ETS+EPS+Conformal+EncounterTest Годовые лицензии реально дорогие... Если брать лицензии поштучно и только минимальный набор (напр. без MMMC, без multiply power domain) то может дешевле... Тут надо точно необходимые возможности представлять.... думаю грамотный выбор сэкономит на пару Леонардов.... Кстати, сколько Лео стоит? 2) power optimization любимое дело для ASIC....

А в просто Verilog есчё просче: assign sig = 0; // Все нули

В Veriloge можно так: `define WIDTH 8 assign sig = {`WIDTH {1'b0}}; // Все нули assign OUT_tmp[`WIDTH-1:0] = {OUT_zn, {(`WIDTH-2){1'b1}}};

1) "рассматривается вариант совместного использования синтезатора как для FPGA так и для ASIC" - Как я понял, Вы хотите одни проекты как ASIC делать, а другие как FPGA. При этом, напр. XILINX ISE не подходит Вам для синтеза FPGA по какой-то причине. При этом цель - сэкономить на тулзах, например за счёт использования одного синтезатора. Правильно? Цены конечно продавец тулзов каждому свои ставит, но что-то мне подсказывает, что купить все необходимые тулзы Cadence для ASIC вместе с синтезатором будет не так-то и дорого. Да и навернека Cadence тулзы раз в 100 (я думаю гдето около 1 000 000$ год на ASIC flow) дороже Леонардов.... Смысл на спичках экономить? Для исключения всяких ненужных проблем с совместимостью, а также для использования продвинутых возможностей оптимизации - лутше использовать тулзы одного производителя. Есть и другие моменты, кроме тайминг оптимизации... Например ECO (Engineering change Order ) требует синтезатора, CONFORMAL тоже его хочет.... Хочеш, не хочеш - а купиш.... Placement может розпознать DFT структуры и сделать их реордеринг, а с внешне встроенным DFT - нет... А как синтезить мультиповер, мультиклок домены, а гейтыд клок компоненты для power optimization тоже Леонардо встроит? ... и.т.д. - Я Вам крайне не советую лезть в предложенный производителем набор тулзов и flow for ASIC. - Точно определите что Вам понадобится в flow for ASIC. - В крайнем случае уточните все моменты с Cadence или Synopsys.... 2) " Разве RC Compiler не является для Вас тулзой внешнего производителя " - у меня Cadence ASIC flow.

1) "Собственно вариантов синтеза я вижу уже три: " - добавте есчё 2: - RCCompiler можно есчё и структуру клокового дерева (clock_tree.spec) подсунуть - есчё точнее. - RCCompiler розпознаёт DFT структуры, описанные его командами 2) "покупке лицензии на синтезатор который бы неплохо справлялся с синтезом как FPGA так и ASIC" А это зачем? Если прототипировать ASIC в FPGA то ответ простой - синтез только в ASIC тулзах (FPGA соотв. в Xilinx ISE, который всё равно нада для P&R). И лутше, и проблем меньше! Я не думаю что Леонарду Вы DEF Floor-plane сможете скормить, а уж тем более clock_tree.spec подсунуть.... 3) "результат работы синтезатора связан с количеством и величиной "timing violations"" - Да. Особенно с учётом возможностей п.1) 4) Ежели зачем-то надо и ASIC и FPGA, то лутше подумайте о записи тайминг констрейнтов в SDC формате. Тогда просто будет с одного тула в другой переходить. 5) "возможность синтеза "gated clock" - пока неизвестно" Если у вас gated clock, то какой смысл говорить об FPGA? --------- Как ASIC я-бы очень был-бы недоволен делать синтез в тулзе внешнего производителя, тем более заточенного под FPGA. В любом случае, нетлист после Леонардо можно "пересинтезить" и в ASIC синтезаторе на худой конец....

1) 1-й вариант, здаётся мне - А латч. Изз-за недоопределения А на всех кейсах. Если доопределить - комбинаторный выход. 2) 2-й вариант - комбинаторный выход из-за компаратора. 3) "...5 клоковых доменов, есть и передача импульсов и передача данных и обмен сигналами между автоматами из разных доменов. Поверьте не один день бился с формальным подходом синтезатора и роутера к предлагаемой задаче. ..." Ну в таком стрёмном случае есть 3 простых решения: - задать при синтезе все клок соурсы строго одинаковыми - по наиболее быстрому. Тулза подумает что всё "почти" синхронно... - физически подключить все клоковые входы (напр. мультиплексором) к одному источнику (напр. тестовому клоку) и синтезить как синхронную схему. При этом, генерация тест векторов сильно упроститься (если это ASIC и там есть DFT и тестовый клок)... В FPGA можно по ресету мультиплексор включать на разные клоковые входы, а при синтезе задать константы, переключающие все клоки на один. Это конечно технологическая нашлёпка, но сильно упрощает жизнь. - если первые 2 не нраавяться, ну задать фалс пас от одного клока к другому, при условии что вставлены синхронизаторы между ними. Как тут привязка FSM выходов к флопам поможет - не знаю.

А заблуждение - это потому, что : 1) вставление тригеров на выходах FSM исключает только комбинаторику самой FSM из бщей задержки. А что будете делать когда декодер FSM имеет 1нс, вход другого модуля имеет входную комбинаторику с 20нс задержкой? 2) В технологиях <0.18 задержка определяется длинной проводом а не гейтами - т.е Placement & routing. Как тут тригера по выходу FSM помогут? 3) Ваше решение ну никак не может быть общей рекомендацией при проектировании FSM. Оно может помочь в очень ограниченно-специальных случаях. ------ Кстати, может если в вашем проекте выкинуть все ненужные тригера по каждому выходу FSM, то у тулзы места больше для оптимального Placement & routing появиться, и все слаки сами пропадут? А-то кажеться мне, что количество таких "ненужных" тригеров даже больше количества нужных....

Причины отрицательных слаков могут быть весьма разнообразны. Одной из них может быть то, что комбинаторные задержки >1CLK... Тогда возможным решением может быть как написано выше: "Иногда, в весьма исключительно-ограниченных случаях, приходиться розбивать комбинаторику тригерами на 2 части - чтобы уменьшить комбинаторную задержку. При этом, логика устройства усложняеться из-за задержек на таких тригерах... Но это большое исключение, и относится оно скорее к самой комбинаторике, а не к FSM.... ." Кстати, это поможет только при SET-UP отрицательных слаках.

Это забота тулзы - выполнение нужных задержек. Тулза сама гарантирует чтобы сигнали приходили к последующим тригерам в нужное время. На то тулза и нужна. Даже если Вы пропустите все выходы с FSM через тригера, всё равно при Place & Route тул имеет право сделать розброс во времени между выходами этих тригеров (на конечных точках) в пределах 1CLK. Это и есть принцип синхронного дизайна!

"что бы исключить такую ситуацию, рекомендуется чтобы выходы автомата были регистровыми." - Извините конечно, но это грубое заблуждение. Это забота тулзы - выполнение нужных задержек. И ничего подобного не рекомендуется, не поможет и ненадо... Иногда, в весьма исключительно-ограниченных случаях, приходиться розбивать комбинаторику тригерами на 2 части - чтобы уменьшить комбинаторную задержку. При этом, логика устройства усложняеться из-за задержек на таких тригерах... Но это большое исключение, и относится оно скорее к самой комбинаторике, а не к FSM.... .

Может чё-то я не так понял... с Леонардо не работал но всёже... Мне кажется Вы путаэте 2 независимые вещи: превращение RTL в нетлист (т.е. синтез) и создание топологии (т.е. Place & Route). Все вещи связанные с timing closure выполняются на стиадии Place & Route. 1) "...насколько результат синтеза будет близок к реалиям связанным с размещение компонентов на кристалле" - Не знаю как в Леонардо, но вот например Cadence RC Compiler может втянуть в себя fllorplane (розмер и форму будущей цифры в формате DEF) и произвести оптимизацию с учётом этого. Поэтому, наверно лутше работать с тулзами одного производителя (чтобы они понимали друг друга) Но при этом, розмещение он делает условное. Более того, временные модели при синтезе не точные (wire load). Грубо говоря - с учётом средней задержки на мм^2. Поэтому вопрос " близок к реалиям связанным с размещение компонентов на кристалле" не совсем коректен. 2) О каком "timing closure" речь? Фактически финальный "timing closure" выполняется на этапе Place & Route. При этом понятно что синтезатор не причём... И связывать вопрос о "timing closure" с синтезатором не коректно. 3) Чего то так рогом в синтез упираться? Если что-то можно синтезить в FPGA то оно легко синтезится и в ASIC тулзе - типа RC Compiler. С синтезом синхронных дизайнов - проблем нет. Другое дело если есть необходимость встроить асинхронщину, или какие другие трюки - то это таки зависит от способностей тулзы. Вы лутше подумайте может ли Леонардо встраивать DFT структуры. Тестировать Ваш ASIC наверно всётаки надо....

1) "ведь не всегда переход осуществляется из первого состояние во второе (001 -> 011) иногда надо к третьему (001 -> 010). А это уже "иголка"" - ну не всегда везёт и всё просто и автоматически, но иногда так получается... 2) Иногда можно синтезатор заставить делать кодировку определённого вида, если он конечно умеет.... 3) Ручное кодирование состояний автомата в Verilog: reg [1:0] FSM_seq; reg [1:0] FSM_next; parameter [1:0] STATE0 =0, STATE1 =1, STATE2 =2, STATE3 =3; always @ (FSM_seq) begin case (FSM_seq) STATE0 : FSM_next <= STATE1; STATE1 : FSM_next <= STATE2; STATE2 : FSM_next <= STATE3; default : FSM_next <= STATE0; endcase end always @ (posedge clk) begin FSM_seq <= FSM_next; end

Синтез можно делать в чём угодно - на выходе всё равно нетлист. Эсли Ваша цель нетлист, а не топология то вопрос синтеза ASIC с помощью Leonardo Spectrum - серьезный. Эсли Ваша цель топология - то одним синтезатором Leonardo Spectrum не обойтись.