xyzzy

У PLX есть нечто именуемое DualCast http://www.plxtech.com/support/training/Du...ure%20Explained

Две инструкции за такт - это если повезет. Т.е. если между ними нет зависимостей, что данны для инструкций уже доступны, что инструкции никуда "наружу" лезть не надо и т.д. Т.е. читать надо - "до двух инструкций за такт". Ваш пин скорее всего расположен в болке, доступ к которому осуществляется через какую-нибудь шину. Обычно периферийные шины работают на частоте ниже частоты ядра и требуют по крайней мере несколько тактов шины, чтобы передать данные. Вот тут, скорее всего ваше время и набегает.

Короткие кабеля для соединения на коротких расстояниях ("patch cable") обычно сделаны из многожильного провода. Кабель для прокладки на большие расстояния идет в катушках и обычно одножильный. На всякий случай ключевые слова -- "stranded core" для многожильного и "solid core" для одножильного.

А если gcc, то __builtin_return_address(unsigned in level)

А ваше устройство использует "MEMORY READ" или "MEMORY READ MULTIPLE"? Последняя команда как раз может и намекнуть бриджу, что читать будут много. Впрочем, это будет зависеть от конкретного бриджа. Некоторые имплементации реагируют на обе команды идентично.

Интересно, а как reflected-wave switching на котором основана PCI будет дружить со звездной топологией? Сдается мне, что отражения сигнала от концов лучей вызовут проблемы. http://en.wikipedia.org/wiki/Reflected-wave_switching Pci System Architecture - Google Books Result http://www.sigcon.com/Pubs/news/2_28.htm

В прошлом году Freescale по ходу Freescale Technology Forum гордо бил себя в грудь, что они открывают внутренности QUICC. Было пару контор воспевающих, как все круто.. http://www.freescale.com/files/netcomm/doc...INE.pdf?fsrch=1 Но.. Как-то ничего никуда не движется. Мы пару лет назад пытались из Freescale выколупать детали, но ничего не вышло. "Мы" - довольно крупный клиент Freescale, регулярно возимся с их чипами еще до того, как они выйдут в Aplha, но в данном случае это ни фига не помогло. Фиг знает, нафиг Freescale так шифроваться...

Намедни взял вот эту платку на LM3S6965: http://www.luminarymicro.com/products/lm3s...uation_kit.html http://www.luminarymicro.com/products/6900s.html Это в общем-то первый ARM, с которым вплотную столкнулся, так что пока, что вижу - то пою и на полную картину мира не претендую. :) Что понравилось (сами чипы от Luminary и тех поддержка) * периферия и документация вглядят довольно вразумительно * Thumb-2 - все прелести компактности Thumb при скорости не-thumb. http://www.arm.com/pdfs/Thumb-2%20Core%20T...0-%20Final4.pdf * Luminary нахаляву дает исходники драйверов ко всей периферии и они даже работают. :beer: * минимальный геморрой с прерываниями. Вектор сразу указывает на C-функцию. проц сам сохраняет/восстанавливает контекст когда надо, причем сделано это, похоже, с толком. * Есть GCC порт с поддержкой Thumb-2 (тащить с couderoucery.com) * Есть поддержка в FreeRTOS. * Можно отлаживаться и шить флэш через OpenOCD * младшие модели - и впрямь, похоже, могут составить конкуренцию AVR. http://www.luminarymicro.com/products/100_...es_devices.html Чего не хватает: * У Luminary yе видать модели с поддержкой внешней памяти. 64К SRAM и 256К флэша мне маловато.

Могу порекомендовать Protek 608: http://www.tequipment.net/Protek608.asp

Тут есть где фантазии разыграться. :-) Взгляните на серьезные генераторы (а заодно и анализаторы) траффика типа Ixia, SmartBits или Agilent. Там можно сотворить практически все, что угодно. Из тривиального и наиболее полезного, к примеру - можно заставить отсылать пакеты на кучу разных VLAN, с уникальным Dest IP, в каждый пакет запихивать timestamp, чтобы потом можно было измерить время путешествия. По отдельности - немного, но в сумме на скоростях больше гигабита нагрузка выходит изрядная. Если готовить все это в памяти, то ее просто не хватит надолго. Скажем, при гигабите надо 100Мб/с. 1Гб - 10 секунд. Не особо густо, если надо гонять траффик целый день. В том-то и фокус, что с FPGA можно и без внешней памяти. Формируешь пакеты на лету как тебе надо и скармливаешь синтезированому MACу напрямую. Формирование пакетов - тоже не сильно сложно реализуется - всего-то надо кучку примитивных генераторов по одному на поле в пакете (SRC MAC, DST MAC, Src IP, Dst IP, и т.д.) плюс кучу MUX'ов и FIFO, чтобы из отдельных полей сшить пакет. Генераторы - инкремент.декремент с шагом и/или последовательно вытаскивать данные из таблицы. С пропускной способностью у памяти действительно все относительно неплохо. Вот только задержка доступа по прежнему хромает. Вот тут довольно неплохо все проиллюстрировано: http://www.digit-life.com/articles2/ddr2-rmma/ddr2-rmma.html Реально даже на процессорах со встроенным контроллером памяти меньше 50нс получить сложно. AMD в этом смысле существенно лучше. Интел пока что изрядно отстает, ибо ему приходится через мост в память лезть. А может вам какой-нибудь Virtex4Pro подойдет. У него на борту и гигабитный мак есть и PowerPC проц. В принципе, можно в проц запихнуть мелкую программулину, которая и будет генерить пакеты на лету. А если взять XC4VFX40, то там процессора целых два. Один на прием, другой на передачу. Вполне может заработать.

Ну, коль уж 1Гбит захотелось, то это что-то в районе 1.4Мппс при 64-байтных пакетах. В принципе, любой MAC и PHY соответствующий стандарту вполне способен и принять и отослать все на полной скорости. Во времена 32-bit PCI @ 33MHz достьчь полной пропускной способности было затруднительно, но в наши дни PCI-Ex и достаточно шустрые процы ситуацию существенно улучшили. Если ваши условия позволяют вам подготовить все данные для уходящих пакетов в памяти перед началом отсылания, то и проц особо мощный не понадобится. Подготовил данные и дескрипторы и сказал "поехали". Если же вам надо все непрерывным потоком, да еще с меняющимися данными, то без FPGA тут, пожалуй, тяжко будет. Скажем, есть у нас 2ГГц проц. При 1Мппс у нас есть примерно 2000 циклов на прием и передачу одного пакета. Кажется - не так-то и мало. Но. Работать мы будем с большим количеством данных, которое в кэш точно не влазит, значит вероятность того, что процессору придется лезть в память довольно велика. Типичное время доступа к памяти - в районе 50-100нс. Существенная часть вашего бюджета уйдет на простой в ожидании памяти, но, в принципе, что-нибудь не сильно сложное сделать возможно. Если вам производительность при малых пакетах не критична, то в принципе, можно и нетривиальные вещи делать. Из вариантов MAC неплохо себя зарекомендовали интеловские 8254* и Broadcom BCM5706/BCM5708. Оба позволяют откладывать прерывания, чтоб не дергать проц на каждый пакет. Оба с адекватным scatter/gather DMA и позволяют выполнять кое-какие операции полезные в сетевых стеках, но вам, это, наверное, поможет не сильно. Броадкомовские маки особенно интересны, что у них "на борту" у МАКа есть пара собственных процессоров, которые-то уже и занимаются раскладыванием принятых пакетов в память процессору. Несколько лет назад народ из FreeBSD сделал zero-copy прием пакетов. http://people.freebsd.org/~ken/zero_copy/ Однако, в обоих случаях - проблема найти документацию. Что интел, что броадком страдают изрядным геморроем в этом плане.

Южный мост действительно имеет достаточно пропускной способности для *встроенных* устройств и они обычно не сильно мешают друг другу. Но вот устройствам сидящим в PCI разъемах все-же приходится бороться за одну единственную шину. Вы попробуйте прицепить винчестер не ко встроенному в южный мост контроллеру, а к IDE контроллеру воткнутому в PCI слот. Там и посмотрим, как винт уживется с граббером. А еще можно и гигабитный ethernet в соседний слот воткнуть..

Увы. Есть только для разных PowerPC - MPC85xx, PPC6xx/7xx/82xx/74xx, PPC40x. Если интересно, могу залить то, что у меня есть на FTP. Похоже пора из этой ветки перебираться в более подходящую.

Можно. Я при помощи BDI2000 (JTAG-дебуггер такой) совершенно замечательно заливаю ROM-image во флэш на системе с MPC8548 (PowerPC, Freescale). Если подходить консервативно, то скорость записи в районе 3Kb/s. В этом случае дебаггер сам лезет во флэш без участия процессора. Если поизвращаться и минимально проинициализировать проц/память то можно шить флэш со скоростью в районе 40Kb/s. В этом случае BDI2000, впрочем, жульничает - заливает данные и маленькую программку в память а потом эта уж программка заливает данные во флэш. --Я

Проблема с AMCC в том, что непонятны перспективы развития. Даже когда 440 принадлежал IBM перспективы были довольно смутными - больше кэша, больше периферии, но вот частота выше 700-800 МГц не фигурировала ни в одном из роадмапов. 0.13um технология, похоже, не дает прыгнуть выше и, судя, по AMCC-шному роадмапу мигрировать на 90нм или 65нм они пока что не собираются. Если когда-нибудь понадобится больше производительности, то придется перебираться на что-то кардинально иное. В этом смысле с точки зрения производительности Freescale MPC85xx выглядит получше. Есть варианты вплоть до двухядерного 8572 работающего на ~2GHz. http://www.freescale.com/webapp/sps/site/p...p?code=MPC8548E С точки зрения средств разработки GCC работает без особых нареканий (по слухам, несколько лет назад Cisco неплохо проспонсировала PowerPC back-end в GCC).