Quote:
Originally Posted by aniSKY
(Post 324522)
ну наконец то добился толку от своего нагромождения кода :D
|
"Нагромождение" -- это очень удачное слово. Честно говорю, эта задача решается проще ;)
Просто, как я понимаю, ты раньше работал исключительно со схемным вводом, а VHDL только начал учить? Код уж больно характерно выглядит.
Quote:
Originally Posted by aniSKY
(Post 324522)
привязял к клоку - от этого и шел косяк, стоило убрать привязку - ка все бульк и в порядке :eek:
|
Хм. Вообще говоря, если ты что-то исправил, и оно
почему-то заработало, это не значит, что ты исправил ошибку. С вероятностью не менее 50% ты просто её замаскировал, и она вылезет когда-нибудь потом. Симуляцией пользуешься хоть?
Quote:
Originally Posted by aniSKY
(Post 324522)
то что получилось в прицепе (мот кто глянет если не лень будет, подскажет что где подправить чтоб правильно и грамотно было :v2_blush:)
|
Приступим. Для начала, тебе следовало бы посмотреть в отчёт квартуса. Он там синим по белому пишет вот такое:
Quote:
Warning: Can't achieve minimum setup and hold requirement CLK25 along 32 path(s). See Report window for details.
|
То есть, попадание в желаемые времянки квартусу не удалось (а если не задавать максимальную тактовую частоту, то квартус выдаёт красным предупреждение про clock/data skew, что более правильно, как мы увидим позже; почему он его не выдаёт при заданной частоте -- хз, это косяк).
На такое сообщение надо реагировать, как бык на красную тряпку: работоспособность схемы не гарантируется !!! То есть надо бросать все, и разбираться, почему.
Разбираемся: лезем в Report Window и открываем в нём вкладку Timing Analyzer. Сразу видим, что там выделены красным строки
Summary и
Clock Hold:' CLK25'. Ну, общая сводка на то и общая, что в ней деталей нету, поэтому открываем вторую, про CLK25. Видим список цепей, красным выделены те, по которым есть нарушение времянок. У меня они начинаются с hcnt[2]->PIXd0[1], что уже само по себе подозрительно (ладно, когда сигналы данных попадают в нарушения по Clock Setup, это просто схема тормозная получилась, но Clock Hold? :v2_dizzy_fear: Это явный признак гонки сигналов :v2_scare:).
Что же, тыкаем правой кнопкой мыши в первую строку, и выбираем Locate->Locate in RTL viewer. Видим то, что в аттаче, и ужасаемся.
Со счётчика hcnt сигналы идут одновременно на тактовый вход триггеров PIXd0, и на вход разрешения записи, через логику! При этом получается, что прибывают они в недопустимом порядке, сначала клок напрямую, а потом сигнал разрешения записи через логику. Таким образом, разрешение записи прибывает на один период hclk[0] позже, чем подразумевалось в VHDL коде, и схема работает только потому, что там есть очень большой запас по времени защёлкивания VD в PIXd0, да и само разрешение записи висит целый период hclk[0]. Стоит уплотнить временную диаграмму доступа в память, и полезут ошибки, странные и непонятные.
О лечении. На самом деле, проще и лучше всего отказаться от использования множественных клоков. FPGA и их компиляторы разработаны для того, чтобы запихивать в них преимущественно синхронную логику. Если планируется делать логику асинхронную (а наличие более одного клока -- это уже асинхронная логика), то с гонками и метастабильностью придётся бороться вручную. Тебе это надо?
Кроме того, в твоей FPGA всего 8 линий для тактовых сигналов, из которых твой код уже использует 5. Как только при расширении проекта потребуется девятый клок, то он пойдёт не по специальной выделенной цепи с выровненным временем доставки, а по обычным проводам (точнее, по ним пойдёт клок с наименьшим количеством триггеров). Что опять же приведёт к гонкам сигналов и глюкам.
Не, в такой простой схеме лучше сделать один клок.
PS: Если ты действительно переходишь со схематика, то Tools->Netlist Viewers->RTL Viewer тебе очень поможет. Сразу видно, какую схему квартус соорудил из твоего кода.
PPS: Прошу не обижаться на тон ;) Просто это действительно базовые вещи при работе с полностью синхронными схемами. А FPGA -- именно такие.
