Vraag:
Waarom is deze Verilog RAM-wijziging beter in termen van resourcegebruik?
Hugo Sereno Ferreira
2019-12-24 05:36:22 UTC
view on stackexchange narkive permalink

Ik gebruik de open-source toolchain Yosys > NextPnr > IcePack voor het synthetiseren van code voor de Lattice HX8K FPGA. Hier is een algemene versie van een 1Kb RAM (die ik gebruik als video-RAM voor een VGA-module): 

  module text_ram # (
    parameter A = 10,
    parameter D = 8
  ) (
    input clk,
    input wij,
    ingang [A-1: 0] adres,
    ingang [D-1: 0] din,
    output reg. [D-1: 0] dout
  );

  reg [D-1: 0] vram [0: (1<<A) -1]; // 2 ^ Een geheugenruimte van D-bits

  eerste
    $ readmemh ("lib / video.hex", vram, 0, 1024);

  altijd @ (posedge clk) beginnen
      if (we) vram [addr] < = din;
      dout < = vram [addr];
  einde
eindmodule

Door de bronnen te analyseren met icebox_stat (naast alle andere logica die ik heb; sorry, maar ik weet niet hoe ik de statistieken voor een enkele component moet isoleren), rapporteert het: 

  DFF's: 21
LUTs: 204
DRAAGT: 26
BRAMs: 3
IOB's: 4
PLL's: 0
GLB's: 3

Nu, met deze eenvoudige wijziging (die, toegegeven, dout anders maakt, maar oké voor mijn beoogde doel): 

  altijd @ (posedge clk)
      if (we) vram [addr] < = din;

  altijd @(*)
      dout < = vram [addr];

Het rapporteert: 

  DFF's: 21
LUT's: 151
DRAAGT: 26
BRAMs: 0
IOB's: 4
PLL's: 0
GLB's: 1

Het zijn niet alleen 53 minder LUT's, maar wat me echt verbaast, is dat het BRAM-gebruik verdwenen lijkt! Kan iemand me uitleggen waarom? En hoe kan ik dergelijke gevallen inspecteren om er zeker van te zijn dat ik de onderliggende beslissingen van Yosys en NextPnr begrijp ?

Twee antwoorden:
Peter Green
2019-12-24 06:42:55 UTC
view on stackexchange narkive permalink

Zoals Joshua zegt, is er hier duidelijk iets mis.De synthesetool heeft uw geheugen duidelijk geoptimaliseerd.

Na een snelle inlezing van het ice40 blockram lijkt het een geregistreerde output te hebben, dus als de output combinatorisch zou worden gemaakt, zou de tool gedwongen worden om een groot aantal registers te gebruiken in plaats van een blockram.

Hier een beetje speculeren, maar ik vraag me af of readmemh alleen werkt op dingen die de synthesetool kon afleiden als blockram, en niet op "grote brokken registers".

Een andere mogelijkheid is dat je bent vergeten om een aantal van de inputs en / of outputs correct aan te sluiten.Met de agressieve optimalisatie die synthesetools doen, kun je het gebruik van bronnen niet echt testen zonder een functioneel ontwerp.

Eigenlijk bent u ter plaatse;BRAM-inferentie heeft geregistreerde uitvoer nodig.Door mijn uitvoer combinatorisch te maken, heeft de `$ readmemh` mijn bestand zojuist in een reeks LUT's geladen.Omdat ik daar zoveel nullen had, werden de resulterende LUT's eigenlijk lager dan de logica die nodig was om toegang te krijgen tot BRAM.En omdat mijn testontwerp niet probeerde om daadwerkelijk * naar het geheugen te schrijven *, eindigde ik in feite met een soort ROM.Zodra ik meer dingen in `lib / video.hex` stopte, ging het aantal LUT's flink omhoog!Les geleerd...
Nu je meer details hebt gegeven, kunnen we reconstrueren wat er is gebeurd, ten eerste omdat je het combinatorisch hebt gemaakt, de synthesetool gedwongen werd om registers te gebruiken in plaats van bram, en omdat je geen schrijfactiviteit had, konden die registers worden geoptimaliseerd en vervangen door constante waarden.Dan, vanwege de nullen in uw gegevens, kan de leesmux grotendeels worden geoptimaliseerd.Aan het eind van de dag was er nog maar weinig over.
Het verbaast me dat de eerste instructie en bestandsbewerkingen zoals $ readmemh worden geëvalueerd door de synthesetool.Als ik het me goed herinner, negeert Synopsys Design Compiler (voor ASIC's) alle initiële instructies.
@Michael Ik denk dat dat een kloof is tussen FPGA- en ASIC-doelen;FPGA's hebben vaak een speciale globale resetlijn waarvan de synthesetools op de hoogte zijn, terwijl AFAIK de meeste ASIC-ontwerpen een handmatige globale reset vereisen die samen met de logica wordt uitgelegd.
Joshua de Haan
2019-12-24 06:04:10 UTC
view on stackexchange narkive permalink

Normaal gesproken, als mijn ontwerp een daling van de bronnen laat zien, betekent dit dat het daadwerkelijk iets heeft 'geoptimaliseerd';Ik vermoed dat hier hetzelfde is gebeurd.

Typische FPGA-toolchains zullen alles wegsnijden dat niet direct of indirect een outputpin beïnvloedt.

De beste manier om te controleren wat Yosys aan het doen is, lijkt het gebruik van het 'show'-commando te zijn: http://www.clifford.at/yosys/files/yosys_appnote_011_design_investigation.pdf



ⓘ
Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 4.0-licentie waaronder het wordt gedistribueerd.
Loading...