BSACPLD

Коллеги, есть ли у кого опыт реализации h.264 на FPGA? Нашел пару проектов на github: https://github.com/openasic-org/xk264 https://github.com/bcattle/hardh264/tree/master?tab=readme-ov-file Но судя по всему это не полноценные кодеки, т.к. есть куча сигналов с непонятным назначением вместо входа под видеопоток. Кто-нибудь их применял или может быть есть более полноценная реализация h.264 под FPGA?

Спасибо за наводку. Не сразу заметил, т.к. у функции не было возвращаемого буфера. Немного переписал приём и передачу. /********************************************************************* * @fn MACRAW_Rx * * @brief Ethernet receive data frames in chain mode. * * @param rx_buf receive buffer pointer * rx_size receive buffer length * * @return receive data length. */ uint16_t MACRAW_Rx(uint8_t* rx_buf, uint16_t rx_size) { uint16_t length = 0; if(!(pDMARxSet->Status & ETH_DMARxDesc_OWN)) { if(!(pDMARxSet->Status & ETH_DMARxDesc_ES) &&\ (pDMARxSet->Status & ETH_DMARxDesc_LS) &&\ (pDMARxSet->Status & ETH_DMARxDesc_FS) ) { length = (uint16_t)((pDMARxSet->Status & ETH_DMARxDesc_FL) >> 16); if(length > rx_size) { length = rx_size ; } memcpy(rx_buf, (uint8_t*)pDMARxSet->Buffer1Addr, length); /*printf("rx_buf: "); for(uint16_t i=0 ; i<length ; i++) { printf("%02X ", rx_buf[i]); } printf("\r\n");*/ } pDMARxSet->Status = ETH_DMARxDesc_OWN; pDMARxSet = (ETH_DMADESCTypeDef *)pDMARxSet->Buffer2NextDescAddr; } return length; } /********************************************************************* * @fn MACRAW_Tx * * @brief Ethernet send data frames in chain mode. * * @param tx_buf send buffer pointer * tx_size send data length * * @return send data length. */ uint16_t MACRAW_Tx(uint8_t* tx_buf, uint16_t tx_size) { // Wait until DMA release Tx buffer while((DMATxDescToSet->Status & ETH_DMATxDesc_OWN) != (u32)RESET) { } /* Setting the Frame Length: bits[12:0] */ DMATxDescToSet->ControlBufferSize = (tx_size & ETH_DMATxDesc_TBS1); memcpy((uint8_t*)DMATxDescToSet->Buffer1Addr, tx_buf, tx_size); /* Setting the last segment and first segment bits (in this case a frame is transmitted in one descriptor) */ DMATxDescToSet->Status |= ETH_DMATxDesc_LS | ETH_DMATxDesc_FS; /* Set Own bit of the Tx descriptor Status: gives the buffer back to ETHERNET DMA */ DMATxDescToSet->Status |= ETH_DMATxDesc_OWN; /* Clear TBUS ETHERNET DMA flag */ ETH->DMASR = ETH_DMASR_TBUS; /* Resume DMA transmission*/ ETH->DMATPDR = 0; /* Update the ETHERNET DMA global Tx descriptor with next Tx descriptor */ /* Chained Mode */ /* Selects the next DMA Tx descriptor list for next buffer to send */ DMATxDescToSet = (ETH_DMADESCTypeDef*) (DMATxDescToSet->Buffer2NextDescAddr); /*printf("tx_buf: "); for(uint16_t i=0 ; i<tx_size ; i++) { printf("%02X ", tx_buf[i]); } printf("\r\n");*/ return tx_size; } Не уверен, что полностью корректно, но в первом приближении работает.

Коллеги, есть у кого пример как принимать сырые Ethernet пакеты с помощью CH32V307? Нашёл только вот такой пример: https://github.com/openwch/ch32v307/blob/main/EVT/EXAM/ETH/MAC_RAW/ETH_Driver/eth_driver_10M.c MACRAW_Tx там есть, а вот MACRAW_Rx или чего либо похожего чтобы забрать пакет из буфера там нет.

Выходные - есть. Входные - нет. Входные DDIO эмулируются на логике.

Как, например, насчёт MAX V (у которого нет регистров в IOB)? Так у Cyclone II, IV E тоже нет входных DDR регистров. Но есть статическая задержка. И метод с задержкой там прекрасно работал на 125 МГц, только я задерживал клок, а не данные. Хотя в случае MAX V и входной задержки нет.

Не совсем согласен. Метод с входной задержкой был успешно применён на Altera (Cyclone II, IV E, Stratix III), Xilinx (Artix-7, Kintex-7), Lattice (ECP5), Fudan (JFMK50T4) и PangoMicro (Logos2). Единственное, где не прокатило, это Gowin, но там всё уперлось в максимальную частоту проекта (больше 80МГц не удалось вытянуть), а не в задержки. При этом единственное различие, это примитивы и конкретные значения задержки. Я просто оборачивал все примитивы во враппер - см. MAC что я выкладывал в этой теме. А с PLL могут быть проблемы, т.к. при изменении скорости падает частота клока - не факт, что PLL будет корректно работать на частоте отличной от указанной при генерации IP блока. На 2.5МГц точно не будет работать, но с другой стороны кто сейчас применяет 10 Мбит/с?...

Вот ещё MDIO до кучи. P.S. Для MAC я обычно ставил IDELAY_VALUE = 10. На Artix-7 этого было достаточно чтобы setup был порядка -1.0 нс. Констрейны при этом были: create_clock -period 7.200 -name {RXC_VIRTUAL} create_clock -period 7.200 -name {RXC} [get_ports {eth_rxc}] set_false_path -rise_from [get_clocks {RXC_VIRTUAL}] -rise_to [get_clocks {RXC}] set_false_path -fall_from [get_clocks {RXC_VIRTUAL}] -fall_to [get_clocks {RXC}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -max 0.500 [get_ports {eth_rx_ctl}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -min -0.500 [get_ports {eth_rx_ctl}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -clock_fall -max -add_delay 0.500 [get_ports {eth_rx_ctl}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -clock_fall -min -add_delay -0.500 [get_ports {eth_rx_ctl}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -max 0.500 [get_ports {eth_rd[0]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -min -0.500 [get_ports {eth_rd[0]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -clock_fall -max -add_delay 0.500 [get_ports {eth_rd[0]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -clock_fall -min -add_delay -0.500 [get_ports {eth_rd[0]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -max 0.500 [get_ports {eth_rd[1]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -min -0.500 [get_ports {eth_rd[1]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -clock_fall -max -add_delay 0.500 [get_ports {eth_rd[1]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -clock_fall -min -add_delay -0.500 [get_ports {eth_rd[1]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -max 0.500 [get_ports {eth_rd[2]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -min -0.500 [get_ports {eth_rd[2]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -clock_fall -max -add_delay 0.500 [get_ports {eth_rd[2]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -clock_fall -min -add_delay -0.500 [get_ports {eth_rd[2]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -max 0.500 [get_ports {eth_rd[3]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -min -0.500 [get_ports {eth_rd[3]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -clock_fall -max -add_delay 0.500 [get_ports {eth_rd[3]}] set_input_delay -clock [get_clocks {RXC_VIRTUAL}] -clock_fall -min -add_delay -0.500 [get_ports {eth_rd[3]}] 7.2 нс это период клока от PHY с учётом возможного гуляния фронтов при восстановлении клока - ставим самый худший случай. eth_mdio.7z

Я использовал AXI, AXI-Stream и I2C. Ethernet и PCIe мне показали немного "недоделанными", поэтому писал сам, точнее у меня уже была своя реализация под RGMII. Собственно вот моя кроссплатформенная реализация MAC для RGMII. eth_mac_rgmii.7z lib.7z

Статические, расчетные. Я уже разобрался. Надо было делать клок с помощью GTP_INBUFGDS вместо GTP_INBUFDS. После этого все тайминги сошлись.

UP. Всё ещё актуально.

Насчёт синтеза в Synplify. Для того чтобы использовать отладчик, на интересующие сигналы нужно было добавить директиву /* synthesis PAP_MARK_DEBUG="true" */. В PDS_2022.2-SP4.2-CentOS7.3-x64 это работает, а в PDS_2023.2-SP1-CentOS7.3-x64 начинает выкидывать сигналы. В более новых версиях поменялись директивы для отладчика или это просто баг?

Т.е. то что сейчас предлагают поставщики со складов, это опытные образцы?

Не пробовал, т.к. в Synplify с начальной инициализацией всегда были приколы. На мой взгляд с инвертором более предсказуемый вариант с точки зрения синтеза в Synplify. 324 Вроде уже серийные должны быть...

Походу нужен. Для Xilinx данный резистор не требуется. Получается, что Logos2 в версии без трансиверов хоть и pin-to-pin, но по схемотехнике немного отличается. Привязал к триггеру, который изначально в 0 (все триггеры у PangoMicro по включению питания 0), проинвертировал сигнал, а условие установки триггера поставил на первое обращение к регистру адреса контроллера QSPI. Заработало. Костыли, костыли, костыли...

Если CE_N это tristate, тогда ещё и внешний pull-up на qspi_sck придётся добавить. В принципе не страшно - можно 0805 припаять между 6 и 8 выводом FLASH. Благо она у меня в SOIC и сделать это совсем несложно. UPD. Если чисто 1 подать, то грузится. А вот если от логики, то не грузится. Пробовал ~locked от PLL подавать.