Доброго всем времени суток
До настоящего момента работал только с CPLD, особых проблем не было. Но для текущего проекта ресурсов CPLD не хватает
Проект -офисная миниАТС,- в FPGA (подошла acex1k), коммутационная матрица, синхронный порт,
тональные генераторы и много чего другого. Наблюдаю следующую картину-отлаживаю один узел, другой, берусь за третий отлаживаю,- начинает сбоить первый, вношу какие -то изменения в один узел- почему влияет на второй, и так замкнутый круг. Это что, нормальная ситуация с FPGA? Или я что-то не так делаю?

Временные ограничения установлены?

Нет, это явно НЕ нормальная ситуация. Скорее всего это связано с тем, что у Вас не синхронный (или частично не синхронный) проект. Особеность проектирования на ПЛИС (да и не только на ПЛИС) - это одна глобальная тактовая частота, по переднему (или заднему) фронту которой происходит стробирование ВСЕХ данных и во ВСЕХ узлах/блоках проекта. И как минимум ВСЕ входы ВСЕХ модулей должны иметь регистровый вход, с защелкиванием данных по фронту глобального клока. А еще лучше и все выходы. То же самое относиться к входам/выходам ПЛИС.

Посмотрите в сторону Cyclone, по цене дешевле и есть поддержка Signal Tap - незаменимая вещь при отработке на железе.

Бывало такое при использовании более 70% ресурсов FPGA - сбоило то, что нормально работало при меньшей загрузке. Думаю, что причина - в ухудшении скоростных характеристик FPGA из-за удлиннения трасс сигналов. Количество трасс внутри микросхемы ограничено, и в определенный момент фиттер не сможет разместить проект, даже если требуется менее 100% логических ячеек. Обычно проблемы сбоев решались нахождением не совсем корректных схемотехнических решений (например, использование выхода логического элемента (AND, OR, XOR и т.д.) в качестве синхросигнала для триггера, даже (или особенно ;-)) если входы ЛЭ изменяются синхронно)). При значительном использовании ресурсов синхронные изменения перестают быть таковыми и на выходе ЛЭ появляются просечки. В качестве профилактики проблем размещения и сбоев я стараюсь использовать как можно меньше различных синхросигналов, при этом выходы логических схем применять только для управления сбросом, установкой, и разрешением.

Уточните, какой тип FPGA вы используете - вам ответят соответствующие специалисты.
Я например, работал только с Xilinx.

Общие рекомендации:
1. Синхронный дизайн. Если есть много клоков - использовать для них глобальные линии и специальные методы перевода сигналов из одного клокового домейна в другой, а также синхронизировать клоки по фазе используя PLL/DCM, или синтезируя клоки от одного источника.
2. Максимально использовать пайп-лайн для передачи сигналов между функциональными блоками, пусть даже всего на один триггер/регистр.
3. Для приема и выдачи сигналов максимально использовать входные и выходные IOB регистры.
Для включеия этих фичей использовать соответствующие записи в констрейнт файле.
4. Поставить констрейнты на все клоки. Как минимум, указать их величину. Как максимум - для
критических путей или групп сигналов добавить констрейнты на Tsu (setup), Tco (clock-to-output).
5. Постоянно проверять логи P&R на предмет прошли ваши констрейнты или нет.

И Xilinx и Altera имеют как GUI средства введения констрейнтов, так и формальное их описание (mnl_qsf_reference.pdf для Altera, cgd.pdf для Xilinx) для непосредственного их введения в констрейнт файлы (.ucf для Xilinx, .qsf для Altera).

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

Большое спасибо за подсказки. Дествительно, в дизайне есть "асинхронности". Попробую все простробировать global clock. Просто я исходил из того что имея отностильно низкую частоту(8 МГЦ имеет толь коммутационная матрица, все остальное работает на 2 МГц), имею колосальный запас по задержкам и предустановкам, и допустил некоторые вольности, которые на больших частотах не прошли бы точно. Прийдется переаботать дизайн

В своё время многие проблеммы с синхронизацией решила вот такая простенькая схемма. Нашёл её в quartusii_handbook
Все триггеры в проекте тактируются глобальной тактовой. А на вход разрешения триггера(ENA) подается с выхода этой схеммы. Т е это просто схемма укорочения импульса, синхронная!!!

Это не синхронизация, а rise detection. При приходе асинхронного сигнала бесполезна.

"то не синхронизация, а rise detection. При приходе асинхронного сигнала бесполезна."
тогда как же поступают при приходе асинхронного сигнала, что бы вписать его в синхронную систему???

Чем же это она бесполезна??? Подобную прибабаху использую уже лет 10 именно для синхронизации асихронных сигналов (если нет требования сохранения длительности) и все прекрасно работает. Типичное применение - запись в синхронное FIFO от чего-то асинхронного или бегущего в другом clock domain. ИМХО - масса вариантов, когда очень удобно использовать... Если надо сохранить длительность (с точностью до клока) - Shift Reg, но принцип тот же самый

Тем что выход первого триггера используется в дальнейшей логике. В классическом синхронизаторе из двух триггеров, предназначенном для борьбы с метастабильностью, выход первого триггера подключают исключительно к входу второго. Идея - в любой технологии при приходе фронта асинхронного сигнала на вход триггера одновременно с приходом клока время установления логического уровня сигнала на выходе триггера может возрастать до бесконечности, но практически лишь слегка, не скажу точно за распределение вероятности - но экспонента в нем была точно. Этот эффект и называется метастабильностью. В большинстве случаев за время одного такта на выходе первого триггера устанавливается логический уровень с очень высокой вероятностью, и поэтому второй триггер его уже быстро защелкивает в пределах времени установления из даташита. Если же выход первого триггера подать на комбинаторную схему, да еще он попадет в критический путь, да еще схема работает на пределе частоты. да еще в констрейнтах ничего не сказано про увеличенное время установления - то даже небольшое связанное с метастабильностью увеличение времени установления сигнала на выходе первого триггера может стать причиной сбоев.

Тем что выход первого триггера используется в дальнейшей логике. В классическом синхронизаторе из двух триггеров, предназначенном для борьбы с метастабильностью, выход первого триггера подключают исключительно к входу второго.
////////////////////////////
Наверно имеет смысл при этом добавить - при приеме данных.
Приведенная выше схема под названием синхронный одновибратор давно уже имеено в таком виде озвучена у Тицце и Шенка.
Идея в том что эта схема обычно используется для преобразования именно клока, который сопровождает данные. Gate clk - в enable clk. И если данные, сопровождаемые gate клоком укладываются хотя бы в два периода глобального клока, то уже без разницы, как воспримет второй триггер метастобильность первого. Данные уверенно будут приняты или в первом такте или во втором.
Да и от частоты клока очень многое зависит. В свое время забавно было читать, как два теоретика рассуждали о том , что лучше принимать данные на частоте 20 мГц чем на 40. И их мало интересовало, есть ли у пользователя такие частоты.

Я согласен с Вашими замечаниями... В этом вопросе так глубоко не копал (распределение вероятности, экспонента,метастабильность.... сложные вопросы)
Приведённая мной схема очень проста , но в большенстве случаев работает.
Тогда может вы подскажите другое решение.
Что лучше использовать при приёме данных? Какую схему используете вы?

Спасибо, но это добавлять было не нужно. Титце с Шенком ничего не пишут про метастабильность, о которой написал я. Действительно, эффекты метастабильности критичны именно для высокочастотных схем, работающих вблизи технологического предела. Если схема работает на частотах, гораздо меньше предельных - то небольшое увеличение времени установления на выходе первого триггера, действительно, не будет для нее существенным, и можно обычно безопасно использовать синхронизатор не из двух, а из одного триггера. Как в обсуждаемой схеме. С другой стороны, то, что используется синхронизатор из двух последовательно включенных триггеров, а не скажем, из пяти, связано только с отношением постоянной времени в законе распределения вероятности для метастабильности к периоду клока. Но вроде бы для применяемых технологий одного такта на предельной частоте клока вполне достаточно для надежного установления логического уровня.

Я стараюсь не работать с асинхронными шинами. Если же приходилось - старался ставить синхронизатор из двух последовательно включенных триггеров. Мне хватало. Если бы не хватило - копал бы в сторону синхронизатора с одним триггером с соответсвующими констрейнтами на выход первого триггера. Но это гораздо сложнее - чтобы доказать работоспособность такой схемы вблизи жестких ограничений - нужно провести измерения параметров метастабильности по методикам, изложенным в аппнотах производителей кристаллов, и все равно, оставались бы сомнения по поводу зависимости этих параметров, например, от температуры. Так что если не хочется об этом задумываться проще ставить два триггера.

В Вашей схеме в качестве синхронизатора используется именно один триггер.

Спасибо за пояснения, но что такое "метастабильность" и как с нею бороться я знаю последние лет 25, а может и больше. Хотя за пояснения все равно спасибо - кому-нибудь точно пригодится. Мои аргументы "за" приведенныю схему ни сном ни духом не утверждают, что она предназначена для борьбы с метастабильностью, но у нее есть свои применения. А вот Shift Reg (как Вы описали - 2-х битовый) делает как раз то, что надо.

Раз уж тема о проблеммах синхронизации, хотелось бы узнать ваше мнение по поводу использования глобальных частот. Думаю эти вопросы возникают у многих.
Как вы считаете можно ли глобальную тактовую частоту подавать на ногу ввода вывода?
Например в РLL частота умножается да 60 мегагерц. Могу ли я эту частоту подать на выход ПЛИС??

Это так - свои применения у схемы есть. Но не для всякой синхронизации асинхронных сигналов её можно использовать не задумываясь - об этом и было замечание. То есть совет использовать эту схему в качестве синхронизатора мог оказаться вредным. Вот если на вход этой схему подключить еще один триггер - то совет будет гораздо безопаснее для начинающих.

Если набрать слово метастабильность в конференции, можно многое чего узнать.

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

Желательно уточнить тип ПЛИС к которой отностися вопрос.
Выводить можно, только надо учитывать несколько неприятных моментов:

1. В ПЛИС с которыми я работал нет "прямого" пути дял Global Clock на вход I в I/O Block, тогда имплементатор пропускает Global Clock через несколько коммутаторов, добавляя, тем самым, некоторую (в общем случае неодинаковую) транспортную задержку. Если у вас несколько выходов с этим Global Clock, то желательно довавить соответствующий Constaint (у Xilinx это Skew).

2. Видел я какой-то XAPP (найти его сейчас не смог), там была применена такая идея: Global Clock не может быстро попасть на на вход I в I/O Block, но может попасть на вход OCLK в I/O Block и быстро, и синхронно с остальными выходами. Тогда можно запитать в ПЛИС с DDR выходом этим клоком DDR коммутатор, который будет мультиплексировать две константы '1' и '0', эмулируя, тем самым, выход Global Clock.

3. При работе ФАПЧ неизбежно появляется jitter. Если PLL цифровой, то jitter может быть весьма "большим" (в десятки пикосекунд) - что для некоторых высокоточных задач - неприемлемо.

Да действительно , не конкретный вопрос я задал ...
Плисс у меня Cyclone II. Я знаю у этих микросхемм есть специальные выводы тактовых частот наружу. Называются они в документации PLL<#>_OUT, привязываются они к специальным ногам плисы. Но при разводке платы я это не учел. Если просто подавать Global Clock на выход плис,то получается криво... мы имею не только плохую частоту на выходе плисс, но и все схемы тактируемые этим Global Clock ведут себя странно.
Наверное лучше спросить по другому .
Можно ли сигналы Global Clock выводить наружу плис без специальных выводов. Если можно то как?

Если все тактируемые схемы ведут себя странно - то дело скорее всего в разводке рлаты...
Есть такой термин - Signal Integrity. Обратите на него пристальное внимание - для клоков он особенно критичен.

Я для приема данных использу FIFO, в случае когда данных очень много оно организуется на двух внешних ОЗУ'шках (одну читает потребитель, и пока она полностью не прочитанна, в другую пишет источник данных), если ОЗУ надо мало, то вполне для FIFO подходит и блоки внутреннего ОЗУ. Как работают счетчики на запись/чтение данных в/из FIFO - зависит от конкретной задачи. Главное, что блок синхронизации я применяю один и тот же.

Идея блока такова:
Есть CLK_1 и есть некое событие, на которое надо отреагировать импульсом длинной в один такт на CLK_2. Наличие события кодируется импульсом, длинной в один такт CLK_1 на линии START. Исходник блока синхронизации (разработал сам):


library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity sync_clk is port (
START: in std_logic;
CLK_1: in std_logic;
CLK_2: in std_logic;

Q: out std_logic );
end entity;

architecture sync_clk_body of sync_clk is

signal F1_FD0: std_logic := '0';
signal F2_FD1: std_logic := '0';
signal F2_FD2: std_logic := '0';

begin
process (CLK_1, F2_FD2)
begin
if F2_FD2 = '1' then
F1_FD0 <= '0';
elsif rising_edge(CLK_1) then
if (START = '1') then
F1_FD0 <= '1';
end if;
end if;
end process;

process (CLK_2)
begin
if rising_edge(CLK_2) then
F2_FD1 <= F1_FD0;
F2_FD2 <= F2_FD1 xor F2_FD2;
end if;
end process;

Q <= F2_FD2;
end architecture;

Эта схема используется в (БСС) Блоках Сетевой Синхронизации Первого и Второго "сортов" в STM (телефонии). За все время тестирований и измерений ни разу не пропустила ни одного импульса. (любой пропушенный умпульс, в данных системах, тут же отзывется плавным, но быстрым, набегом фазы на 1 такт) В БСС второго сорта схема закатана в XCR3256-7TQ144. Работает с частотами около 131.072 МГЦ (практически на предельном быстродействии XPLA3). В Spartan-2E в менее скоростной задачи, за год эксплуатации пока тоже сбоев не обнаружено.

С Altera не работаю, архиректуру Cyclone II не представляю.
Но ловил подобный глюк в Spartan-IIE при GCLK более 200 МГц. Дело было исправлено добавлением к каждому блокировочному конденсатору 0.1 мкФ (Murata X7R) еще и 0.01 мкФ (Murata X7R). После этого все стало работать нормально. В том проекте 0.1 мкФ конденсаторы стояли на каждой ноге питания ПЛИС. В описании конденсаторов Murata для X7R обнуружил, что конденсаторы 0.1 мкФ более или менее хорошо работают на частотах до 20 МГц.
Хоть у Вас частота только 60 Мгц, но все-же может быть дело с блокировочными конденсаторами (?), попробуйте - дорого не выйдет.
Если вы применяете Y5V конденсаторы, то может быть поможет такая наводка: у некоторых из Y5V мы обнаруживали пъезо эффект, т.е. любой удар по плате отзывается небольшим броском напряжения - очень забавно выглядит при просмотре данных с 12-разрядного АЦП, оцифровывающего высокостабильное постоянное напряжение. Если ваше устройство работаете в условиях вибраций... то в таком случае итог будет печален.

Может конечно, дело еще в чем-то...

спасибо , сейчас бегло просмотрел в quartusii_handbook, штука интересная. Раньше об этом не знал.
Вечерком попробую разобраться что к чему.

Moget Ja ne sovsem ponimaju no pochemu XOR vo vtorom processe?
Po moemu u Vas F2_FD2 moget zalipnut' v edinice.
Ne proshe li tak?

process (CLK_2)
begin
if rising_edge(CLK_2) then
F2_FD1 <= F1_FD0;
F2_FD2 <= '0';
if F2_FD1='1' then F2_FD2<='1'; end if;
end if;
end process;

А XOR потому, что:


Как вы должны догадываться, эта выложенная схема, далеко не первая, а результат последовательной оптимизации ряда схем, в т.ч. гибрида схемы leevv(#29) + что-то вроде Alex_vod(#2) - 4 триггера, время реакции не менее 3T CLK2, время релаксации не менее 4T CLK2, по моему в моей схеме с этим получше, а?

Насколько я изучил ПЛИС, логика в них работает как фильтр нижних частот, т.е. ее конечное быстродействие несколько ниже, чем у триггера. А при метостабильном состоянии у триггера на выходе достаточно высокочастотные колебания, которые в чистом виде через логику пройти не могут. Но это пол дела.

В добавок в моей схеме, у триггера F2_FD1 заложено время на выход из метастабильного режима = 1T CLK2 - (Troutes delay + Txor delay). Если для вас этого мало - модифицируйте схему под свои нужды. Но все-таки:

А время тестирования БСС это не 2 минуты и не час. БСС-1 только в захват застоты входит несколько чавов, а затем его еще и тестируют, как он "фильтрует" эту захваченную частоту, со своей-то постоянной времени. Если бы эта схема глючила в ПЛИС, то это было бы видно - уж поверьте. Тем более зависнуть!

Не обращая внимание на результаты -тестирования (каждый программист знает, что никакое тестирование не находит всех ошибок) должен заметить, что схема представляется вполне работоспособной. Более того, по устойчивости к метастабильности она не сильно хуже обычной схемы их двух последовательных триггеров - время задержки в логике перед триггером мало по сравнению со временем разводки. При нормальной работе логики эта схема не может залипнуть - но если есть сомнения, XOR можно наменить на "D1 and not D2".

И еще мысль. Учитывая, что в современных FPGA время разводки часто превышает все остальное - имеет смысл в синхронизаторах жестко констрейнить время распространения сигнала с выхода первого триггера на вход второго, чтобы его не развели через весь кристалл по диагонали.

XOR использовался в XPLA3 (там он аппаратный XOR с своими специфическими свойствами).


А в FPGA (Spartan-IIE) я плотно обкладываю RLOC'ом все узлы и схемы синхронизыции (строки с RLOC я вырезал из предоставленного исходника, чтобы не загромождать код).


Ну я не программист... Без эксперимента (т.е. по теоретическим выкладкам) я не могу сказать будет ли какая-либо метастабильная схема работать на "больших" частотах в ПЛИС - поэтому без экспериментов - никуда (только ведь эксперименты разные бывают...)

XOR использовался в XPLA3 (там он аппаратный XOR с своими специфическими свойствами).
/////////////////////////////////////////////////////////////////////////////
Причем тут аппаратный xor. Его здесь рядом не лежало. Писать наглядно надо. Чтобы потом не вспоминать, что это на самом деле ложиться на триггер со входом enable.
Да и спорить не о чем. ДА. Это схема полностью рабочая. Только вот действительно мертвая зона в три такта clk2 за счет петли обратной связи. А корректировать можно до бесконечности. Например зачем clk1.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity sync_clk is port (
START: in std_logic;
CLK_2: in std_logic;
Q: out std_logic );
end entity;

architecture sync_clk_body of sync_clk is

signal F1_FD0: std_logic := '0';
signal F2_FD1: std_logic := '0';
signal F2_FD2: std_logic := '0';

begin
process (START, F2_FD2)
begin
if F2_FD2 = '1' then
F1_FD0 <= '0';
elsif rising_edge(START) then
F1_FD0 <= '1';
end if;
end process;

process (CLK_2)
begin
if rising_edge(CLK_2) then
F2_FD1 <= F1_FD0;
if (F2_FD1 = '1') then
F2_FD2 <= not F2_FD2;
end if;
end if;
end process;

Q <= F2_FD2;
end architecture;

Что интересно, что бы Вы не делали, лучше Тицце и Шенка все равно не сделаете. Вот его реализация без петли обратной связи.

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity sync_clka is port (
START: in std_logic;
CLK_2: in std_logic;
Q: out std_logic );
end entity;

architecture sync_clk_body of sync_clka is

signal F1_FD0: std_logic := '0';
signal F2_FD1: std_logic := '0';
signal F2_FD2: std_logic := '0';

begin
process (START, CLK_2)
begin
if START = '1' then
F1_FD0 <= '1';
elsif rising_edge(CLK_2) then
F1_FD0 <= '0';
end if;
end process;

process (CLK_2)
begin
if rising_edge(CLK_2) then
F2_FD1 <= F1_FD0;
F2_FD2 <= F2_FD1;
end if;
end process;

Q <= not F2_FD2 and F2_FD1;
end architecture;

Уважаемый sazh!

Ничего если я замечу, что чтение литературы не заменяет самостоятельных размышлений?
Приведенная Вами схема опасна и ни в коей мере не эквивалентна исходной. Потому что метастабильное состояние триггера D1 может неконтролируемо распространяться через выход Q на неопределенную часть схемы. Исходная схема этим свойством не обладает - в ней возможная метастабильность D1 ограничена коротким путем через XOR лишь входом второго триггера.



Обладает - но не факт, что путь через него быстрее пути через LUT.
Я когда-то исследовал один тестовый пример - меня удивляло, почему синтезатор использует LUT вместо такого хорошего встроенного XORF. Написал использование элемента явно. Получил слегка большее время.

To Oldring.
///////////////////////////////////////////
Вашу мысль я не понял. Потому что аппаратного xor я здесь не вижу.
Что касается Тицце и Шенка, Вы сами заметили, что их схема без учета метастабильности. Вы рекомендовали еще один триггер. Нет проблем. Я поставлю. Хотя когда мыслил самостоятельно, я этого не делал.

Ну так дело в том, что исходная схема делает все что нужно с учетом метастабильности - ей дополнительный триггер не нужен.

Я на триггерах не экономлю. (В реальности уже давно ставлю дополнительный буфер. Я тут тексты выкладывал. Уверен, Вы даже не взглянули на них). Для меня важней простота, наглядность. Читаемость схемы сходу пользователем любой квалификации.

Простите, но если ресь идет об этом тексте (других Ваших текстов я в топике не вижу):



то, поверьте, именно о нем я и пишу. Наглядность и читаемость - это здорово, но хорошо бы еще чтобы схемы были работоспособными IMHO синхронизатор - вещь тонкая, понятной для каждого быть не может по определению, поэтому для него важнее оформление в виде отдельного компонента и куча предупреждающих и поясняющих комментариев, чтобы не трогали.

Ничего если я замечу, что чтение njgbrf не заменяет самостоятельных размышлений?


Имелось ввиду топика

Я пока пишу в AHDL и только собираюсь переходить на Verilog, а с VHDL не знаком вовсе.А то что то сложно за Вашими мыслями угнаться. Думаю не я один такой.
Вы бы не могли рисунками показывать свои идеи, ведь схемы не сложные, да и наглядней получается. Простота ведь она сестра таланта и понятно всем станет........ и интересно.

Ничего - но не могу понять, к каким выводам я должен прийти после размышлений. Торможу, наверное. Не подскажете? Вы же не будете оспаривать, что Ваш код в том виде, в котором он опубликован, не обладает свойством устойчивости к метастабильности, в отличие от исходного кода, несмотря на то, что Вы утверждали, что исходный код можно заменить Вашим?

Функционально можно заменить. Что касается текста, я имел ввиду файлы *.zipб которые все уже посмотрели кроме Вас. Поэтому с метастабильностью вопрос у всех уже закрыт.
Если все в совокупности польностью рассмореть, все и так уже понятно.
Единственное, что печалит, после Ваших высказываний я уже врядли дождусь чего то от авторов текстов. Мне ведь действительно интересно их мнение.

Файлы?

Возможно, я действительно что-то упустил. Я видел только один zip - вчера с именем ________________.zip. Его я сразу же просмотрел. Вы имеете в виду какой-то другой zip, который я постоянно пропускаю? И какие-то Ваши вопросы, мнение по поводу которых Вас интересует?

И потом, что означает "заменить функционально"? Это как - заменить все-таки можно, наплевав на то, что в железе с новым кодом могут возникнуть проблемы, которые в исходной схеме возникнуть не могут?

Недавно фильм Павлв Лунгина посмотрел. Остров называется. Рекомендую.

Знаете, это уж совсем

Или Вы всегда так возражаете когда Вас ловят на ошибках?

Приношу свои извинения.

А нарисовать можно, то о чём вы спорите.
У меня как раз 10 битовая АЦП на 32 мегагерца и плисс Cyclone II. Второй день экспериментирую с приёмом данных с АЦП.
Если будет рисунок"схемма" ваших идей , я смогу сразу протестить её на своей плате.

Простите, но лично я рисованием логики никогда не баловался. Сразу в тексте писал. Так что разве что кто-нибудь Вам поможет, но ради такого случая разбираться с редакторами - уж извините...

пожалуйста, вот она, изучайте на здоровье - буду рад, если она сможет еще в каком-нибудь месте послужить обороноспособности нашей великой Родины:

Нажмите для просмотра прикрепленного файла


Чтобы не возникало подобных вопросов я привел СВОЮ постановку задачи для СВОЕЙ схемы. У вас другая задача ? - Если да, то и делайте по другому. Дальнейшие дискусии на тему "А почему нет входа того-то ?" или "А что будет если оторвать выход такой-то" считаю нецелесообразными. Вместо XOR вы можете ставить все что, вам больше понравиться или лучше подойдет к вашей конкретной задачи.


А при том, что решения работают устойчиво на предельных частотах ПЛИС, ТОЛЬКО если вы учитываете аппаратные особености ПЛИС. (Надеюсь это не вызывает сомнений ?)

XOR - для XPLA3 аппаратный, и, как я писал выше, обладает некоторыми очень интересными (для меня) особенностями - коими я и воспользовался, городя эту схему. Ведь не забывайте, этот элемент работает не на ТАКТОВОЙ частоте, а часто он вынужден на входе своем иметь ВЧ колебания триггера F1_D0. (кстати LUT'ов XPLA3 не имела и иметь не собирается)


Я работаю в областях очень чувствительных к сбоям техники - поэтому применяю решения не легко читаемые, а безотказные.
Поделились с вами хорошей схемой - радутесь. Не нравиться - не используй. А что на куда и каким образом легло в ПЛИС это уже мое дело.

Спасибо Boris_TS за схемку
Конечно же Вы правы, кажый может делать схемы по своему, так и делаем.
Интересны ИДЕИ !!!! А уж применять их или нет , дело каждого.
Я так думаю