[ADA007 0]

Приветствую всех!

Есть несколько вопросов к гуру по реализации Ethernet на FPGA. Я рассматривал несколько примеров реализации МАС-а для ПЛИС (один - от mentor-a, что на ftp лежит и другой с сайта fpga4fun) и меня смутило несколько моментов:

 

1- Это то, что частоты tx_clk и rx_clk, которые выходят из PHY используются для тактирования регистров, соответствующих веток ПО. Не правильнее было бы использовать для тактирования системную частоту (при условии, что она выше, чем tx_clk и rx_clk) для тактирования регистров, а уже tx_clk и rx_clk использовать в качестве сигнала разрешения? В чем подвох? или я что-то упустил? :laughing:

* Плюс к выше описанному мы получаем разные клоковые домены по веткам приема и передачи в МАС. Потому, что от PHY tx_clk формируется от внешнего кварцевого резонатора, а rx_clk - из несущей частоты в линии связи. Естественно они будут немного отличаться друг от друга, что добавляет проблем.

 

2- Это то, что для тактирования частотами tx_clk и rx_clk было бы неплохо пропустить их предварительно через DCM или хотяб через PLL. Однако, (не знаю , как в других сериях ПЛИС), в Spartan6 на DCM нельзя подать частоту ниже 5 МГц. А для 10 Мб\с по MII надо как раз 2,5 МГц. И как тут быть , если надо реализовать 10\100 МБ\с?

 

[johan 0]

Добрый день!

 

1. Я бы рекомендовал сделать так:

бОльшую часть логики, которая нужна - сделать на системной, а затем через dual clock FIFO перекидывать в нужный домен. В одном из проектов у меня сделано так: на RX_CLK ищем преамбулу и считаем CRC, вся задача - собрать слова из 8 байт - кидаем это слово в FIFO, где уже это разгребается на системной частоте (просто дальше вся обработка идет с 64-битными словами, поэтому делается именно так) Не могу сказать, что это самый прекрасный и идеальный вариант, но вполне рабочий (всё зависит от того, что вы хотите делать с MAC-ядром).

 

Однако, надо предусмотреть, что этих клоков может не быть. Например, можно сделать дополнительный управляющий сигнал для разрешения работы RX или TX (а эту информацию можно получать из статуса линка трансивера).

 

2. Не обязательно. И без этого должно работать. Главное - не забыть про констрейны :)

 

Кстати, на opencores тоже есть MAC-ядра, например: http://opencores.com/project,ethernet_tri_mode

Изменено 7 сентября, 2015 пользователем johan

[Artemius_tv 0]

Посмотрел проект с fpga4fun, там вообще нет интерфейса MII, а реализуется 10Мбит физуровень на FPGA и рассыпухе.

 

Пример mentor'а я не видел, но возможно он старый, когда даже 25МГц были довольно большой частотой для ПЛИС, возможно рассчитан на поддержку скорости 1 Гбит, а может для экономии потребления.

Если все это не ваш случай, то не вижу подвохов использовать фронты tx_clk и rx_clk как сигналы разрешения.

 

[ADA007 0]

1. Я бы рекомендовал сделать так:

....

Кстати, на opencores тоже есть MAC-ядра, например: http://opencores.com/project,ethernet_tri_mode

Спасибо за ответ. Про ресурс OpenCores я знаю. Просто там слишком навороченный МАС, мне и половины его функционала не нужно. Однако, основные вопросы были не по этому поводу.

Возможно я не достаточно четко выразил свою мысль в вопросах. Постараюсь поянить:

1. Вопрос заключается в том, что многие делают именно так (tx_clk и rx_clk используют как тактовый сигнал для входных/выходных регистров работы с PHY, потом мучаются с клоковыми доменами). Но я не встречал еще реализации в которой бы tx_clk и rx_clk использовались только как CE для входных/выходных регистров приема/отправки данных с PHY. Собственно сам вопрос : почему реализованно именно так? может есть какие-то особенности? не лучше ли реализовать так, как я предложил? как вообще правильно клоки с PHY использовать?

2. Для реализации 10/100/1000 нужно заводить разные частоты на МАС ПЛИС 2,5МГц ; 25МГц и 125 МГц .... Вопрос: как правлиьно это сделать , если DCM/PLL ниже 5 МГц не воспринимает?

[likeasm 0]

PHY можно тактировать с PLL FPGA, а не с внешнего кварца.

Также можно использовать не MII, а RMII интерфейс. В этом случае у вас останется одна частота для приема и передачи из phy, она же, если не путаю, входная частота для phy.

 

[Mahagam 0]

1. Вопрос заключается в том, что многие делают именно так (tx_clk и rx_clk используют как тактовый сигнал для входных/выходных регистров работы с PHY, потом мучаются с клоковыми доменами). Но я не встречал еще реализации в которой бы tx_clk и rx_clk использовались только как CE для входных/выходных регистров приема/отправки данных с PHY. Собственно сам вопрос : почему реализованно именно так? может есть какие-то особенности? не лучше ли реализовать так, как я предложил? как вообще правильно клоки с PHY использовать?

2. Для реализации 10/100/1000 нужно заводить разные частоты на МАС ПЛИС 2,5МГц ; 25МГц и 125 МГц .... Вопрос: как правлиьно это сделать , если DCM/PLL ниже 5 МГц не воспринимает?

много лет назад делал MAC. если делать его один на весь чип, и есть свободные линии глобального тактирования - то схема получается весьма компактная, ибо параллельно с потоком данных проходит лишь сигнал "есть пакет/нет пакета".

а когда пришлось сделать 4 MAC на спартане у которого всего 8 глобальных линий (и требовалось ещё отдельно тактировать остальную схему). то пришлось все приёмные части переводить в другой тактовый домен (передатчикам получилась одна частота на всех). и вот с этим переводом пришлось слегка повозиться.

[johan 0]

Постараюсь поянить:

1. Вопрос заключается в том, что многие делают именно так (tx_clk и rx_clk используют как тактовый сигнал для входных/выходных регистров работы с PHY, потом мучаются с клоковыми доменами). Но я не встречал еще реализации в которой бы tx_clk и rx_clk использовались только как CE для входных/выходных регистров приема/отправки данных с PHY. Собственно сам вопрос : почему реализованно именно так? может есть какие-то особенности? не лучше ли реализовать так, как я предложил? как вообще правильно клоки с PHY использовать?

2. Для реализации 10/100/1000 нужно заводить разные частоты на МАС ПЛИС 2,5МГц ; 25МГц и 125 МГц .... Вопрос: как правлиьно это сделать , если DCM/PLL ниже 5 МГц не воспринимает?

1. Если CE - это Clock Enable, то у меня встречный вопрос, а на какой частоте работать-то? Если на какой-то высокой системной, то насколько высокой? И как гарантировать в этом случае тайминги, т.к. Clock Enable и клок будут не синхронны?

2. RX_CLK приходит с трансивера (кстати, какой трансивер у вас в плате стоит?) - после согласования скоростей (или принудительной установки) там будет как раз 2.5/25/125 МГц, так что линия клока одна.

 

Кстати, может есть в интернете примеры для spartan'a (например, для devkit'ов), как они размещают и подключают свой MAC?

Может конкретно у этого семейства/или у Xilinx есть свои нюансы?

 

[Artemius_tv 0]

Непонятно, зачем пропускать rx_clk через DCM/PLL.

Если нужно сдвинуть клок и данные относительно друг друга, то в Spartan-6 есть IODELAY2.

Если для "правильности", то у Xilinx, например, есть пример RGMII, там они берут rx_clk напрямую, без PLL.

На rx_clk можно вообще практически ничего не делать, только складывать данные в FIFO, тогда можно rx_clk завести на региональный, а не глобальный клок. А всю обработку делать на внутреннем системном клоке после FIFO.

 

[ADA007 0]

Микросхему PHY использую LAN8810. Частота, на которой будет работать часть схемы приемо-передатчика 200 МГц планируется.

Кстати, может есть в интернете примеры для spartan'a (например, для devkit'ов), как они размещают и подключают свой MAC?

Собственно в этом-то и суть, чтоб понять как подключить правильно. Прошу помощи в поиске вариантов...+ обоснований к ним, почему это правильно.

Непонятно, зачем пропускать rx_clk через DCM/PLL.

Частоту 2,5 МГц - может и нет смысле пропускать через DCM. А вот 25 МГц и 125МГц - мне кажется, что есть смысл. Не зря ведь во всех примерах Xilinx пропускают системную частоту, на кот. работает проект, через DCM/PLL. Мне казалось, что это для того, чтоб компенсировать ppm генератора. Для PHY то же установлены пределы ppm, это ж не идеальный генератор. Или я заблуждаюсь? И можно частоту от PHY напрямую заводить, даже не через GBUF???

 

Да, можно

на rx_clk можно вообще практически ничего не делать,

Но почему тогда в указанных мной выше примерах (а может и не только в них, а еще где-то) сделано совсем наоборот и эта частота заходит на весь тракт приема, как клок? Или это они просто неправильно сделали? Или в ПЛИС этот момент вообще не принципиален?

[likeasm 0]

Для PHY то же установлены пределы ppm, это ж не идеальный генератор. Или я заблуждаюсь? И можно частоту от PHY напрямую заводить, даже не через GBUF???

У вашей PHY внутри есть PLL, какой смысл подстраивать подстроенную частоту?

[Golikov 0]

И как плл поправит ппм генератора, если она

от него считает?

[ADA007 0]

И правда, заблуждаюсь. :laughing:

[Artemius_tv 0]

Микросхему PHY использую LAN8810. Частота, на которой будет работать часть схемы приемо-передатчика 200 МГц планируется.

Раз ethernet гигабитный, то rx_clk получится использовать только как клок, слишком частота большая. Т.е. вопрос о использовании rx_clk и tx_clk как сигналы разрешения снят.

 

Да, можно Но почему тогда в указанных мной выше примерах (а может и не только в них, а еще где-то) сделано совсем наоборот и эта частота заходит на весь тракт приема, как клок? Или это они просто неправильно сделали? Или в ПЛИС этот момент вообще не принципиален?

Все равно нужно будет передавать данные с частоты PHY на системную через FIFO, а в каком месте удобнее делать переход - зависит от проекта. В ваших примерах делали законченный универсальный MAC-контроллер, вот и затактировали его от rx_clk и tx_clk. Если, например, нужно прицепить много PHY, то такое решение может оказаться слишком расточительным по ресурсам, как в примере Mahagam.

 

Кстати, а почему решили использовать PHY с GMII, а не RGMII?

 

Изменено 14 сентября, 2015 пользователем Artemius_tv

[likeasm 0]

Кстати, а почему решили использовать PHY с GMII, а не RGMII?

В LAN8810 только GMII, RGMII имеется в LAN8820