CPLD-FPGA eenvoudige voorbeelden.

Heeft met een paar dingen te maken:

1) Ervaring
2) Elk probleem heeft zijn eigen aanpak

Je kunt wel heilig by self-checking testbenches zweren, handig inderdaad om design optimalisaties te doen zonder dat de eigenlijke werking verandert. In het geval van die PWM waar Free het over heeft, zal 'ie vast gauw genoeg zien of iets in de haak is of niet.

Om een zijstraat in te gaan, in mijn werk (software ontwikkelaar) gebruik ik haast nooit de debugger, als iets niet (goed) werkt, is een blik op de source voldoende om te weten wat er mis is. Dat is ervaring.

Wat ik hier mee zeggen wil, dat iets wat ogenschijnlijk onprofessioneel oogt a.k.a. niet volgens het boekje is, niet per definitie al onprofessioneel/ondoordacht is. Meer ervaring = minder hulpmiddelen nodig.

En als je je design goed partitioneert is het goed mogelijk om zonder TB te werken (soms vind ik zelfs beter). Hangt echt van het type hardware af. Een DSP algoritme op een FPGA geimplementeerd schreeuwt om een testbench (je wil immers een heel aantal ingangssignalen kunnen aanleggen en de uitgangen verifieren met bv Matlab), maar een klein subblokje dat bv een switch debounced doet dat weer helemaal niet. Hier wil je ook helemaal geen tijd steken in het aanmaken van de testbench, opzetten van modelsim, de simulatie doen, ... De simulator van quartus is hier ruim voldoende volgens mij.

Ik ben eigenlijk heel tevreden over de quartus simulator. Ik vind het wel jammer dat je geen testbenches kan gebruiken, anders zou ik buiten matlab en quartus niks nodig hebben.

[Bericht gewijzigd door stecj366 op (14%)]

klopt. voor sommige blokken gebruik ik testbenches.
for ander blokken totaal niet.

voor zoeits als volgende code ga je toch geen testbench gaan maken :

 module mux (input [9:0] address,input [15:0] data,
input clk, input write,input reset, input [7:0] inputs, output mux_out );

parameter mapping = 9'h 1ff;

reg [2:0] muxsel;
always_ff @(posedge clock) begin
    muxsel <= muxsel;
    if (write)
      if (address == mapping)  muxsel <= data [2:0];
    if(reset ) muxsel <=0;
end
always_comb  mux_out = inputs [muxsel];
endmodule

dat draai je even door de golfvorm simulator. je ziet direct dat de mux werkt. ( trouwens dergelijk prul sim ik niet. ik kijk naar de rtl viewer en klaar. )

op toplevel als er eenmaal 50 geinstantieerd zijn en ze elk ene address hebben .. en in het systeem zitten kan je evne een testbenchje maken om te verifieren dat alles wel loopt zoals je wilt.

het komt erop neer om kleine moduletjes te maken en die eerst te testen . eenmaal je die hebt : knoop aan elkaar en vooruit ermee

modellen maken is heel leuk , maar als je met een immens programmeerbaar systeem zit kan je dat haast niet modelleren.

die pwm bijvoorbeeld waarover ik sprak is niet lineair. ( de pwm gebruikt een lookup table die kan geladen worden door de computer. is 2 kilobyte data . de pwm wordt gestuurd door een blok wat berekeningen doet afgaande op binnekomende data. daaruit wordt de pwm
gestuurd.

tegen dat jij een testbench gemaakt hebt zit mijn blok al lang in de fpga , hangt ie aan de scoop en stuur ik de a/d aan vanuit een arbitrary waveform generator waarop de te volgen wave opgeslagen is.
met de scoop verifieer ik en kan ik de lookup table uittunen.

de pwm module zelf is gesimd. ( het lezen van de lookup table en dat in de pwm zetten , alsook het laden van de lookup table vanuit de pc . het calculatieblok is ook gesimd )

het systeem simmen ? forget it. trouwens dat haalt toch niks uit. het moet toch ingeregeld worden.

ik weet dat mijn deelmodules werken. ik kan de tabel laden , het calculatieblok werkt en de pwm werkt ook. er valt niks meer te simuleren. de rest is de boel uittunen.

ik heb ook een geweldige testmultiplexer zitten in de fpga die naar buiten komt op een 32 bit poort. daar hangt een van die infiniium scoops met digitale ingangen aan. en ene logic analyser.
vanuit de pc kan ik eender welk punt naar buiten brengen.

Mja, dergelijk prul sim ik toch wel, ook al kijk ik naar de RTL viewer. Ik doe ook altijd gate level sims, om zeker te zijn dat alle delays wel goed zitten. Functional sim is voor in simulink :)

Dat is zowiezo een goede tip voor wie DSP op fpga wil gaan maken. Ik bouw al men algoritmes eerst in Matlab (Ongelooflelijk testbaar, en je moet je geen zorgen maken over overflows ed, ant je zit met floating point), dan in simulink (blok based, al dichter bij de implementatie door instelbare bitbreedtes, fixedpoint notatie, etc.) en dan bouw ik alles na in quartus schematic editor en af en toe met VHDL. Maar ik ben zo tevreden van die schematic entry dat ik bijna geen HDL meer nodig heb (enkel nog voor complexe controle logica, alhoewel...).

Ik heb ook de indruk dat echt time-critical stuff sneller kan gemaakt worden door alles zelf aan te maken. Dan ben je tenminste 100% zeker dat alles is zoals je wil. Ik heb zo een volledig model van een cochlea op FPGA geimplementeerd (tot en met de neurale spikings en peak detectors) en die aanpak werkte echt super.

Op 22 december 2007 23:59:51 schreef MagicBox:
Wat ik hier mee zeggen wil, dat iets wat ogenschijnlijk onprofessioneel oogt a.k.a. niet volgens het boekje is, niet per definitie al onprofessioneel/ondoordacht is. Meer ervaring = minder hulpmiddelen nodig.

Is ten dele waar. Met ervaring zie je eerder waar dingen fout gaan heb je de bug eerder gevonden zonder een uitgebreide analyse. Voorwaarde hierbij is wel DAT je het fout ziet gaan. Soms gaat iets heel subtiel fout, en zie je het gewoonweg niet op de bench. Wat dat betreft is HDL design nog iets "linker".

@FE: die voorbeeld code die je gaf, da's natuurlijk duidelijk dat je daarvoor geen TB gaat maken! Dat doe je niet op dat nivo. Hoef je niet eens te simuleren, zie je zo dat het ok is (met ervaring, is ie weer). Een TB maak ik alleen op top nivo. Dus het hele design in een keer. Modeleren is daarbij (meestal) alleen handig als het om een dataflow gaat. Bv een encryptor of decoder. Control is vaak lastiger te modeleren, dat check je dan zonder model in je testbench (al is dat eigenlijk ook weer een model).

Wat ik nog mis in de discussie, en wat ook pleit voor een TB, is het opzoeken van randsituaties. Bv je hebt een counter dat reset op signaal X, upcount op signaal Y en downcount op signaal Z. Hoe check je het gedrag op ALLE combinaties van de drie? Op de bench?

Let wel, ik ben geen principieel voorstander van TBs. Als je denk het niet nodig te hebben, vooral doorgaan. Ik zie wel vaak problemen hier voorbij komen waarbij men tijden heeft zitten denken en prutsen om iets werkend te krijgen. Met een testbench zie je onmiddelijk waar iets fout gaat. Je kunt overal in je design "prikken".

Zo ook vandaag gekeken of ik wat kon optimaliseren, ik begon aardig uit mijn p-terms te lopen. Ik ben benieuwd of Free dit al wist ;)

Ok, je hebt een 16-bit counter:


always @ (posedge CLK, posedge RESET) begin
  if (RESET)    CNT <= 0;
  else
  begin
    CNT <= CNT ++ 1;
    if (CNT == 16'hFFFF) begin
      /* Bepaal volgende state */
      STATE <= STATE_NEXT;
    end
    case (STATE)
      ..
    endcase
  end
end

Wat hier gebeurt, is dat de synth er een dikke 16-bits comparator in gaat gooien die de counter op 0xFFFF test. Dat is maar liefst 16 inputs en een bak aan AND gates, wat alleen maar erger wordt als de teller groter is/wordt.

Hier ben ik eens over na gaan denken. Wanneer zitten we nu aan de top? Als het MSB 1 is, maar na de volgende clock tick weer 0 gaat worden. Dus, die code even verbouwd:


wire [15:0] CNTNEXT = CNT ++ 1;
wire        CNTTOP  = CNT[15] && !CNTNEXT[15];

always @ (posedge CLK, posedge RESET) begin
  if (RESET)    CNT <= 0;
  else
  begin
    CNT <= CNTNEXT;
    if (CNTTOP) begin
      /* Bepaal volgende state */
      STATE <= STATE_NEXT;
    end
    case (STATE)
      ..
    endcase
  end
end

En jawel hoor, de dikke comparator was weg en had weer meer p-terms en gates over :) De synth maakt er nog steeds een 16-bit timer van. Leuk hè?

Edit: Op die manier kun je dus ook heel goedkoop synchrone clock delers maken:


wire        CLKDIV8 = CNT[2] && !CNTNEXT[2];
...
...
  if (CLKDIV8) begin
    /* Komt elke 8 mainclock pulsen hier */
  end

Da's een goede methode. Lekker zuinig. Er is ook een nadeel: je code wordt minder goed leesbaar. Bij de geoptimaliseerde code zie je niet gelijk wat het doet. Bekijk de code na een paar maanden nog eens en probeer het te lezen. Kost meer tijd. Kan een overweging zijn om toch naar de minder optimale code te gaan.

Daar ben ik het niet helemaal mee eens. Goede naamgeving is het halve (uitzoek) werk. In context tot dit voorbeeldje is de variabele CNTNEXT zeggend genoeg om te bevatten dat dit de volgende teller waarde is, de declaratie zelf laat geen uitsluitsel over: CNTNEXT = CNT ++ 1;
Zelfde voor de topwaarde. CNTTOP geeft duidelijk weer dat 't om de counter top gaat. CNT <= CNTNEXT idem, laad de teller met zijn volgende waarde. CNT geeft aan het is een teller, zal de volgende waarde vast +1 zijn.

Ja, het valt ook wel mee in dit geval hoor. "Probleem" zit hem het meest in de assignment van CNTTOP. Daar zit het denkwerk. De always@ is wel duidelijk.
Maar vergelijk het eens met je eerste stuk code. Daar zie je sneller wat er gebeurd van in je optimalisatie.

Op 23 december 2007 11:09:26 schreef flipflop:
[...]
Modeleren is daarbij (meestal) alleen handig als het om een dataflow gaat. Bv een encryptor of decoder. Control is vaak lastiger te modeleren, dat check je dan zonder model in je testbench (al is dat eigenlijk ook weer een model).

Wat ik nog mis in de discussie, en wat ook pleit voor een TB, is het opzoeken van randsituaties.

nu sla je de nagel op de kop. testbench dient om je dataflow te bekijken.

als je alles synchroon bouwt en static timing analyse doet ben je al een heel eind.

voor randsituaties ; geen tijd verspillen met testbenches... specman of vericity erop losaten. als er iets in zit vinden die dat wel ...

Da's niet wat ik zei he! Een testbench is ALTIJD handig (tenzij het om een enkele file/module gaat zoals in wat voorbeelden hierboven). Een MODEL is handig als het om datapad gaat.

STA doe je niet om functionaliteit te testen, maar alleen je timing. Dat is weer een heel andere discussie.

Specman ed: dat is gewoon een andere methode om je design te testen. Kan sneller zijn, maar het voordeel is vooral dat deze tools dieper zoeken dan dat je zelf ooit zult kunnen. Maarrrrrrrrr, je moet je wel zelf de constraints geven. Je moet dus nog steeds je gewenste of ongewenste gedrag vertellen. Ze vinden heus niet vanzelf jouw bugs hoor.

Op 23 december 2007 13:21:38 schreef MagicBox:
Zo ook vandaag gekeken of ik wat kon optimaliseren, ik begon aardig uit mijn p-terms te lopen. Ik ben benieuwd of Free dit al wist ;)

Ok, je hebt een 16-bit counter:


always @ (posedge CLK, posedge RESET) begin
  if (RESET)    CNT <= 0;
  else
  begin
    CNT <= CNT ++ 1;
    if (CNT == 16'hFFFF) begin
      /* Bepaal volgende state */
      STATE <= STATE_NEXT;
    end
    case (STATE)
      ..
    endcase
  end
end

veel te moelilijk gemaakt ...


reg [15:0] CNTi ( internal counter )
assign CNT = ~ CNTi; 

always @ (posedge CLK) begin
  CNTi <= CNTi;
  if (RESET) CNTi <= 16'hFFFF;
  if (!|CNT) CNTi <= CNTi -1;
  else begin
       STATE <= STATE_NEXT;
       CNTi <= 16'hFFFF;
  end
     case (STATE)
        ..
     endcase
end

voila . verchillende dingen

1) aftellers zijn kleiner dan optellers !

2) flip alle bits van CTNi zo wordt de afteller ene opteller voor de buitenwereld( je brengt Qnot naar buiten maar gebruikt intern Q ... )

if (!|CNTi) | is een reduction or poort dus als alle bits in de teller nul zijn valt die poort naar nul. door dat te inverteren : bingo een signaal wat hoog wordt als alle flipflops laag zijn . dus de teller is nul.

dat zou heel minimalistisch moeten synthetiseren normaal.
de flipflops en hoogstens 5 of 6 LE's..

Op 23 december 2007 16:39:07 schreef flipflop:
Da's niet wat ik zei he! Een testbench is ALTIJD handig (tenzij het om een enkele file/module gaat zoals in wat voorbeelden hierboven). Een MODEL is handig als het om datapad gaat.

STA doe je niet om functionaliteit te testen, maar alleen je timing. Dat is weer een heel andere discussie.

eh ik was mis. ik bedoelde model natuurlijk. om dataflow te doen.

testbench is goed voor toplevel.

STA : als er daar geen problemen zijn zal de boel toch iets doen. en STa moet je draaien op toplevel waarin de delays ( post routing ) inzitten. ik ken er die STA gedraaid hebben op pre-route ... tjah ... )

Begrijp ik het goed dat ik met een down-counter winst behaal over een up-counter? Als dat zo is zal ik eens een progje van me ombouwen naar downcounter. Ik hoef 'm toch niet naar buiten te brengen, dus ga geen conversies doen dan. Ook de countercondities inverteer ik dan wel direct :)

Edit: operatie geslaagd.

Resultaat: 1 macro cell minder, ongeveer 10% meer product terms. In dit specifieke geval blijf ik dus bij de up-counter.. dan heeft het ontwerp een betere resource balans :)

[Bericht gewijzigd door MagicBox op (26%)]

Yeah Ik doe nu ook mee met deze digitale sh*t. Vandaag is mijn Spartan-3E bordje aangekomen. :p
http://dkc3.digikey.com/us/images/Xilinx_3Elg.gif

Ik ben nu bezig met dat klein LCD schermpje. FPGA's zijn toch wat anders als gewoon uC's

Robin

Ik wil graag een integraal vergelijking gaan oplossen in vhdl, maar ik heb eigenlijk geen idee hoe ik dat het beste kan aanpakken.

Bovendien heb ik nog altijd een moeite om echte te begrijpen wat nu z-1/z doet en hoe je deze moet interpeteren in de code.

Misschien dat sommige voor mij nuttige tips hebben. Of misschien met een stukje code een gedeelte kunnen toelichten.

Numeriek een integraal oplossen is optellen. Maar kun je niet wat specifieker zijn?

En ben je iets met een z-transformatie aan het doen? (Filters?) Daarbij is z-n een n stappen vertraagde sample en zn een sample n stappen uit de toekomst.

Bedenk wel dat rechtstreeks de wiskundige formule implementeren niet altijd de handigste of kleinste methode is.

Op 2 januari 2008 13:58:59 schreef robint91:
Yeah Ik doe nu ook mee met deze digitale sh*t. Vandaag is mijn Spartan-3E bordje aangekomen. :p
<<>>

prijzig bordje zeker? kan je op die mega-connector I/O uitbreidingen plaatsen? ik kon hem zo bij digikey niet terug vinden...

edit: aangezien de afbeelding hier http://dkc3.digikey.com/us/images/Xilinx_3Elg.gif weg komt ging ik er vanuit dat het bordje daar dus ook vandaan komt.

inderdaad, beste korting voor uni-gebruikers. maar voor technische hbo zal ook vast wel een regeling zijn te vinden en anders maar via een vriend die wel op de uni zit :P al vind ik 300 dollar nog wel erg veel geld voor hobby. zeker als je er nog totaal geen kaas van gegeten hebt.

[Bericht gewijzigd door MAH op (40%)]

Je moet ook niet bij digikey kijken.

http://www.digilentinc.com/Products/Detail.cfm?Nav1=Products&Nav2=…

Daar kun je hem wel vinden, de prijs valt alleszinds mee vind ik.

Maja deze blijft toffer, zeker gezien de korting die je krijgt als je op de uni zit.

[Bericht gewijzigd door surge_me op (32%)]

@ goedevraag.

Ik ben inderdaad gewoon aan t proberen een filter te maken. Het liefst een PID. Misschien bestaat de code wel al, maar ik zou hem graag zelf willen maken. Want learning by doing is the best way.

Nu weet ik wel hoe ik alles moet realiseren in termen van ideeen, maar alleen de uitvoer vind ik nog altijd een beetje lastig misschien dat iemand me op weg kan helpen.

Zo moet ik bijvoorbeeld error steeds gaan vergelijken met een voorgaande error.

Ik wil dus de error opslaan in een registeren en die vergelijken met een andere error die staat in ander registeren. Het verschil in tijd is de sampletijd. Want na iedere sample komt er een nieuwe waarde van de error.

t zal vast enorm simpel zijn voor de gevorderde persoon. Alleen ik heb er nog problemen mee. Dus als iemand graag wil helpen.

Ik kan het alleen beschrijven, FPGA's heb ik geen kaas van gegeten:

Je neem de actuele waarde en slaat die op.
Daarna bereken je de fout door van de gewenste waarde de actuele af te trekken.
Deze fout versterk je met je P faktor en sla je op in je P deel.
Je integrator verhoog je met de fout * I deel
D deel krijd je door van de actuele error de laatste error af te trekken en te vermenigvuldigen met de D faktor
De huidige error wordt de laatste error.

C Code:


	actual = pressureSensor[3];

	ERROR = (DV - actual);				
	PROP = (float)ERROR;
	PROP*= Pgain;
	INTE+= ((float)ERROR*Igain);
	DIFF = (float)(ERROR - LAST_ERROR);
	DIFF *= Dgain;

	LAST_ERROR = ERROR;
	testout = (signed long)(INTE + PROP + DIFF);

Voorzover die er nog niet was heb ik een korte tutorial gemaak waarin kort uitgelegd wordt hoe je een *.v file in je MAXII micro kit kan programmeren. Op dit moment is het gewoon de encoder.v file van fotoopa waarmee dit topic is begonnen.

Weet iemand hoe je een VGA display/monitor aan een MaxII micro/nano kit kan knopen? Ik ben benieuwd hoe dit in zijn werk gaat. Kan ik hetzelfde VGA circuit ervoor gebruiken als bij het Bluebird board?

@Fotoopa:
Ergens heb ik gezien dat je wat VGA drivers hebt gemaakt voor het Bluebird bord, zou ik deze ook kunnen gebruiken voor het MAXII micro kitje?

Alvast bedankt.

De VGA controller zelf zou geen enkel probleem zijn maar om de karacters op het display te plaatsen is ram of flash geheugen nodig. Omdat die niet zomaar voorhanden is zou een en ander moeten geoptimaliseerd worden met de beschikbare LE's van het MAX II boardje. Zomaar overnemen zal dus niet gaan maar ergens een optimalisatie met een aantal beperkingen moet wel mogelijk zijn.