[Jackov 1]

Микросхема XC6SLX150-FG484I

Настройки PLL на картинке

В .ucf назначаю выводы:

Цитата

NET "ETH1CLK"        LOC = W12    | IOSTANDARD = LVCMOS33;
NET "ETH2CLK"        LOC = Y12    | IOSTANDARD = LVCMOS33;

Почему-то выдаёт ерроры такого содержания:

Цитата

ERROR:Place:1205 - This design contains a global buffer instance,
   <PLL1/clkout1_buf>, driving the net, <ETH1MDC_OBUF>, that is driving the
   following (first 30) non-clock load pins off chip.
   < PIN: ETH1MDC.O; >
   This design practice, in Spartan-6, can lead to an unroutable situation due
   to limitations in the global routing. If the design does route there may be
   excessive delay or skew on this net. It is recommended to use a Clock
   Forwarding technique to create a reliable and repeatable low skew solution:
   instantiate an ODDR2 component; tie the .D0 pin to Logic1; tie the .D1 pin to
   Logic0; tie the clock net to be forwarded to .C0; tie the inverted clock to
   .C1. If you wish to override this recommendation, you may use the
   CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote
   this message to a WARNING and allow your design to continue. Although the net
   may still not route, you will be able to analyze the failure in FPGA_Editor.
   < PIN "PLL1/clkout1_buf.O" CLOCK_DEDICATED_ROUTE = FALSE; >
ERROR:Place:1205 - This design contains a global buffer instance,
   <PLL1/clkout2_buf>, driving the net, <ETH2MDC_OBUF>, that is driving the
   following (first 30) non-clock load pins off chip.
   < PIN: ETH2MDC.O; >
   This design practice, in Spartan-6, can lead to an unroutable situation due
   to limitations in the global routing. If the design does route there may be
   excessive delay or skew on this net. It is recommended to use a Clock
   Forwarding technique to create a reliable and repeatable low skew solution:
   instantiate an ODDR2 component; tie the .D0 pin to Logic1; tie the .D1 pin to
   Logic0; tie the clock net to be forwarded to .C0; tie the inverted clock to
   .C1. If you wish to override this recommendation, you may use the
   CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote
   this message to a WARNING and allow your design to continue. Although the net
   may still not route, you will be able to analyze the failure in FPGA_Editor.
   < PIN "PLL1/clkout2_buf.O" CLOCK_DEDICATED_ROUTE = FALSE; >
ERROR:Place:1136 - This design contains a global buffer instance,
   <PLL1/clkout1_buf>, driving the net, <ETH1MDC_OBUF>, that is driving the
   following (first 30) non-clock load pins.
   < PIN: ETH1MDC.O; >
   This is not a recommended design practice in Spartan-6 due to limitations in
   the global routing that may cause excessive delay, skew or unroutable
   situations.  It is recommended to only use a BUFG resource to drive clock
   loads. If you wish to override this recommendation, you may use the
   CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote
   this message to a WARNING and allow your design to continue.
   < PIN "PLL1/clkout1_buf.O" CLOCK_DEDICATED_ROUTE = FALSE; >
ERROR:Place:1136 - This design contains a global buffer instance,
   <PLL1/clkout2_buf>, driving the net, <ETH2MDC_OBUF>, that is driving the
   following (first 30) non-clock load pins.
   < PIN: ETH2MDC.O; >
   This is not a recommended design practice in Spartan-6 due to limitations in
   the global routing that may cause excessive delay, skew or unroutable
   situations.  It is recommended to only use a BUFG resource to drive clock
   loads. If you wish to override this recommendation, you may use the
   CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote
   this message to a WARNING and allow your design to continue.
   < PIN "PLL1/clkout2_buf.O" CLOCK_DEDICATED_ROUTE = FALSE; >
ERROR:Pack:1654 - The timing-driven placement phase encountered an error.

Если в .ucf добавить строки

Цитата

PIN "PLL1/clkout2_buf.O" CLOCK_DEDICATED_ROUTE = FALSE;
PIN "PLL1/clkout1_buf.O" CLOCK_DEDICATED_ROUTE = FALSE;

то эти ерроры удаётся перевести в ворнинги и скомпилировать проект. Но не оставляет ощущуение, что что-то тут не так.

Цитата

WARNING:Place:1206 - This design contains a global buffer instance,
   <PLL1/clkout1_buf>, driving the net, <ETH1MDC_OBUF>, that is driving the
   following (first 30) non-clock load pins off chip.
   < PIN: ETH1MDC.O; >
   This design practice, in Spartan-6, can lead to an unroutable situation due
   to limitations in the global routing. If the design does route there may be
   excessive delay or skew on this net. It is recommended to use a Clock
   Forwarding technique to create a reliable and repeatable low skew solution:
   instantiate an ODDR2 component; tie the .D0 pin to Logic1; tie the .D1 pin to
   Logic0; tie the clock net to be forwarded to .C0; tie the inverted clock to
   .C1. This is normally an ERROR but the CLOCK_DEDICATED_ROUTE constraint was
   applied on COMP.PIN <PLL1/clkout1_buf.O> allowing your design to continue.
   This constraint disables all clock placer rules related to the specified
   COMP.PIN.
WARNING:Place:1206 - This design contains a global buffer instance,
   <PLL1/clkout2_buf>, driving the net, <ETH2MDC_OBUF>, that is driving the
   following (first 30) non-clock load pins off chip.
   < PIN: ETH2MDC.O; >
   This design practice, in Spartan-6, can lead to an unroutable situation due
   to limitations in the global routing. If the design does route there may be
   excessive delay or skew on this net. It is recommended to use a Clock
   Forwarding technique to create a reliable and repeatable low skew solution:
   instantiate an ODDR2 component; tie the .D0 pin to Logic1; tie the .D1 pin to
   Logic0; tie the clock net to be forwarded to .C0; tie the inverted clock to
   .C1. This is normally an ERROR but the CLOCK_DEDICATED_ROUTE constraint was
   applied on COMP.PIN <PLL1/clkout2_buf.O> allowing your design to continue.
   This constraint disables all clock placer rules related to the specified
   COMP.PIN.
WARNING:Place:1137 - This design is not guaranteed to be routable! This design
   contains a global buffer instance, <PLL1/clkout1_buf>, driving the net,
   <ETH1MDC_OBUF>, that is driving the following (first 30) non-clock load pins.
   < PIN: ETH1MDC.O; >
   This is not a recommended design practice in Spartan-6 due to limitations in
   the global routing that may cause excessive delay, skew or unroutable
   situations.  It is recommended to only use a BUFG resource to drive clock
   loads. Please pay extra attention to the timing and routing of this path to
   ensure the design goals are met. This is normally an ERROR but the
   CLOCK_DEDICATED_ROUTE constraint was applied on COMP.PIN <PLL1/clkout1_buf.O>
   allowing your design to continue. This constraint disables all clock placer
   rules related to the specified COMP.PIN.
WARNING:Place:1137 - This design is not guaranteed to be routable! This design
   contains a global buffer instance, <PLL1/clkout2_buf>, driving the net,
   <ETH2MDC_OBUF>, that is driving the following (first 30) non-clock load pins.
   < PIN: ETH2MDC.O; >
   This is not a recommended design practice in Spartan-6 due to limitations in
   the global routing that may cause excessive delay, skew or unroutable
   situations.  It is recommended to only use a BUFG resource to drive clock
   loads. Please pay extra attention to the timing and routing of this path to
   ensure the design goals are met. This is normally an ERROR but the
   CLOCK_DEDICATED_ROUTE constraint was applied on COMP.PIN <PLL1/clkout2_buf.O>
   allowing your design to continue. This constraint disables all clock placer
   rules related to the specified COMP.PIN.

 

[krux 8]

у xilinx философия такая, что best-practice считается выдавать клок наружу при помощи примитива ODDR.

гуглить по ключевым словам using ODDR for clock forwarding.

на клоковый вход примитивов с глобального клока роутиться будет всегда, а вот на DI / D0 / D1 и вообще на входную часть LUT....это как повезет. Проблема связана с выполнением констрейна на клок. При подаче его на обычный LUT клоковое дерево может "посыпаться"

[Beby 4]

В Spartan-6 Clocking Resources (ug382.pdf) примеры вывода тактовой частоты изображены на:
Figure 3-13: Zero Delay Buffer for Single-Ended Clocks
Figure 3-14: Zero Delay Buffer for Differential Clocks

[Jackov 1]

Я правильно понимаю, что на Figure 3-13 вот эта корка?

При попытке повесить на входы DATA_IN_FROM_PINS_P и DATA_IN_FROM_PINS_N единицу и ноль выдаёт:

Цитата

ERROR:Xst:2033 - Port I of Input buffer DDR/pins[0].ibufds_inst is connected to VCC
ERROR:Xst:2033 - Port IB of Input buffer DDR/pins[0].ibufds_inst is connected to GND
ERROR:Xst:1847 - Design checking failed

 

И ещё. А может быть можно использовать обычный триггер? То есть на PLL делаем удвоенную частоту, а потом делим её на Т-триггером и выводим наружу.

Изменено 10 июля, 2023 пользователем Jackov

[Beby 4]

11 hours ago, Jackov said:

Я правильно понимаю, что на Figure 3-13 вот эта корка?

При попытке повесить на входы DATA_IN_FROM_PINS_P и DATA_IN_FROM_PINS_N единицу и ноль выдаёт:

Wizard'ами не пользуюсь - потому не могу сказать оно или надо что-то другое брать. Однако, точно надо ставить ODDR, а не IDDR+IBUFDS - это точно ! (см. Data Bus Direction) - задача же стояла выводить Clock (на картинке выбран Inputs, а нужен Outputs).

 

Учитесь работать с элементами ПЛИС напрямую - меньше сюрпризов при изменении версии ПО, особенно в "длинных проектах" (которые, после первичной продажи, развиваются более 3 лет). Вот пример:

library ieee;
use ieee.std_logic_1164.all;

library unisim;
use unisim.vcomponents.all;


entity IO_Test is port (
	IN_CLK_1:	in	std_logic;
	IO_CLK_2:	out	std_logic );
end entity;



architecture Tushka of IO_Test is
	signal   CLK_1_UB:	std_logic;
	signal   CLK_1:		std_logic;
	signal  nCLK_1:		std_logic;
	signal   CLK_1_Out:	std_logic;
	
begin
	CLK_1_IBUFG: component IBUFG port map ( I => IN_CLK_1,     O => CLK_1_UB );
	CLK_1_BUFG:  component  BUFG port map ( I =>    CLK_1_UB,  O => CLK_1    );
	
	nCLK_1 <= not(CLK_1);
	
	CLK_1_ODDR: component ODDR2 generic map ( DDR_ALIGNMENT => "NONE",  INIT => '0',  SRTYPE => "SYNC" )
	port map ( D0 => '1',  D1 => '0',  Q => CLK_1_Out,  CE => '1',  C0 => CLK_1,  C1 => nCLK_1,  S => '0',  R => '0' );
	
	CLK_1_OBUF:  component OBUF  port map ( I => CLK_1_Out,  O => IO_CLK_2 );
	
end architecture;

Подсматривать, как именно (и какую разновидность элемента использовать) можно в "лампочке" (самая правая кнопка на Toolbar'е, или в меню: Edit->Language Templates...)

 

11 hours ago, Jackov said:

И ещё. А может быть можно использовать обычный триггер? То есть на PLL делаем удвоенную частоту, а потом делим её на Т-триггером и выводим наружу.

Можно то можно, вопрос только "зачем ?".

На выходной OFD/ODDR проще всего подавать именно ту частоту, на которой работает ваш проект. Если необходимо сформировать выходную тактовую равную внутренней, то используется ODDR; если же выходная тактовая должна быть меньше внутренней (в кратное двум количество раз) то OFD, а делитель (для 2-х кратного деления - Т-триггер) необходимо располагать до OFD.

 

Суть такая: цепи тактирования (а также PLL и JTAG) внутри Spartan-6 питаются от LDO, питающегося от Vccaux.

Обычные связи внутри Spartan-6 питаются от Vccint. Соответственно, при активной работе ПЛИС по Vccint стоит жуткий шум, и единственный способ минимизировать проникновение этого шума в выходные сигналы - это использовать OFD/ODDR/OSerDes для вывода данных из ПЛИС.

 

P.S. Для нормальной работы Spartan-6 необходимо в ucf-фале задать номинал этого Vccaux (который может быть 2.5В или 3.3В), например:

CONFIG VCCAUX = 3.3;

И да, это тоже можно подсмотреть в "лампочке": UCF->FPGA-Devices->Vccaux voltage.

[Jackov 1]

В 11.07.2023 в 11:03, Beby сказал:

Подсматривать, как именно (и какую разновидность элемента использовать) можно в "лампочке" (самая правая кнопка на Toolbar'е, или в меню: Edit->Language Templates...)

О, кажись заработало. Спасибо.

В 11.07.2023 в 11:03, Beby сказал:

Однако, точно надо ставить ODDR, а не IDDR+IBUFDS - это точно ! (см. Data Bus Direction) - задача же стояла выводить Clock (на картинке выбран Inputs, а нужен Outputs).

Я так понял там указано относительно внешнего девайса. Если переключить на Outputs, то становятся активны DATA_OUT_TO_PINS_P(N), а они выходы. Ну да ладно, уже не важно, главное, что заработало.

В 11.07.2023 в 11:03, Beby сказал:

если же выходная тактовая должна быть меньше внутренней (в кратное двум количество раз) то OFD

Вот этого OFD я что-то не нашёл.

 

[Beby 4]

10 hours ago, Jackov said:

Вот этого OFD я что-то не нашёл.

OFD (Output D Flip-Flop) - сейчас это схемный макрос, который порождает размещённый в OLogic D-триггер, подробнее можно ознакомиться в    Spartan-6 Libraries Guide for Schematic Designs (UG616 (v14.7) October 2, 2013).

Возможно, будет полезен и парный документ: Spartan-6 Libraries Guide for HDL Designs (UG615 (v14.7) October 2, 2013).

Ну и в недрах среды периодически попадаются упоминания про OFD.

[Jackov 1]

15 часов назад, Beby сказал:

OFD (Output D Flip-Flop) - сейчас это схемный макрос, который порождает размещённый в OLogic D-триггер

А, я понял, это тот триггер который находится максимально близко к выводу, в его схемотехнике. Вот только как его задействовать? В   UG615 его нет.

[andrew_b 14]

Код надо писать независимым от платформы настолько, насколько это возможно.  Если можно не захламлять код использованием специфичных для данной платформы низкоуровневых компонентов, то это надо делать. Вместо прямого вписывания OFD в код используйте соответствующие настройки синтезатора и констрейны, которые прописываются в пратформоспецифичных файлах ucf, xdc, sdc и др.

 

[krux 8]

On 7/15/2023 at 7:39 AM, andrew_b said:

Код надо писать независимым от платформы настолько, насколько это возможно.  Если можно не захламлять код использованием специфичных для данной платформы низкоуровневых компонентов, то это надо делать. Вместо прямого вписывания OFD в код используйте соответствующие настройки синтезатора и констрейны, которые прописываются в пратформоспецифичных файлах ucf, xdc, sdc и др.

 

Поддержу. Все платформо-зависимое выносить на уровень top и там делать  wrapper-ы это наиболее правильный вариант.

[Beby 4]

17 hours ago, Jackov said:

А, я понял, это тот триггер который находится максимально близко к выводу, в его схемотехнике. Вот только как его задействовать? В   UG615 его нет.

  Не просто "максимально близко к выводу", а с минимальной по размеру и максимально стабильной задержкой ! Можно и из недр ПЛИС тащить сигналы на выход, но уж больно большой разброс может получиться: для светодиодов это непринципиально, а вот для того же параллельного PCI (33 МГц) может быть уже весьма существенно.

  По работе синтезатора в ISE 14.7 (XST) есть следующие описания (даю ссылки именно для 14.7, но у документов написано 14.5):.
XST User Guide for Virtex-4, Virtex-5, Spartan-3, and Newer CPLD Devices (UG627 (v 14.5) March 20, 2013)
XST User Guide for Virtex-6, Spartan-6, and 7 Series Devices (UG687 (v 14.5) March 20, 2013)

  В более древнем xst.pdf намного больше примеров и пояснений и я его настоятельно рекомендую для изучения. Однако, для Spartan-6 в качестве руководства по синтезатору использовать необходимо xst_v6s6.pdf.

  Для описания синтезируемых конструкций необходимо ознакомиться с разделом:
«HDL Coding Techniques».
  Да, на HDL языках можно много чего описать, однако, если это описание отсутствует в (соответствующем вашей ПЛИС) XST User Guide, то результат синтеза такого описания, равно как и его повторяемость... известны только разработчикам XST.

  Для правильного использования Constraint’ов, необходимо ознакомиться с разделами
1. «HDL Constraints»
2. «FPGA Constraints (Non-Timing)»
3. «XST Implementation Constraints (xst.pdf)».
В разделе «FPGA Constraints (Non-Timing)» находится описание по заталкиванию FF в IOB (ILogic/OLogic), см. подраздел «Pack I/O Registers Into IOBs».

  Описание самих Constraint’ов (безотносительно XST) находиться в:
Constraints Guide (UG625 (v. 14.5) April 1, 2013)

  Пара возможных описаний OFD на VHDL прилагаю:

architecture YYY of ZZZ is
    signal    Q:    std_logic_vector(D'Range) := (others => '0');
    
    attribute iob:    string;        -- "true", "false", "auto", "force"
    attribute iob of Q: signal is "true";
begin
    Q_IOFF: process(CLK) begin
        if rising_edge(CLK) then
            Q <= D;
        end if;
    end process;
end architecture;

 

architecture YYY of ZZZ is
    signal    Q:    std_logic_vector(D'Range);
    
    attribute iob:    string;        -- "true", "false", "auto", "force"
begin
    Q_For: for i in D'Reverse_Range
        attribute iob of Q_IOFF: label is "true";
    generate
        Q_IOFF: component FD generic map ( INIT => '0' ) port map ( D => D(i),  Q => Q(i),  C => CLK );
    end generate;
end architecture;

  Обращаю внимание, что именно эти описания я не проверял - выдрал из своего кода и немного подправил. Как и всё непроверенное могут содержать опечатки.

  Относительно переносимости кода.
Где это возможно без ущерба для проекта, желательно не привязываться к конкретным примитивам ПЛИС. В ряде случаев подходят Wrapper’ы (обёртки), потроха которых ПЛИСозависимы, но имеют идентичные входы, выходы, параметры и функционал - для каждого семейства ПЛИС подкладываете свои файлы, в тоже время внешнее описание их использования (instantiation) остаётся неизменным.
И да, есть блоки, которые ПЛИСозависимы целиком - перенастраиваемые PLL, тактовые буфера (BUFH, BUFR, BUFIO) и т.п. Фрагменты блоков, плотно завязаные на эти примитивы проще переписывать целиком (умеренно большими кусками проекта) нежели городить кучу маленьких wrapper’ов.

  Пользоваться ли Wrapper’ами, выталкивать ли constraint’ы в ucf, xdc, sdc и др. файлы или забить на всё это и жёстко вписывать примитивы и constraint’ы в основной код – решать только вам в каждом конкретном случае.

[Jackov 1]

23 часа назад, Beby сказал:

По работе синтезатора в ISE 14.7 (XST) есть следующие описания

Спасибо за такой подробный ответ и ссылки на документацию.

 

23 часа назад, Beby сказал:

Не просто "максимально близко к выводу", а с минимальной по размеру и максимально стабильной задержкой !

Ну я и говорю, это тот триггер который находится в схемотехнике самого вывода.

 

В 15.07.2023 в 07:39, andrew_b сказал:

Код надо писать независимым от платформы настолько, насколько это возможно. 

В 15.07.2023 в 12:31, krux сказал:

Все платформо-зависимое выносить на уровень top и там делать  wrapper-ы

23 часа назад, Beby сказал:

Где это возможно без ущерба для проекта, желательно не привязываться к конкретным примитивам ПЛИС.

Это я понимаю.