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

[Vincent Vega]

какое максимальное количество данных можно передать в компьютер за одну транзакцию PCI?

пока что представляю о наличии регистра cacheline size, который задаёт эту самую длину транзакции. Но этот регистр - 8-битный, из чего можно сделдать вывод, что максимальная длина транзакции - 256 слов. А хотелось бы 2k ( Возможно ли это организовать?

нашёл упоминание о режиме адресации cacheline wrap mode, с помощью которого вроде бы можно "склеить" несколько транзакций - правда пока не пойму чем ограничивается количество передаваемых данных в этом режиме

[Raven]

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

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

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

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

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

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

[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 МБ).
При этом было бы желательным, но не крайне необходимым, что после того, как освоим одну секунду расширить возможности контроллера сбора данных до нескольких секунд по-возможности без перепроектирования платы, а варьируя проект в ПЛИС.