topor_topor

"уменьшает время, но сдвигает его" - сложная формулировка... честно говоря даж нарисовать не смог... "на быстрых тактовых выигрывали unbuffered, на медленных - buffered" - сложно коментировать даже.... Если это результаты измерений - очень интересно их увидеть... Кажется тут кто-то насчитал (а не намерял) вероятностей и просто начал играться математикой... позабыв проверить, а соответствуют ли матмодели реальности.... Пытаться доказать что-то математику, оперируя понятиями "вичисленных" вероятностей безсмысленно - на неправильных матмоделях результат всегда матиматически-единственный (и не верный, если модель не верная)...

так в итоге, буфер уменьшает время пребывания в метастабильном состоянии или увеличивает? Как это обясняет что в библиотечных синхронизаторах стоят быстрые тр игеры и нет буферов?

ну ОК. 1) допустим метастабильность FF1.Q медленно ползёт к 1. По вашему каждый следующий буфер должен ускорять это приближение к 1 и тем самым с буферами метастабильность быстрее достигнет 1 чем без. Такая ваша логика? 2) Или всётаки из-за разброса уровня перехода (0.5) на каждом буфере, метастабильность FF1.Q медленно ползущая к 1 может быть перенаправлена буфером в 0, следующим буфером назад 1, след в 0 и.т.п... Так помоему мы получим длительные колебания около 0.5 (удлинение метастабильности), вместо изначального медленного стремления FF1.Q к 1.... Собственно, это и обясняет почему синхронизаторы не содержат буферов и почему комбинаторика на выходе удлиняет метастабильное состояние.

1) ну поверим секретной "информации, которая под NDA от SMIC" что подача 0.5 с меньшей вероятностью даст метастабильность чем изменение уровня во время клока (но как вы написали "вероятность, в общем, не сильно менее")... физически по-моему суть процесса одна и та-же... 2) следуя вашей логике, на первом буфере метастабильность должна исчезнуть вообще и дальше не пойдёт (а вместо метастабильности (уровень 0.5), побежит усиленный 0 или 1). Таким образом, наличие логики решает проблему с метастабилтьностью полностью. Как метастабильность пойдёт дальше если первый-же усилитель её превратит в 0 или 1? По вашему, время пребывания FF1.Q в метастабильном состоянии действительно должно сократится до задержки распространения от FF1.Q to BUF1.Q. Но метастабильность на вход FF2.D попасть вообще не должна в этом случае.... А синхронизаторы зачемто без логики внутри....

1) ничего не платим. Просто правильно подаём внешний сигнал на FF.RN (см ответ ViKo) 2) единократная подача (в начале) синхронного сброса (тоже что подача 0 на вход FF.D) ничего вообще не даёт, кроме понижения максимальной частоты (сложнее комбинаторика перед тригером). И к тому-же, как ни крути, синхронный сброс всё равно надо делать с внешнего асинхронного сигнала (как минимум это один модуль для формирования общего синхронного сброса). 3) предпочтительнее не парится о ресете вообще . При синтезе все тригеры можно подключить к глобальному ресету (с оговоркой п.1)). 4) для ASIC всё то-же самое.

откуда такие данные что более а что менее вероятно? Насколько я знаю - это равноодинаково. ----- Итак... Мы обсуждаем способ борьбы с метастабильностью, где за счёт кодировки состояний, модуль, попавший в метастабильность, либо переходит в следующее правильное состояние либо остаётся в ресете после снятия сброса. Мы установили, что: 1) подача 0.5 уровня на вход или изменение данных во время клока равновероятно устанавливает тригер в метастабильное состояние. 2) мы поняли, что комбинаторика на выходе метастабильного тригера скорее увеличивает время метастабильности. 3) мы предположили, что следующий фронт клока выводит тригер с метастабильного состояния за время ~0.5 clk-to-out. При этом, за счёт HOLD time delay метастабильное состояние гарантировано удерживается на входе следующего тригера в момент прихода фронта клока и как следствие имеем ситуацию п.1). Выводы отсюда такие: а) в общем случае, блоки имеют комбинаторику на выходе. Согласно п.2) время пребывания такого блока в метастабильном состоянии увеличивается. б) Если метастабильное состояние сохранится до следующего фронта клока (а согласно п.а) этому способствует схема), то согласно п.1) и 3) Х может попасть в следующий тригер и .т.д (Х побежит по схеме) в) предложенное решение (" кодировки состояний, модуль, попавший в метастабильность, либо переходит в следующее правильное состояние либо остаётся в ресете") не только не способствует подавлению метастабильности, а наоборот (за счёт комбинаторики) способствует её распространению. Правильно?

Выходит что подача 0.5 на вход тригера не приводит к его переходу в метастабильное состояние, или намного мало вероятнее, чем изменение уровня во время клока? Или всётаки полууровень и изменение уровня во время клока равновероятно поставит тригер в метастабильность?

...честно говоря сказанное тут противоречит тезису "элемент имеет очень нехреновый КУ по напряжению, поэтому, ....., тем ниже вероятность того, что ... сигнал так и останется между порогов 0/1, а не придет к какому-то четкому уровню" и "То есть, самый худший случай, это когда выход триггера соединен прямо с входом следующего." И обяснение это скорее сомнительное но... Тем неменее вывод о том, что " решение с подряд стоящими быстрыми FF самое удобное, потому что универсальное, на все случаи жизни точно работающее" - совпадает с тем что многие пишут. --------- А что-же делать с HOLD тайм задержкой которая продержит метастабильность после 2-го фронта клока (который укоротит время метастабильности до 0.5clk-to-out)?

интересная информация. Насчёт "<= половины стандартного его времени clock-to-output" это я какраз про время метастабильности вообще от фабов слышал, а никак не второго такта. В любом случае, HOLD time задержка "удержит" метастабильное состояние во время активного фронта на следующем тригере и он его поймает. Насчёт комбинаторики... По вашему выходит, что идеальный синхронизатор это 2 FF между которыми максимум буферов... А почему-то у всех фабов синхро-эдлементы сделаны наоборот без буферов и с флопами побыстрее....

1) "выходит из метастабильности за <= половины стандартного его времени clock-to-output" - это речь о времени метастабильности вообще или именно о "следующем такте который удаляет метастабильность"? 2) А время метастабильности на следующем FF.D, как по вашему зависит от наличия\отсутствия комбинаторики на проедыдущем метастабильном FF.Q? Не увеличится ли оно?

Не согласен. Если на тригер подать константу 0.5 и клок, то тоже получим метастабильность на выходе. и чё при этом с комбинаторикой на его выходе будет и как долго? У вас есть где про ето почитать с полной научной выкладкой? И даже если предположить что это правда (следующий такт удаляет метастабильность), то как минимум Х продержится HOLD время и испортит следующий тригер.... то что клока долго нет после ресета - так это решает вообще все проблемы, которые мы обсуждаем тут :) От только обычно он есть.

2) да и при этом всё должно работать после глобального "да", с учётом что каждый модуль может случайно стартовать с состояния RESET или STEP1.... можна систему построить так, но это сложно думать и только ресурсозатраты... не проще, ли дать чистый ресет и в нужное время? 3) тут я не очень понял... о каком входе и открытом ключе речь? Вы говорите об одном и том-же тригере который попал в метастабилтьность? Вы может имеете в виду, что приход следующего фронта клока на метастабильный тригер делает его гарантировано НЕ метастабильным? как-то это странно... да и чё при этом с комбинаторикой на его выходе будет и как долго? У вас есть где про ето почитать с полной научной выкладкой? И даже если предположить что это правда (следующий такт удаляет метастабильность), то как минимум Х продержится HOLD время и испортит следующий тригер....

Тригер Шмидта от метастабильности не спасает. Он спасает от медленного фронта, и помех на уровнях с малой амплитудой. Даже если идеальный фронт снятия ресета произойдёт на активном фронте клока - тригер может стать метастабильным.

Интересное решение.... Помоему в этом случае будет так: 1) " в этом случае он либо не изменится, оставшись в состоянии резета, либо изменится корректно, либо останется в метастабильном состоянии до следующего такта и Х побежит по всей схеме" 2) Может конечно для вашего устройства и не проблема, но в общем случае, нехорошо если часть модулей схемы "останеться в состоянии резета", а другие "перейдут в другие корректные".... 3) А что касается метастабильного состояния - МОЖЕТ оно длиться больше такта клока. Длительность метастабильного состояния какраз схемой на уровне транзисторов и определяется (в том числе и паразитными ёмкостями, и .т.д). Это время от клока никак не зависит и очень даже может быть более периода (при быстром клоке). Особенно, если выход тригера (Х) проходит через комбинаторику (это не я сам мерял, а ссылаюсь на то что читал в работах других людей). правильное решение

чёто неочень понял.... 1) Ошибку, при которой асинхронный сброс не привязан к клоку может выловить STA анализатор (только обяснить ему надо что сигнал RESET таки асинхронен остальной части схемы). 2) Коректно спроектированная схема с асинхронным ресетом - это та, где на любом входе FF.RN (кроме синхронизатора конечно) никогда не бывает никаких метастабильностей и Х. Как есчё по вашему можно "правильно спроектировать схему", чтобы она работала корректно, если на произвольном тригере из-за проблем с ресетом возникла метастабильность? 3) Записанный Х в регистре - какраз очень соответствует физической реальности, а именно - метастабильному состоянию (оно кстати очень даже может длится более такта клока).

А озвучить эти аргументы вы можете? Очень интересно Да, и что именно понимать под "синхронным сбросом"? Единоразовю загрузку 0 во все тригеры, после включения питания, через отдельный вход по первому активному фронту клока? И чё тут тесбенчу симулить-то? Это прекрасно делает STA анализатор..... Но если хочется - то можно и такой исключительнй момент просимулить. Получите Х - что и покажет наличие метастабильности. При этом, если асинхронный ресет сделан правильно ("привязан к клоку"), то этот Х дальше тригера-синхронизатора никуда идти не должен, и вся схема будет симулится без проблем.

Тулза покажет что сигнал РЕСЕТ меняет своё состояние как минимум (code coverage), а как максимум - покрыты ли заданные временные соотношения (functional coverage). Правда последнее, надо описать вручную, и это описание должнопокрывать возможные "глюки"... Или "глюки" - это не комбинация входов модуля, а о помехи, гонки, снятие ресета во время активного клока и т.п.?

COVERAGE DRIVEN TEST BENCH - это сейчас просто основа верификации... тулза которая этот COVERAGE считает какраз и показывает что покрыто тестом, а что нет.

1) в цифру вообще глобально и в принципе недопустимо заводить никакие асинхронные сигналы (все помнят про метастабильность) И заводить никакие сбросы тупо снаружи даже на входы тригера с именем "асинхронный сброс" тоже нельзя (если он снимется в момент активного фронта клока будет метастабильность) 2) Если на FF.RN вход каждого тригера FSM запустить сигнал, с выхода FF.Q - то это можно и нет проблем (при условии что все эти FF имеют одно и тоже CLK ). И в этом случае даже ненадо ничего специально "прослеживать и контролировать". Тулза это легко и правильно делает сама. В FPGA это правда плохой стиль так ресеты подключать...

Тут скорее стоит вопросс синхронный сбросс (реализуется как вход данных =0) vs асинхронный (специальный вход). Моё мнение такое: 1) Если все тригеры всегда сбрасывать Асинхронным сбросом то схему проектировать легко, меньше "неучтённых" состояний, нет проблем с симуляцией и.т.п Тоесть, тотальное использование асинхронного сбросса это легко и правильно. 2) Асинхронный сбросс скорее ускорит Fmax, т.к. не будет лишней логики на данных как в Синхронном сброссе. 3) Асинхронный сбросс надо "привязывать" к системному клоку во время снятия. Иначе если он снимется на активном фронте клока, то вся схема впадёт в метастабильность.... ----- 4) Действительно, не все тригеры нужно сбрасывать... Это зависит от логики работы устройства. В каждом таком случае надо продумывать все возможные ситуации.... 5) Если не все тригера сбрасывать, то схема может не симулится из-за Х, но при этом всё в ней правильно... Прийдётся заставлять симулятор работать специальными командами. 6) Тригер с асинхронным броссом больше по площади. Соотв. можно её экономить... но это не в FPGA, ибо там все тригеры уже с асинхронными ресетами... ----- 7) спроектировать цифру с только с Синхронным сброссом (кроме может модуля управления стартом) можно, но сложно. Это где модули переодически возвращаются в исходное состояние перед началом нового цикла (хотя можно и асинхронно переодически сбрасывать модули, но немного сложно такое правильно констрейнить и в FPGA так не эфективно). 8) Если схема имееет Синхронный переодический сбросс, то она потенциально более устойчива ко всяким физическим воздействиям. 9) Реализация глобального Синхронного сбросса, который срабатывает только один раз ничем не лутше простого Асинхронного. ----- Если вы делаете проект под FPGA, не заморачивайтесь - используйте глобальный асинхронный сбросс. Кстати, в некоторых FPGA его можно даже в RTL не описывать, а указать при синтезе, чтобы все тригеры к глобальному ресету подключились. На проблемы с частичным асинхронным сбросом стоит идти только ради площади ASIC и-то в технологии >=1um

Судя по проявлению проблемы вам скорее всего надо решить проблему с согласованием линий передачи. Относительно констрейнов... сложно ответить не зная шинного протокола, может вам и установок поумольчанию достаточно.... Может надо external delay (set_out_delay) задать....

1) STA констрейны нужны для того чтобы заставить тул выполнить необходимые вам условия. Для этого надо сначала составить список этих условий. Неработоспособность устройства по неизвестным причинам не есть основанием для создания констрейнов. 2) дпаже если вы никаких констрейнов не задали, тул всёравно считает все сигналы синхронными и применяет дефолтные констрейны к ним. 4) В вашем случае алгоритм действия такой: - При помощи осцилографа понять почему данные приходят битыми (или задержки в линии не те, или помехи возникают из-за рассогласования линии передачи или кростолка и.т.д.) - Если проблема именно в задержках в линии передачи (не согласованность данных и клоков и.т.п) то указать, что именно надо изменить и почему дефолтные правила STA не помогли.

А что делает анализатор если никакой констрейн не задан для пути? Не по дефолтным-ли правилам (по дефолтному констрейну) он его обрабатывает? Если по дефолтному, то что это за дефолтный констрейн интересно узнать....

Короче в таком случае только одно поможет - рукосуйство делаем SP&R, при этом тригер идущий на выход желательно плейсим в ручную в фиксированное место. нужный HOLD TIME набираем ручным-же втыканием буферов... для 2нс думаю штук 5 хватит....

Учтите, без лицензий на тулзы фабы ничего не делают... 10$-20$ -это за штуку похоже... не понял сразу... подумал 20К$ за маски... Всётаки какие расходы на подготовку производства включены? для ваших 500МНц - 90нм надо а то и меньше... тут уже и пара соо тищ $ только на маски... Если образци в НИИ, а производство где? По той-же технологии?