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 МГц).
В общем, хотелось бы получить какие либо рекомендации по разработке устройств на ПЛИС чтобы не получать непредсказуемого поведения)

[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 раскидает выводы и потом разводить плату?