To RAM or no to RAM - вот в чём вопрос! Опции

[m0use]

Привет, ребят.

Стою перед дилемой просто. Нужна обработка матриц - перемножение, сложение элементов. У меня такие мысли.

С первого взгляда, достаточно удобно описывать матрицу как RAM, особенно когда нужно перемножать элементы (на аппаратных умножителях). Но в таком случае за один CLK можно работать только с одним элементом массива (считывать из памяти). Это большое но, потому что хочется максимально распараллелить обработку матрицы. То есть хочется одновременного доступа ко всем элементам - но (и опять же но) комбинаторной логике много, наверно, получается - скорость падает.

Есть ли компромисс? Использовать небольшие блоки памяти? Подскажите, уважаемые коллеги! И вообще верны ли мои рассуждения? .

[Maverick]

Привет, ребят.

Стою перед дилемой просто. Нужна обработка матриц - перемножение, сложение элементов. У меня такие мысли.

С первого взгляда, достаточно удобно описывать матрицу как RAM, особенно когда нужно перемножать элементы (на аппаратных умножителях). Но в таком случае за один CLK можно работать только с одним элементом массива (считывать из памяти). Это большое но, потому что хочется максимально распараллелить обработку матрицы. То есть хочется одновременного доступа ко всем элементам - но (и опять же но) комбинаторной логике много, наверно, получается - скорость падает.

Есть ли компромисс? Использовать небольшие блоки памяти? Подскажите, уважаемые коллеги! И вообще верны ли мои рассуждения? .

какого размера матрицы? и элементы в матрице (их разрядность)?

[rv3dll(lex)]

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

[D13]

ващето память имеет скорость больше чем остальная плис.

в смысле?

[m0use]

какого размера матрицы? и элементы в матрице (их разрядность)?

Неплохо было бы, чтобы матрица была размером не меньше, чем 64x48. Вообще надо обрабатывать изображение 640x480, но думаю, такой объём не эффективно обрабатывать - буду разбивать на блоки порядка 64x48. Элемент матрицы - байт.

rv3dll(lex), а могли бы Вы пояснить. Для того, чтобы такое провернуть, нужен отдельный CLK или можно преобразовать общий CLK и получить большую частоту?

[Koluchiy]

Маленькие блоки RAM - это распределенная RAM.
Если она, конечно, есть.

[m0use]

Маленькие блоки RAM - это распределенная RAM.

Кстати, об этом тоже хотел узнать. Вот у меня небольшой блок памяти описывается поведенчески. На RTL схеме изображается блок RAM, всё как надо. Так вот этот блок RAM - это распределённая память на LUT или блочная RAM?

Просто, я как понял, именно блочную память эффективно с перемножителями использовать, потому что они в кристалле рядом. И можно ли как-то синтезатору SXT сказать, чтобы он блочную память использовал, а не распределённую даже для небольших блоков?

[des00]

Просто, я как понял, именно блочную память эффективно с перемножителями использовать, потому что они в кристалле рядом. И можно ли как-то синтезатору SXT сказать, чтобы он блочную память использовал, а не распределённую даже для небольших блоков?

а ничего что латентность чтения у этих блоков памяти разная ?

[m0use]

а ничего что латентность чтения у этих блоков памяти разная ? smile.gif

Разная - это какая? У блочной памяти время отклика больше?

Сообщение отредактировал m0use - Oct 5 2010, 12:34

[rv3dll(lex)]

вообще про какую плис речь?

для памяти нужен свой быстрый клок.
сама память работать будет на частотах например 500 при том, что остальная схема, если она большая не получится и на 200.

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

[m0use]

А менеждеры клоков умеют получать из одного клока другой, более быстрый? Просто у меня на отладочной плате только и генератор на 50МГц . И получается, если клоки разные будут для памяти и для основной логики, то надо будет решать вопрос синхронизации? Enable какой-нибудь делать?

ПЛИС - Spartan3E.

[Maverick]

Неплохо было бы, чтобы матрица была размером не меньше, чем 64x48. Вообще надо обрабатывать изображение 640x480, но думаю, такой объём не эффективно обрабатывать - буду разбивать на блоки порядка 64x48. Элемент матрицы - байт.

rv3dll(lex), а могли бы Вы пояснить. Для того, чтобы такое провернуть, нужен отдельный CLK или можно преобразовать общий CLK и получить большую частоту?

как по мне лучше распределенная память - на регистрах. Таким образом обеспечивается параллельный доступ ко всем элементам матрицы. Но возможно скорость обработки упадет из-за этого...
Если на RAM блоках тогда нужно придумать FSM, который будет последовательно считывать данные матрицы из RAM блоков и записывать результат обратно в RAM блоки или передавать дальше на обработку... В этом случае наверное нужна двухпортовая память, чтобы "развязать" по скорости поступающих данных на входе и обработанных данных на выходе. Это в том случае если не удастся реализовать обработку входящих данных на проходе (обработка в реалтайме)...
PS Почему бы не взять за основу матрицу 8х6? Как по мне ресурсоемкость меньше и т.д. ...

И получается, если клоки разные будут для памяти и для основной логики, то надо будет решать вопрос синхронизации? Enable какой-нибудь делать?

ПЛИС - Spartan3E.

Выход - двухпортовая память или фифо или синхронизаторы на основе двух регистров.

Можно по другому пути пойти (память (во внутреннюю или во во внешнюю пока не важно))
1. изображение 640x480 записывать в память, а потом уже производить его обработку.
2. Изображение поступает например на частоте 5 МГц, а Ваша схема работает на частоте 50 МГц. Тогда можно организовать автомат, который на каждом десятом такте производил запись входных данных ( изображения 640x480) в память, а остальные 9 тактов производил бы обработку данных.
3. Организовать конвейерное обработку "на проходе". Т.е. производить обработку изображения по мере поступления пикселей изображения. Изображение ж на ПЛИС поступает последовательно..., правильно? Таким образом, когда будет конец кадра изображения - обработанные данные при таком подходе также будут готовы (с некоторой задержкой)

[m0use]

Почему бы не взять за основу матрицу 8х6? Как по мне ресурсоемкость меньше и т.д. ...

Матрицу 8x6 использую пока для отладки. Но вообще думаю о больших размерах .

Просто изображение большое - 640x480 и блоков по 8x6 получится много - то есть чтобы всю матрицу обработать, нужно много проходов. Конечная цель - получить хорошую скорость обработки именно изображения в целом. Поэтому и хочу "элементарный" блок увеличить.

Почему пришлось использовать RAM. В самом начале (когдя я ещё ничего не понимал о внутренней структуре ПЛИС, и смотрел на него как на штуку, которая может много оперций делать за один такт) я всё сделал на регистрах. И всю обработку сделал параллельной. А так как из порядка 100 умножений кристалл аппаратно может сделать лишь 20 получилось много логики (под 100% ресурсов на матрице 8x6) и мало скорости (5 МГц ).

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

Так что буду пробовать. Умножу как RAM, а складывать буду как регистровую память. Посмотрим, насколько макс.такт упадёт. Пока 120МГц. Я бы просто не хотел ниже 100 опускаться. Просто основная операция - умножение по ресурсам. И если их хотя бы больше 10 использовать, но эквивалентная частота будет больше 1ГГц.

[Maverick]

для конкретности понимания Вас не могли бы поделиться алгоритмом обработки изображения , который необходимо реализовать и требованиями к реализации?

[Koluchiy]

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

И резко возрастет объем проекта...