[0608 0]

Имею работающие проекты с FPGA и Eth100. Теперь задача передать блок данных от АЦП по Eth1000 через PHY с RGMII, используя KSZ9031RNX и Cyclone V. Скорость передачи пакетами UDP «плата-компьютер» пока не более 300 Мбит.

Просматриваю вариант использования IP-ядра ALTSHIFT_TAPS, который в RAM строит длиные сдвиговые регистры. На них собираюсь построить две линейки 4-разрядных сдвиговых регистров для  младшего Shift L и старшего Shift H передаваемых полубайтов. При выдаче регистры сдвигаются с частотой 125 МГц и их выходы подключены к 4-х разрядному коммутатору для формирования D[3:0] в PHY. Сдвиги в регистах осуществляются раздельно по нарастающим и спадающим фронтам, в моменты после завершения выдачи полубайтов. Схема и диаграмма иллюстрируют выдачу. Выдаче всего блока данных предшествует предварительная побайтная его загрузка в сдвиговые регисты с помощью FSM или SoC. Возможно будет несколько подобных сдвиговых линеек, чтобы загружать в одни из них, когда из других происходит выдача.

Вопрос. На сколько этот способ выдачи в RGMII реалистичен.

[dxp 140]

Тут самое главное не сдвиговые регистры, а тайминги на внешних портах. Для их достижения нужно использовать специальные регистры в IO элементах. Насколько помню, у Альтеры это называется adtddio -- оно имеет два входа данных и умеет по обоим фронтам клока внутри себя переключать данные с этих входов на выход, формируя требуемый DDR сигнал. Поскольку эти блоки располагаются внутри IO элементов, то таким образом достигается детерминированная задержка от выхода до внешнего порта (пина микросхемы) и, самое главное, минимальный перекос между сигналами. 

На альтерах давно ничо не делаю, а для Xilinx оно выглядит примерно так (суть та же):

Показаны два блока (oddr они у Xilinx называются), подключения к D1, D2 не показаны (но они есть), ниже такой же блок используется для формирования RGMII клока канала передачи (тут на входы данных поданы разные логические уровни). Следует обратить внимание на то, что тактируются эти блоки разными клоками -- нижний сдвинут на четверть периода (2 нс), чем удовлетворяются требования по таймингам.

Ну, а данные на входы  D1, D2 подавать можно прямо из регистра с передаваемыми данными, не помню, чтобы там нужны были сдвиговые регистры.

[0608 0]

Спасибо за ответ. У Альтеры эта мега-функция называется ALTDDIO_OUT, и её задача только выравнять фронты TX_CLK и TXD[3:0], предполагая, что далее нужный сдвиг слока сделает уже PHY. Это показано на рис.2 в AN477. 

Но мне не понятна следующая вторая картинка на рис.4 из AN477. А именно, в какой момент подавать полубайты datain_h[3:0] и datain_l[3:0] на вход уже внедренного TX_DDIO (из ALTDDIO_OUT), относительно входного сигнала outclock. И этот вопрос никак не решается, может кто подскажет.

Edited October 23 by 0608

[sazh 9]

9 часов назад, 0608 сказал:

Сдвиги в регистрах осуществляются раздельно по нарастающим и спадающим фронтам.

 

Может документ старенький поможет.

Implementing_a_Source_Synchronous_Interface_v2.0.zip

[dxp 140]

7 часов назад, 0608 сказал:

ALTDDIO_OUT, и её задача только выравнять фронты TX_CLK и TXD[3:0], предполагая, что далее нужный сдвиг слока сделает уже PHY

Не, её задача -- выдавать DDR сигнал на пины микросхемы -- т.е. по двум фронтам -- с детерминированной задержкой. Это ключевое. А сдвиг клока -- это уже дело второе: можно полагаться на возможности PHY, а можно сделать самому (как в примере выше) -- сформировать в ПЛИС клок, сдвинутый относительно клока данных на 90° (как раз будут требуемые по спеке 2 нс при 8 нс периоде (125 МГц)).

7 часов назад, 0608 сказал:

в какой момент подавать полубайты datain_h[3:0] и datain_l[3:0] на вход уже внедренного TX_DDIO (из ALTDDIO_OUT), относительно входного сигнала outclock.

Ну, это зависит от реализации этого блока, я про altddio не помню, но скорее всего подавать надо одновременно: по положительному перепаду клока улетит один полубайт, по отрицательному -- второй. Попробуйте -- на симуляторе это сразу видно должно быть.

[0608 0]

sazh и dxp, спасибо за подсказки. Пока разбираюсь.

[Alex11 10]

Сто лет назад я делал то, что Вы делаете сейчас. Цыклон тогда был, правда еще только третий, но работало и на нем. Вот проект, можете глянуть. Он сделан под ActiveHDL 9.1 и Synplify 9.0.1. Если их нет,можно посмотреть так, там есть компилированные в VHDL графические файлы.

GigaEth.zip

[0608 0]

Alex11, огромное Спасибо, уже просматриваю! А то, что сделан Eth1000 на Cyclone III - это высота!. 

Edited October 24 by 0608

[0608 0]

Продолжаю тему. С регистами сдвига я перегнул. По-этому разбираюсь с рекомендуемым вариантом передачи на ядрах ALTDDIO_OUT. Для этого составил структурно-функциональную схему с диаграммой. В ней используется основная частота 125М и немного задержанная 125Md. По спаду последней FSM загружает текущий байт в регистр для дальнейшей выдачи сначала младшего полубайта L и за ним старшего H через ALTDDIO_OUT. Тактовая частота TX_CLK, благодаря отдельному ALTDDIO_OUT, совпадает по фронту и спаду c выдаваемыми полубайтами TXD. Сдвиг на 90 градусов для синхронизаций планирую выполнять в PHY, через его регистры MDIO. 

[Alex11 10]

Что-то у меня ответ на личный вопрос не прошел, копирую сюда.

Вы пока данные не примете, все равно не узнаете, что это интервал между фреймами. Кроме того, мне кажется (слишком давно это было, не помню точно), что скремблер работает всегда и не нужно его рассинхронизировать дополнительными сбросами. А сброс в самом начале никому толком не нужен, все само в синхронизм приходит.

[sazh 9]

7 часов назад, 0608 сказал:

Продолжаю тему. С регистами сдвига я перегнул. По-этому разбираюсь с рекомендуемым вариантом передачи на ядрах ALTDDIO_OUT. Для этого составил структурно-функциональную схему с диаграммой. В ней используется основная частота 125М и немного задержанная 125Md. По спаду последней FSM загружает текущий байт в регистр для дальнейшей выдачи сначала младшего полубайта L и за ним старшего H через ALTDDIO_OUT. Тактовая частота TX_CLK, благодаря отдельному ALTDDIO_OUT, совпадает по фронту и спаду c выдаваемыми полубайтами TXD. Сдвиг на 90 градусов для синхронизаций планирую выполнять в PHY, через его регистры MDIO. 

Я только одно не могу понять. Зачем какие то инверсии. Усложнять жизнь разводчику. Напрягать временной  анализатор. ALTDDIO_OUT по сути серилизатор. Два отсчета в периоде.

Все, что касается данных, ALTDDIO_OUT данных -  работает по переднему фронту от pll0.

Если не двигать, на ALTDDIO_OUT клока этот же клок от pll0.

Если двигать, pll1 той же частоты на ALTDDIO_OUT клока. Хотите сдвигайте, хотите нет.

[BkmZZZzzz 2]

On 10/23/2025 at 1:11 PM, 0608 said:

Вопрос. На сколько этот способ выдачи в RGMII реалистичен.

Такой способ вполне реалистичен. Но раз уж пошла речь об относительно скоростном потоке UDP, то посмотрите в сторону вот этого проекта (интерфейс RGMII, MAC 1G и UDP-стеком для Cyclone IV) - https://github.com/alexforencich/verilog-ethernet/tree/master/example/DE2-115/fpga. В UDP-стек данные надо будет закидывать через AXI Stream, а дальше логика сама всё инкапсулирует в Ethernet-пакет и отправит в PHY по интерфейсу RGMII.

[0608 0]

BkmZZZzzz, спасибо за ссылку. Похоже, в приведенном Вами примере речь идет о стеке LIFO, мною же  рассматривался способ применения очереди FIFO на сдвиговых регистрах, реализуемых на ОЗУ. В обеих случаях выдаче в RGMII предшествует процедура заполнения стека/очереди, а сама выдача выполнется формированием синхро-пачки из N импульсов (по числу выдаваемыых байт). Я еще не определился в выборе способа.

По поводу примера с UDP-стеком для Cyclone IV из GitHub. Что-то там очень много файлов и нет возможности скачать все одним архивом для их подробного изучения. У меня задача использовать готовую плату DE10-Nano (там Cyclone V), которая будет установленна как мезонин на плату аналогового сопряжения и оцифровки. 

[dxp 140]

14 часов назад, 0608 сказал:

По поводу примера с UDP-стеком для Cyclone IV из GitHub. Что-то там очень много файлов и нет возможности скачать все одним архивом для их подробного изучения.

Нужно перейти в корень репозитория, там всё есть:

[0608 0]

dxp, спасибо за подсказку, все скачалось, не знал о такой возможности.

BkmZZZzzz, я понял о каких стеках речь, по этому не обращайте внимания на то что я написал про FIFO и LIFO, это здесь лишнее.

Начал читать GitHub, что там представлено очень круто:

Коллекция компонентов Ethernet для обработки пакетов Gigabit, 10G и 25G (8- и 64-битные каналы передачи данных). Включает модули для обработки кадров Ethernet, а также IP, UDP и ARP, а также компоненты для построения полного стека UDP/IP. Включает MAC-модули для Gigabit и 10G/25G, модуль PHY 10G/25G PCS/PMA и комбинированный модуль MAC/PCS/PMA 10G/25G. Включает различные компоненты PTP для реализации систем, требующих точной синхронизации времени. Также включает полные тестовые стенды Cocotb, использующие Cocotbext-eth.

 

Edited November 5 by 0608