Jump to content

    

И снова про ripple clock

Всем добра.
 

Просьба накидать (по возможности на русском) ссылок (литературы, статей, прочей документации), поясняющей, почему для FPGA ripple clock не есть комильфо.
Особенно хорошо бы на примере сравнения ripple clock и синхронного counter-ов. 
 

`define CNTR_DIM 4
`define CNTR_RNG [`CNTR_DIM-1:0]

// http://electrosofts.com/verilog/counter.html
module ripple_cntr ( // asyncronous counter
    input logic clk,
    output logic `CNTR_RNG counter
);

    always_ff @(posedge clk) // 1st counter bit
        counter[0] <= ~counter[0];
        
    genvar i;
    generate for (i = 1; i < `CNTR_DIM; i++) begin : go_gen
    always_ff @(posedge counter[i-1])
        counter[i] <= ~counter[i];
    end 
    endgenerate
	   	
endmodule : ripple_cntr 
`define CNTR_DIM 4
`define CNTR_RNG [`CNTR_DIM-1:0]

module cntr ( // asyncronous counter
    input logic clk,
    output logic `CNTR_RNG counter
);

    always_ff @(posedge clk)
        counter <= counter + 1'b1;
	   	
endmodule : cntr 

 

Edited by MaratZuev

Share this post


Link to post
Share on other sites

если не секрет: в каком ВУЗе задают этот вопрос?

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

поэтому стараются делать единые тактовые сигналы, тогда момент переключения шины будет достаточно точно привязан к этому такту (все триггера переключаются одновременно)

поэтому даже в АЗИКах или каких-то еще не FPGA стараются не делать ripple_counter - может только в каких-то ВЧ делителях частоты такое делают...

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

то есть в FPGA вдвойне не выгодно так делать - и природа и человек против ripple_counter в FPGA :)

Share this post


Link to post
Share on other sites
2 часа назад, MaratZuev сказал:

Просьба накидать (по возможности на русском) ссылок (литературы, статей, прочей документации), поясняющей, почему для FPGA ripple clock не есть комильфо.
Особенно хорошо бы на примере сравнения ripple clock и синхронного counter-ов. 

Да нет особых проблем. Если хватит квалификации то можно и ripple clock использовать. 
Просто чаще всего квалификации не хватает по этому и советуют делайте всё синхронным и это спасёт от 90% проблем.

А квалификация нужна чтобы понимать где это делать а где не нужно. И какие грабли это за собой влечёт.

Вот например накой делать несинхронный счётчик? Ладно первый 2-3 триггера. Остальное то зачем?

А проблемы следующие:
1. Множество частот внутри кристалла сдвинутых на непонятные фазы. В результате встаёт вопрос каким клоком защёлкивать выходы этого счётчика.

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

3. Необходимо следить за тем чтобы не возникали глитчи в логике перед клоковым входом.

4. Есть шанс что раскладчик свихнётся от множественных клоков и насчитает чёрти что.

5. Неэффективное использование ресурсов ибо например в Xilinx 1 слайс на 8 триггером может иметь только один клок. 

6. .......

Share this post


Link to post
Share on other sites
1 час назад, MegaVolt сказал:

накой делать несинхронный счётчик?

Например, поработать 10 лет от одного гальванического элемента.

Share this post


Link to post
Share on other sites

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

16 minutes ago, Plain said:

Например, поработать 10 лет от одного гальванического элемента.

На FPGA !? :shok: . 

Единственное оправданное применение ripple-clock это реализация счета внешних импульсов с максимальной частотой в старт/стоп режиме. Да и то только в тех FPGA где нет локальных быстрых клоков.

 

Удачи! Rob.

 

P.S.  Как раз на CollRuner и делали такой счетчик/частотомер,  работал  до ~450 МНz при максимальной синхронной ~200 MHz. 

 

Share this post


Link to post
Share on other sites
11 минут назад, Plain сказал:

Например, поработать 10 лет от одного гальванического элемента.

Мы про плис говорим?
По моему единственная близкая малопотребляющая микруха это CPLD от Xilinx семейства CoolRunner - xpla3 или CoolRunner -  II. Но и в них по моему количество разных клоков ограничено :(

А на жёсткой логике само собой можно творить всё что угодно. Я же сразу сказал что делать можно всё главное понимать как.

Share this post


Link to post
Share on other sites
2 hours ago, yes said:

если не секрет: в каком ВУЗе задают этот вопрос?

Не в ВУЗе, но в институте, а вот в каком - секрет )
Quartus при реализации ripple clock counter, что вполне понятно, ругается на отсутствие в sdc задания ограничений для этих ripple clock-ов.

Если, всё-таки, приспичило, то как правило писать эти constrain-ы?

Share this post


Link to post
Share on other sites
10 минут назад, MaratZuev сказал:

Не в ВУЗе, но в институте, а вот в каком - секрет )

Что ж в вашем секретном институте не объясняют-то что это такое и чем это хорошо или плохо. Секрет видимо )))

10 минут назад, MaratZuev сказал:

то как правило писать эти constrain-ы?

create_genetared_clock

Share this post


Link to post
Share on other sites
10 минут назад, MaratZuev сказал:

Если, всё-таки, приспичило, то как правило писать эти constrain-ы?

А задача какая? Ведь этот счётчик будет работать с любыми констрейнами и даже без них.

Если нужно ускорить то ограничивать максимальный пусть от треггера до клока.

Share this post


Link to post
Share on other sites
17 hours ago, MaratZuev said:

Не в ВУЗе, но в институте, а вот в каком - секрет )

офф а что сейчас возможно, что институт не является ВУЗом (высшим учебным заведением)?

> create_genetared_clock

если сработает - посмотрите результат

руками задавать такие констрейны достаточно сложно, нужно учесть задержку от такта триггера на его выход, потом цепь трассировки - так как напрямую на тактовый вход повесить выход нельзя (по крайней мере, я не знаю современных ПЛИС - может только в ProASIC3 (?) ), то будет трассировка до специального элемента (входа тактового дерева) протянут "провод" с задержкой, потом задержка тактового дерева - сигнал будет разведен не на один триггер, а на сотни/тысячи (хотя использоваться это "дерево" не будет), то есть счет уже на наносекунды

такое для делителя частоты еще может быть применено, но для счетчика - в нормальной ПЛИС максимальная частота будет гораздо хуже, чем для синхронного счетчика

ну и ресурсы (этих тактовых деревьев весьма мало - десятки на среднюю ПЛИС) будут очень неэффективно потрачены

 

Share this post


Link to post
Share on other sites

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

24 minutes ago, yes said:

руками задавать такие констрейны достаточно сложно, нужно учесть задержку от такта триггера на его выход, потом цепь трассировки - так как напрямую на тактовый вход повесить выход нельзя (по крайней мере, я не знаю современных ПЛИС - может только в ProASIC3 (?) ), то будет трассировка до специального элемента (входа тактового дерева) протянут "провод" с задержкой, потом задержка тактового дерева - сигнал будет разведен не на один триггер, а на сотни/тысячи (хотя использоваться это "дерево" не будет), то есть счет уже на наносекунды

такое для делителя частоты еще может быть применено, но для счетчика - в нормальной ПЛИС максимальная частота будет гораздо хуже, чем для синхронного счетчика

ну и ресурсы (этих тактовых деревьев весьма мало - десятки на среднюю ПЛИС) будут очень неэффективно потрачены

Ну не все так страшно - все зависит от структуры конкретной  FPGA. На Xilinx вполне можно забабахать ripple-clock счетчик  чисто на локальном routinge без привлечения global/regional clock network. Да и констрейнится все просто - от простейшего - "TIG - как получится" - до "from to"  с  заданием минимальной задержки физически реализуемой в данной FPGA для такой цепи (с неким запасом естественно). В первом случае общая задержка после останова счета будет непредсказуема и должна браться с потолка с запасом. Во втором она будет минимальна и предсказуема. Частота счета при этом ограниченна лишь частотой toggle первого триггера. Ну и естественно частотой буфера входного пина.

 

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

 

Удачи! Rob.

 

 

 

 

 

Share this post


Link to post
Share on other sites
43 минуты назад, yes сказал:

офф а что сейчас возможно, что институт не является ВУЗом (высшим учебным заведением)?

Речь скорее всего о каком-нибудь научно-исследовательском институте радиосвязи или тому подобном. Т.е. не учебное заведение, а какой-нибудь секретный ФГУП.

Share this post


Link to post
Share on other sites
35 minutes ago, RobFPGA said:

Частота счета при этом ограниченна лишь частотой toggle первого триггера. Ну и естественно частотой буфера входного пина.

но эта частота будет ограничиваться временем прохождения LUT-а и внешней трассировки, внутри SLICE нету пути с выхода на вход?

то есть не может быть выше частоты для синхронного счетчика малой разрядности, например 4-х разрядного - чтобы в один ЛУТ и не использовать "более длинные" линии внешней трассировки

то есть даже в новых ксайлинсах не получится сделать на ripple_counter делитель быстрее синхронного

??

 

Share this post


Link to post
Share on other sites
18 hours ago, MegaVolt said:

А задача какая?

Задача - взять самый медленный разряд этого счётчика, (да, знаю, ещё одно неправильное решение) гейтовать его, и запитать другой триггер.
Больше никакие разряды ripple счётчика никуда не идут.
 

module ripple_cntr (
    input logic clk,
    input logic ss,
    input logic dr,
    input logic r_rq,
    output logic rq
);

    logic c_rq;
    logic `CNTR_RNG counter;

    always_ff @(posedge clk) // 1st counter bit
        counter[0] <= ~counter[0];
        
    genvar i;
    generate for (i = 1; i < `CNTR_DIM; i++) begin : go_gen
    always_ff @(posedge counter[i-1])
        counter[i] <= ~counter[i];
    end 
    endgenerate
    
    assign c_rq = ss | counter[`CNTR_DIM-1];
    always_ff @ (negedge c_rq or posedge r_rq)
        rq <= r_rq ? '0 : dr;
	   	
endmodule : ripple_cntr

 

Share this post


Link to post
Share on other sites

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

18 minutes ago, yes said:

но эта частота будет ограничиваться временем прохождения LUT-а и внешней трассировки, внутри SLICE нету пути с выхода на вход?

С какой это стати?  Транспортная задержка (задержка распространения) лишь задерживает сигнал, а не фильтрует его. Естественно есть и минимальная длительность импульса (inertial delay) которую цепь может пропустить. Которая и ограничивает макс. частоту сигнала в этой цепи. Но обычно эта задержка меньше чем transport delay. И при малых fanout и короткой цепи (input buffer -> input Clk)  макc. частота обычно в 2-3 раза выше чем макс частота для клокового дерева - отсюда и выигрыш в частоте счета. 

 

Удачи! Rob.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now