Olxx

На первый взгляд - это логичное обьяснение. Но что делать если есть какая-нибудь DSPшная корка типа reed-slomon или viterbi с кучей конфигурационных параметров многие из которых могут существенно повлиять на архитектуру дизайна корки в целом. В этом случае, исходя из Вашей логики, необходимо держать огромное количество нетлистов для всех возможных комбинаций парамтеров корки, но этого явно не наблюдаеться. Еще одно возможное обьяснение - у ксилинкса есть некий "параметризуемый" нетлист но это тоже крайне маловероятно из-за запредельной сложности в реализации подобного подхода. Т.е. скорее всего исходники где-то должны быть, скорее всего спрятаные внутри *.class, т.е. лежат внутри java класов. Да и названия этих классов очень подходят под эту теорию. Как Вы думаете - насколько это вероятно?

Задался вопросом - есть Coregen, который может генерировать корки в виде нетлиста. Эти нетлисты могут генерится для разных типов плис с разными вариантами настроек и конфигураций. По идее - единственный вариант для генерации таких корок - это хранить исходники (пусть даже в зашифрованом виде) и при необходимости синтезировать нужный нетлист. Но в большинстве корок Ксилинкса (даже платных) исходники отсутствуют, но нетлист как-то генерится. Кто знает - как они умудряються нетлист синтезировать???

Есть такой продукт Sigrity Speed2000. По идее это то, что Вам надо. По крайней мере он позволяет моделировать процессы на power plane. Скажу честно - сам я его не пробовал. Sigirty утверждает, что в пакете есть Maxwell EM fields 3D solver. Если это полноценный 3D солвер, то он должен уметь расчитывать распростанение EM сигналов в трехмерных геометрических обьектах и по идее разьем можно смоделировать (если есть его точная трехмерная модель).

Сомневаюсь, что существует готовый калькулятор для подобных расчетов. Thermal pad и antipad надо расчитывать исходя из здравого смысла (обычно пакеты разводки уже имеют некоторое понятие о том какие размеры должны быть соблюдены) и рекомендаций производителя ПП. Как-то на форуме orcad велось обсуждение того какие требования к antipad есть у Layout. Вот даже ссылку нашел: http://orcad.com/forums/ShowPost.aspx?PostID=4955 Там также есть ссылка на некий нормативный документ IPC-2221. К сожалению на сайте ipc.org этот документ дают только за деньги. Посмотреть можно только содержание: http://www.ipc.org/TOC/IPC-2221A.pdf Наверно если очень захотеть его можна найти и в "свободном" доступе.

Если требуется выравнивание груповой задержки то можно применить All-pass IIR filter with arbitrary group delay. Посмотрите в Матлабе, там это все хорошо описано и промоделировать можно.

Не совсем понятно, что имееться в виду под "скоростью внутри FPGA". Если имееться в виду максимальная скорость работы отдельных компонентов FPGA типа умножителей, блочной памяти то в Virtex-4 можно получить нечто близкое к 500MHz. Насчет 1ГГц очень сомневаюсь, что такое вообще имееться на сегодняшний день за разумные деньги. Если же речь идет о всей системе в целом то тут все зависит от разработчика и от того, что разрабатываеться. При этом остаеться максимальный теоретический лимит в 500MHz для дизайнов с минимальной "глубиной" комбинаторной логики и на практике для полностью синхронных дизайнов скорее всего 500MHz Вы не получите.

Давно не работал с оркадом, но если память не изменяет - такая ошибка может вылазить если у Вас недостаточно большой размер pad на планарном слое. Это лечиться увеличением размера pad в "Padstack" для plane layers. Попробуйте сделать все размеры pad на plane layers на 20-30 mils больше чем размер pad на сигнальных слоях. Если проблема исчезнет - просто подгоните размеры pads под минимальное значение которое все-еще воспринимаеться оркадом без ошибки.

По какой-то причине IAR считает, что условие (bytes[0] == 0xFF) &&(bytes[1] == 0x80) невыполнимо (это может происходить по разным причинам, надо больше исходной информации). Самый простой совет - попробуйте обьявит массив bytes как "volatile". В этом случае компилятор перестанет оптимизировать все что связано с "bytes".

Если не жалко отдать 5-10% циклов на overhead планировщика (зависит от количества задач и частоты переключенич контекстов) то однозначно RTOS. Даже для AVR. В результате будет проще спланировать приоритеты, порядок доступа к ресурсам и т.д. Очень рекомендую uC/OS (www.micrium.com). Порт для AVR у них есть. А если по сути вопроса - в обработчиках прерываний лучше делать как можно меньше. По быстрому обработать железо и выставить флаг. Основной цикл проверит флаг (и его приоритет) и передаст управление функции. Если все делать в ISR то real-time реакция системы может стать плохопредсказуемой.

Фильтр Хогенауера (cascaded integrator comb) аппаратно реализуеться очень просто учитывая тот факт, что они не требуют умножителей и используют только операции суммирования и вычитания. В основном используються в multirate системах для выполнения операций decimate и interpolate (архитектура фильтра будет зависеть от выполняемой функции). К примеру CIC интегратор состоит из N каскадов однополюсных дифференциаторов после которых происходит требуемое увеличение sample rate (новые samples просто заполняються нулями) после чего идет N каскадов однополюсных интеграторов. Особое внимание в аппаратной реализации надо уделить увеличению разрядности на выходе фильтра (возможно придеться реализовывать масштабирование). Предполагаю, что аппаратная реализация требуеться на FPGA. Xilinx и Altera имеют готовые реализации CIC фильтров (хотя сделать самому тоже несложно). При ксайликсовую реализацию можете почитать тут: http://www.xilinx.com/ipcenter/catalog/logicore/docs/cic.pdf

Разрабатываю проект с одной FPGA на центральной плате и еще парой FPGA на дочерних платах. На центральной плате есть общий клок - синусоида 10MHz, которая по идее пойдет на центральную плисину. Хотелось бы этот синус подать и на дочерние платы в качестве клока. Посему есть два вопроса: 1. Как Xilinx Spartan относиться к чистому синусу в качестве клока? 2. Можно ли клок развести по разным платам с плисами без применения каких либа доп. компонентов (буферов и т.д.)? Просто физически разделить проводник на плате на несколько веток и развести эти ветки к разным плисам.

Если вы о полноценном стеке протоколов GSM/GPRS от ETSI, то о VisualState рекомендую забыть сразу. Была практика использовать значительно более продвинутые продукты типа Telelogic Tau в подобных проектах, но даже очень дорогие коммерческие UMS/SDL системы в конечном результате добавляют проблем больше чем решают (сразу хочу добавить, что это исключительно мое мнение - наверняка найдуться те кто с этим не согласиться). Лучше чем С + хорошая RTOS + правильно выбранное железо Вам не найти.

Все зависит от того о каких материалах и о каких параметрах речь. Основных электрических параметров два - диелектрическая постоянная и тангенс угла диелектрических потерь. Данные параметры желательно иметь в виде графика завасимости от частот используемых на плате. Есть еще сопротивление поверхности, удельное обьемное сопротивление но они редко используються в расчетах. Если необходимо делать многослойку с различными материалами в разных слоях то довольно важно знать х-ки расширения диелектрика в зависимости от температуры (это из недиелектрических параметров).

Это проблема не только MWO но и любой другой системы моделирования. На таких частотах очень важено знать точные характеристики деэлектрика печатной платы (диелектическая проницаемость, тангенс угла потерь). Лучше не пользоваться стандартным FR4 а использовать специализированые СВЧ материалы. Хотя если точно вымерять характеристики FR4 то можно использовать и его (если размеры СВЧ платы небольшие). По крайней мере положительный опыт работы с FR4 на частотах до 2ГГц есть. Также важно какими моделями описаны компоненты фильтра. Стандартное описание емкостей и индуктивностей на СВЧ уже может не работать - в игру вступают паразитные сопротивления, емкости контактных площадок и т.д.

Нет никаких побочных эффектов. Если с выхода PLL идет нормальный сигнал без сильного фазового шума с нормальным duty cycle то проблем быть не должно. Я так делел один раз со Xilinx Spartan 2 - все нормально работает.