LINUX.ORG.RU

Захват цифровых данных с микросхемы

 захват данных,


0

3

Товарищ описал гипотетическую задачу, хотелось бы услышать советы опытных hardware-мастеров о методах реализации.

Есть некоторая микросхема, у которой 16 выводов, каждый вывод может находиться в состоянии 0 или 1 (проверка по пороговым значениям). Вывода меняют свое состояние с частотой 100MHz. Необходимо получить на компьютере (в виде массива bool языка программирования или файла – как угодно) выходные данные со схемы.

Очень важно, что бы ни одно значение не потерялось (например, снимаем в течение одной секунды - имеем массив 16 * 100 * 10^6 bool значений (или эквивалент)).

Интересует, как такое можно реализовать?

Например, что-то вроде: к микросхеме подводится какой-то контроллер, который передает данные в машину по thernet/usb/fire-wire? Далее программа на C использует библиотеку для захвата.

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

P.S. Мопед не мой, я только размещаю объявление, но мне задача тоже любопытна в общем смысле – буду благодарен за терпеливые ответы опытных мастеров.

UPDATE 1: В задаче так же есть временные ограничения - нет необходимости захватывать поток бесконечно-долго. Хочется понять, как долго его можно захватывать при некоторой реализации.

★★★

Последнее исправление: omegatype (всего исправлений: 1)

google://логический анализатор

Правда, 100 МГц - это проблема.

Minoru ★★★
()

1.6ГГц? напрямую? Сомневаюсь.

Только вспомогательный буфер.

Что за микросхемка-то? А то вдруг можно реализовать все намного проще.

Или: есть такая-то платка, можно купить, она может захватить цифровой поток с этой частотой

Да захватить-то не проблема. Проблема — передать с такой скоростью и сохранить.

Eddy_Em ☆☆☆☆☆
()

И чем же ты собираешься сигнальчики снимать?

С контроллера этой микрухи, конечно же. Или, если я всё правильно понял, осциллографом.

Deleted
()
Последнее исправление: rht (всего исправлений: 1)

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

marvin_yorke ★★★
()
Ответ на: комментарий от Eddy_Em

Вот мои примитивные рассуждения: 16 каналов дают 16 бит информации, на частоте 100 МГц получаем: 16 * 100 = 1600 МБит/секунду. Википедия говорит, что fire-wire стандарта S3200 поддерживает 3200 Мбит/с, т.е. в два раза больше, чем надо. Допустим, запись будем производить прямо в ОЗУ, это значит 1600 Мегабит в секунду, или 200 Мегабайт. Если у нас есть 8 Гигов памяти, то можно захватывать около 40 секунд.

Где-то в них кроется ошибка, раз народ пишет о трудности задачи. Хотелось бы качественно узнать - где?

omegatype ★★★
() автор топика
Ответ на: комментарий от Eddy_Em

1.6ГГц?

1.6 Гбит, поправил тебя.

USB и Ethernet автоматически идут лесом.

SCSI? Думаю, будет проще, чем FireWire (FireWire и прочие USB разрабатывались сначала маркетологами, а потом инженеры уже думали, какими костылями реализовать придуманное - поэтому они технически сложнее, чем уарты, спи и другие стандарты, разработанные инженерами, простые, но неудобные для домохозяек).

prischeyadro ★★★☆☆
()

я бы делал предварительную обработку потока. ведь ему не просто поток нужен, а нужно как-то его обработать, так? тогда арм7-11 и при необходимости фпга должны помочь. Может быть можно аппаратные средства обработки найти, типа кодеров или чего ещё.

aiqu6Ait ★★★★
()
Ответ на: комментарий от aiqu6Ait

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

aiqu6Ait ★★★★
()
Ответ на: комментарий от omegatype

Ваши рассуждения вполне разумны.
Если считаем что все сигналы в вашем устройстве меняются только раз в 10 нс и синхронно (есть какой нидь выход SYNC). То все делается на жесткой логике и статической памяти (правда у нее объем маленький). И тут как раз ошибок нет. Быстро записали дамп, потом медленно как угодно залили его в комп.
Если хотите использовать большой буфер, то это уже DRAM (DDR2/3 итд), тогда нужен уже контроллер памяти, а для этого уже нужна какая-нидь плисина.

А вот если период следования у вас 10 нс, а разница фаз всего 1нс (например на двух выходах идут два меандра с такой разницей фаз). То что бы эту разницу фаз не потерять, уже нужно с такой (а лучше в 2-5-10 раз большей) скоростью считывать данные. А это уже гигагерцы и т.д.

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

Лить такой поток сразу в комп смысла абсолютно никакого нет.

yax123 ★★★★★
()
Ответ на: комментарий от yax123

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

Есть вариант ПЛИС + память, удовлетворяющая по объему требуемому времени снятия данных + любой интрефейс.

Есть ли варианты проще с меньшим временем снятия данных... ?

omegatype ★★★
() автор топика
Ответ на: комментарий от omegatype

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

USB 3 (брутто 5 Гбит/с, нетто точно больше 1.6)?

gag ★★★★★
()

Данные снимаются синхронно «железной» частью и сохраняются в SDRAM буфере. Оттуда считываются любым подходящим интерфейсом (делал похожее на FPGA для захвата и ARMе для считывания и передачи по Ethernet)

RVictor
()

скоростной SoC или MCU с тригером генерации прерывания по обеим фронтам либо FPGA с реализацией того же но на полностью аппаратном уровне.

exception13 ★★★★★
()
Ответ на: комментарий от omegatype

Как-то у вас задача непонятно стоит.
С учетом этого:

Есть вариант ПЛИС + память, удовлетворяющая по объему требуемому времени снятия данных + любой интрефейс.

Если у вас уже это есть, то чего тут время терять. Закажите подходящую прошивку и работайте.

Вашу конкретную задачу правильно решать только описанным образом (плис+ОЗУ+любой интерфейс в комп).
Все остальное это трата сил и средств на неработающий/слишком дорогой результат.

yax123 ★★★★★
()
Ответ на: комментарий от yax123

«Есть вариант» всмысле, что я его концептуально понимаю. Может, есть варианты проще. Если ваше мнение что нет - благодарю за совет.

omegatype ★★★
() автор топика
Ответ на: комментарий от omegatype

Да вариантов сколько угодно, только они по соотношению цена/качества хуже:
1. Можно взять быстрый/чОткий SoC, навешать на него DDR2, на асме написать прошивку, которая будет с GPIO снимать данные и складывать в ОЗУ. Хотя на вскидку я не скажу где есть SoC у которого GPIO может 100мгц снимать.
2. Можно взять осцил с логическим анализатором (типа MSO4000) и все сразу будет работать как надо.
3. можно пошукать по dsp, чего у них есть быстрого для чтения/записи.

yax123 ★★★★★
()
Ответ на: комментарий от omegatype

Да, usb 3 подходит,

Значит, надо идти смотреть, какие чипы есть

остается только вопрос, кто будет этот usb формировать

и определить, что они хотят на входе.

Наверное, надо ещё поискать чип, который преобразует параллельный (мин. 16-битный) вход в последовательный для USB.

gag ★★★★★
()
Ответ на: комментарий от omegatype

Я же говорил: разве что оптоволокно + фреймграббер с хорошим буфером.

Eddy_Em ☆☆☆☆☆
()

100 мегагерц? Фпга тебк нужно.

AiFiLTr0 ★★★★★
()
Ответ на: комментарий от yax123

Контроллер оперативки по идее справится: параллельным кодом подавать данные с ног «железяки», оттуда же — тактовый импульс. И писать в память.

Даже еще проще: генератор адреса инкрементирует адрес на каждый тактовый импульс, данные подключены напрямую к 32-м ногам DataIn DDR'ки, а RAM-controller нужен будет лишь для того, чтобы эти данные потом считать.

Eddy_Em ☆☆☆☆☆
()
Последнее исправление: Eddy_Em (всего исправлений: 1)
Ответ на: комментарий от Eddy_Em

Лично у меня получалось без всяких контроллеров запустить съем данных по адресам только 565РУ7. Все работало на линейке синхронных двоичных счетчиков.

А если брать достаточно объемную и быструю современную память, то надо ставить рядом плисину и не компосировать моск.
Даже если взять подходящую простую SDRAM все равно на такие частоты нужен весьма специфический счетчик (по младшему разряду частотой 100мгц). Делать это на рассыпухе... весьма увлекательно будет. Только ПЛИС, никакого хардкора на ламповых триггерах.

yax123 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.