Допустим тебе поставили задачу разработать какое-нибудь устройство с определенными интерфейсами для решения конкретной задачи.

Как выбирать ПЛИС? Даже если выбор стоит между семействами одной компании к примеру Xilinx.

ИМХО.

смотрим какие интерфейсы нужны и какие семейства ПЛИС могкт им удовлетворить.
далее два варианта:
1. если есть ограничения по финансам: пишем RTL, затем синтезим и оцениваем потребность в ресурсах. исходя из этого делаем выбор ПЛИС учитывая, что возможно потребуется что-то дорабатывать и чем меньше загруженность ПЛИС тем лучше времянка.

2. если нет ограничения по финансам, но есть ограничения по времени: берем бааааааальшую ПЛИСину, чтобы влезло все, что нужно, сообщаем об этом разработчику платы. Параллельно с разработкой платы, пишем RTL и по приходу платы засовываем его в ПЛИС.


примерно так.

Если ты решишь использовать готовые решения, то можно также прикинуть по выпущенным готовым IP cores на выбранные интерфейсы, в какой объем ресурсов всё это выльется. Как правило производители корок, в рекламных брошюрах указывают подобную информацию.

Главное и единственно важное: примерно прикинуть требуемый объем ресурсов. Если проект, не сильно маленький, то триггеры, наверняка можно не считать. Главное проконтролируйте число умножителей да объем имеющейся памяти. Прикиньте сколько Вам надо, умножьте на "коэффициент запаса"(2, ну или любое другое число на ваш вкус, зависит от того, насколько вы доверяете своим же расчетам=) ). А еще можно использовать pin2pin совместимые ПЛИС, если Ваш коэффициент запаса был великоват - в следующей партии поставите ПЛИС поменьше;-)

ИМХО, все зависит от конкретного проекта - в некоторых проектах умножители нафиг не нужны (маршрутизаторы скажем) и основное требование - наличие как можно большего кол-ва памяти, в ЦОС наоборот. Иногда требуется наличие высокоскоростных каналов передачи данных.
Соответственно, требуется реализовать кусок проекта и просчитать приблизительный объем всех требуемых элементов:
объем регистров, памяти, умножителей, наличие каналов lvds и т.д. и т.п. для конкретных ПЛИС. При этом внимательно смотрите на семейства и speed grade. Современные ПЛИС могут работать и на 600МГц, старые не вытянут и 250... Ну и, соответственно, цена будет зависеть не столько от объема, сколько от самомго семейства и "начинки".

Сообщение отредактировал bogaev_roman - Apr 28 2011, 14:25

ну это уж мне казалось как-то совсем само-собой разумеющимся, что человек сможет подобрать ПЛИС с подходящими интерфейсами, числом входов, тактовой частотой... после этого у него остается 10 ПЛИСин, и какую из них ему взять... по-моему, вопрос о той части процесса выбора, которая завязана на разработку под FPGA.

Можно поступать так...
1) Определяемся с семейством (Spartan-3, S6, V-4, V-6, т.п. ) на основе требований (наличие интерфейсов, умножителей, hard IP, быстродействию)
2) Когда определились с семейством - выбираете корпус, которого хватает по контактам и который покрывает максимум разновидностей по емкости внутри семейства...
Например, для S6 - FGG484.

В этом случае Вы можете сравнительно безболезненно перейти с "мелкого" на более "крупный" чип.
Как-то так...

Есть 2 возможных траблы:
1) Требуемый алгоритм так, как он видится, может не влезть и в самую большую плисину (по объему или быстродействию).
2) Самая большая плисина, которая окажется в самом большом корпусе, не пролезет по габаритам или потреблению.

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

я подхожу к вопросу так:

если это несерийное изделие для отработки/демонстрации алгоритма - берем Альтеру (удобство средств разработки)

если это серия (то есть требуется выиграть по стоимости, отсутствию глюков в ПЛИС и т.п.) - берем Ксайлинс

если есть экзотические требования - очень внимательно смотрим на Латтис или Актел

------------------------

алгоритм в каком-то виде должен быть известен - в худшем случае известно, что такой/подобный алгоритм влазит в некую ПЛИС и тогда умножая ее ресурсы на коэффициент (любое чисто больше 1.0) выбираем ПЛИС

в лучшем случае есть RTL код (желательно, проверенный симуляцией, иначе синтез может выбросить большую часть) - синтезируем его в каком-либо универсальном синтезаторе Synplify / Precision для разных ПЛИС - все становится понятно.
но нужно учитывать, что результаты такого синтеза приблизительные и по скорости/ресурсам нужно иметь запас (тут можно коэффициент сказать точнее - что-то типа 1.5)

Ведь вполне возможны ситуации, что проект занимает менее половины кристалла, но не проходит по частоте. Как предусмотреть такие проблемы на этапе выбора ПЛИС? И как бороться с этим?

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

Почему вы так уверены что логику всегда можно распараллелить?

Пример: прием из Ethernet пакета, фильтрация по MAC и по IP адресу и передача в другой интерфейс, к примеру Rocket'ы. Как этот проект можно распараллелить?

подсказывает мой двадцатилетний опыт работы на компьютерах с числом ядер и процессоров больше тысячи...

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

Ровно в 2 раза больше логики, но зато логика может работать в два раза медленнее.

Пока лазял на форуме кое-что нашел по этой теме, цитирую:

Ссылка