_4afc_

Значит проект криво написан. На текущий момент компоненты памяти и умножители от GoWin не дают никакого преимущества по скорости относительно описания на верилоге. работоспособность в ПЛИС полностью совпадает с моделированием.

На самом деле автору нужно было отключить no_rw_check, что он и сделал в среде разработки. Поэтому биться над добавлением этой строки именно в таком виде - не стоит.

Шины адреса для чтения и записи разные? reg signed [17:0] DATA [0:127]/* synthesis syn_ramstyle = "no_rw_check,block_ram" */; поиграйтесь с галкой no_rw_check в настройках проекта. Прикол в том, что Gowin похоже оптимизирует по модулям. И просто регистры между модулями - хуже, чем регистры в конце модуля (или в начале).

Регистры ставить на выходе модулей. И PnR_mode=2.

Если частота датчиков звук/ультразвук - экран из отожженного железа, а не из меди.

Что-то мне кажется, что такой импульс будет иметь широкий спектр и пройдёт и трансформаторную и емкостную развязку. Тут скорее только супресоры спасут линию данных. Кстати про PCB говорят, что если TOP залит землёй - это ослабляет внешнюю помеху на 60дБ. Так что может 1В и наведётся в трубе. Возможно спасут трансформаторы, с намоткой обмотки линии в два провода (для Longitudinal Balance of a Copper Cable Pair)

Я по кабелю 6хUAA3607TAU от industrifil который представляет из себя 6 "МГТФ" не свитых в экране - гонял по LVDS 640 Мбит на 2,5 метра через SerDes от максима.

Что такое ЦАП высших порядков? Матлабом владеете?

Так может 1.0/2.0/5.1 версии ? Типа на 3.3В более 52МГц не ждите...

Работали одновременно уарт, спорт х2, ппи х2 по прерываниям лет 15 назад. На двух ядрах. Разбирайтесь...

Что-то они программер сломали. Не могу прошить флешку на плате TangNano9k (sram - прошивает) v1.9.9.03 прошивает и возвращает статус 0x0001F020 v1.9.10.01 не прошивает и возвращает статус 0x00011422 смены частоты 15/2,5/2 МГц не помогают

Насколько я понимаю OQPSK-DSSS это однотоновая передача сигнала где биты данных кодируются расширенным кодом типа баркера? Интересно что подобные модуляции были в WiFi / WCDMA, а затем, при развитии стандартов все ударились в OFDM... Неужели вместо скорости передачи и чувствительности DSSS появились новые преимущества в сложно рассчитываемой OFDM?

На данный момент фразу SDP36KE initial value я понимаю так: значения данных в SDP36KE & BSRAM считываемые после подачи питания нельзя использовать для генерации случайных данных. В общем-то надобности не было. Было опасение, что они инициализацию ROM/RAM константами в новых ПЛИС не могут осилить...

В какой среде и на какой ПЛИС проверяли? У GoWin в ранних версиях среды (года 2 назад) такой код глючил от фазы луны. Были такие глюки: begin : BadCode rg <= 1; if (A) rg <= 0; end begin : GoodCode if (A) rg <= 0; else rg <= 1; end и такие: begin : BadCode if (A) rg <= 0; else if (B) rg <= 1; end begin : GoodCode if (A) rg <= 0; else begin if (B) rg <= 1; end end Потом они стали прокачивать свой синтезатор на предмет поддержки не только Verilog, но и SystemVerilog и видно обилие исходников криво собираемых подвигло на исправление синтезатора.

Отражений от приёмника до передатчика и обратно? А если тракт с сильным затуханием - отражённый сигнал должен уйти в помехи / не мешать детектированию? Линия - древность, со времён колхозов, 100 раз перерубленная трактором - там 150 Ом только при прокладке было - может не переживать про согласование? Ну судя по картинке - параллельно, и два абонента. "эквивалентное" - В смысле у обоих абонентов TX=RX=волновое (с учётом трансформатора)? Отражения проверить на хорошем кабеле, при испытаниях? Так померялось. Насколько я помню намерялось и больше, но при большем чем 8В напряжении у AD8018 (Vpp?). В итоге более 40% от питания в линию не вылетело.