Digi

Хочу соединить два устройства по JESD . Количество трансферов (lane) 1, передаваемых каналов 4, разрядность 24 бита. На выходе JESD имеем один 32х битный порт, какую корку нужно использовать, чтобы разделить 32х битный порт на 4 24х битных ? PS: с JESD только начинаю разбираться, поэтому вопрос может не совсем корректно сформулировал. Если можно, то поделитесь каким нибудь примером где на один lane используется несколько каналов.

Согласен на Float, тем не менее вопрос про проц и производительность остаётся открытым

А что общественность скажет по поводу 1892BM18Ф ? Вроде разработчик Элвис, производитель Микрон, 180 нм. Проц конечно не шустрый, но в связке с КитаеXilinx свои задачи выполнит. К тому же есть опыт работы с ВМ10Я от Элвиса, набили большую кучу шишек и разработали новые матерные слова. Еще нашел вот такую статью о производстве кристаллов Элвиса https://en.wikipedia.org/wiki/ELVEES_Multicore

В связи с последними событиями открылось истинное лицо отечественных производителей микросхем. Мы широко применяли 1967ВН028 ф. Миландр. Как оказалось из российского там только название и вывернутая наизнанку распиновка. Корпуса, и те забугорные, подсанкционные. Поэтому назрел вопрос, какие отечественные DSP процессоры имеют 100% российское происхождение ? Какие наиболее доступные китайские DSP процессоры применяете ? Минимальные требования к DSP - наличие не менее 16 Мбайт встроенной ОЗУ или возможность подключения внешней памяти, канал связи с внешним миром не менее 3 Гбит/сек с DMA. Наложение окна и вычисление double FFT 8k за время не более 200 мкс. Возможность объединения DSP в кластеры с общей памятью. Наличие JTAG эмулятора и среды разработки на С++, С, ASM.

Может кому пригодиться, но проблема решилась путем переименования метки в имя, начинающееся с .L (.L_outer)

При компиляции asm-овского кода в среде CMLYNX линковщик выдаёт предупреждение на метку __outer (она является первой по коду). На последующие метки, объявленные аналогичным образом, предупреждения не выдаёт. Аналогичное предупреждение выдает и на библиотечные функции, в которых похоже переходы организованы таким же способом. Код работает правильно. В каком направлении копать для того чтобы убрать предупреждение ? Description Resource Path Location Type [L330] Input section .program(./data_conv_enh.doj) breaks the rules on symbol '__outer'. All symbols marked as used. TestFFT Milandr LLVM Link Problem .SECTION/DOUBLEANY .program; .global _apply_time_window; _apply_time_window: LC0=xR0;; // загрузка счётчика циклов j6 = j5 + 2 ;; // Указатель на окно window k6 = j6 ;; __outer: //цикл по количеству отсчётов XR3:0=Q[j0+0]; YR3:0=Q[k0+0];; xyfr0=float r0;; // Преобразование int во float xyfr1=float r1;; xyfr2=float r2;; xyfr3=float r3;; ..... Q[j0+=8]=xR3:0; Q[k0+=8]=YR3:0;; if NLC0E, jump __outer;nop;; nop;; nop;; _apply_time_window.end:

Quartus 20.4 - но галочку не нашёл. Но хотелось бы знать, где она есть ) При переносе в корень диска, проблема разрешалась, но нужно было хранить именно в специально отведённым под это месте. Проблему с репозиторием решил так: git config --system core.longpaths true

При генерации IP корок, Quartus создаёт длинные имена файлов, которые в дальнейшем создают проблемы. Например при работе с репозиториями, архивировании и.т.д. Каким способом можно уменьшить длину создаваемых имен файлов ? Например основную часть имени генерить не как "PCIe_mm_mm_clock_crossing_bridge_0_altera_avalon_mm_clock_crossing_bridge_1920_fdcxukq.v" а более кратко ?

Возникла необходимость измерить TDR при помощи векторного анализатора. В наличии есть VNA с поддержкой дистанционного управления. Хочу реализовать алгоритм измерения TDR по S11. В теории это должно бать обратное преобразование Фурье. Кто сталкивался, направьте на правильный путь.

An332_not_full.zip Откопал в закромах, может кому и пригодится. Но внутри только основные файлы приемника и передатчика. Тестбенчей нет. Утеряны. То что файлы не содержат изменений относительно оригинала - не гарантирую, но код вроде был работоспособный.

DDC пришлось раскидать на разные тактовые частоты. Основная частота заходит на PLL а с PLL 8 частот с такими же параметрами заходят на свои DDC. Так как если их повесить на одну, то время компиляции значительно возрастает и ни один DDC не работает. Хотя предупреждений у TimeQuest нет. Перестаёт корректно работать CIC фильтр.

На первом рисунке это что в в стандартной корке DDIO. А вот во втором случае возникнет проблема синхронизацией полуслов. Потому что FRM это не просто делённые CLK. Кажется так...

А вот так как раз и не получилось сгруппировать. Выдавал ошибку. Поэтому и задал вопрос. Так разве можно ? Если да, то ещё раз попробую сделать и понять, что было не так.

Да, скорее всего на входах, но суть это не меняет. Анализ не проводится. Но при попытке увязать это всё в одну кучу, результат - невозможность вытянуть времянки

Вот например, как быть в таком случае ? Все частоты одинаковы, за исключением A_CLK. Изначально добавлял в одну группу {A_FRMCLK1 A_CLK1} в другую FRMCLKx, отдельно каждую из DDC_CLK* и отдельно OUT_CLK. Возникала ситуация, что на выходе CDC не всегда защёлкивались верные данные. Так как Quartus некоторые биты утягивал совершенно в другую сторону кристалла, а так как между этими клоками не происходил анализ времянок, то и ошибок для него не было. Если замешать все клоки в одну группу, то время компиляции возрастало до неразумных пределов, и времянки везде недотягивали до требуемых. Проект становился совершенно неработоспособным.