Fys 3/4270 høsten Designflyt og utviklingsverktøyene Electronic Product Designer (EPD) og Warp2

Transkript

1 Fys 3/4270 høsten 2004 Designflyt og utviklingsverktøyene Electronic Product Designer (EPD) og Warp2

2 Designflyt og verktøy... 3 Designflyt for programmerbar logikk... 3 Designflyten i kurset... 5 Hvordan komme i gang med EPD... 6 Oppretting av prosjekt... 7 Forberedelse til VHDL-simulering med SpeedWave (Vantage) Klargjøring av simuleringsomgivelsene Litt om Working library Analysering (kompilering) av VHDL-kode Simulering Laste designet inn simulatioren Bruk av kommandofiler Hvordan komme i gang med Warp Oppretting av prosjekt i Warp Syntese og device fitting Kildefiler Device (Teknologivalg) Kontroll av hierarki Tilordning av pinner Kompilering Resultatfiler Jedec-filen Rapportfilen SpeedWave Post-JEDEC simuleringsfil Timing simulering i SpeedWave In-Circuit Programmering (Re-programmering)

3 Designflyt og verktøy I dette kurset skal vi bli kjent med to kraftige systemer for kretskonstruksjon: 1. Electronic Product Designer - EPD fra Innoveda (tidligere Viewlogic) 2. Warp2 fra Cypress Semiconductor EPD er et meget generelt og avansert system for design og simulering, mens Warp2 er et teknologi spesifikt syntese og routing (fitting) verktøy beregnet kun for Cypress sine programmerbare kretser. Dette notatet er skrevet som en kokebok for hvordan man kommer igjennom designprosessen fra A til Å. Designflyt for programmerbar logikk Figuren nedenfor viser en generell designflyt for et programmerbar logikk design. Teknologi uavhengige biblioteker Spesifikasjon Skjema Teknologi avhengige biblioteker Design Entry VHDL, Verilog, ABEL Simulering OK? Syntese Simulering OK? Ja Ja Place & Route (FPGA) Fitting (CPLD) Nei Nei Teknologi avhengig Teknologi uavhengig Timing Simulering OK? Nei Ja Device Programming Figur 1. Designflyt for programmerbar logikk 3

4 Register Transfer Level (RTL)-simulering Den første simuleringen er en høynivå funksjonell simulering, av f.eks. VHDL-kode. Til dette må vi benytte en VHDL-simulator. Ideelt sett trenger vi ikke ta stilling til hvilken teknologi designet skal inn i på dette punktet. Men ofte er det slik at vi må endre koden slik at den tar hensyn til restriksjoner/begrensninger i den teknologien vi til slutt velger. Det kan være at vi må ta hensyn til klokkedistrubusjon, globale reset, styring av tristateutganger osv. Etter at simuleringen er ferdig og vi er fornøyd går vi over til syntesen. Men før det må man gjøre et teknologivalg (type krets). Syntese Syntesen er en prosess som overfører en høynivå beskrivelse over til en gatelevel beskrivelse. Høynivå beskrivelse i denne sammenhengen kaller vi gjerne RTL-level (Register Transfer Level). I en RTL-beskrivelse har man som regel at alle registre (flip-flop er) er synlige. Gatelevel vil her si til sammenkopling av basiskomponenter (AND, OR, NOT osv) i et teknologiavhengig bibliotek. Dette er oftest tilfelle når vi skal ha et design inn i en FPGA. Resultatet av syntesen kan også være boolske ligninger som skal inn i en CPLD. Dette vil være tilfelle ved bruk av Warp2. Det er som regel mulig å gjøre en simulering etter syntesen. Dette vil kun være en verifisering av at syntesen gir rett resultat. Ofte utelates denne simuleringen, men kan være viktig hvis man har problemer og ikke vet hvor feilen ligger. Place and Route(Fitting) og timing simulering Dersom denne simuleringen er korrekt kan man gå over til prosessen der man plasserer det syntetiserte designet inn i den teknologien man har valgt. Denne prosessen kalles place and route for FPGA er og fitting for CPLD er. Verktøyene man benytter i denne prosessen lager kretsleverandørene. Etter at designet har gått igjennom en place and route eller fitting prosess, vil man gjerne verifisere både funksjonalitet og timing på designet. Og man har mulighet til å generere simuleringsfiler på diverse format som kan benyttes til dette. Er denne simuleringen i orden, er man så og si ferdig. Device Programming Da gjenstår bare det vi har kalt device programming, dvs. å få designet inn i den ønskede kretsen. Dette kan gjøres på svært mange forskjellige måter. F.eks. krever SRAM baserte FPGA er at man benytter en ekstern PROM/EPROM eller lignende for å lagre kretskonfigurasjonen(designet). Anti-fuse baserte FPGA er brennes en gang, og det er ingen mulighet for endringer. I en CPLD lagres konfigurasjonen internt i kretsen, og det finnes varianter som er EPROM basert som programmeres elektrisk og som kan slettes med UV-lys. Det finnes EEPROM baserte som både kan programmeres og slettes elektrisk. Det finnes også varianter som kan programmeres og reprogrammeres mens kretsen sitter loddes fast på det ferdige kortet. Disse kalles ISR CPLD er (In System Reprogrammable). Det er en krets av denne siste typen vi skal benytte i kurset. 4

5 Designflyten i kurset Siden vi skal benytte en krets fra Cypress med tilhørende verktøy, blir design flyten for denne litt annerledes en den generelle. For andre teknologier enn Cypress benytter man generelle syntese verktøy fra f.eks. Viewlogic eller Synopsys. Felles for disse er at de kan syntetisere til mange forskjellige målteknologier. Når man benytter Cypress sine programmerbare kretser er synteseprogrammet integrert som en del av fitting verktøyet fra Cypress, Warp2. Hovedforskjellen går ut på at man får ikke simulert rett etter syntese, men må vente til designet er ferdig plassert. I Cypress terminologi kalles dette Post-JEDEC simulering. Begrepene Post-layout, Post-Routing simulering betyr det samme. Denne type simulering vil verifisere både funksjonalitet og timing krav. Teknologi uavhengige biblioteker Spesifikasjon Teksteditor SpeedWave ViewWaves(VWaves) Warp2 (Galaxy) Warp2 (Galaxy) Teknologi avhengige biblioteker Design Entry VHDL Simulering OK? Ja Syntese Fitting (CPLD) Nei Warp2 fra Cypress Electronic Product Designer fra Innoveda SpeedWave ViewWaves(VWaves) ISR22.exe Post-JEDEC Simulering OK? Ja Device Programming Nei Warp2 fra Cypress Electronic Product Designer fra Innoveda Figure 2. Designflyt i kurset 5

6 Hvordan komme i gang med EPD EPD inneholder et program som heter Dashboard. Dashboard kan minne en del om Explorer i Windows. Vi har to typer directory (folders) innenfor Dashboard: Project og Toolboxes. Toolbox ene inneholder oppstart knapper for alle programmene i EPD og er arrangert i forskjellige grupper alt ettersom hvilke type design man skal gjøre. Vi vil finne de nødvendige knapper for våre design innenfor toolbox en Digital simulation. Dashboard startes for eksempel ved Start Programs Eproduct Designer Dashboard. Figure 3. Dashboard Vi kan også opprette egne shortcut-grupper hvor vi kan legge kopiere oppstartknapper fra de mest brukte programmene. Project directoriet inneholder en oversikt over alle prosjektene våre. I Windows NT og 2000 er disse prosjektlistene private for hver bruker. Project mappen er EPD sin måte å holde en bestemt filstruktur på prosjektene og å hjelpe oss med å holde oversikt over alle filer og mapper som inngår i et prosjekt. De aktuelle mappene vil variere litt etter hvilke type design man holder på med. 6

7 Oppretting av prosjekt Prosjekthåndtering er viktig i alle DAK-system. Meningen med dette er å skape en ordnet lagerstruktur for alle filer tilhørende et prosjekt. Et prosjekt i EPD består av et prosjektdirectory og en del underdirectorier. Av viktige underdirectorier kan nevnes:.\sch - inneholder skjema.\sym inneholder skjemasymboler.\wir inneholder sammenkoblingslister av symboler i et skjema Disse directoriene er ikke så viktig for oss i kurset, men skal man benytte EPD skjemategningsprogram, Viewdraw, er dette helt sentralt. Vi vil benytte prosjektdirectoriet som en utgangspunkt for å lagre filer tilhørende VHDLdesignet vårt. Som det snart går fram så får vi behov for å opprette VHDL-biblioteker og da benytter vi prosjektdirectoriet som utgangspunkt. Når vi velger menyen Tools Project Wizard kommer vi inn et hjelpeprogram for å opprette et nytt prosjekt. Vi velger Create or Open a Project og trykker deretter Next. Dette gir følgende dialog: Vi antar i dette eksemplet at prosjektområdet vårt skal hete gruppe_jn og være et underdirectory av c:\fys3/4270. Dere kan f.eks. benytte deres private nettverksdisk til prosjektområder slik at dere er garantert å ha alle filer i fred. Følgende dialog kommer til syne med trykk på... knappen 7

8 Når vi er ferdige her og kommet tilbake til forrige dialog, trykker vi Next som vist under. Dette gir en dialog der vi kan velge biblioteksgrupper eller FPGA-biblioteker. Dette er et biblioteksoppsett for skjemategning som er satt opp på forhånd (av en systemansvarlig). På våre maskiner har vi (sannsynligvis) ikkje noen valg. Skulle det mot formodning dukke opp et valg trykker vi Clear All. Trykk deretter Next. Dette åpner dialogen Specify Project Library. Her trykker vi bare på finish-knappen. 8

9 Etter dette får vi følgende informasjon: Merk altså at vi ikke har noen skjemasymbol biblioteker assosiert med prosjektet vårt. Skal vi f.eks. benytte Viewdraw til å lage skjema f.eks. rettet mot PCB verktøy er det meget viktig å få inkludert korrekte biblioteker. Hvis dette er en aktuell problemstilling ta da kontakt med Stein Lyng-Nielsen(Windows NT) på ELAB eller David Wormald (UNIX). Etter dette er vi klare til å starte å klargjøre for VHDL-simulering. 9

10 Forberedelse til VHDL-simulering med SpeedWave (Vantage) Figure 4 SpeedWave er en av Viewlogics tre digitale simulatorer: Speedwave -VHDL simulator og VHDL source-level debugger Viewsim -Gatelevel simulator VCS -Verilog simulator Alle disse simulatorene kan kjøres hver for seg. VCS har vi ikke lisens på. Programmet Digital Fusjon er et program som gjør det mulig å samsimulere blandede digitale simuleringer (f.eks. VHDL og skjema(gatelevel), VHDL, Verilog og skjema). I kurset skal vi kun simulere VHDL-kode og har bare behov for å benytte SpeedWave (Fusion/Speedwave). Beskrivelsen av SpeedWave tar utgangspunkt i et enkelt VHDL eksempel, der vi modellerer en 4-bits teller. Telleren resettes asynkront til 0 av GRESET_L signalet og trigger på positiv flanke av klokken CLK. Videre kan telleren resettes synkront til tallverdien på hexbryteren S1 ved å en positiv puls på trykknappen INP3. Når telleren når 15 (Fhex), går signalet TERM_COUNT aktivt (lavt). 10

11 Vi skal først se på hvordan vi kan foreta en funksjonell VHDL-simulering av telleren. Dette eksemplet er ment som en første introduksjon til Speedwave og viser langt fra alle muligheter man har der, men én farbar vei. Vi skal senere lære en annen og bedre vei, men den forutsetter bedre kunnskap om VHDL. Når vi har gjort den første simuleringen skal vi fortsette med å ta med samme kode inn i Warp2 og syntetisere og plassere designet inn i CPLD en CY7C374i. Etter dette skal vi kjøre en timing simulering, og når denne har verifisert at kretsen virker som den skal, tar vi å programmerer kretsen. 11

12 Library IEEE; use IEEE.Std_Logic_1164.all; Library CYPRESS; use CYPRESS.std_arith.all; entity FIRST is port( CLK : in std_logic; -- Klokke fra bryter CLK1/INP1 GRESET_L : in std_logic; -- Global Asynkron Reset INP3 : in std_logic; -- Synkron reset COUNT : out std_logic_vector(3 downto 0); -- Telleverdi INP : in std_logic_vector(3 downto 0); -- Startverdi TERM_COUNT : out std_logic; -- Viser telleverdi LEDEN_L : out std_logic -- Enable signal til lysdioder ); end FIRST; -- Arkitekturen under beskriver en 4-bits opp-teller. Naar telleren naar -- maksimal verdi gaar signalet TERM_COUNT aktivt. architecture MY_FIRST_ARCH of FIRST is -- Omraade for deklarasjoner -- For aa faa lysdiodene paa testkortet til aa lyse maa signalene ut vaere -- aktivt lave. Derfor opererer vi med interne signaler med positiv polaritet -- som vi senere inverterer ut paa utgangen. signal COUNT_N : std_logic_vector(3 downto 0):= "0000"; signal TERM_COUNT_N : std_logic := '0'; begin -- Her starter beskrivelsen LEDEN_L <= '0'; -- Maa ha denne lav for at dioder skal kunne lyse COUNTER: process (CLK, GRESET_L) begin if(greset_l = '0') then COUNT_N <= "0000"; elsif (CLK'event and CLK = '1') then -- Synkron reset if INP3 = '1' then COUNT_N <= INP; else COUNT_N <= COUNT_N + 1; end if; end if; end process COUNTER; -- Concurrent signal assignment TERM_COUNT_N <= '1' when COUNT_N = "1111" else '0'; -- Dette er ekvivalent med prosessen --process (COUNT_N) --begin -- if COUNT_N = "1111" then -- TERM_COUNT_N <= '1'; -- else -- TERM_COUNT_N <= '0'; -- end if; --end process; -- Inverterer utsignalene for aa faa lys paa diodene COUNT <= not (COUNT_N); TERM_COUNT <= not(term_count_n); end MY_FIRST_ARCH; 12

13 Klargjøring av simuleringsomgivelsene Speedwave startes som vist i Figure 4. Ved start får vi opp SpeedWave s Console vindu (se figur under). Velg File Analyze VHDL Design. Da åpnes et program som heter HDL-Manager. Dette skal holde styr på VHDL-designene våre. Vi kan da komme rett inn i en Wizard for å sette opp omgivelsene for simulering. Hvis ikke Wizarden dukker opp, kan man få den fram ved å velge Tools Wizard. Velg Next inntil følgende bilde dukker opp. Velg å kalle Working library med det symbolske navnet fys329_rtl. Dette skal fra nå av være lagerplassen vår for VHDL-filer vi skriver og skal simulere funksjonelt (rtl-simulering). Vi skal senere lage et user lib som vi skal lagre VHDL-modeller som er generert på grunnlag av syntese og device fitting, og som vi benytter til timing simulering. 13

14 Nå er tiden inne til å kopiere kilde-filer fra Fys3/4270-websider og over i prosjektdirectoriet. Dette gjøres ikkje med denne programvaren. Bruk Internet Explorer eller lignende og kopier filen oppgave1.zip fra Fys3/4270 hjemmeside. Denne pakkes ut til området beskrevet i library path (dialogen over). Etter trykk på Next i forrige dialog kommer følgende dialog opp: Du kan nå legge til kildefiler (.vhd-filer) ved hjelp av browse-knappen. Vi legger her til filen first.vhd, og går videre med Next-knappen. 14

15 I neste omgang må dere velge system biblioteker. Kryss av for ieee.lib, synopsys.lib, cypress.lib og cyprim.lib og trykk finish. Vi får da dialogen: Som viser at klargjøringen for kompilering (analysering) og simulering ferdig, og vi får opp følgende skjermbilde. Her vil vi komme rett inn neste gang. 15

16 Dette oppsettet lagres ved å velge File Save (evt.save As), og tast inn et navn. Da lages en fil som har extension.hws (hdl workspace file). Litt om Working library Working library eller work har en spesiell betydning i VHDL. Det refererer til VHDL-filer som er under utvikling og uttesting. Det er meget viktig for en VHDL-simulator og synteseverktøy å vite hvilke bibliotek som til en hver tid er working. Vi analyserer, simulerer og syntetiserer alltid på modeller som tilhører work. Vi kan ha mange brukerbiblioteker, men bare ett bibliotek kan være working. I HDL-manager er working library merket med. Det er viktig at simulatoren vet hvilket biblioteket som er satt til working. Når vi velger File Save får vi tillegg til.hws-filen laget et annen fil om heter vsslib.ini. Denne forteller simulatoren hvilke bibliotek som er working og hvilke biblioteker som er med. 16

17 Eksempel på vsslib.inni. c:\fys329\gruppe_jn\fys329_rtl.lib c:\epd\1.1\sim\2000.4\van_vss\win32\pgm\libs\cypress.lib c:\epd\1.1\sim\2000.4\van_vss\win32\pgm\libs\cyprim.lib c:\epd\1.1\sim\2000.4\van_vss\win32\pgm\libs\ieee.lib c:\epd\1.1\sim\2000.4\van_vss\win32\pgm\libs\synopsys.lib Dette betyr at hvis man har flere user lib (og det skal vi ha) så er det meget viktig å lagre.hws og dermed vsslib.ini mellom hver gang man bytter working library. Analysering (kompilering) av VHDL-kode Vi er nå klar til å analysere. Merk filen first.vhd i HDL-manager og velg Analyze Analyze Source File. (Eventuelt høyre musknapp og Analyze). Vi får da følgende bilde: Legg merke til at entiten og arkitekturen til first.vhd nå har kommet fram. Vi har nå fått laget kode som kan simuleres. (Dette er egentlig C++-objektkode moduler). 17

18 Simulering Laste designet inn simulatioren Gå tilbake til SpeedWave vinduet, og velg File Load Design. Velg Library: fys329_rtl.lib og dobbeltklikk. Velg deretter first: Entity, og OK. Da lastes simuleringsobjektet inn i simulatoren og det popper opp to nye vinduer: Et source viewer vindu, som kan benyttes til VHDL source level debugging, og En hierarki browser. Vi skal bare konsentrere oss om hierarki browseren. Denne gir en oversikt over alle elementer som inngår i VHDL-koden, deriblant alle signal navn. Hvis vi dobbeltklikker på first: my_first_arch og deretter Ports får vi fram en liste over alle signalnavn i entiteten first. Klikker vi videre i hierarkibrowseren kan vi få vist alle interne signalnavn osv. Vi skal nå ta utgangspunkt i hierarkibrowseren for å simulere telleren. Det vi nå først er interessert i er å få vist timingdiagram over signalene i entiten. Til dette skal vi benytte plotteprogrammet VWaves (ViewWaves). Vi merker alle signalene i entiten som vist figuren under og velger Signals Display in VWaves. Da startes programmet VWaves opp. Man får spørsmål om å taste inn et navn på vwf (waveform fil), og da kan man velge å benytte fusion.vwf, som foreslås eller noe annet, f.eks. gruppe-x-oy.vwf. 18

19 19

20 For å simulere kretsen må vi påtrykke stimuli på inngangene. Vi har flere måter å gjøre dette på: enten interaktivt eller på kommandolinjen i SpeedWave Console vindu. Resten av eksemplet tar utgangspunkt i simuleringkommandoer tastet inn i console vinduet. Vi skal senere i dette notatet lære hvordan man kan bruke VHDL til å lage stimuli i en såkalt testbench. Når man skal simulere kretser som har klokke 1 er det viktig å si noe om frekvens og dutycycle (prosent høy tid av en periode): Simuleringskommandoene stepsize 50ns og clock / 2 clk 0 1 setter opp en klokke som er stepsize lav og stepsize høy, dvs. en dutycycle på 50% og en periode på 100ns eller en frekvens på 10MHz. 1 Klokke betyr her et signal som har fast repetisjon. Det betyr at klokkeinngangen på en flip-flop ikke nødvendigvis trenger være en klokke. 20

21 I vinduet over trekker vi først greset_l lav, deretter simulerer vi en klokkeperiode (cycle eller c). Vi trekker greset_l høyt og simulerer deretter 16 klokkeperioder. Deretter gir vi en positiv puls på INP3 og simulerer noen perioder. Hvis vi går inn i VWaves og (trykker F4, zoom full) får vi fram følgende bilde: 2 / betyr toppnivået i et hierarki. I et hierarki kan vi f.eks. ha navn som heter /Adder/sum, der Adder er navnet på en entitet. 21

22 VWaves viser timing diagrammer. Vi kan måle tidsforsinkelser, zoome inn områder, og vise signaler på forskjellige format. F.eks. hex, oktalt, ascii-verdi eller tokomplement. I bildet over har vi zoom et inn et område og målt tidsforsinkelsen fra positiv flanke på klokken clk til omslag på telleren. Denne er null, fordi vi har en ren funksjonell simulering og vi har ikke lagt inn tidsforsinkelse i koden vår. (Man legger normalt ikke tidsforsinkelser inn i kode som skal syntetiseres. Om man gjør det så vil uansett synteseverktøyet neglisjere dette). Når man går ut av VWaves blir det lagret to filer, som vi vil ha som en del av innleveringene av obligatoriske oppgaver: Hvis vi sier at vi kalte vwf-filen for oppg1.vwf blir det også lagret en fil som heter oppg1.tra (trace-fil). Disse to filene er helt nødvendige hvis man skal få vist en gammel simulering i VWaves. I innlevering av oppgaver skal dere bruke navnekonvensjonen gruppe-x-oy.vwf og gruppe-xoy.tra. X er gruppenummereret deres og oy er oppgave nummer y. Filene som sendes til oss skal være pakket i zip-format. For eksempel med programmet Winzip. Bruk av kommandofiler Siden utvikling av VHDL-modeller er en prosess med ofte mange iterasjoner, kan det bli svært kjedelig å taste inn de samme kommandoene hver gang man tror at den endelige løsningen er der. Da er det mer hensiktsmessig å samle simuleringskommandoene i en kommandofil, og isteden kjøre denne hver gang man vil simulere på nytt. En simulerings kommandofil skal ha extension.cmd. Under er vist innholdet i kommandofilen first.cmd. 22

23 Sørger for restart av simulator restart Åpner VWaves fil first.vwf med følgende signaler som skal vises wave first.vwf "/CLK" "/GRESET_L" "/INP3" "/INP" "/COUNT" "/COUNT_N" "/LEDEN_L" "/TERM_COUNT" Følgende kommandoer gir en klokke på 10Mhz stepsize 50ns clock "/clk" 0 1 gir asynkron reset puls l "/greset_l" l "/INP3" tilordner hex-bryter S1 verdien 8hex (a = assign) a "/INP" 8\h Går et stepsize fram i tid (s = step) s trekker reset høy h "/greset_l" cycler 16 klokkeperioder (c = cycle) c 16 simulerer 25ns sim 25ns gir synkron reset h "/INP3" c l "/INP3" c 5 Vi skal etterhvert lære mer om simuleringskommandoer. Se ellers online hjelp og Digital Fusion User Guide og VWaves Users Guide., som er tilgjengelig under den flytende programgruppen til Workview Office eller på Fys 3/4270 sine hjemmesider. VHDL-Testbench En annen måte å lage stimuli på er å lage en VHDL Testbench. Det betyr at vi lager alle stimuli input i VHDL istedenfor å benytte simulerings kommandoer. Dette gir mange fordeler, bla. at simuleringen kan portes over på en annen standard VHDL-simulator, fordi man ikke blir avhengig av simulatorens kommandospråk. Å benytte VHDL testbench er dessuten mye mer fleksibelt enn å benytte kommandofil fordi man har hele VHDL språket til 23

24 rådighet. Bl.a. kan man inkludere mye av omgivelsene (andre komponenter, evt et helt kort) i testbench en. Eksemplet under forutsetter at man har lært en del VHDL, bl.a. om komponent instansisering, men vi velger å ta det med her for å vise en mal for hvordan man kan lage en enkel testbench. Vi skal komme tilbake senere med mere avansert bruk av testbench er. 24

25 Library IEEE; use IEEE.Std_Logic_1164.all; Entity TEST_FIRST is -- generic parameters -- port list -- Entiteten for en testbench er gjerne tom end TEST_FIRST; architecture TESTBENCH of TEST_FIRST is -- Område for deklarasjoner -- Komponent deklaration Component FIRST port( CLK : in std_logic; -- Klokke fra bryter CLK1/INP1 GRESET_L : in std_logic; -- Global Asynkron Reset INP3 : in std_logic; -- Synkron reset COUNT : inout std_logic_vector(3 downto 0); -- Telleverdi INP : in std_logic_vector(3 downto 0); -- Startverdi TERM_COUNT : inout std_logic; -- Viser telleverdi LEDEN_L : inout std_logic -- Enable signal til lysdioder ); end Component; signal CLK : std_logic := '0'; signal GRESET_L : std_logic := '1'; signal INP3 : std_logic := '0'; signal COUNT : std_logic_vector(3 downto 0) := "0000"; signal INP : std_logic_vector(3 downto 0) := "0000"; signal TERM_COUNT : std_logic := '1'; signal LEDEN_L : std_logic := '1'; signal COUNT_TEST : std_logic_vector(3 downto 0) :="0000"; constant Half_Period : time := 50 ns; begin -- concurrent statements --Instantierer "Unit Under Test" UUT: FIRST port map ( --formal param=> actual param CLK => CLK, GRESET_L => GRESET_L, INP3 => INP3, COUNT => COUNT, INP => INP, TERM_COUNT => TERM_COUNT, LEDEN_L => LEDEN_L ); -- Definerer klokken CLK <= not CLK after Half_Period; -- Inverterer telleverdien for å se riktig tall i klartekst COUNT_TEST <= not COUNT; STIMULI: process begin GRESET_L <= '0', '1' after 100 ns; INP <= "1010" after Half_Period*12; wait for 2*Half_Period*16; INP3 <= '1', '0' after 2*Half_Period; wait; end process; end TESTBENCH; Testbenchen analyseres til "working" library. Dette gjøres ved å aktivere VHDL Manager 25

26 vinduet, velge t_first.vhd og Analyze Source File. Deretter aktivers Speedwave consolen. Her velges menyen File Load Design. Se figuren under P.g.a. at instansen av first i testbenchen er avhengig av entiteten first i first.vhd er det viktig at testbenchen analyseres sist ellers vil man få en feilmelding ved lasting av designet i simulatoren. Man kan deretter starte en simulering ved å først velge hvilke signaler man vi studere og deretter f.eks: SIM>sim 200ns. 26

27 Hvordan komme i gang med Warp2 Oppretting av prosjekt i Warp2. Start Galaxi, som er Warp2 s grafiske interface. Da kommer man rett inn i forrige aktive prosjekt. Trykk File New. Da kommer man inn i en prosjekt wizard som leder oss gjennom en del viktige valg: Target. Prosjekt navn og directory VHDL-kildefil(er) Målteknologi Vi trenger ikke å gjøre alle valgene med en gang ved å trykke finish. Man kan alltid gjøre om alle valg inne i Galaxi vinduet. I det første valget velg Project(Target-Device), fordi alt vi gjør skal rette seg mot en spesiell krets. 27

28 Da får man valget om å taste inn ett nytt prosjekt navn eller å bla browse. Velg å bla til directoriet hvor man laget Workview Office prosjektet. Da sørger man for å ha alle prosjekt filer på samme området. Trykk Next for å velge kildefil: first.vhd. 28

29 Trykk next for å velge Target device. Det er meget viktig at vi velger rett krets. I kurset skal vi benytte en krets fra Flash 370I familien: CY7C374I-66JC. 29

30 Syntese og device fitting Kildefiler Når man skal syntetisere en VHDL-fil (eller mange) må man først bestemme seg for hvilke VHDL-filer som skal være med. I dette første eksemplet er det bare en, og den heter first.vhd. Senere vil det være flere filer som skal være med. De kan velges ved å gå inn i menyen Project Add Files. Da er man klar til å redigere og/eller syntetisere. På dette punktet er det viktig å si at Warp2 har en relativt god VHDL-editor, som det anbefales å benytte. Det kan nevnes at den har Chromakoding av alle VHDL nøkkelord og den har mal for alle typer VHDL-setninger, en VHDL-browser. Denne kan være et nyttig hjelpemiddel nå når VHDL er nytt og man har problem med rett syntaks. Prøv denne. Videre har editoren kraftige kommandoer for å kommentere ut et område som man merker eller fjerne kommentarer. Vi sier nå at VHDL-filen er ferdig redigert og simulert i SpeedWave, og den skal være klar til å syntetiseres og plasseres i en Cypress-kretsen vi valgte. Device (Teknologivalg) Hvis vi ikke valgte krets under oppretting av prosjektet må vi gjøre det nå (Project Select Device). Kretsen vi benytter på kurset er en C374I device. Den finnes i en rekke varianter og den typen vi har heter CY7C374I-66JC. Det er meget viktig at disse valgene gjøres riktig. Når dette er gjort vil vi se på Project Compiler Options. Da får man følgende bilde fram og her er det en rekke valg: 30

31 Bl.a. spenningsnivå på I/O signalene. Vi benytter 5.0V, men CY7C374 har også mulighet for å benytte 3.3V I/O og 5V internt. Da må den kobles opp med egen 3.3V strømforsyning til I/O, og det er ikke gjort på testkortet. Dette kan være en nyttig fasilitet dersom den skal benyttes i 3.3V omgivelser. Output kan stå med ubenyttede utganger satt til tristate eller Z, som det står. En mulighet som vi skal benytte mye er å simulere designet i SpeedWave etter at designet er syntetisert og plassert i kretsen. Resulatet av en syntese og plassering (eller fitting som det heter i CPLD terminologi) er alltid en Jedec-fil. Dette er en filtype som har blitt benyttet siden PAL ene sine dager og inneholder et såkalt fusemap. Altså et kart over hvilke sikringer som skal brennes for å skape de rette forbindelsene for å implementere den logikken vi ønsker. Warp2 kan generere en rekke filtyper ut fra Jedec-filen som kan benyttes til å simulere det ferdige syntetiserte og plasserte designet for å verifisere funksjonalitet og timing. Som man ser har man en rekke valg for Post routing simulering, slik at man lett kan bytte benytte andre simulatorer. Siden vi benytter SpeedWave velger vi Post-JEDEC Sim: SpeedWave. Tech mapping valgene bør stå som de gjør i bildet over. Vi skal komme nærmere inn på dem senere, når vi skal snakke om syntese og syntese direktiver. Vi har også valg for å styre i hvilken grad syntesen skal optimalisere logikken. Målet for syntesen kan for eksempel være å oppnå en kompakt implementasjon eller optimal hastighet. Vi skal snakke mer om dette under syntese og syntese direktiver senere. Hvis vi skal simulere i SpeedWave etter syntese og plassering, er det meget viktig å velge Enable Testbench Output. Vi har også noen valg som går på rapportering. Ikke velg detailed report. Som vi var inne på, kan vi få Warp2 til generere en Post-JEDEC simuleringsfil på SpeedWave format. Dersom vi ikke velger Enable testbench output, vil Warp lage en Post- JEDEC VHDL-fil som har en entitet som er veldig forskjellig fra entiteten i den opprinnelige VHDL-filen. Det betyr at SpeedWave kommandofiler som man benyttet til å simulere den opprinnelige VHDL-filen funksjonelt, ikke kan benyttes. Dette fordi signalnavnene ikke vil bli de samme. Hvis man har sett på interne signal navn i SpeedWave kan man ikke regne med å se disse i en Post-JEDEC simulering. De er helt sikkert blitt fjernet i det ferdig implementerte designet som et resultat av optimaliseringer. Det betyr at i Post-JEDEC simuleringer er det mest hensiktsmessig å se på ytre signaler som går til en pinne. Vi kan i utgangspunktet benytte de valgene som er foreslått over. Kontroll av hierarki I dette første eksemplet har vi bare en VHDL-fil som er hele designet vårt. Senere skal vi utnytte VHDL s sterke fasiliter til å lage hierarkiske design, der gjenbruk av komponenter og bruk av biblioteker blir sentrale elementer. Uansett er det viktig for syntese verktøyet å vite hvilke VHDL-fil som er topmodulen. Topmodulen er den entiteten i designet som skal tilordnes komponentpinner. I vårt eksempel er det first.vhd som er topmodulen. Vi får valgt denne som topmodul ved å merke filen, trykke på høyre musknapp (for å få fram context sensitive meny) og velge Set top. 31

32 Tilordning av pinner Ideelt sett skulle det bare være å sette i gang en syntese og plassering, men så enkelt er det ikke. Vi har en bibetingelse i vårt design som vi i høyeste grad må forholde oss til, og det er viktig at vi forholder oss riktig til dette også, ellers kan vi risikere å ødelegge kretsen: Nemlig det faktum at designet skal implementeres på en krets som står montert på et ferdig kort slik at all pinneplassering er låst fast. Dette er ideelt sett en uønsket situasjon fordi det viser seg at pinneplasseringen er meget viktig for hvor effektivt designet kan implementeres og sin ytterste konsekvens om det er mulig å implementere designet i det hele tatt når vi har låst pinnene. Vi skal se eksempler på at det ikke lar seg gjøre. Det ideelle er om Warp2 selv får bestemme pinneplasseringen, og at man benytter dette forslaget senere. At pinneplassering er gjort på forhånd er imidlertid ofte situasjonen i virkeligheten, fordi man gjerne ønsker at utlegg av kort og utvikling av programmerbar logikk skal være en parallell aktivitet for å spare tid i prosjektet. Derfor skryter mange programmerbar logikk produsenter av 100% pin-locking capability. Dette er imidlertid noe man skal ta med en klype salt. Det kan godt hende at designet lar seg realisere, men det er ikke sikkert at man får oppfylt timing krav. En ugunstig pinneplassering går ofte ut over ytelse. Dette gjelder spesielt for FPGA er. 32

33 Siden pinneplasseringen er gitt for oss må vi kontrollere dette. Dette gjøres ved å bruke en kontrollfil der signaler fra top-nivå entiteten tilordnes riktige pinnenummer. Kontroll filen skal ha samme navn som top-nivå VHDL-filen og extension.ctl, og denne må ligge lagret i samme directoriet, altså prosjektdirectory et. Sørg alltid på dette kurset for at denne filen eksisterer og er riktig. Det verste vi kan oppnå ved feil bruk/ikke bruk av denne er at utgangssignaler blir tilordnet samme pinnenummer som vi har koblet til bryterne våre. Da kan vi få motdriv. Dette kan ødelegge kretsen eller i beste fall føre til at ingenting vil virke. I dette først eksemplet har vi top-nivå entiteten som vist i figuren under, og vi skal nå tilordne den pinner. Siden pinneplasseringen er gitt for oss må vi kontrollere dette. Dette gjøres ved å bruke en kontrollfil der signaler fra top-nivå entiteten tilordnes riktige pinnenummer. Vi ønsker å bruke trykknappen CLK1/INP1 som klokke. Vi ser av skjemaet at denne er koblet til pinne nr. 23. Videre ønsker vi at G_RESET_L tas fra RESET knappen, som er koblet til pinne nr. 46. Utgangene fra telleren ønsker vi å vise på de fire lysdiodene til høyre, med mest signifikante bit til venstre. Dette gir oss pinnenummerene: 79,80,81 og 82. Term_Count signalet ønsker vi å vise på lysdiode D8 helt til venstre. Dette gir oss i følge skjemaet pinnenummeret 3. LEDEN_L må gå til pinne 69, fordi denne styrer transistoren som muliggjør tenning av lysdiodene. Korrekt kontrollfil first.ctl er vist under: 33

34 Merk at std_logic_vector en COUNT er delt opp i de enkelte elementer: COUNT(3), COUNT(2),...,COUNT(0). Når vi først har fått laget denne kan vi få vist den ved å velge merke first.vhd (topnivå filen), trykke høyre musknapp og velge control file. Dette er samtidig en god kontroll på om vi virkelig har laget en kontrollfil og om den har rett navn. 34

35 Kompilering Når vi nå har tilordnet pinner korrekt er vi klare til å syntetisere og plassere designet. Vi velger Compile Selected. Under kompilering får man fram et statusvindu som viser hva som skjer: Hvis alt gikk bra kan vinduet se slik ut. Hvis ting ikke gikk bra får man som regel klar beskjed om hva som gikk galt. De henvises til Warp2 User Manual og Warp2 reference guide for dokumentasjon om feilmeldinger. Disse er lagt ut som pdf-dokumenter på Fys3/4270 hjemmesiden. Vi ser at en del av prosessen er å linke inn nødvendige biblioteker, optimalisere designet ut fra kriterier vi har gitt (area, speed f.eks), minimalisere boolske ligninger. Disse prosessene er selve syntesen, og her kan man se at samme prosessen gjentar seg, dvs. syntesen kan være en iterativ prosess. Etter at syntesen er ferdig går prosessen over i å plassere (device fitting) det syntetiserte designet over i den kretsen vi har valgt. Når dette er ferdig har vi fått laget jedec-fil. I vårt tilfelle ville vi også lage Post-JEDEC simuleringsfil i SpeedWave format, og vi ser at en egen prosess for dette kjører til slutt. 35

36 Resultatfiler Når denne prosessen er ferdig får vi generert diverse resultat filer. De viktigste for oss er: Jedec-filen Rapportfilen SpeedWave Post-JEDEC simuleringsfil Jedec-filen Jedec-filen (i dette tilfellet first.jed), som vi ikke trenger å se på hvis vi ikke er spesielt interessert, men som er grunnlaget for å programmere kretsen. Rapportfilen Det blir alltid generert en rapportfil som har extension.rpt (i dette tilfellet heter den first.rpt). Denne inneholder viktig informasjon om syntese og fitting prosessen, bl.a. alle boolske ligninger, hvordan designet er plassert, timinginformasjon og pinneplassering. Vi kommer tilbake i detalj om denne når vi skal snakke om syntese. Det viktigste for oss i denne omgang er å få verifisert at pinneplasseringen er korrekt. Vi kan se på rapportfilen ved å topnivå-filen, høyre musknapp og velge report-file (tilsvarende slik vi fikk se på kontrollfilen). Informasjon om pinneplassering finnes et godt stykke ned i filen. Figuren under viser et utdrag av dette: 36

37 Verifiser alltid pinneplasseringen opp mot kontrollfilen før dere programmerer en krets. SpeedWave Post-JEDEC simuleringsfil. Denne får samme navn som den opprinnelige VHDL-filen (top-nivå filen) og blir plassert i underdirectory et.\vhd av prosjektdirectory et. Under er vist et utdrag av denne filen. Legg merke til at SpeedWave filen har samme entitet som den opprinnelige VHDL-filen. Eneste forskjellen kan være (trenger ikke være) at enkelte signaler som er definert som outsignaler i den opprinnelige filen, kan være forandret til type inout. Dette henger sammen at disse utsignalene er routet tilbake fra pinnen og inn i kretsen for å inngå som del av de boolske ligningene. Dette skal vi ta opp nærmere når vi går igjennom arkitekturen til CPLD en. 37

38 Så lenge vi skal simulere ved bruk av kommandofil i SpeedWave vil ikke dette by på problemer, men dersom vi skal simulere ved bruk av Testbench, må vi ta hensyn til dette. Dette siste kommer til å bli tatt opp i detalj på forelesninger senere. Legg også merke til at det blir deklarert en masse interne signalnavn. Navnene på disse er langt fra eventuelle interne navn vi har deklarert i vår opprinnelige kode, slik at å få vist f.eks. timingdiagrammer over interne signal fra opprinnelig kode vil være nesten umulig i en Post- JEDEC simulering. Hvis dere blar videre nedover i simuleringsfilen vil dere se den inneholder en masse timinginformasjon, og VHDL-koden er skrevet på en form som har simulering som mål. Timing simulering i SpeedWave Opprett brukerbiblioteket med symbolsk navn fys329_tim. Dette settes til working ved å klikke på biblioteks navnet. Velg File Assign source file og bla fram til filen.\vhd\first.vhd. Analyserer og lagre hws-filen etterpå. 38

39 Når dere nå laster designet inn i Speedwave ser at working er satt til fys329_tim.lib Som før velger dere entiten test_first, men legg merke til at den har nå en helt annen arkitektur. Simuleringen kan nå kjøres ved å benytte kommandofilen t_first.cmd. Figuren under viser samme simuleringsutsnittet som under den funksjonelle simuleringen. 39

40 In-Circuit Programmering (Re-programmering) For å få programmert Cypress-kretsen må programmeringsadapteret (Merket: ISR programming cable) kobles til parallelporten på en PC med MS-DOS eller Windows 95 som operativsystem i ene enden og til konnektoren på testkortet merket med J2 og ISR probe på testkortet. Når man programmerer må spenningen til testkortet være slått på. For å programmere benyttes et eget program, ISR. Dette startes innenfra Galaxi i menyen Tools ISR Programmer Software. Programmering av Cypress CPLD er foregår etter en standard som kalles JTAG eller IEEE1149, Boundary scan. Dette er egentlig en standard for å teste forbindelser mellom komponenter på kretskort, men benyttes også mye til å programmere kretser in circuit. F.eks. benytter Altera og Xilinx også denne standarden. Før vi starter programmeringen må vi konfigurere litt. Velg File New. Det er viktig at Number of Devices in the JTAG chain er satt til 1, fordi vi skal programmere bare en krets. Etter dette må vi sette inn informasjon om hvilken device, operation og jedec filnavn. Når dette er gjort må vi komponere en JAM 3 -fil Operations Compose JAM Files. 3 JAM er en standard filformat for In-Circuit Programmering utviklet av Altera 40

41 Når vi skal programmere velger vi Operations Play JAM Files. Dersom programmeringen gikk bra kan vi få fram et vindu som under. Cypress garanterer at kretser fra CY370I-serien kan reprogrammeres minimum 100 ganger. Siden det er en øvre grense for hvor mange ganger kretsene kan programmeres er det viktig at vi simulerer godt og ikke programmerer før vi er sikre på at kretsen virker som ønsket. 41