[Alex__M_15_1968 0]

Добрый день, уважаемые коллеги.

 

Нужна Ваша консультация  по следующему вопросу.

Есть "железо" на Spartan-6. При проектировании FPGA используется связка ПО Synplify Premier и ISE Design Suite , т.к. проект написан в SystemVerilog. В проекте есть большое (порядка 60-ти) количество параллельно работающих таблиц (это ПЗУ, в которых лежат константы). Никак не удается "положить" эти ПЗУ в блочную память, таблицы сейчас хранятся в sliсe-ах, которых из-за этого  не хватает для остальной логики проекта.   

 

Прикладываю для анализа максимально упрощенные файлы проекта. Файл верхнего уровня - регистры (по входным адресам и выходным данным) в контактах FPGA .

Второй файл - теоретически должно быть 4 таблицы размерностью 4х20 разрядов каждая.

Третий файл с константами для таблиц, всего 16 20р слов.

  

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

Или нужно как-то иначе описать множество таких таблиц?

 

Спасибо.

mem.hex rom_taps2.sv rom_top.sv

[des00 25]

1 hour ago, Alex__M_15_1968 said:

Второй файл - теоретически должно быть 4 таблицы размерностью 4х20 разрядов каждая.

Третий файл с константами для таблиц, всего 16 20р слов.  

такие мелкие таблицы как раз проще класть именно в логику. LUT у спартана6 это ROM64x1. ваши 16х20 лягут в худшем случае в 20 лютов. Укладывая это в блочную память вы больше проиграете. Т.е. на таком размере таблицы, вам даже передискретизация не поможет (когда в одной памяти все таблицы и вы на высокой тактовой читаете в регистры), потому что используя регистр для прочитанной константы, вы тратите тот самый лют, который пытаетесь сэкономить)

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

UPD. единственное что можно сделать, что может быть будет в плюсе, это использовать блочную память в режиме честной двухпортовки в режиме 512x32(36) и положить туда две таблицы.  Ну и придется изменить код что бы они попарно обращались к этим блоками.  Тогда овчинка может быть будет стоить выделки. Сэкономите ~(30-60)*20 = 600-1200 плиток (если тактовая низкая), уйдет 30 блоков памяти. вивада умеет сама склеивать, но для шестого спартана селяви

 

[Alex__M_15_1968 0]

44 minutes ago, des00 said:

такие мелкие таблицы как раз проще класть именно в логику. LUT у спартана6 это ROM64x1. ваши 16х20 лягут в худшем случае в 20 лютов. Укладывая это в блочную память вы больше проиграете. Т.е. на таком размере таблицы, вам даже передискретизация не поможет (когда в одной памяти все таблицы и вы на высокой тактовой читаете в регистры), потому что используя регистр для прочитанной константы, вы тратите тот самый лют, который пытаетесь сэкономить)

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

UPD. единственное что можно сделать, что может быть будет в плюсе, это использовать блочную память в режиме честной двухпортовки в режиме 512x32(36) и положить туда две таблицы.  Ну и придется изменить код что бы они попарно обращались к этим блоками.  Тогда овчинка может быть будет стоить выделки. Сэкономите ~(30-60)*20 = 600-1200 плиток (если тактовая низкая), уйдет 30 блоков памяти. вивада умеет сама склеивать, но для шестого спартана селяви

 

Спасибо за ответ.

Да, логично положить это в слайсы, но если таблиц 60... и их размерность не 4х20, а 64х20, как в боевом проекте.... извините умолчал об этом

Я здесь выложил сильно усеченный пример (по сути только 4 таблицы с выходами наружу) в расчете на совет по констрейнам.

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

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

[des00 25]

48 minutes ago, Alex__M_15_1968 said:

Да, логично положить это в слайсы, но если таблиц 60... и их размерность не 4х20, а 64х20, как в боевом проекте.... извините умолчал об этом

что 4х20, что 64х20 лягут в 20 LUT или 5SLICE. В отличии от сыклона 4 с LUT4 (ROM16x1), у спартана 6 LUT6 (ROM64x1). Блок блочной памяти большего размера 18к и их меньше. Стоят они в редких колонках по чипу, задержка с выходной памяти до логики составит порядка 4-5нс. Поэтому софт и не ставит такие таблицы в блочную память. Он не видит смысла по ресурсу и скорее всего считает что не впишется по времянке. А если со времянкой с этих таблиц начнутся проблемы, то он вам накрутит ресурса больше, чем вы сэкономили(начнет дублировать пути, регистры и все такое).

Если это константы времени исполнения, то может быть set_false_path поможет. Кстати ЕМНП симплифай пишет в логах почему не смог применить те или иные атрибуты синтеза, по памяти у вас прописано верно

48 minutes ago, Alex__M_15_1968 said:

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

Тогда вам лучше шаблоны описания симплифая посмотреть, ЕМНП, тот шаблон что вы привели симплифай не поймет. Но вот типа такого 

  localparam bit [17 : 0] cTAB[1024] = '{...};

  always_ff @(posedge iclk) begin
    if (iclkena) begin
      rdat[0] <= cTAB[addr];
      rdat[1] <= rdat[0];
    end
  end

вроде понимал лет 10 назад. Но самый надежный способ вставить RAMB18 руками и прописать INIT_XX параметры

48 minutes ago, Alex__M_15_1968 said:

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

Ну у вас в коде было addr_reg -> LUT -> reg. На это уйдет 1/4 + 1/8 слайса (при удачной упаковке) или 1/4 слайса (при неудачной), если убрать первый слой, то будет LUT-reg 1/4 слайса всегда для памяти от 1х1 до 64х1

UPD. Кстати, как вариант, добить мусором ваши таблицы, до размера 128х20, тогда вполне возможно что симплифай поставит их в блочную память, без танцев с бубном). Но вообще учтите, что в отличии от альтеровского LAB, у хилого SLICE, с ресурсом все несколько по другому) Проект может использовать 80% LUT, но 100% SLICE. Т.е. он не всегда может склеить разнородную логику в одном слайсе)

[Alex__M_15_1968 0]

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

попробую все варианты

[andrew_b 14]

Не во всех слайсах луты могут работать как память. В Спартане-6 только в SLICEM можно сделать память, а таких слайсов только четверть от всех. Остальные три четветри (SLICEL и SLICEX) такой функциональности не имеют. См. ds160, стр. 4.

[des00 25]

10 hours ago, andrew_b said:

Не во всех слайсах луты могут работать как память.

Вы про RAM, а у него ROM. А LUT и есть ROM. 

[Timmy 1]

В Spartan6 LUT6 имеет дополнительный вывод с младшей половинки(LUT5), за счёт чего один лут может хранить ROM таблицу 2 разряда по 32 бита, а слайс соответственно 8x32.