RVlad

Ну раз стоит 67 TMS - а это процессор с пл.точкой - то вычислительная мощность алгоритмов весьма значительна --- видимо его и надо использовать . Если вы собираетесь делать что то качественно близкое к данному решению, то реализация на FPGA будет для вас достаточно трудоемкой. (по сравнению с С-Asm программированием VLIW 67 TMSa). Хотя с другой стороны реализовать эффективные алгоритмы ЦОС на VLIW процессоре без использования стандартной библиотеки --- это то же ничего!!

Согласен с Vetal : сделайте , что рекомендуют...ну и пришлите свой тестик - посмотрим ...

Мнея эта тема интересует в том числе и прагматической точки зрения. В данный момент я работаю с разработкой приложения на WinCE. Говорить про недостатки я не буду ... не продуктивно. Но проблема состоит в следующем.Есть два треда - один занимает примерно 10-15% временной диаграммы процесора. Другой, для которого необходимо выдерживать жесткие врменные соотношения . может занимать либо 10, либо 20 либо 50% временной диаграммы(замеры делались на автономном прогоне). Так вот если в 1 и 2 случае все примерно неплохо -- т.е. 1тр + 2тр = сумм загрузка, в случае когда второй тред занимает 50% результат плачевный -- вместо 15+50 = 65 процентов я могу получить и 75 и 85 процентов загрузки. Пытаюсь разобраться , откуда это вылезает ..то ли GUI , то ли драйвера WiFi?? Может что нибудь посоветуете??

Я думаю , что в значительной степени то - о чем мы говорим - это вопрос терминологический. - Если говорить в терминах определений 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 и дают эту возможность ..реализовывать целевую архитектуру приложения. :)

А какие собственно претензии к 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).

Вопрос о выборе DSP или FPGA состоит в значительной мере в том - насколько хорошо вы представляете структуру цифрового алгоритма демодуляции , который собираетесь реализовывать. - Я имею в виду прежде всего не только собственно формулы - а модель сигнал/шум которую вы будете использовать, динамический диапазон в различных точках алгоритма - соответственно разрядность обработки- соответственно- требуемую производительность на каждый эл-т устройста. Если у вас есть с этим ясность - я бы рекомендовал использовать FPGA (от Altera например - Cyclone c DSP builder). Если вам еще надо разбираться с алгоритмами - то конечно DSP . При неопределенности с динамическим диапазоном и разрядностями в разных элементах алгоритма я бы рекомендовал DSP с плавающей точкой (например TMS 320C30).

>... Эта проблема, на мой взгляд, интересна для обсуждения, если ставить >задачу действительно разработать систему жесткого реального времени (т.е. >предсказуемую).А многопроцессорные системы слишком сложны для моего >мозга. Чтобы сделать "предсказуемую" систему жесткого RT вам в случае однопроцессорной конфигурации необходимо просчитать все возможные комбинации состояний ваших задач с учетом статических и динамических приоритетов, блокировки ресурсов, блокировки каналов обмена, переключения контекста и пр. Другими словами для задач реальной сложности обеспечить жесткий RT на однопроцессорной конфигурации практически невозможно. Я уже не говоря про обработку сбоев, отказов и реализацию м-мов контрольных точек. В соостветствующей литературе ральные конфигурации обычно включали несколько процессорных эл-тов с теми или иными средствами аппаратного мажорирования. Так что придеться изучать многопроцессорные системы.

Рекомендую эксперименты с embedd.linux проводить на основе альтеровского софтового процессора NIOS+ uCLinux. Там есть и среда проектирования и готовые типовые конфигурации железа и софта -- и /Если очень надо / можно сделать железный Real_Time (с поддержкой необходимых RT функицй в железе) .(На основе расширений системы команд например).

В среде проектирования под NIOS идет версия uCLinux. Довольно удобно сделана работа в Eclipse c генерацией требуемого ядра uCLinux и набора базовых утилит , сборкой образа и флэш-файл системой. Поддержка TCP\IP реализована вполне работоспособной.!

>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. Удачи!

Я думаю что вполне полезной средой будет Visual Elite... позволяет и Mix Modeling -(SystemC\VHDL\Verilog) & и позволяет писать, использовать в моделировании VirtCPU.

Насколько я помню = разрядность увеличиваеться в среднем на 1.5 разряда на на одну бабочку --- т.о. на 1024 точки - 2**10 = 1.5 р *10 = 15раз Т.о. чтобы не потерять информации необходимо иметь дело на выходе с разрядностью вх.разр+15 разр. (для 1024 т. фурье)

Согласен про Aldec! На мой взгляд - это один из самых удобных редакторов. А если учесть (как уже говорилось выше ) что для всех разумных FPGA у него есть поддержка интеграции с средствами синтеза -- то вывод очевиден, если позволяет задача, лучше и начинать и вести разработку в среде Aldec. Кроме того в Aldec неплохо сделана поддержка профайлинга и верификации (PSL и пр.).

Да , эти документы были весьма полезны...особенно последние редакции. 2-3 неновых (2001-2002) документа у меня есть , если кому нужно..!

мы для разработки микросхем применяем Tanner LE, Паром и Ot-to а вопрос действительно очень интересный. практически и нескем пообщаться на эту тему, когда надо. занимаемся разработкой аналоговых микрух в кремнии. <{POST_SNAPBACK}> А есть ли у кого библиотеки для Tanner LE под какие нибудь свежие TSMC технологии ??