Minimering av logik, i Altera Quartus.

[cyr]

Har följande Verilog-kod i ett projekt i Altera Quartus:

(opcode, breg, rb och rd är 4bits vektorer)

Kod: Markera allt

always@(*)
begin
	case(opcode)
		4'h0,
		4'h1,
		4'h3: breg <= rb;
		4'h8,
		4'h9: breg <= rd;	
		default: breg <= 4'hx;
	endcase
end

När jag tittar på koden så tycker jag att den kan minimeras till en mux som enbart beror på opcode[3] - alla fall som kräver breg = rb har ju den biten = 0, och alla som kräver breg = rd har den lika med 1 (eller hur?).

Jag tycker alltså att den koden ovan borde ge samma resultat efter syntetisering som följande:

Kod: Markera allt

always@(*)
begin
	if(opcode[3]) breg <= rd;
	else breg <= rb;
end

Men när jag syntar dessa får jag olika resultat, med den övre blir varje bit i breg en funktion av 4 signaler och med den undre bara av 3 signaler. Båda tar visserligen upp lika mycket plats i FPGAn, varje LUT har ju 4 ingångar ändå... Men fmax på hela bygget blir mycket högre med den undre varianten. Med den övre blir just den biten där denna kod ingår kritisk med fmax på 91MHz, och med den nedre blir fmax = 102MHz med en helt annan väg som kritisk. Antar att det har att göra med att färre signaler måste routas... eller nåt.

Vad jag inte fattar är varför Quartus inte klarar att minimera den övre varianten så den blir identisk med den nedre... För visst ska de vara likvärdiga? Eller är det min hjärna det är fel på idag?

Jag har en massa kod i det här projektet skriven enligt den övre varianten, för det blir tydligare och jag tänkte att det nog är bäst att låta mjukvaran optimera... men nu vet jag inte riktigt. Ska jag behöva rita massa carnaugh-diagram och göra jobbet själv?

[zus]

Ok, jag är inte så hemma på verilog...

...men kan det inte vara default: greq <= 4'hx; som ställer till det. Du har ju många fler kombinationer som kan komma in i opcode. Alla som du inte radat upp i det övre ex. kommer ju att hamna under default. I det undre exemplet så resulterar ju 0,1,2,3,4,5,6 och 7 i att breg blir rb?

[cyr]

Mjo, fast x betyder ju odefinierat så tanken (åtminstone från min sida) är att programmet själv får välja vilket värde som ska tilldelas där när man syntetiserat. Det verkar också fungera delvis, men inte optimalt.

[babbage]

Jag använder VHDL och inte verilog (jag tror dock att det inte har någon betydelse i det här fallet, men om jag säger något konstigt).

1) Dina båda exempel är inte identiska eftersom x som du säger kan bli vad som helst (till och med z?).

2) Syntesprogram är inte någon "allsmäktig och allvetande gud", de kan vara rätt dumma. Det finns många sätt att beskriva samma funktionalitet och det kan resultera i olika implementationer. Optimeringen (optimera behöver inte vara samma sak som att minimera) är någon mjukvarualgoritm skriven av någon programmerare, så om inte algoritmen hanterar ditt fall så går det ju inte.

3) I det andra fallet har du ju minimerat det själv, så då är jobbet lättare för syntesprogrammet med väldigt få frihetsgrader. Om du själv försöker skriva en algoritm som optimerar fall 1 jämfört med fall 2 så blir det väldigt mer komplext, optimeringsalgoritmen kanske gör en initial ansats (t.ex. att defaultvärdet ska vara "0000") och sen fastnar den i en suboptimering. Den hanterar kanske bara ett defaultvärde som dessutom är konstant, jag skulle inte bli förvånad om det är så (det kan vara intressant att simulera syntesresultatet i fall 1 för att se om så är fallet). Ditt "trick" är ju att identifiera två olika "defaultvärden", rd och rb, och sedan styra dem med en bit.

Vad kan man göra åt det?

Testa syntestricks, sätt hårda constraints på timingen (problemet är ju att veta i förväg vad som är hårt). Man kan kanske sätta constraints på area men om båda ryms i en LUT lär det inte göra någon skillnad. Det brukar finnas flaggor för att sätta "effort", hur länge syntesprogrammet ska jobba på varje funktion innan den ger upp.

Göra som du gjort, skriva kod som ger en bättre implementation (det kan skilja sig för olika syntesprogram om man har otur). Nu fattar jag det som du vill se att just vissa värden på opcode muxar register till breg. Man kan tänka sig att skriva om fall 1 så att du skriver alla 16 fall i case-satsen, men då har du ju optimerat själv igen och så blir det ju så mycket kod. Skriv som fall 2 med tydliga kommentarer motsvarande informationen i fall 1.

Är det viktigt att det går i 102 MHz istället för 91MHz? Annars är det ju bara ett akademiskt problem eftersom båda tar upp en LUT. Om du t.ex siktar på 100MHz så gör som du brukar eller använd färdig kod. Syntetisera och analysera sedan timingen. Optimera sedan de path:er som inte uppfyller timingkrav.

[cyr]

Tack för svaret. Jag hade nog räknat med syntetiseringen skulle vara lite mer systematisk när den hanterar case-satsen. En funktion av färre signaler borde ju rimligtvis vara lättare att implementera så första steget borde vara att reducera uttrycken så mycket som möjligt - tycker jag. Men jag kanske har fel.

Och som du gissade så är det 100MHz som är målet, gärna med lite marginal för det är mer som ska in i samma chip senare och man vet ju aldrig hur det påverkar resultatet.

[babbage]

Den försöker säkert reducera uttrycket, men att göra en algoritm som inser att man kan använda rd och rb villkorat med opcode(3) är nog inte så enkelt. Nu lägger väl inte fpga-leverantörerna ned alltför mycket jobb på att optimera syntesen. Det finns tredjepartföretag som har det som affärsidé. Om du hade använt ett sådant och skrivit och förklarat problemet för företaget är det möjligt att de skulle anpassa algoritmen för att klara även detta. Det kan ju ge dem en konkurensfördel gentemot andra företag hos kunder som gör utväderingar och har kod skrivet på det sättet.

Det finns ju flera begränsningar för ett syntesprogram och det är t.ex. tillgänglig beräkningskraft, arbetsminne och hur länge det får hålla på att optimera (hur snabbt det måste konvergera mot en lösning). Därför strävar de säkert att göra den bästa kompromissen när de designar algoritmer. Redan för gamla "enkla" PAL-kretsar när man endast gjorde minimering använde man program som gav ett bra resultat men inte nödvändigtvis det optimala (espresso från berkeley är väldigt känt).

Det finns väldigt många möjligheter med en case-sats. För andra opcoder kanske det inte alls är så enkelt att skriva om den med en if-sats så att man får ett bättre resultat i syntesen.

Ska det bli en 4-bitars processor? Det är en tanke som jag har haft att man ska göra en väldigt enkel 4- eller 5-bitars processor för kontrollfunktioner, det tar ju ingen plats alls i en fpga. Sedan har man hårdvaruacceleratorer som kan göra tyngre jobb.

[cyr]

Nej det är en 16bits RISC.

Närmare bestämt är det XR16 (http://www.fpgacpu.org/xsoc/xr16.html) som jag skriver min egen implementation av, dels för att lära mig lite, dels för att jag inte gillar licensen på originalkoden och dels för att anpassa den till mina behov och till min FPGA.