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

А двуклоковое FIFO разве не является самым простым решением ?

На кой там фифо?

Вот так нужно:
Нажмите для просмотра прикрепленного файла

Само собой обратный сигнал не нужен.

А хватит ли скорости такого вот Handshake ?

А чего бы не хватить. У нас частоты 3 к 1. Т.е. у нас 3,33 такта быстрой частоты чтобы защёлкнуть медленную. Пересинхронизация занимает максимум 3. Т.е. всё отлично пролазит.

Добрый вечер. По поводу фифо думал, но честно говоря не понял как избежать его переполнения. Что же касается 2-ого варианта, то я так понял, что sender должен быть реализован в плис, т.к. АЦП никаких сигналов кроме данных выдавать не умеет. Но в этом случае нужно, что бы sender говорил, мол у меня есть данные, забирай. Но при каком условии он должен это сообщать?

Приветствую!
Странно - Вы пишете что АЦП пишет на 30 MHz а обрабатывать (читать) Вы хотите на 100 MHz - как в таком случае может переполнится фифо?

Удачи! Rob.

Немного не так выразился. Я хотел сказать, что фифо наоборот, опустеет. Если я туда пишу на частоте 30 МГц, то будет момент, когда в фифо ничего не останется. В этом случае, период стробов на выходе будет гулять. Впрочем я вот сейчас подумал, что если у меня там всёравно дециматор будет стоять, то наверно это ведь не так и страшно, лишь бы он (дециматор) успел выполнить свою задачу между приходом этих стробов. В этом случае, фифо и впрямь самый простой и надёжный способ. Но вот по поводу второго варианта, я так и не допёр. И ещё, подскажите, как правильно в моём случае задать констрейны? В примерах есть лишь вариант, когда плис вместе с тактами выдаёт данные, но вот когда она даёт клок а принимает данные, такого я не нашёл. Подозреваю, что ограничения должны задаваться относительно 100 МГц но как в этом случае учесть задержки в блоке ddr с которого и выходят 30 МГц? Или просто посмотреть задержку в даташите и прибавить к общей?

Значит сигналом поступления данных будет фронт клока от АЦП.

Не понимаю. Клоки для ацп генерит плис. Т.е. Вы хотите сказать, что необходимо отлавливать фронт клока 30 МГц с помощью стандартной схемы определения фронтов (которая будит тактироваться клоком 100 МГц)?

Приветствую!
А мы уж тем более не понимаем что и как у Вас там работает
АЦП у Вас работает непрерывно? Выдает на каждый такт 30MHz новый отсчет?
Тогда просто суете эти данные на вход FIFO клок на запись которого эти же 30MHz. На выходе этого FIFO на частоте чтения 100MHz будет периодически появляется сигнал valid говорящий что есть новый сэмпл от АЦП. Можете сразу обрабатывать - можете подождать пока накопится некоторое количество и обработать пачкой это как удобнее будет.

Удачи! Rob.

P.S.
Что касается времянки - оцените для начала задержки на пути
ODDR -> clk_pin -> board_net -> ADC_clk -> ADC_data -> board_net -> data_pin -> in_reg
И если она будет соизмерима с периодом 30MHz тогда можно возится с board_deskew схемой тактирования.
Ну а если меньше то можно тупо зафиксировать регистры в IOB и не не мучатся.

Да именно так.


Только сделанная правильно с присутствием синхронизатора.

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

Именно так я и сделал.


Поясните пожалуйста за синхронизатор. В книге 100_Power_Tips_for_FPGA_Designer написано что одна частота "относительно" болшьше другой. У меня разница всего в 3 раза. В этом случае я не совсем понимаю как синхронизатор должен выглядеть. Вот есле как на картинке, то мне то же кажется что не заработает. Можно наверное конечно 3-ий триггер добавить... но всёравно не понятно...

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

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

Удачи! Rob.

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

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

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

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

Удачи! Rob.

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

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

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

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

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

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

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



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

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

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

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

Удачи! Rob.

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

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

____------
_-_-_-_-_-_

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

_______-----

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

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

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

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