Максимальный размер пакета данных, какой? Опции

[Genn]

"Захват", пока что, предполагается вести  в течение 1 с, т.е. обойтись буферизацией на самой плате вполне реально (всего-то надо 128 мегабайт памяти). Другое дело, что если бы гнать данные прямо в память ПК, то был бы не нужен собственный SDRAM-контроллер (хотя примерно наполовину он уже разработан)

Если Вам нужен блок данных в пределах 128 МБайт, то закачка непосредственно в память ЭВМ без использования буфера на SDRAM - очень хороший вариант (ведь Вам для обработки Вам все равно прийдется размещать данные в память). Необходим будет только буфер FIFO в пределах 32 кБайт для исключения потери данных во время задержки предоставления шины. С отладкой контроллера SDRAM вам прийдется прилично повозиться, если у Вас нет отлаженного варианта.

[Tommyknocker]

Все-таки пока недостаточно исходных данных, чтобы конкретно посоветовать. Вопросы такие.

1. Какой объем данных вы планируете захватывать? Это чтобы понять, реально ли обойтись буферизацией на самой плате, или все-таки нужно в реальном времени скачивать захватываемое в host's RAM.

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

3. Наконец, сколько народу будет над этим работать, с какой квалификацией, и каковы временнЫе рамки проекта (приблизительно конечно)?

----------------------------------------------------------------------------------------------

С PLX9054 доводилось работать, очень хорошая машинка, довольно-таки добротная и универсальная. Реализация стыковки с локальной шиной PLX будет, по моему мнению, все-таки проще, чем с PCI-ядром непосредственно (это если говорить о Master'е, т.к. разница в Slave несущественна, на мой взгляд), плюс нахаляву достаются такие "вкусности" PLX, как хорошая буферизация, всякие doorbell регистры, 2 DMA (PCI-to-LocalBus!!), всякие features для обеспечения maximum throughput и т.п. (Для вашего случая 2 последних момента могут быть особенно привлекательными) _НО!_ Однозначно посоветовать вам этот вариант пока я не могу, т.к., во-первых, нет пока ответа на вышеупомянутые вопросы, а во-вторых, с этим чипом, действительно, еще надо научиться управляться и грамотно его подключить (а изучать там, как вы заметили, есть что :-)), а в-третьих, это все же еще один чип на плату, что не всегда может оказаться good (и цена у него вовсе не нулевая, и другие соображения м.б. в пользу чисто FPGA-го решения - хотя бы проблемы с местом на плате, например, или еще что).

Учитывая, что Vincent Vega и я вместе работаем над обсуждаемым проектом, то, если Vega позволит, я попытаюсь сформировать общее видение того, над чем мы работаем. Возможно это поможет уважаемым коллегам в построении советов на наши вопросы.
Это устройство (см. рис., надеюсь рисунок корректно присоединился), которое обеспечивает прием и обработку некоторого сигнала. При этом, обработка непосредственно на тактовой частоте ведется в аппаратном ядре (см. рис), а результаты работы этого ядра уже далее обрабатываются в процессоре. Алгоритмы обработки в процессоре достаточно сложны, и для эффективной разработки программно-алгоритмического обеспечения хотелось бы иметь сигнал ("выход АЦП") записанным в файл, чтобы неспешено, полностью моделируя работу на ЭВМ в том числе и ядра, провести отладку ПМО, которое уже потом будет в реальном времени управлять той частью обработки сигнала, которая реализована в аппаратном ядре.
Структура принимаего сигнала такова, что для решения всех или почти всех задач по разработке программно-алгоритмического обеспечения длину записанной реализации хотелось бы иметь на начальном этапе порядка 1 с (нетрудно подсчитать объем при заданной тактовой частоте и разрядности АЦП за одну секунду с двух каналов АЦП составит 100 МБ).
При этом было бы желательным, но не крайне необходимым, что после того, как освоим одну секунду расширить возможности контроллера сбора данных до нескольких секунд по-возможности без перепроектирования платы, а варьируя проект в ПЛИС.

[Raven]

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

Итак, если еще не поздно, попробую все-таки высказать свои соображения.

По всему похоже, что ваша команда впервые приступает к работе с подобными полосами частот и вытекающими из них требуемыми пропускными способностями тракта PCI card - PC memory. Значит, так или иначе, то, что вы будете пытаться делать по первому разу, должно содержать в себе какие-то черты evaluation board (в определенном смысле). Ведь вы же будете и обучаться в том числе работе в таких условиях, верно? А тут можно очень легко "найти" немало граблей, и чтобы не начинать все сначала где-нибудь в середине проекта, лучше подстраховаться и "накрыть" в схеме платы несколько возможных направлений дальнейшего развития событий. Мне кажется, что на поверку это выйдет не так уж страшно с любой точки зрения - и по цене, и по месту на плате, и по добавляемой сложности (учитывая, что вы уже собираетесь ставить на нее - Xilinx XC3S1500, быстрые ADC и т.п.).

Я бы на вашем месте поступил так.

PCI бы подключил с использованием PLX9054 (or PLX9056), и скорее всего, в режиме J. Тут, конечно, придется поработать с документацией на чип, чтобы разобраться, в каких режимах вам лучше его использовать, но там не бог весть сколько внешних сигналов - так что можно все сомнения решать в пользу "подключать к FPGA". Только тут не забывайте о возможной необходимости в pull-up or pull-down resistors. Кроме того, существуют refernce designs с открытой схемотехникой - изучайте и копируйте удачные решения при подключении узлов. Еще я бы особенно поинтересовался, как можно использовать режим запуска 2 внутренних DMA от неких аппаратных сигналов (встречалось вроде упоминание об этом) - такая штука вам может весьма пригодиться.

Далее. Все-таки я бы предусмотрел в схеме подключение SDRAM необходимого объема для буферизации. Всегда можно подыскать такую линейку чипов, которые будут pin compatible снизу вверх, и в то же время позволят вам варьировать объем устанавливаемой памяти. В конце концов, поначалу вы ее вообще можете не запаивать в надежде успеть прокачивать все приходящие данные в RAM, но предусмотреть место для нее и развести сигналы будет совсем не лишним. Я думаю, что скорее всего, она вам все-таки понадобится, вопрос только в объеме. И вот почему. Темп передачи по PCI, который вам потребуется в худшем случае (100 МБ в сек) - уж слишком велик для PCI 32/33. Наш опыт говорит, что даже при упоминавшихся мной где-то в начале дискуссии спецнастройках какая-то осмысленная "жизнь" на машине возможна только, если наша спецплата не будет пытаться передавать по шине более 70-75 МБ/с. Далее - жизнь замирает. Возможно, конечно, что суперсовременные P4 платы несколько улучшили эти показатели, но не думаю, чтобы настолько, чтобы комфортно чувствовать себя при 100 МБ/с. При этом надо еще сказать, что все это происходило на Linux машинах, где есть возможность гибко подстраивать конфигурацию под свои нужды. Windows-машина, скорее всего, перестанет подавать признаки жизни еще раньше. И еще не совсем понятно, можно ли там провести упоминавшиеся настройки, позволяющие осуществлять длинные и сверх-длинные пакетные транзакции по PCI.

Что еще? Пожалуй, я бы еще в схемотехнике предусмотрел некоторый минимум внешних компонентов и связей, необходимых для использования какого-нибудь soft-core CPU (RAM (лучше отдельное от вашей буферной памяти), место для Flash, JTAG, RS-232 (достаточно вывести его на 2х5 header, без DB-9)). Рано или поздно это вам пригодится - не в этом проекте, так уже в следующем. Я, правда, не знаком с Xilinx'овским soft-core CPU - мы пока больше с Alter'овским NIOS II работаем. Но думаю, черты у них во многом схожи, так что вещь может оказаться полезная несмотря на наверняка имеющиеся недостатки (например, для осуществления общего управления и интеграции потоков данных на вашей плате в будущем, когда будет более интеллектуальная обработка в FPGA). Советую присмотреться и примерить на себя, короче.

Думаю, для начала достаточно. Надеюсь, что в дальнейшем отвечать удастся быстрее (если, конечно, у вас еще будут вопросы :-)).