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

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

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

На сколько помню " количество данных которое можно передать в компьютер за одну транзакцию PCI" в мастер режиме ограничено только latency timer-ом (по крайней мере теоретически) смотреть 3.5.4.1. Bandwidth and Latency Considerations в PCI Local Bus Specification Revision 2.2 December 18, 1998

к сожалению, у нас будет (надеюсь ( ) target-устройство

Тогда этот параметр полностью будет зависеть от чипсета материнской платы (т.к. он в данном случае и будет мастером), но latency timer (я надеюсь) и в этом случае должен играть решающую роль наряду с MIN_GNT и MAX_LAT. Мало вероятно что Вы найдёте способ передачи 2k за одну транзакцию.

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

акто какие типовые размеры пакета использовал - с учётом того, что устройство должно работать под windows (т.е. время, мягко говоря, несовсем реальное)?

незнаю читали ли Вы http://www.citforum.ru/book/apparatnie_int...e/otryvok.shtml (6.2.5. Пропускная способность шины) У меня в мастер режиме транзакции по 8/16 двойных слов.

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

1) Возможности Host-bridge, а также всех PCI-to-PCI bridges (если таковые есть) по пути от Host bridge до локальной PCI bus, на которой и находится интересное устройство. Поток данных надо буферизировать внутри моста (а размер буферов никогда не бывает бесконечным ), т.к. шина по другую сторону моста может оказаться занятой в отдельные моменты времени. Соответственно, вполне может оказаться, что не шибко большой объем буферной памяти в бридже будет ограничивать длину пакета. Правда, нужно сказать, что современные мосты вроде обладают вполне приличными характеристиками в этой области (по буферизации), но помнить об этом факторе не помешает.

2) Возможностями самого PCI device, будь то master или slave. Хотя идеология построения PC на сегодняшний день предполагает, что для достижения сколько-нибудь приличных скоростей передачи данных по PCI соответсвующее устройство должно быть PCI Master, т.е., само должно заботиться о перемещении данных в нужное место, и само должно стараться обеспечить нужную скорость (а значит, иметь, например, свой собственный DMA на борту). Т.е., весь этот разговор имеет смысл вести, имея в виду в первую очередь все-таки Master-устройства. А конкретное Master-устройство еще должно уметь работать с пакетами длиной в 2K, и не факт, что ваше на такое способно.

3) Но предположим все же, что первые два пункта позволяют передавать пакеты длиной в 2K. Тогда дело остается за "малым" (говорю с иронией, потому что это "малое" может оказаться совсем не таковым): обеспечить правильные настройки PCI обрудования (и мостов, и devices). Тут-то и надо вспомнить о Latency Timer'е, который задает гарантированное *минимальное* время занятия шины (реальная длительность пакета может быть и больше, если никто другой не пытается выйти на шину по истечении заданного в Latency Timer количества тактов). Размер Latency Timer'а - 8 бит, т.е., если ваше устройство не пренебрегает правилами PCI, гарантировать можно только длительность PCI транзакции в (255 + небольшой хвостик в пару-тройку) тактов. Другое дело, что если на этой же шине остальные устройства малоактивны и не будут часто лезть со своими запросами, то весьма приличная часть транзакций вашего устройства может иметь длину пакета и в 2K, и даже больше (если соответствующий bridge(s) позволит ему это). Настраивает Latency Timers во всех PCI устройствах соответствующий драйвер, и должен он это делать, вообще говоря, на основе информации, извлекаемой из MIN_GNT & MAX_LAT всех PCI устройств. Да только, похоже, пока штатные драйвера обходятся упрощенными алгоритмами обработки этой информации, и лепят значения Latency Timer, исходя из принадлежности устройства к тому или иному классу устройств попросту (т.е., если device скажем, просто Slave, и это какой-нить vendor-specific, то дадут ему 8 тактов (к примеру), а если это сетевой контроллер и мастер, то получит он, скажем 0x80). Вывод: придется делать еще и свой драйвер, который, кроме прочего, будет обеспечивать нужную настройку Latency Timer.

Вот такие вот пироги. Надеюсь, не сильно утомил? ;-)

К информации, приведенной в предыдущем сообщении (Raven) могу добавить следующее:
1. Согласно спецификации PCI максимальная длина пакета не ограничена (в отличие от PCI-X, где она не может быть более 4096 байт). Лично приходилось фиксировать длину пакета около 24 кБайт, что соответствовало количеству данных в буфере платы (в качестве операционки использовалась DOS и другие аппаратные средства ПЭВМ, которые могли бы выходить на шину не задействовались).
2. Действительно следует обратить внимание на архитекуру системы (чипсет), а особенно на иерархию шин в системе. Зачастую многие транзакции завершаются TARGET-ABORT еще до достижения значения, указанного в регистре "Latency Timer".

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

да, по результатам дискуссии я начинаю приходить к мнению, что нужно будет изменить логику работы блока (сейчас именно из-за неё выдвигается требование о размере пакета в 2 килослова), подключаемого к PCI-контроллеру

по всей видимости, буду использовать пакеты длиной около 16

Если пересматривать логику работы контроллера, то зачем опять ориентироваться на конкретную длину пакета. Оптимально иметь 2 буфера данных: малого объема (буфер PCI 16 или 32 слова для сопряжения с шиной PCI) и большого объема (буфер данных для накопления данных), причем в качестве внешнего буфера можно использовать внешее FIFO если внутри контроллера реализовать заданный объем не удается. В качестве буфера PCI тоже используется FIFO (внутри контроллера).
Пакет большой длины обеспечивается равенством скоростей чтения из буфера данных (скорость чтения ) и буфера PCI, т.е. при "внутри пакета" при отсутствии тактов ожидания на шине статус буфера PCI изменяться не будет (сколько данных в буфер приходит, столько и уходит).

Думаю, самое время узнать у Vincent Vega, а какая же все-таки скорость передачи требуется между его PCI устройством и памятью. Исходя из этого можно будет и дать более конкретный (а значит, и более полезный практически) совет по организации этого дела.

Vincent, так что за задача у тебя? Чуток подробнее, если можно, и с приведением треб. скорости и возможных особых требований к реализации (if any).

задача - построение платы "захвата" неких данных, подключаемой по интерфейсу PCI.
Из предназначения платы ("захват", т.е. буферизация данных. чтобы их потом можно было более менее не торопясь считывать черех интерфейс PCI) следует, что жёстких требований к скорости обмена по PCI нет.
Особые требования: желательная простота реализации ). Скажем прямо. опыта для таких сложных проектов пока маловато. Собственно, поэтому на режим master пока не хочется замахиваться.

Хотя тут недавно возникла мысль об использовании в качестве PCI-контроллера микросхем от PLX: PCI 9054, PCI 9056. Интересно - кто-нибудь имел с ними дело? Как считаете сложность реализации проекта на них будет ниже? (всё-таки databook на PCI 9056 занимает 350 страниц, что сравнимо со спецификацией PCI)
Дело в том, что согласно документации, они позволяют перекачивать довольно большой поток данных в режиме master. Может быть тогда можно было бы вообще отказаться от буферизации и гнать наш поток (50 млн. 16-тиразрядных слов в секунду) напрямую в память ПК? достижимо ли это на практике?

Т.о. образом требуемая пропускная способность составляет около 100 Мбайт/с. Такая скорость вполне реальна при использовании bus-master на обычной ПЭВМ (реально у нас получалась такая скорость ввода), но при условии что во время обмена не будут использоваться аппаратные средства находящиеся на той же шине (не будет обмена с ипользованием сетевой карты PCI), т.к. подобная скорость близка к предельной на шине PCI (средняя скорость обмена на шине вцелом зависит от установок Latency Taimer: чем значение больше, тем меньше тратится времени на накладные расходы, что указано в спецификации PCI). Для регистрации данных у вас есть только память, данные из которой в масштабе реального времени сбрасывать на HDD в обычной ПЭВМ не получится (см. обсуждение "Скорость записи PCI -> жесткий диск "), а по сему величина сохраняемого блока напрямую зависит от размера памяти, выделенного для обмена. Про PLX ничего сказать не могу: все было реализовано на ПЛИС.

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

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

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

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

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

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

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



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

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

Нажмите для просмотра прикрепленного файла

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

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

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

По всему похоже, что ваша команда впервые приступает к работе с подобными полосами частот и вытекающими из них требуемыми пропускными способностями тракта 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). Советую присмотреться и примерить на себя, короче.

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