| |
 Ethernet to Е1, Переброс данных из MAC уровня Ethernet в Е1 |
|
|
|
|
 Aug 17 2016, 12:40
|
Участник
Группа: Участник
Сообщений: 53
Регистрация: 14-11-10
Пользователь №: 60 881
|
Здравствуйте!
Являюсь начинающим разработчиком на FPGA. Работаю с ПЛИС Xilinx Spartan 6. Среда разработки ISE 14.7.
Стоит задача: переброс данных из МАС уровня Ethernet в Е1.
Имеется ПЛИС Spartan6 xc6slx150t-2fgg900, PHY Marvell 88E1111, сконфигурированный на работу по оптическому каналу на скорости 1 Gbs, E1 микросхема ds21348, сконфигурированная с NRZE = 1 (не биполярные данные на RPOS и RNEG (TPOS, TNEG), а используются только ноги RPOS и TPOS). Обмен информацией по Е1 организован с помощью HDLC протокола.
Алгоритм работы:
1) полностью принимается пакет с МАС уровня (в буфер), убирается флаг готовности приема данных с МАС уровня;
2) этот пакет передается по Е1 удаленному абоненту, в конце передачи выставляется флаг готовности приема данных с МАС уровня;
3) удаленный абонент, принимая данные по Е1 кладет, их в буфер для передачи в МАС уровень;
4) сразу после окончания приема по Е1 удаленный абонент выдает в МАС уровень принятый пакет.
Используемом соединение: точка-точка, поэтому количество пакетов не очень большое и время между пакетами не превышает времени передачи одного пакета по Е1, следовательно буфер приема данных с МАС уровня не должен переполняться (пока писал, подумал что не плохо было бы все-таки поставить флаг попытки положить данные из МАС уровня в буфер во время передачи по Е1).
Суть вопроса: так как я являюсь начинающим разработчиком на FPGA, я не могу понять почему у меня при разных попытках сборки при малых исправлениях кода (или даже если вовсе код не править) все ведет себя абсолютно непредсказуемо?
Пример: собрал проект, загрузил на плату, смотрю в Wireshark пакеты, приходящие от другого устройства - они абсолютно битые, вовсе не похожи на то, что надо. Запускаю SmartXplorer, выбираю один из вариантов сборки, загружаю на плату, получаю пакеты с битым широковещательным МАС адресом (заместо FF:FF:FF:FF:FF:FF принимается FF:7F:FF:FF:FF:FF или FE:FF:FF:FF:FF:FF), выбираю какой-нибудь другой вариант сборки в результатах SmartXplorer, получаю боле-менее стабильный результат, но есть потери пакетов (каждые 5 секунд высылаю пакет, но, примерно каждые 50 секунд 1-3 пакета теряются).
Части кода, связанные с HDLC и МАС тестировались отдельно, в том числе создавались testbanches. Может что-то в настройках проекта следует указывать или как-то задавать какие-то параметры и флаги портам? Может как-то надо более правильно относиться к тактовым? (Тактовую 2.048 МГц для Е1 получаю простым счетчиком из 32.768 МГц).
В общем, хотелось бы получить какие либо рекомендации по разработке устройств на ПЛИС чтобы не получать непредсказуемого поведения)
|
|
|
|
|
|
|
|
Aug 18 2016, 07:08
|
Участник
Группа: Участник
Сообщений: 53
Регистрация: 14-11-10
Пользователь №: 60 881
|
Цитата поведение похоже на проблемы с времянкой Проблемы с времянками имеются. Для гигабитного интерфейса МАС требуется входная тактовая 125 МГц или более. У меня основная тактовая идет от генератора на 48 МГц. С помощью блока PLL_BASE я формирую частоты 64 МГц (для периферии и процессора, которые выращены на этой ПЛИС) и 128 МГц для данного блока. Вот что после сборки мне говорит Timing Analizer про частоту 64 МГц: Код Timing constraint: TS_CLKOUT1 = PERIOD TIMEGRP "CLKOUT1" TS_clk / 1.33333333 HIGH 50%;
For more information, see Period Analysis in the Timing Closure User Guide (UG612).
23378864 paths analyzed, 16675 endpoints analyzed, 63 failing endpoints
63 timing errors detected. (63 setup errors, 0 hold errors, 0 component switching limit errors)
Minimum period is 17.606ns. Я так понимаю, что данная проблема возникает из-за того, что много блоков (процессор, SPI, пара UART, контроллер памяти) подключено к этой частоте. Есть ли какие-нибудь способы исправить данную ситуацию?
|
|
|
|
|
|
|
|
Aug 18 2016, 11:44
|
Местный
Группа: Участник
Сообщений: 201
Регистрация: 28-07-16
Пользователь №: 92 747
|
Цитата(Tolas @ Aug 17 2016, 12:40)  я не могу понять почему у меня при разных попытках сборки при малых исправлениях кода (или даже если вовсе код не править) все ведет себя абсолютно непредсказуемо? Так и должно быть. Работайте с привязками, читайте документацию. Цитата(Tolas @ Aug 17 2016, 12:40) Может как-то надо более правильно относиться к тактовым? (Тактовую 2.048 МГц для Е1 получаю простым счетчиком из 32.768 МГц). К тактовым всегда нужно относиться правильно. Про кустарные делители частоты в промышленных решениях забудьте сразу, для этого есть DCM и PLL. Цитата(Tolas @ Aug 17 2016, 12:40) В общем, хотелось бы получить какие либо рекомендации по разработке устройств на ПЛИС чтобы не получать непредсказуемого поведения) Про это можно целый курс лекций прочитать. Цитата(Tolas @ Aug 18 2016, 07:08) For more information, see Period Analysis in the Timing Closure User Guide (UG612). Вам, как минимум, рекомендуют изучить UG612 "Timing Constraints User Guide". http://www.xilinx.com/support/documentatio...inx11/ug612.pdfЦитата(Tolas @ Aug 18 2016, 07:08) Minimum period is 17.606ns. Не может он более 56.8 МГц выдать при таком проекте, изучайте отчеты, смотрите пути. Цитата(Tolas @ Aug 18 2016, 07:08) Есть ли какие-нибудь способы исправить данную ситуацию? Есть. Плотно работать с фирменной документацией, там ответы почти на все вопросы.
--------------------
"Классики марксизма говорили, что общественно-экономическая формация меняется с изменением средств производства, которые всегда принадлежали имущему классу.
И сейчас мы находимся в системе координат капитализма, когда самые передовые средства производства принадлежат уже не капиталистам.
Люди, у которых нет обуви, имеют гаджеты. Сейчас создана такая информационная паутина, что вместо коллективного бессознательного можно говорить о коллективном сознании.
Если иметь мозги и гаджеты, можно перевернуть весь мир. Коллективное сознание будет управлять миром! Это исторический путь, который нельзя миновать."
Вячеслав Мальцев
|
|
|
|
|
|
|
|
Aug 22 2016, 13:26
|
Участник
Группа: Участник
Сообщений: 53
Регистрация: 14-11-10
Пользователь №: 60 881
|
Цитата(BackEnd @ Aug 18 2016, 14:44) К тактовым всегда нужно относиться правильно. Про кустарные делители частоты в промышленных решениях забудьте сразу, для этого есть DCM и PLL. В стандартной xilinx'овской библиотеке я не нашел делителя тактовой на 16, а счетчик Вы говорите лучше не использовать. Неужели даже для деления на 16 входной тактовой нужно использовать целый блок PLL или DCM? И еще вопрос про тактовые: "Как быть с тактовыми, частота которых не очень высока, например тактовая на интерфейсе I2C?". Неужели даже для таких тактовых нужно использовать глобальные буфера (BUFG) и писать констрейны для них? Просто я Е1 причислял к интерфейсам с низкой тактовой, поэтому не задумывался об констрейнах на Е1. Цитата(BackEnd @ Aug 18 2016, 14:44) Работайте с привязками Я попытался обконстрейнить все, что связано с Е1: Код NET "clk_32768" LOC = "C1" | IOSTANDARD = LVTTL;
NET "clk_32768" TNM_NET = "clk_32768";
TIMESPEC "TS_clk_32768" = PERIOD "clk_32768" 30517 ps HIGH 50.00%;
NET "e1t1_rclk0" TNM_NET = "e1t1_rclk0";
TIMESPEC "TS_e1t1_rclk0" = PERIOD "e1t1_rclk0" 488281 ps HIGH 50.00%;
OFFSET = IN 122070 ps VALID 244100 ps BEFORE "e1t1_rclk0"; Это для тактовой 32.768 МГц и для входных данных. А как быть с передаваемыми данными, если тактовую для передаваемых данных вырабатываю я, из 32.768 МГц?
|
|
|
|
|
|
|
|
Aug 23 2016, 04:47
|
Местный
Группа: Свой
Сообщений: 347
Регистрация: 16-02-06
Из: г.Николаев, Украина
Пользователь №: 14 377
|
Цитата(Tolas @ Aug 17 2016, 16:40) Стоит задача: переброс данных из МАС уровня Ethernet в Е1. В 2006 году решил подобную задачу, но на другом наборе микросхем, посмотрите в http://electronix.ru/forum/index.php?showt...16146&st=30И там же вторая разработка http://electronix.ru/forum/index.php?showt...16146&st=60 где качестве контроллера Ethernet-10/100 использован чип от Micrel KSZ8842-16 MQL. В состав платы входят C8051F123 и XC9572XL
|
|
|
|
|
|
|
|
Aug 23 2016, 09:47
|
Участник
Группа: Участник
Сообщений: 53
Регистрация: 14-11-10
Пользователь №: 60 881
|
Цитата(Alex11 @ Aug 23 2016, 12:05) Для гигабитного интерейса обычно нужно не просто более 125 МГц, а ровно 125 МГц. Может быть в Марвелле есть возможность работать на другой частоте, не знаю, я с ним не работал. В любом случае будут вопросы с синхронизацией, или нестандартная частота передачи. Да, для Marvell нужна частота 125 МГц для работы на скорости 1 Гб/с, а частота 125 МГц или более нужна для МАС уровня, который обрабатывает данные с PHY.
|
|
|
|
|
|
|
|
Aug 23 2016, 20:21
|
Частый гость
Группа: Свой
Сообщений: 101
Регистрация: 24-02-14
Из: Москва
Пользователь №: 80 661
|
Цитата(des00 @ Aug 23 2016, 05:04) Давая такие советы, аргументируйте. Чем сигнал с выхода триггера, поданный на глобальную линию клока в домен с независимой логикой или с логикой с правильным CDC, отличается от такого же с DCM/PLL? Цитата Неужели даже для таких тактовых нужно использовать глобальные буфера (BUFG) и писать констрейны для них? Судя по постановке вопроса я бы сделал вывод, что глобальная линия использована не была
|
|
|
|
|
|
|
|
Aug 24 2016, 04:44
|
Знающий
Группа: Свой
Сообщений: 529
Регистрация: 15-06-05
Из: Питер
Пользователь №: 6 032
|
Цитата(Tolas @ Aug 22 2016, 22:56) И еще вопрос про тактовые: "Как быть с тактовыми, частота которых не очень высока, например тактовая на интерфейсе I2C?". Неужели даже для таких тактовых нужно использовать глобальные буфера (BUFG) и писать констрейны для них? Просто я Е1 причислял к интерфейсам с низкой тактовой, поэтому не задумывался об констрейнах на Е1. У меня I2C работает на 125 МГц, а 100(400) кГц идёт как enable.
--------------------
Россия это даже не страна.
Россия это секрет, завернутый в загадку и укрытый не проницаемой тайной...
|
|
|
|
|
|
|
|
Aug 24 2016, 08:31
|
Участник
Группа: Участник
Сообщений: 53
Регистрация: 14-11-10
Пользователь №: 60 881
|
Цитата(Lutovid @ Aug 23 2016, 23:21) Судя по постановке вопроса я бы сделал вывод, что глобальная линия использована не была Для входной тактовой 32.768 МГц был определен тактовый буфер: Код IBUFG_002: IBUFG port map (O => tclk, I => clk_32768); Делю входную тактовую счетчиком: Код div16_32768KHz : process (tclk, rstn) is
variable cnt : integer range 0 to 7;
begin
if rstn = '0' then
cnt := 0;
CLKOUT_E1 <= '0';
else
if tclk'event and tclk='1' then
if cnt=7 then
CLKOUT_E1 <= not CLKOUT_E1;
cnt:=0;
else
cnt:=cnt +1;
end if;
end if;
end if;
end process; Сейчас добавил еще строчки для выходных тактовых и входной тактовой принимаемых данных: Код OBUFG_000: BUFG port map (O => e1t1_mclk0, I => CLKOUT_E1);
OBUFG_001: BUFG port map (O => e1t1_tclk0, I => CLKOUT_E1);
IBUFG_003: IBUFG port map (O => e1t1_rclk0_local, I => e1t1_rclk0); Вот только все эти входы и выходы на ПЛИС подключены к обычным портам ввода/вывода (не GCLK). Это плохо?
|
|
|
|
|
|
|
|
Aug 24 2016, 08:44
|
Профессионал
Группа: Свой
Сообщений: 1 975
Регистрация: 30-12-04
Из: Воронеж
Пользователь №: 1 757
|
Цитата(Tolas @ Aug 24 2016, 11:31) Сейчас добавил еще строчки для выходных тактовых и входной тактовой принимаемых данных: Код OBUFG_000: BUFG port map (O => e1t1_mclk0, I => CLKOUT_E1);
OBUFG_001: BUFG port map (O => e1t1_tclk0, I => CLKOUT_E1); Ставить BUFG на сигналы, которые идут только на выход, смысла нет. Вам надо триггеры CLKOUT_E1 расположить в IOB.
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
