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).

Пользую BDI2000 с двумя PowerPC вариантами. Опишите, пожалуйста, поподробнее, что именно не работает.

В обычном PCI (про экспресс пока не в курсе) BAR регистры бриджа программируются так, чтобы они покрывали адресные пространства всех устройств на другой стороне бриджа. Для иллюстрации, если устройства X,Y,Z на вторичной шине живут по адресам 0x80000000, 0x80100000 и 0x80200000 и каждое требует 1М адресного пространства, то бридж должен быть сконфигурурован так, чтобы отвечал не запросы до адресам всех устройств на вторичной шине. В данном случае 0x80000000..0x802fffff. [host] | ----------------- | [B] | ----------------- | | | [X] [Y] [Z] Это все можно представить так, что для всех устройств по одну сторону бриджа бридж выглядит как одно устройства. Если кто-нибудь к нему обращается, то бридж начинает соответствующую транзакцию на другой стороне. Соответственно, чтобы с одной стороны запросы могли добраться до всех устройств на другой стороне, бридж должен отвечать на запросы с адресами любого из устройств на вторичной шине. Эта процедура применяется ко всем типам адресов - I/O, prefetchable и non-prefetchable memory. Если интересны детали, можете заглянуть в исходники NetBSD - там все довольно наглядно. http://cvsweb.netbsd.org/bsdweb.cgi/src/sy...x-cvsweb-markup

V4 + ISERDES + XAPP705 ? Вот только с lvttl действительно непонятно. http://direct.xilinx.com/bvdocs/publications/xapp705.pdf

Взгляните на Freescale MPC8548/8547/8545/8543 http://www.freescale.com/webapp/sps/site/p...=01272645247973 До 1.5ГГц (вероятно, что до 1.8 дотянут) 32К+32К L1 кэша + 512К L2 кэша ~10Ватт на 1ГГц DDR2,PCI,PCI-Ex,до 4-х Гигабитных контроллеров. Ядро довольно шустрое с SIMD расширениями а-ля AltiVec, что должно помочь.

Этот проц и впрямь новый и интересный... Два ядра плюс pattern matching engine - regex в железе. А вот это довольно старая новость. У меня такая плата вот уж почти с год под столом пылится. Впрочем, проц и впрямь симпатичный вышел. По словам народа из Freescale они были сами приятно удивлены, что проц вышел настолько шустрый. В прошлом году обещали как раз 1.3ГГц как максимум. Сейчас, похоже, по результатам новоиспеченного Rev.2 замахиваются на 1.8ГГц. Все хорошо, вот только 85xx в несколько иной категории нежели 405. Как по скорости, так и по периферии, так и по потреблению, так и по цене.

Мня. А куда, интересно, содержимое моего оригинального сообщения исчезло? Тема-то создалась, а сообщение куда-то провалилось. В общем - вопрос сталкивался ли к то с этим продуктом на практике. На бумажке обещают много чего. Особо интересно, что, похоже все это дело состоит из функциональных моделей процессорного ядра (разных) и памяти плюс RTL on-chip периферии, что позволяет аккуратно симулировать железо. Также упоминалась возможность использовать все это как black-box в тест бенчах - процепил его к модели своего устройства, а в качестве стимула - клок и настоящая программа. Если кто работал с Seamless, поделитесь, пожалуйста, впечатлениями.

Попробуйте посмотреть осциллографом на сигналы RX_ER/TX_ER GMII/RGMII или чем там у вас MAC и PHY связаны. Это позволит понять где проблема. Если PHY чего-то не понял, то увидите сигнал об ошибке. Иногда полезно убедиться, что отладочные прибамбасы у PHY отключены. Я однажды наступил на грабли когда у PHY из-за ошибки в схеме по умолчанию был отключен скрамблер. PHY отвечает за то, чтобы пакет был отослан/принят. То бишь ему более интересно как данные закодировать/раскодировать для передачи по проводам/оптике, а что во внутри пакета его не волнует. С содержимым пакета пусть MAC разбирается - проверка CRC, разборка с тем, для кого пакет, unicast/broadcast и т.д. Я все это к тому, что эталонный пакет вам сильно не поможет. Зависит от MAC и драйверов. Обычто MAC пакет таки принимает, но помечает, что CRC не совпадает. Драйвер в таком случае пакет выкидывает и увеличивает счетчик ошибок.

Хмм.. RiscWatch.. Похоже, что они скрестили симулятор и оболочку их дебаггера RiscWatch, который обычно идет, собственно, с железякой-пробом. Симулятор, похоже, как раз и прикидывается пробом прицепленым к процессору. В принципе - вполне адекватно. Жаль, что GDB к нему вряд-ли прицепишь. Кстати, они обещают хорошее приближение количества циклов на инструкцию. Впрочем, удивляет не сильно - с суперскалярностью в 405 не сильно. в 440 получше, но тоже без особых наворотов, так что предсказать, что, когда и где исполняется наверное не так уж и сложно.

К сожалению, timing model у них, похоже, только для относительно "толстых" ядер - e500 и 74xx. И у того и у другого конвейер существенно длиннее, чем у 405, больше execution units и куча других существенных отличий. 603e/e300/G2/G2LE был бы ближе к теме, но, увы. Так что приближение будет довольно грубое. Но все же лучше/быстрее, чем разрисовывать конвейер на бумажке. С другой стороны, не удивлюсь, если у Freescale есть аккуратные модели и для ядер попроще, вот только на их веб сайте о них забыли упомянуть - такое тоже бывает. Впрочем, надежды не очень много. Если мне не изменяет память, когда нам Freescale расхваливал 8548, то гордо били пяткой в грудь, что, мол, сделали точный эмулятор и все вылизали до выхода чипа. У меня сложилось впечатление, что это у них был первый подобный эмулятор. До этого в основном использовали функциональные симуляторы - исполняет инструкции как надо, но вот временные характеристики жизни никак не соответствуют. Интересно, ведь как пить дать у IBM тоже эмуляторы есть/были. Кто-нибудь видел для 405?

Кстати, об эмуляторах. У Freescale есть кучка эмуляторов для их ядер, включая эмуляторы с аккуратными таймингами. Можно в явном виде увидеть как инструкции раскладываются по конвейеру. http://www.freescale.com/webapp/sps/site/o...PCPPCPMD&srch=1 Из минусов - дают нахаляву, но просто так не скачаешь - надо, чтобы кто-нибудь из Freescale разрешил (sales/Field Application Engineer).