Jump to content

    

xyzzy

Свой
  • Content Count

    95
  • Joined

  • Last visited

Community Reputation

0 Обычный

About xyzzy

  • Rank
    Частый гость
  1. Вопрос по PCI Express

    У PLX есть нечто именуемое DualCast http://www.plxtech.com/support/training/Du...ure%20Explained
  2. подсчитать количество тактов

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

    Цитата(paskal @ May 7 2010, 22:40) Для монтажных целей требовались одножильные провода. Решал эту проблему распусканием Ethernet кабеля. Но вот недавно попался кабель, а провод там многожильный. Подскажите какой марки Ethernet надо искать чтоб там был одножильный провод. Или скажите где еще поискать такие провода. Короткие кабеля для соединения на коротких расстояниях ("patch cable") обычно сделаны из многожильного провода. Кабель для прокладки на большие расстояния идет в катушках и обычно одножильный. На всякий случай ключевые слова -- "stranded core" для многожильного и "solid core" для одножильного.
  4. Цитата(igorsk @ Apr 23 2010, 18:00) Если компилятор от Keil/ARM, то есть интринсик __return_address(). А если gcc, то __builtin_return_address(unsigned in level)
  5. PCI 32x33 на Xilinx

    Цитата(Anyone @ Apr 1 2010, 05:21) Временно забудем про задержку между транзакциями. Есть ли способ заставить северный мост передавать южному не по 16 слов, а по 64 слова? А ваше устройство использует "MEMORY READ" или "MEMORY READ MULTIPLE"? Последняя команда как раз может и намекнуть бриджу, что читать будут много. Впрочем, это будет зависеть от конкретного бриджа. Некоторые имплементации реагируют на обе команды идентично.
  6. Интересно, а как 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
  7. В прошлом году Freescale по ходу Freescale Technology Forum гордо бил себя в грудь, что они открывают внутренности QUICC. Было пару контор воспевающих, как все круто.. http://www.freescale.com/files/netcomm/doc...INE.pdf?fsrch=1 Но.. Как-то ничего никуда не движется. Мы пару лет назад пытались из Freescale выколупать детали, но ничего не вышло. "Мы" - довольно крупный клиент Freescale, регулярно возимся с их чипами еще до того, как они выйдут в Aplha, но в данном случае это ни фига не помогло. Фиг знает, нафиг Freescale так шифроваться...
  8. Пара вопросов недают покоя

    Цитата(Andy Great @ Jul 18 2007, 23:53) Может кто уже пробовал живые? Ау! Намедни взял вот эту платку на 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 нахаляву дает исходники драйверов ко всей периферии и они даже работают. * минимальный геморрой с прерываниями. Вектор сразу указывает на C-функцию. проц сам сохраняет/восстанавливает контекст когда надо, причем сделано это, похоже, с толком. * Есть GCC порт с поддержкой Thumb-2 (тащить с couderoucery.com) * Есть поддержка в FreeRTOS. * Можно отлаживаться и шить флэш через OpenOCD * младшие модели - и впрямь, похоже, могут составить конкуренцию AVR. http://www.luminarymicro.com/products/100_...es_devices.html Чего не хватает: * У Luminary yе видать модели с поддержкой внешней памяти. 64К SRAM и 256К флэша мне маловато.
  9. Могу порекомендовать Protek 608: http://www.tequipment.net/Protek608.asp
  10. Цитата(htol @ Jun 22 2007, 01:07) Вычисления для такого рода передач не сильно много: crc для ip пакета, для ethernet кадра, я так понимаю это будет делать MAC. Хэш по адресу, и поиск в таблице состояний по этому хэшу. Больше пока вычислений не вижу. Тут есть где фантазии разыграться. :-) Взгляните на серьезные генераторы (а заодно и анализаторы) траффика типа Ixia, SmartBits или Agilent. Там можно сотворить практически все, что угодно. Из тривиального и наиболее полезного, к примеру - можно заставить отсылать пакеты на кучу разных VLAN, с уникальным Dest IP, в каждый пакет запихивать timestamp, чтобы потом можно было измерить время путешествия. По отдельности - немного, но в сумме на скоростях больше гигабита нагрузка выходит изрядная. Если готовить все это в памяти, то ее просто не хватит надолго. Скажем, при гигабите надо 100Мб/с. 1Гб - 10 секунд. Не особо густо, если надо гонять траффик целый день. Цитата(htol @ Jun 22 2007, 01:07) Чем мне поможет fpga, если все равно нужно будет обращаться к памяти? В том-то и фокус, что с FPGA можно и без внешней памяти. Формируешь пакеты на лету как тебе надо и скармливаешь синтезированому MACу напрямую. Формирование пакетов - тоже не сильно сложно реализуется - всего-то надо кучку примитивных генераторов по одному на поле в пакете (SRC MAC, DST MAC, Src IP, Dst IP, и т.д.) плюс кучу MUX'ов и FIFO, чтобы из отдельных полей сшить пакет. Генераторы - инкремент.декремент с шагом и/или последовательно вытаскивать данные из таблицы. Цитата(htol @ Jun 22 2007, 01:07) Я так понимаю что скорость доступа к DDR ниже? Например ddr 333MHz 32 bit получаем что-то типа 1s/(333MHz*32bit)= 0.7 нс даже если попадется плохой кусок то задержка будет максимум 15 тактов. С пропускной способностью у памяти действительно все относительно неплохо. Вот только задержка доступа по прежнему хромает. Вот тут довольно неплохо все проиллюстрировано: http://www.digit-life.com/articles2/ddr2-rmma/ddr2-rmma.html Реально даже на процессорах со встроенным контроллером памяти меньше 50нс получить сложно. AMD в этом смысле существенно лучше. Интел пока что изрядно отстает, ибо ему приходится через мост в память лезть. А может вам какой-нибудь Virtex4Pro подойдет. У него на борту и гигабитный мак есть и PowerPC проц. В принципе, можно в проц запихнуть мелкую программулину, которая и будет генерить пакеты на лету. А если взять XC4VFX40, то там процессора целых два. Один на прием, другой на передачу. Вполне может заработать.
  11. Ну, коль уж 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/ Однако, в обоих случаях - проблема найти документацию. Что интел, что броадком страдают изрядным геморроем в этом плане.
  12. Цитата(v_mirgorodsky @ Mar 22 2007, 06:05) PCI шина в современном компьютере сегментирована на большое количество сегментов. Каждый из таких сегментов коммутируется на связную шину южного моста, имеющую среднюю пропускную способность в районе 266MB/s. Посему разные мастера совсем даже и не мешают работе друг друга. BTW, 266MB/s - это очень старая информация, сейчас вероятно уже больше. Проверить сие утверждение просто - ставим мощного PCI потребителя данных типа старой видеокарты или платы захвата видео и наслаждаемся совсем даже и незамедленной записью на винчестера во время работы грабера. Из своего опыта - вынимал из порта USB порядка 45MB/s и одновременно работал с винтом - еще метров 60 в секунду - и никаких особых вопросов не возникало. Южный мост действительно имеет достаточно пропускной способности для *встроенных* устройств и они обычно не сильно мешают друг другу. Но вот устройствам сидящим в PCI разъемах все-же приходится бороться за одну единственную шину. Вы попробуйте прицепить винчестер не ко встроенному в южный мост контроллеру, а к IDE контроллеру воткнутому в PCI слот. Там и посмотрим, как винт уживется с граббером. А еще можно и гигабитный ethernet в соседний слот воткнуть..
  13. BDI2000

    Цитата(Make_Pic @ Jan 5 2007, 04:21) У вас нет случайно программной поддержки для отладки с помощью BDI2000 процев MC68332 и ColdFire ( не совсем по теме)? Компилю с помощью GNU C под WINXP. Увы. Есть только для разных PowerPC - MPC85xx, PPC6xx/7xx/82xx/74xx, PPC40x. Цитата(v_shamaev @ Jan 5 2007, 07:26) Еще раз предлагаю создать общий фонд - для разных архитектур. Если интересно, могу залить то, что у меня есть на FTP. Похоже пора из этой ветки перебираться в более подходящую.
  14. Цитата(Andrey_L @ Dec 17 2006, 22:16) А всё таки - реально ли помощью JTAG'a записать во flash хотя бы начальный загрузчик? пробовал кто-нить? Можно. Я при помощи BDI2000 (JTAG-дебуггер такой) совершенно замечательно заливаю ROM-image во флэш на системе с MPC8548 (PowerPC, Freescale). Если подходить консервативно, то скорость записи в районе 3Kb/s. В этом случае дебаггер сам лезет во флэш без участия процессора. Если поизвращаться и минимально проинициализировать проц/память то можно шить флэш со скоростью в районе 40Kb/s. В этом случае BDI2000, впрочем, жульничает - заливает данные и маленькую программку в память а потом эта уж программка заливает данные во флэш. --Я
  15. Цитата(Stanislav @ Dec 19 2006, 08:45) Проц уж больно лакомый для мощных ембеддед систем. Интересуют средства разработки (в частности, гринхилз). Проблема с 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).