Jump to content

    

RVlad

Свой
  • Content Count

    135
  • Joined

  • Last visited

Everything posted by RVlad


  1. Цитата(Del @ Apr 14 2005, 20:25)В уже работающей версии устройства стоит TMS320C6713GFN и ADC AK4394 24 битный. На всем этом происходит обработка сигнала. Фильтрация, подавление зеркальных каналов, демодулирование, и.т.д... Ну раз стоит 67 TMS - а это процессор с пл.точкой - то вычислительная мощность алгоритмов весьма значительна --- видимо его и надо использовать . Если вы собираетесь делать что то качественно близкое к данному решению, то реализация на FPGA будет для вас достаточно трудоемкой. (по сравнению с С-Asm программированием VLIW 67 TMSa). Хотя с другой стороны реализовать эффективные алгоритмы ЦОС на VLIW процессоре без использования стандартной библиотеки --- это то же ничего!!
  2. Согласен с Vetal : сделайте , что рекомендуют...ну и пришлите свой тестик - посмотрим ...
  3. Мнея эта тема интересует в том числе и прагматической точки зрения. В данный момент я работаю с разработкой приложения на WinCE. Говорить про недостатки я не буду ... не продуктивно. Но проблема состоит в следующем.Есть два треда - один занимает примерно 10-15% временной диаграммы процесора. Другой, для которого необходимо выдерживать жесткие врменные соотношения . может занимать либо 10, либо 20 либо 50% временной диаграммы(замеры делались на автономном прогоне). Так вот если в 1 и 2 случае все примерно неплохо -- т.е. 1тр + 2тр = сумм загрузка, в случае когда второй тред занимает 50% результат плачевный -- вместо 15+50 = 65 процентов я могу получить и 75 и 85 процентов загрузки. Пытаюсь разобраться , откуда это вылезает ..то ли GUI , то ли драйвера WiFi?? Может что нибудь посоветуете??
  4. Я думаю , что в значительной степени то - о чем мы говорим - это вопрос терминологический. - Если говорить в терминах определений RTOS - то существует точка зрения, готорая гласит - RTOS - система ориентированная на конкретное приложение:=> если для приложения можно выполнить некоторые определнные требования real-time-a , то и система на основе которой построено это приложение является RTOS. Соответственно различные коммерческие RTOS и делаются для того , чтобы улучшить показатели (и расширить сферу применимости данной OS как RTime). - Другой вопрос, что при проектировании достаточно сложных RT приложений значительно легче разбить его на несколько слабосвязанных задач (если это получаеться) и разместить их на отдельных процессорах. Уменьшение сложности проектирования достигаеться из -за того , что вместо одно большого графа - получаются неслько графов меньшего размера , ну и соответственно ...В этом варианте и требования к OS .для реализации этих подзадач - соответственно снижаются(латентность, мертвое время и пр...). - А вот если не получаеться слабосвязанных задач - то это проблема не RTOS а проблема алгоритма и/или архитектуры вычислений. RTOS здесь уже совсем не поможет.. Тут начинаются всякие MIMD &SIMD и прочие Data flow навороты. Вот тогда при построении DFSG задачи на таких распределенных вычислителях вопрос real-time определяется латентностью переключения этого графа из одного сотояния в другое и соответственно латентностью конвейера данных, обрабатывающих то или иное событие от его появления до выработки решения (результата). Т.о. сначала спецификация на RT приложение - потом выбор архитектуры - а затем уже (если можно и нужно ) спецификация на RTOS. Таак мне кааажется.. Ну а всякие FPGA+(NIOS+command extensions)+Linux и дают эту возможность ..реализовывать целевую архитектуру приложения.
  5. А какие собственно претензии к ModelSim? ModelSim действительно потяжелее , чем Aldec (так многие считают) --- Однако к качеству работы у него меньше претезий , чем у Aldec. Если нужно иметь дело с FPGA - проектами - возьми FPGA Adv@tage (От Ment@r Gr). Вполне работоспособная и удобная вещь --- интегрируеться и с Altera и с Xilinx тулзами. Существует набор готовых встроенных скриптов и для функциональной и для PP&R симуляции. Естественно лучше брать последний FPGA Adv@tage (Ну либо собрать самому из HDL Design&r+L&onardo или Pr&cision + ModeISim).
  6. Вопрос о выборе DSP или FPGA состоит в значительной мере в том - насколько хорошо вы представляете структуру цифрового алгоритма демодуляции , который собираетесь реализовывать. - Я имею в виду прежде всего не только собственно формулы - а модель сигнал/шум которую вы будете использовать, динамический диапазон в различных точках алгоритма - соответственно разрядность обработки- соответственно- требуемую производительность на каждый эл-т устройста. Если у вас есть с этим ясность - я бы рекомендовал использовать FPGA (от Altera например - Cyclone c DSP builder). Если вам еще надо разбираться с алгоритмами - то конечно DSP . При неопределенности с динамическим диапазоном и разрядностями в разных элементах алгоритма я бы рекомендовал DSP с плавающей точкой (например TMS 320C30).
  7. >... Эта проблема, на мой взгляд, интересна для обсуждения, если ставить >задачу действительно разработать систему жесткого реального времени (т.е. >предсказуемую).А многопроцессорные системы слишком сложны для моего >мозга. Чтобы сделать "предсказуемую" систему жесткого RT вам в случае однопроцессорной конфигурации необходимо просчитать все возможные комбинации состояний ваших задач с учетом статических и динамических приоритетов, блокировки ресурсов, блокировки каналов обмена, переключения контекста и пр. Другими словами для задач реальной сложности обеспечить жесткий RT на однопроцессорной конфигурации практически невозможно. Я уже не говоря про обработку сбоев, отказов и реализацию м-мов контрольных точек. В соостветствующей литературе ральные конфигурации обычно включали несколько процессорных эл-тов с теми или иными средствами аппаратного мажорирования. Так что придеться изучать многопроцессорные системы.
  8. linux embedded

    Рекомендую эксперименты с embedd.linux проводить на основе альтеровского софтового процессора NIOS+ uCLinux. Там есть и среда проектирования и готовые типовые конфигурации железа и софта -- и /Если очень надо / можно сделать железный Real_Time (с поддержкой необходимых RT функицй в железе) .(На основе расширений системы команд например).
  9. В среде проектирования под NIOS идет версия uCLinux. Довольно удобно сделана работа в Eclipse c генерацией требуемого ядра uCLinux и набора базовых утилит , сборкой образа и флэш-файл системой. Поддержка TCP\IP реализована вполне работоспособной.!
  10. ARM vs XScale cores

    >1. В чем коренные различия между сабжами? Ядро процессора ARM было разработано специалистами фирмы ARM Ltd. Сама фирма ARM не выпускает процессоров - она продает лицензии на ядра. StrongARM был разработан DEC cовместно c ARM Ltd .После продажи Digital Semiconductor в 1998 процессор StrongARM выпускается фирмой Intel. XScale является продолжением ветки StrongARM. Надо сказать , что хотя тактовые частоты XScale выше, чем у StrongARM производительность процессора возросла значительно меньше,чем можно этого было ожидать. Все таки свазываеться разница в классе инженеров DEC и Intel. По существу. XScale содержит большое количество вспомогательной аппаратуры на борту (кроме процессора). Это дополнительные DSP расширения системы команд, системные магистрали, управление режимами памяти и каналами прямого доступа и пр. и пр. Поэтому разбираться с этим процессором лучше всего 1. Скачав документацию по архитектуре XScale с сайтп Intel/ 2. Получив готовую плату с XScale и базовый софт для тестирования и настроект процессора 3.И/или используя систему с ISS XScale - например от фирмы Virtio А уже после всего этого можно в принципе собирать и свою плату с XSale. Удачи!
  11. Цитата(ASN @ Sep 24 2004, 10:12)oleg_rudakov До ASIC дело не дойдет никогда, принципиально не дойдёт. Это одно из основных требований. ПО функционирует на процессорах. Операционки там никакой нет, только свое firmware.......Просто уже достало вручную набивать многометровые листинги тестовых векторов. Я думаю что вполне полезной средой будет Visual Elite... позволяет и Mix Modeling -(SystemC\VHDL\Verilog) & и позволяет писать, использовать в моделировании VirtCPU.
  12. Цитата(Rok @ Jan 12 2005, 17:19)Если вы помните, то поворачивающие множители для БПФ всегда меньше 1. Следовательно после умножения число будет меньше умножаемого. Необходимо сделать только округление после умножения. Т.е. если на входе 16 разрядов, то после первой бабочки (Radix-2) нам достаточно на 2 разряда больше (умножение и затем сложение комплексных чисел). А если идти еще дальше и рассматривать скажем 1024 точки, то можно заметить, что после каждой бабочки увеличивать разрядность необязательно. Насколько я помню = разрядность увеличиваеться в среднем на 1.5 разряда на на одну бабочку --- т.о. на 1024 точки - 2**10 = 1.5 р *10 = 15раз Т.о. чтобы не потерять информации необходимо иметь дело на выходе с разрядностью вх.разр+15 разр. (для 1024 т. фурье)
  13. Согласен про Aldec! На мой взгляд - это один из самых удобных редакторов. А если учесть (как уже говорилось выше ) что для всех разумных FPGA у него есть поддержка интеграции с средствами синтеза -- то вывод очевиден, если позволяет задача, лучше и начинать и вести разработку в среде Aldec. Кроме того в Aldec неплохо сделана поддержка профайлинга и верификации (PSL и пр.).
  14. Цитата(aosp @ Mar 31 2005, 13:22)Так что начинать можно не с нуля. Плохо только то, что они руководящие документы просто так не отдают Да , эти документы были весьма полезны...особенно последние редакции. 2-3 неновых (2001-2002) документа у меня есть , если кому нужно..!
  15. Цитата(radimir @ Mar 1 2005, 10:04)Цитата(custic @ Jan 29 2005, 19:04)Я как раз и понял, что основная масса пользователей работает с ПЛИС. >>производительПЛИС Altera и Xilinx c радостью сделают в кремнии жестко >>при большом заказе. А вот как раз найти тех кто и делает это на заказ в кремнии, поделится опытом, узнать новое и решить возникающие проблемы в проектировании, вот что хотелось. Может кто откликнется... мы для разработки микросхем применяем Tanner LE, Паром и Ot-to а вопрос действительно очень интересный. практически и нескем пообщаться на эту тему, когда надо. занимаемся разработкой аналоговых микрух в кремнии. А есть ли у кого библиотеки для Tanner LE под какие нибудь свежие TSMC технологии ??