[SM 0]

как так? если я сам пишу то как я могу не знать выполняю я требуемые спецификации или нет?

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

[axalay 0]

http://electronix.ru/forum/index.php?showtopic=66052&hl=

Спасиб-лишним не будет это сделать. Я так понимаю-это облегчает жизнь разводчику?

 

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

Вот к примеру данные на память 125 DDR. Я осцилом смотрю и вижу что все ровно посередке-как и требует даташит на память.

А это по рекомендациям ксалинкса :

 

wire ENVOI;

FDC FDC_ENVOI (

.Q (ENVOI),

.D (VCC),

.C (~Clock90),

.CLR (~W_BAR) );

 

wire D1_FDC;

FDC WRT_FDC_D1 (

.Q (D1_FDC),

.D (D1),

.C (~Clock90),

.CLR (Reset) );

 

wire Q_BUF;

FDDRRSE WRT_FDDR_DQ (

.Q (Q_BUF),

.D0 (D0),

.D1 (D1_FDC),

.C0 (~Clock90),

.C1 (Clock90),

.CE (LockedDcm),

.R (Reset),

.S (GND) );

 

OBUFT WRT_FDDR_DOBUFT (

.I (Q_BUF),

.O (Q),

.T (ENVOI) );

 

Все как хотел так и получил. Я не думаю что из-за температуры времянка настолько сдвинется. А если это так (сдвинется) то и констрейны тут не помогут

 

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

Вот к примеру данные на память 125 DDR. Я осцилом смотрю и вижу что все ровно посередке-как и требует даташит на память.

А это по рекомендациям ксалинкса :

 

wire ENVOI;

FDC FDC_ENVOI (

.Q (ENVOI),

.D (VCC),

.C (~Clock90),

.CLR (~W_BAR) );

 

wire D1_FDC;

FDC WRT_FDC_D1 (

.Q (D1_FDC),

.D (D1),

.C (~Clock90),

.CLR (Reset) );

 

wire Q_BUF;

FDDRRSE WRT_FDDR_DQ (

.Q (Q_BUF),

.D0 (D0),

.D1 (D1_FDC),

.C0 (~Clock90),

.C1 (Clock90),

.CE (LockedDcm),

.R (Reset),

.S (GND) );

 

OBUFT WRT_FDDR_DOBUFT (

.I (Q_BUF),

.O (Q),

.T (ENVOI) );

 

Все как хотел так и получил. Я не думаю что из-за температуры времянка настолько сдвинется. А если это так (сдвинется) то и констрейны тут не помогут

[SM 0]

Все как хотел так и получил. Я не думаю что из-за температуры времянка настолько сдвинется. А если это так (сдвинется) то и констрейны тут не помогут

 

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

 

Что касается "то и констрейны тут не помогут" - опять заблуждение. Помогут. Для того они и придуманы. STA анализирует все на всех корнерах, и если где-то что-то не так, это причина для дальнейшей оптимизации, пока все слаки не станут неотрицательными.

[Victor 0]

Все как хотел так и получил. Я не думаю что из-за температуры времянка настолько сдвинется. А если это так (сдвинется) то и констрейны тут не помогут

Вот у вас, как вы говорите, все вручную. А примитив в IOB не положен. Если вдруг потеснее в кристалле станет, настройки синтезатора забудете поставить, чтобы в IOB регистры входные-выходные складывал, ну или настройка по умолчанию изменится в следующей версии ;) сдвинется вами вручную положенный примитив в сторону на пол-кристалла, и получите дополнительно пару нан... А если описать времянки, то синтезатор/PAR будет _обязан_ это учитывать.

А если уж очень хочется вручную, тогда добавьте атрибут IOB = TRUE ну или в конце концов не FDDRRSE, а OFDDRRSE вставлять.

Еще IOBDELAY надо не забыть, Его тоже синтезатор может сам подергать, а это как-никак около 3 нс...

 

При STA по умолчанию подразумеваются самые худшие условия по температуре и напряжению питания.

Очень рекомендую OFFSET посмотреть... Полезно.

[axalay 0]

Понятно: лень - двигатель прогресса.

Вся проблема в том что мне в последствии пришлось клок поднимать. До этого все работало. После переписывания Сторона Rx работает как надо (F max довел дщ 140 МГц). По Tx надо поднять это число с 102. Осталось переписать 1 файло. За советы спасибо-это не из-за лени. Просто такой необходимости не было. Ша ucf допишу. Между прочим я тему как раз для этого и открыл, чтоб советы послушать. У меня весь этот сыр-бор из-за того , что в плис приходит 10 клоков (8 клоков с PHY, один с памяти и еще с главного FPGA) а BUFGMUX всего 8. Вот и пришлось извратиться. Иначе рабочая частота была бы в 2 раза меньше, а там и без констрейнов все разводилось.

 

А если уж очень хочется вручную, тогда добавьте атрибут IOB = TRUE ну или в конце концов не FDDRRSE, а OFDDRRSE вставлять.

Еще IOBDELAY надо не забыть, Его тоже синтезатор может сам подергать, а это как-никак около 3 нс...

В данном спартане OFDDRRSE нема.

[axalay 0]

добавил:

# multi-cycle paths -- clock enables

NET "clock_gen/Clock125Ena" TNM = Clock125Ena;

TIMESPEC TS_Clock125Ena = FROM Clock125Ena TO Clock125Ena TS_BusRxClock_p/4;

 

NET "clock_gen/Mac0ClockEna" TNM = Mac0ClockEna;

TIMESPEC TS_Mac0ClockEna = FROM Mac0ClockEna TO Mac0ClockEna TS_BusRxClock_p/4;

NET "clock_gen/Mac1ClockEna" TNM = Mac1ClockEna;

TIMESPEC TS_Mac1ClockEna = FROM Mac1ClockEna TO Mac1ClockEna TS_BusRxClock_p/4;

NET "clock_gen/Mac2ClockEna" TNM = Mac2ClockEna;

TIMESPEC TS_Mac2ClockEna = FROM Mac2ClockEna TO Mac2ClockEna TS_BusRxClock_p/4;

NET "clock_gen/Mac3ClockEna" TNM = Mac3ClockEna;

TIMESPEC TS_Mac3ClockEna = FROM Mac3ClockEna TO Mac3ClockEna TS_BusRxClock_p/4;

 

легче не стало. Но я так понял-это лишним не будет. Все вроде верно написал?

[andrew_b 14]

добавил:

[...]

легче не стало. Но я так понял-это лишним не будет. Все вроде верно написал?

В логах про эти констрейны что-нибудь есть?

[axalay 0]

В логах про эти констрейны что-нибудь есть?

Все нафиг-перекур на 4 дня! Логи после выходных выложу. Наблюдаются интересные штучки при использовании мультициклов-отпишусь тоже после праздников

[Postoroniy_V 0]

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

 

Что касается "то и констрейны тут не помогут" - опять заблуждение. Помогут. Для того они и придуманы. STA анализирует все на всех корнерах, и если где-то что-то не так, это причина для дальнейшей оптимизации, пока все слаки не станут неотрицательными.

 

Понятно: лень - двигатель прогресса :laughing: Это к Васе-ахалую напрямую относится

2 axalay

Василий, ты всё такой же ленивый!

Эх ничего не меняется :cranky:

[axalay 0]

Эх ничего не меняется :cranky:

:) Постояноство-признак мастерства! Его не пропьешь!

 

А теперь по мультициклам. Есть 4 модуля каждый из которых работает по своему клок енабля.

// Mac0ClockEna _|---|___________|---|___________|---|___________|---|

// Mac1ClockEna _____|---|___________|---|___________|---|___________|

// Mac2ClockEna _________|---|___________|---|___________|---|_______

// Mac3ClockEna _____________|---|___________|---|___________|---|___

 

Есть еше остальная часть (схема управления) на которую я завел Mac0ClockEna. Так вот: до того как мультицикл не был описан работало и управление и все остальное и приемная часть маков (про передающую часть я уже писал-кардиналоно переписать одно файло). Описал мультициклы-и перестал работать первый канал по приему (как раз тот самый Mac0ClockEna). Но при этом управление и все остальное продолжают свою работу. Когда же я убрал с остальной части клок енабля-все снова начало работать (кроме передающей части разумеется-чудес не бывает). Вот вам и мультициклы и лень :) Жду комментов - почему? Вроде как минимум хуже стать не должно было. Но факт остается фактом.

[des00 25]

Жду комментов - почему? Вроде как минимум хуже стать не должно было. Но факт остается фактом.

Версии :

1. У вас в схеме реально синтезировался не клок енабле. Т.е. где то у вас есть переход с регистров которые хлопают по енаблу, на регистры которые по нему не хлопают, а енабле входит в логику на входе этого регистра.

2. Вылез потенциальный баг который вы раньше не заметили.

 

Как лечить :

1. Быстро и лениво : на альтере сигнал тапом проблема решается махом, на хилых чипскоп в руки, но возможно глюки велкам

2. Не быстро и нужно подумать : внимательно читаем код, смотрим отчет синтезатора и начинаем работать по Хаусовски, идем по симптомам, выдвигая версии причин %)

[axalay 0]

Версии :

1. У вас в схеме реально синтезировался не клок енабле. Т.е. где то у вас есть переход с регистров которые хлопают по енаблу, на регистры которые по нему не хлопают, а енабле входит в логику на входе этого регистра.

2. Вылез потенциальный баг который вы раньше не заметили.

 

Как лечить :

1. Быстро и лениво : на альтере сигнал тапом проблема решается махом, на хилых чипскоп в руки, но возможно глюки велкам

2. Не быстро и нужно подумать : внимательно читаем код, смотрим отчет синтезатора и начинаем работать по Хаусовски, идем по симптомам, выдвигая версии причин %)

Сто пудов в клок енабле - смотрел уже в кристалле куда она заводится в триггеры. И именно туда куда надо-на вход енабле.

"Вылез потенциальный баг который вы раньше не заметили." - это стандартный ответ. Ну при чем тут баг. Если без описания мультициклов все работает. А с ними первый канал перестает. А причина скорее всего в том, что тот клок енабле, который используется в первом канале-использовался по всему кристаллу. Когда я это исключил. То все 4 канала стали снова работать. Но при этом я в коде ничего не менял, а клок енабле входит именно туду куда я и хотел. Чипскопои м сигналтапом я умею пользоваться и пользуюсь. Чтоб не выглядеть голословным-выкладываю картинко. Да и я не в первом классе, чтоб мне говорили что такое описание заведет клок енабле в D вход триггера.

 

// addr calc fsm

reg [1:0] State;

always @(posedge Clock or negedge Reset)

if (!Reset) begin

State=STATE_PAUSE;

AddrStart=Min;

AddrCalc=Min;

end //if

else if (ClockEna&Ena) begin

case (State)

STATE_PAUSE : begin

if (Write) begin

State=STATE_INC;

AddrCalc=(AddrCalcComp)?(AddrCalc+1):Min;

end //if

end //STATE_PAUSE

STATE_INC : begin

if (End) begin

State=STATE_LOAD;

AddrCalc=(Err)?AddrStart:((AddrCalcComp)?(AddrCalc+1):Min);

end //if

else

AddrCalc=AddrCalc+1;

end //STATE_PAUSE

STATE_LOAD : begin

State=STATE_PAUSE;

AddrStart=AddrCalc;

end //STATE_LOAD

endcase //State

end //else if

 

И извините за прямолинейность. Могу выложить и с других мест, но поверьте на слово.

[andrew_b 14]

Нет никакого желания разбирать код с таким форматированием. Вас же просили использовать тэг code.

[des00 25]

Сто пудов в клок енабле - смотрел уже в кристалле куда она заводится в триггеры. И именно туда куда надо-на вход енабле.

вы просмотрели абсолютно все триггеры вашего проекта, куда заводиться нужны вам clk_ena?

 

"Вылез потенциальный баг который вы раньше не заметили." - это стандартный ответ. Ну при чем тут баг.

прежде чем отвечать не помешает немного подумать. На что влияет установка мультицкла на путь? Она влияет на то, что при анализе времянки и синтезе к пути будет применяться не период клока, а N периодов клока. Ни на что другое этот констрейн не влияет. Если же влияет, то это вопрос к разработчикам XST, что за г...о они сделали.

Если STA у вас прошло нормально, а проект не работает, то логично предположить что где-то есть место, которому нужна времянка Т, а применялась N*T. Следующий узел решения логической задачи, это понять, как при задании мультицикла к триггерам с Ena, мог быть допущен этот баг.

 

Вот пример где такое задание констрейнов (к триггеру, к которому приходит сигнал clk_ena) не корректно

always_ff @(posedge clk) begin
  if (ena) begin
    dat_a <= in_a; 
    dat_b <= in_b;  
  end 
  mult <= ena ? (dat_a*coe) : (dat_b*coe);
  if (ena) 
    res_a <= mult;
  if (~ena) 
    res_b <= mult;  
end

 

пути mult -> res_a, mult -> res_b не мультицикловые, тогда как по формальным признакам (на clk_ena приходит ena) будут анализироваться как мультицикловые.

 

И извините за прямолинейность. Могу выложить и с других мест, но поверьте на слово.

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

[Des333 0]

Ну, если с мультицклом не работает, а с без него работает, то скомпильте прошивку с мультициклом, потом уберите мультицикл из .sdc и проготите анализатором - вылезет конкретно тот путь, который "не уложился". Его потом конкретно и анализируйте.