Hvordan analysere 2 programmer i Xinlinx ISE5

[nokamil]

Jeg lagde 2-programmer (både i VHDL) i 2 forskjellige måter på Xilinx ISE5 for spartansk serierekke å gjøre det samme.Nå vil jeg vite hvilket program som mer effektive.Effektiv på en måte, som tar mindre antall porter.Hvordan kan jeg finne ut dette effektivitet.Plus jeg ønsker også å vite at hvordan programmene er analysert det som er gjort på en bedre måte.Selv om begge fungerer bra.

 

[oppr]

se på resultatet av syntese.Du får informasjon om den kritiske bane og hvor mange ressurser som er nødvendig

 

[elektrom]

Se RTL Skjematisk etter syntese, kan forstå hvordan du design er implementert på FPGA.

 

[bibo1978]

Hvis du har gjort en god begrensningen fil deretter lese innlegget PAR følge rapportene du har 4 hoved rapporter "hvis du ikke bruker mulriple banen ruting" disse rapportene er PAR rapport Asynkrone utsette rapporten, PAD rapporten og PAR statisk timng rapporten.
den PAR rapporten vil gi nøyaktig hvor mye did designen tok av theFPGA "slice telle, PAD, memoriess ..."
puten rapporten vil gi deg informasjon om Pins assignement steder i FPGA, volage standard, forsinkelse elementer hvis noen, IOB flip flops, slew rate ...
Asynkrone utsette rapporten vil gi deg en detaljert info.om asynkron tid hver net tar før det kommer en synkron element "flip flop, minne" denne forsinkelsen er ikke relatert til klokke, betyr at denne rapporten bare forteller deg hvor mye tid det tok fra X til Y
Til slutt vil du ha den statiske gang rapport som viser frekvensen som denne PAR har scoret og hvis det er noen unmet begrensningen vil du finne detaljert informasjon om ruten på signalet "kritisk sti"
Hvis PAR kan ikke scorer målet og deretter prøve å legge noen begrensninger "u kan ikke tro hva plasseringsmålrettet begrensninger kan gjøre"
Du kan selv gjøre en gulvplan til design "jeg ikke ønsker at det er en tidkrevende metode, men du har ingen annen måte"

Men alle de ovenstående ikke er nok for store design kan du gjøre din egen timing analyse om ønskelig, men først kan du bruke Innlegg PAR modell med standard forsinkelse fil "SDF" til resimulate utforming så hvis du ikke treffer target forsøker å gjøre en analyse gjennom innlegget PAR timing analyseverkøyet og du kan legge noen begrensninger over noen garn "tråder".
Hvis du fortsatt ikke kan innfri kravene gå tilbake til design "HDL code"
og prøve å analysere årsaken til forsinkelsen "vanligvis den grunn er ikke den kritiske banen, dvs du kan gjøre endringer på den kritiske banen som introdusere et annet kritisk sti" men noen ganger er kritisk banen analyse kan løse prolem.
Hvis problemet presists kan du slappe av dine krav "hvis systemet kan akseptere"
Hvis systemet ikke godtar slik behandling har du til å søke etter en annen tilnærming "algoritme" "alt det du har gjort er borte"
Trist, men sant: (
Men alltid pipelining vil løse noen problemer "fortsatt pipelining må være rimelig,
dvs. det er et punkt der mer rørene ikke kan tolereres"

dvs all folks