[Digi 0]

А по какому принципу нужно объединять клоки в группы ?

[Digi 0]

Неужели никто не занимается описанием input delay ? Или мои вопросы слишком сложные ?

 

[Yuri124 1]

On 7/9/2021 at 9:51 AM, Digi said:

по какому принципу нужно объединять клоки в группы ?

ИМХО - по разумению (логика). Предположим - имеете несколько клоков, каждый тактирует свое оборудование, обрабатываемые/пересылаемые данные нигде не пересекаются и между клоковыми доменами не передаются. Логично объявить эти клоки независимыми, даже если они синхронны - чтобы облегчить компилятору задачу по разводке.

И прямо противоположный пример - имеем несколько клоков, физически - из разных источников (несинхронные), но блоки, ими тактируемые, обмениваются данными. В этом случае приходится объявлять эти клоки независимыми, при этом предусмотрев механизм корректной передачи данных при пересечении клоковых доменов.

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

Как-то так...

[Digi 0]

Вот например, как быть в таком случае ? 

Все частоты одинаковы, за исключением A_CLK.  Изначально добавлял в одну группу {A_FRMCLK1 A_CLK1} в другую FRMCLKx, отдельно каждую из DDC_CLK* и отдельно OUT_CLK.  Возникала ситуация, что на выходе CDC не всегда защёлкивались верные данные. Так как Quartus некоторые биты утягивал совершенно в другую сторону кристалла, а так как между этими клоками не происходил анализ времянок, то и ошибок для него не было.  Если замешать все клоки в одну группу, то время компиляции возрастало до неразумных пределов, и времянки везде недотягивали до требуемых. Проект становился совершенно неработоспособным.

 

[RobFPGA 27]

Приветствую!

13 minutes ago, Digi said:

Вот например, как быть в таком случае ?
...
Возникала ситуация, что на выходе CDC не всегда защёлкивались верные данные. 

Если вы задали клоки асинхронными  и на выходе CDC получаете неправильные данные то это не CDC,  а какое то ... 

И асинхронность клоков тут ни при чем.  

 

Удачи! Rob.

[Yuri124 1]

17 minutes ago, Digi said:

в другую FRMCLKx, отдельно каждую из DDC_CLK* ...  Возникала ситуация, что на выходе CDC не всегда защёлкивались верные данные.

Т.е. - CDC и все DDC заявлены асинхронными , и компилятор не анализировал времянку между ними? 

Тогда - может быть, не на выходе CDC появлялся "брак", а во входных регистрах DDC  - из-за отсутствия анализа и попыток засинхронизировать потоки данных.

[Digi 0]

33 минуты назад, Yuri124 сказал:

Тогда - может быть, не на выходе CDC появлялся "брак", а во входных регистрах DDC  - из-за отсутствия анализа и попыток засинхронизировать потоки данных.

Да, скорее всего на входах, но суть это не меняет.  Анализ не проводится. Но при попытке увязать это всё в одну кучу, результат - невозможность вытянуть времянки

[RobFPGA 27]

Приветствую!

39 minutes ago, Yuri124 said:

Тогда - может быть, не на выходе CDC появлялся "брак", а во входных регистрах DDC  - из-за отсутствия анализа и попыток засинхронизировать потоки данных.

Это  как?  входной регистр CDC  работает синхронно во входном клок-домене. Получается что  для этого клока нет констрейнов?  Каким образом может быть отсутствие анализа для входного клока СDС из за асинхронности выходного клока? 

 

Удачи! Rob.    

[Yuri124 1]

11 minutes ago, Digi said:

при попытке увязать это всё в одну кучу, результат - невозможность вытянуть времянки

исходя из Вашей блок-схемы - клоки FRMCLKx и DDC -  должны быть синхронными. И тогда нужно их группировать - {FRMCLKx с DDC_CLK1} и {FRMCLKx c DDC_CLK2}. А не всё в одну кучу.

6 minutes ago, RobFPGA said:

Каким образом может быть отсутствие анализа для входного клока СDС из за асинхронности выходного клока?

Я предположил, что нет анализа между CDC и DDC, из-за чего не CDC выдает неправильно, а DDC принимает неправильно.

Изменено 20 июля, 2021 пользователем Yuri124

[RobFPGA 27]

Приветствую!

30 minutes ago, Yuri124 said:

Я предположил, что нет анализа между CDC и DDC, из-за чего не CDC выдает неправильно, а DDC принимает неправильно.

Да,  вы правы. Если  FRMCLKx и DDC_CLK*  объявили асинхронными  то контроля путей  между  CDC и DDC не будет. :(  

 

Удачи! Rob.

[Digi 0]

1 час назад, Yuri124 сказал:

И тогда нужно их группировать - {FRMCLKx с DDC_CLK1} и {FRMCLKx c DDC_CLK2}.

А вот так как раз и не получилось сгруппировать. Выдавал ошибку. Поэтому и задал вопрос. Так разве можно ? Если да, то ещё раз попробую сделать и  понять, что было не так. 

[Yuri124 1]

30 minutes ago, Digi said:

Так разве можно ?

сам так не пробовал - не было необходимости. Можно попробовать объединить в группу все три этих клока, думаю, компилятор сам не должен анализировать пути между DDC_CLK1 и DDC_CLK2, т.к. судя по блок-схеме пересылок данных между этими клоковыми доменами нет.

[Freibier 3]

02.07.2021 в 09:18, Digi сказал:

Структура такая: 

 

А если попробовать так :

[Digi 0]

На первом рисунке это что в в стандартной корке DDIO. А вот во втором случае возникнет проблема  синхронизацией полуслов. Потому что FRM это не просто делённые CLK.  Кажется так...