Счетчики с большой разрядностью, Как лучше писать? Опции

[nice_vladi]

Всем привет!

Возник такой вопрос:
Нужно отмерить промежуток времени от события А до события Б с большой точностью (допустим, с точностью 100 МГц-го клока). Время между событиями составляет 500 000 +- 10 000 тактов 100 МГц. Получается счетчик на 3 байта.
Вроде не много, но если надо посчитать несколько таких отрезков времени независимо, да потом как-то обработать данные - выливается в кучу логики.

Как можно уменьшить размеры счетчиков?

Самое адекватное, что приходит в голову - это завести еще один счетчик, на низкой частоте, допустим, на 1 МГц. Этот счетчик будет отсчитывать основную длительность, и в конце, где примерно ожидается событие - включается первый, на 100 МГц-ах и досчитывает точное время до события. Потом результаты счетчиков суммируются.

Но при таком решении все равно нужно тратить место на медленный счетчик, на суммирование и т.д. По моим соображениям выигрыша не будет, либо он будет настолько мал, что не стоит всех этих заморочек. Да и момент запуска/остановки медленного счетчика завязан на клок 1 МГц и даст огромную (по меркам 100 МГц) ошибку.

[Lmx2315]

Вы сделали такие счётчики и они у вас не завелись на 100 Мгц?

[bogaev_roman]

Делал недавно на похожей частоте на Воронежской плисине таймер, с времянкой проблемы были. Пришлось бить на несколько последовательных, суть следующая - при достижении максимального значения на первом формируется сигнал CE, записываемый в регистр, который служит разрешением счета для следующего.Таким образом, вместо одного счетчика разрядностью N соединяются последовательно два счетчика разрядностью N/2. Надеюсь суть описал понятно, кода под рукой нет.
PS/ Вспомнил - у des00 в статье было http://embedders.org/content/timequest-dly...-litsom-k-litsu

[iosifk]

Нужно отмерить промежуток времени от события А до события Б с большой точностью (допустим, с точностью 100 МГц-го клока). Время между событиями составляет 500 000 +- 10 000 тактов 100 МГц. Получается счетчик на 3 байта.
Вроде не много, но если надо посчитать несколько таких отрезков времени независимо, да потом как-то обработать данные - выливается в кучу логики.

Как можно уменьшить размеры счетчиков?

Самое адекватное, что приходит в голову - это завести еще один счетчик, на низкой частоте, допустим, на 1 МГц.

Прескейлер даст выигрыш только в том случае, если его выход будет использоваться еще где-то...
А если нет, то какая разница, где считать?

[ViKo]

Одним таймером на 32 разряда считайте. А время измеряйте по захватам состояния таймера.

[iosifk]

Делал недавно на похожей частоте на Воронежской плисине таймер, с времянкой проблемы были. Пришлось бить на несколько последовательных, суть следующая - при достижении максимального значения на первом формируется сигнал CE, записываемый в регистр, который служит разрешением счета для следующего.Таким образом, вместо одного счетчика разрядностью N соединяются последовательно два счетчика разрядностью N/2. Надеюсь суть описал понятно, кода под рукой нет.

Это Вы разбили счетчик, чтобы получить перенос в группе.

[Tpeck]

Как можно уменьшить размеры счетчиков?

Использовать умножители.

[Maverick]

Использовать умножители.

Поясните пожалуйста....
Или пример дайте...

[Tpeck]

Поясните пожалуйста....
Или пример дайте...

Эскизы прикрепленных изображений

 

[andrew_b]

Умножитель != DSP block.

[Tpeck]

Умножитель != DSP block.

В каких кристаллах?

[andrew_b]

В каких кристаллах?

Не надо троллить. Не кормлю.

[Tpeck]

Не надо троллить. Не кормлю.

?

[blackfin]

В каких кристаллах?

Вы что, никогда не видели внутренности DSP48?

Там внутри кроме, собсно, умножителя, есть ещё много всякого:



Поэтому:

DSP == (Pre-adder + Multiplier + Pattern Detector + add/subtract/accumulate engine) != Multiplier..

[Tpeck]

Вы что, никогда не видели внутренности DSP48?

Там внутри кроме, собсно, умножителя, есть ещё много всякого:



Поэтому:

DSP == (Pre-adder + Multiplier + Pattern Detector + add/subtract/accumulate engine) != Multiplier..

Я с этим утверждением и не спорю. Просто может есть умножители без блока add/subtract/accumulate engine и люди их используют, а я об этом не знаю
Мне всегда казалось, если есть умножители => есть сумматоры большой разрядности для интегрирования => можно подать 1 на интегратор и получить счетчик.

[Bad0512]

Всем привет!

Возник такой вопрос:
Нужно отмерить промежуток времени от события А до события Б с большой точностью (допустим, с точностью 100 МГц-го клока). Время между событиями составляет 500 000 +- 10 000 тактов 100 МГц. Получается счетчик на 3 байта.
Вроде не много, но если надо посчитать несколько таких отрезков времени независимо, да потом как-то обработать данные - выливается в кучу логики.
о меркам 100 МГц) ошибку.

У вас 19-разрядный счетчик не работает на 100 МГц? Что это за ПЛИС такая? ИМХО это даже для воронежских поделок не должно быть проблемой.

[blackfin]

.. есть умножители => есть сумматоры ..

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

Вы же предложили операцию суммирования выполнять с помощью операции умножения.

С точки зрения обычной математики это невозможно. Но, может, у вас какая-то своя математика?

[Tpeck]

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

Вы же предложили операцию суммирования выполнять с помощью операции умножения.

С точки зрения обычной математики это невозможно. Но, может, у вас какая-то своя математика?

Я предложил реализовать не с помощью операции умножения, а с помощью аппаратного умножителя которые есть в большинстве ПЛИС.
Мне казалось это очевидным и мне даже в голову не приходит как это можно было трактовать по другому.
Но видимо я ошибался.

[bogaev_roman]

ИМХО это даже для воронежских поделок не должно быть проблемой.

Ошибаетесь.

[Tpeck]

С точки зрения обычной математики это невозможно.

Так здесь и не математику обсуждаем.

[nice_vladi]

Вы сделали такие счётчики и они у вас не завелись на 100 Мгц?

Да ну нет же) все нормально завелось. Я думаю, есть возможность как-то более изящно отсчитывать промежутки времени. Т.к при реализации на счетчиках с большой разрядностью съедается много логики (несколько счётчиков+мультиплексирование результатов)

Делал недавно на похожей частоте на Воронежской плисине таймер, с времянкой проблемы были. Пришлось бить на несколько последовательных, суть следующая - при достижении максимального значения на первом формируется сигнал CE, записываемый в регистр, который служит разрешением счета для следующего.Таким образом, вместо одного счетчика разрядностью N соединяются последовательно два счетчика разрядностью N/2. Надеюсь суть описал понятно, кода под рукой нет.
PS/ Вспомнил - у des00 в статье было http://embedders.org/content/timequest-dly...-litsom-k-litsu

Это немного не то. Повысится максимальная частота работы, но количество логики останется тем же (мб немного больше).

Одним таймером на 32 разряда считайте. А время измеряйте по захватам состояния таймера.

Немного не понял, можно про захват состояния тамера подробнее? Я представлял себе так: событие А начинаем считать. Событие Б забрали результат, сбросили счётчик. Ну, что-то вроде этого.

[ViKo]

Немного не понял, можно про захват состояния тамера подробнее? Я представлял себе так: событие А начинаем считать. Событие Б забрали результат, сбросили счётчик. Ну, что-то вроде этого.

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

[Lmx2315]

У вас 19-разрядный счетчик не работает на 100 МГц? Что это за ПЛИС такая? ИМХО это даже для воронежских поделок не должно быть проблемой.

..почти все воронежские плис до 50 Мгц , только одна какая-то под 100 Мгц , на простом счётчике.

[iosifk]

Всем привет!

Возник такой вопрос:
Нужно отмерить промежуток времени от события А до события Б с большой точностью (допустим, с точностью 100 МГц-го клока).

А давайте представим не тупой счетчик с проблемами переноса, а счетчик совсем небольшой + память + автомат + аккумулятор + флаг...
Значит все действия разбиваем на такты-таймслоты. Автомат проверяет что счетчик выдал переполнение и начал делать следующее:
читает 4-6 бит ячейку памяти, делает инкремент аккумулятора и если есть флаг переполнения, то взводит флаг. результат записывает в эту ячейку, а в этот же такт в аккумулятор грузится число из другой ячейки памяти... И его содержимое инкрементирует с учетом флага...
И вот так, старшие биты обрабатываем по "микропроцессорному" за несколько тактов. И чтобы не было перерывов ровно настолько же тактов крутится счетчик. Думаю, что для автомата нужно 6-8 тактов. Аккумулятор скажем на 4 разряда. Память если на Ксайлинксе, то там есть как SRL так и распределенная память на 1 логической ячейке 32х1 (в старых было 16х1)... Так вот, 4 таких ячейки дадут 4 бита х 32 = разрядный счетчик... При этом немного экономится всего. И триггеров и межсоединений...
Причем, если надо, то к этому же автомату, если добавить память, то можно и 2 канала сделать...

[iosifk]

А давайте представим не тупой счетчик с проблемами переноса, а счетчик совсем небольшой + память + автомат + аккумулятор + флаг...
Значит все действия разбиваем на такты-таймслоты. Автомат проверяет что счетчик выдал переполнение и начал делать следующее:
читает 4-6 бит ячейку памяти, делает инкремент аккумулятора и если есть флаг переполнения, то взводит флаг. результат записывает в эту ячейку, а в этот же такт в аккумулятор грузится число из другой ячейки памяти... И его содержимое инкрементирует с учетом флага...
И вот так, старшие биты обрабатываем по "микропроцессорному" за несколько тактов. И чтобы не было перерывов ровно настолько же тактов крутится счетчик. Думаю, что для автомата нужно 6-8 тактов. Аккумулятор скажем на 4 разряда. Память если на Ксайлинксе, то там есть как SRL так и распределенная память на 1 логической ячейке 32х1 (в старых было 16х1)... Так вот, 4 таких ячейки дадут 4 бита х 32 = разрядный счетчик... При этом немного экономится всего. И триггеров и межсоединений...
Причем, если надо, то к этому же автомату, если добавить память, то можно и 2 канала сделать...

Либо даже вот так.
Делаем на SRL сдвиговый регистр. От него 4 бита переписываем в аккумулятор и инкрементируем. Результат переписываем обратно и потом регистр сдвигаем циклически. Причем сам регистр можно сдвигать на 1 бит, но писать-читать из него через 4 бита. А их как раз хватит для автомата.
Итого: SRL - 1 ячейка, аккумулятор на 4 бита, счетчик - ну скажем 5-8 разрядов, триггер разрешения счета и триггер готовности...

[Maksim]

https://ru.m.wikipedia.org/wiki/Регистр_сдв...обратной_связью

[jcxz]

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

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

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

А в чём выигрыш-то? Ну хорошо - счётчик один, но раз автору нужно независимо друг от друга посчитать несколько таких отрезков (видимо для каждого учитываемого отрезка Oi, есть своя пара сигналов Ai и Bi, задающих начало и конец отрезка Oi, и эти отрезки O0...Oi могут по времени как угодно накладываться друг на друга).
А значит потребуется для каждого отрезка завести как минимум один регистр хранения (содержимого счётчика на момент Ai) и один сумматор в доп. коде.
А это однозначно больше чем просто один счётчик на один отрезок.

[ViKo]

А в чём выигрыш-то?...
А это однозначно больше чем просто один счётчик на один отрезок.

Может, и нет. Смотря куда результат выдавать.

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

Все равно есть ограничение на длину счетчика.

[jcxz]

Все равно есть ограничение на длину счетчика.

Ограничение в чём? В количестве входов элемента "И"?

[iosifk]

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

А значит потребуется для каждого отрезка завести как минимум один регистр хранения (содержимого счётчика на момент Ai) и один сумматор в доп. коде.
А это однозначно больше чем просто один счётчик на один отрезок.

для параллельного переноса надо задействовать довольно много интерконнектов - а это ценный ресурс.
что же касается сдвиговых регистров, то они делаются на SRL - это 16 или 32 бита, но они в одной ячейке. А так как соседние ячейки соединяются локальными интерконнектами, то там можно поднять частоту повыше...
А когда надо много счетчиков - то берем двухпортовку и один аккумулятор с автоматом... По одному порту читает результат, по другому порту работает автомат... И туда влезут сотни каналов...

[ViKo]

Ограничение в чём? В количестве входов элемента "И"?

В быстродействии, естественно.

[jcxz]

В быстродействии, естественно.

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

[ViKo]

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

Как последовательный перенос имеет некую задержку для создания переноса (особенно, для последнего разряда), так и параллельный перенос имеет задержку.
А что вам непонятно? Вы знаете, к примеру, 32-разрядный элемент "И"? Как его сделать в ПЛИС? Какое у него будет быстродействие?
А предыдущему триггеру нужна 31-разрядная схема "И", и т.п. Ох... много.

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

[jcxz]

Как последовательный перенос имеет некую задержку для создания переноса (особенно, для последнего разряда), так и параллельный перенос имеет задержку.

Всё имеет задержку, только разница в разы: для параллельной схемы задержка будет равна задержке одного разряда + задержка на "И", а в последовательной - суммарной задержке всех разрядов.

А что вам непонятно? Вы знаете, к примеру, 32-разрядный элемент "И"? Как его сделать в ПЛИС? Какое у него будет быстродействие?

Многовходовой "И" легко делается из нескольких меньших.
Последовательно-параллельный перенос тоже возможен. Для уменьшения используемых элементов. Но разве в современных ПЛИС (не знаком с ними) не хватит ресурсов на несколько полноценных 24-разрядных счётчиков с параллельным переносом???

[Александр77]

Всё имеет задержку, только разница в разы: для параллельной схемы задержка будет равна задержке одного разряда + задержка на "И", а в последовательной - суммарной задержке всех разрядов.
Многовходовой "И" легко делается из нескольких меньших.

Когда будете делать слоеную "И", задержка составит не меньше чем n*dt, где n - число слоев. Тут все и полезет в сторону снижения частоты.

[ViKo]

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

[jcxz]

Когда будете делать слоеную "И", задержка составит не меньше чем n*dt, где n - число слоев. Тут все и полезет в сторону снижения частоты.

Или я чего-то не понимаю или здесь клуб троллей...
5-ти входовые "И" возможны? Если да, то для реализации на их основе 24-входового "И" достаточно всего 2-х(!) "слоёв".
Не 20-и, а всего-лишь 2-х, Карл! А это по задержке будет меньше чем один разряд счётчика.

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

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

[ViKo]

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

Нет. 4-входовые.

Если да, то для реализации на их основе 24-входового "И" достаточно всего 2-х(!) "слоёв".
Не 20-и, а всего-лишь 2-х, Карл! А это по задержке будет меньше чем один разряд счётчика.

Итого, 3. Но вы не учитываете задержки каналов, связывающих логические элементы. И задержек там будет, мама не горюй. А, поскольку количество каналов и логических элементов ограничено, там такая конструкция вырастет, что пол-ПЛИСы займет.
Мне только в кошмарном сне может присниться предлагаемое вами решение, реализованное в ПЛИС.

[_4afc_]

Когда будете делать слоеную "И", задержка составит не меньше чем n*dt, где n - число слоев. Тут все и полезет в сторону снижения частоты.

Задержка не перейдёт в снижение частоты если после каждого слоя поставить тригер.

Нет. 4-входовые.

Если говорить за все современные ПЛИС - думаю у Xilinx всё же 6-входовые.

[ViKo]

Задержка не перейдёт в снижение частоты если после каждого слоя поставить тригер.

Такт потеряли. Желаете считать через такт-другой?

Если говорить за все современные ПЛИС - думаю у Xilinx всё же 6-входовые.

Ага, у них много чего есть, но цепи переносов не выбрасывают.

[_4afc_]

Такт потеряли. Желаете считать через такт-другой?

Желаю узнать результат с задержкой в такт - другой.

Ага, у них много чего есть, но цепи переносов не выбрасывают.

Не знаю, в чём проблемы иметь многоразрядный счётчик. В XC6SLX9 просто 32 разрядный счётчик спокойно считает на частоте 375МГц.

[svedach]

Не знаю, в чём проблемы иметь многоразрядный счётчик. В XC6SLX9 просто 32 разрядный счётчик спокойно считает на частоте 375МГц.

В седьмой серии на Artix (-1), 32 бит счетчик без проблем раскладывается на 150 МГц... На большей не проверял - не надо было...

[_4afc_]

Нужно отмерить промежуток времени от события А до события Б с большой точностью (допустим, с точностью 100 МГц-го клока). Время между событиями составляет 500 000 +- 10 000 тактов 100 МГц. Получается счетчик на 3 байта.

Вообще-то достаточно одного 16битного счётчика, если вы измеряете диапазон 500 000 +- 10 000 тактов.
Если его запускать по событию А и останавливать по событию Б, то счётчик будет содержать время (0...65535)+458752 такта.

В седьмой серии на Artix (-1), 32 бит счетчик без проблем раскладывается на 150 МГц... На большей не проверял - не надо было...

Код

module t1(input CLK100, output CLK2);
reg      [31:0] Count;
always @( posedge CLK100 )  begin Count<=Count+1;    end
assign CLK2=Count[31];
endmodule

XC6SLX9-2TTG144 Synthesizing:
# Registers : 32
Flip-Flops : 32
Speed Grade: -2
Minimum period: 2.654ns (Maximum Frequency: 376.861MHz)

Код

----------------------------------------------------------------------------------------------------------
  Constraint                                |    Check    | Worst Case |  Best Case | Timing |   Timing  
                                            |             |    Slack   | Achievable | Errors |    Score  
----------------------------------------------------------------------------------------------------------
  TS_sys_clk_pin = PERIOD TIMEGRP "sys_clk_ | SETUP       |     0.430ns|     2.236ns|       0|           0
  pin" 375 MHz HIGH 50%                     | HOLD        |     0.465ns|            |       0|           0
                                            | MINPERIOD   |     0.000ns|     2.666ns|       0|           0
----------------------------------------------------------------------------------------------------------
All constraints were met.

[ViKo]

Я в Cyclone III делал таймер, цитирую свои комментарии:
Для EP3C5E144C8 при длине таймера LENTH получается следующая рабочая частота:
28 256.02 MHz
29 251.32 MHz
30 247.04 MHz

На стандартных последовательных переносах, jcxz!

[jcxz]

30 247.04 MHz
На стандартных последовательных переносах, jcxz!

Это надо читать как ~30ГГц ? Серьёзно?

[_Anatoliy]

Это надо читать как ~30ГГц ? Серьёзно?

LENTH 30, частота 247.04 MHz.
Так понятно?

[ViKo]

Это надо читать как ~30ГГц ? Серьёзно?

Это же таблица. Там пробелы есть между колонками. В оригинале были табуляции.