обробка часу на FPGA

Я новачок у fpgas, і є деякі тонкощі часу, які я не впевнений, я розумію: якщо всі мої синхронні процеси спрацьовують на одному краю, то це означає, що мої введення "захоплені" на одному зростаючому краю, а мій Виходи змінюються на .. той самий край? наступний піднімаючий край?

якщо у мене є два модулі, де вихід одного з них надходить на входи наступного, може виникнути ситуація, коли входи до мого модуля (виходи попереднього модуля) змінюються одночасно з їх захопленням.

Маркер на 205ns показує, про що я говорю, op та data_write, які є моїми вводами. У цьому тестовому випадку все, здається, "просто працює", але в моделюванні не зрозуміло, що саме потрапляє в полон. Чи дані_write = "0001 ..." фіксуються на 205ns або (205ns + 1 тактовий цикл)? Чи є спосіб отримати більш детальні форми сигналів в ISim, які показують час налаштування та час утримання?

Дякую.

Завжди є деяка затримка поширення через триггер. Його часто називають "затримкою до Q" затримкою.

Це означає, що ваші входи захоплені на межі, а виходи змінюються на тому самому краю, але лише через кілька наносекунд пізніше. Цього декількох затримок наносекунд достатньо (якщо ваші шльопанці розроблені з «нульовим часом утримування», як вони є в більшості FPGA), що зміни не впливають на жодні тригерні переходи до наступного краю годинника.

У функціональному або RTL-моделюванні (що, мабуть, ви робите для отримання результату), затримка не буде імітуватися як тривала наносекунда. У VHDL це буде єдиний дельта-цикл годинника тренажера, який технічно взагалі немає часу. Це робить неможливим побачити затримку на виході тренажера. Тим не менш, для імітованих як ідеальних шльопанців достатньо, щоб зміни на виході не впливали на шльопанці нижче за течією.

Якщо ви робите моделювання після місця та маршруту, воно повинно мати можливість включати відповідні затримки, щоб ви чітко бачили ці ефекти за рахунок збільшення зусиль для моделювання.

На бажаному краю годинника (зростаючий чи падаючий) вхід на D відображається на виході Q. Це займає обмежений час (затримка від тактової частоти до Q) та припускаючи, що немає порушень часу, D буде проходити лише один FF за один раз (тобто якщо є інший вхід FF, підключений до Q, другий FF передасть значення Q FF1 перед тим, як воно зміниться.

Щоб включити синхронізацію у своє моделювання, вам потрібно синтезувати та розмістити та прокласти маршрут, а потім виконати моделювання місця та маршруту. Тут будуть включені всі комбінаційні, затримки до Q та ін. Моделювання HDL не має жодного з цих термінів, тому воно корисне лише для тестування основних операцій, а не обмежень часу. Ви також отримаєте звіт про терміни, який повідомить вам про обмеження швидкості певного доменного годинника, повідомить про наявність порушень у часі та покаже вам слабкість часу для різних шляхів. Ви можете скористатися цією інформацією, щоб визначити, де можуть знадобитися розміщення каналів, або додати правила, щоб повідомити про програмне забезпечення, що порушення не є проблемою (наприклад, такі речі, як багатоциклічні шляхи або перехресні шляхи)

Це мається на увазі як доповнення до попередніх відповідей, з яких я вважаю, ви отримуєте ідею.

Ці питання справді можуть бути дещо складними на початку, коли моделювання RTL розробляє проекти, оскільки важко зрозуміти, що є причиною та який ефект при ідеальному / функціональному / RTL-моделюванні (= відсутність затримок із поширенням).

При правильному тренажері, затримки дельта може фактично бути візуалізовані. ISim цього не робить, але в ei ModelSim ви можете включити дельта розширення по краях годин. Нижче наведено приклад скріншота з помилкового сторонніх IP-адрес, з якими я вирішував проблеми.

c- тактовий сигнал, і +1т.д. - цикли дельти, візуалізовані як час.

Якщо конструкція моделюється там, де і моделювання, і конструкція справді ідеальна і синхронна , без затримок, що моделюються, ви можете, в принципі, переглянути всі зміни сигналу на певному боці годинника, як це відбувається трохи після цього флангу годинника. Отже, у вашому прикладі при 205 нс data_write= 0000...це те, що захоплюється. Деякі інші логіки в першому блоці змінюють сигнал data_writeна 0001...на одному фланзі, і здається , що сигнал на data_writeкілька годин після флангу. Це "трохи після" буде однією або декількома дельтами імітації в ідеальному моделюванні (ваш приклад) (не видно в ISim, але, наприклад, ModelSim з дельта-розширенням), або деякі PS / ns пізніше в реальному світі.

Зі сторони: Одним з важливих моментів у дизайні RTL є переконання, що вхідні дані завжди відбираються на флангу годинника - навіть один цикл дельти пізніше буде занадто пізно. Введення може бути недопустимим на одну дельту пізніше. Або іншими словами: "не возитися з годинниковою доріжкою".