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

Поиск

Показаны результаты для тегов 'gowin'.

  • Поиск по тегам

    Введите теги через запятую.
  • Поиск по автору

Тип контента


Форумы

  • Сайт и форум
    • Новости и обсуждения сайта и форума
    • Другие известные форумы и сайты по электронике
    • В помощь начинающему
    • International Forum
    • Образование в области электроники
    • Обучающие видео-материалы и обмен опытом
  • Cистемный уровень проектирования
    • Вопросы системного уровня проектирования
    • Математика и Физика
    • Операционные системы
    • Документация
    • Системы CAD/CAM/CAE/PLM
    • Разработка цифровых, аналоговых, аналого-цифровых ИС
    • Электробезопасность и ЭМС
    • Управление проектами
    • Нейронные сети и машинное обучение (NN/ML)
  • Программируемая логика ПЛИС (FPGA,CPLD, PLD)
    • Среды разработки - обсуждаем САПРы
    • Работаем с ПЛИС, области применения, выбор
    • Языки проектирования на ПЛИС (FPGA)
    • Системы на ПЛИС - System on a Programmable Chip (SoPC)
    • Методы и средства верификации ПЛИС/ASIC
  • Цифровая обработка сигналов - ЦОС (DSP)
    • Сигнальные процессоры и их программирование - DSP
    • Алгоритмы ЦОС (DSP)
  • Микроконтроллеры (MCU)
    • Cредства разработки для МК
    • ARM
    • RISC-V
    • AVR
    • MSP430
    • Все остальные микроконтроллеры
    • Отладочные платы
  • Печатные платы (PCB)
    • Разрабатываем ПП в САПР - PCB development
    • Работаем с трассировкой
    • Изготовление ПП - PCB manufacturing
  • Сборка РЭУ
    • Пайка и монтаж
    • Корпуса
    • Вопросы надежности и испытаний
  • Аналоговая и цифровая техника, прикладная электроника
    • Вопросы аналоговой техники
    • Цифровые схемы, высокоскоростные ЦС
    • RF & Microwave Design
    • Метрология, датчики, измерительная техника
    • АВТО электроника
    • Умный дом
    • 3D печать
    • Робототехника
    • Ремонт и отладка
  • Силовая электроника - Power Electronics
    • Силовая Преобразовательная Техника
    • Обратная Связь, Стабилизация, Регулирование, Компенсация
    • Первичные и Вторичные Химические Источники Питания
    • Высоковольтные Устройства - High-Voltage
    • Электрические машины, Электропривод и Управление
    • Индукционный Нагрев - Induction Heating
    • Системы Охлаждения, Тепловой Расчет – Cooling Systems
    • Моделирование и Анализ Силовых Устройств – Power Supply Simulation
    • Компоненты Силовой Электроники - Parts for Power Supply Design
  • Интерфейсы
    • Форумы по интерфейсам
  • Поставщики компонентов для электроники
    • Поставщики всего остального
    • Компоненты
  • Майнеры криптовалют и их разработка, BitCoin, LightCoin, Dash, Zcash, Эфир
    • Обсуждение Майнеров, их поставки и производства
  • Дополнительные разделы - Additional sections
    • Встречи и поздравления
    • Ищу работу
    • Предлагаю работу
    • Куплю
    • Продам
    • Объявления пользователей
    • Общение заказчиков и потребителей электронных разработок

Поиск результатов в...

Поиск контента, содержащего...


Дата создания

  • Начало

    Конец


Дата обновления

  • Начало

    Конец


Фильтр по количеству...

Регистрация

  • Начало

    Конец


Группа


AIM


MSN


Сайт


ICQ


Yahoo


Jabber


Skype


Город


Код проверки


skype


Facebook


Vkontakte


LinkedIn


Twitter


G+


Одноклассники


Звание

Найдено: 0 результатов

  1. Доброго времени суток, уважаемые участники, Набрёл на 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 вроде бы есть аналогичные входные буферы - есть ли у кого-нибудь опыт их применения и понимание, на сколько эффективно они работают с синфазными входными помехами?
  2. Приветствую, господа. Может, есть какие-то апноты по созданию приёмника на основе IODELAY + IEM + IDES? Вроде бы чувствую, что с помощью IEM можно отказаться от битовой тренировочной последовательности, но дальше своих чувств и предположений продвинуться не могу. Кто-нибудь работал с модулем IEM? Где можно найти хоть какое-нибудь описание, кроме состава портов?
  3. Об исследовании одного глюка в ПЛИС Gowin: https://github.com/juj/gowin_flipflop_drainer Насколько я понял, вопрос остается открытым...
  4. Здравствуйте. Кто-нибудь делал для Gowin обновление конфигурации по JTAG с микроконтроллера ? Что-то описание у них мутное какое-то. В описании одно пишут. Создал SVF файл - так как-то иначе все выходит. У меня пока что получилось только ID и регистр статуса прочитать. Теперь бьюсь со стиранием - никак не выходит.
  5. Обнаружили с коллегами любопытный баг, когда писали код 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. Есть ли у кого какие мысли?
  6. Приветствую участников форума, Пробовал-ли кто-нибудь заставить работать 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 с нестандартными кабелями?
  7. Доброго времени суток всем участникам, В даташите на 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 У кого-нибудь получилось упаковать два подобных триггера в одну ячейку? Или может быть есть место, где описана невозможность подобной упаковки?
  8. Доброго времени суток всем участникам, Попытавшись разместить выходные регистры данных и управления 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).
  9. Доброго всем времени суток! Пытаюсь понять, как у 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?
  10. Хочу предупредить любителей (таких как я, например) ставить элементы соответствующими примитивами, а не использовать IP Core Generator. В даташите на говиновскую память (в доступной мне версии UG285-1.3.4E, 11/01/2022 по крайней мере) использование Byte Enable нигде явно не оговорено. Лишь однажды, в режиме SDPB, когда порт А используется только для записи, byte_en появляется в адресе в инстансе примитива. Больше никаких упоминаний. В prim_sim.v (когда уже приходится туда лезть) мы увидим, что в любом режиме с шириной данных больше или равной 8 битам по порту записи, младшие биты адреса используются как Byte Enable соответственно количеству байтов. IP Core Generator сам подставляет в нужные биты перманентные единицы. Надеюсь, сэкономлю кому-нибудь время, которое сам безвозвратно потратил.
  11. Добрый день, Дано: 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, которые ожидаемым образом изменяются от подключения к подключению кабеля, что доставляет массу неудобств.
  12. Имею на руках означенный родной программатор. Вопрос: его работоспособность можно как-нибудь проверить, не имея на руках (пока) ничего, роме как кита DK_START_GW2AR-LV18EQ144PC8I7_V1.1, которому внешний программатор как собаке пятая нога, т.к. имеется такой же на борту? Смысл пробы - сотворить простейший переходник с него на эфовский (начало не помню, но оканчивается на Iso) от @StewartLittle под разводку последнего, дабы к приходу смонтированных плат хоть один вариант того, что не прошивается (ежели таковой казус и произойдёт), был бы мог смело быть отметённым.
  13. Всем привет! Пытаюсь запрограммировать встроенную в ПЛИС флешку на 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. Уважаемые участники, как вы решаете (если решаете) вопрос с верификацией прошивки после программирования?
  14. Всем привет! Имеется ПЛИС GW1NR-LV9QN88PC6/I5 (Tang Nano 9K). В документации от Gowin (SUG283-1.5E, 11/15/2018) указано наличие примитива BUFG: Я инстанцирую его в модуле верхнего уровня и в нетлисте после синтеза он ожидаемо присутствует. Однако в сгенерированном после pnr файле vo его нет. Нет его и в путях прохождения тактового сигнала Timing Analyzer. Т.е. складывается впечатление, что этот примитив BUFG на самом деле не существует на кристалле ПЛИС. Или я что-то делаю не так? Если использовать в качестве входов тактовых сигналов пины GCLKT, то проблем нет и ругани в PNR на эту тему тоже нет. Но мне интересен вариант использования глобального буфера, на вход которого сигнал подаётся не с выделенного пина, а с любого другого. Я понимаю, что это даёт дополнительную задержку, но в ряде случае это допустимо и может быть даже вполне оправдано. Получается, что такой вариант с Gowin невозможен?
  15. Всем привет! Обнаружилась досадная особенность при синтезе совершенно элементарной конструкции синхронизатора для параллельной шины у 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 для этих синхронизаторов и тем самым совершили ошибку.
  16. Добрый день, есть убунта 20.04, на ней успешно стоит GoWin EDA и успешно все собирает. Сделал свой первый проект под GoWin, и пытаюсь загрузить. Похоже загрузчик не видит порт. Пробовал под рутом, и без рута. Ничего не получается. На том же компе у меня успешно под ардуиной грузится все, что можно. При втыкании борды в усб наблюдаю и в /dev появляются ttyUSB0 и ttyUSB1, но после запуска загрузчика (хоть с командной строки, хоть с оболочки) они оттуда исчезают. С командной строки пробовал даже так: в этом случае, программатор уже не ругается, что не видит порт, но пишет, что де PS: винды нет, и ставить некуда, так как привык работать на лаптопе с этой убунтой. Пожалуйста, подскажите, что попробовать, чтобы все-таки запустить это все? Спасибо! ИИВ
  17. Всех приветствую. Может кто-нибудь подскажет, как корректно создать простой блок памяти 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...
×
×
  • Создать...