[rv3dll 0]

то что он проведёт дорожку до менеджера клоков не по выделенной линии меня не волнует

 

какие ещё могут быть проблемы

 

virtex4 fx20

[tolik1 0]

то что он проведёт дорожку до менеджера клоков не по выделенной линии меня не волнует

 

какие ещё могут быть проблемы

 

virtex4 fx20

У меня стоит и никаких особых проблем не было. Хотя хочу попробовать добиться чтобы от этой переменной избавиться. Думаю надо BUFG привязать LOCом. Чтобы она сразу повела на нужный BUFG .

[rv3dll 0]

У меня стоит и никаких особых проблем не было. Хотя хочу попробовать добиться чтобы от этой переменной избавиться. Думаю надо BUFG привязать LOCом. Чтобы она сразу повела на нужный BUFG .

поделись как сделаешь!!!

[rloc 51]

... Хотя хочу попробовать добиться чтобы от этой переменной избавиться. Думаю надо BUFG привязать LOCом. ...

 

От этой переменной избавиться нельзя. Если такты заводить не на ножку глобальных тактов, то возможна нестабильная работа DCM, если таковые используется. У меня были случаи, когда только половина DCM'ов работала стабильно, на другой половине похоже была плохая ЭМС по входному сигналу.

[evsh 0]

Не совсем понятна ситуация:

1. Используется не_GC primary нога нужной половины для ввода частоты в кристалл?

2. Используется BUFG не той же половины, что и DCM?

 

Проблемы будут если частота связана с другими внешними сигналами (например, частота PCI). Хотя, это тоже решаемое. Иначе, теоретически, всё должно быть нормально. На практике гарантировать стабильную работу, конечно, не буду, но у меня всё было хорошо.

 

Да, начиная с ISE 10 эта переменная не работает. Нужно использовать в ucf атрибут CLOCK_DEDICATED_ROUTE:

NET "CLK_I" CLOCK_DEDICATED_ROUTE = TRUE;

[rloc 51]

Речь идет когда такты заводятся не через ногу _GC_, т.е. такты попадают с обычной ноги на BUFG через роутинг.

[rv3dll 0]

на самом деле у меня через глобал клок входы -

 

два клока один внешний с другой платы

другой внутренний - генератор на этой плате

 

входы оба в одном банке чуть ли не соседние ноги - но через 1 компилирует а через другой(отладочный) нет

 

переменную поставил вроде всё работает

[rloc 51]

Можно поподробнее: номера ног, название и тип корпуса?

[rv3dll 0]

Можно поподробнее: номера ног, название и тип корпуса?

 

xc4vfx20

 

ноги AF14 AF15

[rloc 51]

xc4vfx20

 

ноги AF14 AF15

 

Если я правильно понимаю, то речь идет о корпусе FF672 и ноги зовутся IO_L2P_GC_LC_4 и IO_L1N_GC_LC_4?

Если так, то только с первой ноги можно завести на BUFG или DCM посредством "dedicated routing", со второй ноги - только в случае, когда входной сигнал дифференциальный и она является комплементарной с IO_L1P_GC_LC_4 (AE15).

[evsh 0]

Если я правильно понимаю, то речь идет о корпусе FF672 и ноги зовутся IO_L2P_GC_LC_4 и IO_L1N_GC_LC_4?

Если так, то только с первой ноги можно завести на BUFG или DCM посредством "dedicated routing", со второй ноги - только в случае, когда входной сигнал дифференциальный и она является комплементарной с IO_L1P_GC_LC_4 (AE15).

Так точно. Или принудительно с переменной.

 

Тут ещё такой момент есть. Если есть привязка к другим сигналам, то нужно учитывать, что частота, заходящая на ножку *N_GC_* будет сдвинута на 180 градусов.

[tolik1 0]

От этой переменной избавиться нельзя. Если такты заводить не на ножку глобальных тактов, то возможна нестабильная работа DCM, если таковые используется. У меня были случаи, когда только половина DCM'ов работала стабильно, на другой половине похоже была плохая ЭМС по входному сигналу.

Не совсем так. Речь идет о том случае когда тактовый сигна на плате подается на Пин_GC внутри кристалла на BUFG а далее в устройство.

Может я и ошибаюсь но мне видится следующая логика работы.

1 Сначала разводится устройство.

2 К нему подключается BUFG, оптимально подходящий (по местоположению в кристалле) с точки зрения разведенного(синтезированного) устройства.

3 Вход BUFG пытается провести к пину. И тут выясняется что данная трасса не оптимальна.

BUFG - вещь аппаратная и помоему имеет привязку к конкретному пину.(Здесь могу ошибаться)