[Yuri124 1]

35 minutes ago, en-valb said:

TimeQuest до этого брал в качестве Launch clk0 а в качестве Latch clk1 и это было верно?

TimeQuest считает временные соотношения между сигналами при передаче данных reg1  -> reg2.

Соответственно, launch  - тот клок, по которому данные записываются в reg1, а latch - по которому записываются в reg2.

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

[en-valb 0]

19 minutes ago, Yuri124 said:

55 minutes ago, en-valb said:

TimeQuest до этого брал в качестве Launch clk0 а в качестве Latch clk1 и это было верно?

TimeQuest считает временные соотношения между сигналами при передаче данных reg1  -> reg2.

Соответственно, launch  - тот клок, по которому данные записываются в reg1, а latch - по которому записываются в reg2.

В моем случае reg1 это выходной регистр контроллера SDRAM, а reg2 это входной регистр во внешней микросхеме памяти, я правильно понял?

[Yuri124 1]

1 minute ago, en-valb said:

reg2 это входной регистр во внешней микросхеме памяти, я правильно понял?

думаю - нет, т.к. Квартус совсем не знает о том, что находится за пределами кристалла FPGA.

reg1 и reg2 - это я образно обозвал источник и приемник данных.

Чтобы память смогла принять-выдать информацию FPGA, нужно соблюсти на выводах FPGA временные соотношения между данными и клоком (с учетом времени передвижения по pcb) - это в даташите на микросхему памяти + разводка платы.

Эти соотношения нужно прописать в проекте. Для того, чтобы Квартус при компиляции проекта постарался их выполнить, а потом - Timq Quest проверит выполнение.

 

[en-valb 0]

Убрал из sdc set_clock_groups. Скомпилировал.

 

Для анализа выбрал первый слак SDRAM_WE. Во вложении диаграмма слака из TimeQuest. 

 

На вкладке Data Path с Data Arrival Path разобрался у Дениса это хорошо расписано, но вот с Data Required Path темный лес могу предположить что -5,134 это задержка клока Latch (clk1), и она все портит, т.е. мне необходимо поставить Latch слева от слака, левее Output Delay?

 

SDRAM_WE.bmp

Изменено 23 апреля, 2019 пользователем en-valb

[en-valb 0]

1 hour ago, en-valb said:

т.е. мне необходимо поставить Latch слева от слака, левее Output Delay?

Сработало, в PLL на clk1 изменил сдвиг фазы вместо -60 deg поставил +30 deg (0,833 нс) перекомпилировал слаки исчезли!!! Буду дальше разбираться с set_input_delay и set_output_delay

[en-valb 0]

Обконстрейнил все, что можно, появились вопросы:

1. Что делать с tdi, tms и tdo? 

2. Что делать с SDRAM_CLK это ведь по сути clk1 в проекте, может сгенерировать клок SDRAM_CLK из clk1  с помощью create_generated_clock и переписать все констрейны set_input_delay и set_output_delay заменив {inst|altpll|sd1|pll7|clk[1]} на SDRAM_CLK?

 

 

3. Еще он пишет, что необконстрейнин один клок.

Но ведь это же не клок, на просторах интернета есть где то информация, что это quartus ошибается и в следующих версиях Quartus баг будет исправлен. Что с ним делать сейчас, погасить через set_false_path или как то по другому????

 

[Yuri124 1]

19 hours ago, en-valb said:

с Data Required Path темный лес

Вот тоже - долго думал над Вашей диаграммой. Физический смысл этого раздела понятен, но  минусовые числа в столбце Incr (Инкремент) - непонятны. Или это из-за какой-то ошибки в sdc - выглядит так, как будто идет путь не "вперед" от точки возникновения клока, а "назад"...

 

21 minutes ago, en-valb said:

Что делать с tdi, tms и tdo?

Это - jtag? - забить пока. Там частоты сильно меньше, да и понизить их в прошивальщике можно. Или прописать частоту tck.

23 minutes ago, en-valb said:

Что делать с SDRAM_CLK это ведь по сути clk1 в проекте, может сгенерировать клок SDRAM_CLK из clk1  с помощью create_generated_clock и переписать все констрейны set_input_delay и set_output_delay заменив {inst|altpll|sd1|pll7|clk[1]} на SDRAM_CLK?

Я думаю - так было бы правильно (ведь для внешней памяти важны временные соотношения сигналов управления и данных относительно ее (памяти) синхросигнала.

clk1 - это выход клока из блока PLL на его выходе, я правильно понял?

[en-valb 0]

 

18 minutes ago, Yuri124 said:

clk1 - это выход клока из блока PLL на его выходе, я правильно понял?

Да, правильно. 

[en-valb 0]

Забыл обновленный sdc вложить.

test_sdram.out.sdc

 

В нем пока нет create_generated_clock для SDRAM_CLK

Изменено 24 апреля, 2019 пользователем en-valb

[en-valb 0]

После того как я попытался добавить в sdc create_generated_clock для SDRAM_CLK, TimeQuest высыпал слаками. Судя по диаграмме когда я передвинул Latch на +30 deg (0,833 нс) это было не правильно, странно конечно, что я не увидел слаков тогда. 

Снова слаки.bmp

[en-valb 0]

 

3 hours ago, Yuri124 said:

23 hours ago, en-valb said:

с Data Required Path темный лес

Вот тоже - долго думал над Вашей диаграммой. Физический смысл этого раздела понятен, но  минусовые числа в столбце Incr (Инкремент) - непонятны. Или это из-за какой-то ошибки в sdc - выглядит так, как будто идет путь не "вперед" от точки возникновения клока, а "назад"...

 

 

Да я думаю, что он анализирует предыдущие данные, а Latch берет текущий.

 

 

[Yuri124 1]

30 minutes ago, en-valb said:

Судя по диаграмме когда я передвинул Latch на +30 deg (0,833 нс) это было не правильно, странно конечно, что я не увидел слаков тогда. 

Вполне может быть, что анализатор посчитал Latch Edge через такт, те с дополнительной задержкой 10 нс, ибо - красное невозможно было бы не заметить.

Понятно, что никакой Latch Edge, сдвинутый на 800 пикосекунд от Launch не сможет защелкнуть

Думаю, можно подсказать, какой действительно фронт нужно брать для анализа - через set_multicycle... Или покрутить фазу.

Но вначале - убедиться - что клок для памяти и сдвиги сигналов относительно него описаны правильно.

 

У Дениса Шехалева был пример, когда Квартус неправильно посчитал пути задержек клоков, и слэков не было, а когда поправили файл sdc (т.е. когда пути клоков стали считаться правильно)- они появились.

 

[en-valb 0]

30 minutes ago, Yuri124 said:

Думаю, можно подсказать, какой действительно фронт нужно брать для анализа - через set_multicycle... Или покрутить фазу.

set_multicycle_path -end -from {get_clocks {inst|altpll|sd1|pll7|clk[0]}} -to {get_clocks {inst|altpll|sd1|pll7|clk[1]}} -setup 2

[en-valb 0]

Добавил set_multicycle_path слаки уменьшились, наихудшее значение стало -0,557 нс, добавил сдвиг фазы еще на 22,5 deg и того получилось +52,5 deg. Откомпилировал получил слаки -1,542 нс, увеличил сдвиг фазы до +108 deg слаки исчезли полностью, но запас по SDRAM_BA[0] маловат будет, попробую подвинуть еще немного.

clk1 +108 deg.bmp

BA[0].bmp

[en-valb 0]

Но мне кажется, что здесь, что то не то? Он должен анализировать от первого Latch`a в право, а он от второго в лево. От второго понятно почему, но почему он все время в лево.  Как ему сказать что бы брал от Latch`a Data Required с права а не слева. Т.е. у меня Data Required запаздывает почти на такт, и я его сдвигом фазы пододвинул больше чем на такт, таким образом избавился от слаков, но какой то способ странный мне кажется.