scheme_ru

Это объявление - тендер на разработку устройства. Техническое задание на разработку смотрите в прикрепленном файле. Я готов работать как с компаниями в сфере контрактной электроники, так и с индивидуальными специалистами. Отвечать лучше всего сразу на адрес электронной почты, указанный в файле. Желательно, чтобы в откликах присутствовали предложения сроков и цены, а также некоторая информация о себе (а ля портфолио), чтобы можно было получить представление о вашем опыте в данной области. Территориально - Москва. С уважением, Евгений Александрович techzadanie_rfid_wifi.pdf

Предложение для тех, кто не привязан целиком и полностью к миру электроники и готов попробовать себя в других областях. Приглашаются толковые программисты, можно студенты последних курсов технических вузов, для обучения программированию в системе SAP/R3 и последующего трудоустройства. Обучение будет проводиться в Москве в июне-июле, компания молодая отечественная. Обучение бесплатное и подразумевает дальнейшее трудоустройство. Основные требования к потенциальным слушателям: общая логическая и техническая грамотность, опыт работы программистом, технический английский. После успешного обучения слушатели будут приглашены на работу. Стартовый оклад от 30 тыс. руб. в месяц чистыми на руки, зарплата полностью белая. В перспективе зарплата программиста в системе SAP/R3 может достигать 140 тыс. рублей в месяц и выше. Резюме присылайте на e-mail: [email protected]

Перепробовав различные средства создания документации и help, могу порекомендовать ComponentOne Doc-to-Help. Документ пишется в MS Word, на выходе можно получить HTML (вполне достойный, не такой, как сам word пишет), CHM и прочие форматы. Удобная система создания линков, автоматической индексации, глоссария и т.п. PDF, к сожалению, сам не пишет - приходится плагином от Acrobat 7 пользоваться. Правда, использую версию 7.2, хотелось бы проапгрейдится до 2005 или даже 2006 - там глюков поменьше и возможностей побольше будет. Help&Manual не понравился - он использует свой формат, а все же привычней писать в Word'е, функционал побогаче, да и написано уже много, не перебивать заново. Еще распространен Robohelp от Macromedia. Впечатления - виснет сам и вешает машину. Посмотрев в процессах, выяснилось, что работает конвертор в режиме эмуляции 16-битной MS DOS. Соответственно, имена файлов длиннее 8 символов не понимает. Видимо, как сто лет назад написали движок, так только обертку правят. Правда, может такая уникальная версия попалась на рассмотрение.

Бывают ли такие программаторы - а ля микроконтроллеры, в которых сценарий работы с выводами (выставление/чтение сигналов) можно было бы полностью писать самому? На вскидку, пробежавшись по программаторам на рынке, создалось впечатление, что такого нижнеуровнего доступа к выводам микросхемы коммерческие программаторы не предоставляют, и для этих целей необходимо делать целиком custom board?

Иерархические имена в Verilog относятся к поведенческой части языка, и синтезаторы их по определению не поддерживают. Хотя, задача протаскивания новых сигналов между модулями сквозь иерархию встречается нередко, почему-то ни один CAD, с которым мне доводилось работать, не предлагает инструмента для автоматизации этой операции, или мне просто нигде не удалось такого инструмента разглядеть.

Например, eCos: http://ecos.sourceware.org/docs-latest/ref...-ecos-port.html

Что-то за обилием постов конкретные вопросы как-то замылились. Ну вот на те, которые выудил из текста: 1. Wire-speed (line-rate...) - в общем, верно - коммутация на скорости пропускной способности. При этом гарантирована коммутация кадров даже в том случае, если они поступают с пиковой загрузкой, равной пропускной способности сегмента. Задержка на прохождение кадров через коммутатор (при условии, что кадр первый и очереди свободны) здесь фактически равна следующему: время поступления кадра в коммутатор + время выдачи кадра из коммутатора (т.е. зависит только от длины кадра и пропускной способности канала), само же вычисление маршрута практически задержки не вносит. Современные коммутаторы Ethernet 10/100 обычно разруливают траффик полноценно. Вычисление маршрута кадра происходит паралелльно самому процессу приема кадра. Т.е. на момент, когда кадр закончит поступать в коммутатор, его маршрут уже известен, и он сразу может поступать на выход (если, конечно в очереди никого нет). Однако для гигабитных сетей, производители иногда лукавят - для кадров большой длины действительно пропускная способность выдерживается высокой; но если плотным потоком будут поступать кадры с минимальной длиной, то скорее всего начнут появляться "дыры" и потери. 2. По поводу переполнения выходных буферов и QoS. В коммутаторах уровня 2 обычно все Quality of Service упирается в один механизм: best effort - "наилучшее усилие". В общем, тут используется принцип приоритетов: либо по портам, либо по тэгам кадров в соответствии с IEEE 802.1Q (раньше 802.1P). На практике это означает, что существует несколько выходных очередей на каждом порту, и пакет попадает в ту или иную очередь в соответствии со своим значением приоритета. Порядок выборки кадров из очередей зависит от реализации. Я когда-то делал по-простому: на 16 приоритетных кадров проходит 1 неприоритетный. Всего, кстати, таких приоритетов в соответствии с 802.1Q может быть не более 7. Но на практике в Ethernet коммутаторах реализуют не более 2 или 4 уровней. В случае переполнения очереди кадры приходится уничтожать. Другого решения тут нет. Да, можно использовать механизмы управления потоком, но они в Ethernet "уведомительные", и передатчик может их проигнорировать. С другой стороны, при управлении потоком блокируется входной порт, причем целиком. - и надо иметь серьезные аргументы для того, чтобы из-за переполнения очереди выходного порта целиком блокировать поступление кадров с входного порта (а если совсем правильно - то со всех входных портов, потому как на выходной порт следующий кадр может прийти с любого из входных портов, и разместить его уже будет негде) - тем самым "залипание" по выходу одного потока может привести к перекрестной блокировке всех остальных потоков, не связанных с ним. Можно, конечно, пытаться глубже анализировать трафик, использовать специальные механизмы и т.п. - но это уже не будет Layer 2 switch. Поэтому решение простое - убивать. По поводу, что именно убивать? Здесь написали про последний кадр или случайный кадр. Имхо, уничтожать надо самый "древний" кадр, который дольше всех "живет" в коммутаторе. По моему опыту, TCP в таком случае легче и гибче разруливает ситуацию, происходит меньше ретрансмиссий и быстрее настраивается интенсивность потока. Хотя, строгого статистического анализа на разных типах трафика и разных загрузках я не проводил. 3. Integrated - интегрированный. Весь коммутатор на одном чипе. В отличие, скажем, от брэндовых Cisco или 3Com, которые любят "размазывать" свои коммутаторы по чипсету: процессор, коммутирующая матрица, контроллеры интерфейсов. Хотя, слово integrated применительно к Ethernet switch controller может иногда означать еще два момента: 1. интегрированы трансиверы физического уровня PHY (Tx); 2. интегрирована буферная память пакетов в чип. 4. Multi-layer - значит, не просто layer 2 чип, т.е. коммутатор, а еще может анализировать и более высокиий уровни - маршрутизатор на уровне 3 (IP), обрабатывать транспортные протоколы уровня 4 (TCP) и т.д. В качестве примера приведу один интересный чип - ADM5120. С одной стороны, это коммутатор уровня 2, но наличие ядра MIPS и шины PCI позволяет строить на этом чипе действительно многоуровневые сетевые устройства - шлюзы, сетевые экраны, точки доступа и т.д. 5. Да, про aging еще скажу. Это действительно устаревание MAC-адресов в адресной таблице. Устаревают только динамические MAC-адреса, которым коммутатор обучился автоматически в процессе работы и анализа трафика. Рекомендованное время устаревания 300с. Эта цифра, да и сам термин более подробно освещен в стандарте IEEE 802.1D - фактическом стандарте на коммутаторы и мосты уровня 2.

Ну тогда вот: 1. Realtek RTL8316B http://www.realtek.com.tw/products/product...modelid=2005052 2. VIA Atlantic family http://www.vntek.com/en/products/atlantic/ 3. Marvell GalNet®-2 Switched Ethernet Controllers http://www.marvell.com/products/switching/...2plus/index.jsp Только у Marvell традиционно проблема с получением документации. 4. Intel Media Switch http://www.intel.com/design/network/produc...inecard_esc.htm 5. Vitess Heathrow http://www.vitesse.com/products/product.php?number=VSC7302 6. LSILogic StreamPack http://www.lsilogic.com/products/switches/ 7. Broadcom ROBOswitch http://www.broadcom.com/products/Enterpris...ing-Products#s7 Список можно продолжать и далее. Вроде даже есть подобная отечественная разработка. В качестве обвязки к контроллерам обычно используется какая-нибудь память и порт управления: либо какой-то специфический для реализации которого надо что-то сделать на FPGA, либо один из стандартных интерфейсов - напр., последовательный.

А те устройства, которые планируется объединять, уже имеют интерфейсы типа MII/RMII? Если нет, то использование Ethernet внутри устройства - не самое лучшее решение. Вам придется реализовывать MAC-контроллеры во всех устройствах, сборщики Ethernet - кадров и т.п. Не говоря уже о том, что single chip Ethernet switch controller с цифровыми портами, а не витой парой, сейчас - штука редкая, технология не стоит на месте. Впрочем, можете поискать в google эту фразу, что-то и вывалится, но сможете ли купить. Если все устройства на fpga, то можно реализовать какой-нибудь свой простенький пакетный коммутатор. Это будет и проще и эффективней. По поводу FPGA - вот есть, только сколько ж это стоит: http://www.altera.com/products/ip/iup/ethernet/m-mtip.html

Продукция фирмы Wiznet может Вас заинтересовать. Вот здесь ссылка на русском языке http://www.efo.ru/doc/Wiznet/Wiznet.pl?494 Обратите внимание на компонентные модули, - это как раз то, о чем Вы говорите. Что касается уровня обработки - IP, UDP/TCP, то это, наверняка настраивается, правда сам не использовал, врать не буду.

Порекомендую ту же белорусскую систему Search, которая упоминается в указанной ветке. Только, подозреваю, за нее придется заплатить, и вряд ли вы сумеете найти ломанный продукт. Вот ссылка на сайт разработчиков http://www.intermech.ru/search.htm Чтобы не покупать кота в мешке, они вам могут предложить evaluation версию, и вообще к потенциальным клиентам относятся очень внимательно, постоянно теребят и готовы идти на различные уступки.

[Вопрос 1] Так, да не совсем. В спецификации AXI п. 8.2.: "The data for a sequence of write transactions with the same AWID value must complete in the same order that the master issued the addresses in." Другими словами, если AWID одинаковые, но адреса разные, то сначала должна быть полностью завершена транзакция, соответствующая первому адресу, т.е. слэйву 1. Затем только мастер начнет выставлять данные, соответствующие второй транзакции, т.е. слэйву 2. Вы так и написали. Но что касается интерконнекта, все несколько проще. Стэк коммутаций в интерконнекте - это полностью на воле разработчика. Если есть ресурсы и желание - пусть реализует стэк. В крайнем случае, он просто может снимать сигнал подтверждения адреса на адресном канале сразу после начала первой транзакции, и ожидать, пока она не завершится. Вообще, от глубины такого стэка будет зависеть, сколько отложенных транзакций может поддерживать интерконнект. Как только возможности исчерпаны - снимается сигнал подтверждения адреса на канале адреса. [Вопрос 2] Зачем слэйву вообще переставлять транзакции? Пусть в сквозном режиме как данные приходят, так он их и перенаправляет дальше потребителям - например, в память. Фраза о "slave must never stall..." говорит о том, что потребители разных потоков (ID) в слэйве должны обладать одинаковой производительностью, чтобы избежать взаимной блокировки потоков. То, что я в предыдущем посте назвал рекомендацией, в спецификации, оказывается, идет со словом must-обязательно. В Вашем случае все проще - потребитель в слэйве один - память, поэтому все потоки будут обрабатываться с одинаковой производительностью и взаимоблокировок потоков не будет. Особняком стоит вопрос сохранения строгой последовательности событий в рамках AXI. Да, последовательность событий может нарушаться (тот же пример с одновременным запросом от нескольких мастеров - понятно, что на слэйв запросы придут в той очередности, которую назначит им интерконнект - последовательность событий изменится, вместо одновременного запроса образовалась очередь во времени), и нижнеуровневый протокол коммутации AXI это не волнует. В AXI говорится: "If two write transactions with different AWID values access the same or overlapping address locations then the processing order is not defined. A higher-level protocol must ensure the correct order of transaction processing." А с точки зрения слэйва и интерконнекта транзакции от разных мастеров имеют разный AWID., т.е. данное предложение однозначно говорит о том, что перестановкой данных от разных транзакций слэйв заниматься не обязан. Данные на канале записи не появятся до тех пор, пока не будет подтверждения начала транзакции на канале адреса сигналом ready. Т.е. увеличение количества защелок на канале адреса проведет лишь к сдвигу и увеличению продолжительности транзакции, но никак не к инверсии последовательности фаз. Точнее, появиться-то данные могут и раньше, они там могут быть даже постоянно, но они будут игнорироваться до тех пор, пока слэйв не подтвердит начало транзакции на канале адреса. Т.е. последовательность событий фиксирована: 1. Сначала происходит handshaking на канале адреса. 2. Если выполнено 1., то разрешен прием данных и соответствующие handshaking на канале данных. Иначе получалась бы та нерабериха с блуждающими данными, о которой я писал в прошлом сообщении.

ВОТ! Вот в этом-то и состоит вопрос! Если обязать слэйв принимать данные на запись в любой последовательности, то количество логики со стороны слэйва выростает до безобразия! Давайте разберемся: В таком случае слэйв должен иметь некий буфер данных для записи, чтобы в любом случае иметь возможность принять данные от мастера. Разбор получаемых данных может происходить, либо "на лету" (т.е. сразу рассортировываться по нескольким очередям), либо необходимо организовать выборку требуемых данных из единой очереди. Оба варианта требуют ощутимое количество аппаратуры (хотябы той же памяти). Так же не ясен размер этого буфера. Сколько может прийти "непоследовательных" данных?! Т.к. по спецификации данные могут приходить раньше самого запроса на запись(фазы передачи адреса записи), то получается что ограничить их число можно только принятием некого дополнительного соглашения по работе Мастера. Например: данные на запись приходят не ранее такого-то количества фаз данных, и не позднее такого-то количества фаз данных относительно фазы передачи адреса. Что так же может добавить логики и Мастеру! Получается что ядро AXI - максимально упрощено, а логика мастеров и слейвов таким образом сильно усложняется! Вопросы: 1) Верны ли на ваш взгляд мои суждения? 2) Нет ли каких-нибудь идей по решению этого вопроса? 3) Возможна ли реализация "возможности отклонения приема текущего слова данных типа Retry later или Get off and let the faster go first" без отступления от спецификации? <{POST_SNAPBACK}> Да ну, не сгущайте краски, все совсем не так мрачно. Во-первых, никто не заставляет слэйв принимать данные на каждом такте или с неприемлимо высокой для него скоростью. Как только внутренние ресурсы заполняются - слэйв снимает сигнал готовности READY - и все, шина данных висит, пока внутренние ресурсы не освободятся и слэйв не будет способен продолжить прием, о чем он потом снова просигнализирует активизацией сигнала READY. Никаких мегабуферов не нужно, можно даже одним регистром обойтись, и вся игра идет на блокировании/разблокировании шины механизмом handshaking. Проблема тут только одна: в случае, если слэйв одновременно реализует два интерфейса, существенно различающихся по производительности (напр., последовательный порт и синхронную память), то потоки на запись в медленный интерфейс могут блокировать потоки на запись в быстрый интерфейс. Да и то, это локальная блокировка, т.е. она актуальна лишь для данного слэйва и лишь для порта связи слэйва с интерконнектом. Мастер она не сильно напряжет: если мастер умеет работать с несколькими потоками, то он параллельно сможет работать с остальными слэйвами, и на производительностях тех обменов локальная блокировка в одном из слэйвов не скажется. Но вообще, отсюда сразу следует рекомендация - желательно в одном слэйве реализовывать интерфейсы, близкие по производительностям, чтобы не было таких затыков, когда производительность быстрого интерфейса блокировками фактически сведется к производительности медленного интерфейса. Вот с этим утверждением совершенно не согласен. Где это в спецификации такое говорится? Это что, получается, что по AXI могут "гулять" неприкаянные данные, которые вроде уже есть, но по какому адресу их нужно направить еще не известно, и к какому burst-у они относятся, тоже непонятно? Откуда же берутся такие данные, разве какой-то мастер может сначала послать данные, а потом вдогонку пустить адрес и размер burst-а??? Где же эти данные "пережидают" момента, пока придет указание, куда их нужно направить - в недрах интерконнекта или по умолчанию, на всякий случай, рассылаются всем слэйвам, а там уж, когда адрес придет - видно будет, кому они достались по ошибке? Нет, телега впереди лошади в AXI ходить не умеет. Сначала адресная фаза, в которой указывается адрес, размер burst-а (!), а также характеристики транзакции (тэги и дополнительные атрибуты), а уже только потом идут данные. И никак иначе.

По какому принципу тогда коммутируется Канал данных операции записи? Поле WID этого канала выставляется мастером, однако слэйв имеет право выполнять транзакции(с разными ID) в любом порядке. Значит ему могут понадобиться данные от другой транзакции. А мастер не имеет возможности определить данные какой именно транзакции нужно передать слэйву. <{POST_SNAPBACK}> Не совсем понял, в чем вопрос? Мастер посылает данные с 4-битовыми WID не заботясь о том, кто и как эти данные потом разбирает. Единственное, что он отслеживает - это handshaking на каждое слово и статус передачи на канале отклика. Он никак не идентифицирует слэйва-получателя транзакции. Слэйв определяется интерконнектом по memory map, и только интерконнект должен помнить на какой слэйв скоммутирована транзакция с данным ID от данного мастера. В слэйв данные приходят с 8-битовым WID, старшие разряды которого указывают на мастера-источника данных, а младшие на номер потока(транзакции), который этот мастер присвоил данной транзакции. И при операциях записи это не "слэйв имеет право выполнять транзакции с разными ID в любом порядке", а мастер имеет право выставлять данные с разными ID в произвольном порядке. Либо интерконнект может одновременно коммутировать на слэйв потоки от нескольких мастеров. Слэйв же обязан разбирать данные именно в том порядке, в котором они к нему приходят (иначе на канале записи данных необходимо было бы ввести возможность отклоенения приема текущего слова данных типа Retry later или Get off and let the faster go first, после которого пропускался бы более быстрый поток, а потом снова бы возвращалось отложенное слово ). Количество потоков с разными ID, которые способен обрабатывать слэйв, определяется количеством адресов, посланных на слэйв до того момента, пока слэйв не снимет сигнал готовности приема очередного адреса через handshaking сигналами valid и ready на канале адреса. Т.е., если слэйв подверждает прием каждого следующего адреса на канале адреса только после полного завершения предыдущего пакета (burst), это означает, что он способен одновременно обрабатывать лишь один поток. Если же он подтвердит прием, к примеру, 4-х новых адресов, а 5-го не подтвердит до тех пор, пока один из burst-ов не завершится, это означает, что он способен обрабатывать до 4-х параллельных потоков.

Да, эти тэги. Interleaving - это частный случай Ordering Model шины AXI, касающийся реализации неупорядоченной операции записи в слэйве. В общем случае речь идет просто о том, что данные могут поступать что на запись, что на чтение не в том порядке, в котором поступали адреса, соответствующие этим данным. На этот вопрос в спецификации четко даны ответы в пп. 8.7 и 8.8. Рекомендуется, чтобы ширина ID в мастере была равна 4 битам, а ширина ID в слэйве равна 8 битам. Оставшиеся 4 бита к ID мастера должен добавлять сам интерконнект по принципу "географической адресации" статически таким образом, чтобы 4-битовая "база" ID у каждого мастера была уникальной в рамках интерконнекта. При такой схеме один мастер одновременно может обрабатывать до 16 перемешанных потоков, а в рамках интерконнекта может находиться до 16 мастеров. У слэйвов нет ID, как их нет и у мастеров. ID - это атрибут транзакции, а не идентификатор слэйва или мастера, и он не используется для глобальной адресации внутри интерконнекта. ID нужны для того, чтобы участники взаимодействий в перемешанных потоках данных могли в правильном порядке собрать данные на получающей стороне, а также вернуть отклик соответствующему мастеру. Т.е. мастер, начиная транзакцию, назначает ей некоторый 4-битовый ID, затем к этому ID интерконнект добавляет "базовые" 4 бита, уникальные для данного мастера. Таким образом, вся транзакция в рамках интерконнекта характеризуется уникальным ID. Этот ID затем будет использоваться интерконнектом и слэйвом для манипулирования с потоками данных и откликов, т.к. каждый отклик и слово данных сопровождаются своим ID. Правила обработки транзакций с учетом этих ID приведены в спецификации AXI в главе 8 - основной перечень правил в п. 8.2. А выборка слэйва производится только по адресу в соответствии с memory map, тэги тут никакой роли не играют. Похоже, что Вы за базовый документ приняли PrimeCell AXI Configurable Interconnect (PL300) Technical Reference Manual, а не собственно спецификацию AMBA AXI Protocol v1.0 Specification. В самой AXI нет никакой TrustZone, поэтому не стоит себе забивать себе голову этим feature некоторой частной реализации интерконнекта AXI, который, по-видимому нужен был кому-то из первых клиентов-заказчиков PL300. Да, невыровненные передачи тоже сюда относятся. Но вопрос стоит несколько шире: если интерконнект универальный и конфигурируемый, то он должен уметь поддерживать абонентов с разными размерностями шин данных, а также с разным типом endianity. Вот тут как раз и возникает большая-пребольшая ж***. Для организации взаимодействия пары мастер-слэйв с произвольной шириной шины данных и endianity с каждой стороны, да еще и с возможностью невыровненных передач, там придется наворачивать очень даже интересный мультиплексор-перестановщик, который будет перекачивать потоки данных из одного представления в другое и обратно. И такая машинка, в принципе должна стоять на каждой возможной связке мастер-слэйв внутри интерконнекта в каждом направлении, если планируется, что интерконнект будет неблокирующим и разрешены одновременные обмены данными между разными парами мастер-слэйв.