[Грендайзер 0]

Схема выделения фронта приведенная Вам будет работать если добавить еще 1-2 регистра в цепочку на входе для подавления метастабильности.

Я так и думал. Правда не понятно другое. Если в цепочке триггеров произойдёт метастабильность (а она произоёдёт, ведь фронты то "плывут" относительно друг друга), то после того как триггер из этого состояния выйдет, есть вполне реальная вероятность что в какой то момент времети после метостабильности на выходе триггера будет присутствовать не верный уровень, который в итоге "пролезет" и на выход схемы. Наверно если бы отношение частот было хотя бы на порядок больше то это явление наверно было бы довольно редко, но в данном случае отношение всего 3... и как мне кажется схема будет работать не очень надёжно :05:

Изменено 4 июля, 2018 пользователем Грендайзер

[RobFPGA 27]

Приветствую!

 

Цепочка последовательная триггеров на входе как раз и служит чтобы на выход этой цепочки не попал непонятно какой сигнал а только 0 или 1. Каждый триггер в цепочке уменьшает вероятность этого печального события. Причем чем выше быстрая частота тем длинне цепочка требуется.

 

Но это не имеет отношения к плаванью фронтов. Фронты и так будут плыть так как 30MHz и 100MHz не кратные и не синхронизированы.

То есть на выходе тут будут импульсы со скважностью 3 и реже 4 .

 

Удачи! Rob.

[Самурай 12]

Добрый день. Возник такой вот вопросик. Есть отладочные платки на с Spartan-3 и простеньким АЦП. Плата с АЦП тактируется с помощью платы с ПЛИС. Тактовая частота спартана 100МГц, а частота тактирования АЦП 30МГц (данная частота получается с помощью связки DCM -> OFDDRCPE что в коргене обозначатся как Clock Forwarding/Board deskew). Данные с АЦП сперва идут на DDC а затем на CIC. Всю дальнейшую обработку хотелось бы вести на частоте 100МГц. Однако, очевидно, что т.к. частоты не кратны, одна относительно другой будет "плыть". Так вот вопрос какправильно перейтти с частоты 30Мгц на 100МГц, т.е. как корректно защёлкивать данные идущие с частотой 30МГц частотой 100МГц (пока лишь приходит мысль воткнуть ещё одну DCM и сделать на ней частоту в 90МГц или 120МГц)?. Однако этот вариант имеет свои минусы. И 2 вопрос, как будит выглядить UCF файл для такого случая (т.е. когда клоки идут С плис, а данные НА плис).

 

А позвольте поинтересоваться, а на кой Вам «всю дальнейшую обработку хотелось бы вести на частоте 100МГц»? Какой Вы профит от этого хотите поиметь? Геморрой Вы, как можно заметить, уже поимели... И поимеете еще больше, когда на 100МГц начнут сыпаться констрейны...

 

Можно конечно предположить, что Вы таки хотели бы сэкономить аппаратные ресурсы, работая на кратно большей частоте и перейдя от параллельной к последовательной форме реализации своих алгоритмов. Но пока из Ваших текстов видно, что Вы даже в принципе не подозреваете о такой возможности... Да и ради одного банального DDC нет особого смысла страдать такой фигней. И можно предположить, что после CIC Вам таки совсем все равно, 100 у Вас МГц тактовая, или 30...

 

Так зачем Вам 100МГц?

 

[Грендайзер 0]

Так зачем Вам 100МГц?

Ну во первых сама по себе задача увязки клоков весьма важна и интересна. Во вторых я и впрямь хочу поэкономить ресурсы, т.к. плиса у меня маленькая, а помимо указанных блоков там будет стоять несколько КИХов, которые пожрут почти все умножители нуууу и ещё кое какая переферия. Что же касается констрейнов, то как мне кажется, в моём случае 100МГц частота вполне съедобная.

 

К сожалению всё равно не понимаю, как синхронизатор поможет, если на выходе триггера присутствует неправильное значение. Ну да Бог с ним... Я так понял, что всё же фифо самый простой и надёжный вариант. Подскажите ещё такой вот вопросик. Допустим у меня есть 2 разных тактовых сигнала. При том один больше второго. Допустим я хочу отловить фронт более медленного. Допустимо ли завести более медленный сигнал на информационный вход триггера (пусть клоки синхронны) в схеме определения фронтов?

[MegaVolt 25]

Если АЦП выдает данные каждый такт то вышеприведенная схема с синхронизатором работать не будет .

Удачи! Rob.

Какие ваши аргументы?

 

Синхронизатор на картинке в посте#3 рассчитан так что данных на шине sender должны стоят стабильно пока не придет обратный handshake сигнал от receiver. А для этого по картинке требутся как минимум 2 такта быстрой и 2 такта медленной частоты. Но ведь АЦП выдает на гора отсчет кажый такт!

Я же сразу написал что обратная цепочка не требуется. Т.е. строб о появлении новых данных пересинхронизируется на выход и защёлкивает ещё не изменившиеся данные.

 

 

 

К сожалению всё равно не понимаю, как синхронизатор поможет, если на выходе триггера присутствует неправильное значение.

Каждый новый триггер в цепочке уменьшает вероятность неверного значения на выходе. Причём зависимость степенная. И соответсвенно при двух триггерах вероятность пролезания метастабильного состояние через 2 триггера практически невероятна. Через 3 триггера считается достаточным для военных применений :)

 

Ну да Бог с ним... Я так понял, что всё же фифо самый простой и надёжный вариант.

Ну ежели ресурсов немеряно то наверное да. Мой варант проще и предсказуемее фифо.

Подскажите ещё такой вот вопросик. Допустим у меня есть 2 разных тактовых сигнала. При том один больше второго. Допустим я хочу отловить фронт более медленного. Допустимо ли завести более медленный сигнал на информационный вход триггера (пусть клоки синхронны) в схеме определения фронтов?

Да

 

[Грендайзер 0]

И соответсвенно при двух триггерах вероятность пролезания метастабильного состояние через 2 триггера практически невероятна.

Не, про метостабильное состояние это понятно... не понятно другое. Вот картинка. Допустим частота clk1 < частота clk2. В какой то момент триггер d2 вошёл в это самое метостабильное состояние. Допустим, что время этого состояния было не долгим (скажем < чем период clk2). Теперь, кто сказал, что после выхода триггера из этого состояния в точке С будет присутствовать верный уровень... тут ведь как карта ляжет... Например если на момент нихода фронта clk2 в точке B была '1'. Триггер вошёл в метостабильное состояние... а после выхода у него на выходе (в точке С) появился '0'. Тогда триггрер d3 в момент прихода следующего фронта clk2 защёлкнет '0', а должен был защёлкнуть '1'. Ну и пошло поехало... Или я в чём то неправ?

Изменено 5 июля, 2018 пользователем Грендайзер

[RobFPGA 27]

Приветствую!

... Или я в чём то неправ?

Вы все стремитесь в будущее забывая о том что было раньше - попробуете проанализировать ситуацию с учетом того что сначала была тьма 0 во всех точках и тут решили подать свет 1-цу - да неудачно так что событие это в точке B пришлось на начало обеда фронт clk2. Что будет в точка схемы и на выходе через такт, 2, 3... ? Увидим ли мы на выходе полумрак?

 

Удачи! Rob.

[MegaVolt 25]

Не, про метостабильное состояние это понятно... не понятно другое. Вот картинка. Допустим частота clk1 < частота clk2. В какой то момент триггер d2 вошёл в это самое метостабильное состояние. Допустим, что время этого состояния было не долгим (скажем < чем период clk2). Теперь, кто сказал, что после выхода триггера из этого состояния в точке С будет присутствовать верный уровень... тут ведь как карта ляжет... Например если на момент нихода фронта clk2 в точке B была '1'. Триггер вошёл в метостабильное состояние... а после выхода у него на выходе (в точке С) появился '0'. Тогда триггрер d3 в момент прихода следующего фронта clk2 защёлкнет '0', а должен был защёлкнуть '1'. Ну и пошло поехало... Или я в чём то неправ?

Да всё верно. Наличие местастабильности вызовет нестабильность точки перехода из 1 в 0 в один период шустрой частоты.

 

Примерно так:

 

____------

_-_-_-_-_-_

 

выход в хорошем случае:

 

_______-----

 

выход в плохом случае

________---

 

В фифо точно так же есть синхронизатор только он более громоздкий из-за того что нужно передавать не 1 бит а указатель.

 

И эта проблема не лечиться никак. Кроме работы на кратных частотах.

[Грендайзер 0]

Коллеги, очень признателен за помощь. Теперь кое что стало доходить. Всем большое спасибо :)