Поиск
Показаны результаты для тегов 'cpu'.
-
Компания Loongson – производитель микроконтроллеров и процессоров на собственной архитектуре LoongArch, расширила линейку 3-го семейства решений на SoC (System on Crystal), выпустив процессор 3A6000. Подробнее
-
Производитель Loongson представляет многоцелевое энергоэффективное решение для промышленного применения – SoC 2K0500 из второго семейства. Чип может быть использован в таких направлениях как IoT, АСУ, BMC, ЧПУ. Подробнее
-
Делаю задания, застрял на одном моменте (я новичок, студент). Есть следующее задание, пункт 45, заполнить файл инструкциями по варианту. Мой файл INSTR.hex выглядит так (фото ниже), и сами инструкции (фото ниже). Что-то застрял, не могу понять что делать надо
- 8 ответов
-
- quartus ii
- cpu
-
(и ещё 4 )
C тегом:
-
Распределил задачи на три ядра: 1. CPU0 - инит периферии, загрузка задачи в CPU1 и DSP, кодер Рида-Соломона 2. CPU1 - декодер Рида-Соломона 3. DSP - управляющая программа + всё остальное. Основная проблема: при подаче питания на плату - кодер Рида-Соломона на CPU0 возвращает правильнные данные, но DSP при приёме этих данных пакета из эфира с помощью приёмника (трансивер Si4463) - возвращает мусор в проверочных символах. При этом сам пакет приходит правильный. Проблема именно в проверочных символах. Если же сделать сброс (нажать кнопку RESET на плате MangoPi - allwinner T113-s3), то проверочные символы верны. И после каждого сброса - данные верны. Проблема возникает только при подаче питания. Взаимодействие CPU0,CPU1 с DSP : управление - через волатильный флаг, слово в памяти - регион не кеширован, не буферизован, SHARED=1. Данные - пара буферов - для кодера и декодера. Кешированы, буферизованы, SHARED=1. #define FEC_CODER_DATA 0xC7D00000 //адрес буфера кодера (кеширован) #define FEC_DECODER_DATA 0xC7D80000 //адрес буфера декодера (кеширован) #define FEC_CODER_CONTROL 0x47E00000 //контроль кодера (не кеширован) #define FEC_DECODER_CONTROL 0x47E80000 //контроль декодера (не кеширован) #define rsc (*(IO u32*)FEC_CODER_CONTROL) #define rsd (*(IO u32*)FEC_DECODER_CONTROL) Процедура запуска кодирования со стороны DSP - buf - входной и выходной буфер. Для простоты - приведен пример синхронной работы кодера (вынуждающий ждать его завершения работы, что сводит "на нет" преимущества многоядерности, но зато более понятен). Есть и асинхронный режим - когда возвращается закодированное содержимое с предыдущей итерации, а даётся команда на кодирование новых данных - без ожидания. static dtype *RSC=(dtype*)FEC_CODER_DATA; static dtype *RSD=(dtype*)FEC_DECODER_DATA; void FEC_Encode(u16 *buf) { memcpy(RSC,buf,Fsize); __asm__ __volatile__ ("" ::: "memory"); xthal_dcache_region_writeback(RSC,Fsize); __asm__ __volatile__ ("" ::: "memory"); rsc=0; __asm__ __volatile__ ("" ::: "memory"); while(!rsc); __asm__ __volatile__ ("" ::: "memory"); xthal_dcache_region_invalidate(&RSC[Fsize>>1],EE<<1); __asm__ __volatile__ ("" ::: "memory"); memcpy(&buf[Fsize>>1],&RSC[Fsize>>1],EE<<1); } Процедура кодирования со стороны CPU0: void FEC_Encode(void) { if(!rsc) { cache_inv_range((u32)RSC,((u32)RSC)+Fsize); __asm__ __volatile__ ("" ::: "memory"); memcpy(EncodeBuf,RSC,Fsize); __asm__ __volatile__ ("" ::: "memory"); encode_rs(EncodeBuf); memcpy(&RSC[Fsize>>1],&EncodeBuf[KK],EE<<1); __asm__ __volatile__ ("" ::: "memory"); cache_flush_range((u32)&RSC[Fsize>>1],((u32)&RSC[Fsize>>1])+(EE<<1)); __asm__ __volatile__ ("" ::: "memory"); rsc=1; } } При приёме вместо содержимого проверочных символов: memcpy(&RSC[Fsize>>1],&EncodeBuf[KK],EE<<1); Прилетает мусор (при каждом новом включении - разный). При этом проверял пакет данных : перед передачей, во время передачи, после передачи - он правильный. Проблема при приёме - проверочные символы битые. При сбросе проблема уходит. Если же сделать кодирование на одном ядре - средствами DSP, то проблема не возникает: void FEC_Encode(u16 *buf) { memcpy(EncodeBuf,buf,Fsize); encode_rs(EncodeBuf); memcpy(&buf[Fsize>>1],&EncodeBuf[KK],EE<<1); } Настройка MMU CPU0,1 для "регистров" rsc/rsd (управление): mmu_tlb_address[i + (dram_base>>20)] = (dram_base + (i << 20)) | (0 << 19) | (0 << 18) | (0 << 17) | (1 << 16) | //SHARED (0 << 15) | (0 << 12) | //TEX (3 << 10) | (0 << 9) | (15 << 5) | (0 << 4) | (0 << 3) | //Cacheble (0 << 2) | //Bufferable (2 << 0); Настройка MMU для буферов: mmu_tlb_address[i + (dram_base>>20)] = (dram_base + (i << 20)) | (0 << 19) | (0 << 18) | (0 << 17) | (1 << 16) | //SHARED (0 << 15) | (0 << 12) | //TEX (3 << 10) | (0 << 9) | (15 << 5) | (0 << 4) | (1 << 3) | //Cachable (1 << 2) | //Bufferable (2 << 0); В чём может быть проблема?
-
Для чего нужен flush icache?
repstosw опубликовал тема в Программирование
Собственно, для чего? flush dcache - понятно. Скинуть с кеша данных в память. Чтобы DMA или периферал какой-нибудь прочитал правильные данные, подготовленные CPU invalidate dcache - понятно. Объявить кеш данных недостоверным. Чтобы CPU прочёл корректные данные, после того как периферал или DMA записали в память данные/ invalidate icache - тоже понятно. Объявить кеш инструкций недостоверным. Для самомодифицирующегося кода: если мы записали байт-код какой-нибудь функции в память и её нужно выполнить. А flush icache - зачем? Какова практическая цель его применения? Сбросить кеш кода в память. Для чего? -
Организаторы проведут интерактивную сессию вопросов и ответов с менеджером по линейке продуктов и техническим экспертом – представителями Xilinx. Подробнее