[Kazap 0]

Доброго всем времени суток

До настоящего момента работал только с CPLD, особых проблем не было. Но для текущего проекта ресурсов CPLD не хватает

Проект -офисная миниАТС,- в FPGA (подошла acex1k), коммутационная матрица, синхронный порт,

тональные генераторы и много чего другого. Наблюдаю следующую картину-отлаживаю один узел, другой, берусь за третий отлаживаю,- начинает сбоить первый, вношу какие -то изменения в один узел- почему влияет на второй, и так замкнутый круг. Это что, нормальная ситуация с FPGA? Или я что-то не так делаю?

[papasha 0]

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

[Самурай 12]

Доброго всем времени суток

До настоящего момента работал только с CPLD, особых проблем не было. Но для текущего проекта ресурсов CPLD не хватает

Проект -офисная миниАТС,- в FPGA (подошла acex1k), коммутационная матрица, синхронный порт,

тональные генераторы и много чего другого. Наблюдаю следующую картину-отлаживаю один узел, другой, берусь за третий отлаживаю,- начинает сбоить первый, вношу какие -то изменения в один узел- почему влияет на второй, и так замкнутый круг. Это что, нормальная ситуация с FPGA? Или я что-то не так делаю?

 

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

[chan 0]

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

[ybd 0]

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

[dmivs 0]

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

Я например, работал только с Xilinx.

[maior 0]

Общие рекомендации:

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).

 

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

[Kazap 0]

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

[Alex_vod 0]

В своё время многие проблеммы с синхронизацией решила вот такая простенькая схемма. Нашёл её в quartusii_handbook

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

[EugeneS 0]

В своё время многие проблеммы с синхронизацией решила вот такая простенькая схемма. Нашёл её в quartusii_handbook

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

 

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

 

:blink:

[Alex_vod 0]

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

тогда как же поступают при приходе асинхронного сигнала, что бы вписать его в синхронную систему???

[LeonY 0]

В своё время многие проблеммы с синхронизацией решила вот такая простенькая схемма. Нашёл её в quartusii_handbook

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

 

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

 

:blink:

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

[Oldring 0]

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

 

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

[sazh 3]

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

////////////////////////////

Наверно имеет смысл при этом добавить - при приеме данных.

Приведенная выше схема под названием синхронный одновибратор давно уже имеено в таком виде озвучена у Тицце и Шенка.

Идея в том что эта схема обычно используется для преобразования именно клока, который сопровождает данные. Gate clk - в enable clk. И если данные, сопровождаемые gate клоком укладываются хотя бы в два периода глобального клока, то уже без разницы, как воспримет второй триггер метастобильность первого. Данные уверенно будут приняты или в первом такте или во втором.

Да и от частоты клока очень многое зависит. В свое время забавно было читать, как два теоретика рассуждали о том , что лучше принимать данные на частоте 20 мГц чем на 40. И их мало интересовало, есть ли у пользователя такие частоты.

[Alex_vod 0]

Я согласен с Вашими замечаниями... В этом вопросе так глубоко не копал (распределение вероятности, экспонента,метастабильность.... сложные вопросы)

Приведённая мной схема очень проста , но в большенстве случаев работает.

Тогда может вы подскажите другое решение.

Что лучше использовать при приёме данных? Какую схему используете вы?