Поиск
Показаны результаты для тегов 'gowin'.
-
Обнаружили с коллегами любопытный баг, когда писали код spi-slave устройства для GW2A. Для отладки код был упрощен до минимума и фактически превратился в одиночный триггер (см. картинку). RST, CLK, DIN – входные порты, на которых формируется сигнал, согласно временной диаграмме ниже. Для теста я формирую их с помощью другой отладочной платы с ПЛИС. DOUT – защелкнутый триггером сигнал DIN. MUST – то, что должно было быть защелкнуто на триггере. Если хотите пробовать повторить багу, то я оставлю оба кода источника и приемника под спойлером. Проблема выглядит следующим образом: После перезагрузки (power on/off) платы (или после перепрошивки ПЛИС) данные, которые приходятся на первый защелкивающий фронт триггера, не поступают на его выход (это событие помечено на временной диаграмме стрелкой 1-?->2). Все последующие защелкивания происходят корректно (например, стрелка 3-ok->4). Вот так эта проблема выглядит в GAO: Для всех, кроме первой, итераций схема функционирует корректно вплоть до выключения питания/перепрошивки. Чтобы исключить из рассмотрения GAO, выходной сигнал был выведен на пин и подключен к логическому анализатору вместе в входными RST и CLK. Картина оказалась аналогичной. Уточню, как выглядит схематик синтезированного кода, также посмотрим на то, какие ресурсы задействовал компилятор. Собирал я все на нескольких версиях софта. Самый последний тест был на Gowin EDA 1.9.9 (build 65859). Самый простой способ, который позволяет вернуть «адекватную» работоспособность триггеру, это проброс входного сигнала CLK на выходной пин (раскомментировать строчку "clk_la <= CLK" в коде). Совершенно непонятно по какой причине в этом случае баг пропадает. Чтобы докопаться до источника проблемы, было произведено множество манипуляций со схемой. Я уберу все их под спойлер, оставлю только самое важное. Решающим оказалось предположение копать в сторону работы glitch-free механизма DCS. Стоит отметить, что на репортах не задействуется ни DQCE, ни DCS. Что за DQCE и DCS под спойлером. Был добавлен блок DCS из доступных ip, в настройках которого можно управлять glitchless mode. После сборки получили такие результаты: glitchless mode = false -> работает нормально glitchless mode = true -> работает ненормально Самой показательной оказалась сборка с добавлением DCS в код так, чтобы можно было управлять glitchless mode со свича на плате. Если будете пробовать, код компонента под стойлером. В итоге, есть два вышеописанных способа решить проблему, если вы вдруг столкнетесь с таким поведением. Хоть и удалось локализовать проблему, но непонятно, почему прокидывание CLK на пин, не задействует glitch-free. Есть ли у кого какие мысли?
-
Доброго времени суток, уважаемые участники, Набрёл на IP Core Gowin USB 2.0 SoftPHY, которое позволяет (на первый взгляд) реализовать подключение шины USB 2.0 напрямую к ПЛИС Gowin (без использования специальных трансиверов): На первый взгляд ничего страшного, но далее следует указание настроек пинов ввода-вывода ПЛИС: usb_rxdn_i: IO_TYPE=LVDS25 PULL_MODE=NONE; usb_rxdp_i: IO_TYPE=LVDS25 PULL_MODE=NONE. При этом в даташите для дифференциальных входов определено максимально допустимое входное напряжение не более 2,15 В: При этом, нужно понимать, что для USB 2.0 Full-speed уровни на входе могут быть до 3,3 В включительно. Отсюда вопрос: как Gowin представляет себе надежную работу этого Soft PHY, если они выходят за заданные ими же допустимые пределы? Попутно возникает ещё один вопрос, касающийся двунаправленных пинов usb_dxp_io со стандартом "IO_TYPE= LVCMOS33D", которые внутри используют буферы типа ELVDS_IOBUF (Emulated LVDS). Является ли входной буфер Emulated LVDS дифференциальным приёмником сигнала, т.е. может ли он подавлять синфазную помеху на входах? У меня не было практики работы с подобными буферами, т.к. у Xilinx нет такого варианта настройки входных буферов. Однако у тех же Intel и Lattice вроде бы есть аналогичные входные буферы - есть ли у кого-нибудь опыт их применения и понимание, на сколько эффективно они работают с синфазными входными помехами?
-
Доброго времени суток всем участникам, В даташите на GW2A (DS102-2.6E) приведена следующая иллюстрация регистров ячейки ввода-вывода в режиме SDR: Т.е. выглядит всё так, как будто бы есть два независимых входа тактовых сигналов: O_CLK и I_CLK. При этом попытка упаковать в ячейку ввода-вывода двух триггеров, тактируемых различными тактовыми сигналами, приводит к выдаче ошибки на этапе PnR: ERROR (CT1094) : 'dut_inst/out_q2_0_s0' can't be placed according to constraint У кого-нибудь получилось упаковать два подобных триггера в одну ячейку? Или может быть есть место, где описана невозможность подобной упаковки?
-
Доброго времени суток всем участникам, Попытавшись разместить выходные регистры данных и управления 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).
-
Доброго всем времени суток! Пытаюсь понять, как у Gowin описать констрейнты для синхроного интерфейса, у которого выходные регистры для сигналов интерфейса тактируются от PLL, а тактовый сигнал для передаваемых данных генерируется с помощью ODDR. Суть задачи вполне типовая и хорошо описана, например, в документации на Альтеру: Констрейнты для тактового сигнала Альтера предлагает описывать так: create_clock -name input_clock -period 10.000 [get_ports clk_in] create_generated_clock -name common_clock -source \ [get_pins PLL|inclk[0]] [get_pins PLL|clk[0]] create_generated_clock -name output_clock -source \ [get_pins DDR|ddio_outa[0]|muxsel] [get_ports clk_out] Для Gowin это выглядит приблизительно так: create_clock -name sys_clk_i -period 20 -waveform {0 10} [get_ports {sys_clk_i}] create_generated_clock -name clk -source [get_ports {sys_clk_i}] -multiply_by 12 -divide_by 5 [get_pins {main_pll_inst/rpll_inst/CLKOUT}] create_generated_clock -name clk_o -source [get_pins {clk_oddr_inst/Q0}] -multiply_by 1 [get_pins {clk_o_obuf/O}] В результате Gowin ругается совершенно странным образом: ERROR (TA2004) : "constraints/timing.sdc":3 | Cannot get clock with name '' WARN (TA1052) : Generated clock is ignored Т.е. он должен был бы найти тактовый сигнал clk, но не находит ничего. Кто-нибудь имел опыт решения подобной задачи на Gowin?
-
Хочу предупредить любителей (таких как я, например) ставить элементы соответствующими примитивами, а не использовать IP Core Generator. В даташите на говиновскую память (в доступной мне версии UG285-1.3.4E, 11/01/2022 по крайней мере) использование Byte Enable нигде явно не оговорено. Лишь однажды, в режиме SDPB, когда порт А используется только для записи, byte_en появляется в адресе в инстансе примитива. Больше никаких упоминаний. В prim_sim.v (когда уже приходится туда лезть) мы увидим, что в любом режиме с шириной данных больше или равной 8 битам по порту записи, младшие биты адреса используются как Byte Enable соответственно количеству байтов. IP Core Generator сам подставляет в нужные биты перманентные единицы. Надеюсь, сэкономлю кому-нибудь время, которое сам безвозвратно потратил.
-
Всем привет! Имеется ПЛИС GW1NR-LV9QN88PC6/I5 (Tang Nano 9K). В документации от Gowin (SUG283-1.5E, 11/15/2018) указано наличие примитива BUFG: Я инстанцирую его в модуле верхнего уровня и в нетлисте после синтеза он ожидаемо присутствует. Однако в сгенерированном после pnr файле vo его нет. Нет его и в путях прохождения тактового сигнала Timing Analyzer. Т.е. складывается впечатление, что этот примитив BUFG на самом деле не существует на кристалле ПЛИС. Или я что-то делаю не так? Если использовать в качестве входов тактовых сигналов пины GCLKT, то проблем нет и ругани в PNR на эту тему тоже нет. Но мне интересен вариант использования глобального буфера, на вход которого сигнал подаётся не с выделенного пина, а с любого другого. Я понимаю, что это даёт дополнительную задержку, но в ряде случае это допустимо и может быть даже вполне оправдано. Получается, что такой вариант с Gowin невозможен?
-
Синхронизаторы и Gowin
makc опубликовал тема в Работаем с ПЛИС, области применения, выбор
Всем привет! Обнаружилась досадная особенность при синтезе совершенно элементарной конструкции синхронизатора для параллельной шины у Gowin: вместо пары регистров Gowin Synthesis для ПЛИС GW1N-UV9LQ100C6/I5 и других из этого семейства генерирует память и управляющий триггер. При этом, например, для GW1N-LV1LQ100C6/I5 этого не наблюдается. Вот как выглядит пример описания для повторения эксперимента:bus_sync.v RTL после синтеза выглядит красиво и вроде бы мы получили ровно то, что хотели и планировали: Но как бы не так. В нетлисте, генерируемом параллельной с красивой картинкой RTL всё выглядит уже не так безобидно: По сути генерируется память с организацией 2х8 и Т-триггер, который перебирает адрес этой памяти, имитируя поведение сдвигового регистра, которым и является синхронизатор. Всё бы ничего, но это не синхронизатор. Это подтверждает и отчёт об используемых ресурсах, получаемый после синтеза: Hierarchy Module Resource MODULE NAME REG NUMBER ALU NUMBER LUT NUMBER DSP NUMBER BSRAM NUMBER SSRAM NUMBER bus_sync (src/bus_sync.v) 1 - 1 - - 2 В котором SSRAM NUMBER равен двум, а триггеров только один вместо 16 и это само по себе уже наводит на нехорошие мысли, что что-то здесь не так. Поправьте меня, если я не прав да и вообще интересны ваши комментарии по теме синтезатора у Gowin. Я не хочу сказать, что это какая-то ошибка в синтезаторе. Формально он прав, т.к. принял решение сэкономить на триггерах и это неплохо. Но проблема в другом: в штатном асинхронном FIFO IP от Gowin именно через такие "псевдосинхронизаторы" передаются между тактовыми доменами счётчики, считающие в коде Грея. Соответственно из этого я делаю вывод, что разработчики забыли поставить атрибуты syn_srlstyle для этих синхронизаторов и тем самым совершили ошибку.
