v_mirgorodsky
-
Постов
341 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные v_mirgorodsky
-
-
Не знаю как сейчас, но еще полтора года назад на VD Mais качество пайки BGA корпусов было просто отвратным. Это - из личного опыта.
-
Поскольку ваш входной поток предполагается мизерным по отношению к выходному потоку, то тратить слишком много усилий на приемную сторону действительно не стоит. Просто вы уж очень круто и расточительно обходитесь с ресурсами чипа - в любом случае - ваш проект, вам и принимать решение. Я делал по другому.
Для работы с Jumbo пакетами необходимо писать свой драйвер. Сама система, если не ошибаюсь, не предоставляет сервисов доступа к столь низкоуровневм функциям.
Еще, берут легкие сомнения в способности виндового TCP/IP стека прокачать с одного сетевого интерфейса 90MB/s :cranky: Еще, из моего опыта, хостовую сетевуху лучше брать серверную. Она несколько дороже, но гораздо меньше грузит процессор хоста на приеме за счет аппаратных ускорителей предварительного разбора Ethernet фреймов.
-
Dimonira
Все это оч круто, до тех пор, пока не надо заботиться о пиковой пропускной способности самого канала. Размер Ethernet пакета может варьироваться в очень широких пределах, сейчас точно не вспомню, но минимальная длинна была порядка 64 байта, а максимальная зависела от текущего режима работы сети и составляла от ~1500 байт до 16кБ. Ну и как при таком разнообразии входных параметров будет работать ваша система с двумя FIFO? И это с учетом того, что память в Спартане побита блоками по 4кБ :cranky: Т.е. в идеале в два блока памяти пометилось бы почти 4.5 1500 байтных пакета, а в вашем случае аж два :ninja:
Еще момент. В дуплексной сети ошибок в пакетах я не встречал. Практически все современное оборудование работает в дуплексе - о каких ошибках приема мы говорим? Да, они возможны, но как исключение из правил, а не как постоянная практика. По этой причине затачивать тракт под эффективное удавливание ошибочных пакетов в минимуме, IMHO, избыточно. Хотя мож вы собираетесь связываться по Ethernet в условиях жесточайших электро-магнитных помех :cranky:
Основным источником ошибок в полудуплексной сети служат коллизии. А по стандарту они считаются невозможными начиная с определенного байта пакета. По этой причине проще забакапить голову пакета на SRL, а потом уже при отсутствии коллизий начать записывать в основное FIFO.
Все эти моменты я знаю из собственного опыта написания и отладки собственного TriSpeed Gigabit Ethernet MAC. BTW, полнофункциональный TriSpeed Gigabit Ethernet MAC требует для своей реализации немногим больше 1000 альтеровских ячеек или 500 хилых слайсов. То, что генерит кореген, IMHO, слегка избыточно.
P.S. Мы на гигабите разгоняли медиум до ~123MB/s - остались только самые положительные впечатления от Ethernet как от интерфейса :w00t:
-
Берем и увеличиваем шину FIFO на один бит, этот бит делаем равным единице в начале и конце езернет пакета. Дальнейшая логика без особых проблем может разобраться первый это байт пакета или нет. Если совсем немного помудрить и сделать приемную шину хотя бы x16 то тогда на шару можно получить целых два лишних бита, и тогда вообще никакой неоднозначности не возникнет. Такая доделка займет совсем немного ресурсов, а позволит увеличить глубину FIFO в два раза и использовать его более эффективно.Короче я решил сделать два приёмных ФИФО вместо одного. Алгоритм простой: когда пакет принят в один ФИФО (причём принят только успешно), то два ФИФО "переключаются" между собой, так что следующий пакет будет приниматься в другой ФИФО, а тем временем первый ФИФО будет вычитан процессором (по выставленному прерыванию). -
Ну чо, давайте пи...ми меряться ;) Я начинал програмить еще на ЕС1045, первым моим компилятором был компилятор с языка PL/1, до сих пор где-то валяются записи по синтаксису языка PL/1 и описание некоторых его библиотек. В то время каждый этап сборки программы выполнялся отдельной программой и надо было помнить командную строку запуска транслятора, компилятора, линкера и еще нескольких программ, непосредственно участвовавших в процессе. Отладка даже простой программы могла растянуться на день, а иногда и на больше.ага - и на марсе скоро будут яблони цвести. конечно когда-нибудь всё у всех будет. да и в принципе языки программирования отомрут - компиляторы будут непосредственно читать гениальные мысли разработчика прям из мозга - по электромагнитным показаниям его активностьСегодня в Delphi полноценное диалоговое приложение можно накатать просто возюкая мышой по экрану.
Эволюция от ЕС1045 с PL/1 до компиляторов сегодняшнего уровня была пройдена менее чем за 15 лет. По моим субъективным оценкам уровень развития компиляторов будущего для FPGA находится где-то во второй половине пути - т.е., лет через пять уже можно будет начинать забывать о идеологии написания аппаратуры на RTL уровне - просто работа на RTL уровне будет уже не эффективной.
-
Угу, так потому я и сказал о дальнейшем развитии технологий FPGA до той степени, когда 10-20 тысяч макроячеек - типа современных альтеровский ALUT'ов будут раздаваться в качестве бонуса к основному объему самой FPGA :) Согласен, это время наступит очень не скоро, но оно обязательно придет. Все ведь дело в соотношении стоимости чипа ко времени программиста его проектирующего :)я бы не стал проводить подобных аналогий между десктоп-направлением и встраиваемыми применениями (а уж в проекции на FPGA - высокопроизводительными встраиваемыми системами) в процессорах плата за пользовани ЯВУ - увеличенное время выполнения алгоритмав ПЛИС - повышенное потребление (докучи к необходимости применения более емкого и дорогого кристалла)в ASIC-проектировании ситуция еще более интересная (в случае рассмотрения возможного использования SC): надо найти компромисс между площадью (т.е. стоимостью) конечного кристалла и временем разработки + опять же существуют свои сферы устройств с критичным энергопотреблением.C точки зрения временного или пространственного разворота цикла - так это тоже не проблема. Компилятор будущего :) сам примет решение как его развернуть и сгенерит код, который будет давать абсолютно четкий детерминированный результат согласно спецификации языка. Для примера, Intel C++ компилятор версии 6.0 при компиляции исходников для P4 Northwood заменял некоторые операции умножения несколькими операциями сложения - чем не пример пространственного vs временного разворота цикла?
Еще. По роду занятий пришлось немного пооптимизировать на Ассемблере для старших x86 - презанимательнейшее занятие. Как оказалось, каждая команда имеет свое время обновления результатов, их можно спаривать - тогда они выполняются одновременно, если попытаться использовать результат выполнения команды слишком рано, то процессор останавливается и ждет готовности операндов команды, а может запустить другие независимые команды из очереди. Короче, компилятор постоянно решает задачи планирования, подобные временной vs пространственный разворот. И весьма успешно.
Еще более интересным с этой точки зрения оказывается Ассемблер сигнальников. Там можно просто непосредственно указать, что эта инструкция должна быть спарена с той - получаются такие себе сверх оптимальные функции, эффективность которых ограничена только знаниями программиста.
Пройдет время и подобные инструменты появятся и для FPGA. Может не сразу оптимальные, но ведь и компиляторы прошли долгую эволюцию до своего сегодняшнего уровня.
-
Не стоит даже начинать :(( Для удобоваримой скорости зарядки такой аккумулятор необходимо заряжать хотя бы одним ампером тока. Мне не известны успешные реализации таких устройств на такие мощности.До полуметра, я предполагаю что 20в должно хватить, но чем больше тем лучше. Для заряда акумулятора 12В 7Ач.Делаю РОБОТА. -
Для оценки всего проекта не достаточно информации - питание управляющего и управляемого устройства, дальность, желаемая серийность - в смысле подбора комплектующих - малосерийные и единичные изделия сильно отличаются от больших партий. Еще не плохо было бы знать в какие размеры необходимо целиться, от какого питания запитывать сами дистанционные выключатели и целевую область применения устройства, в смысле агрессивности окружающей среды, температуры и других параметров.
Как правильно сказал acex2 здесь подымать полный ZigBee протокол будет просто избыточно. Будет достаточно пары передатчиков от Microchip или подобных.
-
Все зависит от того, на какое растояние надо передать мощность и от ее количества :) На сегодняшний день есть множество приборов, использующих беспроводное питание, начиная от карточек авторизации и заканчивая бытовыми электрическими зубными щетками. Для более конкретного обсуждения уточните область применения и другие сопутствующие параметры :)
-
linda
Если есть конкретные предложения, то говорите. Пока кроме флейма в этой ветке ничего не было. Судя по первому посту, необходимо взять микроконтроллер, прицепить к нему ZigBee физик, прицепить пару транзисторов для управления исполнительными механизмами и на этом закончить. Если это так, то такая работа вряд ли стоит более $1000 и выполняется при наличии опыта в течение двух-трех недель с изготовлением опытного образца.
-
Не стоит рождать полновесный JPEG под ARM, если его нет готового в исходниках или в документированной библиотеке - очень муторное и долгое занятие. А в остальном все сравнительно просто - примеров реализации DKT в нете валом, квантование - просто деление на некие константы, битстрим - для упрощения можно взять похожим на JPEG. Если повезет, то за недели три управитесь.
-
А потом полученное решение выбросить по причине неработоспособности. CMOS сенсоры суть аналоговые устройства с цифровым бак-ендом, потому однозначно гарантировать их полностью синхронную работу не возможно. Это приведет к рассинхронизации входных потоков даных и к дополнительным проблемам при обработке. Такое решение может жить только в том случае, если нет никаких требований к одновременной работе сенсоров. Типа, запустили один - получили картинку, запустили второй.С видеопортами решил поступить так- матрица в 8битном режиме. PPI- как я понял может быть шириной до 16 бит=> каждый CMOS повесить на половинку PPI. CMOSы тактировать одним генератором, а сигналы синхронизации матриц за_and_ить. -
Работоспособность той или иной системы подачи питания зависит от конкретных параметров работы всего устройства. Один керамический кондер на одну питающую ножку перекрывает 90% различных применений и 90% рабочих частот. Если FPGA заливается не полностью или работает на сравнительно низких частотах, то количество кондеров можно уменьшить, однако конкретное число должно быть предметом детального и тщательного анализа. В большинстве случаев разработчики не респолагают конкретными цифрами, способными дать хорошую аппроксимацию толерантности системы подачи питания в зависимости от количества фильтрующих конденсаторов. По этой причине один кондер на одну ножку питания является консервативной хорошо зарекомендовавшей себя практикой построения систем распределения питания.
Кондеры все же следует ставить 0402 - надежно и проверено предыдущим опытом. Монтажники экспериментальных макетов немного матерятся, но со временем привыкают :) Не лишними будут и пара электролитов по VCCINT.
-
Шас под руками Quartus'а нет, но по виду вроде все правильно - должно работать нормально. Доберусь до работы смогу сказать более точно.
-
Можно в тексте исходника, объявляя специфические аттрибуты, можно в файле настройки проекта - *.qpf, если память не изменяет. Оба способа рабочие.
-
Наверное, уже поздновато отвечать, но все же прокомментирую некоторые высказывания.
Такую штука будет даже не фокусом. 66MB/s легко достижимы практически на любом чипсете. Необходимо просто предпринять очень специфические меры по обеспечению доступа бурстами в драйвере устройства.PCI target может быть и потянет - но обычные компы нет. Делайте PCI master.
PCI шина в современном компьютере сегментирована на большое количество сегментов. Каждый из таких сегментов коммутируется на связную шину южного моста, имеющую среднюю пропускную способность в районе 266MB/s. Посему разные мастера совсем даже и не мешают работе друг друга. BTW, 266MB/s - это очень старая информация, сейчас вероятно уже больше. Проверить сие утверждение просто - ставим мощного PCI потребителя данных типа старой видеокарты или платы захвата видео и наслаждаемся совсем даже и незамедленной записью на винчестера во время работы грабера. Из своего опыта - вынимал из порта USB порядка 45MB/s и одновременно работал с винтом - еще метров 60 в секунду - и никаких особых вопросов не возникало.На самом деле в любом компе все устройсва грубо говоря сидят на одной шине. Это все порты USB, сеть, винчестеры и пр. Многие из них умеют писать в DMA режиме, поэтому заранее точно определить загруженность шины невозможно. -
CADiLO
А можете пролить немного света по MMS? Просто есть желание отправлять на мобильный телефон картинку с удаленного объекта по запросу через отправку MMS. На данный момент это только планы, однако хотелось бы знать хотя бы теоретическую возможность реализации такой идеи.
-
Tanya
Можно еще попробовать заказать плату со встроенными пассивными элементами. Понятно, что такое решение намного дороже в изготовлении, однако существенно сложнее в копировании, поскольку кроме топологии необходимо знать точные номиналы спрятанных в толще платы пассивных компонентов. К сожалению, не знаю технологических норм изготовления плат такого типа, потому более точно сказать ничего не смогу.
-
А есть ли что-то подобное по MMS? Должен ли телефон/модуль обладать какими-либо специфическими функциями для поддержки отправки MMS? Я слышал мнение, что MMS ничем существенно не отличаются от SMS за исключением размера. Так ли это?
-
Спасибо, не знал, что так необходимо делать...
-
Demeny
А еще надо внимательно читать вопрос, по которому идет обсуждение - защищать собираемя двухслойную плату, а на двух слоях силуэтов дорожек вполне достаточно для копирования, даже при наличии полигонов на одной или другой стороне.
-
При использовании некоторых мегакоре ядер при установленом флаге что-то связанное с ClearBox - Quartus генерит абсолютно читабельный VHDL исходник, в котором можно посмотреть и примеры использования примитивов пинов и IO блоков. К сожалению, можно только посмотреть - при попытке использовать обычно нарываешься на абсолютное отсутствие документации по компоненту. По этой причине надо делать так, как говорит Самурай - писать код на чистом VHDL и укладывать его в IOB констрейнами.
-
Угу, при наличии двух экземпляров платы вопрос решается в независимости от покрытия и всех остальных ухищрений. Просто один экземпляр вскрываем, видим проблему, второй вскрываем в темной комнате и фотографируем с мощной вспышкой или не вскрываем, но кладем под рентгеновский аппарат. Можно еще поставить ИК прожектор и разбирать сверяясь с любой тривиальной камерой.
Единственное, что приходит на ум, залить всю плату каким-нибудь непрозрачным компаундом. Это не даст гарантии что устройство не скопируют, однако значительно усложнит процесс копирования.
-
Ну примерно так)) Только вот не везде это срабатывает... Мне нужно было снять шумы с TEN12-4813 - удалось, подавил на 30 дБ ( этого было достаточно).. А вот попробовал на TES3-2411, эффект незначительный.. Далее в подробности и теорию не вдавался - голова другим занята сейчас)))
А можно хотя бы схематическую схемку посмотреть? Вопрос очень интересный и очень специфический.
Деление чисел (VHDL)
в Языки проектирования на ПЛИС (FPGA)
Опубликовано · Пожаловаться
Ежли делить будете на ограниченное количество фиксировааных чисел, то деление лучше заменить умножением на обратное.