SM 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба Кто поможет? Как обозначить чтобы данные менялись не раньше чем через заданное время после фронта? в формате SDC: set_output_delay -clock clock_name -min MIN_DELAY -max MAX_DELAY а так, OFFSET OUT AFTER (не позже, чем, т.е. setup)/BEFORE (не раньше, чем, т.е. HOLD) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба OFFSET OUT AFTER (не позже, чем, т.е. setup)/BEFORE (не раньше, чем, т.е. HOLD) чет я не так трактую мануал, но вроде AFTER - это данные долнжны стать валидными не позже указанного времени после клока а BEFORE, данные должны быть валидными не позже чем за указанное время до клока а вот что данные могут меняться не РАНЬШЕ чем за указанное время ПОСЛЕ клока, вот такого чего - то нет... или я не правильно трактую мануал? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
olegras 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба По какой - то причине то ли передача то ли прием сдвигается на 1 бит, причем в моделсиме все четко, а в железе кирдык. Может поможет... Помнится у меня была точно такая же проблема. Камень был Spartan-3E, SPI слейв, SCK был заведен на неклоковый вход, данные почемуто сдвигались на 1 бит, в симуляторе было все ОК. Долго мучался с этими констрейнами. Пока не вывалил все сигналы в чипскоп. Оказалось что последовательность сигналов SPI, которые я формировал в симуляторе отличается от последовательности, которые выдает МК. Точнее - их начало, когда CS опускается в ноль. Проблема решилась настройкой SPI на стороне МК (у него было несколько режимов SPI) и подправкой кода ПЛИС. После этого все констрейны удалил, кроме CLOCK_DEDICATED_ROUTE = FALSE; Правда SPI на МК был не очень шустрый - кажется порядка 20 МГц. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
o_khavin 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба Мне кажется потенциально опасное решение. В начале работы на холодном кристале все пойдет по одному пути, потом он прогреется и...? В процессе работы "путь" поменяться не может. :) Зависимость от температуры есть, но не в весь диапазон. Основной вклад даёт разброс параметров разных чипов. С этим калибровка и борется. Кстати, аналогичный механизм используется в коре Xilinx-а по работе с DDR-памятью - производится калибровка и подстройка задержки DQ относительно DQS. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба В процессе работы "путь" поменяться не может. :) Зависимость от температуры есть, но не в весь диапазон. Основной вклад даёт разброс параметров разных чипов. С этим калибровка и борется. Кстати, аналогичный механизм используется в коре Xilinx-а по работе с DDR-памятью - производится калибровка и подстройка задержки DQ относительно DQS. при проверке констраинов 2 пути коротки и длинный коротки с запасом укладывается, длинны не укладывается. НА реальной железке если по 1 слову читать почти всегда все хорошо, если группу слов то временами вылазят ошибки. я трактовал что коротки и длинный путь это как бы граничные условия, реальная работа где-то по середине. Пока хочется избежать калибровки, потому что внутренне мне она кажется страшной%) Может поможет... Помнится у меня была точно такая же проблема. Камень был Spartan-3E, SPI слейв, SCK был заведен на неклоковый вход, данные почемуто сдвигались на 1 бит, в симуляторе было все ОК. Правда SPI на МК был не очень шустрый - кажется порядка 20 МГц. Спасибо за ответ, на 25 МГц все работает, проблемы на 50 МГц. И их причина обнаружена, данные не успевают выставляться, даже тут уже есть несколько решений проблемы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба а вот что данные могут меняться не РАНЬШЕ чем за указанное время ПОСЛЕ клока, вот такого чего - то нет... или я не правильно трактую мануал? BEFORE на, например, -2 нс (либо на период клока - 2 нс), будет говорить о том, что данные должны удерживаться после фронта, не менее, чем 2нс (hold time), то есть меняться не раньше, чем. Ну, по крайней мере, так должно быть, раз документация говорит, что BEFORE предназначено для анализа HOLD таймингов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба :) теперь бы еще узнать как это делается. Я совсем совсем не силен в констрейнах.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
olegras 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба проблемы на 50 МГц. И их причина обнаружена, данные не успевают выставляться ... SPI был настроен в такой режим. Выставление данных - по заднему фронту SCK. CS - на асинхронных ресетах клоковых процессов. Думаю, что и на 50 МГц должно работать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба :) теперь бы еще узнать как это делается. Я совсем совсем не силен в констрейнах.... А Вы почитайте подробный отчет анализа SETUP-ов и HOLD-ов - там должно быть написано, что он там с чем суммировал в каком анализе, что получилось, и какой запас (или нарушение) - проанализируйте это, и придет ясность, как правильно обконстрейнить. К сожалению, повторю, я с ксилинкс дела не имел, поэтому гарантировано точно не могу подсказать, как правильно описать HOLD (удержание старых данных после клока, не менее, чем на сколько то) - я говорю по аналогии с другими средами разработки. Но "анализ отчета анализатора", подробного отчета, должен по идее все расставить по своим местам. ---------------------- UPD: Хмммм.... Пожалуй, я был неправ... Поверхностное чтение документации на констрейны xilinx показывает, что там нет возможности обконстрейнить HOLD для выходов (для входов однако есть - OFFSET IN ... VALID ....), есть только возможность его узнать, какое оно получилось, анализом минимального времени. И у самого есть вопрос к знатокам хилых - что, внатуре нет? Странно все это... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dr.Alex 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба Странно все это... А каким образом вообще можно управлять минимальным холдом выхода? Он что, задержки там будет вставлять? Да и кажется всем микрухам сейчас достаточен нулевой холд по входам, тогда как у любого вЫхода он больше нуля, так шта и непонятно зачем его констрейнить снизу.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба ну задержки есть, то есть хотелось бы чтобы он проанализировал путь, и если он короче чем заданное время воткнул задержку, А если больше не трогал. Угнетает что на SPI проца нет никакой спецификации. Вот он захватывает данные по восходящему фронту, но нет никаких данных сколько они должны стоять до, и сколько после клока. И если косвенно "сколько до" можно прикинуть, данные должны выставлять по падающему клоку, то сколько они должны удерживаться - не понятно... Варианты использования такой задержки масса. К примеру задав ее пол периода я могу по восходящему фронту ставить данные не раньше падающего, то есть вообще выполнить требования. А без такой задержки я боюсь иметь теоретическую возможность снять данные до их захвата процом. Реально это наверное невозможно, так как путь распространения сигнала до регистра и обратно все же не нулевой, и если я вижу фронт, то на проце он был заведомо раньше, но для очистки совести хотелось бы держать это время под контролем. Вот кстати сейчас думаю воткнуть ДДР на входе и выходе которые есть у спартана 6, это позволит анализировать фронты входящего сигнала с точностью +- 5 нСек, а вот что мне для выхода даст пока не очень понимаю, но чувствуется что тоже что-то даст... почему мне не дают по 2 фронтам блин работать... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dr.Alex 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба Угнетает что на SPI проца нет никакой спецификации. Могу вам гарантировать что минимальный холд по входу у него 0. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба А каким образом вообще можно управлять минимальным холдом выхода? Он что, задержки там будет вставлять? Латис, как и альтера, например, после разводки, когда все 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 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба что то как то муторно написано, не 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 7 января, 2014 Опубликовано 7 января, 2014 · Жалоба что то как то муторно написано, не VALID ли мне нужен? OFFSET = OUT 15 ns VALID 20 ns AFTER "spi_clk" RISING Он самый. Но он по документации есть только у IN, а у OUT - нету. Так что, увы... а перекрыться не может, подразумевается, что задается жесткое окно, где сигнал обязан быть стабилен, от и до. А что до и после, и как они там сдвинутся, никого не волнует уже. То есть констрейн означает, что сигнал должен быть устойчив в течение 20 нс после 15 нс от фронта. Но, повторюсь, согласно документации для OUT нельзя задать VALID, а только AFTER/BEFORE. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться