Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: FIFO generator 9.1
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Mar_K
Проект на spartan6 -3 grade. Два тактовых домена 75 и 200 МГц. Передаю данные между ними с использованием FIFO (fifo generator 9.1), разрядность которого 64 бита чтение и запись. Тайминг аналайзер пишет, что все констрейyты выполнены, однако, в секции "Unconstrained" есть проваленные по hold time именно внутри самого FIFO (грейкаунтер похоже: U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/wr_pntr_gc_4 to U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/gsync_stage[1].rd_stg_inst/Q_4). Соответственно проект глючит.

У меня несколько вопросов:
1) Реально ли получить работающий FIFO с такими параметрами в данном кристале?
2) Как правильно написать ограничения?

По поводу второго вопроса читал DS317, но там для 16 разрядного случая. Еще задавал timespec на оба клока и устанавливал maxdelay datapathonly на передачу данных между ними равную 5ns. После чего из секции unconstrained эти пути пропадали и ошибок вообще не наблюдалось в аналайзере, но в работающем железе по прежнему глюки. Если вместо 200 МГц запустить, на, скажем, 150 МГц то все гут.
des00
ИМХО 99% что глючит не FIFO
Golikov A.
какого рода глюки то? И как у вас фифо на клоки подключено? А клоки через буферы идут или нет? И еще вопрос как было вычислено что путь распространения между клоками именно 5 наносекунд максимум?
Mar_K
Клоки генерятся разными PLL и подключены через bufg естественно. Про 5 наносекунд, они не были никак вычислены, а просто взяты от балды.
Род глюков таков, что если всего в фифо записывается 64 слова, то прочитается, например, 63.
des00
Цитата(Mar_K @ Oct 13 2014, 12:11) *
Род глюков таков, что если всего в фифо записывается 64 слова, то прочитается, например, 63.

либо пишете не 64, либо ошибка в логике чтения, например не выдерживаете требования к интерфейсам сгенерированного фифо
Mar_K
Цитата(des00 @ Oct 13 2014, 09:39) *
либо пишете не 64, либо ошибка в логике чтения, например не выдерживаете требования к интерфейсам сгенерированного фифо

Тоже больше склоняюсь к этому варианту. Делал diff с рабочей версией по svn, но пока принципиальной разницы не нашел..
andrew_b
Цитата(Mar_K @ Oct 12 2014, 20:57) *
2) Как правильно написать ограничения?

По поводу второго вопроса читал DS317, но там для 16 разрядного случая.
Смотрите ug175, параграф "Setup and Hold Time Violations".
Вместо описывания каждого разряда можно использовать wildcard'ы.
Mar_K
Цитата(andrew_b @ Oct 13 2014, 10:17) *
Смотрите ug175, параграф "Setup and Hold Time Violations".
Вместо описывания каждого разряда можно использовать wildcard'ы.

Понял. Значит можно просто забить на это, а проблема остается в неправильной обработке.
Mar_K
Понизил частоту с 200 до 160 МГц. Работает стабильно. А на 200 нет. Может джитер адский? К сожалению нет возможности посмотреть так как нет хорошего осцила в наличии. У меня кит от Avnet.
des00
вы случайно порты usedw или аналогичные для чтения не используете ?
Mar_K
Цитата(des00 @ Oct 13 2014, 20:25) *
вы случайно порты usedw или аналогичные для чтения не используете ?

Нет не использую. Вчера до поздней ночи игрался с констрейнтами и пришел к выводу, что я просто не понимаю как их описать правильно. Если эти сигналы не появляются в отчете об ошибках, то схема работает на 200 МГц стабильно, но при этом в других местах в отчете появляются ошибки, там где они раньше не вылезали. В проекте до недавнего времени было 2 тактовых домена (62.5 и 75 МГц) и все разводилось и роботало четко. Но после добавления третьего (200 МГц) начались такие вот странности. Причем схема, которая тактируется от 200 МГц отдельно укладывается в плис без ошибок.

Amurak
Цитата(Mar_K @ Oct 14 2014, 09:59) *
Нет не использую. Вчера до поздней ночи игрался с констрейнтами и пришел к выводу, что я просто не понимаю как их описать правильно. Если эти сигналы не появляются в отчете об ошибках, то схема работает на 200 МГц стабильно, но при этом в других местах в отчете появляются ошибки, там где они раньше не вылезали. В проекте до недавнего времени было 2 тактовых домена (62.5 и 75 МГц) и все разводилось и роботало четко. Но после добавления третьего (200 МГц) начались такие вот странности. Причем схема, которая тактируется от 200 МГц отдельно укладывается в плис без ошибок.

Клоки друг от друга отвязаны? В ISE это делается так:

NET "CLK_200" TNM_NET = "CLK_200";
TIMESPEC TS_CLK_200 = PERIOD "CLK_200" 200 MHz HIGH 50 %;
NET "CLK_100" TNM_NET = "CLK_100";
TIMESPEC TS_CLK_100 = PERIOD "CLK_100" 100 MHz HIGH 50 %;

TIMESPEC TS_200to100_tig = FROM "CLK_200" TO "CLK_100" TIG ;
TIMESPEC TS_100to200_tig = FROM "CLK_100" TO "CLK_200" TIG ;
Mar_K
Цитата(Amurak @ Oct 14 2014, 13:02) *
Клоки друг от друга отвязаны? В ISE это делается так:

NET "CLK_200" TNM_NET = "CLK_200";
TIMESPEC TS_CLK_200 = PERIOD "CLK_200" 200 MHz HIGH 50 %;
NET "CLK_100" TNM_NET = "CLK_100";
TIMESPEC TS_CLK_100 = PERIOD "CLK_100" 100 MHz HIGH 50 %;

TIMESPEC TS_200to100_tig = FROM "CLK_200" TO "CLK_100" TIG ;
TIMESPEC TS_100to200_tig = FROM "CLK_100" TO "CLK_200" TIG ;



Все именно так. Дело не в констреинтах.
Вобщем я был наивен, когда полагал что без синхронизации пока для небольшого теста можно обойтись, хотя до этого всегда делал сразу по нормальному, а потом и вовсе забыл про синхронизацию сигнала разрешения чтения FIFO специальным блоком в 200 МГц домене. Как результат 1.5 недели наблюдения эпических глюков и бессонных ночей с обтеканием потом, который вытирался полотенцем из UCF.

Не забивайте на синхронизацию, люди.
des00
Цитата(Mar_K @ Oct 14 2014, 19:06) *
Не забивайте на синхронизацию, люди.

судя по второму посту я почти телепат sm.gif))))))
Bad0512
Цитата(Mar_K @ Oct 14 2014, 19:06) *
Все именно так. Дело не в констреинтах.
Вобщем я был наивен, когда полагал что без синхронизации пока для небольшого теста можно обойтись, хотя до этого всегда делал сразу по нормальному, а потом и вовсе забыл про синхронизацию сигнала разрешения чтения FIFO специальным блоком в 200 МГц домене. Как результат 1.5 недели наблюдения эпических глюков и бессонных ночей с обтеканием потом, который вытирался полотенцем из UCF.

Не забивайте на синхронизацию, люди.

Прочитал весь топик по дигонали. 2 замечания :
1. Размер корегеновских фифошек у Хилых исторически всегда на 1 меньше размера памяти под фифошку.
Об этом написано в документации - читайте внимательно. Зачем это сделано? Могу только догадываться, думаю что для упрощения логики full/empty.
2. Недопустимо использовать для работы связанных с фифошкой автоматов сигналы из другого клокового домена.
Поэтому для автомата чтения пользуем только флаг fifo_prog_empty (уровень программируется), а для автомата записи - аналогичный флаг fifo_prog_full.
В противном случае автоматы начинают глючить, а вы в итоге чтобы обойти эти грабли начинаете городить синхронизаторы.
А нужно было всего лишь выбрать правильный флаг.
Mar_K
Цитата(Bad0512 @ Oct 15 2014, 09:40) *
Прочитал весь топик по дигонали. 2 замечания :
1. Размер корегеновских фифошек у Хилых исторически всегда на 1 меньше размера памяти под фифошку.
Об этом написано в документации - читайте внимательно. Зачем это сделано? Могу только догадываться, думаю что для упрощения логики full/empty.
2. Недопустимо использовать для работы связанных с фифошкой автоматов сигналы из другого клокового домена.
Поэтому для автомата чтения пользуем только флаг fifo_prog_empty (уровень программируется), а для автомата записи - аналогичный флаг fifo_prog_full.
В противном случае автоматы начинают глючить, а вы в итоге чтобы обойти эти грабли начинаете городить синхронизаторы.
А нужно было всего лишь выбрать правильный флаг.

По поводу 2 -- вы себя накрутили. У меня ридер фифиошки как раз этими флагами управляется, а синхронизируется только сигнал разрешения работы этого ридера. Я еще не настолько псих чтобы дизайнить как вы написали, и не вижу в теме моего поста с описанием того, что у меня именно так сделано.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.