Jump to content

    

mikeT

Участник
  • Content Count

    76
  • Joined

  • Last visited

Community Reputation

0 Обычный

About mikeT

  • Rank
    Частый гость

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Новосибирск

Recent Profile Visitors

1801 profile views
  1. Спасибо за подробный ответ. Если не секрет (а если секрет, то так и напишите ) кого рассматриваете в качестве производителей? SiFive, Codasip?
  2. Что означает фраза? а) Вы собираетесь писать код под какие-то RISC-V процессоры? Если не секрет, то какие? (производитель и ISA, т.е. например RV64IMDAV) б) Вы сами собираетесь разработать ядра RISC-V, скажем тот-же что и в примере выше RV64IMDAV с микроархитектурой типа "6-issue out-of-order 8 stage pipeline" в) оба пункта И какого размера команды этим всем занимаются?
  3. Имеются две практически идентичные реализации одного и того же проекта. Ниже приведены две таблицы с характеристиками Destination Clock Path (для обоих вариантов). Видно, что различие имеется только для параметра Setup_fdre_C_D: в одном случае он равен 0.076 ns, а в другом 0.033 ns. Отличия в реализации по сути только в одном: в первом случае триггер размещен в SLICEM, во втором в SLICEL. На данный момент мне неясны следующие моменты: что означает параметр Setup_fdre_C_D – это “настоящий” Tsetup для триггера или это какая-то “приведенная” величина (используемая в Xilinx Timimg Analysis) почему при практически идентичной структуре эти параметры имеют различные значения – это отличие обусловлено тем, что используются SLICEM/SLICEL или чем-то другим?
  4. Цитата(Vacik @ Jan 18 2017, 18:54) Не могли бы Вы подробнее описать предлагаемый механизм? Написал вам в личку.
  5. Цитата(Vacik @ Jan 17 2017, 02:38) //на уровне WSA организуется пул "мега"-буферов каждый на 64 пакета это происходит автоматически при использовании WSA? Вы должны задать это все сами. Там не совсем так просто, но в документации написано все достаточно внятно. Кроме буферов там подцепляются т.н. overlapped events и т.д. Цитата(Vacik @ Jan 17 2017, 02:38) Попробовал. Ошибки появляются в процессе загрузки ОС на VirtualBox. Видимо что-то дергает он у хостовой ОС. Это нормально? Насчет этого ничего сказать не могу. Мы работали под виндой чистой. Попробуйте для начала тоже под "чистой" виндой потестить, а иначе вы рискуете бороться с проблемами не связанными собственно с сетью и сокетами (вашей реализацией), а связанными с реализацией сторонних фирм. Цитата(Vacik @ Jan 17 2017, 02:38) Размер буффера сокета на прием 256М. Т.е. не кратно длине 1 пакета. Размер этого буфера влияет конечно, но после какого-то значения (скажем 8М по нашему опыту) уже не так сильно Цитата(Vacik @ Jan 17 2017, 02:38) Ошибки изредка все же есть. Это нормально, это же UDP.
  6. Цитата(Vacik @ Jan 14 2017, 16:19) Есть ли способ улучшить прием? Попробуйте использовать WSASocket и все что с ним связано - это если делать под Windows. Суть в том, что можно организовать прием пачки пакетов как-бы "автоматически", т.е. без "дергания" механизмов синхронизации уровня пользователя. Ну и естественно, организуете свою буферизацию как бы вторым слоем. У нас стояла задача выжать предельную производительность при приеме 1Г потока с нашего железа на комп под виндой. Сначала я написал пробной тест с использованием обычных сокетов, но были проблемы с потерей пакетов, переупорядочиванием (даже на локал-хосте!) и, самое главное, загрузкой процессора. У нас пакеты не превышали обычную длину, т.е. 1472 байта. Был организован пул буферов (количество буферов естественно настраивается, но из практики их количество = 64-256). На каждый принятый пакет формируется сообщение (вроде бы там семафор используется, но это уже детали реализации) и управление передается следующему слою софта (следующему потоку). С WSA сокетами получается двухуровневая буферизация - на уровне WSA организуется пул "мега"-буферов каждый на 64 пакета (это вроде максимум, что WSA может позволить) и ОС дергается уже в 64 раза реже, чем при использовании обычных сокетов. Ну а далее все тоже самое - организуется еще один слой - ряд буферов, как и в первом случае, но теперь это уже буфера 64*1472 (все параметры есс-но задаются как минимум на уровне компайл-тайм), их количество у нас порядка 128. Скорость в установившемся режиме (гоняли сутками) удалось получить на уровне 99.7% или 99.8% от теоретического предела для 1Г. Стабильность высокая. Загрузка процессора небольшая. При грамотно написанном софте можно распараллелить задачу - как минимум аффиннити процессорам задать, но нам и этого не потребовалось. 100% исключить пропадания пакетов нельзя, да и сам UDP это не гарантирует. P.S. А вообще, мне тоже многие знакомы профи сказали "переходи на Линукс"
  7. Насчет библиотек не подскажу, а по самим алгоритмам советую посмотреть очень хорошую книгу (для введения в проблематику) Active Computer Vision by Cooperative Focus and Stereo, Eric Paul Krotkov, 1989. В ней Глава 3, по-моему конкретно по теме. Вообще, сама тема "автофокус" очень серьезная и, несмотря на то, что этой проблемой занимаются давно, "волшебного" решения ("секретной формулы") нет. Не существует "идеальных" алгоритмов, все зависит от задачи. Сам алгоритм, по сути, разбивается на две части: (1) вычисление функционала фокуса, (2) поиск экстремума. Функционал фокуса - это параметр (по сути, число), который характеризует резкость изображения (выбранная зона кадра или весь кадр). Чем резче изображение, тем больше значение функционала фокуса. Если имеется алгоритм для вычисления функционала фокуса, вы можете попробовать найти подвижку оптики, при которой функционал фокуса будет максимальным, т.е. по сути требуется решить задачу поиска экстремума функции (неизвестной). Для ознакомления могу порекомендовать хорошую подборку алгоритмов функционала фокуса - Алгоритмы автофокуса. В реальности, к сожалению, примерно 95% из описанных в "научных" статьях (причем в солидных источниках) алгоритмов, оказываются на практике нерабочими, т.е. это классические "сферические кони в вакууме". Из реально работающих алгоритмов (в условиях зашумленности, перепада освещенности и т.д.) рекомендую обратить внимание на достаточно "старый" TENG (см. исходник по ссылке).
  8. Цитата(aT-DeviLru @ Sep 28 2012, 01:03) Недавно вышел Vivado HLS от Xilinx, который можно использовать для синтеза с SystemC. А есть отзывы именно по поводу того, как Vivado HLS производит синтез с SystemC? Пробовал уже кто-нибудь?
  9. Начал изучать спецификацию шины Avalon и понял что плохо понимаю (даже на уровне терминологии) как использовать, например, BFM модели для верификации, что такое мониторы и т.д. Посоветуйте пожалуйста литературу, а точнее список книг/статей/мануалов, которые раскрывают все необходимые вопросы. В частности, что порекомендуете (и в каком порядке) из приведенного ниже списка: 1. SystemVerilog for Verification: A Guide to Learning the Testbench Language Features by Chris Spear and Greg Tumbush (2012) 2. Writing Testbenches using SystemVerilog by Janick Bergeron (2010) 3. Verification Methodology Manual for SystemVerilog by Janick Bergeron, Eduard Cerny, Alan Hunter and Andy Nightingale (2005) Очень хотелось бы не просто список (а тем более из полутора десятков источников), а что-то типа рекомендуемого плана изучения «от простого к сложному» + какие-то дополнительные темы (возможно отдельные книги) в виде уже «факультативного» освоения.
  10. Embedded C++

    Заинтересовало упоминание языка Ада в задачах, где требуется надежность и т.д. В свое время читал "общеразвивающую" инфу про то, что этот язык был специально создан по заказу МО США именно для сложных, высоконадежных систем, например, для ПО на каких-нибудь крылатых ракетах, истребителях... Полез сейчас в инет посмотреть (ради любопытства) "а на чем написано ПО для А-380, F-35?" Нашел инфу про F-35, про А-380 искать пока лень. Но насчет ПО для F-35 я был несколько удивлен, хотя и ожидал чего-то подобного. Если коротко, то на С++. Один из слайдов документа (ссылка ниже) содержит фотографию Joint Strike Fighter (F-35 Lightning II) и ниже подпись со стрелочкой, указывающей на самолет, "C++ inside". SafetyCriticalC++Presentation.pdf На других ресурсах по этой же теме (софт для F-35) приводятся данные что первоначально там была "солянка" из Ады, С, С++, ассемблера, но потом было решено все 100% кода перевести на С++. Документ достаточно интересный и, мне кажется, заставляет задуматься насчет использования С++ в эмбеддед и холиварах типа С vs. С++.
  11. Здравствуйте. Имеются отладочные комплекты DM37x Evaluation Module (на базе DM3730) и AM3517. Интересует работа только с ядром Cortex A8 (в случае с DM37x Evaluation Module), т.е. поддержка эмулятором двух ядер не требуется. На первом этапе нас интересует работа с голым железом, в дальнейшем с Linux. 1) Возможна ли работа с ними из под CCS 5.x (в частности 5.01) с помощью вашего эмулятора SAU100-USB (v.2)? 2) Если "да", то чем вариант SAU100-USB (v.2) хуже варианта SAU510-USB ISO PLUS JTAG Emulator? (!) Особенно интересует насколько SAU100-USB (v.2) "тормознутее" по сравнению с SAU510-USB ISO PLUS JTAG Emulator. Например, при просмотре дампа памяти, регистров и т.п. Заранее благодарю за ответы.
  12. У нас стоит подобный вопрос - именно для Cyclone IV. Тулз (Power Delivery Network) пока не использовали. На данный момент не спеша собираем инфу по имеющимся референс-дизайнам. Могу посоветовать посмотреть на плату кита DE2-115 (Terasic). В частности, по поводу VCCA, похоже там никто особо не заморачивался - стоит 4 конденсатора по 0.1мк и вроде все (хотя лучше проверьте, конечно сами). Я не призываю тупо копировать "как у Терасика" или "как сделал Вася". Просто привожу пример дизайна, выполненного достаточно солидной конторой. Можно у Альтеры посмотреть аналогичный кит, у них Терасиком ряд китов практически одинаковые, я даже не понимаю зачем их под двумя разными марками выпускать. Если что найдете интересного напишите пожалуйста в тему - думаю этот вопрос будет многим интересен.
  13. Цитата(Boris_TS @ Feb 27 2012, 18:26) Раньше, что-то подобное писали, а теперь нет. Теперь говорят: моделируйте (в том же Hyperlinx), ибо хрен его знает, как вы разведёте Вашу печатную плату - типа оно от разводки зависит больше, чем от ПЛИС. ... Цитата(Boris_TS @ Feb 27 2012, 18:26) ... После долгих препирательств, был получен вразумительный ответ: ну-у-у-у, при вашей частоте и длине трасс всё должно работать... но обещать мы ничего не будем, поэтому берите Hyperlinx и моделируйте ваше устройство - может быть после моделирования у Вас появятся какие-либо дополнительные требования к разводке (или разъёмам и пр. компонентам). О как! Спасибо большое, а я тут собрался от Альтеры ответ типа "Да-Нет" получить. Понимаю, что был в этом вопросе весьма наивным. Думаем сейчас: 1. в Hyperlinx посмотреть, как вы и советовали. 2. на ките со Стратикс-3 глянуть живьем. похоже у всех альтер I/O 1.8V (non-referenced, JESD8-7) одинаково устроены.
  14. Цитата(DmitryR @ Feb 27 2012, 14:53) На самом деле это очень зависит от частоты и это надо моделировать. Вы правы, но как тогда понять стандарт (в моем случае это JESD8-7) - там нет ничего про динамику. И Альтера просто ссылается в таблице (где приведены возможные I/O стандарты) на этот самый JESD.. Допустим я все это смоделирую и все окажется ОК. А через полгода Альтера чуть-чуть изменит технологию и все станет "немножко не так", но приписка "все по стандарту JESD8-7" останется. Я к тому, что должно же быть какое-то четкое руководство или, точнее сказать, договоренность типа "это 1.8 В и это 1.8 В и они стыкуются". Ну а по частотам в приниципе написано отдельно типа "это работает до 150МГц, а это до 133 МГц " (цифры условные).