Helt sant att det går att använda pipeline med variable också. Hade otur när jag tänkte/förklarade!
Dock får man tänka till lite när man tilldelar och använder variable / signaler mm eftersom det skiljer vilket värde som används. T.ex. har man en klockad signal och du använder den i en process så vet du att värdet på signalen är det som beräknades i föregående klockcykel. För variabler så sker tilldelningen "omedelbart" i den bemärkelsen att resultatet sker direkt för satser som ligger efter tilldelningen i processen och använder variabeln.
Det gäller bara att hålla tungan rätt i munn så funkar det!
Korken skrev:Dock, vad för krav ställs på signalerna in/ut för att de ska vara kompatibla med "variable"?
Måste man ha signed / unsinged eller hur funkar det då?
Det är inget speciellt med typerna på en variabel, samma regler gäller som om du skulle använt en signal.
Mao, om du t.ex. har en unsigned in-port på modulen så bör du använda typen unsigned
(eller omvandlingsfunktioner) på variabler som tilldelas signalen.
Jag fick en fundering när jag kollade på koden för magnitude_est på förra sidan som handlar om process.
Just i den har jag signalerna som "driver" allt i sensitivity listen, men inte input signaler.
Ska input signaler som "bara" är värden vara med i den eller bara de signaler som "driver" allt?
Som i den är det clk och rst som den ska reagera på, men blir lite osäker.
Angående sensitivity list:
De signaler som ska göra att processen "aktiveras" ska vara med i sensitivity list. I ditt fall vill du bara att klockan ska styra när signaler uppdateras. Exempel: Hade du haft asynkron reset av dina signaler, alltså att de ska resettas oberoende av när i klockperioden man befinner sig så skulle resetsignalen vara med i sensitivity list. Om du däremot vill ha synkron reset, alltså att resetsignalens värde bara spelar roll på en klockflank, så ska inte resetsignalen vara med i sensitivity list. I FPGAer bör man i de flesta fall eftersträva att ha synkron logik (och synkron reset) så oftast har man bara klockan i sensitivity list. Det finns massor av undantag, t.ex. när man har med olika typer av interface-handskakningar att göra, eller vid vissa typer av klockövergångar, mm.
Angående att använda variabler för att skapa register/pipelines:
Det är fullt möjligt att använda variabler för att skapa register, men jag skulle avråda från det. Koden blir oftast tydligare om man använder signaler och man riskerar inte att beteendet ändras bara för att man t.ex. byter plats på två rader i koden. Det är även lättare att följa vågformer i simulatorer om man vet att värdet bara ändras EN gång i en klockad process. (Signaler får sitt värde när processen har löpts igenom, variabler kan ändra värde flera gånger i en process.)
Det finns olika skolor när det gäller variabel-användandet, men jagförespråkar att man bara använder dem för att spara mellanresultat som sedan i slutändan tilldelas till en signal så variablerna inte "koms ihåg" till nästa varv i processen. Anledningar att ha variabler kan vara för att förtydliga koden, speciellt om man har flera typkonverteringar på vägen i en uträkning.
Till sist, angående overmapped på IOB:
XST anser väl att normalfallet är att man vill syntetisera en komplett konstruktion som ska mappas till en FPGA, då är det bara kretsens IOn som är alternativet för in- och utdata. Om det inte redan nämnts i tråden så finns det en parameter att ställa nånstans som styr om detta ska göras eller inte. Jag kommer inte ihåg vad den heter, det var några år sedan jag körde XST senast.
Dags igen för en ny fråga inom VHDL (och FPGAer in general)!
Jag har lekt med att skapa massa klockor osv och det är två frågor som har kommit till mig:
1) I en tutorial serie jag kollade för ett tag sedan ( så används räknare ganska flitigt som "clock dividers".
Dock jag läste någonstans att detta är dåligt (kommer tyvärr inte ihåg vart ifrån jag läste detta), så tänkte kolla här.
Varför är detta dåligt? Vad är den generella praxisen när det kommer till klockgenerering i FPGAer? Alltid köra med en "Clock Manager"?
2) Det andra som jag ramlade över är, hur ska man göra om man ska koppla i hop två domäner med olika klockhastighet?
Tex så har jag en domän som arbetar på 26.6 MHz (kamera avläsning) och min "mattematik"-domän som går i 200 MHz.
Mellan dessa vill jag flytta 10 bits per kamera-klockcykel, från kameran till matte-domänen.
Vad ska man tänka på när man gör detta? Kan tänka mig att alla typer av cool and wonderful stuff kan hända när man börjar blanda klockor.
Jag har googlar men får bara upp 500 sidors datablad om hur hela klockdomäner fungerar, dåligt med praktisk info vad jag kan hitta.
Det enklaste är att lägga en klockdomän exakt heltal snabbare dvs 26,6 MHz x 7 = 186,2 MHz eller för den vågade 26,6 MHz x 8 = 212,8 MHz. När man har heltalsdivisioner mellan klockdomäner så kan man helt enkelt förutsätta att data bara finns där vid en viss tidpunkt. Samt låta den snabba klockdomänen styra den långsammare direkt via nedstegning. Eller om det kniper använda DCM (faslåsningsöverklockning) så att den lägre klockade domänen styr den snabbare.
I övrigt spara data i ett register. Sätt en flagga "värde lämnat". Nästa domän startar då flaggan är satt och kan då läsa registret samt nollställer flaggan. Repeat ad infinum.
Det absolut enklaste och kraftfullaste sättet är "dual-clock fifo". Då slipper du mycket special logik och de är designade att klara full speta på klockorna.
Finns att läsa om i bland annat: http://www.xilinx.com/support/documenta ... ources.pdf
