Jump to content

    

Работа с памятью (BRAM) Vivado.

Добрый день.

Столкнулся со следующей проблемой.

При переносе проекта с ISE на Vivado.

Присутствует память ROM, реализован на BRAM объявлена как  is array (4095 downto 0) of std_logic_vector (99 downto 0);

Я думал синтезатор разобьет её на блоки 4096x9 и поставит их в колонку и все будут счастливы, как это было в ISE.

Но он сделал из них блоки 1024x36 и получилось каскад из 4 блоков памяти. (см. прикрепленный файл). Естественно там не сошлись времянки :(

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

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

Использовать примитивы не хочется :(

 

Ужас.png

Share this post


Link to post
Share on other sites
20 минут назад, Tpeck сказал:

Присутствует память ROM, реализован на BRAM объявлена как  is array (4095 downto 0) of std_logic_vector (99 downto 0);

Я думал синтезатор разобьет её на блоки 4096x9 и поставит их в колонку и все будут счастливы, как это было в ISE.

Так сделайте несколько блоков 4096x6 через generate

Share this post


Link to post
Share on other sites

Есть аттрибут CASCADE_HEIGHT, который можно управлять конфигурацией синтезируемой памяти. Правда про него пишут, что он только для Ultrascale.

Share this post


Link to post
Share on other sites
5 minutes ago, iosifk said:

Так сделайте несколько блоков 4096x6 через generate

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

А тут уже ROM, надо переделывать конфигурационные файлы и как-то их подсовывать в этот generate.

6 minutes ago, alexadmin said:

Есть аттрибут CASCADE_HEIGHT, который можно управлять конфигурацией синтезируемой памяти. Правда про него пишут, что он только для Ultrascale.

Если я правильно понял, то этот атрибут будет действовать на весь проект, а у меня в этом проекте используется каскад с размером - 2.

Это как крайний случай.

Share this post


Link to post
Share on other sites
4 minutes ago, Tpeck said:

А тут уже ROM, надо переделывать конфигурационные файлы и как-то их подсовывать в этот generate.

так а в чём проблема, если как Вы пишете не пользуетесь примитивами?

reg [4095:0] myROM [6][..] = { /*const_here*/ };

PS: синтезить с птичкой -sv

 

Share this post


Link to post
Share on other sites
19 minutes ago, Tpeck said:

Если я правильно понял, то этот атрибут будет действовать на весь проект, а у меня в этом проекте используется каскад с размером - 2.

Нет, отчего? Аттрибут накладывается индивидуально на объект в HDL-коде (или через XDC). В ug901 пример приведен:

(* cascade_height = 4 *) reg [31:0] ram [(2**15) - 1:0];

Share this post


Link to post
Share on other sites
6 minutes ago, alexadmin said:

Нет, отчего? Аттрибут накладывается индивидуально на объект в HDL-коде (или через XDC). В ug901 пример приведен:

(* cascade_height = 4 *) reg [31:0] ram [(2**15) - 1:0];

А слона то я и не приметил :(

 Спасибо :)

Буду пробовать.

Share this post


Link to post
Share on other sites
32 minutes ago, Doka said:

так а в чём проблема, если как Вы пишете не пользуетесь примитивами?

Это каждую память надо разбить на блоки. Инициализирующие файлы разбить на блоки.

Входы разбить на array, выходы разбить на array. Корректно все это разъединить, потом соединить.

Переписать конфигурационные скрипты, они станут не совместимы со старым софтом под ISE и кучу всякого еще вылезет.

Потом все это еще проверить надо будет. Брррррр.

PS тем более, если есть  cascade_height :)

Share this post


Link to post
Share on other sites
9 hours ago, Alex77 said:

ug949 глава 3 ???

Спасибо.

В догонку к регистру OutReg внутри памяти они еще один регистр предлагают поставить снаружи, если fanout большой.

Вот только какой в чем причина таких действий?

Выход триггера имеет большую нагрузочную способность чем выход BRAM с OutReg ?

Выход триггера имеет выход на более удобные связи внутри ПЛИС чем BRAM  с OutReg ?

OutReg.png

Share this post


Link to post
Share on other sites

Немного offtop.

Для перехода из одного SRL в другой поставили axisc_registr_slices.

И что бы вы думали? Она сделала вот такую схему (см. рисунок) и отправила из нижнего SRL  в верхней. Там сигнал поступает на триггер, но это не помогает. В итоге частота меньше 350 МГц.

PS То уровень формируется в блок дизайне. Плис забита процентов на 20-30.

SRL.png

Share this post


Link to post
Share on other sites
1 час назад, Tpeck сказал:

Выход триггера имеет большую нагрузочную способность чем выход BRAM с OutReg ?

Идея в другом. Дополнительные регистры при трассировке дублируются и ставятся в разные места. Это и сокращает пути.

Share this post


Link to post
Share on other sites

Приветствую!

8 minutes ago, Tpeck said:

Немного offtop.

Для перехода из одного SRL в другой поставили axisc_registr_slices.

И что бы вы думали? Она сделала вот такую схему (см. рисунок) и отправила из нижнего SRL  в верхней. Там сигнал поступает на триггер, но это не помогает. В итоге частота меньше 350 МГц.

PS То уровень формируется в блок дизайне. Плис забита процентов на 20-30.

А чего тут удивительного - axisc_registr_slices это простенькое FIFO на 2 слова сделанное на 2 регистрах и mux на  выходе.  По другому через SRL оно и не перетянет.

Удачи!  Rob.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now