oval

Неоднократно имели дело с сериями Actel ProASICPlus и ProASIC3. По существу вопроса могу сказать следующее: Actel в среднем примерно в 2-2.5 раза уступает по производительности Xilinx и Altera. Actel требует гораздо более внимательного подхода в плане задания ограничений (constraints), более внимательного анализа времен. Также приходилось активно пользоваться средствами физического синтеза (PALACE) и планирования кристалла (Actel). Также отмечалась зависимость временных параметров вариантов разводок (прошивок) в пределах 15-20% при большой степени загруженности ресурсов кристалла. Вообщем, не зря у разработчиков ASIC ценится в первую очередь опыт работы с ПЛИС Actel, а уж потом Xilinx, Altera. P.S. В принципе от Actel осталось положительное впечатление.

Очень может быть, я конкретных временных характеристик не смотрел. Таким образом я бы не стал поступать, сделал бы все на одном кристалле, ИМХО.

Не совсем так, зависит от технологии, по которой выполнена FPGA.

Что касается ПЛИС, то если рассматривать Xilinx и Altera, семейства ПЛИС соотносятся примерно следующим образом: Xilinx Virtex 2 = Altera Stratix II Xilinx Spartan 3 = Altera Cyclon III то есть серии Virtex и Cyclone занимают разные ниши. Кроме того, Virtex 2 на данный момент уже достаточно устаревшее семейство, как альтернатива - Virtex 4(5), если все же требуется high-end FPGA. Чтобы принять решение о выборе семейства нужно более детально проанализировать степень сложности необходимой обработки сигнала. К разводке следует конечно подойти внимательно, выполнив требования производителей микросхем, а также обязательно промоделировав PCB на предмет целостности сигналов и т.п.

Применительно к ПЛИС Xilinx смотрите тут.

Зависит от множества факторов (profile, level, требований по "качеству сжатия" и т.п.). По мере работы над задачей, станет понятно, что выбрать. Могу лишь отметить, что реализация на ПЛИС "с нуля" - весьма не тривиальная задача для целого коллектива... Имели дело с аппаратной реализацией H.264. Исходников скорее всего найти увы не получиться... Сомневаюсь... На порядок выше, а то и не на один... если в исходниках... P.S. Если появятся вопросы, спрашивайте, постараюсь ответить...

Либо использовать кристалл (микросхему) большей емкости, либо пытаться создать более оптимальную с точки зрения занимаемых ресурсов архитектуру проекта. По первому варианту кристалл подобрать можно, по второму существует естественно некоторый предел, при котором в меньший объем уже не уложиться.

DSP блоки реализованы в виде отдельных блоков, подобно BRAM.

Не вдаваясь в подробности, насколько я помню, 480МГц Вам не удастся получить по причине выхода этого значения за диапазон возможных выходных частот модуля DCM. Так что, начинайте с этого, проверьте, так ли это. Помоему там максимально возможная выходная чатота порядка 320МГц.

Если речь шла лишь о конкретной привязке к пинам, то тогда понятно.

Это как это так? Вы хотите сказать, что сигналы шины PCI IRDY и TRDY используются только в PCI-66? Или я что-то неправильно понял?

Делайте так, как делали всегда. Не нужно ничего выдумывать, да и выдумать-то ничего не удастся.

Сюда можно добавить еще Synplify DSP.

Other Bitgen Command Line Options - это список дополнительных ключей командной строки при вызове утилиты bitgen. Подробное описание этих ключей можно найти в документации (в части, посвященной утилите bitgen).

Stas, то есть в Вашей реализации контроллера DDR2 SDRAM оптимизация пропускной способности осуществляется только лишь поддержкой параллельного открытия до 4-х банков? А вообще, все зависит от характеристик конкретной системы, в которой используется контроллер: где-то возможность поддержки параллельно открытых банков дает выигрыш по производительности, а где-то и существенный проигрыш. Так что поддержка параллельно открытых нескольких банков - далеко не панацея для увеличения производительности, существует еще масса достаточно нетривиальных способов. Понятие же "латентности" вполне применимо для случая контрллера DDR2 SDRAM. Кстати, если не секрет, какова латентность у Вашего контроллера, допустим по чтению? (т.е. количество тактов от момента принятия контроллером запроса на чтение с внешней стороны, до предоставления первых прочитанных данных внешней же стороне)

За это время реально сделать контроллер DDR ничем не лучше, чем контроллер от Altera. А чтобы сделать "нормальный" контроллер, нужно значительно больше времени. Не все так просто.

Еще, как вариант при наличии дистрибутива, можно доставить утилиту uncompress.

На разницу в 10 слайсов не стоит обращать внимания. Если посмотреть и разобраться в том, что представляет из себя слайс, то можно выяснить, что слайс - это объединенные определенным образом несколько LUT и несколько FF, а также элементы некоторой специальной логики. Так вот, и в первом варианте и во втором количество логики в Вашем проекте абсолютно одинаково, Logic Utilization: Number of Slice Flip Flops: 1,705 out of 15,360 11% Number of 4 input LUTs: 2,541 out of 15,360 16% чего и следовало ожидать. А вот расположение этой логики внутри слайсов, как контейнеров LUT и FF, оказалось разным, Logic Distribution: Number of occupied Slices: 1,999 out of 7,680 26% Number of Slices containing only related logic: 1,999 out of 1,999 100% Number of Slices containing unrelated logic: 0 out of 1,999 0% *See NOTES below for an explanation of the effects of unrelated logic Logic Distribution: Number of occupied Slices: 1,989 out of 7,680 25% Number of Slices containing only related logic: 1,989 out of 1,989 100% Number of Slices containing unrelated logic: 0 out of 1,989 0% *See NOTES below for an explanation of the effects of unrelated logic что вполне закономерно, и ничего странного тут нет. Ключевым словом в отчете здесь является Logic Distribution, ведь может использоваться лишь часть слайса, то есть он может быть задействован не полностью. Таким образом, предполагаю, что ошибка кроется не здесь. Попробуйте описать перестановку байт любым другим эквивалентным способом или способами. Посмотрите на результат. По поводу синтеза в Synplify: попробуйте не включать .ucf файл, подключите его уже после синтеза в Synplify, в проекте ISE. Если все же требуются ограничения на этапе синтеза, то создайте файл ограничений в самом Synplify. И еще, средства синтеза не лишены ошибок, причем влияющих на функциональность схемы (хотя встречается такое крайне редко). Здесь на форуме я писал об ошибке, обнаруженной в Synplify 8.8.0. По сему, используем 8.6.2. Исправлена ли ошибка синтеза в версиях 8.8.0.2 и 8.8.0.4, сказать не могу, не проверял. Естественно, не факт, что эта ошибка проявит себя на Вашем проекте.

Изначально, столкнувшись с проблемой последовательности следования байтов, Вы стали решать ее совершенно правильно. А теперь зачем-то полезли в "дебри". Зачем??? Нужно попытаться разобраться в причинах того, почему проект "разрушился". Возможно, ошибка кроется в средстве синтеза, которым синтезируется проект. Поробуйте использовать другой синтезатор. Убедитесь, что проект собирается правильно, что используются нужные версии файлов и т. п. Вообщем, ищите причину, а не занимайтесь расшифровкой и т. п.

По-простому не получится. Достаточно нетривиальная задача, да и обеспечить требуемую производительность скорее всего принципиально не удасться. P.S. Скорее всего даже связываться не стоит.

1. Смотрите в сторону расширений системы команд типа SSE, MMX. А вообщем, как заметил уважаемый Harbour, burst пересылками управляет мост (чипсет). Со стороны CPU этим можно управлять лишь косвенно: обращаясь по последовательным адресам, используя обращения в кэшируемые области адресов, используя SSE (MMX), конфигурируя области адресов с предвыборкой/отложенной записью и т. п. P.S. Обычно, при проблемах с производительностью программных пересылок, прибегают к использованию контроллера DMA или организуют PCI-master в самом устройстве, который затем автономно занимается пересылкой данных.

Спасибо. Понял. Но, к сожалению, интересуют именно SATA PHY.

Возвращаясь к вопросу: существуют ли на сегодняшний день доставаемые в России SATA приемопередатчики (PHY)? Если ли у кого-нибудь реальный опыт использования таковых? SI больше не производит SATA PHY? P.S. Варианты, встроенные в ПЛИС, не рассматриваю.

Да, насколько мне известно, не предоставляет. Только универсальная модель для верификации, о которой речь шла выше. Остальное только ввиде "списка цепей" (netlist) в базисе целевой технологии.

Ничего удивительного, поскольку данная модель предназначается для моделирования и не является синтезируемой. Приведенная VHDL конструкция не является синтезируемой. При попытке синтеза ISE и ругается.