я такое поведение наблюдал и на 2 МГц. На меньших частотах вероятность поймать сбой ниже, на высоких частотах обычно сбой сразу видно, а на низких он может вылезти со временем. Это делает эту проблему еще более неприятной, т.к. прячет её до поры до времени.
Это самая неприятная вещь по сравнению с обычным программированием в котором состояние всегда детерминировано. На FPGA при использовании асинхронных конструкций начинаются приколы не токько с race conditions но и с метастабильностью.
Возможно на Xilinx это и так, но на Altera/Cyclone (например IV или 10) это точно не так. В них клок можно либо завести через специальный GPIO поддерживающий CLK (а таких GPIO немного), либо сгенерировав на PLL. Других вариантов сгенерировать клок на Altera/Cyclone нет, никакие хаки не не помогут - в чипе физически нет возможности пробросить обычный сигнал на шину клоков. А блоки которые имеют выход на шину клоков (типа PLL) невозможно затактировать от обычного сигнала, они тактируются только от клоков. При синтезе будет просто ошибка, даже если с синтаксисом все будет в порядке.
я знаю про constraints и в описываемом случае они были подробно заданы. И как-раз меняя их я и игрался пытаясь обойти эти баги. Но в итоге пришел к тому, что использование подобных асинхронных конструкций приводит только к практически неустраняемым плавающим сбоям и от их использования лучше просто отказаться. Самое неприятное, что использование подобных конструкций может создать первое впечатление что всё работает, но проблемы обязательно вылезут позже...
Вместо того, чтобы вешать логику на разные фронты клока, я думаю более надежный и простой вариант - сгенерировать в два раза более высокочастотный клок на PLL и тактировать всё по одному фронту от одного клока.
Нет, что касается Altera/Inter Cyclone IV и 10, там физическое ограничение - невозможно пробросить обычный сигнал на шину клоков. Физически нет таких соединений на кристалле. Отсюда и требование использовать либо клоковый пин либо PLL. Можно нагуглить статьи и app notes про это и именно там сказано что это невозможно физически. На форумах можно найти хаки как это якобы можно обойти, но они позволяют только обойти ошибки начального анализа. При синтезе всеравно вылезет ошибка.
Можете попробовать поиграться в Quartus - завести обычный сигнал в качестве клока на PLL. Гарантирую, для Cyclone IV и 10 у Вас это точно не получится, у них физически невозможно завести обычный сигнал на клоковый вход.
Клоковые сигналы и обычные разводятся физически на разных шинах и у обычных сигналов джиттер больше из-за особенностей FPGA. Кроме того невозможно обеспечить точные задержки для сброса и установки обычного сигнала, поэтому на выходе счетчика не будет 50% duty cycle. Поэтому если Вы используете оба фронта, то у Вас уже возникает проблема, т.к. длительность одного из полупериодов будет меньше и соответственно выше требование к максимальной частоте схемы которая тактируется одним из фронтов...
к сожалению не гарантирует. Более того, предсказать какой получится скважность нереально - это будет зависеть от разводки, поэтому малейшее изменение в коде может привести к изменению скважности и то что до этого работало перестаент работать и наоборот...
Скважность точно задать можно только на PLL. Более того, на PLL можно еще и точную задержку фазы указать.



Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 


