BSACPLD

У меня платы наконец пришли. Данная схема работает как надо 🙂

Коллеги, не появилось ли поддержки CSI-2 в новых PDS? Или может есть какой-нибудь открытый IP, который можно доработать под Pango? Вопрос больше академический - от предыдущего проекта есть несколько не использованных плат, есть желание попробовать запустить на них CSI-2...

Походу мне Class 0 подойдёт вместо Class 3. Схема для Class 3 легко превращается в Class 0 путём выкидывания схемы классификации - меньше компонентов закупать/паять 🙂

Для Class 0 другая схема нужна.

У меня отличие от оригинальной схемы в двух резисторах вместо одного, чтобы более точно ток задавать. И управляемый стабилитрон на 2.5В вместо 1.25В.

Там класс определеяется током через резисторы R48, R44. 2.5В/(R48+R44) Конкретно в данной схеме Class 1. P.S. Забыл поменять в образце на Class 3 😞 Но ничего страшного, на двух платах можно руками перепаять 🙂

Я на рассыпухе сделал для своего проекта. Благо мощность всего 10 Вт требовалась и места хватало. На макете работает. Сейчас жду опытный образец.

Коллеги, есть ли у кого опыт реализации 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