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

[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? То есть если данные будут хранится в памяти, а по мере необходимости вычислений они оттуда будут выдёргиваться.

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

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

[Shtirlits]

Я бы ответы искал User Guide на конкретную микросхему, в разделе Block RAM.
Потом сделал бы схему, которая пишет и читает память обращаясь к разным её портам.
Далее обдумал бы полученный результат и перепроектировал свою схему.

[CaPpuCcino]

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

то снизит ли это количество используемых LUT?

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

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

есть всё в документации на сайте. однако в принципе синтезатор может синтезировать память из обычного описания на языке. главное чтобы описываемое вами хранилище не противоречило параметрам аппаратного ядра (только что об этом говорил здесь -> http://electronix.ru/forum/index.php?showt...st&p=809678 )
алаверды

ЗЫЖ правда судя по этому

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%

проблема с ресурсами упирается в комбинаторику и боюсь встроенная память вам не поможет. и вообще-то меня терзают смутные сомнения... (правильно ли вы описываете то, что проектируете)
и ещё вот это вот: Number of bonded IOBs: 19 out of 232 8%
что это за проект такой хитрый?

_{Отредактировано пользователем 03:02 14 сентября 2010}

[m0use]

Спасибо за советы и Ваше время!

Кристалл - Spartan3E (xc3s500e). Block RAM обязательно посмотрю.

меня терзают смутные сомнения... (правильно ли вы описываете то, что проектируете)

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

и ещё вот это вот: Number of bonded IOBs: 19 out of 232 8%
что это за проект такой хитрый?

Я не очень понимаю и прошу Вас пояснить, почему эти данные заставили Вас предположить, что проект хитрый. Это в каком контексте такой показатель - плохо (или хорошо)?

Суть проекта такая. В ПЛИСу загружается матрица (изображение). Из этой матрицы получается градиентные матрицы (по x и по y), их которых по алгоритму Харриса (описание на en-wiki) в трёх вложенных for-циклах строится нужная матрица. То есть достаточно много матриц, которые получаются из друг друга. Может быть, собственно, поэтому и получается много LUTов, которые все эти регистры и их сочетания обеспечивают.

Сообщение отредактировал m0use - Sep 14 2010, 21:25

[CaPpuCcino]

Я не очень понимаю и прошу Вас пояснить, почему эти данные заставили Вас предположить, что проект хитрый. Это в каком контексте такой показатель - плохо (или хорошо)?

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

Суть проекта такая. В ПЛИСу загружается матрица (изображение). Из этой матрицы получается градиентные матрицы (по x и по y), их которых по алгоритму Харриса

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

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

[ADA007]

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

Да, количество LUT конечно же снизится, дело в том, что при подключении Block RAM как примитива память будет строиться уже не на триггерах, а на блочной памяти, которая находится на кристалле, кстати доступ к ней будет осуществляться гораздо быстрее, чем если бы она была построена на траггерах. Так как это примитив, то его надо генерировать IP Core Generator и подключить к проекту. Более подробно читаем тут...

[andrew_b]

Так как это примитив, то его надо генерировать IP Core Generator и подключить к проекту.

Совершенно не обязательно. В большинстве случаем память прекрасно описывается поведенчески.

[m0use]

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

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

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

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

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

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

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

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

Спасибо.

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

[des333]

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

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

UPD. Уберу как я, от греха подальше, картинку, пока неокрепшие мозги не испортил.

[CaPpuCcino]

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

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

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

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

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

[des333]

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

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

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

[CaPpuCcino]

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

вот, с начинающими как раз лучше не рисковать, потому как собственная картина мира у них ещё не сформировалась, понять и устаканить свои представления они как раз в этот момент и пытаются, а тут такое потрясение

[vadimuzzz]

у Максфилда (The Design Warrior's Guide to FPGAs, http://ifile.it/2gydqm/design.warriors.gui...o.fpga_maz.rar)
есть хорошие картинки:

[m0use]

Спасибо, войны дизайна . Вы мне глаза приоткрываете на HDL!

У меня, конечно, вопросов только больше становится, но что-то начинаю понимать .

С частотой тактирования не разобрался пока. Вот рисунок выше. Я правильно понял, что скорость возрастает за счёт того, что во втором случае (pipeling) комбинаторной логики станет меньше? А не просто от того факта, что регистр появился. Просто, к примеру фраза:

Там где очень много логики между регистрами - там самая низкая частота.

мне непонятна. Насколько я себе представляю, в простейшем случае все логические блоки сидят на одном CLK. Или CLK - это не один "проводник", на нём задержки присутствуют?

The Design Warrior's Guide to FPGAs

Спасибо за книгу. Пока кажется очень обстоятельной.

[CaPpuCcino]

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

всё верно (для простейшего случая) - чем сложнее логическая функция, тем длиннее и тернистее путь для прохождения всех сигналов по всем возможным внутренним путям. поэтому частота тактирования выбирается ~по максимальному времени распространения сигнала, иначе регистр стоящий на конце этого пути защёлкнет свою челюсть до того как до него добежит фронт сигнала.
вот смотрите: допустим у вас вся система построена на 2х входовых элементах И и ИЛИ (+ регистры). где-нибудь в пути между двумя соседними регистрами вам необходимо выполнить преобразование ((A & B ) | (C & D)) & (F & E), и есть где-нибудь в пути между другими соседними регистрами функция (X & Y). каждый логический вентиль даёт задержку сигнала 1 нс. в первом случае у вас минимальная задержка прохождения сигнала будет 2 нс, а максимальная 3 нс (посчитайте количество скобок в выражении и попробуйте нарисовать эту пирамидальную структуру с задержками на каждом вентиле. чтобы понять, что можно говорить и о минимальной задержке, представьте, что некоторые переменные могут и не меняться, т.е. сигнал на этих путях стабилен - фронта распространения нет). во втором случае время задержки 1 нс (если принять, что хоть один сигнал из X,Y меняться всё-таки должен). все регистры системы тактируются одновременно (!условно! одновременно, т.к. сигнал тактирования тоже должен бегать по проводам, а длинна этих проводов до каждого из регистров может быть разная, но этим можно пока пренебречь). если мы будем тактировать систему с учётом минимально возможной задержкой (1нс на X&Y), то первая функция просто не будет успевать пропустить через себя изменяемые значения собственных переменных и всё у нас будет через одно место, поэтому приходится тактировать схему с частотой как минимум соответств. самой большей задержке системы.
теперь, если угодно вопрос на засыпку: а можно ли схему выполняющую те же самые логические преобразования изменить так, чтобы заставить тактироваться всё-таки с периодом в 1нс? (при тех же самых условиях о 2х входовых элементах с 1нс задержкой фронта)
ЗЫ: в архитектурах ПЛИС в данный момент логика реализуется не на базе 2х входовых булевых вентелях, но общий принцип остаётся тем же

Я правильно понял, что скорость возрастает за счёт того, что во втором случае (pipeling) комбинаторной логики станет меньше? А не просто от того факта, что регистр появился.

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

[Shtirlits]

какие есть средства для "эквивалентной трансформации вычислительного метода" ?

[des333]

какие есть средства для "эквивалентной трансформации вычислительного метода" ?

Бумага, ручка и мозг. 

[CaPpuCcino]

Бумага, ручка и мозг. 

5 баллов, ей богу! это в общем именно так, во всяком случае я с автоматизированными системами не знаком (возможно какие-то наработки в области эвристики имеются).

какие есть средства для "эквивалентной трансформации вычислительного метода" ?

я на всякий случай (если не понятно о чём именно идёт речь) поясню несколькими простыми примерами:
самый простой, что приходит первым делом на ум: умножитель можно сделать матричным, а можно на основе КА (т.е. аккумуляторным). здесь точность не меняется в общем случае, тактовая тоже остаётся на месте, а вот общая производительность меняется за счёт существенного изменения ресурсов.
следующий пример: сортировка массивов. есть множество методов и параллельных и более последовательных и они очень сильно различаются по всем показателям, кроме точности (в общем случае о таких трансформациях выпускают книжки в основном для программирования супер-ЭВМ/различных архитектур/).
есть копромиссные преобразования, которые как правило меняются и по точности и в общем случае по качеству(о точности можно говорить условно) преобразования. как-то классифицировать их я не берусь. примеров много в области обр. сигналов (в основном точность), и в частности изображений (качество в общем смысле)
алаверды

[m0use]

теперь, если угодно вопрос на засыпку: а можно ли схему выполняющую те же самые логические преобразования изменить так, чтобы заставить тактироваться всё-таки с периодом в 1нс?

Кажется, я понял. Надо добавить 4 регистра для хранения промежуточных результатов. Тактирование тогда станет 1 нс. Хотя в первом случае на получение результата операции потребуются все те же 2-3 нс (2-3 такта), во втором случае мы получим его за 1 нс, а не за 3 нс. Так ?

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

Сообщение отредактировал m0use - Sep 22 2010, 11:34

[m0use]

Посмотрел код. Может, в этой триаде - бумага+карандаш+мозг - что-то недостаточно развито, но мне показалось, что главный вопрос был сформулирован CaPpuCcino уже давно:

и вообще-то меня терзают смутные сомнения... (правильно ли вы описываете то, что проектируете)

Меня тоже терзают, поэтому сначала приведу описание того, что я проектирую на языке Русский, а потом то, как я это описал на языке Veilog.

Русский:

Код

Функциональная задача такая - на вход поступает изображение, матрицы RGB. Пусть пока это одна матрица I (требуемый порядок - 640x480). Из этой матрицы получается две градиентные матрицы - по x (Ix) и по y (Iy). После этого из этих градиентных матриц строится матрица Харриса по формуле выше.

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

Verilog:

Код

// ASSIGNES //
assign end_load_w = ( int_bytes_loaded == P_IMAGE_ROWS * P_IMAGE_COLS - 1 );
assign end_grad_w = ( int_grad == P_IMAGE_ROWS * P_IMAGE_COLS  );
assign end_harris_w = ( int_harris == P_HARRIS_SIZE );
<...>;
// END ASSIGNES //

/ ALWAYS-BLOCKS //
// ** RESET & LOAD & DBOUTPUT ** //
always @( posedge CLK or posedge RESET ) begin
    if( RESET ) <начальная иницализация>;
    else if( IN_1_BTN_CLICK && !end_load_w ) begin
        mem_image[ int_bytes_loaded ] <= IN_8_IMAGE;
        int_bytes_loaded <= int_bytes_loaded + 1;
        DB_OUT_7_LED_r <= int_bytes_loaded;
    end
    else <после окончания преобразования вывод результата>;
end
// ** GRADIENT & HARRIS ROUTINE ** //
always @( posedge CLK or posedge RESET ) begin
    if( RESET ) <начальная инициализация>
    else if( end_load_w && !end_grad_w && !end_harris_w  )
        for( int_xi = 0; int_xi < P_IMAGE_COLS; int_xi = int_xi + 1 )
            for( int_yi = 0; int_yi < P_IMAGE_ROWS; int_yi = int_yi + 1 )
                if( int_grad != P_IMAGE_ROWS * P_IMAGE_COLS ) begin
                    mem_image_x[ int_xi + P_IMAGE_COLS*int_yi ] = <разность по x>;
                    mem_image_y[ int_xi + P_IMAGE_COLS*int_yi ] = <разность по y>;
                    int_grad = int_grad + 1;
                end
                else;
    else if( end_load_w && end_grad_w && end_db_output_w && !end_harris_w )
        for( int_xi_2 = P_RADIUS; int_xi_2 < ( P_IMAGE_COLS - P_RADIUS ); int_xi_2 = int_xi_2 + 1 )
            for( int_yi_2 = P_RADIUS; int_yi_2 < ( P_IMAGE_ROWS - P_RADIUS ); int_yi_2 = int_yi_2 + 1 )
                if( int_harris != P_HARRIS_SIZE ) begin
                    mem_harris[ <адрес блока памяти> ] = f_harris_block( int_xi_2, int_yi_2 );
                    int_harris = int_harris + 1;
                end
                else;
    else;
end
<...>;
// END ALWAYS-BLOCKS //

// FUNCTIONS //
// ** TABLE SQRT ** //
function integer f_my_sqrt;
    input integer f_int_x;
    
    case( f_int_x )
        0: f_my_sqrt = 0;
        3: f_my_sqrt = 1;
        4: f_my_sqrt = 2;
        default: f_my_sqrt = 255;
    endcase
endfunction
// ** HARRIS BLOCK ** //
function integer f_harris_block;
    // FARGUMENTS //
    input integer f_int_x;
    input integer f_int_y;
    // FVARIABLES //
    integer f_int_ki;
    integer f_int_ri;
    integer f_int_xx;
    integer f_int_xy;
    integer f_int_yy;
    
    begin
        f_int_xx = 0;
        f_int_xy = 0;
        f_int_yy = 0;
        for( f_int_ki = -P_RADIUS; f_int_ki <= P_RADIUS; f_int_ki = f_int_ki + 1)
            for( f_int_ri = -P_RADIUS; f_int_ri <= P_RADIUS; f_int_ri = f_int_ri + 1 )
            begin
                if( `_ABS( f_int_ri ) <= f_my_sqrt( `_SQR( P_RADIUS ) - `_SQR( f_int_ki ) ) ) begin
                    f_int_xx = f_int_xx + <mem_image_x * mem_image_x>;
                    f_int_xy = f_int_xy + <mem_image_x * mem_image_y>;
                    f_int_yy = f_int_yy + <mem_image_y * mem_image_y>;
                end
                else;
            end
        f_harris_block = f_int_xx + f_int_xy + f_int_yy;
    end
endfunction
// END FUNCTIONS //

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

Сообщение отредактировал m0use - Sep 22 2010, 14:49

[CaPpuCcino]

а вы моделировали функционально? результат получается правильным? (это чтоб не проверять математику, а сконцентрироваться только на оптимизацией путей данных)

Хотя в первом случае на получение результата операции потребуются все те же 2-3 нс (2-3 такта), во втором случае мы получим его за 1 нс, а не за 3 нс.

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

[m0use]

Не, и так понятно, Вы доступно объясняете. Спасибо .

а вы моделировали функционально? результат получается правильным?

В работе я уже код проверял - программировал ПЛИС, код работает, выход правильный, т.е. математика корректная.

[CaPpuCcino]

а какая оценка тактовой даётся синтезатором?
и почему у вас так регистров-то мало используется вы не думали? 640*480 уже за 300 тыс. слов, а у вас только около 1 тыс бит
ещё боюсь у вас с умножителями беда - аппаратных умножителей в вашем кристалле всего 20. это значит требуемые умножители будут реализованы на общей логике, а это очень жирно м.б.

вы не подскажите вот эти угловые скобки в выражение, это что такое - никак не могу вспомнить их в верилоге
f_int_xx = f_int_xx + <mem_image_x * mem_image_x>

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

[des333]

вы не подскажите вот эти угловые скобки в выражение, это что такое - никак не могу вспомнить их в верилоге 
f_int_xx = f_int_xx + <mem_image_x * mem_image_x>

И не вспомните. 

У автора их еще много.

Код

<...>;
...
if( RESET ) <начальная иницализация>;
...
mem_harris[ <адрес блока памяти> ] = f_harris_block( int_xi_2, int_yi_2 );

[m0use]

а какая оценка тактовой даётся синтезатором?

Код

Timing Summary:
---------------
Speed Grade: -4

   Minimum period: 206.584ns (Maximum Frequency: 4.841MHz)
   Minimum input arrival time before clock: 2.793ns
   Maximum output required time after clock: 4.310ns
   Maximum combinational path delay: No path found

Блин, мало получается. Я думал, по наивности, что 50МГц - то есть как раз то, что с кварца подаётся .

и почему у вас так регистров-то мало используется вы не думали? 640*480 уже за 300 тыс. слов, а у вас только около 1 тыс бит

У меня входная матрица - 8*6. Отладочный вариант. О 640*480 я только мечтать могу с таким кодом .

это значит требуемые умножители будут реализованы на общей логике

Объясните пожалуйста, что значит "на общей логике". Это с помощью LUTов?

Угловые скобки - это моё изобретение для экономии места. Я в них суть общую обозначал. Просто очень длинные индексы у матриц .

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

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

Самое главное, что мне пока не понятно - это почему тактовая частота такая низкая. Как Вы думаете, если перейти к блочной обработке, частота повысится?

есть подозрение, что вы кристалл выбрали слабый

А кристалл пока выбирать не приходится - SDK Nexys2 .

Сообщение отредактировал m0use - Sep 22 2010, 16:12

[CaPpuCcino]

Самое главное, что мне пока не понятно - это почему тактовая частота такая низкая. Как Вы думаете, если перейти к блочной обработке, частота повысится?

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

Объясните пожалуйста, что значит "на общей логике". Это с помощью LUTов?

да

[m0use]

Понятно. А есть ли возможность конвеерно выполнять все необходимые умножения на эти 20 аппаратных умножителях?

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

Не совсем понятны мне эти термины, ну, это дело такое - загуглю. Но знаю, что есть уже написанные умножители (IP Core в ICE) - применение этих модулей поможет решить вопрос?

[CaPpuCcino]

Понятно. А есть ли возможность конвеерно выполнять все необходимые умножения на эти 20 аппаратных умножителях?

Не совсем понятны мне эти термины, ну, это дело такое - загуглю. Но знаю, что есть уже написанные умножители (IP Core в ICE) - применение этих модулей поможет решить вопрос?

1) да именно так и придётся делать (на мой взгляд) - пусть у вас скользящее окно по картинке едит и делает преобразования локально в этом окне.
это "едет" означает, что вы из вашей картинки организуете поток, который будет проходить через ваш конвейер преобразований.
2) этого не знаю. всё зависит от того как вы конвейер задумаете реализовывать. я сам себе когда-то разных реализаций умножителей наделал (когда-то софт-процессор лепил) и до сих пор ими по необходимости пользуюсь. ЗЫЖ кстати ISE а не ICE, но это лирика

[m0use]

Идею понял, только уточнить хочу. Если у меня в always-блоке будет использоваться не более 20 умножений, то все они будут реализованы на аппаратных умножителях?

Софт-процессор - это круто! А с ISE опечатка, верно .

[des333]

Идею понял, только уточнить хочу. Если у меня в always-блоке будет использоваться не более 20 умножений, то все они будут реализованы на аппаратных умножителях?

Если у вас весь проект состоит из одного блока always - то да. 

[CaPpuCcino]

Если у меня в always-блоке будет использоваться не более 20 умножений, то все они будут реализованы на аппаратных умножителях?

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

[Krys]

ЗЫЖ правда судя по этому

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%

проблема с ресурсами упирается в комбинаторику и боюсь встроенная память вам не поможет. и вообще-то меня терзают смутные сомнения... (правильно ли вы описываете то, что проектируете)

Дело в том, что луты можно использовать как память. Ключевое слово Distributed RAM. Так что, наоборот, такие строчки из отчёта синтезатора говорят о том, что использование RAM-блока вполне может исправить ситуацию.