Search the Community

Доброго всем времени суток! Пытаюсь понять, как у 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?

Доброго времени суток всем участникам, Попытавшись разместить выходные регистры данных и управления 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 Analyzer Oscilloscope с Tang Nano 9K или каким-либо другим нестандартным кабелем USB<=>JTAG? На плате Tang Nano стоит не родной преобразователь, а его эмуляция на BL702: Bus 001 Device 009: ID 0403:6010 Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6010 FT2232C/D/H Dual UART/FIFO IC bcdDevice 5.00 iManufacturer 1 SIPEED iProduct 2 JTAG Debugger iSerial 3 FactoryAIOT Pro bNumConfigurations 1 Через openFPGALoader плата определяется и программируется, т.е. сам по себе преобразователь рабочий. Но среды Gowin Programmer и Gowin Analyzer Oscilloscope его признавать не хотят. Судя по онлайн-помощи из утилиты programmer_cli поддерживается несколько вариантов кабелей: --cable "Gowin USB Cable(FT2CH)" Select a type of USB cable(including quotation marks): "Gowin USB Cable(GWU2X)" "Gowin USB Cable(FT2CH)" "Parallel Port(LPT)" "Digilent USB Device" "USB Debugger A" Default cable is "Gowin USB Cable(FT2CH)" --cable-index <int> Select a number for USB cable: 0: Gowin USB Cable(GWU2X); 1: Gowin USB Cable(FT2CH); 2: Parallel Port(LPT); 3: Digilent USB Device; 4: USB Debugger A; Higher priority than --cable, default cable-index is 0 Но перебор их ничего не дал, т.к. в лучшем случае я получаю сообщение "Unknown Cable" и дальше дело не идёт. Есть какие-нибудь варианты заставить работать Gowin Analyzer Oscilloscope с нестандартными кабелями?

Здравствуйте. Кто-нибудь делал для Gowin обновление конфигурации по JTAG с микроконтроллера ? Что-то описание у них мутное какое-то. В описании одно пишут. Создал SVF файл - так как-то иначе все выходит. У меня пока что получилось только ID и регистр статуса прочитать. Теперь бьюсь со стиранием - никак не выходит.

Доброго всем времени суток! При реализации механизма программирования внутренней флеш-памяти ПЛИС GW1N-9C через JTAG на GPIO МК внезапно выяснилось, что данные в Y-страницы флеш-памяти (4 байта) необходимо писать в перевёрнутом виде, т.е. младший по смешению из bin-файла байт (например, по смещению 0) пишется по смещению старшего байта (т.е. по смещению 3) и так далее. При этом, что интересно, в генерируемом средой Gowin Programmer SVF-файле этого переворота нет, судя по моим наблюдениям. Соответственно если использовать SVF без модификаций, то КМК прошить им ПЛИС не получится. Может быть кто-то пробовал и готов поделиться результатом? В документации от Gowin на этот счёт путаница: они пишут про программирование Y-страницы начиная с LSB, говоря о битах, но на самом деле LSB - это младший байт. При этом в проекте openFPGALoader (файл src/gowin.cpp) также присутствует переворот (tx[3-x] = t[x]), что подтверждает мою гипотезу: for (int ypage = 0; ypage < nb_iter; ypage++) { unsigned char *t = buffer+xoffset + 4*ypage; for (int x=0; x < 4; x++) { if (page == 0) tx[3-x] = t[x]; else tx[x] = t[x]; } _jtag->shiftDR(tx, NULL, 32); if (!is_gw1n1) _jtag->toggleClk(40); } Условие page == 0 соответствует программированию конфигурации ПЛИС. При прошивке пользовательской области флеша переворот байт не выполняется. В любом случае после добавления аналогичного кода перестановки байт в слове Y-страницы прошивка успешно стартовала и ПЛИС работает как было задумано. PS: В руководстве от Gowin процедура верификации внутреннего флеша после программирования также описана некорректно. Для её лучшего понимания советую посмотреть на генерируемый средой SVF-файл.

Хочу предупредить любителей (таких как я, например) ставить элементы соответствующими примитивами, а не использовать IP Core Generator. В даташите на говиновскую память (в доступной мне версии UG285-1.3.4E, 11/01/2022 по крайней мере) использование Byte Enable нигде явно не оговорено. Лишь однажды, в режиме SDPB, когда порт А используется только для записи, byte_en появляется в адресе в инстансе примитива. Больше никаких упоминаний. В prim_sim.v (когда уже приходится туда лезть) мы увидим, что в любом режиме с шириной данных больше или равной 8 битам по порту записи, младшие биты адреса используются как Byte Enable соответственно количеству байтов. IP Core Generator сам подставляет в нужные биты перманентные единицы. Надеюсь, сэкономлю кому-нибудь время, которое сам безвозвратно потратил.

Приветствую, господа. Может, есть какие-то апноты по созданию приёмника на основе IODELAY + IEM + IDES? Вроде бы чувствую, что с помощью IEM можно отказаться от битовой тренировочной последовательности, но дальше своих чувств и предположений продвинуться не могу. Кто-нибудь работал с модулем IEM? Где можно найти хоть какое-нибудь описание, кроме состава портов?

Добрый день, Дано: Gowin_V1.9.8.08 и programmer_cli из этого набора; Кабель на базе FT2232H, у которого для подключения JTAG задействован канал B. Кабель успешно определяется средой: $ sudo ./programmer_cli --scan-cables Cable found: Gowin USB Cable(FT2CH)/0/5873/null (USB location:5873) Cable found: Gowin USB Cable(FT2CH)/1/5874/null (USB location:5874) Cost 0.11 second(s) При этом все попытки работать со вторым каналом с помощью параметра --channel 1 эффекта не дают, хотя по описанию и по выдаче выбирается именно второй канал - B (немного смущает надпись null на конце выдачи в имени кабеля): $ sudo ./programmer_cli --channel 1 --scan Scanning! Target Cable: Gowin USB Cable(FT2CH)/1/0/[email protected] Error: No Gowin devices found! Cost 0.54 second(s) При этом если выбирать порт кабеля с помощью параметра --location 5874, то сканирование успешно выполняется и программатор работает как обычно (несмотря на совершенно кривую выдачу): $ sudo ./programmer_cli --location 5874 --scan Scanning! Target Cable: Gowin USB Cable(FT2CH)/0/0/[email protected] Device Info: Family: GW1NR Name: GW1N-9C GW1NR-9C (One of them) ID: 0x1100481B 1 device(s) found! Cost 1.04 second(s) Я что-то упускаю при использовании параметра --channel 1? Или это всё-таки проблема (ошибка) программатора? PS: Перейти на использование канала A сейчас возможности нет. PPS: Проблем бы не было, если бы не постоянно мутирующие значения location, которые ожидаемым образом изменяются от подключения к подключению кабеля, что доставляет массу неудобств.

Имею на руках означенный родной программатор. Вопрос: его работоспособность можно как-нибудь проверить, не имея на руках (пока) ничего, роме как кита DK_START_GW2AR-LV18EQ144PC8I7_V1.1, которому внешний программатор как собаке пятая нога, т.к. имеется такой же на борту? Смысл пробы - сотворить простейший переходник с него на эфовский (начало не помню, но оканчивается на Iso) от @StewartLittle под разводку последнего, дабы к приходу смонтированных плат хоть один вариант того, что не прошивается (ежели таковой казус и произойдёт), был бы мог смело быть отметённым.

Всем привет! Пытаюсь запрограммировать встроенную в ПЛИС флешку на Tang Nano 9K из командной строки с верификацией: gw_programmer_cli --device GW1NR-9C --fs firmware.fs -r 6 Target Cable: Gowin USB Cable(FT2CH)/0/0/null Operation "embFlash Erase,Program,Verify" is starting on device-1... Erasing embFlash ...: [#########################] 100% Programming...: [#########################] 100% Verifying...: [ ] 0% Error: Verify Failed at 0 Verifying...: [#########################] 100% Error: Verify Failed! Cost 12.59 second(s) И ещё ни разу не было такого, чтобы верификация прошла. При этом простое программирование без верификации проходит "на ура". Программатор (программа) из комплекта Gowin_V1.9.8.06-1. Уважаемые участники, как вы решаете (если решаете) вопрос с верификацией прошивки после программирования?

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

Всем привет! Обнаружилась досадная особенность при синтезе совершенно элементарной конструкции синхронизатора для параллельной шины у 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 для этих синхронизаторов и тем самым совершили ошибку.

Добрый день, есть убунта 20.04, на ней успешно стоит GoWin EDA и успешно все собирает. Сделал свой первый проект под GoWin, и пытаюсь загрузить. Похоже загрузчик не видит порт. Пробовал под рутом, и без рута. Ничего не получается. На том же компе у меня успешно под ардуиной грузится все, что можно. При втыкании борды в усб наблюдаю и в /dev появляются ttyUSB0 и ttyUSB1, но после запуска загрузчика (хоть с командной строки, хоть с оболочки) они оттуда исчезают. С командной строки пробовал даже так: в этом случае, программатор уже не ругается, что не видит порт, но пишет, что де PS: винды нет, и ставить некуда, так как привык работать на лаптопе с этой убунтой. Пожалуйста, подскажите, что попробовать, чтобы все-таки запустить это все? Спасибо! ИИВ

Всех приветствую. Может кто-нибудь подскажет, как корректно создать простой блок памяти 8 адресов, 8 бит данных в Gowin? GOWIN FPGA Designer Version 1.9.8.05 build(57076). _Tools > IP Core Generator > Memory > Block Memory > SP 1.0 Address Depth:8 Data Width: 8 Получается //--------Copy here to design-------- test_RAM_ad8b_d8b your_instance_name( .dout(dout_o), //output [7:0] dout .clk(clk_i), //input clk .oce(oce_i), //input oce .ce(ce_i), //input ce .reset(reset_i), //input reset .wre(wre_i), //input wre .ad(ad_i), //input [2:0] ad .din(din_i) //input [7:0] din ); //--------Copy end------------------- Почему " .ad(ad_i), //input [2:0] ad" , а не [7:0] ? Вроде, 1 блок памяти 18Kb...