oval

ндя задача не тривиальная, есть след.вопросы : 1. Какое разрешение вы будете жать ? (CIF, D1, HD) ?? 2. Какой фрейм рейт ? 3. Видео интерлейснутое или нет ? 4. Какой profile/level вы планируете использовать и реализовывать ? 5. Разжимать вы будете свой поток или любой ? 6. Будете ли использовать Rate Control ? 7. На какую цену решения вы закладываетесь ? Добавлю еще один вопросик: 8. Усилия скольких человек планируете задействовать?

Имели дело с семейством Actel ProASICPlus, конкретно с кристаллами APA450, APA300, APA150, APA075. Частоты до 66МГц. Функционально в основном системные контроллеры (связки различных интерфейсов, в т. ч. PCI, SDRAM). Математики (функций DSP и т. п.) делать на Actel не приходилось. Что касается потребления, ничего криминального не замечено, по крайней мере можно сказать, что не больше, чем соответствующие по объему кристаллы Altera или Xilinx. По частотным характеристикам абсолютно точно уступают FPGA Altera или Xilinx. Для логики среднего уровня сложности предел наступает уже на частотах около 55-60МГц и то, приходится выводить, особенно тщательно приходится выводить времена по внешним интерфейсам. Вывод: для Actel'я нужно очень внимательно следить за выполнением необходимых временных параметров, по ВСЕМ, даже очень медленным внешним интерфейсам, аккуратно задавать временные ограничения, как внешние, так и внутренние. На подходе к вышеуказанным частотам, с очень большой вероятностью придется еще заниматься планированием кристалла (floorplanning). Что касается нового семейства ProASIC3, то оно примерно на 20-30% производительнее (быстрее) ProASICPlus. В целом не плохая линейка семейств со своими преимуществами и недостатками, которая приучит вас проектировать правильно, научит работать с ограничениями (constraints) практически всех типов, подготовит к переходу на ASIC :)

Если пересчитать имено максимальную задержку сигнала для худшего разряда входного сигнала то получилось 10,85 нс - 92 МГц. Такие цифры для Акселератора, будут точнее?! В данном случае для семейства Actel Axcelerator вполне адекватная цифра.

Подсказать к сожалению нечего. Если речь идет о ПЛИС, то 150МГц вряд-ли достижимо. Встречалась подобная задача, частота получалась значительно ниже, вычисляли результат за несколько тактов, ничего более толкового в голову не пришло. Как вариант, можно попытаться заранее подготавливать данные для данного вычисления, сортировать их. З.Ы. Если удасться найти по данному вопросу что-нибудь толковое, дайте знать, пожалуйста. Тоже интересно.

По стабильности ядра Quest'ы на данный момент ничего криминального не замечено. Единственная неприятность это то, что из-за какой-то конструкции VHDL (из-за какой конкретно не выяснено) валится загрузка проекта при использовании code coverage, при этом компиляция проходит нормально. Без использования code coverage все также проходит без ошибок (используется Q6.1c + VHDL + Verilog + SC).

Запускать не пробовал, но могу сказать, что ругаться точно будет :) В указанной строчке последний символ "\" надо удалить ;)

А также, если ресурсов "основных спецов" не хватает для реализации поставленной задачи, и требуется посторонняя помощь. ;) Разумеется, если есть интерес завершить проект в срок или уменьшить time to market :) При этом понятие "зарплата" по отношению к людям, относящимся к "посторонней помощи" вообще не распространяется, а фактическая стоимость работ на стороне может быть вполне соизмерима с зарплатой основных спецов ;) З.Ы. Предложение со своей стороны я также изложил в привате :)

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

Она на местном фтп существует в соответствующем разделе, но я могу, если нужно, кинуть Вам на почту.

ИМХО второй сверху пункт (от Synopsys) можно либо вообще исключить, либо перенести в конец списка. Синтезируемое подмножество SystemC на данный момент мало кем из производителей серьезно поддерживается. Еще продолжительное время на RTL уровне будут использоваться HDL языки. Ввиду этого гораздо более полезно изучить более высокий уровень абстракции описания моделей, то есть поведеньческое описание. Зная и понимая RTL уровень на HDL, перейти на SystemC RTL нет проблем, одно и то же просто описывается другими буквами. :) К списку литературы можно еще добавить книгу J. Bhasker "A SystemC Primer" от Cadence. Многим из моих коллег эта книга понравилась. ;)

Возможно, заявленная емкость 400K, - это эквивалентная емкость без учета блочной памяти. В Вашем случае основная часть цифры 650K формируется за счет блоков памяти Block RAM.

Вот несколько преимуществ, которые можно отметить: отсутствие внешней загрузочной PROM, готовность к работе по включению питания, а также отсутствие значительного броска по току в момент включения питания. Последнее зачастую оказывается критичным.

Часто приходится работать с семейством Actel ProASICPlus. Так уж случается, что в основном всегда под завязку. Тупиковых ситуаций не было, но бывало, что Designer загибался на этапе разводки соединений (route), благо с выдачей сообщения о невозможности развести. Проблема решалась после использования планирования кристалла (ручное задание областей расположения отдельных блоков проекта). Однако, если требуемые временные характеристики проекта близки к технологическому пределу выбранного семейства, то при большой степени заполненности кристалла можно столкнуться с практически неразрешимыми временными нарушениями. Вообщем, лучше все же иметь запас.

Думаю, вряд-ли я ошибаюсь. :) Из чего состоят двунаправленные буфера, я знаю и понимаю. Надо управлять, не вопрос, будем управлять, как я описал выше. :) Да, совершенно верно. Но этим процессом зачастую можно управлять с помощью специальных атрибутов синтеза. Да, не во всех семействах FPGA Xilinx есть возможность организовать внутренние шины с тримя состояниями. Так вот, логическое НОРМАЛЬНОЕ поведение структуры IOB и внешнего проводника можно повторить, используя внутренние буфера с тримя состояниями. Естественно, электрические проблемы (платы, соединения и т. п.) повторить таким образом не удасться. Например, можно с эмулировать логическое соединение PCI мастера(ов) и PCI слэйва(ов) внутри FPGA, то есть создать виртуальную PCI шину. Подчеркиваю, что речь идет об эмуляции логики работы шины PCI. P.S. Как я понял автора темы, у него стояла некоторая подобная задача. Возможно, для отладки.

Аналогично, на VirtexII, тоже без проблем ;) Без управляющего сигнала, задающего направление передачи? Задача ведь стоит "полностью имитировать внешний проводник". По-моему, часть авторов прочитала цитату, которая в кавычках, а часть авторов ее пропустила. Или у виртекса действительно такие чудесные буфера на пинах? Я уже чего-то совсем ничего не понимаю :( Берете два блока, каждый из которых имеет по порту типа inout, соединяете эти порты сигналом, получаете двунаправленную шину. Все управление третьим состоянием заключено внутри блоков. Другой вариант, если буферы двунаправленных сигналов внешние по отношению к блокам (или единому блоку): создаем отдельную архитектуру верхнего уровня, в ней сохраняем все технологические буферы, кроме тех двунаправленных буферов, которые относятся к эмулируемому проводнику. Вместо них HDL текстом описываем двунаправленную локальную шину, то есть организуем два буфера с тремя состояниями: один для сигналов (AIn, AOut, AEn), второй для сигналов (BIn, BOut, BEn). Вообщем, логически повторить поведение проводника, проблемы не вижу :)

Аналогично, на VirtexII, тоже без проблем ;)

В принципе возможно, если в Вашем семействе Spartan'а имеются внутренние линии с тремя состояниями. Возможно придется организовать еще один более высокий уровень иерархии проекта, чтобы там и организовать эту самую двунаправленную связь. Также некоторые средства синтеза по умолчанию преобразуют локальные (внутренние) двунаправленные шины в обычные однонаправленные. Чтобы в действительности получить внутреннюю двунаправленную шину (сигнал), возможно потребуется задать некоторые специфические атрибуты синтезатора. Кроме того, обычно внутренние шины кристалла "подтянуты" к питанию или земле.

Бывало, но очень редко. ;)

У Вас порт d : std_logic_vector функция conv_integer(d) конвертирует std_logic_vector в integer +18,8(integer) (операции можна проводить только с одинаковыми типами данных) а функция conv_std_logic_vector конвертирует обратно integer в std_logic_vector Например если б в место 18,8 былоб "1111" тогда q<= d + "1111"; а при 18,8 надо конвертировать типы Не, не совсем так :) Код не "красив"! Это не дробное число 18,8. Просто пробелы надо расставлять после запятых! Сигналу (выходу) q присваивается результат функции conv_std_logic_vector(conv_integer(d)+18, 8). Функция имеет два параметра, что преобразовывать (в данном вызове conv_integer(d)+18) и во сколько разрядов (в данном случае 8). Если я правильно понял, то в заблуждение вводило отсутствие пробела после запятой в строке 18,8 В смысл алгоритма я честно говоря не вдумывался :)

Думаю, ошибаетесь. Annex E Features under consideration for removal Ports of mode linkage (see 1.1.1.2 and 4.3.2) Не вижу никаких недостатков у buffer кроме возможного геморроя со старыим кривыми синтезаторами. Использовал в ISE и Modelsim для внутренних интерфейсов модулей - работает нормально. И тем не менее во всякого рода документации часто встречаются фразы НЕ в пользу использования типа buffer. Так уж сложилось. :)

Практически это я и имел ввиду, только разве что в отношение буферов BUFIO :)

По первой части вопроса. Очень возможно, что один или несколько сигналов (или отдельных их составляющих битов): CE, SWE, EA[11:0], BE[3:0], ED[31:0] (xapp753, p.38, Fg.3-6) связаны с пинами корпуса, входные триггера которых (этих пинов) оказываются недоступны для специальной выделенной клоковой цепи, доступ к которой получен через BUFIO связанный с пином B17. Как вариант, можно попробовать отцепить все сигналы кроме EclkOutx от пинов и попробовать развести. З.Ы. Чисто теоритическое предположение. Может я чего и неправильно понимаю. ;)

Почему, функция работает, она возвращает 0 (то, что и выводит в сообщении). Просто в качестве аргумента она получает вектор, содержащий в одном или нескольких битах состояния U|X|W|Z, что лишает ее возможности конвертировать этот вектор в адекватное целое число, она выводит предупреждение и возвращает 0. Причины могут быть разными, в том числе и отсутствие начального значения сигнала-аргумента этой функции. Так что Вы правы. Неразрешаемый тип сигналов (unresolved) иногда вполне оправдано использовать с целью предупреждения ошибки назначения более одного драйвера (источника) сигнала. В этом случае данная ошибка обнаруживается уже на этапе компиляции. Уловить преимущество использования std_logic по отношению к std_ulogic мне так и не удалось. Везде, где сигнал имеет единственный драйвер (источник), я использую тип std_ulogic. А вот, что касается векторов, то использование std_ulogic_vector ведет к некоторым проблемам при преобразовании типов, равно как и для std_ulogic_vector нет некоторых полезных функций. Поэтому всегда использую std_logic_vector.

Ну, появляется, и что? Вопрос-то в чем состоит?

Естественно будет! По чисто физическим причинам. Чем выше температура, тем больше задержка и наоборот. ;)