czas procesu na FPGA

Jestem nowy w fpgas i istnieją pewne subtelności czasowe, których nie jestem pewien, rozumiem: jeśli wszystkie moje procesy synchroniczne są uruchamiane na tym samym zboczu, oznacza to, że moje dane wejściowe są „przechwytywane” na jednym zboczu narastającym, a moja wyjścia zmieniają się na… tej samej krawędzi? kolejna wschodząca krawędź?

jeśli mam dwa moduły, w których wyjście jednego wpływa do wejść następnego, może wystąpić sytuacja, w której dane wejściowe do mojego modułu (wyjścia poprzedniego modułu) zmieniają się w tym samym czasie, w którym są przechwytywane.

Znacznik przy 205ns pokazuje, o czym mówię, op i data_write są moimi danymi wejściowymi. Wszystko wydaje się „po prostu działać” w tym przypadku testowym, ale w symulacji nie jest jasne, co dokładnie jest rejestrowane. Czy data_write = "0001 ..." jest przechwytywany przy 205ns lub (205ns + 1 cykl zegara)? Czy istnieje sposób na uzyskanie bardziej szczegółowych przebiegów w programie ISim, które pokazują czasy konfiguracji i wstrzymania?

Dzięki.

Przerzutnik zawsze ma pewne opóźnienie propagacji. Często nazywa się to opóźnieniem „od zegara do Q”.

Oznacza to, że twoje dane wejściowe są rejestrowane na brzegu, a dane wyjściowe zmieniają się na tej samej krawędzi, ale zaledwie kilka nanosekund później. To kilka nanosekundowych opóźnień jest wystarczające (jeśli twoje przerzutniki są zaprojektowane z „zerowym czasem podtrzymania”, jak to ma miejsce w większości układów FPGA), że zmiany nie wpływają na żadne przerzuty do następnego zegara.

W symulacji funkcjonalnej lub RTL (prawdopodobnie robisz to, aby wygenerować wynik) opóźnienie nie będzie symulowane jako trwałe nanosekundy. W VHDL będzie to pojedynczy cykl delta zegara symulatora, co technicznie nie jest wcale czasem. To uniemożliwia dostrzeżenie opóźnienia na wyjściu symulatora. Niemniej jednak w przypadku symulowanych jako idealne flip-flopów wystarczy, aby zmiany wyjściowe nie wpływały na przerzutniki downstream.

Jeśli wykonujesz symulację po umiejscowieniu i trasie, powinna ona zawierać odpowiednie opóźnienia, aby wyraźnie zobaczyć te efekty, kosztem zwiększonego wysiłku symulacyjnego.

Na pożądanym zboczu zegara (rosnącym lub opadającym) wejście na D pojawia się na wyjściu Q. Zajmuje to skończoną ilość czasu (opóźnienie od zegara do Q) i przy założeniu, że nie występują naruszenia taktowania, D przejdzie tylko przez jeden FF na raz (tzn. jeśli do Q podłączone jest inne wejście FF, drugi FF przekaże wartość Q FF1 zanim się zmieni.

Aby uwzględnić czasy w symulacji, musisz zsyntetyzować i umieścić i trasować swój projekt, a następnie uruchomić symulację miejsca i trasy. Będzie to uwzględniać wszystkie kombinacje, opóźnienia zegara do Q itp. Symulacja HDL nie ma żadnego z tych ustawień czasowych, więc jest przydatna tylko do testowania podstawowej operacji, a nie limitów czasowych. Otrzymasz również raport o taktowaniu, który poinformuje Cię o ograniczeniach prędkości w konkretnej domenie zegara, poinformuje Cię, czy występują jakieś naruszenia taktowania, i pokaże luz czasowy dla różnych ścieżek. Możesz użyć tych informacji, aby dowiedzieć się, gdzie należy wprowadzić zmiany, lub dodać reguły informujące oprogramowanie, że naruszenie nie stanowi problemu (np. W przypadku ścieżek wielocyklowych lub ścieżek krzyżowych)

Ma to stanowić uzupełnienie poprzednich odpowiedzi, z których, jak sądzę, masz pomysł.

Sprawy te mogą być na początku nieco trudne, gdy symuluje się projekty RTL, ponieważ trudno jest zrozumieć, co jest przyczyną i jaki jest efekt w idealnych / funkcjonalnych / symulacjach RTL (= brak opóźnień propagacji).

Przy pomocy odpowiedniego symulatora można w rzeczywistości wizualizować opóźnienia delta . ISim tego nie robi, ale w ei ModelSim można włączyć rozszerzenie delty wokół krawędzi zegara. Poniżej znajduje się przykładowy zrzut ekranu z błędnego adresu IP innej firmy, który zastrzeliłem.

cto sygnał zegara, +1itd. to cykle delta, wizualizowane jako czas.

Jeśli symulowany jest projekt, w którym zarówno symulacja, jak i projekt są naprawdę idealne i synchroniczne , bez symulacji opóźnień, można w zasadzie zobaczyć wszystkie zmiany sygnałów na konkretnym boku zegara jako nieznacznie występujące po tym boku zegara. Dlatego w twoim przykładzie, przy 205 ns, data_write= 0000...jest tym, co jest przechwytywane. Jakaś inna logika w pierwszym zespole zmienia sygnał data_writedo 0001...tego samego boku, i wydaje się, że sygnał na data_writelekko po boku zegara. To „nieco później” byłoby jedną lub kilkoma deltami symulacji w idealnej symulacji (twój przykład) (niewidocznym w ISim, ale np. ModelSim z rozszerzeniem delty) lub niektórych ps / ns później w prawdziwym świecie.

Na marginesie: Jedną ważną rzeczą przy projektowaniu RTL jest upewnienie się, że wejścia są zawsze próbkowane na flankach zegara - nawet jeden cykl delta później jest za późno. Dane wejściowe mogą nie być poprawne później o jedną różnicę. Lub innymi słowy: „nie zadzieraj ze ścieżką zegara”.