[MaratZuev 0]

Всем добра.
 

Просьба накидать (по возможности на русском) ссылок (литературы, статей, прочей документации), поясняющей, почему для 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 

 

Изменено 17 июня, 2019 пользователем MaratZuev

[yes 5]

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

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

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

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

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

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

[MegaVolt 25]

2 часа назад, MaratZuev сказал:

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

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

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

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

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

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

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

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

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

6. .......

[Plain 168]

1 час назад, MegaVolt сказал:

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

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

[RobFPGA 27]

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

16 minutes ago, Plain said:

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

На FPGA !?  . 

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

 

Удачи! Rob.

 

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

 

[MegaVolt 25]

11 минут назад, Plain сказал:

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

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

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

[MaratZuev 0]

2 hours ago, yes said:

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

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

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

[dvladim 0]

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

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

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

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

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

create_genetared_clock

[MegaVolt 25]

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

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

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

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

[yes 5]

17 hours ago, MaratZuev said:

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

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

> create_genetared_clock

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

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

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

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

 

[RobFPGA 27]

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

24 minutes ago, yes said:

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

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

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

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

 

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

 

Удачи! Rob.

 

 

 

 

 

[dvlwork 0]

43 минуты назад, yes сказал:

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

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

[yes 5]

35 minutes ago, RobFPGA said:

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

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

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

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

??

 

[MaratZuev 0]

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

 

[RobFPGA 27]

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

18 minutes ago, yes said:

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

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

 

Удачи! Rob.