GAYVER 2 30 августа, 2018 Опубликовано 30 августа, 2018 · Жалоба блок двухпортовой распределенки с синхронной записью и асинхронным чтением. описан по шаблону из хелпа. по объему - четверть от максимально доступной. на мапе выдает: 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 27 30 августа, 2018 Опубликовано 30 августа, 2018 · Жалоба Приветствую! блок двухпортовой распределенки с синхронной записью и асинхронным чтением. описан по шаблону из хелпа. по объему - четверть от максимально доступной. на мапе выдает: ... Clock Region restrictions ... Могу предположить что клок для этой RAM является локальным а не глобальным - типа полученным от какого-то BUFIO/BUFH - вот и не хватает всей Вашей RAM размазанной по всему кристаллу теплого местечка у этого клока. для меня тут никакой смысловой нагрузки... куда смотреть, чего делать?Откровенно самокритично :) ... Подумать, поменять тип клока ... Подумать зачем Вам такая размазня на четверть кристалла, поменять тип памяти на BRAM ... Подумать, ... Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GAYVER 2 31 августа, 2018 Опубликовано 31 августа, 2018 · Жалоба Приветствую! Могу предположить что клок для этой RAM является локальным а не глобальным - типа полученным от какого-то BUFIO/BUFH - вот и не хватает всей Вашей RAM размазанной по всему кристаллу теплого местечка у этого клока. Откровенно самокритично :) ... Подумать, поменять тип клока ... Подумать зачем Вам такая размазня на четверть кристалла, поменять тип памяти на BRAM ... Подумать, ... Удачи! Rob. вот я и смотрел что там с клоками не так... пока ничего не насмотрел - все берется с ДСМа, раскидывается через буфг. взять блочку не получится ввиду ее нехватки. сегодня еще попробую однопортовую сделать вместо двушки. самокритично, потомучто кроме расплывчатого направления "смотри клоки" ничего не понятно - куда именно смотреть и почему вообще какие то проблемы с клоком возникли. а с подобным в своей практике ранее не сталкивался, чтобы хоть как то сократить область поисков. потому как каждая неудачная разводка до момента выкидывания репортов крутится часа 2-3... и выкинуть часть проекта не получится - это и так тестовая рыба без основного вычислителя зы вспоминается случай с ИСЕ, когда в процессе разводки неправильно собиралась шина :). допустим, есть шина 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 14 31 августа, 2018 Опубликовано 31 августа, 2018 · Жалоба Сколько клоков у вас используется? Сколько и каких тактовых буферов задействовано? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 31 августа, 2018 Опубликовано 31 августа, 2018 · Жалоба Приветствую! вот я и смотрел что там с клоками не так... пока ничего не насмотрел - все берется с ДСМа, раскидывается через буфг.Ну нам то от сюда не видно как все на самом деле. ... сталкивался, чтобы хоть как то сократить область поисков. потому как каждая неудачная разводка до момента выкидывания репортов крутится часа 2-3... и выкинуть часть проекта не получится - это и так тестовая рыба без основного вычислителя Для Spartan 6? 2-3 часа? Сурово. :blink: Что же Вы там такого намутили? Для уменьшения времени тут надо бы заняться абстрактной живописью в стиле Пикассо в PlanAhead - выделять блоки/модули дизайна и фиксировать их на кристалле. За 2-3 итерации существенно сокращает время сборки. Но кажется мне что это долгое "жжж" неспроста - обычно это показатель не оптимального дизайна с кучей потенциально критичных мест (по ресурсам или времянке). взять блочку не получится ввиду ее нехватки.С учетом предыдущего пункта тут уже напрашивается необходимость пересмотра структуры дизайна раз все так критично и приходиться ресурсы по сусекам скрести. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GAYVER 2 31 августа, 2018 Опубликовано 31 августа, 2018 · Жалоба тайна раскрыта :). в недрах дизайна обнаружен буфер, на вход которого заведена синхра (которая идет и на память), а выход - на логику. выход буфера законстрэйнен через CLOCK_DEDICATED_ROUTE. после ЭНДки полученный сигнал сразу вытаскивался на пин плисины и нигде внутри больше не использовался. но выход буфера был воспринят как клок и растащен дальше на память... С учетом предыдущего пункта тут уже напрашивается необходимость пересмотра структуры дизайна раз все так критично и приходиться ресурсы по сусекам скрести. Удачи! Rob. пересмотреть не получится - есть заданный кристалл и заданные алгоритмы, под которые нужно определенное количество памяти. кто-то несколько лет назад посчитал что памяти хватает. теперь приходится изворачиваться и архитектурно и алгоритмически - чтобы впихнуть невпихуемое... Для Spartan 6? 2-3 часа? Сурово. :blink: Что же Вы там такого намутили? Для уменьшения времени тут надо бы заняться абстрактной живописью в стиле Пикассо в PlanAhead - выделять блоки/модули дизайна и фиксировать их на кристалле. За 2-3 итерации существенно сокращает время сборки. Но кажется мне что это долгое "жжж" неспроста - обычно это показатель не оптимального дизайна с кучей потенциально критичных мест (по ресурсам или времянке). Удачи! Rob. ну 2-3 часа это он какраз пытается впихнуть невпихуемое. алгоритм же 3 или 4 раза стартует с нуля, в случае неудачи предыдущего шага. а если все в порядке, то разводка с учетом УЦФа минут за 10-15 проходит :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
