[DmitryR 5]

Решил я оптимизировать один простой контроллер, чтобы был кратким (как выстрел, ЛОЛ) и полностью конфигурируемым. В частности чтобы можно было ему задавать фронт, по которому работать. Ну и пишу:

 

clocking get_edge @((posedge clk iff a) or (negedge clk iff !a));

 

И сразу же выясняется, что ни clocking, ни даже iff синтезатором (Квартус) не поддерживаются. У кого-нибудь есть идеи, как это сделать элегантно с помощью синтезируемых конструкций? Я понимаю, как это сделать с помощью условной компиляции, но это мне кажется как-то... Не совсем современно, что ли.

[iosifk 3]

Решил я оптимизировать один простой контроллер, чтобы был кратким (как выстрел, ЛОЛ) и полностью конфигурируемым. В частности чтобы можно было ему задавать фронт, по которому работать.

Поскольку исходный постулат совершенно неправильный, то начинать надо не с ответа на пост ТС.

Начинать надо с принципов организации проекта как такового.

Нельзя строить проект вот так:

(posedge clk iff a) or (negedge clk iff !a)); - это вредительство чистой воды!!!

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

[DmitryR 5]

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

[ViKo 0]

У меня такт инвертируется с помощью xor. Но это не основной тактовый сигнал в проекте.

[Димыч 0]

<...> Внутри этого домена активный фронт должен быть только положительный

 

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

 

Бездумно расставлять posedge - negedge конечно нельзя.

 

[Shivers 2]

Топикстартер жжет. Особенно про DDR-триггер порадовало. Конечно, и DDR-триггер можно сделать, но в ПЛИС используются обычные флип-флопы, состоящие из двух защелок с разнополярным управлением (если точнее - однопроводным двухфазным управлением).

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

[Golikov 0]

строго говоря в СПИ иногда надо клок инвертировать:)

 

iff a - это конструкция для условной симуляции

 

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

Кстати там же автор решал проблемы выбора синхронного и асинхронного сброса.

[DmitryR 5]

А вот задач, где надо оперативно инвертировать клок "на лету" я не встречал. Это какая то особо извращенная фантазия топикстартера. По хорошему, лучше идти читать учебник по схемотехнике сначала, а потом браться за верилог.

Почему все всегда подозревают в людях худшее, да ещё и хамят при этом? Я совершенно не собираюсь менять клок "на лету" (в данном случае), а хочу настраивать его константой времени компиляции.

 

 

строго говоря в СПИ иногда надо клок инвертировать:)

Проблема в том, что если я напишу

 

wire real_clk = a ? clk:!clk;

 

то скорее всего получу на самом деле инвертированный клок со всеми сопутствующими прелестями (в смысле инвертированный именно инвертором, на логике), а вовсе не переход на обратный фронт. И вот это уже совершенно нехорошо.

 

[RobFPGA 108]

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

 

Почему все всегда подозревают в людях худшее, да ещё и хамят при этом? Я совершенно не собираюсь менять клок "на лету" (в данном случае), а хочу настраивать его константой времени компиляции.

 

Проблема в том, что если я напишу

 

wire real_clk = a ? clk:!clk;

 

то скорее всего получу на самом деле инвертированный клок со всеми сопутствующими прелестями (в смысле инвертированный именно инвертором, на логике), а вовсе не переход на обратный фронт. И вот это уже совершенно нехорошо.

Почему все всегда подозревают в компиляторах худшее ... А Вы пробовали в реальном проекте ? И для какого типа FPGA?

 

Как Вы думаете если напишете

module bla_bla_bla (....
always @(posedge clk) begin
...
end
always @(negedge clk) begin
...
end

Как синтезатор сделает Вам тригера с инверсными клоками?

 

Удачи! Rob.

 

[DmitryR 5]

А Вы пробовали в реальном проекте ? И для какого типа FPGA?

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

 

Как Вы думаете если напишете

module bla_bla_bla (....
always @(posedge clk) begin
...
end
always @(negedge clk) begin
...
end

Как синтезатор сделает Вам тригера с инверсными клоками?

Никак, но этого и не требуется. Вы не поняли вопрос.

 

[Shivers 2]

Почему все всегда подозревают в людях худшее, да ещё и хамят при этом? Я совершенно не собираюсь менять клок "на лету" (в данном случае), а хочу настраивать его константой времени компиляции.

Хамить и не думал, но - мои извинения.

Не хотите читать учебчники? ОК, извольте:

На верилоге можно много чего написать, но результатом интерпретации должен стать либо флоп, либо защелка. С клоком возможны манипуляции, к примеру - можно мультиплексировать входной клок со своей инверсией (как в Вашем посте). Если же Вы хотите получить флоп, тактируемый передним фронтом, либо тот же флоп. но тактируемый задним фронтом (в зависимости от параметра компиляции) то используйте конструкцию generate, либо дефайны. Но на мой вкус, это уже ветвление архитектуры, и совмещать такое ветвление в одном файле - неправильно.

 

[RobFPGA 108]

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

 

Пробовал, но это не важно, ...

Хи - результат неважен?

 

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

Это абстрактная недостижимая цель. Если пишете для синтеза реального железа приходится всегда иметь ввиду особенности конкретных синтезаторов, целевого железа и структуры проекта. Хотя самый близкий способ к такой "идеальной универсальности" это макросы.

 

Никак, но этого и не требуется. Вы не поняли вопрос.

Проясните что я не понял.

А я поясню мой намек который судя по ответу Вы не поняли -

module bla_bla_bla2(input clk, ...
controller_super_shot #(.clock_polarity_select_lol(0)) i_ctrl_neg (.clk(clk), ...); 
controller_super_shot #(.clock_polarity_select_lol(1)) i_ctrl_pos (.clk(clk), ...);
...
endmodule

Если по Вашему сделать модули с триггерами с инверсными клоками в таком случае "... Никак ..." то зачем Вам тогда делать такой универсальный модуль?

 

Удачи! Rob.

[DmitryR 5]

Если же Вы хотите получить флоп, тактируемый передним фронтом, либо тот же флоп. но тактируемый задним фронтом (в зависимости от параметра компиляции) то используйте конструкцию generate, либо дефайны. Но на мой вкус, это уже ветвление архитектуры, и совмещать такое ветвление в одном файле - неправильно.

Спасибо, мне это всё понятно. Но define - это устаревшая конструкция, а использование generate в данном случе приводит к удвоению объёма кода.

 

Но на мой вкус, это уже ветвление архитектуры, и совмещать такое ветвление в одном файле - неправильно.

Возьмите хотя бы SPI - там в зависимости от параметров CPHA и CPOL меняются фронты, по которым происходят захват и выдача данных. Другое дело, что в реальных реализациях клок там чаще всего так или иначе эмулируется, но с точки зрения теории это уже детали.

 

[Shivers 2]

Возьмите хотя бы SPI - там в зависимости от параметров CPHA и CPOL меняются фронты, по которым происходят захват и выдача данных. Другое дело, что в реальных реализациях клок там чаще всего так или иначе эмулируется, но с точки зрения теории это уже детали.

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

[DmitryR 5]

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

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