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

ig_f

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

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

  • Посещение

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


  1. Пока путем релокейта прослаканых регистров в соседний LAB удалосьизбавиться от красных надписей. Понадобилось 5-6 перестановок: локейтишь один, появляется новый) Благо всего пара регистров со слаками было... Но смущает то, что в списке осталось много регистров со положительным слаком, но небольшим 5 - 20 пс. И при этом по сетапу у них около 12 нс, т.е. огромный запас. Было бы хорошо подкорректировать, но не вручную же их таскать по чипу? Попробую воспользоваться Ваши советом не очень понял, о какой детализации идет речь?
  2. Это генерённая fifo из визарда не представляю как туда чего-то добавить. Можно наверно только регистр этот попробовать в другой лаб поместить... Вот посмотрел сетап для этого пути. Т.е. там дисбаланс чудовищный в пользу сетапа. ПОчему то квартус не смог это разрулить
  3. Да, я имел ввиду многослойную логику. Но счас глянул конкретное место с самым большим слаком, и там всего один LUT в той же ячейке... При этом они в одном LABе. Слак по холду. На картинке прослаканый путь
  4. В общем проблема решена, частично. Может кому-то будет полезно. Проблема была в длинных интерконнект путях, которые квартус добавлял вместе с моей накруткой фазы в PLL. Отключил в настройках фиттера функцию Optimize Hold Timinng, после этого фиттер стал более послушным, перестал накидывать эти задержки, и вместе с локейтом регистров это дало результат - по входным данным слаки удалось устранить, приемник заработал как надо. Правда, еще есть слаки в длинных комбинационных путях fifo, которая стоит после lvds приемников... Я пока-что забил на это, там максимальная величина слакп 0.029 нс. Но в дальнейшем хотелось бы устранить. Может посоветуете по-крупному методологию, как с этим можно бороться?
  5. Добрый день! В проекте есть приемник CSI2 на частоте на частоте 300 МГц, 600 Мбит/с в режиме ДДР соответственно. Для приема используется блок altlvds_rx c десериализацией 8. Входной клок заведен на отдельную PLL, и c[0] используется чтобы латчить входные данные. Данные center-aligned, задержки прописаны по методичке ddr-timing-cookbook. В PLL ставлю нулевую задержку. Собираю, смотрю тайминги Слак по setup. Напрашивается добавить фазы в PLL. Добавляю 90гр и смотрю опять Фаза накрутилась, но квартус зачем-то навалил и задержки по данным. Сперва решил, что он куда-то регистры разместил далеко, залокейтил их как в первой сборке, но оказалось он впихнул на вход комбинационную логику которая делает DOUT = DIN и тупо добавляет задержки данных. Ставил 120гр фазы, квартус уменьшает задержку комбинационной логики, фазы PLL хватает чтоб слак по setup убрать, но теперь надо бороться с холдом... ок, вижу что там нужно вписать теперь мультицикл, так как фронт вылез за launch, вписываю, собираю - он опять увеличил комбинационную задержку так что и по сетапу прослакано... Можно ли сделать так, чтобы квартус не довавлял/убавлял по свой прихоти эту комбинационную логику пустую? Или я что то не так трактую? Вот таблицы DataPath из репорта до и после добавления мультицикла. +3.5 нс на ровном месте Я не специалист по заданию ограничений но может как-то это решается? Если нет, то каким путем нужно идти, чтобы добиться сходимости таймингов? PS Проект достался по наследству, он как-то работал в железе до тех пор пока не потребовалось сделать пару изменений. После сборки данные перестали приниматься. Оказалось нет входных констрейнов. Я немного слышал о ПЛИС и решил, что смогу быстренько подчинить, а он как уж на сковороде
  6. Здравствуйте! Хочется поднять CSI-2 на Lattice CrossLink. Подскажите, имея free license можно будет пользоваться ядром (синтезировать, отмоделировать, зашить в железку)? Никаких подводных камней в бесплатном софте не будет? (ранее с Lattice не работал)
  7. Такой вариант проверялся изначально, он работает, но не подходит идеологически: мне нужно проинициализировать память в нескольких однотипных модулях создаваемых через generate, при предложенном подходе придется создавать кучу mif c различными именами + при моделировании в modelsim память остается непроинициализированной. Поэтому решено было парсить mif и инициализировать внутри архитектуры. Ещё из недостатков: хочется, чтобы при малой глубине ROM (например меньше 16) она выполнялась на LUTах; ram_init_file жестко цепляет блочную память.
  8. Так и делаю, этот модуль задаю как топ файл. В месседж информации ноль Info (12127): Elaborating entity "tst_rom" for the top level hierarchy Warning (13024): Output pins are stuck at VCC or GND Warning (13410): Pin "data[0]" is stuck at GND Warning (13410): Pin "data[1]" is stuck at GND Warning (13410): Pin "data[2]" is stuck at GND Warning (13410): Pin "data[3]" is stuck at GND Warning (13410): Pin "data[4]" is stuck at GND Warning (13410): Pin "data[5]" is stuck at GND Warning (13410): Pin "data[6]" is stuck at GND Warning (13410): Pin "data[7]" is stuck at GND Warning (13410): Pin "data[8]" is stuck at GND Warning (13410): Pin "data[9]" is stuck at GND Warning (13410): Pin "data[10]" is stuck at GND Warning (13410): Pin "data[11]" is stuck at GND Warning (13410): Pin "data[12]" is stuck at GND Warning (13410): Pin "data[13]" is stuck at GND Warning (13410): Pin "data[14]" is stuck at GND Warning (13410): Pin "data[15]" is stuck at GND Info (16010): Generating hard_block partition "hard_block:auto_generated_inst" Info (16011): Adding 0 node(s), including 0 DDIO, 0 PLL, 0 transceiver and 0 LCELL Warning (21074): Design contains 5 input pin(s) that do not drive logic Warning (15610): No output dependent on input pin "clk" Warning (15610): No output dependent on input pin "addr[0]" Warning (15610): No output dependent on input pin "addr[1]" Warning (15610): No output dependent on input pin "addr[2]" Warning (15610): No output dependent on input pin "addr[3]" Info (21057): Implemented 21 device resources after synthesis - the final resource count might be different Info (21058): Implemented 5 input pins Info (21059): Implemented 16 output pins Info: Quartus Prime Analysis & Synthesis was successful. 0 errors, 23 warnings
  9. Всем доброго времени суток! Столкнулся с проблемой при синтезе ROM, инициализированного из текстового файла. Для инициализации использовал пару функций которые работают с textio и std_logic_textio и вычитывают нужные строки из mif-файла. После синтеза Quartus выбрасывает всю внутреннюю логику и притягивает выходы к нулям. Пробовал сперва играться с настройками синтеза касательно ROM, потом и RAM, но результата не добился. При инициализации памяти массивом прямо из кода модуль синтезируется правильно, на настройки синтеза реагирует (вставляет блоки или логику по настройкам). Кривые функции чтения из файла скажите вы... но они отлично работают в Modelsim, и даже автоматически распознаются как логика или как блочная память в зависимости от размера ROM. Уверен что многие здесь инициализировали память из файлов. В общем буду признателен за любую помощь в задании настроек синтеза, поиске косяков в инициализации памяти или указании на иные причуды квартуса. Код тестового модуля прикрепляю. З.Ы. Quartus 17.0 Standard. library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; --use work.fir_gen_pkg.all; use ieee.std_logic_textio.hread; use std.textio.all; entity tst_rom is generic ( COEF_WIDTH : integer := 16; C_OFFSET : integer := 16; C_NUMBER : integer := 16; FILENAME : string := "TEST_FILE.mif" ); port ( clk : in std_logic; data : out std_logic_vector(COEF_WIDTH - 1 downto 0); addr : in natural range 0 to C_NUMBER - 1 ); end entity; architecture beh of tst_rom is type memory_t is array (0 to C_NUMBER - 1) of std_logic_vector(COEF_WIDTH - 1 downto 0); impure function read_mif_line( FILENAME : in string; C_OFFSET : in integer; COEF_WIDTH : in integer ) return std_logic_vector is file mif: text is FILENAME; constant CONTENTBEGIN : string := "CONTENT BEGIN"; -- variables variable mifLine : line; variable mifMess : string(1 to 80); variable addr : integer; variable char : character; variable data : std_logic_vector(COEF_WIDTH - 1 downto 0); begin for i in 0 to 2047 loop readline(mif, mifLine); read(mifLine, mifMess(1 to mifLine'length)); exit when (mifMess(1 to 13) = CONTENTBEGIN); end loop; for i in 0 to C_OFFSET - 1 loop readline(mif, mifLine); end loop; readline(mif, mifLine); read(mifLine, addr); assert addr = C_OFFSET report "Line address value does'n match input offset." severity Warning; for i in 0 to 79 loop read(mifLine, char); exit when (char = ':'); end loop; hread(mifLine, data); file_close(mif); return data; end read_mif_line; impure function mem_init return memory_t is variable tmp : memory_t;-- := (others => (others => '0')); begin for i in 0 to C_NUMBER - 1 loop tmp(i) := read_mif_line(FILENAME, C_OFFSET + i, COEF_WIDTH); end loop; return tmp; end mem_init; constant rom : memory_t := mem_init; --constant rom : memory_t := (0 => x"F020", -- 1 => x"001F", -- 2 => x"E01E", -- 3 => x"001D", -- 4 => x"DD1C", -- 5 => x"001B", -- 6 => x"001A", -- 7 => x"1019", -- 8 => x"FF18", -- 9 => x"0017", -- 10 => x"5016", -- 11 => x"0015", -- 12 => x"2314", -- 13 => x"0013", -- 14 => x"5A12", -- 15 => x"0011"); begin process(clk) begin if rising_edge(clk) then data <= rom(addr); end if; end process; end beh;
  10. А как на счет PCIe, DMA, GigETH? В Vivado WebPACK они доступны?
  11. Доброго времени суток! Есть система с NIOS II и UART'том. Хочется эту систему помоделировать в Modelsim. Есть старый AN189 Simulating Nios Embedded Processor Designs, в котором говориться, что можно при моделировании в интерактивном режиме общаться с UART через виртуальный терминал. В старых версиях SOPC builer терминалы запускались с через макросы в .do файле, а в системах генереруемых Qsys такого файла нет. Но при этом в настройках UART галки на вызов окон терминалов можно поставить. Так вот вопрос: как теперь вызвать эти терминалы?
  12. Спасибо, кажется разобрался. Выкинул clkctrl блоки и запустил сигналы на PLL с пинов напрямую. Из картинок понял, что в циклоне есть для этого специальные линии, а clkctrl были лишними. Квартус не ругается.
  13. Доброго времени суток! В Cyclone III используется PLL, выход C0 выводится наружу через CLKCTRL BLOCK, C1 используется для тактирования внутри ПЛИС. Дело в том, что на PLL подаются две частоты: одна от тактового генератора и от внешнего устройства. Т.е. PLL переключается между двумя частотами. Оба этих сигнала заведены на PLL через CLKCTRL BLOCK'и. При выполнении Assignment Analysis квартус выдает следующее: Error (176399): Following nodes use the same resource DEDICATED_BUF_X40_Y52_N0_I0 Error (176404): Node "GCLK120~input" is currently placed at location PIN G21 (CLK4, DIFFCLK_2p) with a Global Signal type of Global Clock Error (176405): Node drives Clock Control Block dm_device_clockmanager:clockmanager_inst|dm_device_clk2gclk:clk0_2_gclk|dm_devic e_clk2gclk_altclkctrl_uhi:dm_device_clk2gclk_altclkctrl_uhi_component|clkctrl1 Error (176404): Node "GTXCLK_pxi~input" is currently placed at location PIN B11 (CLK11, DIFFCLK_4p) with a Global Signal type of Global Clock Error (176405): Node drives Clock Control Block dm_device_clockmanager:clockmanager_inst|dm_device_clk2gclk:clk1_2_gclk|dm_devic e_clk2gclk_altclkctrl_uhi:dm_device_clk2gclk_altclkctrl_uhi_component|clkctrl1 Насколько я понял квартус решил запустить обе тактовых на один и тот же CLKCTRL BLOCK. Почему так произошло? Их же там 5шт. с каждой стороны, в проекте всего 4шт. используется Как побороть эту проблему? И еще пара вопросов возникла по-ходу. Можно ли использовать PLL для вывода тактовой наружу, если используется переключение между двумя частотами? Не критично ли то, что одна из тактовых, подаваемых на PLL, подается с "чужого" dedicated-пина (т.е входные пины находятся один на верхней, другой на боковой стороне микросхемы)?
  14. Спасибо, что пояснили суть проблемы. В общем буду допиливать проект, а потом смотреть на тайминги и отчеты place and route. Если не сойдутся тогда буду смотреть на вариант с защелкиванием по заднему фронту. А как можно проверить тайминги раньше, чем весь проект будет готов? Что-то в моем хэндбуке на этих страницах совсем о другом написано и вообще нет таких разделов... может версии разные PS Нашлось в другой главе с другим названием. В целом я так и сделал, как там описано.
  15. Теперь понял. Сперва подумал, что предлагают чтоб автомат постоянно щелкал на 120 МГц. Думаю можно поправить автомат, добавить в него разрешающих сигналов. Наверное такое будет более красивым. А вообще мне казалось, что gated clok это когда сигнал тактовой смешивается с некоторыми управляющими сигналами через комбинационную логику. В моем случае я формирую сигнал довольно низкой частоты с помощью восьмиразрядного счетчика и компаратора который формирует сигнал разрешения для T-триггера, на тактовый вход которого подается 120 МГц. То есть моменты переключения вполне детерминированы и связаны с основной тактовой. Далее выход триггера заводится на Clock Control Block и поступает на GCLK. В описании Clock Control Block такая схема тактирования подразумевается. Мне она видется вполне безопасной на частоте 400 КГц, разве нет?. Ни в коем разе не спорю, что предложенное вами решении выглядит лучше и порождает меньше проблем, как для меня, так и для САПРа. Просто хочу узнать возможно ли в принципе использовать такое тактирование?
  16. Ненароком не оскорбили - я не волшебник, а только учусь . Пока отношу себя к дилетантам :) Нет никакой проблемы поставить лишние пару триггеров. И, наверно, это было бы самым простым решением проблемы. В этом проекте не важно: есть этот синхронизатор или нет. А в каком-нибудь другом этот момент может оказаться критическим. Поэтому хочется все-таки разобраться. Изначально автомат задумывался на основной частоте 120 МГц, но, во-первых ему ни к чему такая скорость обработки т.к. его входные сигналы медленные, во вторых у него достаточно долгие периоды выжидания переходов в следующие состояние, что на частоте 120 МГц выливается в длинющие счетчики. Поэтому было решено скинуть его на низкую частоту. В принципе можно попробовать работать на 120 МГц, но пугают LUTы в управляющем автомате, нагроможденные в четыре этажа(может зря пугают?). Сигналы выдаваемые автоматом не стробируют никаких данных, а лишь дают разрешение на запуск, остановку работы и т. п. В альтеровских руководствах сказано, что если клоки завязанные, то их можно считать синхронными и, соответственно, можно обойтись без синхронизатора. Поэтому вариант, который предложил уважаемый SM мне кажется более естественным для решения данной задачи. Начинаю понимать, что мой вопрос возник из-за недостаточного знакомства с Timing Analysis и задания констрейнов :rolleyes: . И как тут прилепить цитирование со ссылкой на автора, а не просто "Цитата"?
  17. Доброго времени суток! Есть управляющий автомат работающий на частоте 400 кГц и есть логика обработки данных работающая на частоте 120 МГц. Соответственно автомат управления посылает различные сигналы в остальную логику. Частота 400 кГц формируется из основной частоты 120 МГц (без использования PLL, с помощью обыкновенного счетчика), т.е. клоки в общем-то связанные. Вопросы: 1) Правильно ли я мыслю, что в моем случае можно обойтись без синхронизаторов(тех самых, что используются для борьбы с метастабильностью)? 2) Если так, то что для этого нужно сделать? Заранее спасибо! ps Cyclone III
  18. Доброго времени суток! Тема немного запылилась, но хотелось бы узнать к каким выводам пришел автор. Тоже ковыряю PDN tool. Очень интересует вопрос, как быть с импульсным источником питания? Ведь набор развязывающих конденсаторов по сути меняет емкость выходного фильтра, соответственно изменяются параметры контура обратной связи... Как учитывать выходной фильтр в PDN tool? Была мысль игнорировать источник в PDN tool и обеспечивать развязку конденсаторами от частот на которых фильтр имеет импеданс выше целевого(то есть практически немного выше резонансной частоты), но опять таки остается нерешенной проблема - нагрузка конденсаторами меняет характеристики фильтра.
  19. благодарю. просмотрел одним глазом пока, но думаю это то, что надо буду разбираться да были и такие мысли, и насчет DDR регистра подумывал, но это через обычный вывод - джиттер хуже чем через PLL_CLKOUT, поэтому решил с выхода PLL тактировать
  20. Здравствуйте! Имеется проект, в котором параллельные данные(16 каналов) с плис Cyclon III передаются микросхеме SERDES, попутно с ними клок 125 МГц, сдвинутый на 180 градусов. Хотелось бы передавать клок с PLL через вывод PLL_CLKOUT. Пока не могу понять в каком режиме при этом должен работать PLL и как добиться нужного сдвига фаз между данными и тактовой. Была мысль сделать так: внутренности плис тактировать с выхода с1 PLL, наружу подавать сигнал c выхода с0, при этом задать в настройках PLL сдвиг на 180 градусов. Как при этом дело будет обстоять с задержками между выходным клоком, с1 и соответственно данными? Опыта работы с PLL мало, выравнивание задержек тоже толком не занимался, так что подскажите общие принципы, в какую сторону смотреть, где прочесть, а там думаю сорентируюсь :rolleyes:
  21. Спасибо за ответ. Значит можно подать питание одновременно. Решил посмотреть по-поводу clamp-диодов и вспомнил, что попадался как-то на глаза гидлайн для EPCS: AN 523: Cyclone III Devices Configuration Interface Guidelines with EPCS Devices. На первой же страницы написано: The EPCS device operates at 3.3 V or 3.0 V. When the AS configuration scheme is selected, I/O bank 1 of Cyclone III family devices allows I/O voltages of 3.3, 3.0, or 2.5 V. You can operate Cyclone III family devices I/O bank 1 and the EPCS device at any combinations of the allowable operating voltages. .... When the I/O voltage for Cyclone III family devices AS configuration signals is determined, select the right AS configuration MSEL settings based on the selected I/O voltage level. Значит должно взлететь
  22. День добрый! Не удалось найти внятного ответа на следующие вопросы. Подскажите пройдет ли конфигурация плис Cyclon III от EPCS (запитывается 3.3 В) в режиме AS, если напряжение питания банка с конфигурационными пинами (DATA, DCLK, ASDO, nCSO) 2.5 В? В MSEL выбран режим AS 2.5/3.0V. Другой вопрос: в какой последовательности должно подаваться питание на ПЛИС(VCCIO, VCCINT, VCCA и др. в том числе питание EPCS)?
  23. Благодарю, буду разбираться
  24. Здравствуйте! Я не большой специалист в технической электродинамике и тем более в HFSS. Но есть задача и ее нужно решить. Есть частотно-селективная поверхность (теоретически рассчитаны размеры печатных элементов и толщина подложки), задача которую она должна выполнять: подавление поверхностной волны, энергия должна направляться по нормали к поверхности. Необходимо сообразить модель и убедится что поверхностная волна в слое не распространяется, количественно оценить ослабление. До этого с HFSS не работал, пару дней перечитал всяких Банковых/Курушиных, научился чертить, определять границы, назначать порты... вообщем кой какие мало-мальские основы. Когда дело дошло до собственной модели - заступорился. Примеры решения задач с ЧСП найти не удалось. Не могу понять какой должна быть модель: 1) это должна быть модель с периодическими граничными условиями (Master/Slave), или же модель с множеством элементов? 2) какое нужно задать воздействие на структуру? 3) какие параметры, характеристик, диаграммы выводить в отчет, чтобы убедится, что поверхностных волн не возникает или оценить их величину? Вообщем ткните носом в каком направлении двигаться :)
×
×
  • Создать...