что-то форум слегка глючит и сообщение куда-то пропало. пробую ещё раз

доброго всем времени суток.

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

у меня есть 2 тактовых сигнала с близкими частотами, например, 125 и 130 МГц. они стартуют в разные моменты времени и по идее, рано или поздно их передние фронты должны совпасть. вот этот момент и нужно определить - то есть сделать схему совпадений для тактовых сигналов.

есть какой-нибудь _простой_ метод, позволяющий это сделать? может, какая-нить хитрая мегафункция имеется...

ЗЫ. пользуюсь Quartus, если это имеет значение.

NXOR попробуй

Сначала объедините по И оба сигнала, затем этот объединенный и сигнал более высокой частоты
подайте на xor.
Осталось отловить тот тактовый период, на котором не будет импульса на вых. xor

Странная задача. А смысл в чем?
По идее Вы можете работать только в дискретах. Берете например частоту много выше например 500 мГц. Стробируете ею эти клоки. И анализируете по обоим каналам, когда совпадут состояния 01 (xor не подходит, если надо анализировать какой то один перепад). И зачем это надо. Ведь не определить количество этих совпадений в дискретах этой 500 мГц частоты.
Верилог:

module comp_clk
(
input clk_500,
input clk_125,
input clk_130,
output out
);

reg [1:0] shift_left_rga;
reg [1:0] shift_left_rgb;

always @(posedge clk_500)
begin
shift_left_rga <= {shift_left_rga[0], clk_125};
shift_left_rgb <= {shift_left_rgb[0], clk_130};
end
assign out = (shift_left_rga == 2'b01) & (shift_left_rgb == 2'b01);


endmodule

Я бы сделал так:
1. Рассматривать один сигнал как клок, другой - как данные.
2. Приготовить из клока задержаный на небольшое время. Этоя время будет задавать точность, с которой определится время совпадения фронтов.
3. Данные щелкать в регистры (возможно, в 2 для убирания метастабильности) по клоку и задержаному клоку.
4. Если защелкнуто по клоку 0, а по задержанному 1, то был фронт в промежутке между.
Эта система определит совпадение фронтов, если фронт по данным пройдет позже фронта клока. Чтобы не потарять ситуацию, когда фронт данных ранише фронта клока - либо меняете местами клок и данные, либо задерживаете данные и дважды клок - сообразите сами, писать лень.

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

Ну например если использовать PLL то можно там вывести смещенную по фазе частоту клока.

Чувствуется ехидная ирония
Зависит от задачи: если только моделирование - то assign clk1=#0.5 clk
Если в железе - использовать pll, или цинично пропустить через несколько лог. элементов (умоляю, не надо мне объяснять, что в парадигме синхронного дизайна это моветон, я знаю и мне стыдно ) .
К сожалению, задача поставлена некорректно, т.к. не задана точность (и вообще похоже на учебную задачу). В симуляторе, например, ждать совпадения 2-х произвольных фронтов можно очееееень долго.

А чем такой подход не нравится?
Только здесь еще будут выделяться совпадения по спаду, надо придумать как их отбрасывать

// Эта система определит совпадение фронтов, если фронт по данным пройдет позже фронта клока. Чтобы не потарять ситуацию, когда фронт данных раньше фронта клока - либо меняете местами клок и данные, либо задерживаете данные и дважды клок.
И что в результате. Получим два отклика по одному фронту? А длительность этих откликов уже никому не нужна?.На какой частоте приемника можно уверено зафиксировать такой импульс? Да еще соблюсти времена установки данных для корректной работы в программируемой логике.
Все что Вы предлагаете, это по сути эквивалент решения, приведенного мною Выше. И ничего другого быть не может.

Вы невнимательно прочитали мой пост, или не подумали, а ведь собирались дальше сами. Замечу, что у меня выходной сигнал находится в тактовом домене - или обычного или задержанного, как сделаете.

Все в мире эквивалентно, ибо имеет одного создателя. А дьявол кроется в деталях. Если в задаче поставить точность 1 нс, то моим способом можно сделать, а как сделать внутреннюю частоту fpga 1 ГГЦ? Тогда надо вводить фазовые сдвиго Вашего базового клока на 90, 180 и 270 градусов и работать в их доменах, тогда частоту можно уронить в 4 раза.

1. У Вас на выходе асинхронная игла с неопределенной сколь угодно малой длительностью. Что потом с ней делать дальше?
2. Причем при точном совпадении фронтов ее длительность =0 (если пренебречь задержками в И), т.е. возможна потеря.
3. Выходной сигнал будет всегда, если на И исказится положительный полупериод быстрейшего клока, т.е. время совпадения жестко определено и равно половине периода быстрейшего клока.

///Вы невнимательно прочитали мой пост, или не подумали, а ведь собирались дальше сами. Замечу, что у меня выходной сигнал находится в тактовом домене - или обычного или задержанного, как сделаете.
Вы оперируете одним периодом этого клокового домена.
Во втором Вы действительно подхватите этот пичок. И получите импульс в период. А если фронт удасться зафиксировать и в следующем периоде, зафиксируете длительность в два периода. так и будете вобулировать. Хоть и не царское это дело, может напишите модуль?

Вы имеете в виду ситуацию, когда частоты близки и фронты будут совпадать с заданной точностью в течение не одного, а N периодов? Да, такое возможно, на выходе будет не однотактный строб, а длинный - ну выделите из него фронт стандартной цепочкой из 2 триггеров и xor, если задача это требует. У Вашего кода будет такой же недостаток.

A propos а что такое "вобулировать"?

Вам должно быть стыдно:

Без сброса, убирания метастаб. и пр.

Согласен

Вы имеете в виду ситуацию, когда частоты близки и фронты будут совпадать с заданной точностью в течение не одного, а N периодов? Да, такое возможно, на выходе будет не однотактный строб, а длинный - ну выделите из него фронт стандартной цепочкой из 2 триггеров и xor, если задача это требует. У Вашего кода будет такой же недостаток.

Стыдиться мне нечего. Дальше фронта не пошлют. Меньше взвода не дадут. У моего кода нет такого недостатка.

Есть. При соотношении частот 500/130/125 Мгц Ваш код на каждое совпадение выдаст банч из примерно 6 импульсов. Между импульсами будут пробелы по 3-4 такта. А при другом соотношении частот число импульсов изменится.

Решал однажды такую задачу. Не всё так просто, как кажется :-)
Было две основных проблемы:
1. При обозначенных частотах сравнение фронтов будет довольно сложным из-за разных и, к сожалению, изменяющихся при перекомпиляциях, временных задержек внутри кристалла.
2. В моём случае надо было не просто просигнализировать постфактум о том, что совпадение было, а предсказать - что на следующем фронте оно будет или что на следующем его уже не будет. Подразумевалось, что за совпадение фронтов принималось время +/- 12% от длительности единички наибольшей частоты.
ЗЫ: Использование PLL может помочь только если хотя бы одна из частот достаточно стабильна.

уххх, граждане.. ну и дискуссию устроили только драться не надо, ОК

кто-то говорил. что похоже на учебную задачу - да, так и есть - в первом посте я это и написал.

в общем, буду переваривать всё здесь сказанное, хотя наверное надо менять алгоритм.

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

спасибо, всё написанное пригодится. :!:

Посмотрите у Xilinx XAPP250 - там есть схема на двух триггерах и одной логике, IMHO то, что Вам надо.