Всем добрый день! Может кто-нить поднимал на ПЛИС 10G Ethernet? Какие ПЛИС использовали для этого, и какие отладочные платы и каких производителей можете порекомендовать?
Заранее спасибо!
Полная версия этой страницы: FPGA для работы с 10G Ethernet
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Цитата(gin @ Dec 5 2016, 14:56) 
Всем добрый день! Может кто-нить поднимал на ПЛИС 10G Ethernet? Какие ПЛИС использовали для этого, и какие отладочные платы и каких производителей можете порекомендовать?
Заранее спасибо!
Заранее спасибо!
Для современных ПЛИС 10G вообще не скорость.
Если хотите поднять десятку на low-end (циклоны/спартаны), то берете плис с 4x3.125 трансиверами, ставите внешний XAUI PHY и вперед.
Более кошерный вариант - брать плис с 10G трансиверами (арии, кинтексы, стратиксы, виктексы). Там внешний PHY не понадобится.
Цитата(goodsoul @ Dec 5 2016, 17:01)
Для современных ПЛИС 10G вообще не скорость.
Если хотите поднять десятку на low-end (циклоны/спартаны), то берете плис с 4x3.125 трансиверами, ставите внешний XAUI PHY и вперед.
Более кошерный вариант - брать плис с 10G трансиверами (арии, кинтексы, стратиксы, виктексы). Там внешний PHY не понадобится.
Если хотите поднять десятку на low-end (циклоны/спартаны), то берете плис с 4x3.125 трансиверами, ставите внешний XAUI PHY и вперед.
Более кошерный вариант - брать плис с 10G трансиверами (арии, кинтексы, стратиксы, виктексы). Там внешний PHY не понадобится.
10G - это для начала, потом нужно 40G. Просто, как я понимаю, там должна быть оптика, а значит должны быть модули SFP или QSFP. И вот пока не очень понятно, как должно быть организовано взаимодействие ПЛИС с этими модулями.
Вот собственно и смотрю в сторону Arria 10, есть там интересный вариант с QSFP+, но для меня не очень понятно как обрабатывать от них данные. Там же от каждой QSFP идут 4 линии на ПЛИС, и как тот же Ethernet трафик по ним распределяется, и как его собирать затем в пакеты
Приветствую!
А для этого Вам нужно в FPGA сделать 10/40G PCS/PMA корку чтобы через MGT трансиверы можно было подключится к QSFP+ и в придачу 10/40G MAC controler который и будет принимать и отправлять пакеты.
Посмотрите примеры реализации и даташиты корок 10/40G на сайте производителя FPGA которую Вы выберете - там все понятно будет.
Удачи! Rob.
Цитата(gin @ Dec 5 2016, 17:12)
10G - это для начала, потом нужно 40G. Просто, как я понимаю, там должна быть оптика, а значит должны быть модули SFP или QSFP. И вот пока не очень понятно, как должно быть организовано взаимодействие ПЛИС с этими модулями.
Вот собственно и смотрю в сторону Arria 10, есть там интересный вариант с QSFP+, но для меня не очень понятно как обрабатывать от них данные. Там же от каждой QSFP идут 4 линии на ПЛИС, и как тот же Ethernet трафик по ним распределяется, и как его собирать затем в пакеты
Вот собственно и смотрю в сторону Arria 10, есть там интересный вариант с QSFP+, но для меня не очень понятно как обрабатывать от них данные. Там же от каждой QSFP идут 4 линии на ПЛИС, и как тот же Ethernet трафик по ним распределяется, и как его собирать затем в пакеты
А для этого Вам нужно в FPGA сделать 10/40G PCS/PMA корку чтобы через MGT трансиверы можно было подключится к QSFP+ и в придачу 10/40G MAC controler который и будет принимать и отправлять пакеты.
Посмотрите примеры реализации и даташиты корок 10/40G на сайте производителя FPGA которую Вы выберете - там все понятно будет.
Удачи! Rob.
Цитата(RobFPGA @ Dec 5 2016, 17:39)
Приветствую!
А для этого Вам нужно в FPGA сделать 10/40G PCS/PMA корку чтобы через MGT трансиверы можно было подключится к QSFP+ и в придачу 10/40G MAC controler который и будет принимать и отправлять пакеты.
Посмотрите примеры реализации и даташиты корок 10/40G на сайте производителя FPGA которую Вы выберете - там все понятно будет.
Удачи! Rob.
А для этого Вам нужно в FPGA сделать 10/40G PCS/PMA корку чтобы через MGT трансиверы можно было подключится к QSFP+ и в придачу 10/40G MAC controler который и будет принимать и отправлять пакеты.
Посмотрите примеры реализации и даташиты корок 10/40G на сайте производителя FPGA которую Вы выберете - там все понятно будет.
Удачи! Rob.
Спасибо! Правильно ли я понял. что для работы с SFP (до 10G) корки никакие не нужны, а нужно только использовать встроенные в ПЛИС сериалайзеры/десериалайзеры. А для работы с QSFP нужно писать еще дополнительную корку. И предоставляют ли такие корки производители ПЛИС?
Цитата(gin @ Dec 5 2016, 16:48)
Спасибо! Правильно ли я понял. что для работы с SFP (до 10G) корки никакие не нужны, а нужно только использовать встроенные в ПЛИС сериалайзеры/десериалайзеры. А для работы с QSFP нужно писать еще дополнительную корку. И предоставляют ли такие корки производители ПЛИС?
посмотрите пример
Приветствую!
Нет не правильно - не важно для какой скорости - если упрощенно то в любом случае нужно будет иметь как минимум
1 PHY уровень - для 10/40G это модуль MGT трансиверов,
2 Physical Coding/Attachment Sub-layer - для 10/40G это корка PCS/PMA - кодирование, синхронизация канала, поднятие линка,
3 Media access layer- отправка/прием пакетов, для 10/40G это корка MAC контроллера
4 ...
......
Если есть финансы то писать нужно будет только сумму в счете
а не корки.
Успехов! Rob.
Цитата(gin @ Dec 5 2016, 17:48)
Спасибо! Правильно ли я понял. что для работы с SFP (до 10G) корки никакие не нужны, а нужно только использовать встроенные в ПЛИС сериалайзеры/десериалайзеры. А для работы с QSFP нужно писать еще дополнительную корку. И предоставляют ли такие корки производители ПЛИС?
Нет не правильно - не важно для какой скорости - если упрощенно то в любом случае нужно будет иметь как минимум
1 PHY уровень - для 10/40G это модуль MGT трансиверов,
2 Physical Coding/Attachment Sub-layer - для 10/40G это корка PCS/PMA - кодирование, синхронизация канала, поднятие линка,
3 Media access layer- отправка/прием пакетов, для 10/40G это корка MAC контроллера
4 ...
......
Если есть финансы то писать нужно будет только сумму в счете
а не корки. Успехов! Rob.
Цитата(RobFPGA @ Dec 5 2016, 18:19)
Приветствую!
Нет не правильно - не важно для какой скорости - если упрощенно то в любом случае нужно будет иметь как минимум
1 PHY уровень - для 10/40G это модуль MGT трансиверов,
2 Physical Coding/Attachment Sub-layer - для 10/40G это корка PCS/PMA - кодирование, синхронизация канала, поднятие линка,
3 Media access layer- отправка/прием пакетов, для 10/40G это корка MAC контроллера
4 ...
......
Если есть финансы то писать нужно будет только сумму в счете а не корки.
Успехов! Rob.
Нет не правильно - не важно для какой скорости - если упрощенно то в любом случае нужно будет иметь как минимум
1 PHY уровень - для 10/40G это модуль MGT трансиверов,
2 Physical Coding/Attachment Sub-layer - для 10/40G это корка PCS/PMA - кодирование, синхронизация канала, поднятие линка,
3 Media access layer- отправка/прием пакетов, для 10/40G это корка MAC контроллера
4 ...
......
Если есть финансы то писать нужно будет только сумму в счете
а не корки. Успехов! Rob.
Вот теперь я точно запутался!
В свое время приходилось немного сталкиваться с SDH/SONET, частоты там были ниже (2,4 Гб/с), но суть была похожа. На входе стояли SFP, которые были подключены к ПЛИС. В ПЛИС я использовал аппаратный десериализатор чтобы получить уже параллельную шину (16 бит вроде) внутри ПЛИС. Далее остальную обработку делал сам. Я думал, что что то похожее будет с Ethernet, только частоты выше. Или я полностью неправ оказался?
Спасибо!
Цитата(gin @ Dec 5 2016, 18:33)
Вот теперь я точно запутался!
В свое время приходилось немного сталкиваться с SDH/SONET, частоты там были ниже (2,4 Гб/с), но суть была похожа. На входе стояли SFP, которые были подключены к ПЛИС. В ПЛИС я использовал аппаратный десериализатор чтобы получить уже параллельную шину (16 бит вроде) внутри ПЛИС. Далее остальную обработку делал сам. Я думал, что что то похожее будет с Ethernet, только частоты выше. Или я полностью неправ оказался?
Спасибо!
В свое время приходилось немного сталкиваться с SDH/SONET, частоты там были ниже (2,4 Гб/с), но суть была похожа. На входе стояли SFP, которые были подключены к ПЛИС. В ПЛИС я использовал аппаратный десериализатор чтобы получить уже параллельную шину (16 бит вроде) внутри ПЛИС. Далее остальную обработку делал сам. Я думал, что что то похожее будет с Ethernet, только частоты выше. Или я полностью неправ оказался?
Спасибо!
Всё именно так как у Вас было с SDH. Более того, какие-то вещи уже реализованы в ПЛИС аппаратно, какие-то в виде альтеровских мегафункций(за xilinx не скажу, но думаю там также). При желании можете оставить только SerDes, а остальное сделать самостоятельно.
Другое дело, что на скоростях 40G к самой плате предъявляются более жёсткие требования, чем к плате на 2,5G.
Цитата(DuHast @ Dec 12 2016, 16:17)
Всё именно так как у Вас было с SDH. Более того, какие-то вещи уже реализованы в ПЛИС аппаратно, какие-то в виде альтеровских мегафункций(за xilinx не скажу, но думаю там также). При желании можете оставить только SerDes, а остальное сделать самостоятельно.
Другое дело, что на скоростях 40G к самой плате предъявляются более жёсткие требования, чем к плате на 2,5G.
Другое дело, что на скоростях 40G к самой плате предъявляются более жёсткие требования, чем к плате на 2,5G.
Спасибо! Насмотрел я одну плату, там как раз Altera, сейчас разбираюсь, что предоставляет Quartus и какие IP там есть. Единственное, что как всегда напрягает - то что сам стандарт на 10G Ethernet платный. Приходится лазить и искать информацию по Интернету. Но это мне не в первой)
Цитата
стандарт на 10G Ethernet платный
это вы про что?
http://standards.ieee.org/getieee802/download/802.3-2015.zip
Вот здесь указываете свой (любой) email и скачиваете архив. Там в 802.3-2015_SECTION4.pdf раздел 49 описывает 10G.
Цитата(novartis @ Dec 14 2016, 19:32)
это вы про что?
http://standards.ieee.org/getieee802/download/802.3-2015.zip
Вот здесь указываете свой (любой) email и скачиваете архив. Там в 802.3-2015_SECTION4.pdf раздел 49 описывает 10G.
http://standards.ieee.org/getieee802/download/802.3-2015.zip
Вот здесь указываете свой (любой) email и скачиваете архив. Там в 802.3-2015_SECTION4.pdf раздел 49 описывает 10G.
Спасибо! Вчера даже его скачал, но не успел посмотреть толком. Если там все описано подробно, то это замечательно. А то уже привык, что большинство стандартов платные
Продолжаю разбираться с 10G.
Так как буду использовать Альтеру, то пишу про нее. Как я понял, в Аррие и Стратиксе есть аппаратные блоки, предназначенные специально для работы с 10G Ethernet. Они включают в себя сериализатор/десериализатор, кодер/декодер 64/66b и скремблер. То есть на выход мне выдается уже готовый поток данных 64 бита, которые разбиты на группы по 8 байт + 8 управляющих сигналов. Для работы с этими аппаратными блоками предназначено IP 10GBASE-R PHY. На выходе которого и появляются эти данные.
Правильно ли я понимаю, что:
1. Это IP (ну то есть аппаратное ядро) восстанавливает клок и выдает данные по его фронту (156.25 МГц).
2. Выходные данные уже разбиты на байты. То есть байты Ethernet пакета строго идут по соответствующим линиям. (7..0, 16..9, и т.д.)
Теперь вопросы:
1. Если этот аппартаный блок восстанавливает частоту, то зачем нужно его тактировать внешним клоком с той же номинальной частотой?
2. Управляющие сигналы (8 бит). Показывают ли они, что принятые байты - это данные либо управляющие символы Ethernet, такие как - Idle, Start, Terminate, Error. Или они означают что то иное?
Заранее спасибо всем тем кто потратит свое время и прокоментирует мое сообщение))
Так как буду использовать Альтеру, то пишу про нее. Как я понял, в Аррие и Стратиксе есть аппаратные блоки, предназначенные специально для работы с 10G Ethernet. Они включают в себя сериализатор/десериализатор, кодер/декодер 64/66b и скремблер. То есть на выход мне выдается уже готовый поток данных 64 бита, которые разбиты на группы по 8 байт + 8 управляющих сигналов. Для работы с этими аппаратными блоками предназначено IP 10GBASE-R PHY. На выходе которого и появляются эти данные.
Правильно ли я понимаю, что:
1. Это IP (ну то есть аппаратное ядро) восстанавливает клок и выдает данные по его фронту (156.25 МГц).
2. Выходные данные уже разбиты на байты. То есть байты Ethernet пакета строго идут по соответствующим линиям. (7..0, 16..9, и т.д.)
Теперь вопросы:
1. Если этот аппартаный блок восстанавливает частоту, то зачем нужно его тактировать внешним клоком с той же номинальной частотой?
2. Управляющие сигналы (8 бит). Показывают ли они, что принятые байты - это данные либо управляющие символы Ethernet, такие как - Idle, Start, Terminate, Error. Или они означают что то иное?
Заранее спасибо всем тем кто потратит свое время и прокоментирует мое сообщение))
Здравствуйте. А не прокомментирует ли кто-нибудь, почему у Ксайлинкса встроенное 1G Ethernet ядро есть только у Virtex 4,5,6 , а начиная с седьмой серии его нет, а софт-ядро платное, а 10G платное для всех? И как с этим делом у Альтеры дела обстоят?
Цитата(gin @ Dec 16 2016, 10:27)
1. Если этот аппартаный блок восстанавливает частоту, то зачем нужно его тактировать внешним клоком с той же номинальной частотой?
Прошу прощения, не понял о каком блоке идет речь? Исходя из моего скромного понимания, частота в линии может быть произвольной и даже меняться со временем (от температуры например), поэтому к ней надо подстраиваться (реклокинг). Основная системная частота должна оставаться относительно стабильной. Меня вот эта книжка по этой тематике порадовала: http://www.xilinx.com/publications/archive...ks/serialio.pdf
Цитата(AVR @ Dec 16 2016, 10:44)
Прошу прощения, не понял о каком блоке идет речь? Исходя из моего скромного понимания, частота в линии может быть произвольной и даже меняться со временем (от температуры например), поэтому к ней надо подстраиваться (реклокинг). Основная системная частота должна оставаться относительно стабильной. Меня вот эта книжка по этой тематике порадовала: http://www.xilinx.com/publications/archive...ks/serialio.pdf
У Альтеровского IP 10GBASE-R PHY есть два клока:
1. xgmii_rx_clk - судя по всему это клок, по фронту которого выдаются данные. Как я понимаю, он восстанавливается из входного 10G сигнала.
2. pll_ref_clk - еще один клоковый вход. Вот не очень понимаю для чего он
Цитата(gin @ Dec 16 2016, 10:52)
У Альтеровского IP 10GBASE-R PHY есть два клока:
1. xgmii_rx_clk - судя по всему это клок, по фронту которого выдаются данные. Как я понимаю, он восстанавливается из входного 10G сигнала.
2. pll_ref_clk - еще один клоковый вход. Вот не очень понимаю для чего он
1. xgmii_rx_clk - судя по всему это клок, по фронту которого выдаются данные. Как я понимаю, он восстанавливается из входного 10G сигнала.
2. pll_ref_clk - еще один клоковый вход. Вот не очень понимаю для чего он
Судя по доке, второй вроде как основной (ведь есть не только прием но и передача - а там от чего референситься?).
Первый - вообще другой частоты и там написано что его можно использовать чтобы минимизировать размеры FIFO, а то при некотором расхождении частот видимо может много набежать в фифошку. Ну это мои предположения, наверное мне не стоило комментировать в теме...
Цитата(AVR @ Dec 16 2016, 11:24)
Судя по доке, второй вроде как основной (ведь есть не только прием но и передача - а там от чего референситься?).
Первый - вообще другой частоты и там написано что его можно использовать чтобы минимизировать размеры FIFO, а то при некотором расхождении частот видимо может много набежать в фифошку. Ну это мои предположения, наверное мне не стоило комментировать в теме...
Первый - вообще другой частоты и там написано что его можно использовать чтобы минимизировать размеры FIFO, а то при некотором расхождении частот видимо может много набежать в фифошку. Ну это мои предположения, наверное мне не стоило комментировать в теме...
Сейчас разбираюсь с документацией по этому вопросу, как я понял, он необходим для работы сериализаторов, и там только 2 варианта.
Из User Guide:
For Arria V and Stratix V devices, the TX PLL
reference clock can be either 644.53125 MHz
or 322.265625 MHz
1. Если этот аппартаный блок восстанавливает частоту, то зачем нужно его тактировать внешним клоком с той же номинальной частотой?
RX часть восстанавливает клок из входных данных.
TX часть работает на своей (по значению такой же) частоте, ей нужно подать референс клок.
2. Управляющие сигналы (8 бит). Показывают ли они, что принятые байты - это данные либо управляющие символы Ethernet, такие как - Idle, Start, Terminate, Error. Или они означают что то иное?
Это они и означают, в IEEE 802.3 clause 49 расписана табличка 49-1 - Control codes
RX часть восстанавливает клок из входных данных.
TX часть работает на своей (по значению такой же) частоте, ей нужно подать референс клок.
2. Управляющие сигналы (8 бит). Показывают ли они, что принятые байты - это данные либо управляющие символы Ethernet, такие как - Idle, Start, Terminate, Error. Или они означают что то иное?
Это они и означают, в IEEE 802.3 clause 49 расписана табличка 49-1 - Control codes
Цитата(novartis @ Dec 16 2016, 11:48)
1. Если этот аппартаный блок восстанавливает частоту, то зачем нужно его тактировать внешним клоком с той же номинальной частотой?
RX часть восстанавливает клок из входных данных.
TX часть работает на своей (по значению такой же) частоте, ей нужно подать референс клок.
2. Управляющие сигналы (8 бит). Показывают ли они, что принятые байты - это данные либо управляющие символы Ethernet, такие как - Idle, Start, Terminate, Error. Или они означают что то иное?
Это они и означают, в IEEE 802.3 clause 49 расписана табличка 49-1 - Control codes
RX часть восстанавливает клок из входных данных.
TX часть работает на своей (по значению такой же) частоте, ей нужно подать референс клок.
2. Управляющие сигналы (8 бит). Показывают ли они, что принятые байты - это данные либо управляющие символы Ethernet, такие как - Idle, Start, Terminate, Error. Или они означают что то иное?
Это они и означают, в IEEE 802.3 clause 49 расписана табличка 49-1 - Control codes
Спасибо! То есть я правильно понимаю, что если я использую только принимающую часть (ставлю параметр rx_only), то референс клок вообще не нужен? Что в таком случае нужно подавать на порт pll_ref_clk?
Это конечно логично, но вот при настройке в визарде этой корки при выборе rx_only сигнал pll_ref_clk не исчезает. К тому же в xcvr_user_guide.pdf есть такая картинка:
Нажмите для просмотра прикрепленного файла
То есть реф клок все таки в приемной части у них задейстован ( в их реализации pcs)
Нажмите для просмотра прикрепленного файла
То есть реф клок все таки в приемной части у них задейстован ( в их реализации pcs)
Цитата(novartis @ Dec 16 2016, 12:16)
Это конечно логично, но вот при настройке в визарде этой корки при выборе rx_only сигнал pll_ref_clk не исчезает. К тому же в xcvr_user_guide.pdf есть такая картинка:
Нажмите для просмотра прикрепленного файла
То есть реф клок все таки в приемной части у них задейстован ( в их реализации pcs)
Нажмите для просмотра прикрепленного файла
То есть реф клок все таки в приемной части у них задейстован ( в их реализации pcs)
Вот пытаюсь собрать в Quartus элементарную схему.
Прием 10G -> Передача 10G без всякой обработки.
Для приемника и передатчика использую корку 10GBASE-R PHY. Приемник имеет параметр rx_only, передатчик tx_only соответственно. Есть pll, который задает реф клок 322,265625 для передатчика. Но Quartus отказывается это собирать. Причем ругается именно на приемник.
Код
Error (14996): The Fitter failed to find a legal placement for all periphery components
Error (14986): After placing as many components as possible, the following errors remain:
Error (175001): Could not place HSSI PMA CDR REFCLK Select Mux, which is within 10GBASE-R PHY rx_10GBASE_R_PHY
Info (14596): Information about the failing component:
Info (175028): The HSSI PMA CDR REFCLK Select Mux name: rx_10GBASE_R_PHY:rx_10GBASE_R_PHY_inst|altera_xcvr_10gbaser:rx_10gbase_r_phy_ins
t|sv_xcvr_10gbaser_nr:xv_xcvr_10gbaser_nr_inst|sv_xcvr_10gbaser_native:ch[0].sv_x
cvr_10gbaser_native_inst|sv_xcvr_native:native_inst|sv_pma:inst_sv_pma|sv_rx_pma:
rx_pma.sv_rx_pma_inst|rx_pmas[0].rx_pma.cdr_refclk_mux0
Info (14597): No legal location could be found for this component out of 54 considered location(s). Reasons why each location could not be used are summarized below:
Error (175006): Could not find path between source fractional PLL and the Receiver channel
Info (175026): Source: fractional PLL rx_10GBASE_R_PHY:rx_10GBASE_R_PHY_inst|altera_xcvr_10gbaser:rx_10gbase_r_phy_ins
t|sv_xcvr_10gbaser_nr:xv_xcvr_10gbaser_nr_inst|sv_xcvr_10gbaser_native:ch[0].sv_x
cvr_10gbaser_native_inst|g_fpll.altera_pll_156M~FRACTIONAL_PLL
Info (175021): The fractional PLL was placed in location FRACTIONALPLL_X0_Y55_N0
Error (175022): The Receiver channel could not be placed in any location to satisfy its connectivity requirements
Info (175029): 18 locations affected
Info (175029): Receiver channel containing PIN_AV2
Info (175029): Receiver channel containing PIN_AT2
Info (175029): Receiver channel containing PIN_AP2
Info (175029): Receiver channel containing PIN_AM2
Info (175029): Receiver channel containing PIN_AK2
Info (175029): Receiver channel containing PIN_AH2
Info (175029): Receiver channel containing PIN_AF2
Info (175029): Receiver channel containing PIN_AD2
Info (175029): Receiver channel containing PIN_AB2
Info (175029): Receiver channel containing PIN_Y2
Info (175029): Receiver channel containing PIN_V2
Info (175029): Receiver channel containing PIN_T2
Info (175029): and 6 more locations not displayed
Error (175003): The I/O pad location is occupied (18 locations affected)
Info (175029): PIN_D39
Info (175029): PIN_F39
Info (175029): PIN_H39
Info (175029): PIN_K39
Info (175029): PIN_M39
Info (175029): PIN_P39
Info (175029): PIN_T39
Info (175029): PIN_V39
Info (175029): PIN_Y39
Info (175029): PIN_AB39
Info (175029): PIN_AD39
Info (175029): PIN_AF39
Info (175029): and 6 more locations not displayed
Error (175007): Could not find uncongested path between source PLL output counter and the HSSI PMA CDR REFCLK Select Mux
Info (175026): Source: PLL output counter rx_10GBASE_R_PHY:rx_10GBASE_R_PHY_inst|altera_xcvr_10gbaser:rx_10gbase_r_phy_ins
t|sv_xcvr_10gbaser_nr:xv_xcvr_10gbaser_nr_inst|sv_xcvr_10gbaser_native:ch[0].sv_x
cvr_10gbaser_native_inst|g_fpll.altera_pll_156M~PLL_OUTPUT_COUNTER
Info (175021): The PLL output counter was placed in location PLLOUTPUTCOUNTER_X0_Y52_N1
Error (175022): The HSSI PMA CDR REFCLK Select Mux could not be placed in any location to satisfy its connectivity requirements
Info (175029): 18 locations affected
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y14_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y18_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y22_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y26_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y30_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y34_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y38_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y42_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y46_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y50_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y54_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y58_N39
Info (175029): and 6 more locations not displayed
Error (14986): After placing as many components as possible, the following errors remain:
Error (175001): Could not place HSSI PMA CDR REFCLK Select Mux, which is within 10GBASE-R PHY rx_10GBASE_R_PHY
Info (14596): Information about the failing component:
Info (175028): The HSSI PMA CDR REFCLK Select Mux name: rx_10GBASE_R_PHY:rx_10GBASE_R_PHY_inst|altera_xcvr_10gbaser:rx_10gbase_r_phy_ins
t|sv_xcvr_10gbaser_nr:xv_xcvr_10gbaser_nr_inst|sv_xcvr_10gbaser_native:ch[0].sv_x
cvr_10gbaser_native_inst|sv_xcvr_native:native_inst|sv_pma:inst_sv_pma|sv_rx_pma:
rx_pma.sv_rx_pma_inst|rx_pmas[0].rx_pma.cdr_refclk_mux0
Info (14597): No legal location could be found for this component out of 54 considered location(s). Reasons why each location could not be used are summarized below:
Error (175006): Could not find path between source fractional PLL and the Receiver channel
Info (175026): Source: fractional PLL rx_10GBASE_R_PHY:rx_10GBASE_R_PHY_inst|altera_xcvr_10gbaser:rx_10gbase_r_phy_ins
t|sv_xcvr_10gbaser_nr:xv_xcvr_10gbaser_nr_inst|sv_xcvr_10gbaser_native:ch[0].sv_x
cvr_10gbaser_native_inst|g_fpll.altera_pll_156M~FRACTIONAL_PLL
Info (175021): The fractional PLL was placed in location FRACTIONALPLL_X0_Y55_N0
Error (175022): The Receiver channel could not be placed in any location to satisfy its connectivity requirements
Info (175029): 18 locations affected
Info (175029): Receiver channel containing PIN_AV2
Info (175029): Receiver channel containing PIN_AT2
Info (175029): Receiver channel containing PIN_AP2
Info (175029): Receiver channel containing PIN_AM2
Info (175029): Receiver channel containing PIN_AK2
Info (175029): Receiver channel containing PIN_AH2
Info (175029): Receiver channel containing PIN_AF2
Info (175029): Receiver channel containing PIN_AD2
Info (175029): Receiver channel containing PIN_AB2
Info (175029): Receiver channel containing PIN_Y2
Info (175029): Receiver channel containing PIN_V2
Info (175029): Receiver channel containing PIN_T2
Info (175029): and 6 more locations not displayed
Error (175003): The I/O pad location is occupied (18 locations affected)
Info (175029): PIN_D39
Info (175029): PIN_F39
Info (175029): PIN_H39
Info (175029): PIN_K39
Info (175029): PIN_M39
Info (175029): PIN_P39
Info (175029): PIN_T39
Info (175029): PIN_V39
Info (175029): PIN_Y39
Info (175029): PIN_AB39
Info (175029): PIN_AD39
Info (175029): PIN_AF39
Info (175029): and 6 more locations not displayed
Error (175007): Could not find uncongested path between source PLL output counter and the HSSI PMA CDR REFCLK Select Mux
Info (175026): Source: PLL output counter rx_10GBASE_R_PHY:rx_10GBASE_R_PHY_inst|altera_xcvr_10gbaser:rx_10gbase_r_phy_ins
t|sv_xcvr_10gbaser_nr:xv_xcvr_10gbaser_nr_inst|sv_xcvr_10gbaser_native:ch[0].sv_x
cvr_10gbaser_native_inst|g_fpll.altera_pll_156M~PLL_OUTPUT_COUNTER
Info (175021): The PLL output counter was placed in location PLLOUTPUTCOUNTER_X0_Y52_N1
Error (175022): The HSSI PMA CDR REFCLK Select Mux could not be placed in any location to satisfy its connectivity requirements
Info (175029): 18 locations affected
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y14_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y18_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y22_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y26_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y30_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y34_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y38_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y42_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y46_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y50_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y54_N39
Info (175029): HSSIPMACDRREFCLKSELECTMUX_X0_Y58_N39
Info (175029): and 6 more locations not displayed
И как я понимаю, основная проблема как раз этот самый реф клок для приемника
к pll_ref_clk особое отношение. нельзя просто так взять и на него подать сигнал из логики ПЛИС.
Нужно подать тот же pll_ref_clk, что и на tx идет. Но возможно такое не прокатит, будет что нибудь писать типа не могу разместить несколько HSSI в одном триплете.
а зачем вам такая реализация?
Сгенерите один 10GBASE-R, выход rx подайте на вход tx.
Нужно подать тот же pll_ref_clk, что и на tx идет. Но возможно такое не прокатит, будет что нибудь писать типа не могу разместить несколько HSSI в одном триплете.
а зачем вам такая реализация?
Сгенерите один 10GBASE-R, выход rx подайте на вход tx.
Цитата(novartis @ Dec 16 2016, 12:37)
к pll_ref_clk особое отношение. нельзя просто так взять и на него подать сигнал из логики ПЛИС.
Нужно подать тот же pll_ref_clk, что и на tx идет. Но возможно такое не прокатит, будет что нибудь писать типа не могу разместить несколько HSSI в одном триплете.
а зачем вам такая реализация?
Сгенерите один 10GBASE-R, выход rx подайте на вход tx.
Нужно подать тот же pll_ref_clk, что и на tx идет. Но возможно такое не прокатит, будет что нибудь писать типа не могу разместить несколько HSSI в одном триплете.
а зачем вам такая реализация?
Сгенерите один 10GBASE-R, выход rx подайте на вход tx.
подавал клок с того же pll на tx и на rx. Тоже выдает ошибку. Тем более в будущем проекте у меня должно быть несколько модулей rx и только один tx.
И эти rx будут независимы друг от друга и от tx. Пока не понимаю как это реализовать. Да и вообще может быть такой вариант, что tx нет, например данные будут на PCI уходить. Как в таком случае быть?
У корки можно указать, сколько каналов будет. Например укажите 5 каналов. Заведете один pll_ref_clk, будет у вас 5 rx, 5 tx.
Не нужны tx - тогда ставьте опцию rx_only, но реф клок все равно подавать надо.
Если надо 5 rx, 1 tx, то создаете 5 rx, 5 tx (4 не используете).
Не нужны tx - тогда ставьте опцию rx_only, но реф клок все равно подавать надо.
Если надо 5 rx, 1 tx, то создаете 5 rx, 5 tx (4 не используете).
Цитата(novartis @ Dec 16 2016, 12:47)
У корки можно указать, сколько каналов будет. Например укажите 5 каналов. Заведете один pll_ref_clk, будет у вас 5 rx, 5 tx.
Не нужны tx - тогда ставьте опцию rx_only, но реф клок все равно подавать надо.
Если надо 5 rx, 1 tx, то создаете 5 rx, 5 tx (4 не используете).
Не нужны tx - тогда ставьте опцию rx_only, но реф клок все равно подавать надо.
Если надо 5 rx, 1 tx, то создаете 5 rx, 5 tx (4 не используете).
Но ведь у всех этих rx разные источники. И восстановленные клоки xgmii_rx_clk должны быть разные. А он создает только один клок для любого количества каналов. В общем что то я недопонимаю
Нажмите для просмотра прикрепленного файла
xgmii_rx_clk у них у всех одинаковые, получены из pll_ref_clock.
В pcs каждого канала данные приходят на своей собственной восстановленной частоте rx_pma_clk (конкретно на этом рисунке 257.8125МГц).
Внутри pcs производится переход с частоты rx_pma_clk на частоту xgmii_rx_clk, наверно с помощью фифо.
xgmii_rx_clk у них у всех одинаковые, получены из pll_ref_clock.
В pcs каждого канала данные приходят на своей собственной восстановленной частоте rx_pma_clk (конкретно на этом рисунке 257.8125МГц).
Внутри pcs производится переход с частоты rx_pma_clk на частоту xgmii_rx_clk, наверно с помощью фифо.
Цитата(novartis @ Dec 16 2016, 12:59)
Нажмите для просмотра прикрепленного файла
xgmii_rx_clk у них у всех одинаковые, получены из pll_ref_clock.
В pcs каждого канала данные приходят на своей собственной восстановленной частоте rx_pma_clk (конкретно на этом рисунке 257.8125МГц).
Внутри pcs производится переход с частоты rx_pma_clk на частоту xgmii_rx_clk, наверно с помощью фифо.
xgmii_rx_clk у них у всех одинаковые, получены из pll_ref_clock.
В pcs каждого канала данные приходят на своей собственной восстановленной частоте rx_pma_clk (конкретно на этом рисунке 257.8125МГц).
Внутри pcs производится переход с частоты rx_pma_clk на частоту xgmii_rx_clk, наверно с помощью фифо.
Спасибо за помощь! Сейчас попробую создать полную версию (rx и tx) может там заработает
Удалил PLL, завел реф клок извне и собралось все без ошибок. Видимо какая то проблема в неправильных настройках PLL
Скачал с AlteraWiki архив с проектом, где используется ядро 10GBASE-R PHY. И там действительно для формирования сигнала не используется PLL. Сигнал заводится снаружи. Как то странно зачем гнать извне высокочастотный клок (322 или 644 МГц)? Неужели нельзя умножить внутри, или PLL вносит слишком большие искажения?
После пролистывания темы: предлагаю автору начать с 1G на обычном SFP. Многое станет понятно, потом и на 10G можно переходить.
Запускать это все оптимально на отладочной плате, на них на всех почти слоты под SFP устанавливают.
Запускать это все оптимально на отладочной плате, на них на всех почти слоты под SFP устанавливают.
Цитата(Koluchiy @ Dec 16 2016, 17:47)
После пролистывания темы: предлагаю автору начать с 1G на обычном SFP. Многое станет понятно, потом и на 10G можно переходить.
Автор уже оплатил счет на плату 10G с модулями SFP+ )))
А что за плата, если не секрет?
Цитата(gin @ Dec 16 2016, 18:49)
Автор уже оплатил счет на плату 10G с модулями SFP+ )))
Ничего не мешает вместо SFP+ воткнуть обычный SFP, далее - смотри п.1.
Цитата(Koluchiy @ Dec 16 2016, 18:25)
Ничего не мешает вместо SFP+ воткнуть обычный SFP, далее - смотри п.1.
Спасибо, может быть как вариант. Хотя, пока вот прям принципиально неразрешимых проблем с 10G не вижу. PHY модуль же аппаратно реализован, главное его корректно подключить
Цитата(gin @ Dec 16 2016, 10:52)
У Альтеровского IP 10GBASE-R PHY есть два клока:
1. xgmii_rx_clk - судя по всему это клок, по фронту которого выдаются данные. Как я понимаю, он восстанавливается из входного 10G сигнала.
2. pll_ref_clk - еще один клоковый вход. Вот не очень понимаю для чего он
1. xgmii_rx_clk - судя по всему это клок, по фронту которого выдаются данные. Как я понимаю, он восстанавливается из входного 10G сигнала.
2. pll_ref_clk - еще один клоковый вход. Вот не очень понимаю для чего он
Клок восстановленный из данных клок называется rx_recovered_clk, можно настроить мегафункцию, чтобы он выводился наружу, но Вам он не понадобится.
Из CDR данные по этому клоку поступают в ФИФО, откуда забираются клоком xgmii_rx_clk и преобразуются в XGMII интерфейс. Поэтому xgmii_rx_clk может быть один на много приемников.
Сам xgmii_rx_clk получается из pll_ref_clk в PLL, но главное назначение pll_ref_clk - это опорный клок для CDR. CDR хоть и восстанавливает частоту входных данных, но ему всё равно нужен опорный сигнал(см. схему, которую уже здесь приводили)
Цитата(DuHast @ Dec 16 2016, 20:19)
Клок восстановленный из данных клок называется rx_recovered_clk, можно настроить мегафункцию, чтобы он выводился наружу, но Вам он не понадобится.
Из CDR данные по этому клоку поступают в ФИФО, откуда забираются клоком xgmii_rx_clk и преобразуются в XGMII интерфейс. Поэтому xgmii_rx_clk может быть один на много приемников.
Сам xgmii_rx_clk получается из pll_ref_clk в PLL, но главное назначение pll_ref_clk - это опорный клок для CDR. CDR хоть и восстанавливает частоту входных данных, но ему всё равно нужен опорный сигнал(см. схему, которую уже здесь приводили)
Из CDR данные по этому клоку поступают в ФИФО, откуда забираются клоком xgmii_rx_clk и преобразуются в XGMII интерфейс. Поэтому xgmii_rx_clk может быть один на много приемников.
Сам xgmii_rx_clk получается из pll_ref_clk в PLL, но главное назначение pll_ref_clk - это опорный клок для CDR. CDR хоть и восстанавливает частоту входных данных, но ему всё равно нужен опорный сигнал(см. схему, которую уже здесь приводили)
Спасибо!
Мне не до конца понятен вот какой момент. Например, у меня имеется несколько входных сигналов 10G Ethernet, скажем 3. Все эти сигналы идут с разных источников. Номинальная частота их 10.3125 ГГц (после декодирования 64/66b станет 10 ГГц). Но так как источники разные, то и частоты у них все-равно отличаются на величину некоторой погрешности. И после всех преобразований на выходе XGMII интерфейсов для каждого канала должен быть свой выходной клок xgmii_rx_clk. То есть должно быть физически 3 xgmii интерфейса для принимаемых данных. Верно?
И второй вопрос, правильно ли я понял, что опорный клок pll_ref_clk (322.265625 либо 644.53125 МГц) должен заводится извне. Его нельзя брать с внутреннего блока PLL? По крайней мере Quartus мне так сделать не дает, выдавая ошибку.
Заранее спасибо за ответ!
Цитата(gin @ Dec 19 2016, 10:14)
Спасибо!
Мне не до конца понятен вот какой момент. Например, у меня имеется несколько входных сигналов 10G Ethernet, скажем 3. Все эти сигналы идут с разных источников. Номинальная частота их 10.3125 ГГц (после декодирования 64/66b станет 10 ГГц). Но так как источники разные, то и частоты у них все-равно отличаются на величину некоторой погрешности. И после всех преобразований на выходе XGMII интерфейсов для каждого канала должен быть свой выходной клок xgmii_rx_clk. То есть должно быть физически 3 xgmii интерфейса для принимаемых данных. Верно?
И второй вопрос, правильно ли я понял, что опорный клок pll_ref_clk (322.265625 либо 644.53125 МГц) должен заводится извне. Его нельзя брать с внутреннего блока PLL? По крайней мере Quartus мне так сделать не дает, выдавая ошибку.
Заранее спасибо за ответ!
Мне не до конца понятен вот какой момент. Например, у меня имеется несколько входных сигналов 10G Ethernet, скажем 3. Все эти сигналы идут с разных источников. Номинальная частота их 10.3125 ГГц (после декодирования 64/66b станет 10 ГГц). Но так как источники разные, то и частоты у них все-равно отличаются на величину некоторой погрешности. И после всех преобразований на выходе XGMII интерфейсов для каждого канала должен быть свой выходной клок xgmii_rx_clk. То есть должно быть физически 3 xgmii интерфейса для принимаемых данных. Верно?
И второй вопрос, правильно ли я понял, что опорный клок pll_ref_clk (322.265625 либо 644.53125 МГц) должен заводится извне. Его нельзя брать с внутреннего блока PLL? По крайней мере Quartus мне так сделать не дает, выдавая ошибку.
Заранее спасибо за ответ!
1 Как я уже писал, из CDR данные по восстановленному из данных клоку( rx_recovered_clk) поступают в ФИФО, откуда забираются клоком xgmii_rx_clk , Это фифо может компенсировать разность между xgmii_rx_clk и rx_recovered_clk до 100PPM за счет добавления и исключения пауз между пакетами. Поэтому xgmii_rx_clk может быть один на несколько приемников.
2 От куда заводить pll_ref_clk зависит от кристалла. Со специального пина можно запитать все приемопередатчики на одной стороне ПЛИС. Можно с PLL, но с ограничениями. Читайте документацию на кристалл. Но если вы работаете с готовой платой, то там RefClk должен быть уже заведён куда надо. Более того к платам, как правило, идёт референс дизайн, где пожно посмотреть все подключения внешних портов.
Цитата(DuHast @ Dec 19 2016, 19:37)
1 Как я уже писал, из CDR данные по восстановленному из данных клоку( rx_recovered_clk) поступают в ФИФО, откуда забираются клоком xgmii_rx_clk , Это фифо может компенсировать разность между xgmii_rx_clk и rx_recovered_clk до 100PPM за счет добавления и исключения пауз между пакетами. Поэтому xgmii_rx_clk может быть один на несколько приемников.
2 От куда заводить pll_ref_clk зависит от кристалла. Со специального пина можно запитать все приемопередатчики на одной стороне ПЛИС. Можно с PLL, но с ограничениями. Читайте документацию на кристалл. Но если вы работаете с готовой платой, то там RefClk должен быть уже заведён куда надо. Более того к платам, как правило, идёт референс дизайн, где пожно посмотреть все подключения внешних портов.
2 От куда заводить pll_ref_clk зависит от кристалла. Со специального пина можно запитать все приемопередатчики на одной стороне ПЛИС. Можно с PLL, но с ограничениями. Читайте документацию на кристалл. Но если вы работаете с готовой платой, то там RefClk должен быть уже заведён куда надо. Более того к платам, как правило, идёт референс дизайн, где пожно посмотреть все подключения внешних портов.
Спасибо!
1. Получается, что xgmii_rx_clk формируется из pll_ref_clk?
2. И если разность между xgmii_rx_clk и rx_recovered_clk меньше 100PPM, то FIFO будет успевать справляться с этой рассинхронизацией, и потерь данных не будет? А что произойдет, если разность будет более 100PPM? Будет происходить потеря данных?
Действительно, на плате установлен программируемый тактовый генератор (Si570) с низким джиттером, он и предназначен для тактирования 10G приемопередатчиков. Получается, его надо заводить напрямую на вход ref_clk, без промежуточной внутренней PLL?
Кристалл - Stratix V
Цитата(gin @ Dec 20 2016, 10:25)
Спасибо!
1. Получается, что xgmii_rx_clk формируется из pll_ref_clk?
2. И если разность между xgmii_rx_clk и rx_recovered_clk меньше 100PPM, то FIFO будет успевать справляться с этой рассинхронизацией, и потерь данных не будет? А что произойдет, если разность будет более 100PPM? Будет происходить потеря данных?
Действительно, на плате установлен программируемый тактовый генератор (Si570) с низким джиттером, он и предназначен для тактирования 10G приемопередатчиков. Получается, его надо заводить напрямую на вход ref_clk, без промежуточной внутренней PLL?
Кристалл - Stratix V
1. Получается, что xgmii_rx_clk формируется из pll_ref_clk?
2. И если разность между xgmii_rx_clk и rx_recovered_clk меньше 100PPM, то FIFO будет успевать справляться с этой рассинхронизацией, и потерь данных не будет? А что произойдет, если разность будет более 100PPM? Будет происходить потеря данных?
Действительно, на плате установлен программируемый тактовый генератор (Si570) с низким джиттером, он и предназначен для тактирования 10G приемопередатчиков. Получается, его надо заводить напрямую на вход ref_clk, без промежуточной внутренней PLL?
Кристалл - Stratix V
1 да
2 да.если разность больные 1000ppm то при брольшом трафика может произойти ошибка ФИФО( Rx Fifo error) её возникновение можно отслеживать.
Вообще в пятом стратиксе можно запитывать ref_clk от pll, но корку 10gBasedR можно тактировать только внешним клоком т.к. Внутри её самой ref_clk подаётся на pll для получения gmii_rx_clk.
Цитата(DuHast @ Dec 22 2016, 22:44)
1 да
2 да.если разность больные 1000ppm то при брольшом трафика может произойти ошибка ФИФО( Rx Fifo error) её возникновение можно отслеживать.
Вообще в пятом стратиксе можно запитывать ref_clk от pll, но корку 10gBasedR можно тактировать только внешним клоком т.к. Внутри её самой ref_clk подаётся на pll для получения gmii_rx_clk.
2 да.если разность больные 1000ppm то при брольшом трафика может произойти ошибка ФИФО( Rx Fifo error) её возникновение можно отслеживать.
Вообще в пятом стратиксе можно запитывать ref_clk от pll, но корку 10gBasedR можно тактировать только внешним клоком т.к. Внутри её самой ref_clk подаётся на pll для получения gmii_rx_clk.
Большое спасибо!
единственное, разность частот 100 или 1000 ppm?
Цитата(gin @ Dec 23 2016, 10:14)
Большое спасибо!
единственное, разность частот 100 или 1000 ppm?
единственное, разность частот 100 или 1000 ppm?
Ну это уже самому можно посмотреть.
http://www.altera.com/literature/ug/xcvr_user_guide.pdf
Цитата(DuHast @ Dec 24 2016, 14:03)
Ну это уже самому можно посмотреть.
http://www.altera.com/literature/ug/xcvr_user_guide.pdf
http://www.altera.com/literature/ug/xcvr_user_guide.pdf
Спасибо! На самом деле иногда полезно почаще заглядывать в даташиты))
В любом случае, стабильность частоты будут зависеть от стабильности генератора на плате. Плата уже едет, так что пока жду ее, буду готовить тестовый проект.
Если кому интересно... В общем в середине января приехала, купленная плата. Запустил на ней тестовый проект: прием 10G трафика и сразу же его выдача обратно без какой либо промежуточной обработки. Делал это для проверки правильности настройки тактового генератора. Настроил правильно, проект заработал - принимает и выдает обратно данные без ошибок и потерь.
Теперь делаю боевой проект, в общем то принципиальных трудностей нет, но есть некоторые вопросы:
1. Как правильно задать констрейт на xgmii_rx_clk? В принципе, так как этот клок формируется автоматически модулем 10GBASE-R, то констрейт должен генериться автоматически. Но хотелось бы описать его самому.
2. Пока не очень принципиально, но все же. Каким методом лучше рассчитывать CRC-32. Так как шина данных параллельная (64 бита), то табличный способ тут явно не пойдет. Но и не уверен,что получится напрямую на проходе сделать. В общем, может есть какие то описания, как считать CRC для Ethernet?
Заранее спасибо!
Теперь делаю боевой проект, в общем то принципиальных трудностей нет, но есть некоторые вопросы:
1. Как правильно задать констрейт на xgmii_rx_clk? В принципе, так как этот клок формируется автоматически модулем 10GBASE-R, то констрейт должен генериться автоматически. Но хотелось бы описать его самому.
2. Пока не очень принципиально, но все же. Каким методом лучше рассчитывать CRC-32. Так как шина данных параллельная (64 бита), то табличный способ тут явно не пойдет. Но и не уверен,что получится напрямую на проходе сделать. В общем, может есть какие то описания, как считать CRC для Ethernet?
Заранее спасибо!
Про crc ethernet можно почитать здесь https://electronix.ru/forum/index.php?showt...c=32896&hl=
Цитата(gin @ Feb 14 2017, 18:25)
Если кому интересно... В общем в середине января приехала, купленная плата. Запустил на ней тестовый проект: прием 10G трафика и сразу же его выдача обратно без какой либо промежуточной обработки. Делал это для проверки правильности настройки тактового генератора. Настроил правильно, проект заработал - принимает и выдает обратно данные без ошибок и потерь.
Теперь делаю боевой проект, в общем то принципиальных трудностей нет, но есть некоторые вопросы:
1. Как правильно задать констрейт на xgmii_rx_clk? В принципе, так как этот клок формируется автоматически модулем 10GBASE-R, то констрейт должен генериться автоматически. Но хотелось бы описать его самому.
2. Пока не очень принципиально, но все же. Каким методом лучше рассчитывать CRC-32. Так как шина данных параллельная (64 бита), то табличный способ тут явно не пойдет. Но и не уверен,что получится напрямую на проходе сделать. В общем, может есть какие то описания, как считать CRC для Ethernet?
Заранее спасибо!
Теперь делаю боевой проект, в общем то принципиальных трудностей нет, но есть некоторые вопросы:
1. Как правильно задать констрейт на xgmii_rx_clk? В принципе, так как этот клок формируется автоматически модулем 10GBASE-R, то констрейт должен генериться автоматически. Но хотелось бы описать его самому.
2. Пока не очень принципиально, но все же. Каким методом лучше рассчитывать CRC-32. Так как шина данных параллельная (64 бита), то табличный способ тут явно не пойдет. Но и не уверен,что получится напрямую на проходе сделать. В общем, может есть какие то описания, как считать CRC для Ethernet?
Заранее спасибо!
Установить Quartus 11. Сконфигурировать в MegaWizard IP блок CRC. Использовать сгенерированный блок в своём проекте, в своей версии Quartus'а
Цитата(DuHast @ Feb 15 2017, 06:51)
Установить Quartus 11. Сконфигурировать в MegaWizard IP блок CRC. Использовать сгенерированный блок в своём проекте, в своей версии Quartus'а
Спасибо! Надо будет глянуть
Кстати, по поводу констрейтов. Есть один очень неприятный момент. В принципе, когда подключается ядро 10GBASE-R, то как уже говорил, Quartus автоматически задает констрейт на xgmii clk. И честно разводит проект с учетом требований на этот клок. Но когда я подключаю к проекту SignalTap, то констрейт этот игнорируется, и разводка проекта происходит без учета ограничений по xgmii clk. В итоге требования не выполняются и работоспособность нарушается. Пол дня ломал сегодня голову, почему вдруг рабочий проект перестает работать... У меня 14 Quartus, может в поздних версиях это исправили.
Цитата(gin @ Feb 15 2017, 17:26)
Кстати, по поводу констрейтов. Есть один очень неприятный момент. В принципе, когда подключается ядро 10GBASE-R, то как уже говорил, Quartus автоматически задает констрейт на xgmii clk. И честно разводит проект с учетом требований на этот клок. Но когда я подключаю к проекту SignalTap, то констрейт этот игнорируется, и разводка проекта происходит без учета ограничений по xgmii clk. В итоге требования не выполняются и работоспособность нарушается. Пол дня ломал сегодня голову, почему вдруг рабочий проект перестает работать... У меня 14 Quartus, может в поздних версиях это исправили.
А есть уверенность, что иерархия проекта не меняется (имеется ввиду, что пути, указанные в ограничениях не меняются и названия портов/сигналов) и что ограничения именно игнорируются, а не просто не выполняются?
Цитата(bogaev_roman @ Feb 15 2017, 18:04)
А есть уверенность, что иерархия проекта не меняется (имеется ввиду, что пути, указанные в ограничениях не меняются и названия портов/сигналов) и что ограничения именно игнорируются, а не просто не выполняются?
Проект точно не меняется, так как все модули сохраняется, а логика работает (но со сбоями). Эти сбои как раз очень похожи на те, что будут происходит при не выполнении констрейтов.
Плюс к этому, когда не подключен SignalTap, то в отчете Quartus дает информацию по всем клокам, которые есть в проекте. А когда подключен, то только по одному. Поэтому я и грешу на SignalTap
Цитата(gin @ Feb 15 2017, 18:32)
Проект точно не меняется, так как все модули сохраняется, а логика работает (но со сбоями). Эти сбои как раз очень похожи на те, что будут происходит при не выполнении констрейтов.
Плюс к этому, когда не подключен SignalTap, то в отчете Quartus дает информацию по всем клокам, которые есть в проекте. А когда подключен, то только по одному. Поэтому я и грешу на SignalTap
Плюс к этому, когда не подключен SignalTap, то в отчете Quartus дает информацию по всем клокам, которые есть в проекте. А когда подключен, то только по одному. Поэтому я и грешу на SignalTap
Очень интересная картинка, он повыкидывал вообще все клоки из анализа. Читайте отчет фиттера, на каком основании, может действительно глюк конкретной версии. Можно еще посмотреть в rtl viewer, может он эти сигналы переименовал на каком-то основании, хотя clk_ref и clk_sys не должен был трогать, если они порты.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.