[zombi 0]

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

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

Подскажите вот такой момент :

Вот два режима поступающих на плис данных. Вверху SDR, внизу DDR.

CLK одинаковая, данные поступают на одни и те же пины.

Смотрим только на нарастающий фронт клока (отметил синим кружочком).

По этому фронту данные фиксируются в одних и тех-же регистрах.

SDC требует указать величину -max (интервал отметил красным)

Но на самом деле интервал должен быть в обоих случаях примерно одинаковый (отметил зелёным).

Видно что зелёные интервалы примерно одинаковые, а красные практически в два раза отличаются.

Почему так? Где я чего напутал?

[Yuri124 1]

28 minutes ago, alexadmin said:

Картинка в цитируемом посте выше

Да, картинка (верхний тайминг) - как раз Ваш случай, когда следующий защелкиваюший переход клока (фронт или спад) располагается внутри окна валидных данных.

tsetup считается относительно следующего фронта клока (относительно latching edge), а thold - относительно launching edge.

Поэтому если в верхней строке этой цитаты слово previous не забыть распространить на оставшиеся строки - то всё норм.

Quote

 

min is the value from the launching clock edge to the (previous) data valid ending.

If the data valid ending is earlier than the launching clock edge, min is positive.

If the data valid ending is later than the launching clock edge, min is negative

 

 

[zombi 0]

23 minutes ago, zombi said:

Подскажите вот такой момент :

Агаааа, кажется я понял в чем дело.

Скорее всего при описании отрицательного фронта обязательно придётся добавить параметр -add_delay и это увеличит ранее определённый -max для положительного фронта.

Подскажите, так ли это?

[Yuri124 1]

9 minutes ago, zombi said:

Подскажите, так ли это?

Quote

 

-add_delay

Create additional delay constraint instead of overriding previous constraints

 

 

22 minutes ago, zombi said:

Где я чего напутал?

Как по мне - всё правильно в обеих картинках.

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

Ну - просто формальное определение окна валидности данных относительно фронта/спада клока из-за отсутствия более понятной "человеческой"  команды, как я понимаю.

На самом деле (физически) текущие данные защелкиваются текущим фронтом клока, но программе нужно указать (из-за особенности ее расчета) - как будто данные появляются в результате выборки предыдущим фронтом.

[des00 25]

On 4/13/2021 at 8:30 PM, zombi said:

Есть внешняя мс подключенная к плис.

а можно название этой чудо микросхемы, которая при тактовой 12МГц имеет вот такое окно валидости?

Quote

 2) окно для захвата данных всего +-5 нс . Т.е. шириной всего 10 нс. А тактовая 150 МГц - период целых почти 7 нс.

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

ЗЫ. просмотрел тему, предположение о таком узком окне возникло само собой и мне кажется, что оно необоснованно. Т.к. в таком случае

Quote

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

Проект работает, но чувство того что чего-то не хватает меня не покидает.

вот это было бы под большим сомнением.

[Yuri124 1]

15 hours ago, zombi said:

Где я чего напутал?

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

Для того случая, когда у Вас регистр защелкивается только по фронту - т.е. режим SDR - надо писать констрейны, как Вы и предполагали - т.е. их привязывать только к фронту импульса, а не так, как в источнике от Xilinx, который нам любезно предоставили выше. Ведь он для режима DDR - когда например по фронту клока на шине появляются данные, которые будут защелкиваться спадом этого же клока.

 

2 hours ago, des00 said:

вот это было бы под большим сомнением.

Ну почему же - для setup и для hold предоставляется по целых 5 нс, и вполне могло оказаться, что при любой разводке Квартус сам того не ожидая вписывается в это окно валидности данных.

Тем более, что Квартус считает по наихудшим данным, и в даташите на микросхему тоже наверняка указаны наихудшие параметры. Т.е. фактически окно могло быть не +-5 нс, а шире, и рассчитанные Квартусом слаки - тоже меньше реальных.

Изменено 15 апреля, 2021 пользователем Yuri124

[zombi 0]

Окно валидных данных на стороне источника шире и намного шире.

Всё дело в том что два устройства могут соединяться кабелем.

Требование обеспечить на приёмной стороне +-5нс именно этим и обусловлено.

 

[Yuri124 1]

On 4/13/2021 at 8:22 PM, zombi said:

Подскажите, на этой картинке все верно нарисовано и записано?

Еще раз обдумал эту картинку - да, всё верно. Валидные данные нарисованы непривычно, это сбивало меня с толку.

Launch clock вычитывает данные на шину данных - самое позднее через max  нс и самое раннее - через min нс. Считается, что эти данные существуют до следующего фронта - т.е. когда приходит фронт latch clock, то относительно него данные уже были валидны в течение времени T-tmax и после этого же фронта  latch clock они будут сохраняться еще в течение времени tmin.

В Вашей задаче launch clock -  на выводе микросхемы источника данных, а  latch clock - на входе ПЛИС. Если время задержки для клока и для всех данных одинаково, то задержки взаимно обнуляются, и можно считать, что  launch clock и latch clock  - один и тот же.

НО! Вы писали, что длины проводников выровнены. Это само еще не гарантирует, что задержки тоже выровнены. См формулу (1) в   https://www.terraelectronica.ru/news/5275

Т.е. расположение дорожек в разных слоях, наличие переходных отверстий, а также разное расположение опорного земляного слоя приводит к разной скорости распространения сигналов и разным задержкам.

Даже расположение дорожки параллельно плетению стеклотекстолита может повлиять на величину задержки - т.к. один проводник будет располагаться там, где больше стекла , а другой - где больше смолы, заполняющей промежутки между слоями стекла. [но это уже больше для гигагерцового диапазона имеет существенное значение ИМХО].

Посмотрите, какие у Вас запасы по setup и hold (слаки) - и для бОльшего спокойствия можно ужесточить окно валидности данных - увеличить max и уменьшить min на какую-то разумную величину, если дорожки располагаются в разных слоях или имеют разное количество переходных отверстий.

 

 

[des00 25]

27 minutes ago, zombi said:

Окно валидных данных шире и намного шире.

Всё дело в том что два устройства могут соединяться кабелем.

Требование обеспечить приёмной стороне +-5нс именно этим и обусловлено.

 

кабель у вас что, без связи по постоянке?  микросхему назовите.

[zombi 0]

4 minutes ago, des00 said:

микросхему назовите.

Что угодно с ATA интерфейсом.

[des00 25]

48 minutes ago, Yuri124 said:

Ну почему же - для setup и для hold предоставляется по целых 5 нс, и вполне могло оказаться, что при любой разводке Квартус сам того не ожидая вписывается в это окно валидности данных.

Тем более, что Квартус считает по наихудшим данным, и в даташите на микросхему тоже наверняка указаны наихудшие параметры. Т.е. фактически окно могло быть не +-5 нс, а шире, и рассчитанные Квартусом слаки - тоже меньше реальных.

угу, а если tsu/th +-1нс, то, руководствуясь используемым принципом для рассчета окна валидности, она составит 2нс, а есть чипы где tsu/th +-0.1нс. попробуй попади))) вот тут логика здравого смысла уже должна дать сбой.

tsu/th это входные параметры триггера устройства-приемника данных. а в даташите, должны быть прописаны выходные параметры триггера устройства-источника данных. А это tco_min, tco_max. Все эти параметры, в синхронной схеме связаны между собой. tco_max/tsu влияет на tsu setup slack, tco_min/th на th hold slack. Действительно есть чипы, где данные не держутся весь период тактовой частоты интерфейса и там действительно  нужно успевать укладываться в окно. Но, что-то мне подсказывает, что это не тот случай.

[Yuri124 1]

32 minutes ago, zombi said:

два устройства могут соединяться кабелем

Длина кабеля? Согласование обеспечивается или нет? Если нет - то действительно, пока на длинном кабеле сигналы устаканятся, то может остаться малое окно для их захвата. 

[des00 25]

Just now, zombi said:

Что угодно с ATA интерфейсом.

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

[Yuri124 1]

4 minutes ago, des00 said:

угу, а если tsu/th +-1нс, то, руководствуясь используемым принципом для рассчета окна валидности, она составит 2нс, а есть чипы где tsu/th +-0.1нс. попробуй попади))) вот тут логика здравого смысла уже должна дать сбой.

tsu/th это входные параметры триггера устройства-приемника данных. а в даташите, должны быть прописаны выходные параметры триггера устройства-источника данных. А это tco_min, tco_max. Все эти параметры, в синхронной схеме связаны между собой. tco_max влияет на tsu, tco_min на th. Действительно есть чипы, где данные не держутся весь период тактовой частоты интерфейса и там действительно  нужно успевать укладываться в окно

Спасибо!

Но если источник сигнала медленный (т.е. большие величины  tco_min, tco_max), а приемник быстрый - [есть чипы где tsu/th +-0.1нс], то как мне кажется, в этом случае окно +-5 нс будет меньше сужаться и в него попасть легче, чем с чипом гле +-1нс.

[zombi 0]

6 minutes ago, Yuri124 said:

Длина кабеля? Согласование обеспечивается или нет?

А помнит кто-то еще винчестеры и другие устройства с ATA интерфейсом и 40 жильным кабелем?