Мне бы найти ПЛИС со встроенной памятью от 8 Мбайт, но не по заоблачным ценам. Логики нужно немного - пару десятков тысяч LE...
А внешняя память не подходит, т.к. алгоритм предполагает на каждом такте извлечение из памяти до 500 бит.
Писать в нее не нужно (нужно только раз), может быть даже ПЗУ.

В самом крутом Virtex 6: XC6VSX475T "всего" 4Мбайта блочной памяти + 1МБайт распределённой
а у Stratix 4 и того меньше. А цены на такие ПЛИС от 20КилоБаксов.
Так что ищите другие методы.

Кстати вы ничего не сказали про скорость вашей памяти а телепаты уже спят.
А то может вам SPI флешки достаточно будет в soic8, или raid массива из них...

8 мегабайт встроенной памяти это пожалуй и по заоблачным ценам нереально... Осетра надо урезать

А что, неужели так сложно самому пройтись по сайтам всех ТРОИХ основных производителей FPGA и убедиться, что желание найти да еще и отдает некоторой бредовостью (даже если у Вас опечатка и надо читать про 8Мбит)? Или для Вас "заоблачные" цены это все что больше $100k?. А вообще мне кажется, что в консерватории надо что-то менять, постановка задачи вызывает некоторые сомнения в ее продуманности. Впрочем, в задаче не озвучены временные параметры этого самого такта, если это не сотни МГц, то как раз внешняя память Вам легко поможет.

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

Если не сложно, поясните, что означает "схлопнется"? И зачем тут Си?

Ага, только если у товарисча таблица шифрования, то тогда вопрос придется озвучивать в форме "Мне бы найти ПЛИС миллионов на 8-10 LE, но не по заоблачным ценам" )).

Сообщение автора темы вызвало у меня ощущение начала анализа портирования готового решения с процессорной системы. А там только кэша столько может быть

Утрированно, если надо прибавить к входящему массиву данных числа от единицы до миллиона, то можно сделать ПЗУ с числами от одного до миллиона, а можно поставить счетчик. Конечно, не все всегда так просто, но можно сделать простой тест: этот массив, планируемый для размещения в ПЗУ, обработать винраром - результат сильно приближенно но покажет, сколько там действительно уникальной информации. Если массив пожмется в сто раз - это повод поискать алгоритмическую замену, если не пожмется вообще - скорее всего, применение ПЗУ в самом деле оправдано.

Что же касается 500 бит информации за такт - это всего 500 ножек, не фантастика на сегодняшний день. Но надо еще смотреть алгоритм, нужен ли на самом деле произвольный доступ, или можно это ПЗУ покэшировать внутренней памятью.

Внешняя память + ПЛИС
Я другого варианта не вижу

память на 8 мбит я и сам найти могу. Просто, думалось, возможно, существуют какие-то ПЛИС, у которых сделан основной упор на блоки памяти, а я об этих ПЛИС не знаю...
А сама задача?
Есть система линейных уравнений (в GF(2)), которая строится исходя из пришедших данных. Потом система решается. Результат отдается дальше. Если систему строить и решать, уходит около 200 тактов. Если все возможные системы построить и решить заранее, то на хранение результата всех решений и нужно эти самые 8 Мбайт. При таком подходе пришедшие данные становятся адресом в памяти, по которому извлекается готовый ответ. Итого - продуктивность возрастает в 200 раз, если делать за такт. Быстродействие - хотелось бы получить 250 млн. систем в секунду

РАР-ить и схлопывать в логику эту память бессмысленно...

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

Спасибо, за ответы!

Сообщение отредактировал S_Hawk - Sep 30 2009, 18:13

А если DDR - то 250 ножек...
А если QDR...

А к полученному множеству решений нельзя применить прореживание на этапе сохранения в память и последующую интерполяцию на этапе выборки нужного варианта?

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

бОльшие ресурсы можно применять по-разному. Можно параллелить решение... можно создавать отдельные потоки... конвеерезировать... Но в любом случае, большие ресурсы - большие затраты (цена, потребляемая энергия...). А параметр затрат тоже хочется оптимизировать...

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

Сообщение отредактировал S_Hawk - Sep 30 2009, 19:11