Jump to content
    

Правки задержек сигналов

В 03.04.2024 в 20:18, sazh сказал:

Это китаец вряд ли потянет. Надо смотреть что его pll может. И можно ли камеру на него сажать.

В других темах обсуждали.

 

Если верить даташиту то до 1200 можно.

image.png.6fb79fb4a022b6765f2ecf565dfdf522.png

Share this post


Link to post
Share on other sites

1200 мне кажется только для сериализатора/десериализатора в MIPI (схема которая превращает паралельные данные в последовательные для передачи по LVDS) а не для всей схемы Если прочитать примечание то частота для данных 1200/8=150 

600 тоже довольно высокая частота - проверьте точно необходима?

Share this post


Link to post
Share on other sites

В 04.04.2024 в 09:38, Maverick_ сказал:

Если прочитать примечание

Это частота байт. 

Камера имеет разрешение 560*560 и частоту кадров 360 fps. в формате 10бит на пиксель.

560 * 560 * 10 = 3 136 000 бит на кадр.

 3 136 000 * 360 = 1 128 960 000 бит в секунду.

Есть 2 line:

1 128 960 000 / 2 = 564 480 000 бит в секунду на line.

До есть приходить на вход IP MIPI будут последовательные данные с частотой 564 480 000 бит в секунду.

После десериализации получаем 70 560 000 байт в секунду.

Но это немного не по теме. Это в темах по мипи обсуждалось.

Тут то сейчас вопрос как линии поправить чтобы не было варнингов в ИДЕ. Пока сделал по такому совету.

В 03.04.2024 в 17:51, Freibier сказал:

объявить частоты эксклюзивными, и тогда все обмены данными между клоковыми доменами на совести разработчика.

Вроде бы проблемы ушли но осталась проблемка с HOLD

image.thumb.png.13c96b4e3d8ca1df24c805438bee57c1.png

 

Что это значит также не очень понятно.

Share this post


Link to post
Share on other sites

Это значит, что у вас Hold нарушается. Загуглите, что такое Hold
Причем пути не CDC, т.е. внутри одного клокового домена. Что очень плохо.
Чтобы понять причину, надо для начала посмотреть в колонку clock skew в репорте (на скриншоте отсутствует). Если Clock skew большой, проблема с деревом клока - сильный перекос; если же маленький, то надо делать репорты по указанным путям по Setup: если запас по Setup отсутствует (slack маленький), то надо понижать частоту; если большой, то по каким то причинам тул не хочет вставлять баферы задержки.
Так же есть вероятность что эти пути тоже асинхронные (даже если клок один и тот же - так иногда делают), читайте документацию на айпи. Но на вскидку, не похоже. Похоже на обычный счетчик, в котором просто нарушен холд.

Share this post


Link to post
Share on other sites

В 04.04.2024 в 11:11, Yaahoo сказал:

Это значит, что у вас Hold нарушается. Загуглите, что такое Hold

А можете подсказать на конкретном примере?

Вот есть кусок кода:

 

Ко команде с компа я включаю светодиод и выключаю.

image.thumb.png.a2ef774cecdb8a7c748175465a7b4707.png

 

Что можно сделать чтобы устранить ошибку именно тут?

В 04.04.2024 в 11:11, Yaahoo сказал:

Похоже на обычный счетчик, в котором просто нарушен холд.

Именно счетчик и есть. И что нужно сделать в коде чтобы поправить холд?

Share this post


Link to post
Share on other sites

Судя по всему у вас проблема не одна, а целая куча, поэтому не стоит их сваливать вместе, а лучше решать по очереди, отдельно.

По репорту из предпоследнего поста - я уже ответил. Регистра с нарушением (byte_cnt) в приведенном коде нет. И по прежнему не ясно что там с clock_skew

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

Share this post


Link to post
Share on other sites

В 04.04.2024 в 12:00, Yaahoo сказал:

поэтому не стоит их сваливать вместе, а лучше решать по очереди, отдельно.

поэтому я и прошу подсказать как решить конкретную задачку причем на самых простых процессах которые не завязаны нигде в коде. И имеют всего 2 разных тактирования.

В 04.04.2024 в 12:00, Yaahoo сказал:

Если клоки асинхронные - нужно описать их соотв.

Как и где? Если вы про констрейны то там эти клоки описаны.

 

В 04.04.2024 в 12:00, Yaahoo сказал:

Регистра с нарушением (byte_cnt) в приведенном коде нет.

Как уже писалось выше это простой счетчик. Код в приложении потому что там очень уж много всего. Код может и дикий но он отлажен и работает. и это i2c и огромных скоростей там не требуется. 

I2C.vhd

Share this post


Link to post
Share on other sites

8 часов назад, Worldmaster сказал:

 

Есть 2 line:

1 128 960 000 / 2 = 564 480 000 бит в секунду на line.

До есть приходить на вход IP MIPI будут последовательные данные с частотой 564 480 000 бит в секунду.

После десериализации получаем 70 560 000 байт в секунду.

 

я на констрейны грешил. входной клок 282.24 MHz. После десериализации получаем 70 560 000 байт в секунду на каждую линию.

Share this post


Link to post
Share on other sites

В 04.04.2024 в 19:00, sazh сказал:

я на констрейны грешил. входной клок 282.24 MHz. После десериализации получаем 70 560 000 байт в секунду на каждую линию.

Я не понял. Можно более внятно разъяснить в чём я не прав?

Share this post


Link to post
Share on other sites

10 часов назад, Worldmaster сказал:

Я не понял. Можно более внятно разъяснить в чём я не прав?

560х560х360  пиксельная частота 112.896 МНz, x10 = 1.12896Gbps,

564 на линию, данные сопровождаются клоком по обоим фронтам, 282.24 MHz.

На выходе корки clkbyteout 282.24делить на 4, 

70.56 MHz x16 = 1.12896

А дальше корка должна быть, которая из этого снова 10 битовый пиксель сделает. И работать она будет на частоте 140МНz.

Ваш говин поддержиаает 1:16 mode?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...