kaktus

Прошивка грузится с флэшки, или есть какие-то другие источники загрузки?

Должен признаться, мы тут у себя внаглую (лично я не одобряю) подключаем QL 3.3В флэшки на 2.5В банк 14, просто ставя в цепи D00, D01 резисторы 100 Ом и норм. Работает. Но в Вашем случае, где разница 0.3В так сделать по-моему вполне допустимо, чтобы не морочитья с лишними преобразователями.

Пока вырисовывается картина: На банк 0 надо подать минимум 1.5V, ну так пусть он от 1.5 и работает вместе с JTAG (его на разъем тоже можно пустить через преобразователь уровня на всякий случай, т.к. есть загрузчики, которые 1.5 не переварят); CFGBVS подключаем на землю, что означает загрузку от 1.5V/1.8V; Банки, которые работают с памятью должны поддерживать 1.35V/1.5V и, очевидно, должен присутствовать механизм переключения. В писании (ug470) же сказано: The CFGBVS pin setting determines the I/O voltage support for bank 0 at all times, and for bank 14 and bank 15 during configuration. Впрочем это наверное актуально, если потом оно будет выше, чем на банке 0. Из выше сказанного напрашивается решение: загружаться при напряжении 1.5V (DDR3L от него ничуть плохо не будет, L как я понимаю - это возможность работать от 1.35, но не необходимость), затем переключать 14 и 15 на 1.35, если это нужно. Остается неприятность, что 0-й банк питается от отдельного питания, для сохранения возможности конфигурации по JTAG. Можно еще рассмотреть MT25QU на 1.8V, вместо QL. Возможно она сможет нормально работать с банками, запитанными от 1.5V без преобразователей уровня.

работало 1 раз

У меня в приложении запрашивает авторизацию и говорит, что Login Failed. Одновременно с тем же логином паролем запросто пускает в профиль на сайте.

Это опция была для автоматического подключения вывода на встроенную консоль. Можно использовать внешнюю программу терминалку типа putty. Можно вручную запустить встроенную из меню: Window - Show View - Other - Terminal

Вот иллюстрация прикола с оптимизацией питания для BRAM. Появляются цепи с характерными названиями pwropt*, *cooolgate* , на ограничения по fanout забивает, времянки в итоге не сходятся.

В итоге удалось утоптать проект в кристалл. В логику работы не вносилось никаких изменений. В процессе, еще работая над неполным проектом переползли на 2018.3. Просто открытый тройкой проект собрался раза в 2 быстрее. Если будет время попробую прогнать ради любопытства полный проект снова на 2018.2 с обретенными достижениями: Помог ситуации Multicycle Path на достаточно большой группе цепей. В какой-то момент свинью подкладывала BRAM power optimization. Выглядит на схематике это забавно: триггер, которому задан fanout 4 честно раздает сигнал 4-м друзьям, но к цепи подключается 5 дополнительная нагрузка, которая прорываясь дальше сквозь иерархию превращается в раскидистое дерево на ветвях которого времянка потом и не сходится. Отключение этой оптимизации глобально с помощью директивы в настройках implementation сразу дало результат: времянки на высокой частоте больше не рассыпались не смотря на дальнейшее добавление числа каналов с 50% до 100%. (https://www.xilinx.com/support/answers/56747.html) После чего проблема в основном переместилась в точки перехода с одной частоты на другую. Тут наибольшее положительное влияние оказал констрейн CLOCK_DELAY_GROUP, когда речь шла о пересадке данных с одной частоты на другую (кратную ей). Без него дело доходило до абсурда, когда из-за разных путей тактового сигнала от буферов, стоящих в соседних позициях не сходилась времянка для триггеров, стоящих в 2нс друг от друга при периоде в 3.2 нс. По мере добавления каналов Vivado, пока мог, запихивал все в один SLR, потом переместил существенную часть во второй. Кусок, который работает на высокой частоте, полностью лежит в нижнем. Переходы между SLR на частоте 155. Никаких лагун я не прописывал, ничего сам не флурпланил. LUT - 60%; FF - 25% Хорошо себя показала стратегия синтеза AlternateRoutability. С ней разводка прошла побыстрее и не понадобилось отключать BRAM power оптимизацию. Вопросы: 1. Сейчас обе частоты идут с одной MMCM с соседних буферов, выравниваются по фазе благодаря констрейну CLOCK_DELAY_GROUP. Что если раздавать по проекту высокую частоту, а уже по месту делить ее на BUFGCE_DIV? 2. Возможно ли остановить процесс route не дожидаясь его окончания или точнее посмотреть промежуточные результаты? Он после каждой очередной итерации пишет WNS, а ждать когда он бросит эти попытки чтобы получить список проблемных цепей приходится иногда очень долго.

Ларчик просто открывался. Оказалось, что напаяна флэшка N25Q512A, которая при всех прочих сходных характеристиках внутри состоит из 2х чипов по 32МБ, а не одного на 64МБ, как mt25qu512.

Сохранил копию проекта с которым развлекался все это время в vivado 2018.2, открыл в 2018.3, обновил IP ядра, никаких настроек не менял, нажал generate bitstream. 2018.2 размер bin : 34 138 780 ( > 32МБ) mcs: 96 024 192 (при этом меньше) По JTAG все шьется, но ПЛИС с флэшки не грузится 2018.3 размер bin : 33 307 596 ( < 32МБ) mcs: 96 686 283 (при этом больше) По JTAG все шьется, ПЛИС с флэшки грузится 32МБ = 2^25 = 33 554 432 Еще интересны результаты компиляции: сильно разное время при почти идентичной "утилизации"см. картинки

Вот как-то так это выглядит : set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design] set_property CONFIG_VOLTAGE 1.8 [current_design] set_property CFGBVS GND [current_design] set_property BITSTREAM.CONFIG.SPI_32BIT_ADDR YES [current_design] set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 4 [current_design] set_property CONFIG_MODE SPIx4 [current_design] set_property BITSTREAM.CONFIG.CONFIGRATE 33 [current_design] set_property BITSTREAM.CONFIG.SPI_FALL_EDGE YES [current_design] set_property BITSTREAM.CONFIG.CONFIGFALLBACK DISABLE [current_design] Стали смотреть какие получались файлы (bit) в разные времена. Бывали и больше 32 МБ. Но это первый большой файл сделанный в версии 2018.2, может в этом дело...

В соседней теме писал о проблемах с таймингами после увеличения заполнения, теперь новый сюрприз. Загрузочный файл mcs в максимальном варианте по количеству каналов обработки увеличился с 92 до 96 МБ и плис перестала грузиться с флэшки. Битовым файлом из которого сделан mcs при этом плис шьется нормально. Сама флэшка тоже шьется и проходит проверку. С файла mcs размером 65 МБ сделанного с меньшим числом каналов в этом же проекте днем ранее тоже грузится. Возможно это как-то связано с размером битового файла и рубежом в 32 МБ? SPIx4, 33MHz, Falling Edge, 1.8V, Compress bitstream, mt25qu512, xc085ku. Пробовал 12Мгц не помогло.

Все это безобразие пока еще в одном SLR происходит, но от пересечений мне не уйти после возвращения полной набивки. Вас не затруднит указать мне путь к тайному знанию про лагуны и все что с ними связано? Пока нашел что-то об этом только в ug574, ug949.

Столбец Loocation раздвинул на картинке в начале темы, но думаю следующие "веселые картинки" больше прояснят ситуацию. На картинках Тактовая, и Цепь в кристалле и схеме,на которой при задержке 2.103 и периоде 3.2 из-за разных путей тактовой Slack -0.3 И на этой тактовой должно висеть в 3 раза больше чем сейчас. Также оговорюсь, что триггеров по схеме вставлено довольно много.

При довольно низком уровне загрузки кристалла проект перестал укладываться по времянкам. Львиная доля проекта работает от 2-х тактовых 155.52 и на ней же удвоенной 311.04, кое где данные пересаживаются с одной на другую. Из приведенных ниже картинок видно, что тактовые буферы практически не использованы, собственно в основном работают упомянутые 2 из них, при этом проблема вылезает из-за Clock Path Skew. У меня есть подозрение, что это можно вылечить используя хваленые "UltraScale Architecture Clocking Resources", распихав BUFG во все углы. Раньше проект разводился при заполнении около 60%, но после небольшого увеличения нагрузки на частоту 155 перестал: возникают связи между (SLR) двумя кристаллами из которых состоит ПЛИС с задержками по 15 нс, но это, видимо, проблема из другой оперы! При уменьшении количества каналов и соответственно загрузки до 15% разводится, на 20% начинает сыпаться с более высокой частоты, что в данный момент и представлено вашему вниманию. Отсюда вопросы: 1. Верно ли мое предположение про BUFG? 2. Если верно, то как это грамотно сделать, желательно не залезая в код. 3. Если не верно, то..... стратегии синтеза и разводки?...