Нужен Capture Timer на сотни МГц, Выбор камня Опции

[Dot]

В идеале - на 32 бита, но сойдет и 16-разрядный.
Главное, чтоб тактовая частота (естественно - внутренняя) была не менее 500 МГц.
Внешние "фотографирующие" импульсы приходят сравнительно редко - до 300 кГц.
Задержка между фронтом фотографирующего импульса и срабатыванием тоже не важна, лишь быб была постоянной.

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

Сообщение отредактировал Dot - Dec 10 2014, 17:51

[_pv]

http://www.acam.de/products/time-to-digita...erter/overview/

а вообще вроде делается на любой fpga с разрешением в сотню пикосекунд и без высокочастотных таймеров

[Golikov A.]

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

[blackfin]

В идеале - на 32 бита, но сойдет и 16-разрядный.
Главное, чтоб тактовая частота (естественно - внутренняя) была не менее 500 МГц.

Четыре штуки: MC100EP016A ..

Figure 4. 32‐Bit Cascaded EP016A Counter, если что..

[_pv]

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

да на любой, так как разрешение надо в пару нс всего ring oscillator можно попробовать вообще через IO сделать, ноги попарно объединив, там задержки больше чем внутри, чтобы не сильно много логики расходовать на это.

[yes]

зачем 500МГц - возьмите 50МГц, а результат умножте на 10

это я к тому, что на КМОП входе (а там еще триггерный синхронизатор) погрешность определения фронта будет несколько наносекунд.

-------

по этому и нет таких процессоров

[_pv]

зачем 500МГц - возьмите 50МГц, а результат умножте на 10
это я к тому, что на КМОП входе (а там еще триггерный синхронизатор) погрешность определения фронта будет несколько наносекунд.

не надо грязи, быстрая логика вроде LVC/AUC серии или fairchildовская NC7SZ имеет джиттер в пикосекунды.

[yes]

не надо грязи, быстрая логика вроде LVC/AUC серии или fairchildовская NC7SZ имеет джиттер в пикосекунды.

забываем про тактовый сигнал в процессоре и шумы по входу

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

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

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

[Dot]

http://www.acam.de/products/time-to-digita...erter/overview/

Они вроде работают по старт-стопному методу. А мне надо непрерывно, со скоростью ~300k в секунду получать снимки счетного регистра. Дальше - ЦОС этих "сэмплов".

зачем 500МГц - возьмите 50МГц, а результат умножте на 10

а почему не 5 МГц и результат помножить на 100, или 500кГц и результат помножить на 1000?

ring oscillator можно попробовать

я знаю только что такое стринги...

Значит получается (на текущий момент) , что на ARMах без внешней "залепухи" никак?

[_pv]

Они вроде работают по старт-стопному методу. А мне надо непрерывно, со скоростью ~300k в секунду получать снимки счетного регистра. Дальше - ЦОС этих "сэмплов".

микросхема вроде двухканальная, и добавив совсем немного логики: триггер для деления пополам и пару лог И, непрерывная последовательность импульсов разделяется на старты и стопы для двух каналов.
ну либо как blackfin посоветовал, берите ЭСЛные счётчики, какой-нибудь однокристальный ВЧ трансивер в качестве тактовой частоты МГц на 900 и тупо считайте время.
зачем правда 32х разрядный счётчик понадобился если 2нс от 3мкс это 10 с небольшим разрядов?
плюс считать можно время не между импульсами, а между импульсами и фронтами какой-нибудь 50..100МГц частоты. там и 4х разрядого счётчика хватит, а уж 50МГц можно чем угодно посчитать.

я знаю только что такое стринги...

просто 2N+1 инверторов включенных друг за другом кольцом, плюс выход каждого еще подключен ко входу 2N+1 разрядной защёлки, которая по внешнему сигналу защелкивает состояние всех инверторов. задержки распространения тупо инвертора внутри fpga субнаносекундные, соответственно можно получить хорошее разрешение по времени и без гигагерцовых тактовых частот, только автокалибровка нужна, так как задержки плывут.
гугл по запросу "tdc fpga" много интересного может рассказать.

[Golikov A.]

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

решение в лоб грубой силой не всегда реализуемо...

[Dot]

"просто 2N+1 инверторов включенных друг за другом кольцом," - _pv

Мои стринги круче -- в них есть еще поперечная перемычка...

Вобщем принци понятен, вроде так и реализовано у acam, но дело в том, что меня не интересуют временные интервалы как таковые. Мне нужны именно "сфотографированные" фазы счетчика в их наипервейшем виде в виде значений 0...1023 (как минимум), непрерывная цепочка таких значний. Да, 32 бит избыточны, но они желательны, чтобы "прикрутить" параллельно еще одну задачу (определение частоты) без всяких заморочек с программным расширением разрядности. В принципе обойдусь и 10 битами.

Но вы меня неизбежно толкаете к внешней рассыпухе (пусть даже и в виде fpga). Видимо, все это будет (я надеялся, что что-то пропустил) у ARMов лет так через 5.

Да, mr. Golikov A., примерно так ("и АЦП померить") я и делаю на текущий момент.
.

[Golikov A.]

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

Даже АРМ+ПЛИС в одном корпусе - уже специфическая вещь, так что думаю не появятся....

А чем вам внешняя ПЛИС то не угодила? это фактически гибкая параллельно обрабатывающая все и вся периферия, нормальное решение, все пользуют, расширяет возможности АРМа колоссально (хорошее слово, его редко удается применить).

[jcxz]

А чем вам внешняя ПЛИС то не угодила? это фактически гибкая параллельно обрабатывающая все и вся периферия, нормальное решение, все пользуют, расширяет возможности АРМа колоссально (хорошее слово, его редко удается применить).

У внешней ПЛИС есть серьёзный недостаток как я понимаю - необходимость её прошивки/отладки.
И обновления прошивки в ней в дальнейшем, если устройство уже работает у заказчика.
Если к устройсту есть канал удалённого доступа, то он как правило - к CPU. А ПЛИС уже надо
как-то обновлять программой в этом CPU. Если-же канала нет и для обновления всё равно нужно приезжать и
подключаться UART/JTAG к девайсу, то необходимость обновления прошивки в ПЛИС - это дополнительные операции.

[blackfin]

Даже АРМ+ПЛИС в одном корпусе - уже специфическая вещь, так что думаю не появятся..

Шутить изволите?

Cyclone V SoC Hard Processor System.
Zynq-7000 All Programmable SoC.