rom størrelse på FPGA er et problem

[jenardo]

Hej alle,
Jeg held anvendt en V2Pro Development Board til at udvikle en 8051 og CAN-system på chippen.Jeg brugte Keil software for at få et hex fil derefter omregnes den til en rom fil i 8051.Alt dette var en succes.

ROM brugte jeg havde en 16-bit adresse og 32-bit ord.Det er skrevet af koden som følger:
altid @ (posedge CLK)
begynd
sagen (adr)
16'h0: data_out <= 32'h12345678;
16'h1: data_out <= 32'h12345678;
......
......
Standard: data_out <= 32'h0;
endcase
ende

Det virkede fint i små programmer til at teste min IP.
Da jeg fik den hex fil for chauffører og omdannet det til rom fil, den nåede op på en adresse på 16'h108D ....hvilket er omkring 4K-ord.
Under kortlægning, 129 ud af 44 blokere RAMs blev brugt ...og så processen ikke fortsætte, fordi FPGA er ikke nok plads.

Jeg har ændret følsomhed liste til "adr" i stedet for "posedge CLK".Dette resulterede i distribueres RAM bliver brugt i stedet for at blokere RAM.Og stadig havde jeg et problem med størrelse for overmapping af LUTs.

Her er mine spørgsmål:
1 - Er en 4K * 32 bits rom for stor i størrelsen??
NB: KAN og 8051 anvendte kun 50% af FPGA (xc2vp7-6fg456)
2 - Er det virkelig en størrelse problem eller er det en forkert kortlægning foretaget af værktøjet?
3 - Hvis størrelsen er problemet, kan den indbyggede flash PROMs (bruges til programmering af FPGA) anvendes som rommer?
4 - Jeg har brug for en løsning på dette problem.

<img src="http://www.edaboard.com/images/smiles/icon_biggrin.gif" alt="Very Happy" border="0" />Tak for alle i forvejen.

 

[banjo]

OK,

På spørgsmål # 1, hvorfor er den ROM 32 bit bred, når 8051 er en 8 bit enhed?Uanset den Virtex2 blokere RAMs er 2K med 9 bits.Selv hvis du kaster måde paritet bit, dette 4KX32 rom bør kun bruge, 8 blok RAMs.Da compiler synes at være at bruge meget mere RAM end dette, er det fejlfortolker dit design.Du kan åbne design med FPGA Editor og derefter forsøge at finde ud af hvorfor så mange flere blokere RAMs bliver brugt.Mest sandsynligt, at data bliver spejlet på tværs numberous RAMs fordi compileren mener enkelte moduler behovet for uafhængig kontrol.
For at rette dette,
er du nødt til at tage eksplicit kontrol af rom gennemførelse.Åbne CoreGen og bruge det til at angive din ROM.Dernæst, efter du får rom defineret med et rimeligt beløb af blok RAM, gemme det som et separat modul.Denne separat modul vil derefter blive instantieres som en "black box" i dit design og compileren vil ikke længere er nødt til at gætte, hvordan du konfigurerer din hukommelse.

 

[echo47]

Det er gode forslag.

Hvis du bruger XST, også henvise til din "XST Brugervejledning", kapitlet "HDL varenomenklatursystem Techniques", afsnittet "RAMs og rom'er".Det viser, hvordan man skriver Verilog så XST korrekt udleder en ROM anvender Block RAMs.

Du kan også direkte instantiate en RAMB16 og initialisere det med defparam erklæringer.Det
er beskrevet i din ISE "Biblioteker Guide".