Program för att designa mikroprocessorenheter. Mikroprocessorer. Operatörer och verksamhet

Ett mimåste uppfylla följande krav: ge hög prestanda och vara enkelt att implementera, måste säkerställa stabil och problemfri drift, vara relativt billigt och förbruka få resurser. För att utföra de tilldelade uppgifterna och i enlighet med de grundläggande kraven är mikrokontrollern i K1816BE51-serien lämplig.

Figur 3 - Blockschema över ettem.

mikroprocessorprogramalgoritmchip

Mikroprocessorsystemet (MPS) består av följande block: mikrokontroller (MC), random access memory (RAM), läsminne (ROM), programmerbar timer (PT), parallellt programmerbart gränssnitt (PPI), analog-till-digital omvandlare (ADC), digital-till-analog-omvandlare (DAC), multiplexor (MUX), programmerbar avbrottskontroller (PIC).

MK:n bildar en adressbuss (ABA), en databuss (SD) och en styrbuss (CC). RAM-, ROM-, PT-, PPI-, PKP-block är anslutna till bussarna.

RAM är utformat för att lagra sensormätningsdata, såväl som mellanliggande data. ROM är utformad för att lagra programkod och olika konstanter.

PT är utformad för att räkna tidsintervallet som kommer att krävas för att utföra MK-kommandon. Innan operationen utförs startas PT. Om operationen lyckas återställer MK:n PT. Om inget räkneåterställningskommando tas emot från MC (en frysning har inträffat), genererar PT, vid slutet av tidsintervallräkningen, en MC-återställningssignal.

PPI är avsedd för anslutning externa enheter. En ADC, en diskret multiplexor och en DAC är anslutna till SPI:n.

ADC:n är utformad för att omvandla en analog signal från sensorer och en digital kod, som matas till MK:n via PPI. Analoga sensorer ansluts till ADC via en analog multiplexer.

Data från diskreta sensorer tas emot genom en diskret multiplexor.

DAC:n är utformad för att generera kontrollåtgärder.

Kontrollpanelen är utformad för att serva externa avbrott.

Stadier av design av mikroprocessorsystem

Mikroprocessorsystem i deras komplexitet, krav och funktioner kan skilja sig avsevärt i tillförlitlighetsparametrar, volym programvara, vara enprocessor och multiprocessor, byggd på en typ av mikroprocessorset eller flera osv. I detta avseende kan designprocessen modifieras beroende på kraven på systemen. Till exempel kommer processen att designa MPS som skiljer sig från varandra i ROM-innehåll bestå av att utveckla program och tillverka ROM.

Vid utformning av musom innehåller flera typer av mikroprocessoruppsättningar är det nödvändigt att lösa problem med minnesorganisation, interaktion med processorer, organisation av utbyte mellan systemenheter och den externa miljön, samordning av funktionen hos enheter med olika driftshastigheter, etc. Nedan är en ungefärlig sekvens av steg, typiska för att skapa ett mikroprocessorsystem:
1. Formalisering av systemkrav.
2. Utveckling av systemets struktur och arkitektur.
3. Utveckling och produktion av systemhårdvara och mjukvara.
4. Omfattande felsökning och acceptanstestning.

Steg 1. I detta skede upprättas externa specifikationer, systemets funktioner listas, de tekniska specifikationerna (TOR) för systemet formaliseras och utvecklarens planer anges formellt i officiell dokumentation.

Steg 2. I detta skede bestäms funktionerna för individuella enheter och mjukvara, mikroprocessoruppsättningar väljs utifrån vilka systemet kommer att implementeras, interaktionen mellan hårdvara och mjukvara och tidsegenskaperna för individuella enheter och program bestäms .

Steg 3. Efter att ha fastställt funktionerna som implementeras av hårdvaran och funktionerna som implementeras av programmen, börjar kretsdesigners och programmerare samtidigt att utveckla och tillverka en prototyp respektive mjukvara. Utveckling och tillverkning av utrustning består av utveckling av struktur- och kretsscheman, prototyptillverkning och off-line felsökning.
Mjukvaruutveckling består av att utveckla algoritmer; skriva texten i källprogram; översättningar av källprogram till objektprogram; offline-felsökning.

Steg 4. Se Omfattande felsökning.

I varje steg av MPS-design kan människor introducera fel och fatta felaktiga designbeslut. Dessutom kan defekter uppstå i utrustningen.

Källor till fel

Låt oss överväga felkällorna i de tre första stadierna av design.

Steg 1. I detta skede kan felkällor vara: logisk inkonsekvens av krav, utelämnanden, felaktigheter i algoritmen.

Steg 2. I detta skede kan felkällor vara: utelämnanden av funktioner, inkonsekvens i protokollet för interaktion mellan utrustning och program, felaktigt val av mikroprocessoruppsättningar, felaktigheter i algoritmer, felaktig tolkning av tekniska krav, utelämnande av vissa informationsflöden.

Steg 3. I detta skede kan felkällor vara: under utvecklingen av utrustning - utelämnanden av vissa funktioner, felaktig tolkning av tekniska krav, defekter i synkroniseringskretsar, brott mot designregler; under produktionen av en prototyp - fel på komponenter, installations- och monteringsfel; vid utveckling av mjukvara - utelämnanden av vissa funktioner mandat, felaktigheter i algoritmer, felaktigheter i kodningen.

Var och en av de listade felkällorna kan generera ett stort antal subjektiva eller fysiska fel som måste lokaliseras och elimineras. Felsökning och fellokalisering är en svår uppgift av flera skäl: för det första på grund av det stora antalet fel; för det andra på grund av att olika fel kan yttra sig på samma sätt. Eftersom det inte finns några modeller för subjektiva fel är denna uppgift inte formaliserad. Det har gjorts vissa framsteg när det gäller att skapa metoder och verktyg för feldetektering och lokalisering av fysiska fel. Dessa metoder och verktyg används i stor utsträckning för att kontrollera drifttillståndet och diagnostisera fel hos diskreta system under konstruktion, produktion och drift av de senare.

Subjektiva felfunktioner skiljer sig från fysiska genom att de inte längre uppstår efter upptäckt, lokalisering och korrigering. Men, som listan över felkällor antyder, kan subjektiva fel införas under utvecklingen av systemspecifikationen, vilket innebär att även efter den mest noggranna testningen av ett system mot dess externa specifikationer kan subjektiva fel fortfarande förekomma i systemet.

Designprocessen är en iterativ process. Fel som upptäcks under acceptanstestningsstadiet kan leda till korrigering av specifikationer och följaktligen till att hela systemet börjar designas. Det är nödvändigt att upptäcka fel så tidigt som möjligt; för att göra detta är det nödvändigt att kontrollera projektets riktighet i varje utvecklingsstadium.

Validering av designen

De viktigaste metoderna för att övervaka designens riktighet är följande: verifiering - formella metoder för att bevisa designens riktighet; modellering; testning.

Det är mycket arbete med verifiering av mjukvara, firmware och hårdvara. Dessa verk är dock teoretiska till sin natur. I praktiken används fortfarande modellering av objektbeteende och testning.

För att kontrollera projektets riktighet vid varje designstadium är det nödvändigt att utföra modellering på olika nivåer av den abstrakta representationen av systemet och verifiera den korrekta implementeringen av en given modell genom testning. I stadiet av kravformaliseringen är korrekthetskontroll särskilt nödvändig, eftersom många designmål inte är formaliserade eller i princip inte kan formaliseras. Den funktionella specifikationen kan granskas av ett team av experter eller simuleras och testas för att avgöra om de önskade målen uppnås. När funktionsspecifikationen är godkänd börjar utvecklingen av funktionstestprogram för att fastställa att systemet fungerar korrekt i enlighet med dess funktionsspecifikation. Helst utvecklas tester som är helt baserade på denna specifikation och ger möjlighet att testa vilken implementering som helst av ett system som påstås kunna utföra de funktioner som specificeras i specifikationen. Denna metod är raka motsatsen till andra, där tester byggs i relation till specifika implementeringar. Implementeringsoberoende funktionsverifiering är vanligtvis attraktiv endast i teoretiska termer, men har ingen praktisk betydelse på grund av dess höga grad av generalitet.

Att automatisera det tråkiga arbetet med att skriva testprogram minskar inte bara design-/felsökningsperioden genom att generera testprogram under designfasen (eftersom de kan genereras direkt efter att systemkraven har genererats), utan gör det också möjligt för designern att ändra specifikationer utan att behöva oroa dig för att skriva om alla testprogram igen. Men i praktiken prioriteras testutveckling ofta lägre än design, alltså testprogram dyker upp mycket senare än den är klar. Men även om detaljerade tester visar sig vara förberedd, är det ofta opraktiskt att köra dem på en simulator, eftersom detaljerad modellering kräver stora utgifter för programutveckling och beräkningstid, som ett resultat måste det mesta av felsökningsarbetet skjutas upp till skapandet av ett prototypsystem.

När ett fel har upptäckts måste dess källa lokaliseras för att kunna utföra korrigering på lämplig abstraktionsnivå av systemet och på lämplig plats. Falsk identifiering av källan till felet eller att göra korrigeringar på en annan nivå av den abstrakta representationen av systemet leder till att information om systemet är övre nivåerna blir felaktig och kan inte användas för ytterligare felsökning under produktion och drift av systemet. Till exempel, om en funktionsfel introduceras i källtexten för ett program skrivet på assemblerspråk, och korrigeringen utförs i objektkod, utförs ytterligare felsökning av programmet i objektkod; i det här fallet reduceras alla fördelar med att skriva ett program på assemblerspråk till ingenting.

Blockschemat för enheten presenteras i bilaga A.

Detta mikroprocessorsystem består av följande block: mikroprocessor, RAM, ROM, programmerbart parallellt gränssnitt, analog-till-digital-omvandlare, timer, display.

Analoga signaler från sensorerna kommer till ingångarna på en analog multiplexer som är inbyggd i ADC:n, som vid varje tidsintervall kopplar om en av signalerna till ingången på analog-till-digital-omvandlaren.

En analog-till-digital-omvandlare används för att omvandla en analog signal till en digital kod som mikroprocessorn arbetar med.

Mikroprocessorn får åtkomst till ADC:n genom ett programmerbart parallellt gränssnitt. Läser information från ADC-utgångarna och lagrar den i en RAM-minnescell. Dessutom beräknar MP, baserat på information från oljetryckssensorn vid stationens utlopp, den regulatoriska påverkan. Denna mängd i formuläret digital kod ställdonet överförs.

RAM används för tillfällig lagring av information mottagen från sensorer och mellanresultat av mikroprocessorberäkningar.

Systemprogramvaran lagras i ROM (skrivskyddat minne). Läsoperationen styrs av mikroprocessorn.

Programmet, som är lagrat i ROM, tillhandahåller följande systemoperationer:

Sekventiell avfrågning av sensorer;

Styrning av analog-till-digital omvandling av en analog signal;

Oljetrycksreglering;

Indikering och larm;

Svar på effektbortfall.

Utveckling av systemalgoritmen

Blockschemat för algoritmen presenteras i Appendix B.

Initialisering

I detta skede skrivs styrord till RUS för det programmerbara parallella gränssnittet. PPI DD10 arbetar i nollläge. Portarna fungerar enligt följande: port A - ingång, port B - utgång, port C - utgång. PPI DD1 arbetar i nollläge. Portarna fungerar enligt följande: port A - utgång, port B - utgång, port C - utgång.

Sensor polling

De analoga sensorerna pollas av ADC. Diskreta sensorer genom port A på PPI 1 avfrågas av mikroprocessorn.

Sparar till RAM

Resultaten som erhålls efter att ha förhört sensorerna läggs in i en minnesenhet för tillfällig lagring.

Kontrollåtgärd

Mikroprocessorsystemet analyserar mottagna data och genererar en digital styråtgärd.

Utveckling av ett schematiskt diagram

Det schematiska diagrammet för enheten presenteras i bilaga D.

Adressbussen bildas med användning av ett buffertregister och en bussdrivrutin. Registerval utförs med hjälp av mikroprocessorns ALE-signal. Bussföraren behövs för att öka belastningskapaciteten för adressens höga byte.

Databussen bildas med hjälp av en busdrivrutin, som väljs genom att applicera DT/R- och OE-signalerna.

Systembussen bildas genom DD10-avkodaren genom att applicera en kombination av M/IO, WR, RD-signaler.

Tabell 1 - Styrsignaler

Valet av ROM, RAM och andra enheter sker med hjälp av linjerna A13-A15 på adressbussen genom en avkodare. ROM-celler finns på adressen 0000h.

Tabell 2 - Val av enhet

			Enhet

Valet av en port eller ett register för PPI-styrordet utförs via linjerna AO, Al i adressbussen. Diskreta sensorer matas till ingångarna på port A PA0-PA7 på PPI DD12; till ingångarna på port B - från ADC; Lysdioder är anslutna till ingångarna på port C.

Den analoga multiplexorn används för att välja den enhet från vilken information läses. En analog multiplexer är inbyggd i ADC:n. ADC-bredden sammanfaller med databussens bredd och är 8 bitar.

Motstånd R2-R4 används för att omvandla en enhetlig strömsignal på 4...20 mA till en spänning på 1...5V.

Genom att klicka på knappen "Ladda ner arkiv" laddar du ner filen du behöver helt kostnadsfritt.
Innan du laddar ner den här filen tänk på de bra sammanfattningar, tester, terminsuppsatser, avhandlingar, artiklar och andra dokument som ligger outtagna på din dator. Det här är ditt arbete, det ska delta i samhällets utveckling och gynna människor. Hitta dessa verk och skicka in dem till kunskapsbasen.
Vi och alla studenter, doktorander, unga forskare som använder kunskapsbasen i sina studier och arbete kommer att vara er mycket tacksamma.

För att ladda ner ett arkiv med ett dokument, ange ett femsiffrigt nummer i fältet nedan och klicka på knappen "Ladda ner arkiv"

Liknande dokument

Analys av designlösningar och val av den optimala lösningen utifrån det. Syntes av ett funktionsdiagram av ett mikroprocessorsystem baserat på analys av källdata. Processen att utveckla hårdvara och mjukvara för ett mikroprocessorsystem.

kursarbete, tillagt 2014-05-20


Teoretisk grund utveckling av ett mikroprocessorsystem baserat på en mikrokontroller och en läsenhet e-böcker, analys av deras tekniska och ekonomiska indikatorer och jämförelse med analoger. Grundläggande standarder för arbetsskydd vid arbete med dator.

avhandling, tillagd 2010-07-13


Möjligheten att använda en MP-enhet. Mikroprocessorsystemarkitektur. Strukturell organisation av LSI VT med isolerade bussar. Innehåll och eventuellt fokus för mikrokontrollern. Generaliserad struktur för en enkel inbäddad mikrokontroller.

abstrakt, tillagt 2011-04-28


Mikroprocessorsystemets struktur, algoritmen för dess kontroll och signalöverföring. Adressfördelningskarta. Elutveckling schematiskt diagram och val av elementbas. Beräkning av strömförbrukning, strömförsörjning, mjukvara.

kursarbete, tillagd 2014-01-22


Fördelning av funktioner mellan hårdvaru- och mjukvarudelar i mikroprocessorsystemet. Val av mikrokontroller, utveckling och beskrivning av struktur-, funktions- och kretsschema. Val av programmeringsmiljö, algoritmdiagram och programlista.

kursarbete, tillagt 2013-08-17


Syfte och design av ett mikroprocessorstyrsystem. Beskrivning av funktionsdiagrammet för mikroprocessorns styrsystem. Beräkning av mätkanalens statiska egenskaper. Utveckling av en algoritm för funktionen av ett mikroprocessorstyrsystem.

kursarbete, tillagd 2010-08-30


Allmänt koncept för mikrokontroller, deras användning och syfte. Utveckling av ett projekt för datainsamling av mikroprocessorer med SDK 1.1 och SDX 0.9 stativ. Skapande av programvara och dess laddning i laboratoriemontern SDK-1.1.

kursarbete, tillagd 2014-01-31

Kvalitativa och kvantitativa förändringar i den elementära basen av VT-utrustning har lett till

ändra de etablerade principerna för deras design (som stel

struktur, konsekvent central ledning, linjeorganisation

minne och oförmåga att anpassa datorstrukturen till egenheter

problem som löses).

De klassiska Von Neumann-principerna för att organisera datorsystem ersattes av idéerna om problemorientering av MPS, parallell- och pipeline-informationsbearbetning, användning av tabellformade metoder för databehandling, principer om regelbundenhet och homogenitet för MPS-strukturer; blir verklig

möjlighet att skapa adaptivt omkonfigurerbara system, samt

hårdvaruimplementering av mjukvarufunktioner. Därför för närvarande

tid när man designar datorsystem baserade på mottagna MPS

tillämpning av den så kallade "3M"-principen: modularitet, trunking,

mikroprogrammerbarhet.

Principen för modulär organisation innebär konstruktion av beräknings- och

styra MPS baserat på en uppsättning moduler: strukturell, funktionell och

elektriskt kompletta datorenheter som låter dig självständigt

eller i kombination med andra moduler för att lösa problem i denna klass. Modul

strategi för design av mikrodatorer och system tillåter (när de implementeras som

universella och specialiserade moduler) för att säkerställa skapandet av familjer

(rader) av MPS, olika funktionalitet och egenskaper,

täcker ett stort antal applikationer, hjälper till att minska

designkostnader, och förenklar även kapacitetsutbyggnad och

omkonfigurering av system, försenar inkuransen av datoranvändning

Backbone metod för informationsutbyte i motsats till sättet att organisera

godtyckliga anslutningar (enligt principen "alla med alla") låter dig organisera och

minimera antalet anslutningar i MPS. Det underlättar utbytet av information mellan

funktionella och strukturella moduler på olika nivåer med hjälp av

motorvägar som ansluter in- och utgångsbussar. Det finns en-, två-,

tre- och flerlinjeanslutningar. Det är nödvändigt att notera förhållandet

kretsdesign och strukturella lösningar som dyker upp under implementeringen

den här metoden utbyte i form av att skapa speciell dubbelriktad buffert

kaskader med tre stabila tillstånd och användningen av tillfälliga

multiplexering av utbyteskanaler.

Firmware kontroll ger den största flexibiliteten i organisationen

multifunktionella moduler och möjliggör problemorientering

MPS, och även använda makrooperationer i dem, vilket är mer effektivt än att använda

standardrutiner. Dessutom överföring av kontrollerade ord i form

krypterade kodsekvenser motsvarar minimeringsvillkoren

antal VLSI-stift och minska antalet sammankopplingar i moduler.

Förutom huvuddragen i MPS-design som anges ovan bör det vara det

notera regelbundenhetsprincipen, som förutsätter en naturlig

repeterbarhet av elementen i strukturen för MPS och kopplingarna mellan dem. Tillämpning av detta

principen gör att du kan öka den integrerade tätheten, minska längden på bindningar

on-chip, minska topologisk tid och kretsdesigntid

utformning av LSI och VLSI, minska antalet korsningar och typer av funktionell

och strukturella element.

Vid utveckling av MPS-arkitekturen (systemstadiet) är det nödvändigt att lösa följande

Beskriv den konceptuella strukturen för systemets funktionella beteende med

positioner att ta hänsyn till användarens intressen under dess konstruktion och organisation

beräkningsprocessen i det;

Bestäm strukturen, nomenklaturen och funktionerna för att konstruera programvara och

mikroprogramverktyg;

Beskriv egenskaperna hos den interna organisationen av dataflöden och kontroll

information;

Genomföra en analys av det fysiskas funktionella struktur och egenskaper

implementering av systemenheter ur mjukvarubalansens perspektiv,

mikroprogram och hårdvara.

Huvudstegen för att designa en MPS visas i fig. 3.1.

I det inledande konstruktionsstadiet kan MPS beskrivas i en av

följande konceptuella nivåer: "svart låda", strukturell, program,

logisk, krets.

På nivån "svart låda" beskrivs MPS av externa specifikationer, där

yttre egenskaper listas.

Ris. 3.1. Stadier av MPS-design

Den strukturella nivån skapas av hårdvarukomponenterna i MPS, som

beskrivs av funktionerna hos enskilda enheter, deras sammankopplingar och information

strömmar.

Programvarunivån är uppdelad i två undernivåer (processorinstruktioner och

språk) och MPS tolkas som en sekvens av operatörer eller

kommandon som orsakar en eller annan åtgärd på en viss datastruktur.

Den logiska nivån är inneboende uteslutande i diskreta system och är uppdelad i

två undernivåer: kopplingskretsar och registeröverföringar.

Den första undernivån bildas av grindar (kombinationskretsar och minneselement) och databehandlingsoperatörer byggda på deras bas. Den andra undernivån kännetecknas av en högre grad av abstraktion och representerar en beskrivning av register och dataöverföring mellan dem. Den innehåller två

delar: information och kontroll: den första bildas av register,

operatörer och dataöverföringsvägar, den andra ger beroende på

tidssignaler som initierar dataöverföring mellan register.

Kretsnivån är baserad på en beskrivning av funktionen hos diskreta anordningselement.

I livscykeln för en MPS, som alla diskreta system, finns det tre stadier:

design, tillverkning och drift.

Varje steg är uppdelat i flera faser för vilka det finns sannolikheter för strukturella eller fysiska fel. Fel klassificeras efter deras orsaker: fysiska, om orsaken är defekter i elementen, och subjektiva, om orsaken är konstruktionsfel.

Subjektiva fel delas in i design och interaktiva. Design

funktionsfel orsakas av brister som införts i systemet i olika skeden

genomförandet av den ursprungliga uppgiften. Interaktiva fel uppstår i

under arbete på grund av fel från servicepersonalen (operatören). Resultatet

manifestationer av ett fel är ett fel, och ett fel kan

orsaka ett antal fel, och samma fel kan orsakas

många fel.

Det finns också begreppet defekt - en fysisk förändring av parametrar

systemkomponenter som överskrider tillåtna gränsvärden. Defekter kallas

misslyckanden om de är tillfälliga och misslyckanden om de är permanenta.

En defekt kan inte upptäckas förrän förutsättningarna för

förekomsten av ett fel på grund av det, vars resultat bör vara, i dess

kö, skickas till utgången av objektet som studeras för att göra

observerbar funktionsfel.

Feldiagnos är processen för att fastställa orsaken till ett fel genom

testresultat.

Felsökning är processen att upptäcka fel och fastställa

källor till deras utseende enligt resultaten av testning under utformningen av MPS.

Felsökningsverktyg är enheter, komplex och program. Ibland under

Debugging avser upptäckt, lokalisering och eliminering av fel. Framgång

felsökning beror på hur systemet är designat, om

egenskaper som gör det bekvämt för felsökning, samt från de verktyg som används

för felsökning.

För att utföra felsökning måste den designade MPS ha

egenskaper styrbarhet, observerbarhet och förutsägbarhet.

Styrbarhet – egenskap hos ett system där dess beteende är mottagligt för

ledning, d.v.s. Det är möjligt att stoppa driften av systemet i

visst tillstånd och starta om systemet.

Observerbarhet– en egenskap hos ett system som låter dig övervaka dess beteende

systemet, bakom förändringen av dess interna tillstånd.

Förutsägbarhet– en systemegenskap som gör att systemet kan installeras i

ett tillstånd från vilket alla efterföljande tillstånd kan förutsägas.

MPS kan variera avsevärt i komplexitet, krav och funktioner

driftsparametrar, volym av programvara, typ

mikroprocessorset etc. I detta avseende kan designprocessen

variera beroende på kraven på systemet.

Designprocessen är en iterativ process. Fel som upptäcks under acceptanstestningsstadiet kan leda till specifikationskorrigering, och

därför till början av designen av hela systemet. Hitta

fel måste upptäckas så tidigt som möjligt; för detta måste du kontrollera

projektets korrekthet i varje utvecklingsstadium. Följande metoder finns

kontroll av konstruktionens korrekthet: verifiering (formella metoder

bevis på projektets riktighet); modellering; testning.

Den senaste tiden har det dykt upp mycket arbete med mjukvaruverifiering

mjukvara, firmware, hårdvara. Dessa verk är dock fortfarande kvar

teoretisk till sin natur. Därför används i praktiken oftare modellering

objektbeteende och testning på olika abstrakta nivåer

systemrepresentationer.

I stadiet av formalisering av systemkrav, övervakning av projektets riktighet

särskilt nödvändigt eftersom många designmål inte är formaliserade eller

kan i princip inte formaliseras. Funktionsspecifikationen kan

analyseras av ett team av experter eller simuleras och testas i

experimentellt för att identifiera uppnåendet av önskade mål. Efter godkännande

funktionsspecifikation börjar utvecklingen av testprogram,

utformad för att etablera korrekt drift av systemet i enlighet med

dess specifikation. Helst utvecklas tester helt

baserat på denna specifikation och möjliggör verifiering av eventuella

implementering av ett system som har förklarats kapabelt att utföra funktionerna

som anges i specifikationen. Denna metod är raka motsatsen till andra,

där tester byggs i relation till specifika implementeringar. Dock i praktiken

testutveckling prioriteras ofta lägre än

projekt, så testprogram dyker upp mycket senare än det