Поиск

Доброго времени суток всем участникам, Попытавшись разместить выходные регистры данных и управления OEN в ячейках ввода/вывода у Gowin GW2A (используется Gowin_V1.9.9Beta-1 и пробовал Gowin_V1.9.8.11) я столкнулся с рядом проблем: Отсутствуют констрейнты, которые бы позволяли на уровне исходника на Verilog говорить среде, что синтезируемый триггер (регистр) необходимо разместить во встроенном в ячейку ВВ триггере. В описании архитектуры GW2A приводится следующая иллюстрация: Но при этом в библиотеке примитивов отсутствуют соответствующие примитивы для OREG/TRIREG. Есть, правда ODDR, но к нему есть свои вопросы и о них ниже. Для режима SDR ниже приводится более детальная иллюстрация структуры ячейки: При этом для входов сброса есть следующее примечание: "Local set/reset signal O_SR and I_SR can be either synchronized reset, synchronized set, asynchronous reset, asynchronous set, or no-function;". Т.е. должны поддерживаться все возможные режимы сброса (вполне ожидаемо, на первый взгляд). Однако из-за отсутствия в библиотеке соответствующих примитивов на практике в этом убедиться затруднительно. При этом у приведенных в описании архитектуры триггеров для режима DDR вход сброса отсутствует. С другой стороны в документе "Gowin FPGA Primitive User Guide", где казалось бы должны были быть описаны указанные в описании архитектуры элементы (триггеры) есть только описание регистров DDR: Причём, что очень странно, в описании портов ODDRC, для входа CLEAR указана поддержка только асинхронного режима: После выполнения PnR с настройками размещения регистров в IOB в результатах бэканнотации (нетлист, генерируемый после PnR) у триггеров, которые я считал должны были быть размещены в ячейках ВВ, я вижу инстанцирование DFFR с очень подозрительным недокументированным аттрибутом: (*gowin_io_reg = "FALSE" *) DFFR ... Найти описание этого gowin_io_reg я нигде не смог, гугл про него не знает. Как можно проконтролировать, какие регистры попали в триггера ячеек ВВ, а какие нет? Ни в одном репорте этих данных нет. Собственно вопрос: какие есть варианты управления размещением триггеров для надежного их размещения в ячейках ВВ? Пока в голову приходит только один вариант: явно инстанцировать ODDRC в режиме SDR (подавать на оба входа один и тот же сигнал) и полагаться на него. Но это выглядит крайне кривой затеей, т.к. исходя из описания архитектуры должны быть возможности как минимум использовать синхронных сброс триггеров в ячейках ВВ. PS: Похоже, что та же проблема и с входными регистрами (триггерами). Однако с ними всё-таки немного проще и, надеюсь, решение для выходов будет вполне применимо и для входов. PPS: Выяснилось, что для размещения регистров управления третьим состоянием выходов в ячейках ВВ важна полярность. Т.е. если активный уровень сигнала управления будет 1, то между этим регистром и входом OEN на буфере ВВ синтезатор добавит инвертор и это не позволит PnR разместить соответствующий триггер в ячейке ВВ. Поэтому необходимо учитывать эту особенность и правильно выбирать активный уровень этих сигналов в проекте (должен быть active-low).

Всем привет! Имеется ПЛИС GW1NR-LV9QN88PC6/I5 (Tang Nano 9K). В документации от Gowin (SUG283-1.5E, 11/15/2018) указано наличие примитива BUFG: Я инстанцирую его в модуле верхнего уровня и в нетлисте после синтеза он ожидаемо присутствует. Однако в сгенерированном после pnr файле vo его нет. Нет его и в путях прохождения тактового сигнала Timing Analyzer. Т.е. складывается впечатление, что этот примитив BUFG на самом деле не существует на кристалле ПЛИС. Или я что-то делаю не так? Если использовать в качестве входов тактовых сигналов пины GCLKT, то проблем нет и ругани в PNR на эту тему тоже нет. Но мне интересен вариант использования глобального буфера, на вход которого сигнал подаётся не с выделенного пина, а с любого другого. Я понимаю, что это даёт дополнительную задержку, но в ряде случае это допустимо и может быть даже вполне оправдано. Получается, что такой вариант с Gowin невозможен?

Добрый день. Столкнулся с отрицательным значением для Tsetup в документации на ЦАП AD9117. (Tsetup = -0.2 нс, Thold = 1.5 нс) В связи с чем возник вопрос, как всё-таки правильно задавать constrain'ы для внешних сигналов. Для выходных интерфейсов временные ограничения я задаю следующим образом (если принять разницу во времени распространения клока и данных по плате = 0): set_output_delay -clock {clock_name} -man Tsetup {port_name} -add_delay. set_output_delay -clock {clock_name} -min -Thold {port_name} -add_delay. Соответственно для AD9117: set_output_delay -clock {clock_name} -man -0.2 {port_name} -add_delay. set_output_delay -clock {clock_name} -min -1.5 {port_name} -add_delay. Смущает отрицательное Tsetup, что говорит о том, что данные на входе микросхемы должны быть установлены после прихода фронта, до 0,2нс (но можно и раньше). Тем самым минимальное время на которое должны установиться данные = Tsetup + Thold = 1.3 нс. Или я неправильно понимаю трактовку этого значения, и производитель указывает время Tsetup относительно фронта клока (т.е. если оно отрицательное, это значит что данные должны установиться за 0.2 нс до прихода фронта клока.), и тогда минимальное время удержания данных на шине должно быть = 1.7 нс. Сталкивался кто-нибудь с отрицательным Tsetup, и как правильно в таком случае задавать set_output_delay?

Всем привет! Столкнулся со следующей проблемой: Vivado выдаёт предупреждения о том, что не может найти pins, cells, nets, прописанные в констрейнах, хотя оные объекты вроде на месте - это легко проверяется хоть через просмотр нетлиста, хоть через схематик, хоть через Tcl консоль, выдавая туда команды get_pins/get_cells/get_nets - ровно те, которые прописаны в констрейнах. Всё находится, всё на месте. Но при запуске, например, Synthesis, в окне Messages вижу: Интриги добавляет ещё то обстоятельство, что аналогичный констрейн на другой объект не вызывает такого поведения - там всё хорошо. Вот оба констрейна: create_generated_clock -name pcie_user_clk [get_pins pcie_port/pipe_clock_i/mmcm_i/CLKOUT2] create_generated_clock -name dpc_clk [get_pins dpc_clk_gen/inst/plle2_adv_inst/CLKOUT0] Это два простых констрейна для переименования клоков. Разница между ними в том, что первый относится к MMCM, находящейся внутри корки, а второй - к инстансу в проекте. Сам объект на месте (как уже выше указал), более того, по результату вижу, что клок-то таки переименовался (имеет указанное в констрейне имя). Вот оно на схеме (пин помечен маркером): В общем, заподозревал, что что-то тут, возможно, с порядком обработки данных - такое впечатление, что констрейн прикладывается в момент, когда ещё нетлист не готов и поэтому не находит объект (а в случае первого констрейна находит потому, что там в проект подтаскивается корка, синтезированная OOC, т.е. уже с нетлистом). Но если так, то как это разрулить? Никаких средств не нашёл, гугление тоже не помогло. Из-за этой же фигни не удаётся использовать waiver'ы - подобная ругань, что нет объектов (а они есть в результирующем нетлисте). В общем, обращаюсь к коллективному разуму и опыту.