Перейти к содержанию
    

kaktus

Участник
  • Постов

    73
  • Зарегистрирован

  • Посещение

Весь контент kaktus


  1. Прошивка грузится с флэшки, или есть какие-то другие источники загрузки?
  2. Должен признаться, мы тут у себя внаглую (лично я не одобряю) подключаем QL 3.3В флэшки на 2.5В банк 14, просто ставя в цепи D00, D01 резисторы 100 Ом и норм. Работает. Но в Вашем случае, где разница 0.3В так сделать по-моему вполне допустимо, чтобы не морочитья с лишними преобразователями.
  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 без преобразователей уровня.
  4. У меня в приложении запрашивает авторизацию и говорит, что Login Failed. Одновременно с тем же логином паролем запросто пускает в профиль на сайте.
  5. Это опция была для автоматического подключения вывода на встроенную консоль. Можно использовать внешнюю программу терминалку типа putty. Можно вручную запустить встроенную из меню: Window - Show View - Other - Terminal
  6. Вот иллюстрация прикола с оптимизацией питания для BRAM. Появляются цепи с характерными названиями pwropt*, *cooolgate* , на ограничения по fanout забивает, времянки в итоге не сходятся.
  7. В итоге удалось утоптать проект в кристалл. В логику работы не вносилось никаких изменений. В процессе, еще работая над неполным проектом переползли на 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, а ждать когда он бросит эти попытки чтобы получить список проблемных цепей приходится иногда очень долго.
  8. Ларчик просто открывался. Оказалось, что напаяна флэшка N25Q512A, которая при всех прочих сходных характеристиках внутри состоит из 2х чипов по 32МБ, а не одного на 64МБ, как mt25qu512.
  9. Сохранил копию проекта с которым развлекался все это время в 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 Еще интересны результаты компиляции: сильно разное время при почти идентичной "утилизации"см. картинки
  10. Вот как-то так это выглядит : 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, может в этом дело...
  11. В соседней теме писал о проблемах с таймингами после увеличения заполнения, теперь новый сюрприз. Загрузочный файл mcs в максимальном варианте по количеству каналов обработки увеличился с 92 до 96 МБ и плис перестала грузиться с флэшки. Битовым файлом из которого сделан mcs при этом плис шьется нормально. Сама флэшка тоже шьется и проходит проверку. С файла mcs размером 65 МБ сделанного с меньшим числом каналов в этом же проекте днем ранее тоже грузится. Возможно это как-то связано с размером битового файла и рубежом в 32 МБ? SPIx4, 33MHz, Falling Edge, 1.8V, Compress bitstream, mt25qu512, xc085ku. Пробовал 12Мгц не помогло.
  12. Все это безобразие пока еще в одном SLR происходит, но от пересечений мне не уйти после возвращения полной набивки. Вас не затруднит указать мне путь к тайному знанию про лагуны и все что с ними связано? Пока нашел что-то об этом только в ug574, ug949.
  13. Столбец Loocation раздвинул на картинке в начале темы, но думаю следующие "веселые картинки" больше прояснят ситуацию. На картинках Тактовая, и Цепь в кристалле и схеме,на которой при задержке 2.103 и периоде 3.2 из-за разных путей тактовой Slack -0.3 И на этой тактовой должно висеть в 3 раза больше чем сейчас. Также оговорюсь, что триггеров по схеме вставлено довольно много.
  14. При довольно низком уровне загрузки кристалла проект перестал укладываться по времянкам. Львиная доля проекта работает от 2-х тактовых 155.52 и на ней же удвоенной 311.04, кое где данные пересаживаются с одной на другую. Из приведенных ниже картинок видно, что тактовые буферы практически не использованы, собственно в основном работают упомянутые 2 из них, при этом проблема вылезает из-за Clock Path Skew. У меня есть подозрение, что это можно вылечить используя хваленые "UltraScale Architecture Clocking Resources", распихав BUFG во все углы. Раньше проект разводился при заполнении около 60%, но после небольшого увеличения нагрузки на частоту 155 перестал: возникают связи между (SLR) двумя кристаллами из которых состоит ПЛИС с задержками по 15 нс, но это, видимо, проблема из другой оперы! При уменьшении количества каналов и соответственно загрузки до 15% разводится, на 20% начинает сыпаться с более высокой частоты, что в данный момент и представлено вашему вниманию. Отсюда вопросы: 1. Верно ли мое предположение про BUFG? 2. Если верно, то как это грамотно сделать, желательно не залезая в код. 3. Если не верно, то..... стратегии синтеза и разводки?...
  15. Понимаю, ответ немного не в тему, но меня смутила фраза "VHDL 2008 необходим для описания 8-и входового И". VHDL 2008 стараюсь избегать, чтобы не встречать сложностей, с которыми столкнулся автор темы, сам пишу в таких случаях вот так : вне процесса y <= '1' when (a="11111111") else '0'; в процессе это будет выглядеть так: if (a="11111111") then y<='1'; else y <= '0'; end if; По фэншую, наверное, следует написать так, что должно работать для вектора произвольной (разумной) длины: y <= '1' when (CONV_INTEGER(a) = 2**(a'length)-1) else '0'; Для неразумной длины entity AND_VECTOR is generic(LEN : integer := 8); port ( A : in std_logic_vector(LEN -1 downto 0); Y : out std_logic ); end AND_VECTOR; architecture AND_V of AND_VECTOR is begin process(A) begin Y<= '1'; for i in 0 to LEN -1 loop if A(i) = '0' then Y<= '0';end if; end loop; end process; end AND_V;
  16. Подскажите решается ли эта проблема: https://communities.mentor.com/thread/14438. Я с ней уже столкнулся, но что-то в сети не вижу решения. При Backward from PCB некоторые цепи, которые были сваплены отобразились на схеме, но большинство было проигнорировано с последующей формулировкой "Manually connect to old net".
  17. Что-то я начинаю путаться. За DxDesigner я взялся по нескольким причинам: 1. Как я понимаю именно PADS-Logic похоронен в версии 9.5 и в VX2.4 нас встречает DXD, хотя проект мой он так запросто не захотел открывать стал требовать центральную библиотеку и я пока не стал с этим заморачиваться. 2. DXD не привязан к PADS-Layout, можно выбрать тулз для разводки в т.ч. также имеющий место в конторе Allegro. 3. Большое количество наработок в PADS-Logic, которые конвертируются в DxD по крайней мере по части библиотек элементов. 4. Пить много я по жизни не могу и в моей ДМС нет психиатрической помощи, а PADS-Logic (понимаю, что это дело привычки), но меня очень быстро приводит в состояние истерики стилем редактирования, при котором 70% времени уходит на переключения между режимами "удалить"/"подвинуть"/"скопировать", про работу с шинами я вообще молчу. Как там с лицензиями устроено не знаю - они сетевые на всю контору. Так понимаю сколько-то раз из обновляли, так до версии 9.5 и добрались. Когда перешли с P-CADа на этот замечательный САПР, по причине из п.4 я отказался заниматься схемотой и делал только прошивки для ПЛИС, а сейчас просто приперло.
  18. С той проблемой по PiNSWAP о которой писал, я уже справился. Я всего лишь неправильно обновлял компонент в Layout. Проблема гораздо глубже, надеюсь, в нынешних версиях PADS дела обстоят лучше. Удручает то, то САПР 2012 года выпуска создает проблемы там, где P-CAD 2000 родом из прошлого тысячелетия нормально справлялся. Несмотря на многие достоинства ограничение в 255 символов на длину строки родом из бейсика или паскаля на тот же PINSWAP делает принципиально невозможным реализовать банальные вещи. Например, объединить несколько банков FPGA по 50 ног с одинаковым напряжением питания в один символ, чтобы свободно перебрасывать пины при разводке. И это FPGA ориентированный САПР, где говорится о поддержке VHDL, Modelsim и т.п. PADS-Logic, входящий в этот же PADS 9.5, имеющий P-CADоподобную таблицу для этих целей легко решает задачу PINSWAP на любое количество ног. Для LVDS пар придется снова прибегать к P-CADовскому опыту. Делается символ на пару +/- и далее (в DxD это даже проще) указываются номера соответствующих пинов и PARTS=n, как для обычного многогейтового элемента. На Layout пары свапятся как гейты. Ваш вариант с одновременным редактированием мне не очень подходит, т.к. у нас в конторе разводкой занимаются специально обученные люди, а моя задача сделать такую схему, чтобы на этапе разводки получать как можно меньше вопросов куда что можно переключить, какой ширины проводник, кого с кем выравнивать. По последнему вопросу при редактировании констрейнов мы с DxD также поставили друг друга в тупик в какой-то момент (1 оказывается не равно 1.0000 и мы не можем дальше работать, но отредактировать нельзя потому что равно), хорошо, что он делает архивы проекта и можно откатиться.
  19. Подскажите пожалуйста или направьте, где посмотреть. Задача: FPGA, банк с парой десятков LVDS пар - как правильно сделать символ(ы), чтобы при разводке пары можно было перекидывать, как это происходит с одиночными цепями по PINSWAP. Пробовал задать PINSWAP в стиле ([a+,a-],[b+,b-]), но Layout по-моему такого не понимает. UPD. Расширю вопрос: Возможно ли использовать PINSWAP в компонентах, состоящих из нескольких символов, объединенных через HETERO? Я наблюдаю корректную работу PINSWAP в 6-ти выводном элементе AND-3 между его входами, но попытка прописать эквивалентность для одного из банков FPGA не увенчалась успехом. Может PADS не задуман для таких сложных вещей?.. Другие версии PADS не предлагайте, лицензия есть только на эту.
  20. Столкнулся со следующей проблемой, которая проявляется на версиях 2017.3 и 2017.4 установленных на разных машинах: - Vivado при коррекции содержимого в окне IO Ports часто заявляет, что данный вывод уже занят другим сигналом. Если отказаться от замены, а затем прописать снова, то после нескольких попыток вывод нормально назначается; - В другой раз Vivado на этапе создания битстрима заявляет, что какие-то выводы не назначены и в IO Ports они действительно оказываются без привязки, при этом содержимое XDC файла не менялось, там они по прежнему прописаны. Пока не пропишешь их снова в IO Ports, их упоминание в XDC просто игнорируется. Кто-нибудь знает, как это лечится?
  21. На такой скорости мне кажется проще использовать обычные выводы ПЛИС. Вход организовать через CDR, выход прямо с ПЛИС. Тактировать выход той же тактовой взятой с CDR, но почищенной от джиттера с помощью внешней микросхемы. В свое время делал коммутатор для СТМ, который миксует данные с нескольких потоков СТМ, он же и тактовую раздает. Там у меня данные, которые я отдаю, стробируются от ПЛИСовой PLL, на которую приходят 155МГц с какого-то EXARа. А саму тактовую 155, сопровождающую данные, пришлось отдавать через ПЛИС просто от входа к выходам (так была плата разведена), минуя плисовую PLL, т.к. она только добавляла джиттер. Сама по себе ПЛИС Virtex-5 тактовую не испортила. Вроде до СТМ-16 там все так и работает.
  22. Если продолжить тему мультиплексоров, то стоит обратить внимание на xapp522 от Xilinx. Тут описано формирование оптимального мультиплексора для 6 и 7 семейств. Мне в свое время нужен был мультиплексор 16-1 (точнее 640 штук 640-1, которые я и собирал из 16-1) и именно оптимальная реализация из этого xapp помогла поднять проект, т.к. из простой записи на VHDL ISE его порождала не так компактно. https://www.xilinx.com/support/documentatio...-techniques.pdf
  23. У меня рядом с дистрибутивом лежат вот эти файлы, которыми следует заманить оригинальные. Точно не помню от какой беды они помогают, от падения map, или xst, но помню, что с падением map тоже как-то боролся. Попробуйте заменить свои, сохранив на всякий оригинальные. DS_14_7_patch.ZIP
×
×
  • Создать...