CPLD-FPGA eenvoudige voorbeelden.

Op 13 november 2007 23:27:53 schreef rew:

Anderzijds, als je niet opgeeft wat ie moet worden, vind ik dat een compiler moet kunnen beslissen dat het simpeler wordt als ie een bepaalde waarde krijgt die voor de hardware "makkelijk is".

Ik heb hier "=" gebruikt en niet "<=" Krijg ik dan combinatoriek ipv een register? Als ik verilog tot nu toe goed begrijp zou als dit op een clock werkt en out een register is, de boel gedefinieerd onveranderd blijven als somevar de waarde 3 of 5 heeft. Toch?

Als het combinatoriek is, dan MOET de compiler een waarde kiezen. Laat hem dan maar een "makkelijke waarde" kiezen. Voor implementatie in een FPGA maakt 1 of 0 eigenlijk niet uit. Voor implementatie als een ASIC wel.

der gaat er hier een serieus zijn gat verbranden ...
Als je logica op die manier schrijft infereert de synthesizer latches.... en dat is gegarandeerd miserie.

De synthesizer MAG niks 'aannemen'.

wat je WEL kan doen i het volgende

pixel [7:0] <= 0;
case(pix_sel)
   0: pixel[0] <= 1;
   1: pixel[1] <= 1;
   2: pixel[2] <= 1;
   3: pixel[3] <= 1;
   4: pixel[4] <= 1;
   5: pixel[5] <= 1;
   6: pixel[6] <= 1;
   7: pixel[7] <= 1;
endcase

dat spul maakt dus een tros stuurbare multiplexers ( heb ik hierboven een uitvoerige epistel gepost of 'concurrent if 'statements. de onderste heeft prioriteit. ( de case heeft prioriteit )

je werkt van begin naar de ingangen van de flipflop toe.
je komt dus eerst iets tegen wat de flipflop op nul wil zetten. dat wordt onderbroken door het 'case' statement.

met andere woorden voor elke flipflop komt een multiplexer nu. gestuurd door 'case x'

     
  0--|\     ____
     | |---|d  q|
  1--|/   -|>   |
      |    |____| 
   case x

Waarom is een latch toch altijd 'gegarandeerd misere', ik bedoel, je kunt daar toch rekening mee houden?

testbaarheid en snelheid dalen door de latches

Op 14 november 2007 01:01:28 schreef surge_me:
[...]

Mwa als je het goed bekijkt zie je dat dat een mooi sprookje is (van precies het zelfde moment) JE moet ervoor zorgen dat je counter+1 de grootste vertraging heeft t.o.v de andere vergelijkingen binnen je always@ statement.
MAar goed als je ooit eens wat meer de grenzen op zoekt (kwa snelheid van de FPGA) dan zul je zien dat dit soort oplossingn niet altijd direct goed werken..

Nee, zowel de berekening van "counter+1" als de berekening "pwm[0] > counter" gaan uit van de oude waarde van counter. Ze worden in een register geladen bij de volgende klokflank.

Met jou redenering gaat "counter <= counter+1" als een dolle staan te tollen. Hij berekent de volgende waarde en die wordt pas in de "counter" registers gezet zodra er een volgende klok puls komt.

Op 13 november 2007 17:06:56 schreef fotoopa:@SMD lover,
Ik heb je opgave geschreven in verilog. Van je structuur blijft niets over.
...
Maar dan heb ik het omgezet voor je EPM7064 en daar bekom ik 60 macro cellen voor

Super super, dank je wel!
Met die structuur bedoel je zeker het schema? Verder ben ik erg blij dat het nu in Verilog is, ik hoop er weer wat van op te steken. Zodra ik de pinnen heb toegewezen en alles getest laat ik het weten. Hartelijk dank
En.. als je een tip hebt hoe je dit voor elkaar hebt gekregen? Ik sta er echt van te kijken!

Normaal moet het perfect draaien. Dezelfde versie draait hier op de FPGA board, zij dat de uitlezing direct op de 4 digits is omdat er meer resources zijn.

Tip? eigenlijk is het vri eenvoudig, ik gebruik dezelfde decade tellers van 1ms, 10ms, 100ms en 1s zowel voor de random wachttijd, als de meettijd en als de uitlees registers. Je had daarvoor afzonderlijke delers gebruikt en dat kost macrocellen.Nu is het programma ook veel kleiner. Zoals je zult zien werk ik bijna altijd met case blokken. Dit bestuurt heel gemakkelijk, is duidelijk, is ook goed testbaar met een LA en verbruikt weinig cellen.
Laat maar weten als het draait.

Oh ja, de tekens boven cijfer 9 kun je aanpassen om andere figuren op je display te maken. je moet ook eens nakijken of de tabel voor de segmenten juist is in volgorde en ook in level want ik heb deze van mijn FPGA bordje gebruikt. Anders moet je de segment tabel maar aanpassen.

[Bericht gewijzigd door fotoopa op woensdag 14 november 2007 10:56:45 (18%)]

Op 14 november 2007 10:13:02 schreef rew:
pas in de "counter" registers gezet zodra er een volgende

En dat "in de counter registers zetten" kost geen tijd?

D'r is een "setup" en een "hold" tijd. De signalen dienen minimaal <setup> tijd voor de clock stabiel te zijn, en minimaal <hold> na de clock dat te blijven. Moderne D flipflops hebben een hold tijd die negatief is (maar dat heeft weinig nut), dus de specs zeggen meestal "0".

Stel de registers in de FPGA hebben een setup tijd van 1ns, een propagation delay van 1ns en het uitrekenen van Counter+1 kost 10 ns.
Als de boel op een langzame clock loopt, bijvoorbeeld 100ns, dan zie je dat rond 1 ns de uitgangen van de registers de nieuwe waarden hebben aangenomen. 10ns later is dan "counter+1" uitgerekend en komt klaar te staan aan de ingangen van de registers. Het geheel wacht dan rustig in die toestand tot 99ns wanneer de ingang stabiel MOET zijn. Op 100ns komt de clock en zal kort daarna de uitgangen van de registers de nieuwe waarde reflecteren.

Draai je de clock op tot 83.3 MHz, in dit geval de limiet, dan veranderd de uitgang van het register op 1ns, op 11ns is de boel stabiel uitgerekend, en moet de boel stabiel blijven tot op 12ns de volgende clock komt.

Zou je de clock op 125 MHz zetten, dus dat je na 8 ns een volgende clock krijgt, dan kan je effecten hebben dat "counter+1" bij de waarde van counter=15 naar nul gaat ipv naar 16 (counter > 4 bits). De volgende clock komt dan voordat de waarden aan de ingangen van de registers stabiel zijn.

Om de theorie van onze leermeerster eens te toetsen aan de werkelijkheid even een kleine proef:

module prioriteit(
input		 clk,
input	   [2:0] pix_sel,
output reg [7:0] pixel );

always @ (posedge clk)
begin
	pixel [7:0] <= 0;
	case(pix_sel)
		0: pixel[0] <= 1;
		1: pixel[1] <= 1;
		2: pixel[2] <= 1;
		3: pixel[3] <= 1;
		4: pixel[4] <= 1;
		5: pixel[5] <= 1;
		6: pixel[6] <= 1;
		7: pixel[7] <= 1;
	endcase
end
endmodule

Compileer dit heel klein progje en je ziet dat hij 8 LE's gebruikt. Het programma zal idd perfect werken.

Verplaats nu de toekennings regel onder de endcase:

module prioriteit(
input		 clk,
input	   [2:0] pix_sel,
output reg [7:0] pixel );

always @ (posedge clk)
begin
	case(pix_sel)
		0: pixel[0] <= 1;
		1: pixel[1] <= 1;
		2: pixel[2] <= 1;
		3: pixel[3] <= 1;
		4: pixel[4] <= 1;
		5: pixel[5] <= 1;
		6: pixel[6] <= 1;
		7: pixel[7] <= 1;
	endcase
	pixel [7:0] <= 0;
end
endmodule

En compileer nu opnieuw het programma. Je ziet dat er geen LE's meer nodig zijn maar in het rapport zie je idd dat alle uitgangen altijd op null staan. Dit wat de les die we kregen en die gaan we nooit meer vergeten.

Met dank aan onze F_E.

Ook het onderste programma "werkt perfect". Het doet precies wat je hebt opgegeven.

whaaaaa. een enorme epistel van mij zomaar verdwenen ...
verdikke ...

toch nog een beetje kunnen redden

Ergens in een kwijtgeraakt tijdstip op 14 november tussen 18:00 en 22:32:
@rew : klopt.programma werkt correct ( computers fouten nooit) maar het design is mis ! programma doet exact wat je geschreven hebt, maar twas niet wat je nodig hebt.

De 'concurrent if' is een techniek om design fouten te vermijden bij complexe if then else systemen.

om in te pikken op wat foto_opa schrijft :

Juist. De pixel[7:0] <=0 heeft prioriteit voor de case. ( je moet het zo zien : hoe lager je bent hoe 'dichter' je bij de output staat, dus hoe hoger je prioriteit. Die case mag daar doen wat hij wil: de lijn erna zegt dat alle outputs op nul moeten. punt uit.

In je eerste geval zegt de lijn eerst dat alle outputs op nul moeten. En dan gaat die 'case' dat gaan oversturen door 1 van de pinnen zijn wil op te drukken.

Je moet het echt zien als een omgekeerde 'else'
Een if then else is :
-als dit ....
-anders als dit ....
-anders als ...
-anders ...

en als je ene mogelijke weg vergeet : bingo.

Concurrent if's zijn :
-tis dit ( die 'als' is er niet . tis 'altijd' dit)
-bovenstaande, behalve in dit geval : blabla
-bovenstaande, behalve in dit geval : blabla

der is geen 'vergeten' weg

Je moet in multiplexers denken : we grijpen terug naar foto_opa voorbeeld

eerste geval :

  0--|\    ___
     | |--|d q|-
  1--|/   |>  |
      |   |___|
     case

eerste lijn zegt : tis altijd nul
de case zegt : behalve wanneer ik zeg dat het 1 moet zijn

tweede geval is

        'tis nul'
  0--|0\       |  
     |  |-----|0\   ____ 
  1--|1/      |  |-|d  q|--
      |    0--|1/  |>   |
     case          |____|

eerste lijn (de case) zegt : ik zeg wanneer het 1 is ( merk op dat die case nooit zegt wanneer het nul moet zijn ... schoolvoorbeeld van 'vergeten pad'. perfecte verilog maar niet werkend circuit: design fout. in eerste voorbeeld mag de designer dat vergeten. de blokken die niet geraakt worden hebben een conditie opgedrukt gekregen in de eerste lijn.)

tweede lijn zegt : behalve dat het altijd nul is.

Tweede lijn heeft prioriteit, eerste lijn heeft niks te piepen. dus :smijt alles weg , inclusief de flipflop en hang output aan nul.

Dit 'concurrent if' mechanisme is heel handig als je een comlexe genestte if-then-else structuur hebt. Je kan die complexe structuur in vele gevallen heel simpel omgooien naar ene tros genestte if's. Veel leesbaarder. En veeel minder tikwerk , en tis kleiner ook en je hebt geen kans op 'vergeten' paden ( die weer tot latches leiden ). En de synthesizers kunnen er beter weg mee wat tot minder area leidt ( zeker in asic's. Bij fpga gebeurt er toch weer post-rtl expansie om het te mappen op de aanwezig blokken , bij asic smijten ze effectief neer wat ze nodig hebben. Als je een or nodig hebt met 5 inputs dan wordthet dat. in de fpga kan het zijn dat er alleen or's zijn met 3 ingangen en dan staan daar fysiek 2 gecascadeerde or's. )

Nog een tip :

Om dit soort 'vergeten' condities te vermijden ( en te vermijden dat je overal die 'else's moet gaan schrijven in je genestte structuur :
- Schrijf de default conditie van alle uitgangen eerst neer.
- Daarnaa zet je de 'override' logica neer. als er een dood pad in je systeem zit zal de uitgang de default conditie aannemen. en geen random spul naar buiten sturen.

Een voorbeeld je van een mogelijk 'dood' pad

if (reset)  x<=0;
else if(write) x<=data_in;
     else  x<=x;  // om 'proper' te zijn zou je dit MOETEN schrijven

en wat gebeurt er als beide inputs op hetzelfde moment arriveren ? of er geen inputs zijn ? Je moet het zien als volgt : 'reset' en 'write' zijn twee ingangscondities van je logisch blok.

reset write output
 1      x    x<0 ;  if reset : write speelt geen rol
 0      1    x<=7;  if not reset ( else ) : zie naar write 

En wat met de conditie :

reset write output
 1      0    ???

Je hebt daar niks voor gespecifieerd ... nu is de synthesizer wel slim genoeg om daar 'aan te nemen' dat je dan wilt dat de uitgang 'x' niet veranderd. Maar het is geen goed idee om de compiler dingen te laten 'aannemen' ...

Maar als je complexe testen doet geraak je zelf op de duur de pedalen kwijt.
Om die miserie te verhinderen : concurrent if's.

bijvoorbeeld:

x<=x;                // houdt ALTIJD uw laatste waarde
if (write) x <= in;  // behalve alst schrijven is :
if (reset) x<=0      // bovenstaande behalve alst reset is

Nu is er nooit discussie. je hebt ALTIJD een afgedekt pad : met name de eerste conditie ( dat mag GEEN if of case zijn maar gewoon een simpele toekenning : 'uitgang is dit.')

Al de volgende lijnen 'modificeren' het pad wat de toekenning aflegt naar de uitgang ,maar ze 'onderbreken' het pad niet.

Ik zit hier nu al een paar dagen met een echte asic designer naast mij en kheb al meer geleerd in die 2 dagen dan in de laaste 4 maand uit allerhande boeken. Sommige blokken code ( die werken na veel tunen van de if-then-else structuur ) heb ik herschreven in concurrent ifs. Veel simpeler te lezen en ze werkten direct juist.

der is 1 heeeel interessant document : IEEE1364.2001 . Jammergenoeg niet gratis ( kost 100 $ of zoiets ). is een lijvig werk ( 500x paginas op a4 ... ) wat niet alleen de taal specifieerd maar ook HOE de synthesizers de boel moeten implementeren. bij tijden zeer 'droog' om te lezen. maar als je iets niet snapt kan je daar in vinden hoe het de synthesizers het implementeren.
[Bericht gewijzigd door free_electron op 14 november 2007 18:33:12]

en namens fotoopa:

@ free_electron:

Als ik dit zo lees ga je nu weer je boek moeten herschrijven

Maar ik heb hier toch nog een speciaal geval getest. We weten dat bij de logische ic's een DFF zoals een 74x74 met asynchrone reset en set je niet gelijktijdig beiden moogt activeren omdat de toestand dan onbepaald is.

Ik wou dat ook even nazien hoe dit verloopt met je voorgaande uitleg en heb dit stukje code geschreven:

module flipflops
(
input		clk,
input		asetn,
input		aresn,
input		d_in,
output	reg	d_out
);


always @ (posedge clk or negedge asetn or negedge aresn)
begin
  if (!aresn) d_out <= 0;
    else if (!asetn) d_out <=1;
      else d_out <= d_in;
end
endmodule

Opzich niets speciaal voldoet aan je voorkeur schrijfwijze enz. Na compilatie en simulatie ontdek ik het volgende:

Als je beide asetn en resn gelijktijdig actief maakt neemt de uitgang het level in van de bovenste if, indit geval wordt d_out=0 gedurende de ganse periode, echter bij gelijktijdig hoog brengen van beide signalen neemt d_out het level aan van de 2de lijn: dus d_out=1
Natuurlijk vanaf de volgende clock wordt het level opnieuw bepaald door d_in wat ook verwacht wordt.

Stel dat je nu de 2 bovenste lijnen omwisseld zodat asetn op de eerste lijn staat dan zal d_out gedurende de tijd dat de BEIDE set/rest ingangen actief zijn nu d_out=1 zijn en bij het gelijktijdig loslaten ook nu weer de omgekeerde toestand aannemen dit tot aan de volgende clock.

In de simulator zit dus een vaste methode in waarvan ik niet weet of het in de praktijk ook zo verloopt. Immers om dit te testen zou je een stukje extra code moeten schrijven om dit zichtbaar te maken ( of met een heel trage clock werken)

Ik weet wel wie gaat er nu die beide set/reset ingangen gelijktijdig actief maken als je weet dat het niet mag, maar we zijn nu wel curieus hoe die compiler het in de praktijk doet.

Update:

Ik heb nog even de RTLviewer geopend en daar zie je idd de vergrendeling van de volgorde indien beiden actief zijn. Maar wel eigenaardig dat juist na het terug hoog worden van beide signalen het level omkeerd.

Maar hé, als je het pad volgt dan zie je door de delay's dat het idd zo moet verlopen door de delay van de bijgevoegde gate....

Hier het plaatje als de 2 bovenste lijnen omgewisseld zijn. Dus ja dat verklaar alles.

[Bericht gewijzigd door fotoopa op 14 november 2007 19:51:52]

en stecj366

Maar als het op power aankomt zijn ze wel veel gunstiger. Daar waar het zuinig moet worden vooral latches gebruikt. In synchroon design gebruik je eigenlijk alleen FFs.

Helaas is dit alles wat ik uit mijn cache kan pulliken

kzallet mar proberen herschrijven zeker ... #$%^& moderators #$%$% mompel mompel.

als er hem nog ene vindt... mag ie hem posten. ik hebbem niet meer.

bon, effe kijken of ik mij nog kan herinneren wat ik paar uur terug heb neergepoot :

@ rew : klopt dat programma doet perfect wat je daar geschreven hebt. alleen is er iet s mis met het design zelf. computers maken gene fouten het zijnd e mensen die ze bedienen.

dat concurrent-if ' gebeuren is een methode om 'design fouten' of 'design tekortkomingen' te vermijden.

als je logica designed moet je exact zijn. het is voldoende dat je ergens in een geneste if-then else soep een pad vergeet volledige te bewandelen en je kan allerhande vreemde resultaten krijgen. logica die soms niet doet wat je verwachtte etc. ( meestal omdat er ergens een latch geinstantieerd is op een signaal... )

om in te pikken op foto opa zijn demo.

in het eerste voorbeeld staat daar :
- de uitgangen zijn allemaal nul (eerste lijn )
- in het geval van 'pixel' moet deze uitgang 1 worden.

de onderste regel heeft dus prioriteit.

bij het tweede voorbeeld staat daar :
- in het geval van 'case' moet deze uitgang 1 worden.
- alle uitgangen zijn nul.

dus de synthesizer mapt dit zo uit :
geval 1 :

 0--|0\    ___
    |  |--|d q|
 1--|1/   |>  |
   case   |___|

in geval 2 wordt het dit

     case
 0--|0\         
    |  |--|0\   ___
 1--|1/   | |--|d q|
        0-|1/  |>  |
   altijd nul  |___|

dus de synthesizer smijt alles weg en verbindt de uitgangen hard aan nul.

je moet in multiplexers denken.

Het voordeel van concurrent if's is dat er ALTIJD een pad gedefinieerd is. er is geen plaats voor 'interpretatie.

stel je doet het volgende

if (reset) x<=0
else if (write0 x<=in

als je de waarheidstabel opstelt :

 reset  write
   1      x    x<=0
   0      1    x<=in

je waarheidstabel is niet 'compleet': Er wordt niet opgegeven wat er moet gebeuren als beide ingangen nul zijn. je gaat ervanuit dat x wel behouden zal blijven ... vertrouw de synthesizer NOOIT en zeker niet op 'het zal wel goedkomen' !.

eigenlijk zou je moeten opgeven

if (reset)  x<=0;
  else 
     if (write0 x<=in;
     else x<=x;
 

nu zijn alle ingangscondities wel 'afgedekt'

met die concurrent if techniek heb je dat probleem niet :
x <=x;
if (write) x<=in
if (reset) x<=0

en nu zijn alle condities afgedekt en reset heeft hoogste prioriteit. er is geen 'gat' meer in je truth table. het kan zijn dat er nog steeds ene fout zit in je denkwijze , maar nu laat je niks meer over aan het 'toeval' en de grillen van de synthesizer.

bovendien synthetiseert dat veel denser. multiplexer zijn mooi te herleiden naar logica. Zeker als je technology onafhankelijk wilt designen. als je in een ASIC een 4 input OR nodig hebt dan staat daar een 4 input or. in een FPGA kan het zijn dat er alleen 3 inpt ors zijn en dan moet er bij te RTL expansie nog een stap gebeuren (2 gecascadeerde ors ). het kan zijn dat bij die insertion ook nog iets gebeurt met niet afgedekte condities. en dat zijn moelijke problemen om te vinden.

je kan in Quartus ook daar het schema van opvragen. als je in die RTL viewer gaat zien zul je onder de 'view RTL' nog 3 andere opties zien. de onderste : post mapping. dat tootn je ECHT hoe het in de fpga verbonden is. het is voldoende een andere famileie te kiezne ( bijvoorbeeld van een cyclone naar een stratix switchen en dat circuit komt er gans anders uit te zien.

ik zit nu paar dagen met asic designer naast mij en heb al meer geleerd dan in 4 maand boekskes lezen. ook IEEE1364 is een hele interessant document. jammergeneog niet vrij en beetje 'droog' om te lezen. maar het verschaft inzicht in hoe de synthesizers aan de slag gaan.

ik zla maar niet beginnen over metastabiliteit zekerst bij verschillende klokdomainene ...

potverpillepap ! eerst moeten goe din memory krabben om mij te herinneren wat ik allemaal neergepoot had , dat terug ingetikt....al die ASCII tekekningskes hermaken.... dan gezien dat er een fout in de bb tags zat , ondertussen had er iemand teruggepost teruggepost , dan mijn eigen gequoted...

hopelijk ist nu weer in orde. en laat mijn origineel maar staan. kan ik eens lezen of ik goed zat ..

@ de mods : trek nu eerst nog ne keer ne backup he ... if int vervolg : eerst ne backuo trekken alvorens te 'mod'deren met het forum >:p .

ik kan nie garanderen dat ik het mij nog eens kan herinneren ... -warranty void when read -

[Bericht gewijzigd door free_electron op woensdag 14 november 2007 22:59:51 (23%)]

Op 14 november 2007 22:55:25 schreef free_electron:
potverpillepap ! eerst moeten goe din memory krabben om mij te herinneren wat ik allemaal neergepoot had , dat terug ingetikt....al die ASCII tekekningskes hermaken.... dan gezien dat er een fout in de bb tags zat , ondertussen had er iemand teruggepost teruggepost , dan mijn eigen gequoted...

hopelijk ist nu weer in orde. en laat mijn origineel maar staan. kan ik eens lezen of ik goed zat ..

@ de mods : trek nu eerst nog ne keer ne backup he ... if int vervolg : eerst ne backuo trekken alvorens te 'mod'deren met het forum >:p .

ik kan nie garanderen dat ik het mij nog eens kan herinneren ... -warranty void when read -

Zo heb je niets, en zo heb je het dubbel

ik zie in de topiclog ook geen enkel spoor van een actie waarbij er iets gedelete is door een mod... dus moet je het zelf geweest zijn

@ fotoopa,

In een DFF zoals de 7474, is vrijwel altijd gewoon gedefinieerd wat er gebeurt als je zowel de SET als de RESET actief (=laag) maakt.

Op bladzijde 3 van het datasheet zie je onderaan in table 1 dat Q hoog wordt als de zowel de SET als de RESET actief (laag) zijn. Wat Q betreft is de "SET" dus overheersend. (wat de !Q uitgang betreft is de RESET overheerseend).

Vanuit een theoretisch oogpunt valt er natuurlijk niks te zeggen over wat "eigenlijk zou moeten". De implementatie blijkt een bepaald gedrag te vertonen, en dat wordt dan in het datasheet beschreven en tot "wet" verheven.

Op 14 november 2007 23:45:37 schreef Jeroen Boere:
ik zie in de topiclog ook geen enkel spoor van een actie waarbij er iets gedelete is door een mod... dus moet je het zelf geweest zijn

behalve dat het topiclog een groot gat bevat tussn 18u00 en 22u15 zeker ...

Op 15 november 2007 00:56:21 schreef free_electron:
[...]
behalve dat het topiclog een groot gat bevat tussn 18u00 en 22u15 zeker ...

gheghe... topiclog is leeg...

Op 15 november 2007 00:44:54 schreef rew:
@ fotoopa,
In een DFF zoals de 7474, is vrijwel altijd gewoon gedefinieerd wat er gebeurt als je zowel de SET als de RESET actief (=laag) maakt.
Op bladzijde 3 van het datasheet zie je onderaan in table 1 dat Q hoog wordt als de zowel de SET als de RESET actief (laag) zijn. Wat Q betreft is de "SET" dus overheersend. (wat de !Q uitgang betreft is de RESET overheerseend).

Dat is afhangkelijk van de fabrikant en verschilt ook tuusen de familie's 74LS74, 74HC74 enz.
deze datasheet geeft duidelijk aan dat het niet stabiel is
Maar oké, mijn hoofdbedoeling was te weten hoe het in de verilog compiler van Quartus zou verlopen.

Maar ondertussen is mijn bericht gedeeltelijk verloren gegaan maar zo erg is het ook weer niet.

module flipflops
(
input		clk,
input		asetn,
input		aresn,
input		d_in,
output	reg	d_out
);


always @ (posedge clk or negedge asetn or negedge aresn)
begin
  if (!aresn) d_out <= 0;
    else if (!asetn) d_out <=1;
      else d_out <= d_in;
end
endmodule

Door de RTLviewer heb ik de oplossing reeds zelf gezien.
mede door deze beide beelden:

Het schema wordt bepaald door de volgorde van de verilogcode en verklaar daarmee ook meteen de resultaten van de simulator. Dit 2de plaatje komt door het omwisselen van de volgorde van de asetn en aresn regels:

Door de gate die ertussen komt is het resultaat van de simulator perfect te begrijpen.

Verilog programma's schrijven gaat nog beter als je ook begrijpt hoe de compiler het oplost. Dit was wat F_E ons ook wilde aangeven en idd dat helpt ons weer een stuk vooruit.

Op 15 november 2007 02:15:53 schreef Jeroen Boere:
[...]

gheghe... topiclog is leeg...

De laatste reactie waarvan ik een mailtje kreeg was van FlipFlop om 20:21:01 en die zou moeten komen na de reactie van REW van 16:44:51 (en natuurlijk na dat Free elektron verhaal...)

Daarnaast kon ik ook niet op circuitsonline terecht gister avond...

Nogal jammer allemaal. Ik hoop dat de betreffende posters hun verhaal alsnog willen plaatsen (en kunnen herinneren uberhaupt ).

Ik zeg ook weer eens wat. Topic gaat meteen dood