Jump to content

    

kaktus

Участник
  • Content Count

    67
  • Joined

  • Last visited

Community Reputation

0 Обычный

About kaktus

  • Rank
    Участник
  • Birthday 09/06/1980

Информация

  • Город
    Санкт-Петербург

Recent Profile Visitors

1293 profile views
  1. Вот иллюстрация прикола с оптимизацией питания для BRAM. Появляются цепи с характерными названиями pwropt*, *cooolgate* , на ограничения по fanout забивает, времянки в итоге не сходятся.
  2. В итоге удалось утоптать проект в кристалл. В логику работы не вносилось никаких изменений. В процессе, еще работая над неполным проектом переползли на 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, а ждать когда он бросит эти попытки чтобы получить список проблемных цепей приходится иногда очень долго.
  3. Ларчик просто открывался. Оказалось, что напаяна флэшка N25Q512A, которая при всех прочих сходных характеристиках внутри состоит из 2х чипов по 32МБ, а не одного на 64МБ, как mt25qu512.
  4. Сохранил копию проекта с которым развлекался все это время в 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 Еще интересны результаты компиляции: сильно разное время при почти идентичной "утилизации"см. картинки
  5. Вот как-то так это выглядит : 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, может в этом дело...
  6. В соседней теме писал о проблемах с таймингами после увеличения заполнения, теперь новый сюрприз. Загрузочный файл mcs в максимальном варианте по количеству каналов обработки увеличился с 92 до 96 МБ и плис перестала грузиться с флэшки. Битовым файлом из которого сделан mcs при этом плис шьется нормально. Сама флэшка тоже шьется и проходит проверку. С файла mcs размером 65 МБ сделанного с меньшим числом каналов в этом же проекте днем ранее тоже грузится. Возможно это как-то связано с размером битового файла и рубежом в 32 МБ? SPIx4, 33MHz, Falling Edge, 1.8V, Compress bitstream, mt25qu512, xc085ku. Пробовал 12Мгц не помогло.
  7. Все это безобразие пока еще в одном SLR происходит, но от пересечений мне не уйти после возвращения полной набивки. Вас не затруднит указать мне путь к тайному знанию про лагуны и все что с ними связано? Пока нашел что-то об этом только в ug574, ug949.
  8. Столбец Loocation раздвинул на картинке в начале темы, но думаю следующие "веселые картинки" больше прояснят ситуацию. На картинках Тактовая, и Цепь в кристалле и схеме,на которой при задержке 2.103 и периоде 3.2 из-за разных путей тактовой Slack -0.3 И на этой тактовой должно висеть в 3 раза больше чем сейчас. Также оговорюсь, что триггеров по схеме вставлено довольно много.
  9. При довольно низком уровне загрузки кристалла проект перестал укладываться по времянкам. Львиная доля проекта работает от 2-х тактовых 155.52 и на ней же удвоенной 311.04, кое где данные пересаживаются с одной на другую. Из приведенных ниже картинок видно, что тактовые буферы практически не использованы, собственно в основном работают упомянутые 2 из них, при этом проблема вылезает из-за Clock Path Skew. У меня есть подозрение, что это можно вылечить используя хваленые "UltraScale Architecture Clocking Resources", распихав BUFG во все углы. Раньше проект разводился при заполнении около 60%, но после небольшого увеличения нагрузки на частоту 155 перестал: возникают связи между (SLR) двумя кристаллами из которых состоит ПЛИС с задержками по 15 нс, но это, видимо, проблема из другой оперы! При уменьшении количества каналов и соответственно загрузки до 15% разводится, на 20% начинает сыпаться с более высокой частоты, что в данный момент и представлено вашему вниманию. Отсюда вопросы: 1. Верно ли мое предположение про BUFG? 2. Если верно, то как это грамотно сделать, желательно не залезая в код. 3. Если не верно, то..... стратегии синтеза и разводки?...
  10. Понимаю, ответ немного не в тему, но меня смутила фраза "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;
  11. DxDesigner-Layout v.9.5 PINSWAP для LVDS

    Подскажите решается ли эта проблема: https://communities.mentor.com/thread/14438. Я с ней уже столкнулся, но что-то в сети не вижу решения. При Backward from PCB некоторые цепи, которые были сваплены отобразились на схеме, но большинство было проигнорировано с последующей формулировкой "Manually connect to old net".
  12. DxDesigner-Layout v.9.5 PINSWAP для LVDS

    Что-то я начинаю путаться. За 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 я отказался заниматься схемотой и делал только прошивки для ПЛИС, а сейчас просто приперло.
  13. DxDesigner-Layout v.9.5 PINSWAP для LVDS

    С той проблемой по 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 и мы не можем дальше работать, но отредактировать нельзя потому что равно), хорошо, что он делает архивы проекта и можно откатиться.
  14. Подскажите пожалуйста или направьте, где посмотреть. Задача: FPGA, банк с парой десятков LVDS пар - как правильно сделать символ(ы), чтобы при разводке пары можно было перекидывать, как это происходит с одиночными цепями по PINSWAP. Пробовал задать PINSWAP в стиле ([a+,a-],[b+,b-]), но Layout по-моему такого не понимает. UPD. Расширю вопрос: Возможно ли использовать PINSWAP в компонентах, состоящих из нескольких символов, объединенных через HETERO? Я наблюдаю корректную работу PINSWAP в 6-ти выводном элементе AND-3 между его входами, но попытка прописать эквивалентность для одного из банков FPGA не увенчалась успехом. Может PADS не задуман для таких сложных вещей?.. Другие версии PADS не предлагайте, лицензия есть только на эту.