Roberto_Tolas 0 24 августа, 2016 Опубликовано 24 августа, 2016 · Жалоба Ставить 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 14 24 августа, 2016 Опубликовано 24 августа, 2016 · Жалоба В параметрах 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". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Roberto_Tolas 0 24 августа, 2016 Опубликовано 24 августа, 2016 · Жалоба Изменил констрейн, добавил слово FALLING в конце, так как данные считываются по заднему фронту сигнала. Вроде прошел Place & Route быстренько. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Roberto_Tolas 0 30 августа, 2016 Опубликовано 30 августа, 2016 · Жалоба Итак, пока я переписываю проект и упрощаю его чтобы легче было искать ошибки, у меня возникают общие вопросы. 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 14 30 августа, 2016 Опубликовано 30 августа, 2016 · Жалоба 1) Получается, что все тактовые сигналы, которые идут из вне на ПЛИС и синхронизируют логику процессов обмена данными должны быть заведены на GCLK пины ПЛИС. А в проекте на VHDL они должны приниматься во внутренний сигнал через IBUFG.Если сигнал заведён на тактовый пин, синтезатор вставляет этот буфер сам. В коде буфер можно не вставлять. Как быть, если входных тактовых слишком много, ведь ресурсы ПЛИС ограничены в плане глобальных тактовых буферов?К каждому дизайну индивидуальный подход. я не понимаю разницы с делителем, реализованном на счетчике.Я тоже. В обоих случаях драйвером сигнала является триггер. 3)если данный сигнал участвует в процессах формирования и обработки выходных данных, то нужно ли его вешать на глобальный тактовый буфер: BUFG_002: BUFG port map(I => CLKOUT_E1, O => e1_tx_clk); ? Да. Все сигналы, используемые внутри ПЛИС как тактовые, должны быть заведены на тактовое дерево. Если тактовый сигнал идёт только наружу, использовать буфер смысла нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
backend 0 30 августа, 2016 Опубликовано 30 августа, 2016 · Жалоба В стандартной 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 14 31 августа, 2016 Опубликовано 31 августа, 2016 · Жалоба Кстати говоря, в Spartan6 есть специальные буферы BUFIO2, которые умеют делить тактовую в 3--8 раз. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Roberto_Tolas 0 13 сентября, 2016 Опубликовано 13 сентября, 2016 · Жалоба Благодарю пользователя 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 раскидает выводы и потом разводить плату? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться