[Dot 0]

В идеале - на 32 бита, но сойдет и 16-разрядный.

Главное, чтоб тактовая частота (естественно - внутренняя) была не менее 500 МГц.

Внешние "фотографирующие" импульсы приходят сравнительно редко - до 300 кГц.

Задержка между фронтом фотографирующего импульса и срабатыванием тоже не важна, лишь быб была постоянной.

 

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

Изменено 10 декабря, 2014 пользователем Dot

[_pv 54]

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

 

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

[Golikov 0]

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

[blackfin 22]

В идеале - на 32 бита, но сойдет и 16-разрядный.

Главное, чтоб тактовая частота (естественно - внутренняя) была не менее 500 МГц.

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

 

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

[_pv 54]

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

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

 

[yes 5]

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

 

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

 

-------

 

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

 

 

[_pv 54]

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

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

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

 

[yes 5]

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

 

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

 

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

 

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

 

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

[Dot 0]

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

 

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

 

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

 

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

 

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

 

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

 

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

[_pv 54]

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

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

ну либо как blackfin посоветовал, берите ЭСЛные счётчики, какой-нибудь однокристальный ВЧ трансивер в качестве тактовой частоты МГц на 900 и тупо считайте время.

зачем правда 32х разрядный счётчик понадобился если 2нс от 3мкс это 10 с небольшим разрядов?

плюс считать можно время не между импульсами, а между импульсами и фронтами какой-нибудь 50..100МГц частоты. там и 4х разрядого счётчика хватит, а уж 50МГц можно чем угодно посчитать.

 

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

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

гугл по запросу "tdc fpga" много интересного может рассказать.

[Golikov 0]

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

 

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

[Dot 0]

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

 

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

 

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

 

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

 

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

.

 

 

 

[Golikov 0]

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

 

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

 

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

[jcxz 199]

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

У внешней ПЛИС есть серьёзный недостаток как я понимаю - необходимость её прошивки/отладки.

И обновления прошивки в ней в дальнейшем, если устройство уже работает у заказчика.

Если к устройсту есть канал удалённого доступа, то он как правило - к CPU. А ПЛИС уже надо

как-то обновлять программой в этом CPU. Если-же канала нет и для обновления всё равно нужно приезжать и

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

[blackfin 22]

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

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

 

Cyclone V SoC Hard Processor System.

Zynq-7000 All Programmable SoC.