|
Ethernet to Е1, Переброс данных из MAC уровня Ethernet в Е1 |
|
|
|
Aug 24 2016, 13:01
|

Участник

Группа: Участник
Сообщений: 53
Регистрация: 14-11-10
Пользователь №: 60 881

|
Цитата(andrew_b @ Aug 24 2016, 11:44)  Ставить 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 Из-за чего это может происходить?
|
|
|
|
|
Aug 24 2016, 13:33
|
Профессионал
    
Группа: Свой
Сообщений: 1 975
Регистрация: 30-12-04
Из: Воронеж
Пользователь №: 1 757

|
Цитата(Tolas @ Aug 24 2016, 16:01)  В параметрах 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".
|
|
|
|
|
Aug 30 2016, 08:49
|

Участник

Группа: Участник
Сообщений: 53
Регистрация: 14-11-10
Пользователь №: 60 881

|
Итак, пока я переписываю проект и упрощаю его чтобы легче было искать ошибки, у меня возникают общие вопросы. 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); ?
|
|
|
|
|
Aug 30 2016, 09:01
|
Профессионал
    
Группа: Свой
Сообщений: 1 975
Регистрация: 30-12-04
Из: Воронеж
Пользователь №: 1 757

|
Цитата(Tolas @ Aug 30 2016, 11:49)  1) Получается, что все тактовые сигналы, которые идут из вне на ПЛИС и синхронизируют логику процессов обмена данными должны быть заведены на GCLK пины ПЛИС. А в проекте на VHDL они должны приниматься во внутренний сигнал через IBUFG. Если сигнал заведён на тактовый пин, синтезатор вставляет этот буфер сам. В коде буфер можно не вставлять. Цитата Как быть, если входных тактовых слишком много, ведь ресурсы ПЛИС ограничены в плане глобальных тактовых буферов? К каждому дизайну индивидуальный подход. Цитата я не понимаю разницы с делителем, реализованном на счетчике. Я тоже. В обоих случаях драйвером сигнала является триггер. Цитата 3)если данный сигнал участвует в процессах формирования и обработки выходных данных, то нужно ли его вешать на глобальный тактовый буфер: Код BUFG_002: BUFG port map(I => CLKOUT_E1, O => e1_tx_clk); ? Да. Все сигналы, используемые внутри ПЛИС как тактовые, должны быть заведены на тактовое дерево. Если тактовый сигнал идёт только наружу, использовать буфер смысла нет.
|
|
|
|
|
Aug 30 2016, 14:18
|

Местный
  
Группа: Участник
Сообщений: 201
Регистрация: 28-07-16
Пользователь №: 92 747

|
Цитата(Tolas @ Aug 22 2016, 13:26)  В стандартной xilinx'овской библиотеке я не нашел делителя тактовой на 16, а счетчик Вы говорите лучше не использовать. Не то и не там ищете. Цитата(Tolas @ Aug 22 2016, 13:26)  Неужели даже для деления на 16 входной тактовой нужно использовать целый блок PLL или DCM? А где вам еще может пригодиться аппаратный блок, который специально предназначен для решения в том числе таких задач? У вас этих блоков больше, чем требуется. Цитата(Tolas @ Aug 30 2016, 08:49)  У меня стоит задача разделить частоту 32.768 МГц на 16 и получить частоту 2.048 МГц. http://www.xilinx.com/support/documentatio...uides/ug382.pdfстр. 73 Table 2-7: DCM_SP AttributesCLKDV_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." Цитата(Tolas @ Aug 30 2016, 08:49)  Чем же плох делитель частоты с помощью счетчика? Если не сильно углубляться в вопрос, то: 1. Это можно сделать с помощью аппаратного модуля CMT (DCM, PLL), не изобретая велосипед, не тратя ресурсы логики. 2. При использовании DCM/PLL упрощается задача по обеспечению проектных ограничений, так как САПР хотя бы по поводу самопального счетчика-делителя не раскладывает пасьянсы в попытках натянуть сову на глобус. 3. При использовании DCM/PLL вы вряд ли столкнетесь с разваливанием проектов после переразводки и головняком "раньше все работало, а теперь нет". 4. У аппаратного решения есть петля обратной связи (см. Figure 2-2: DCM Functional Block Diagram на стр. 61), которая кроме прочих полезностей предназначена и для "eliminate clock distribution delays". Цитата(Tolas @ Aug 30 2016, 08:49)  Может тыкнете меня носом в информацию где можно понять в чем разница? http://www.xilinx.com/support/documentatio...uides/ug382.pdfUG382 Spartan-6 FPGA Clocking Resources User GuideПолезно посмотреть весь документ. Про CMT, DCM, PLL на стр. 57 Figure 2-2: DCM Functional Block Diagram на стр. 61
--------------------
"Классики марксизма говорили, что общественно-экономическая формация меняется с изменением средств производства, которые всегда принадлежали имущему классу. И сейчас мы находимся в системе координат капитализма, когда самые передовые средства производства принадлежат уже не капиталистам. Люди, у которых нет обуви, имеют гаджеты. Сейчас создана такая информационная паутина, что вместо коллективного бессознательного можно говорить о коллективном сознании. Если иметь мозги и гаджеты, можно перевернуть весь мир. Коллективное сознание будет управлять миром! Это исторический путь, который нельзя миновать." Вячеслав Мальцев
|
|
|
|
|
Sep 13 2016, 08:31
|

Участник

Группа: Участник
Сообщений: 53
Регистрация: 14-11-10
Пользователь №: 60 881

|
Благодарю пользователя 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 раскидает выводы и потом разводить плату?
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|