Использование встроенной памяти ПЛИС. Опции

[m0use]

Доброго всем времени суток!

Вопрос такой. Пишу код, который работает с матрицами, в том числе обрабатывает их в циклах. Получилось так, что текущая версия кода при размере матрицы, далёком от практических потребностей код требует значительных ресурсов (насколько я понял из отчёта, близких к предельным для этой ПЛИСы):

Logic Utilization:
Number of Slice Flip Flops: 1,231 out of 9,312 13%
Number of 4 input LUTs: 8,329 out of 9,312 89%
Logic Distribution:
Number of occupied Slices: 4,654 out of 4,656 99%
Total Number of 4 input LUTs: 8,741 out of 9,312 93%
Number of bonded IOBs: 19 out of 232 8%
Number of BUFGMUXs: 1 out of 24 4%
Number of MULT18X18SIOs: 20 out of 20 100%

Скажите, ребят, если я буду использовать память (пока я себе это представляю как модуль памяти из IP Core Generator), то снизит ли это количество используемых LUT? То есть если данные будут хранится в памяти, а по мере необходимости вычислений они оттуда будут выдёргиваться.

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

Заранее спасибо, коллеги!

[m0use]

Несколько раз перечитывал, что вы мне ответили, чтобы понять .

выполняете кучу преобразований за один такт очень крутой комбинаторной функцией может серьёзно снижать общ. произв. системы

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

лучше выложите исходник - быстрее получите качественную консульт.

Я ещё попробую использовать память, если не поможет, то обращусь за такой помощью. Просто представляю, какой это труд в чужом коде разбираться, да ещё ошибки искать.

узкий поток данных на вход-выход

Тоже прекрасно понимаю, что это узкое место в системе, но не знаю, что с этим делать. Смысл проекта в том, что с компьютера по какому-нибудь интерфейсу (пока это RS232, потом планируется Ethernet) передаётся изображение (матрица порядка 640x480). Это изображение обрабатывается на ПЛИСе и выдаёт результат. Да, передача матрицы - процесс, который ощутим в общем времени работы, но куда от него деться?

Более подробно читаем тут...

Спасибо.

И. Ещё раз ВСЕМ спасибо.

[CaPpuCcino]

Выходит, Вы говорите, что на уровне кода необходимо дробить операции?

алгоритм в структурном исполнение состоит из (в общем случае) их путей прохождения данных. пути состоят из промежуточных хранилищ(например регистров) и комбинаторной блоков комбинаторной логики, которые осуществляют эффективное преобразование потока данных (еслественно, что пути данных не обязательно линейны и однонаправленны, они могут иметь обратные связи, пересекаться и расходиться при помощи коммутирующих элементов, хотя коммутирующие элементы тоже суть комбинаторика/фактически мультиплексоры - это пересечение потока данных и условного потока управления/)
при установившемся и постоянном потоке данных в синхронном цифровом дизайне производительность системы тем выше, чем выше тактовая частота тактируемых в пути данных регистров (зы: для чисто управляющих систем это немножко не так, точнее тоже так, но там приоритеты другие - важна скорость отклика) частота тактирования может быть тем выше, чем меньше время распространения сигнала от одного регистра до соседнего, следовательно макс. частота опред. наибольшей задержкой распр. данных между регистрами. т.о. нужно стремится, чтобы кмбинаторная логика была равномерно размазана между слоями регистров.
более того, если комбинаторная функция зависит не только от предыдущего состояния системы(просто пример - сравнение с накопленной за несколько шагов суммой), но и от более ранней истории состояний, сложность комбинаторики возрастает нелинейно (зависимость от кол-ва операндов и кол-ва состояний). поэтому разумно произвести эквивалентное преобразование, которое разобьёт вычисление на несколько шагов с сохранением промежуточных результатов вычисления (так и появляются автоматы состояний - хотя почти любой считающий автомат можно разложить на параллельную комбинаторику, сложность этой комбинаторики будет настолько сложной, что электроны умрут от старости, пока будут бежать от одной ступени конвейера до другой, поэтому целесообразней создать автомат, который бу работать последовательно, но с малым вр. исп. операции).
ну вот примерно так. надеюсь не слишком сложно объяснил, чтобы что-то полезное из этого сообщ. для себя извлечь
ЗЫ: картинку des333 подобрал на редкость неудачную - смотреть и вникать на её нижнюю часть строго воспрещается, т.к. она описывает технику вычисления волной (где тактирующий сигнал распространяется вместе с потоком данных)

если что-то не понятно из объяснения - спрашивайте, попробую переформулировать в более понятной манере
удач

Я ещё попробую использовать память, если не поможет, то обращусь за такой помощью. Просто представляю, какой это труд в чужом коде разбираться, да ещё ошибки искать.

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

[des333]

ЗЫ: картинку des333 подобрал на редкость неудачную - смотреть и вникать на её нижнюю часть строго воспрещается, т.к. она описывает технику вычисления волной (где тактирующий сигнал распространяется вместе с потоком данных)

Согласен. Просто рисовать было неохота, а в гугле другие картинки  на скорую руку не нашлись.
Подумал, что для новичок вникать в асинхронную суть второго варианта не станет, и что сойдет картинка. Но, наверное, рисковать не стоит, уберу ка я лучше картинку. 

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