[Roberto_Tolas 0]

Здравствуйте!

Являюсь начинающим разработчиком на 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 МГц).

В общем, хотелось бы получить какие либо рекомендации по разработке устройств на ПЛИС чтобы не получать непредсказуемого поведения)

 

[Lutovid 0]

Вообще поведение похоже на проблемы с времянкой - на примере широковещательного пакета видно что 1 бит поменялся - обратите внимание на тайминг, констрейнты на клоки и на пины, или проблема с распространением на самой плате< если она кастомная; надеюсь, правильно понял вопрос)

P.S. проверьте флаги достоверности CRC в пакетах, лично мне не очевидно вообще на каком этапе внедряется ошибка, по этому что-то более конкретное не могу посоветовать

[Roberto_Tolas 0]

поведение похоже на проблемы с времянкой

Проблемы с времянками имеются. Для гигабитного интерфейса МАС требуется входная тактовая 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, контроллер памяти) подключено к этой частоте. Есть ли какие-нибудь способы исправить данную ситуацию?

[backend 0]

я не могу понять почему у меня при разных попытках сборки при малых исправлениях кода (или даже если вовсе код не править) все ведет себя абсолютно непредсказуемо?

Так и должно быть. Работайте с привязками, читайте документацию.

 

Может как-то надо более правильно относиться к тактовым? (Тактовую 2.048 МГц для Е1 получаю простым счетчиком из 32.768 МГц).

К тактовым всегда нужно относиться правильно. Про кустарные делители частоты в промышленных решениях забудьте сразу, для этого есть DCM и PLL.

 

В общем, хотелось бы получить какие либо рекомендации по разработке устройств на ПЛИС чтобы не получать непредсказуемого поведения)

Про это можно целый курс лекций прочитать.

 

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

 

Minimum period is 17.606ns.

Не может он более 56.8 МГц выдать при таком проекте, изучайте отчеты, смотрите пути.

 

Есть ли какие-нибудь способы исправить данную ситуацию?

Есть. Плотно работать с фирменной документацией, там ответы почти на все вопросы.

 

[Roberto_Tolas 0]

К тактовым всегда нужно относиться правильно. Про кустарные делители частоты в промышленных решениях забудьте сразу, для этого есть DCM и PLL.

В стандартной xilinx'овской библиотеке я не нашел делителя тактовой на 16, а счетчик Вы говорите лучше не использовать. Неужели даже для деления на 16 входной тактовой нужно использовать целый блок PLL или DCM? И еще вопрос про тактовые: "Как быть с тактовыми, частота которых не очень высока, например тактовая на интерфейсе I2C?". Неужели даже для таких тактовых нужно использовать глобальные буфера (BUFG) и писать констрейны для них? Просто я Е1 причислял к интерфейсам с низкой тактовой, поэтому не задумывался об констрейнах на Е1.

Работайте с привязками

Я попытался обконстрейнить все, что связано с Е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 МГц?

[Lutovid 0]

Можно попробовать работать через clock enable, если экономите PLL... Вообще говоря вы же можете посмотреть конкретную цепь, где не сошлась времянка и сделать выводы в каком месте проблема, вполне возможно, что не с констрэйнтами проблема, а с логикой... То что вы перечислили, это не много блоков< если стоит глобальный клоковый буффер

Изменено 22 августа, 2016 пользователем Lutovid

[des00 25]

К тактовым всегда нужно относиться правильно. Про кустарные делители частоты в промышленных решениях забудьте сразу, для этого есть DCM и PLL.

Давая такие советы, аргументируйте. Чем сигнал с выхода триггера, поданный на глобальную линию клока в домен с независимой логикой или с логикой с правильным CDC, отличается от такого же с DCM/PLL?

 

[Voloshchenko 0]

Стоит задача: переброс данных из МАС уровня 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

[Alex11 3]

Для гигабитного интерейса обычно нужно не просто более 125 МГц, а ровно 125 МГц. Может быть в Марвелле есть возможность работать на другой частоте, не знаю, я с ним не работал. В любом случае будут вопросы с синхронизацией, или нестандартная частота передачи.

[Roberto_Tolas 0]

Для гигабитного интерейса обычно нужно не просто более 125 МГц, а ровно 125 МГц. Может быть в Марвелле есть возможность работать на другой частоте, не знаю, я с ним не работал. В любом случае будут вопросы с синхронизацией, или нестандартная частота передачи.

Да, для Marvell нужна частота 125 МГц для работы на скорости 1 Гб/с, а частота 125 МГц или более нужна для МАС уровня, который обрабатывает данные с PHY.

[iosifk 3]

Да, для Marvell нужна частота 125 МГц для работы на скорости 1 Гб/с, а частота 125 МГц или более нужна для МАС уровня, который обрабатывает данные с PHY.

На самом деле МАС эту частоту должен получать от PHY... А уже "внутри" проекта после CDC частота может быть любая...

 

[Lutovid 0]

Давая такие советы, аргументируйте. Чем сигнал с выхода триггера, поданный на глобальную линию клока в домен с независимой логикой или с логикой с правильным CDC, отличается от такого же с DCM/PLL?

Неужели даже для таких тактовых нужно использовать глобальные буфера (BUFG) и писать констрейны для них?

 

Судя по постановке вопроса я бы сделал вывод, что глобальная линия использована не была

[wolfman 0]

И еще вопрос про тактовые: "Как быть с тактовыми, частота которых не очень высока, например тактовая на интерфейсе I2C?". Неужели даже для таких тактовых нужно использовать глобальные буфера (BUFG) и писать констрейны для них? Просто я Е1 причислял к интерфейсам с низкой тактовой, поэтому не задумывался об констрейнах на Е1.

 

У меня I2C работает на 125 МГц, а 100(400) кГц идёт как enable.

 

[Roberto_Tolas 0]

Судя по постановке вопроса я бы сделал вывод, что глобальная линия использована не была

Для входной тактовой 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). Это плохо?

 

[andrew_b 14]

Сейчас добавил еще строчки для выходных тактовых и входной тактовой принимаемых данных:

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.