[SM 0]

Кто поможет? Как обозначить чтобы данные менялись не раньше чем через заданное время после фронта?

 

в формате SDC:

 

set_output_delay -clock clock_name -min MIN_DELAY -max MAX_DELAY

 

а так, OFFSET OUT AFTER (не позже, чем, т.е. setup)/BEFORE (не раньше, чем, т.е. HOLD)

 

[Golikov 0]

OFFSET OUT AFTER (не позже, чем, т.е. setup)/BEFORE (не раньше, чем, т.е. HOLD)

 

чет я не так трактую мануал, но вроде

AFTER - это данные долнжны стать валидными не позже указанного времени после клока

а BEFORE, данные должны быть валидными не позже чем за указанное время до клока

 

а вот что данные могут меняться не РАНЬШЕ чем за указанное время ПОСЛЕ клока, вот такого чего - то нет... или я не правильно трактую мануал?

[olegras 0]

По какой - то причине то ли передача то ли прием сдвигается на 1 бит, причем в моделсиме все четко, а в железе кирдык.

 

Может поможет...

Помнится у меня была точно такая же проблема. Камень был Spartan-3E, SPI слейв, SCK был заведен на неклоковый вход, данные почемуто сдвигались на 1 бит, в симуляторе было все ОК. Долго мучался с этими констрейнами. Пока не вывалил все сигналы в чипскоп. Оказалось что последовательность сигналов SPI, которые я формировал в симуляторе отличается от последовательности, которые выдает МК. Точнее - их начало, когда CS опускается в ноль. Проблема решилась настройкой SPI на стороне МК (у него было несколько режимов SPI) и подправкой кода ПЛИС. После этого все констрейны удалил, кроме CLOCK_DEDICATED_ROUTE = FALSE; Правда SPI на МК был не очень шустрый - кажется порядка 20 МГц.

[o_khavin 0]

Мне кажется потенциально опасное решение. В начале работы на холодном кристале все пойдет по одному пути, потом он прогреется и...?

В процессе работы "путь" поменяться не может. :) Зависимость от температуры есть, но не в весь диапазон. Основной вклад даёт разброс параметров разных чипов. С этим калибровка и борется. Кстати, аналогичный механизм используется в коре Xilinx-а по работе с DDR-памятью - производится калибровка и подстройка задержки DQ относительно DQS.

 

[Golikov 0]

В процессе работы "путь" поменяться не может. :) Зависимость от температуры есть, но не в весь диапазон. Основной вклад даёт разброс параметров разных чипов. С этим калибровка и борется. Кстати, аналогичный механизм используется в коре Xilinx-а по работе с DDR-памятью - производится калибровка и подстройка задержки DQ относительно DQS.

 

при проверке констраинов 2 пути

коротки и длинный

коротки с запасом укладывается, длинны не укладывается. НА реальной железке если по 1 слову читать почти всегда все хорошо, если группу слов то временами вылазят ошибки.

 

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

 

Может поможет...

Помнится у меня была точно такая же проблема. Камень был Spartan-3E, SPI слейв, SCK был заведен на неклоковый вход, данные почемуто сдвигались на 1 бит, в симуляторе было все ОК. Правда SPI на МК был не очень шустрый - кажется порядка 20 МГц.

 

Спасибо за ответ,

на 25 МГц все работает, проблемы на 50 МГц. И их причина обнаружена, данные не успевают выставляться, даже тут уже есть несколько решений проблемы.

 

 

[SM 0]

а вот что данные могут меняться не РАНЬШЕ чем за указанное время ПОСЛЕ клока, вот такого чего - то нет... или я не правильно трактую мануал?

 

 

BEFORE на, например, -2 нс (либо на период клока - 2 нс), будет говорить о том, что данные должны удерживаться после фронта, не менее, чем 2нс (hold time), то есть меняться не раньше, чем.

 

 

Ну, по крайней мере, так должно быть, раз документация говорит, что BEFORE предназначено для анализа HOLD таймингов

[Golikov 0]

:) теперь бы еще узнать как это делается. Я совсем совсем не силен в констрейнах....

[olegras 0]

проблемы на 50 МГц. И их причина обнаружена, данные не успевают выставляться ...

 

SPI был настроен в такой режим. Выставление данных - по заднему фронту SCK. CS - на асинхронных ресетах клоковых процессов. Думаю, что и на 50 МГц должно работать.

 

 

[SM 0]

:) теперь бы еще узнать как это делается. Я совсем совсем не силен в констрейнах....

 

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

 

Но "анализ отчета анализатора", подробного отчета, должен по идее все расставить по своим местам.

 

----------------------

UPD:

Хмммм.... Пожалуй, я был неправ... Поверхностное чтение документации на констрейны xilinx показывает, что там нет возможности обконстрейнить HOLD для выходов (для входов однако есть - OFFSET IN ... VALID ....), есть только возможность его узнать, какое оно получилось, анализом минимального времени. И у самого есть вопрос к знатокам хилых - что, внатуре нет?

 

Странно все это...

[Dr.Alex 0]

Странно все это...

 

А каким образом вообще можно управлять минимальным холдом выхода? Он что, задержки там будет вставлять?

 

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

[Golikov 0]

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

 

Угнетает что на SPI проца нет никакой спецификации. Вот он захватывает данные по восходящему фронту, но нет никаких данных сколько они должны стоять до, и сколько после клока. И если косвенно "сколько до" можно прикинуть, данные должны выставлять по падающему клоку, то сколько они должны удерживаться - не понятно...

 

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

Реально это наверное невозможно, так как путь распространения сигнала до регистра и обратно все же не нулевой, и если я вижу фронт, то на проце он был заведомо раньше, но для очистки совести хотелось бы держать это время под контролем.

 

 

 

Вот кстати сейчас думаю воткнуть ДДР на входе и выходе которые есть у спартана 6, это позволит анализировать фронты входящего сигнала с точностью +- 5 нСек, а вот что мне для выхода даст пока не очень понимаю, но чувствуется что тоже что-то даст... почему мне не дают по 2 фронтам блин работать...

 

[Dr.Alex 0]

Угнетает что на SPI проца нет никакой спецификации.

 

Могу вам гарантировать что минимальный холд по входу у него 0.

[SM 0]

А каким образом вообще можно управлять минимальным холдом выхода? Он что, задержки там будет вставлять?

 

Латис, как и альтера, например, после разводки, когда все SETUP-ы утрясли, проводят (опциональный) "Par hold correction" (ниже привожу лог, как они, конкретно латис в данном случае, это делают в одном из проектов). Реально, они удлиняют пути от тех регистров, от которых оказался слишком быстрый путь на выход, либо удлиняя разводку, либо вставляя лишние буфера. Кстати. Точно так же делают и среды разводки заказных ИМС, тот же encounter например, втыкая лишние буфера куда надо, когда запускается коррекция холдов.

 

 

И вопрос стоял не "зачем", и не "как это внутри делается", а как это описать констрейнами:

 

дано: Спецификация PCI rev 3.0, Table 7-4, Tval, значения min=2нс, max=6нс, CLK=66МГц

 

для латиса:

 

CLOCK_TO_OUT PORT "pci_nTRDY" MAX 6.00 ns MIN 2.00 ns CLKPORT "pci_CLK" ;

 

для альтеры:

 

set_output_delay 9.1515 -clock pci_CLK -max [get_ports pci_nTRDY]

set_output_delay -2.00 -clock pci_CLK -min -add_delay [get_ports pci_nTRDY]

 

UPD: для пояснения, 9.1515 это период клока 66 МГц (15.1515) минус те самые 6 нс спецификации PCI/66

 

 

кстати. вот заодно и ответ на "зачем" - для PCI например. где 2 нс минимум по спецификации - и у кучи путей, разведенных "кое как", но с соблюдением MAX_DELAY, получается ошибка по MIN_DELAY из-за образовавшихся "коротких и быстрых путей" !

 

 

А для XILINX как это написать?

 

 

 

Start NBR section for re-routing
Level 4, iteration 1
0(0.00%) conflict; 0(0.00%) untouched conn; 0 (nbr) score; 
Estimated worst slack/total negative slack: 0.886ns/0.000ns; real time: 3 mins 1 secs 

Start NBR section for post-routing

End NBR router with 0 unrouted connection

NBR Summary
-----------
 Number of unrouted connections : 0 (0.00%)
 Number of connections with timing violations : 0 (0.00%)
 Estimated worst slack : 0.886ns
 Timing score : 0
-----------
Notes: The timing info is calculated for SETUP only and all PAR_ADJs are ignored.

Par hold correction will be run with extra effort. 

Hold time optimization iteration 0:
There are 91 hold time violations, the optimization is running ...
End of iteration 0
43027 successful; 0 unrouted;  real time: 3 mins 28 secs 

Hold time optimization iteration 1:
There are 3 hold time violations, the optimization is running ...
Starting iterative routing.
End of iteration 1
43027 successful; 0 unrouted;  real time: 3 mins 36 secs 

Hold time optimization iteration 2:
There are 3 hold time violations, the optimization is running ...
End of iteration 2
43027 successful; 0 unrouted;  real time: 3 mins 44 secs 

Hold time optimization iteration 3:
All hold time violations have been successfully corrected in speed grade M

Total CPU time 4 mins 7 secs 
Total REAL time: 4 mins 17 secs 
Completely routed.
End of route.  43027 routed (100.00%); 0 unrouted.
Checking DRC ... 
No errors found.

Hold time timing score: 0, hold timing errors: 0

Timing score: 0 

[Golikov 0]

что то как то муторно написано, не VALID ли мне нужен?

 

OFFSET = OUT 15 ns VALID 20 ns AFTER "spi_clk" RISING

 

не будет ли это что сигнал должен появиться не позже чем через 15 наносекунд, и удерживаться не меньше 20 наносекунд? Но тут тоже непонятно он же может перекрытся или его не хватит...

что-то я не могу в документации найти описание VALID для OFFSET OUT, или под валидом именно в этом случае понимается время удержания от клока до смены?

 

Есть у кого какие сведения?

 

UDP.

даже наверное вот так

 

OFFSET = OUT 8 ns VALID 16 ns BEFORE "spi_clk" RISING

 

за 8 наносекунд до клока стать валидными и держаться 16 наносек, то есть данные валидны и постоянны +- 8 наносек вокруг клока, я прав?

 

[SM 0]

что то как то муторно написано, не VALID ли мне нужен?

 

OFFSET = OUT 15 ns VALID 20 ns AFTER "spi_clk" RISING

 

Он самый. Но он по документации есть только у IN, а у OUT - нету. Так что, увы...

 

а перекрыться не может, подразумевается, что задается жесткое окно, где сигнал обязан быть стабилен, от и до. А что до и после, и как они там сдвинутся, никого не волнует уже. То есть констрейн означает, что сигнал должен быть устойчив в течение 20 нс после 15 нс от фронта. Но, повторюсь, согласно документации для OUT нельзя задать VALID, а только AFTER/BEFORE.