|
|
Я решил все-такиглянуть более детально в DM642. Я было подумал, что в нем что-то особенное в PCI, но ничего нового не нашел, т.к. там стандартный PCI-порт для С6х, который мне хорошо известен. А раз так, то Ваше понимание его работы ошибочно и вот почему:
1. По описанию Сonfiguration registers самого DM642 доступны ему самому, так что сконфигурировать их ему не проблема.
ответ: неправильно. Речь шла не об PCI I/F CONTROL REGS, которые доступны с двух сторон, а об PCI CONFIGURATION REGS, которые есть PCI TYPE#0 HEADER и доступны только внешнему мастеру на PCI. Сюда входят DevID, VendorID, BARs, etc. Нас интересуют BARs, которые будет некому программировать, т.к. в Вашей системе нет внешнего host-hub и PnP системы. Я в таком режиме PCI i/f @ C64xx на запускал, но наиболее вероятно, что PCI i/f вообще не будет активирован.
Кроме того, при PCI i/f есть проблема DSP BOOT. Использование PCI предполагает, что DSP BOOT будет внешний, а из чего Вам бутироваться если PCI не проинициализирован а забутироваться из FLASH не получиться, т.к. WARMRESET от PCI i/f держит DSP kernel в сбросе?
2. DM642 может и мастером и слэйвом.
ответ: да, может, если его при этом кто-то извне сначала сконфигурирует через PnP, я а Вас такого нет.
3. Мне надо не из NIC массив загонять в процессор, а наоборот. Причём всегда в одну сторону, т.е. наружу. В процессор будет приходить только управление (не много), так что этим можно пренебречь. Надо выдавать где-то не более 0.5G bit/s, но на расстояние 100 м и более. Т.е. наполную напрягать 1G ethernet не надо, но в тоже время Fast ethernet такой поток не потянет. К тому же сетевая организация очень нужна для построения системы (если не рассматривать только один девайс сам по себе).
ответ: даже 0.5G/s очень проблемно, особенно если Вы хотите его задействовать через PCI@DM642. Для этого надо обеспечить порядка 64Mbyte/s, или 16Mwords/s непрерывного потока. С первого взгляда это можно при 32B/66M PCI i/f для DM642, но тут-то и вступает в действие структура PCI i/f для С6х, которая ну никак не оптимизирована для скоростных пересылок. Я уже говорил, что PCI i/f для C6x - это тот-же HPI-порт, но доступный от PCI, а HPI в С6х очень медленный и его скорость очень зависит от того, что делает процессор, т.к. все HPI/PCI пересылки - это скрытый EDMA контроллер. Типовая задержка HPI-порта - это 80..300нс при 600МГц процессоре 6416 (она же соответствует скорости генерации MASTER STREAM для PCI i/f), а вообще задержки могут доходить до 2мкс и более (все зависит от DSP программы), так что это никак не проходит.
С учётом сказанного, может всё-таки это рабочий вариант?
А вообще, на счёт 1G ethernet-а, "Если хочется 1G приценить, то надо цеплять как минимум на DSP-магистраль " и т.д. У меня пока скорее вопрос в том что подцепить? А уж потом как. Ведь большинство 1G EMAC-ов рассчитаны на PCI шину, да ещё и работают только от 0 градусов.
Тут упоминались ещё PM3387/PM3386 от PMC-Sierra, которые не PCI? и казалось бы, подойдут и по температуре (от -45), но у них интерфейс POS-PHY Level 3, возможно, ещё более кривой. Его можно подцепить через FPGA, но я смотрел у Ксалинкса ядро для этого интерфейса, оно стоит до хрена.
Получается, что с 1G вообще любые варианты кривые.
Как же реализовать задачу?
ответ: Ну, молодой человек, Вы хотете прилепить реактивный двигатель к телеге и так, чтобы двигатель найти на помойке и телегу не переделывать (извините за образность). Вот здесь Вы и подошли к главному вопросу: А стоит ли? А вот я бы сказал по другому: стоит ли именно так? Ваш подход не правилен, т.к. Вы пытаетесь выжать теоретический предел из железа, не думая о системе и софте в целом. Посмотрите на 1G PCI чипы. У них у всех 64B/66M i/f. Ведь не спроста произведение 64B*66M более чем в 4 раза больше чем 1Gbit/s!
А Вы забыли о том, кто будет формировать IP-пакеты для NIC платы? (Я предпололагаю, что Вы будете подключаться в IP сеть) А знаете ли Вы, что такое IP (в смысле его реализации, а не интернета как такового) и какие ресурсы процессора требуются для его реализации? Так вот, в нормальных устройствах (например OMAP), все IP/сетевые дела делает как раз второе ядро ARM, а не сам DSP.
Есть фирма ATEME, которая делает системы SOIP (video security over IP) на базе 642, 4-х камер и т.п. Этот кит продается в TI за $15,000. Я советую Вам его купить и поработать с ним, и Вы сразу забудите про 1G для 642.
И вот еще один вопрос Вам: а вообще, причем тут DM642 и чем обусловлен его выбор? Какие DSP-задачи он там должен решать?
Одним словом, если надо 1GE, то его надо делать работающим по монопольной магистрали и скачивающим данные, например, из очень длинного FIFO, куда процессор их будет загонять стримом. Ни в коем случае не использовать напрямую магистраль процессора для исключения всех конфликтов и задержек. Здесь, правда есть проблема обратного взаимодействия и обработки IP-пакетов, но в принципе оно решаемо.
POS-PHY Level 3 пусть Вас не пугает, есть внешние чипы, которые его реализуют. Кроме того, без особх сложностей можно задействовать 1GE чины с PCI 64/66, сделав интерфейс к ним через эмулятор PCI на ПЛИС. Их интерфейс можно программировать от DSP напрямую, а данные передавать через FIFO, но это все страшно безграмотно.
На сем закругляюсь, и так много времени ушло.
Надеюсь, что все вышесказанное добавило Вам реализма и Вы по-другому взгляните на Вашу задачу.
С уважением,
Павел
E-mail: 
info@telesys.ru
