Leren Verilog: Een korte Tutorial-serie over digitale elektronica ontwerp met FPGA en Verilog HDL (19 / 21 stap)

Stap 19: VM 4.2: blokkeren vs. Non-Blocking Verilog verklaringen

Wanneer we code in C/C++ schrijven, onze code regel voor regel in sequentiële volgorde is uitgevoerd totdat het programma wordt verteld om af te wijken van dit patroon (bijvoorbeeld naar een bepaalde regel springen). Een regel wordt uitgevoerd en pas na het afwerkingen uitvoeren is de volgende regel uitgevoerd. Voor de meest praktische doeleinden zien we niet iedere vertraging bij de eenvoudige consoletoepassingen. Maar in digitaal ontwerp, deze vertraging van het uitvoeren van één regel naar het volgende zeer negatieve en merkbare gevolgen zou kunnen hebben. Zelfs vertragingen van minder dan een nanoseconde kon veroorzaken problemen; glitches om precies te zijn.

Een glitch is formeel gedefinieerd als een kortstondige en ongewenste wijziging in de uitgang van een circuit als gevolg van een ingang voor het invoeren van een tijdelijke staat en de input hebben van ten minste twee paden door het circuit met geen gelijkwaardige gate vertragingen tussen paden.

Stel je voor dat je hebt twee schakelaars (sw0 en sw1) die beide een logica van 0 waren, en de daaruit voortvloeiende output van een enkele LED een logica een was mochten beide schakelaars een logica 0 (LED = ~(sw0 & sw1)), onder andere gewenste uitgangen. Maar zeggen dat u sw1 spiegelen naar een hoge staat van logica. Wat gebeurt er als alleen voor een kleine fractie van een seconde dat LED nog steeds een logica terwijl de spanning van de bron sw1 was "rimpelingen" weg "downstream" door de logic-poorten in haar verschillende paden totdat het tot de laatste in het circuit poort? Daarin ligt een fractie van een seconde waar de LED een logica een is wanneer theoretisch het moet een logica nul; uw circuit brak de regels van de vergelijkingen van zijn eigen logica!

Terwijl het punt van deze module is niet ter dekking van hoe op te lossen van storingen in uw logica verklaringen, is het punt dat zelfs mooi gevormde logica vergelijkingen voor circuits die zijn "glitch gratis" potentieel een glitch maken kunnen als u een blokkerende instructie gebruiken waar u moet hebt gebruikt een niet-blokkerende instructie en vice versa.

Hoe gaat dit gebeuren en waarom zou het verkeerde Verilog verklaring veroorzaken dit?

Een blokkerende instructie is een toe te wijzen (het hoeft niet noodzakelijkerwijs gebruik van het "toewijzen" sleutelwoord) verklaring die met de operator "=". Blokkerende instructies worden uitgevoerd als code in C/C++: opeenvolgend en in volgorde.

Een verklaring van niet-blokkerende is een vertaaltaken toe te wijzen-instructie waarin met de "< =" exploitant. Non-blocking verklaringen toen zette in hetzelfde bereik van code met andere niet-blokkerende verklaringen zal gelijktijdig worden uitgevoerd.

Re lees de bovenstaande definities zoals ze zeer belangrijk zijn.

Een gemeenschappelijke gedachte studenten kunnen hebben is "Verilog code een hardwarebeschrijvingstaal, is dus het moet niet uit wat voor soort verklaring ik schrijf omdat het synthetiseren in hetzelfde fysieke circuit en gedragen zich op dezelfde manier." Dit is niet noodzakelijkerwijs het geval, als de complexe Verilog compiler zal hebben om verschillende transistor patronen om door te geven van de verschillende signalen naar verschillende plaatsen te maken, en u moet opgeven als dit moet gebeuren op hetzelfde moment of op andere tijdstippen. Is het wellicht efficiënter om te bouwen van een circuit met verklaringen die signalen tegelijk handig om het circuit kunnen direct blokkeren, maar vaak is het belangrijk dat de twee of meer uitvoer veranderingen op in wezen hetzelfde moment plaatsvinden.

Ziet u hoe een reeks blokkerende instructies ongunstig van circuit gedrag zou kunnen beïnvloeden? De verklaringen van de hoogste niveau toewijzen blokkeren omdat de instructies worden alleen "uitgevoerd" eenmaal, maar iets als een decoder die kan "always" worden herevaluatie van voorwaarden moet u uitgangen tegelijkertijd wijzigen. Stel je de problemen die een ingenieur hebben zou als hun decoder-uitgang GS en uitgangssignalen EO gewijzigd op verschillende tijdstippen!

Neem een kijkje op enkele eenvoudige voorbeelden ("als" verklaringen vallen in de volgende module!):

Example #1
altijd @ (sw0, sw1)
beginnen
Als (sw0 == 1' b1)
beginnen
alle deze uitgangen krijgt hun
waarden op hetzelfde moment
Uitgang1 < = 1' b0;
output2 < = 1' b1;
output3 < = 1' b0;
einde
einde

Voorbeeld #2
altijd @ (sw0, sw1)
beginnen
Als (sw0 == 1' b1)
beginnen
het eerste resultaat krijgt, dan de volgende twee
gelijktijdig zal worden toegewezen
Uitgang1 = 1' b0;
output2 < = 1' b1;
output3 < = 1' b0;
einde
einde

Example #3
altijd @ (sw0, sw1)
beginnen
Als (sw0 == 1' b1)
beginnen
het eerste resultaat krijgt, dan de volgende twee zal
na elkaar worden toegewezen
Uitgang1 = 1' b0;
output2 = 1' b1;
output3 = 1' b0;
einde
einde

Nooit zetten een blokkerende instructie binnenkant van een blok van de structurele logica. Met andere woorden, Leg nooit een "=" binnenkant van een altijd blokkeren. Zelfs als u alleen het wijzigen van een uitgang is slechte praktijken een blokkerende instructie te gebruiken.

Altijd een blokkerende instructie gebruiken bij het gebruik van het sleutelwoord "toewijzen". Deze verklaringen vindt altijd plaats buiten een altijd blokkeren. Voorbeeld gebruik zou worden waarbij een reg waarvan de waarde die u wijzigt binnenkant van een altijd blokkeren, vervolgens toe te wijzen een draad output "=" van de reg waarde.

Hint: je meestal krijgt een reg een waarde door gebruik te maken van het formulier: < naam van reg >< = < waarde >;

Extra Hint (duplicate): U kunt alleen het instellen van waarden voor een reg in een altijd blokkeren, geen toewijzen waarden wilt typen van de draad. U kunt echter later de draad gelijkgesteld aan van de reg waarde toewijzen.