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

Vengin

Свой
  • Постов

    140
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Vengin

  • Звание
    Частый гость
    Частый гость

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

2 417 просмотров профиля
  1. Здравствуйте. Имеется кастомная плата с процессором ADSP-CM409F (Analog Devices). Задействовано два SPI интерфейса, и любые попытки транзакций чтения/записи не происходят (блокируются). Далее детали. Используется два SPI интерфейса (SPI_0, SPI_1), оба подсоединены к Porct_C (к специальным пинам, которые могут быть промультиплексированы на SPI интерфейс): Мультиплексирование сделано используя PinMux тул (часть "ADSP-CM40x Enablement Package"): Код для тестирования SPI базируется на примере “SPI_flash_read” (также входящий в "ADSP-CM40x Enablement Package"), который использует выделенный SPI_2 интерфейс для чтения встроенной Flash памяти, и этот пример работает. Далее упрощённая версия кода (который не работает) для инициализации и чтения одного байта по SPI_1: #include <stdio.h> #include <drivers/spi/adi_spi.h> // SPI variables uint8_t rx_buf[4] = {0}; // SPI_1 transceiver setup for 1 byte RX operation (without prologue) ADI_SPI_TRANSCEIVER xcvr = { NULL, 0, NULL, 0, &rx_buf[0], 1 }; static ADI_SPI_HANDLE hSPI; static uint8_t SpiMemory[ADI_SPI_INT_MEMORY_SIZE]; ADI_SPI_RESULT tst_spi1() { /******************************************************************************* * SPI Init: Master, Non-DMA mode, Software SlaveSelect ******************************************************************************/ ADI_SPI_RESULT res; res = adi_spi_Open(1, &SpiMemory, ADI_SPI_INT_MEMORY_SIZE, &hSPI); res += adi_spi_SetMaster(hSPI, true); //set as master res += adi_spi_SetHwSlaveSelect(hSPI, false); // Software (not Hardware) Slave Select res += adi_spi_SetWordSize(hSPI, ADI_SPI_TRANSFER_8BIT); // 8-bits word size res += adi_spi_SetClock(hSPI, 39); // 2 MHz (for SYSKCLK = 80MHz) res += adi_spi_SetClockPolarity(hSPI, true); // Active HIHG clock res += adi_spi_SetClockPhase(hSPI, true); // Data transitions on the RISING edge of the clock res += adi_spi_RegisterCallback(hSPI, NULL, NULL); // none res += adi_spi_EnableDmaMode(hSPI, false); // Interrupt driven mode /******************************************************************************* * SPI transfer to read 1 byte in either Blocking/Non-Blocking mode ******************************************************************************/ #define SPI_RW_BLOCKING #ifdef SPI_RW_BLOCKING // Blocking Transfer res = adi_spi_ReadWrite(hSPI, &xcvr); #else // Non-Blocking Transfer bool bAvailable = false; // Submit RX buffer to receive 1 char res = adi_spi_SubmitBuffer(hSPI, &xcvr); do { // Non-blocking check for rx_buf availability res = adi_spi_IsBufferAvailable(hSPI, &bAvailable); if (ADI_SPI_SUCCESS != res) { break; // exit the loop } } while (!bAvailable); #endif // SPI_RW_BLOCKING return res; } Код состоит из двух частей: Инициализация (Master, Non-DMA mode, Software Slave-Select). Транзакция чтения 1 байта в блокирующем/неблокирующем режиме. Проблема возникает во 2-ой части при попытке транзакции данных. Любая транзакция (чтения/записи в блокирующем или неблокирующем режиме) никогда не заканчивается, а зависает в бесконечном цикле ожидания. В блокирующем режиме код зависает на строке adi_spi_ReadWrite(hSPI, &xcvr): Внутри функции adi_spi_ReadWrite() видно, что код зависает на функции adi_osal_SemPend(): При входе в функцию adi_osal_SemPend(): видно что код просто крутится в бесконечном цикле while, в котором вроде что-то связанное с прерываниями (функции _adi_osal_InterruptsDisable()/_adi_osal_InterruptsEnable()): Такая же проблема возникает в неблокирующем режиме. В этом случае после передачи буфера (функция adi_spi_SubmitBuffer(hSPI, &xcvr) ), код зависает на функции adi_spi_IsBufferAvailable(), т.е. буфер данных никогда не становится доступным. Что конкретно не так непонятно. Пробовал разные настройки инициализации – не помогает. Пробовал разные комбинации чтения/записи данных разных размеров – ничего. Проблема идентична для обоих SPI интерфейсов (SPI_0 и SPI_1). Может кто знает, в чем может быть проблема и как это решить? ADSP-CM409F SPI debug.zip
  2. А вы уверены, что Active-HDL 9.2 вообще поддерживает работу с ipcore Vivado 2019.1? Когда-то давно с этим боролся, и вроде поддержка версий Vivado от 2018 была в в Active-HDL где то 10.3 (или 10.4, 10.5). Смотрите совместимость (должна быть где-то то в доках или на сайте у xilinx-а и/или Active-hdl).
  3. Для Xilinx ISE это может и работает, но в Vivado свой компилятор библиотек compile_simlib, со своим синтаксисом и т.п. Пример: compile_simlib -simulator modelsim -simulator_exec_path {C:/PF/modeltech64_2019.2/win64} -family all -language all -library all
  4. 1. Сделано. 2. Подключено в файле проекта *.mpf (аналог modelsim.ini). Библиотеки в симуляторе отображаются. 3. Не совсем понятно. Аналог директивы #include (для VHDL это LIBRARY ...; USE ...;)? Это и так делается в сгенеренных коркой файлах. Не припомню одинаковых библиотек с суффиксами. Обычно вроде есть только несколько разных версий (типа floating_point_v7_0_16, floating_point_v7_1_8). Строка "protected" вроде фигурирует только внутри файлов библиотек " *_vh_rfs.vhd " (header с описанием чего и как зашифровано).
  5. Здравствуйте. Решил обновить рабочий софт: работал на связке Vivado 2017.4 + Modelsim 10.5, обновил до Vivado 2019.1 + Modelsim 2019.2. Скомпилил симуляционные библиотеки. При попытке симуляции одного рабочего проекта (без оптимизации, т.е. "vsim -novopt …") изначально получаю ошибку: # ** Error (suppressible): (vsim-12110) All optimizations are disabled because the -novopt option is in effect. This will cause your simulation to run very slowly. If you are using this switch to preserve visibility for Debug or PLI features, please see the User's Manual section on Preserving Object Visibility with vopt. -novopt option is now deprecated and will be removed in future releases. Подавляю эту ошибку (добавлением флага "vsim -novopt suppress 12110 …") и симуляция отрабатывает (при этом вываливается куча warnings, предупреждающих, что при выключенной оптимизации симуляция будет медленной и т.п.). Когда же пытаюсь включить оптимизацию (“vsim -voptargs="+acc" ….”) получаю маловразумительные ошибки: # ** Error: D:\PF\Xilinx\Vivado\2019.1\data\ip\xilinx\xbip_dsp48_addsub_v3_0\hdl\xbip_dsp48_addsub_v3_0_vh_rfs.vhd(64): (vopt-1598) Library "<protected>" not found. # ** Error: D:\PF\Xilinx\Vivado\2019.1\data\ip\xilinx\xbip_dsp48_addsub_v3_0\hdl\xbip_dsp48_addsub_v3_0_vh_rfs.vhd(64): (vopt-1136) Unknown identifier "<protected>". В проекте используются ядра floating_point_v7_1_8, которым требуются xbip_dsp48_addsub_v3_0_vh_rfs.vhd, о которых по идее и говорится в ошибках. Т.к. это всё шифрованные исходники, то пытаться искать в них что-то бессмысленно. Где искать корень зла непонятно. Сделал пустой проект с простейшим float ядром add32 (на базе ядра floating_point_v7_1_8) и он симулируется корректно, как с оптимизацией, так и без неё. Может есть идеи, в чём может быть проблема при включении оптимизации? Или кто какие версии Modelsim использует с Vivado 2019.1? Xilinx для Vivado 2019.1 рекомендует Modelsim 10.7c, но его найти пока не удалось.
  6. На картинке в 1-ом посте действительно выделяется только цвет самого соединения (а при clock/reset domains выделяются ещё порты). clock/reset domains цвета раскидывается сам (может и можно настраивать - не заморачивался, и так хватало), с другим "разукрашиванием" вроде не сталкивался. Windows версия если что.
  7. ЕМНИП цвета раскидываются автоматически при показе clock domains или reset domains (в менюшке View). Не знаю точно с какой версии это появиялось (есть в 16.1)
  8. Действительно, после того как добавил тип параметра integer, warning-и исчезли и компонент лепистся нормально. Эх, жаль что всё уже на VHDL написано...
  9. Подход понятен. Но проблемы это не решает (по крайней мере в VHDL). Если даже убрать параметр Generic ADDR_WIDTH и в явном виде прописать ширину порта: addr : in std_logic_vector(natural(ceil(log2(real( DATA_WIDTH ))))-1 downto 0); Получаем ошибку: [IP_Flow 19-627] Port 'addr': XPath expression failed: Unsupported function call or array usage "real" found in expression "(natural(ceil(log2(real(spirit:decode(id('MODELPARAM_VALUE.DATA_WIDTH')))))) - 1)". Кстати попробовал в Vivado 2019.1 - те же ошибки. А ещё попробовал Verilog код, и там тоже не всё так гладко: module top # ( parameter DW = 32, parameter AW = $clog2(DW) ) ( input clk, input [AW-1:0] addr1, input [$clog2(DW)-1:0] addr2, input [DW-1:0] din, output [DW-1:0] dout ); endmodule IP Packager выдаёт warnings: [IP_Flow 19-5101] Packaging a component with a SystemVerilog top file is not fully supported. Please refer to UG1118 'Creating and Packaging Custom IP'. [IP_Flow 19-329] [HDL Parser] Unable to determine the value format for HDL parameter 'AW' with value 'spirit:log(2,DW)'. The parameter type is not supported in this release. [IP_Flow 19-533] HDL Parameter 'AW (Aw)': Missing data type Не нравится именно parameter AW = $clog2(DW). В итоге получается модуль, у когорого шина addr1[0:0], addr2[4:0]: Наверное чем иметь такой ненужный геморрой с этим IP Packager лучше в Block Design выпихнуть наружу порты, которые нужно подключать к корке и склеивать это всё уже в HDL. Бррр...
  10. О, а я пробовал с GENERIC - не клеилось, на портах и не проверял. Как и упоминалось на форумах Xilinx какой-то очень сырой и своеобразный этот парсер IP Packager. Да и не совсем понятно, что этот подход (использование XPATH функций) даёт? Допустим IP Packager не ругается на модифицированный HDL (с использованием XPATH функции вместо стандартный). Но ведь при этом сам HDL код уже не скомпилишь для симуляции/синтеза. В чём тогда смысл?
  11. Не понимаю. Допустим есть конфигурационный файл с расчётом параметра PAR1: constant PAR1_0: natural := 32; constant PAR1_1: natural := 8; constant PAR1: natural := natural(ceil(log2( PAR1_0/PAR1_1 ))); Я так понимаю, предлагается вместо формулы вставить константу, равную рассчитанному значению: constant PAR1_0: natural := 32; constant PAR1_1: natural := 8; --constant PAR1: natural := natural(ceil(log2( PAR1_0/PAR1_1 ))); constant PAR1: natural := 2; Так что ли? Тогда при любом изменении значений входящих в формулу (PAR1_0, PAR1_0) нужно вручную перерасчитывать PAR1 (и отслеживать это). Это бессмысленная и ненужная работа. Вроде сама идея программирования сводится к автоматизации ручного труда, а не к обратному. Честно говоря, не хочу превращать тему во флуд. Просто пытаюсь решить простую казалось бы проблему. А для этого пытаюсь получить ответ на два простых вопроса: 1) Можно или нельзя напрямую из HDL кода подтягивать параметры, если в рассчётах параметров используются только стандарные библиотечные мат функции типа log2? 2) Возвращаясь к изначальному вопросу в 1-ом сообщении: что за механизм такой функции XPATH и куда его пихать? Потому как когда вручную модифицируется параметр, то рассчёты делаются вроде как по синтаксису TCL (например, для ADDR_WIDTH по формуле expr {log($DATA_WIDTH)/log(2)} ) ----------------------- А в какой Vivado это? Я пытаюсь на 2017.4. Может в версиях постарше постепенно решают проблемы..
  12. Гм. Ну я вроде считаю себя программистом. Но вооще это продиктовано ТЗ - есть набор конфигураций, которые корка должна "подхватывать". Но должна быть и возможность её настраивать вручную. И всегда легко сказать "меняйте архитектуру" (хотя я например не вижу на что менять). Как вы себе это представляете, когда проект пишется не один месяц, вдруг всё поменять. Да и не совсем понятен предлагаемый подход: заменить все параметры на рассчитанные фиксированные значения. Т.е. придётся делать N копий версий проекта (по количеству конигурационных файлов), где каждая версия имеет жёстко вбитые в коде константы рассчитанных параметров? И опять таки самое главное. Простая замена GENERIC на непосредственно формулы с мат функциями типа log2 не решает проблемы (т.е. ошибки IP Packager остаются)!!!
×
×
  • Создать...