Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Распределенная память
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
GAYVER
Aug 30 2018, 13:02
блок двухпортовой распределенки с синхронной записью и асинхронным чтением. описан по шаблону из хелпа. по объему - четверть от максимально доступной. на мапе выдает:

CODE
The following instances are the last set of instances that failed to place:
0. B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O (size: 8)
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMC
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMB
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMA
.............................................

These instances could be impacted by the following constraints
(the line IDs below correspond with the instances above):

Clock Region restrictions

0. LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O
driver: DCM B_PLL/DCM_inst1 @ DCM_X0Y3
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O
driver: DCM B_PLL/DCM_inst1 @ DCM_X0Y3
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O
driver: DCM B_PLL/DCM_inst1 @ DCM_X0Y3
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O
driver: DCM B_PLL/DCM_inst1 @ DCM_X0Y3
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O
driver: DCM B_PLL/DCM_inst1 @ DCM_X0Y3
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O
driver: DCM B_PLL/DCM_inst1 @ DCM_X0Y3
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O
driver: DCM B_PLL/DCM_inst1 @ DCM_X0Y3
LUTM B_IN_ADC/B_RAMD_IN_test/Mram_RAM_RE_STR11_RAMD_O
driver: DCM B_PLL/DCM_inst1 @ DCM_X0Y3
CLOCKREGION_X0Y2, CLOCKREGION_X1Y2
...............................................................


для меня тут никакой смысловой нагрузки... куда смотреть, чего делать?
RobFPGA
Aug 30 2018, 14:08
Приветствую!
Цитата(GAYVER @ Aug 30 2018, 16:02) *
блок двухпортовой распределенки с синхронной записью и асинхронным чтением. описан по шаблону из хелпа. по объему - четверть от максимально доступной. на мапе выдает:
...
Clock Region restrictions
...
Могу предположить что клок для этой RAM является локальным а не глобальным - типа полученным от какого-то BUFIO/BUFH - вот и не хватает всей Вашей RAM размазанной по всему кристаллу теплого местечка у этого клока.

Цитата(GAYVER @ Aug 30 2018, 16:02) *
для меня тут никакой смысловой нагрузки... куда смотреть, чего делать?
Откровенно самокритично sm.gif ...

Подумать, поменять тип клока ...
Подумать зачем Вам такая размазня на четверть кристалла, поменять тип памяти на BRAM ...
Подумать, ...

Удачи! Rob.
GAYVER
Aug 31 2018, 06:10
Цитата(RobFPGA @ Aug 30 2018, 17:08) *
Приветствую!
Могу предположить что клок для этой RAM является локальным а не глобальным - типа полученным от какого-то BUFIO/BUFH - вот и не хватает всей Вашей RAM размазанной по всему кристаллу теплого местечка у этого клока.

Откровенно самокритично sm.gif ...

Подумать, поменять тип клока ...
Подумать зачем Вам такая размазня на четверть кристалла, поменять тип памяти на BRAM ...
Подумать, ...

Удачи! Rob.



вот я и смотрел что там с клоками не так... пока ничего не насмотрел - все берется с ДСМа, раскидывается через буфг.

взять блочку не получится ввиду ее нехватки.

сегодня еще попробую однопортовую сделать вместо двушки.

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

зы
вспоминается случай с ИСЕ, когда в процессе разводки неправильно собиралась шина sm.gif. допустим, есть шина NAME(7:0) и несколько сигналов NAME_1, NAME_5. после разводки шина имела вид:
NAME(7:0)= NAME(7) & NAME(6) & NAME_5 & NAME(4) & NAME(3) & NAME(2) & NAME_1 & NAME(0)

пока я это нашел... пол кристалла облазил ))

вот чую сейчас будет что то подобное...
andrew_b
Aug 31 2018, 06:24
Сколько клоков у вас используется?
Сколько и каких тактовых буферов задействовано?
RobFPGA
Aug 31 2018, 06:37
Приветствую!
Цитата(GAYVER @ Aug 31 2018, 09:10) *
вот я и смотрел что там с клоками не так... пока ничего не насмотрел - все берется с ДСМа, раскидывается через буфг.
Ну нам то от сюда не видно как все на самом деле.

Цитата(GAYVER @ Aug 31 2018, 09:10) *
...
сталкивался, чтобы хоть как то сократить область поисков. потому как каждая неудачная разводка до момента выкидывания репортов крутится часа 2-3... и выкинуть часть проекта не получится - это и так тестовая рыба без основного вычислителя
Для Spartan 6? 2-3 часа? Сурово. blink.gif Что же Вы там такого намутили? Для уменьшения времени тут надо бы заняться абстрактной живописью в стиле Пикассо в PlanAhead - выделять блоки/модули дизайна и фиксировать их на кристалле. За 2-3 итерации существенно сокращает время сборки. Но кажется мне что это долгое "жжж" неспроста - обычно это показатель не оптимального дизайна с кучей потенциально критичных мест (по ресурсам или времянке).

Цитата(GAYVER @ Aug 31 2018, 09:10) *
взять блочку не получится ввиду ее нехватки.
С учетом предыдущего пункта тут уже напрашивается необходимость пересмотра структуры дизайна раз все так критично и приходиться ресурсы по сусекам скрести.

Удачи! Rob.
GAYVER
Aug 31 2018, 08:21
тайна раскрыта sm.gif. в недрах дизайна обнаружен буфер, на вход которого заведена синхра (которая идет и на память), а выход - на логику. выход буфера законстрэйнен через CLOCK_DEDICATED_ROUTE. после ЭНДки полученный сигнал сразу вытаскивался на пин плисины и нигде внутри больше не использовался. но выход буфера был воспринят как клок и растащен дальше на память...

Цитата(RobFPGA @ Aug 31 2018, 09:37) *
С учетом предыдущего пункта тут уже напрашивается необходимость пересмотра структуры дизайна раз все так критично и приходиться ресурсы по сусекам скрести.

Удачи! Rob.



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

Цитата(RobFPGA @ Aug 31 2018, 09:37) *
Для Spartan 6? 2-3 часа? Сурово. blink.gif Что же Вы там такого намутили? Для уменьшения времени тут надо бы заняться абстрактной живописью в стиле Пикассо в PlanAhead - выделять блоки/модули дизайна и фиксировать их на кристалле. За 2-3 итерации существенно сокращает время сборки. Но кажется мне что это долгое "жжж" неспроста - обычно это показатель не оптимального дизайна с кучей потенциально критичных мест (по ресурсам или времянке).

Удачи! Rob.



ну 2-3 часа это он какраз пытается впихнуть невпихуемое. алгоритм же 3 или 4 раза стартует с нуля, в случае неудачи предыдущего шага. а если все в порядке, то разводка с учетом УЦФа минут за 10-15 проходит sm.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.