Ethernet to Е1, Переброс данных из MAC уровня Ethernet в Е1 Опции

[Tolas]

Здравствуйте!
Являюсь начинающим разработчиком на 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]

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

[Tolas]

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

Проблемы с времянками имеются. Для гигабитного интерфейса МАС требуется входная тактовая 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]

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

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

Может как-то надо более правильно относиться к тактовым? (Тактовую 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 МГц выдать при таком проекте, изучайте отчеты, смотрите пути.

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

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

[Tolas]

К тактовым всегда нужно относиться правильно. Про кустарные делители частоты в промышленных решениях забудьте сразу, для этого есть 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]

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

Сообщение отредактировал Lutovid - Aug 22 2016, 14:21

[des00]

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

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

[Волощенко]

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

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

[Tolas]

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

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

[iosifk]

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

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

[Lutovid]

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

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

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

[wolfman]

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

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

[Tolas]

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

Для входной тактовой 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]

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

Код

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.

[Tolas]

Ставить BUFG на сигналы, которые идут только на выход, смысла нет. Вам надо триггеры CLKOUT_E1 расположить в IOB.

Сделал вот так:

Код

e1t1_mclk0 <= CLKOUT_E1;
e1t1_tclk0 <= CLKOUT_E1;

В параметрах Map процесса стоит Pack I/O Registers/Latches into IOBs: For Inputs and Outputs. Этого достаточно чтобы "триггеры CLKOUT_E1 расположить в IOB"? Или следует написать констрейн вида

Код

INST "CLKOUT_E1" IOB =TRUE;

Я так понимаю что после сборки можно посмотреть лежат ли в IOB эти триггеры в FPGA Editor'e. Только вот я не нашел где...

После добавления строки

Код

OFFSET = IN 122070 ps VALID 200 ns BEFORE "e1t1_rclk0";

процесс Place & Route стал очень долгим и выводится следующее сообщение:

Код

Unusually high hold time violation detected among 24 connections. The top 20 such instances are printed below. The
   router will continue and try to fix it
    e1t1_rpos0:I -> ethmac/e1_1_rx/TR_FLAG:A6 -165406
    e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<6>:B6 -165117
    e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<6>:D6 -165030
    e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.one_cnt<1>:D2 -165025
    e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<6>:C6 -164960
    e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<6>:A6 -164895
    e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<2>:C6 -164845
    ethmac/e1_1_rx/SIZE_TO_READ<10>:C -> ethmac/e1_1_rx/SIZE_TO_READ<10>:CE -164835
    e1t1_rpos0:I -> ethmac/e1_1_rx/SIZE_TO_READ<10>:C4 -164835
    e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<2>:D6 -164824
    e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<7>:A6 -164818
    e1t1_rpos0:I -> lut11048_1737:D1 -164809
    ethmac/e1_1_rx/hdlc_bit_get.byte<6>:B -> ethmac/e1_1_rx/Mram_REC_DATA:DIA4 -164767
    ethmac/e1_1_rx/hdlc_bit_get.byte<6>:D -> ethmac/e1_1_rx/Mram_REC_DATA:DIA6 -164745
    e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<2>:A1 -164709
    ethmac/e1_1_rx/hdlc_bit_get.byte<2>:AMUX -> ethmac/e1_1_rx/Mram_REC_DATA:DIA0 -164709
    e1t1_rpos0:I -> ethmac/e1_1_rx/SYNC_LOCAL:A5 -164704
    ethmac/e1_1_rx/hdlc_bit_get.byte<6>:C -> ethmac/e1_1_rx/Mram_REC_DATA:DIA5 -164663
    ethmac/e1_1_rx/hdlc_bit_get.byte<2>:C -> ethmac/e1_1_rx/Mram_REC_DATA:DIA1 -164638
    ethmac/e1_1_rx/hdlc_bit_get.byte<2>:AMUX -> ethmac/e1_1_rx/hdlc_bit_get.byte<2>:AX -164632

Из-за чего это может происходить?

[andrew_b]

В параметрах Map процесса стоит Pack I/O Registers/Latches into IOBs: For Inputs and Outputs. Этого достаточно чтобы "триггеры CLKOUT_E1 расположить в IOB"?

В принципе должно быть достаточно. Но поскольку в коде триггер описан один, а в FPGA их надо два, возможно, придётся немного пошаманить. Разрешить дупликацию триггеров. Или наоборот: в коде описать два триггера, а синтезатору запретить их объединение.

Я так понимаю что после сборки можно посмотреть лежат ли в IOB эти триггеры в FPGA Editor'e. Только вот я не нашел где...

Можно, конечно, и FPGA Editor, но можно и проще. Смотрите Pinout Report. Там в таблице есть колонка "IO Register".

[Tolas]

Изменил констрейн, добавил слово FALLING в конце, так как данные считываются по заднему фронту сигнала. Вроде прошел Place & Route быстренько.

[Tolas]

Итак, пока я переписываю проект и упрощаю его чтобы легче было искать ошибки, у меня возникают общие вопросы.
1) Получается, что все тактовые сигналы, которые идут из вне на ПЛИС и синхронизируют логику процессов обмена данными должны быть заведены на GCLK пины ПЛИС. А в проекте на VHDL они должны приниматься во внутренний сигнал через IBUFG. Дополнительно должны быть обконстрейнены данные на выход и на вход (с помощью OFFSET IN и OFFSET OUT), которые зависят от этих тактовых. Возникает следующий вопрос: "Как быть, если входных тактовых слишком много, ведь ресурсы ПЛИС ограничены в плане глобальных тактовых буферов?"
2)

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

Можно попробовать работать через clock enable, если экономите PLL

У меня стоит задача разделить частоту 32.768 МГц на 16 и получить частоту 2.048 МГц. Чем же плох делитель частоты с помощью счетчика? Попробовал поработать через clock enable и переписал код вот так:

Код

IBUFG_001: IBUFG port map (O => tclk, I => clk_32768);

clock_enable_32768KHz : process (tclk) is        
variable cnt : integer range 0 to 7;
begin
    if (rising_edge(tclk)) then
        if (rstn = '0') then        
            cnt := 0;
            CLKOUT_E1_EN <= '0';
        else
            if cnt=7 then
                CLKOUT_E1_EN <= '1';
                cnt:=0;
            else
                CLKOUT_E1_EN <= '0';
                cnt:=cnt + 1;
            end if;
        end if;        
    end if;
end process;

out_2048KHz : process (tclk) is
begin
   if (rising_edge(tclk)) then
      if (rstn = '0') then
         CLKOUT_E1 <= '0';
      else
         if (CLKOUT_E1_EN = '1') then
            CLKOUT_E1 <= not CLKOUT_E1;
         end if;
      end if;
   end if;
end process;

Правда пока его не проверял, но я не понимаю разницы с делителем, реализованном на счетчике. Может тыкнете меня носом в информацию где можно понять в чем разница?
3) В п.1 я говорил про входные тактовые сигналы. А как быть с выходными тактовыми сигналами? В п.2 я как раз такой сигнал формирую, он служит для синхронизации выходных данных. Нужно ли его как-то обконстрейнить? И, если данный сигнал участвует в процессах формирования и обработки выходных данных, то нужно ли его вешать на глобальный тактовый буфер:

Код

BUFG_002: BUFG port map(I => CLKOUT_E1, O => e1_tx_clk);

?

[andrew_b]

1) Получается, что все тактовые сигналы, которые идут из вне на ПЛИС и синхронизируют логику процессов обмена данными должны быть заведены на GCLK пины ПЛИС. А в проекте на VHDL они должны приниматься во внутренний сигнал через IBUFG.

Если сигнал заведён на тактовый пин, синтезатор вставляет этот буфер сам. В коде буфер можно не вставлять.

Как быть, если входных тактовых слишком много, ведь ресурсы ПЛИС ограничены в плане глобальных тактовых буферов?

К каждому дизайну индивидуальный подход.

я не понимаю разницы с делителем, реализованном на счетчике.

Я тоже. В обоих случаях драйвером сигнала является триггер.

3)если данный сигнал участвует в процессах формирования и обработки выходных данных, то нужно ли его вешать на глобальный тактовый буфер:

Код

BUFG_002: BUFG port map(I => CLKOUT_E1, O => e1_tx_clk);

?

Да. Все сигналы, используемые внутри ПЛИС как тактовые, должны быть заведены на тактовое дерево. Если тактовый сигнал идёт только наружу, использовать буфер смысла нет.

[BackEnd]

В стандартной xilinx'овской библиотеке я не нашел делителя тактовой на 16, а счетчик Вы говорите лучше не использовать.

Не то и не там ищете.

Неужели даже для деления на 16 входной тактовой нужно использовать целый блок PLL или DCM?

А где вам еще может пригодиться аппаратный блок, который специально предназначен для решения в том числе таких задач?
У вас этих блоков больше, чем требуется.

У меня стоит задача разделить частоту 32.768 МГц на 16 и получить частоту 2.048 МГц.

http://www.xilinx.com/support/documentatio...uides/ug382.pdf
стр. 73
Table 2-7: DCM_SP Attributes
CLKDV_DIVIDE
"Allowable values for CLKDV_DIVIDE include 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5, 5.5, 6, 6.5, 7, 7.5, 8, 9, 10, 11, 12, 13, 14, 15, 16."

Чем же плох делитель частоты с помощью счетчика?

Если не сильно углубляться в вопрос, то:
1. Это можно сделать с помощью аппаратного модуля CMT (DCM, PLL), не изобретая велосипед, не тратя ресурсы логики.
2. При использовании DCM/PLL упрощается задача по обеспечению проектных ограничений, так как САПР хотя бы по поводу самопального счетчика-делителя не раскладывает пасьянсы в попытках натянуть сову на глобус.
3. При использовании DCM/PLL вы вряд ли столкнетесь с разваливанием проектов после переразводки и головняком "раньше все работало, а теперь нет".
4. У аппаратного решения есть петля обратной связи (см. Figure 2-2: DCM Functional Block Diagram на стр. 61), которая кроме прочих полезностей предназначена и для "eliminate clock distribution delays".

Может тыкнете меня носом в информацию где можно понять в чем разница?

http://www.xilinx.com/support/documentatio...uides/ug382.pdf

UG382 Spartan-6 FPGA Clocking Resources User Guide
Полезно посмотреть весь документ.
Про CMT, DCM, PLL на стр. 57
Figure 2-2: DCM Functional Block Diagram на стр. 61

[andrew_b]

Кстати говоря, в Spartan6 есть специальные буферы BUFIO2, которые умеют делить тактовую в 3--8 раз.

[Tolas]

Благодарю пользователя BackEnd за развернутый ответ.
Сейчас борюсь с временными констрейнами для гигабитного Ethernet. Очень уж они "жесткие" получаются. Создал маленький проект, в котором используются только сигналы RxD, TxD, RxCLK, TxCLK с PHY микросхемы. В качестве эксперимента завернул данные с приема на передачу через внутренние сигналы. Примерно так:

Код

IBUFG_000: IBUFG port map (O => eth_rx_clk, I => rx_clk);

rx_proc : process(eth_rx_clk)
begin
    if (rising_edge(eth_rx_clk)) then
        data <= rx_data_delayed;
    end if;
end process;

BUFG_000: BUFG port map(I => eth_rx_clk, O => eth_tx_clk);

tx_proc : process(eth_tx_clk)
begin
    if (rising_edge(eth_tx_clk)) then
        tx_data <= data;
    end if;
end process;

tx_clk <= eth_tx_clk;

Задал следующие констрейны:

Код

NET "rx_clk" TNM_NET = "rx_clk";
TIMESPEC "TS_rx_clk" = PERIOD "rx_clk" 7500 ps HIGH 50 %;

OFFSET = IN  2500 ps VALID 3000 ps BEFORE "rx_clk";

В таком виде избежать проблем с констрейнами не удалось. Но, используя IODELAY2 на сигналы RxD удалось удовлетворить констрейнам. Но в основном проекте уже так не прокатило, так как там проект большой, задержки больше и уже не удалось найти такой параметр IDELAY_VALUE чтобы все констрейны были удовлетворены.
Вопросы, которые у меня появились в процессе этих манипуляций:
1) Что можно еще предпринять для удовлетворения констрейнам?
2) Когда создавал маленький проект, сначала в ucf файле указал только констрейны, без Location для выводов. Он раскидал все выводы так, как считает нужным. И, в принципе, проект удовлетворил констрейнам даже без IODELAY2. Может быть тогда следует сначала писать проект для FPGA, задавая все констрейны, потом смотреть куда ISE раскидает выводы и потом разводить плату?