CPLD-FPGA eenvoudige voorbeelden.

Op 13 november 2007 11:07:14 schreef rew:

Ik krijg trouwens, altijd een aantal timing violations bij de voorbeeld designs, maar het werkt wel. Is dat bij jou ook zo?

Ja heb ik ook maar als je het programma draait blijkt het toch altijd te werken.

Spijtig dat er geen output verbonden is met de 2de groep van de clockingangen op de FPGA. Zo kon ge gemakkelijker een nieuwe lage clock aanmaken of een andere PLL gebruiken. Vroeger maakt ik altijd zo een harde verbinding en heb dat heel veel gebruikt.

Voor CPLD gebruikers die weinig macro cellen hebben zou ik een 32 Khz xtal aanbevelen. Dan moet je niet zoveel delers plaatsen om trage tijden te meten.

@foto opa:

Ik heb het bord gister besteld, en tevens mijn inschrijving bij de TU gemaild. Het is goedgekeurd, en het bord is al opgepikt door fedex. Het zal dus morgen wel thuis zijn.

Gr. Rik

[Bericht gewijzigd door Rikkepic op dinsdag 13 november 2007 11:59:43 (20%)]

Oh dat gaat dus ook heel snel met die goedkeuring!

In ieder geval is de DE2 aan studentenprijs echt een supergoede keuze! Ik had ook wat getwijfeld maar aan de volle prijs is de meerwaarde iets kleiner. Wel is het zo dat alle DE1 ontwerpen zonder meer ook op de DE2 boards draaien.

Voor nieuwe FPGA gebruikers die de DE1 kunnen betalen is dit de beste prijs/prestatie board die ik momenteel ken. Als je eens ziet hoeveel de eindkost is van de huidige FPGA BlueBird board samen met een USB blaster dan zit je al boven de 70% van een DE1 board die echt veel meer waarde heeft. Maar puur buget gezien blijft de BlueBird board ook nog een mooie plaats voorbehouden naar mogelijkheden.

De MAXII CPLD board is ook een mooi alternatief maar daar ontbreekt wat periferie als starterkit zodat je die direct moet uitbereiden, maar je hebt dan weer een kwalitatief beter afgewerkt boardje en vooral ook een USBblaster voor een lagere prijs dan de BlueBird kit. Een van de MAXII I/O connectors is trouwens volledig compatibel met de DE1/DE2.

Op 13 november 2007 09:06:04 schreef fotoopa:
@SMD lover,

Het is idd maar 91-64 macrocellen maar toch een vrij groot verschil. Nu ik goed je bedoelingen weet is er wel veel kans dat het gaat. Straks probeer ik het en heb ik nog een oplossing voor de middag dan zie je het wel. Deze namiddag ben ik niet vrij.

Denk je dat er een kans is dat het gaat passen? Prima als het in Verilog is hoor, ik ben zelf ook vooral bezig met Verilog. Tenminste dat wil zeggen dat ik het aan het leren ben

Op 13 november 2007 14:15:47 schreef SMD lover:
[...]Denk je dat er een kans is dat het gaat passen? Prima als het in Verilog is hoor, ik ben zelf ook vooral bezig met Verilog. Tenminste dat wil zeggen dat ik het aan het leren ben

Kan je even bevestigen of je oscillator 4 MHz is? Volgens je VHDL code vermoed ik vanwel. dit speeld een rol in het aantal macro cellen.

Ik heb voorlopig een versie draaiende op mijn FPGA boardje die ik dan moet omzetten naar een EPM7064S versie en voorlopig heb ik voldoende cellen om ook de seconden weer te geven, waarschijndelijk zelfs tot op de 1msec maar dat moet ik nog even testen. mijn oscillator is 50 MHz en daarom verbruikt hij meer cellen. Ik moet nog wat aan de random generator sleutelen maar anders zou hij blijkbaar werken.

Ja mn oscillator is 4MHz. Jij hebt inderdaad wat meer macrocellen!
Had ik dat ook maar...

Oké maar met die 4 Mhz en je EPM7064 zal het wel lukken. Ik doe wat verder, moest eerst deze namiddag boodschappen doen maar gezien het slechte weer is dit uitgesteld. Ik test nog wat verder, zet het dan om voor je I/O en kijk of het gaat met het aantal cellen maar vanaf dat punt kan ik het niet meer testen zonder hardware. Je moet dan enkel de pinnen juist zetten volgens je hardware om te runnen.

Op 12 november 2007 19:41:21 schreef SMD lover:
Beste fotoopa,

uwen url werkt niet. dat zijn altijd chinese tekens die doorkomen.

en nee latticce is niet dood. http://www.latticesemi.com/

Op 13 november 2007 08:25:13 schreef Jochem_S:

@free: in software gebruik ik in zo'n geval liever case statements, maar jij zegt dus eigenlijk dat een compiler dit beter zal verwerken?
Wat betreft onafgedekte condities: je kunt in een if-elseif-elseif-elseif... constructie natuurlijk ook gewoon altijd een else op het einde zetten waarin je default staat.

het houdt alleen steek als je inderdaad in hardware 'denkt'. dit ding is eigenlijk een omgekeerd 'if' je moet het zien als een 'except' en van onder beginnen lezen.

als je complexe genestte if-then -else if - else statements hebt ka het gebeuren dat er ergens een latch inferred wordt ( het is voldoende dat je ergens een mogelijk path vergeet en het is prijs. )

met de paralell if constructie kan dat niet gebeuren.

hoe lager je komt in de lijst hoe hoger de prioriteit. voordeel is dat geimplementeerd wordt als een tros multiplexers. ( wat perfect in lookup table past. met andere woorden dat mapt perfect op zowel FPGA als ASIC. )

je moet het zien als volgt

out <= out;
if (out !=0) <= out -1;
if (preset ) out <=7;
if (reset) out <=0

out is out , behalve als out nog geen nul is : dan moet er 1 af , behalve als preset hoog is , dan moet out 7 worden en dat , behalve als reset hoog is : dan moet out nul worden.

die constructie hierboven ontplooit zich dus mooi naar een nest flipflops met multiplexers ervoor.
bovendien is het veel minder tikwerk ook. en er is geen kans op ambiguiteit. en de compiler kan veel betere analyseren wat er moet gebeuren. een synthesizer is een verschrikkelijk dom ding ( veel dommer dan bijvoorbeeld een c-compiler ). hij is alleen goed in het maken van multiplexer ( die mooi evalueren naar boolean formules en den perfect plat te kloppen zijn ) . Das ook een van de redenen dat een case statement compacter landt dan zijn equivalent in if then ese constructies.
grote compilers ( zoals synopsys ) hebben daar minder last van ( je betaalt er ookvoor ... ) maar de 'freebies' hebben daar wel last mee.

bovendien is de logica die gebouwd wordt simpeler te volgen. je kan in Quartus de RTL etlist opvragen. dan zie je daar echt in scheme astaan wat je geschreven hebt. als je dan de post mapping opvraagt dan zie je exact hoe het intern in de fpga landt. ik heb gisteren een geanse dag zitten 'tunen' op een relatief klein blok spaarde ik haaft de 1/3 uit. maar het grote verschil zat hem in timing. circuit was ook 1/3 sneller !. van 130 MHz max naar bijna 180 MHz... en ik had 150 nodig ...

zo zijn er nog truukjes :
een decoder maken:

bijvoorbeeld 1 uit 8

input [2:0] code;
output [7:0] decode;

assign decode = (8'd1 << code)

das gegarandeerd dat dat in een lut landt.

heel veel heb je ook een systeem wat moet trippen op een 'edge'

input detect
reg [1:0] edge_detect

edge_detect <= {edge_detect[0],detect}

if (edge_detect == 1) huppekee

bij elke clock wrdt de input gesampeld. in rust is edge_detect dus leeg. bij de eerste sample zit er dan 01 in. en dan tript de detector ( if edge_detect ==1 )
als 'detect' nog steeds hoog is bij de volgende klokslag zal er 11 in edge-detect staan : de detector tript nu niet meer.

[Bericht gewijzigd door free_electron op dinsdag 13 november 2007 16:28:45 (26%)]

@SMD lover,
Ik heb je opgave geschreven in verilog. Van je structuur blijft niets over.

Ik heb alles getest op de bluebird FPGA board maar ik moest daar een en ander bijpassen vanwege de hardware zodat die beduidend meer LE's gaat gaan verbruiken.

Maar dan heb ik het omgezet voor je EPM7064 en daar bekom ik 60 macro cellen voor:

module reactie
(
  input	        clk_4mhz,
  input	        MS1,
  output	A,
  output	B,
  output	C,
  output	D,
  output	E,
  output	F,
  output	G
);

Ik heb je decimal punt niet gebruikt omdat ik andere tekens gebruik van de display om de statussen aan te tonen.

Zo komt er bij powerup de letter P op het display.
Daarna kun je eenmaal drukken en kom je in het programma terrecht dit is de idle toestand en wordt aangeduid met 3 horizontaale streepjes op het display.

Nogmaals drukken start je gevraagde programma en wordt aangeduid met 1 horizontaal streepje op het display.

Na een random tijd wordt een speciaal character getoont een soort hoge n dit is het teken voor je reactie, dus opnieuw drukken.

De rest verloopt zoals gevraagd maar nu zijn er 4 digits die na elkaar verschijnen in de volgorde:

sec, 100ms, 10ms en msec

Door telkens te drukken zie je ze verschijnen op je display.
Ben je rond dan komt terug het idele teken waarna er een nieuwe cyclus kan gestart worden. De powerup P zal je niet meer zien want de powerup is voorbij.

Wat moet je nu nog doen:

Het archieve project restoren
De pin nummers toekennen, onderaan de source zie je een tekening hoe de 7 segment is aangesloten.
DP is er niet meer
De drukknop ingang verwacht slechts 1 signaal die actief laag is ( drukken moet een nul geven)

Dit alles in 60 macro cellen en ik hoop geen fouten gemaakt te hebben tijdens het omzetten van de ene hardware naar de andere zonder deze laatste te kunen testen.

Wil je persee je DP gebruiken dan heb je nog 4 macro cellen over dus ruim genoeg.

Het volledige project kun je hier downloaden

Ik heb ook de versie voor de BlueBird FPGA board gemaakt. Omdat er hier 4 digits beschikbaar zijn komt het resultaat van de reactiesnelheid meteen op de 4 digit display.
voor de rest is de werking als hierboven.
Gebruikte toets is MS1.
De FPGA versie hier downloaden . Deze versie staat ook online op mijn download pagina.

@fotoopa: Zo, das weer service van de zaak! En de vrouw zonder boodschappen.

@free: maar een case-statement zou net zo mooi uitpakken begrijp ik?

Op 13 november 2007 16:21:51 schreef free_electron:
[...]
zo zijn er nog truukjes :
[...]

Well, there you lost me. Ik kan nog geen steek Verilog en om eerlijk te zijn ben ik ook aan het vechten om het niet te gaan leren voor ik VHDL in de basis onder de knie heb. Het is verleidelijk met al die mooie voorbeelden hier, maar ik ga er vanwege m'n werk meer aan hebben als ik nu even doorzet met VHDL.

ach ,der zijn verilog to vhdl tools tegenwoordig.

verilog erin , vhdl eruit , met behoud van commentaar en alles.
( en omgekeerd ook )

bij vhdl is er meer prutswerk aan de syntax dan aan verilog. het gaat hem om het 'digitaal ontwerp' zelf. je kan perfect de syntax van die talen ond er de knie hebben maar nog niet weten hoe je ene flankdetector maakt , of wanneer je iets moet pipelinen en wanneer niet... en daar helt vhdl of verilog niks bij.

je bent beter af met verilog. je kan je meer concentreren op het design zonder al de syntactische vingerkramp pietluttigheden te moeten oplossen.

enfin

nog iet :
als je FPGA's hebt met ingebouwde PLL's. gebruik ze !

Ga nooit zelf een clock afdelen ! het is dan namelijk niet meer gegarandeerd dat de afgedeelde klok correct propageert over gans de chip. als je dat via de PLL doet worden de clocknets gebruikt en ben je van de skew vanaf ! heel belangrijk.

@ jochem : juist. synthesiserz hebben graag case statements. daar is alles duidelijk gedfinieerd ( maar vergeet uwe DEFAULT niet , of het is weer koekebak ! )

Een paar dagen vrij, en dan gaan we wat stoeien met CPLD's van Xilinx. Ik gebruik ISE webversion.

Ik heb onderstaande source gemaakt (sabel me aub niet neer voor onjuistheden, het is de eerste keer dat ik iets bak met verilog)

module PWM_V1a(clk50, pix_sel, sub_pix_sel, pixel_clk, pix_data, red, green, blue, pixel);
	input clk50;

	input [1:0] sub_pix_sel;
	input pixel_clk;
	input [7:0] pix_data;
	input [2:0] pix_sel;
	output red;
	output green;
	output blue;
	output [7:0] pixel;

	reg [7:0] counter;
	reg [7:0] pwm_duty [2:0];
	reg pixel;
	reg red;
	reg green;
	reg blue;
	

	always @(posedge pixel_clk) begin
		case(sub_pix_sel)
			0: pwm_duty[0] <= pix_data;
			1: pwm_duty[1]	<= pix_data;
			2: pwm_duty[2] <= pix_data;
		endcase
	end
	
	always @(posedge pixel_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
	end
	
	always @(posedge clk50) begin
		counter <= counter + 1'b1;
		red <= pwm_duty[0] > counter;
		green <= pwm_duty[1] > counter;
		blue <= pwm_duty[2] > counter;

	end


endmodule

ik krijg daarbij een fout die ik niet kan verklaren. in iMPACT heb ik netjes alle nets aan een I/O gehangen. en toch komt de fout naar voren.

Tevens staat er de fout aangaande use_dsp48... geen idee waar dit vandaan komt. ik refereer nergens naar iets wat op dsp48 lijkt.

de fout:

WARNING:Xst:2734 - Property "use_dsp48" is not applicable for this technology.
WARNING:Cpld:1007 - Removing unused input(s) 'pix_sel<0>'.  The input(s) are
WARNING:Cpld:1007 - Removing unused input(s) 'pix_sel<1>'.  The input(s) are
WARNING:Cpld:1007 - Removing unused input(s) 'pix_sel<2>'.  The input(s) are

Op 13 november 2007 20:43:30 schreef free_electron:
bij vhdl is er meer prutswerk aan de syntax dan aan verilog. het gaat hem om het 'digitaal ontwerp' zelf. je kan perfect de syntax van die talen ond er de knie hebben maar nog niet weten hoe je ene flankdetector maakt , of wanneer je iets moet pipelinen en wanneer niet... en daar helt vhdl of verilog niks bij.

Ik bekijk ook zeker de voorbeelden om de design-truken en alles te doorgronden, ik zie allemaal prachtige tips voorbij komen. Alleen is het voor het begrijpen van de voorbeelden vaak toch handig om de bijbehorende taal wat te kennen.

je bent beter af met verilog. je kan je meer concentreren op het design zonder al de syntactische vingerkramp pietluttigheden te moeten oplossen.

Was het maar zo simpel. Op het werk gebruiken we gewoon VHDL. Punt. Een converter lost natuurlijk niet de praktische problemen op (even meekijken met een collega, even een review doen, etc).

Er zitten verschillende probleem gevallen in maar eerst moet minstens de syntax juist zijn.
Probeer even het eerste gedeelte aan te passen:

module PWM_V1a
	(
	clk50,
	pix_sel,
	sub_pix_sel,
	pixel_clk,
	pix_data,
	red,
	green,
	blue,
	pixel
	);
input 		  clk50;
input 	    [1:0] sub_pix_sel;
input 		  pixel_clk;
input 	    [7:0] pix_data;
input 	    [2:0] pix_sel;
output 	reg	  red;
output 	reg	  green;
output 	reg	  blue;
output 	reg [7:0] pixel;
reg         [7:0] counter;
reg         [7:0] pwm_duty [2:0];

Hiermee zijn de syntax fouten er al uit.
Maar er zijn nog verschillende andere toekenningen die waarschijndelijk niet zullen geven wat je bedoelt.
Deze regel vb:

reg [7:0] pwm_duty [2:0];

hier begrijp ik niet wat je wilt?

een en ander getweaked.

`default_nettype none
// eerst efkes verkeerde definities blokkeren : als je 
// iets gebruikt wat je vergeten definieren hebt 
// ( tikvauten ) stopt de compiler.

module PWM_V1a(
	input            clk50, pixel_clk, 
	input      [1:0] sub_pix_sel,
	input      [7:0] pix_data,
	input      [2:0] pix_sel,
	output reg       red,green,blue,
	output reg [7:0] pixel
);

// voila. zo hoef je op geen 35 plaatsen gaan zoeken over
// weke signalen het gaat, of ze wires of registers zijn 
// en hoe breed ze zijn. en je hebt geen vodden doordat 
// ze in de header anders zijn dan in de module zelf 
// ( big no-no ! )

reg [7:0] counter;
reg [7:0] pwm_duty [2:0];
	
always @(posedge pixel_clk) begin
	case(sub_pix_sel)
		0: pwm_duty[0] <= pix_data;
		1: pwm_duty[1]	<= pix_data;
		2: pwm_duty[2] <= pix_data;
                default : // en hier ?
	endcase
     
/*        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
*/ 
// bovenstaande gaat mis ( doet niet wat jij denkt ... )
// ik veronderstel dat je wilt dat er slechts 1 output 
// hoog wordt ? je kent nooit een nul toe in 
// bovenstaande. de flifplops, (tm)(r)(c) f_e 2007 :p, 
// kunnen alleen geset worden 

// dus ofwel
    case(pix_sel)
        0: pixel <= 8'b0000_0001; // _ hoeft niet
        1: pixel <= 8'b00000010;  // zonder _
        2: pixel <= 8'h04         // in hex
	3: pixel <= 8'd8          // in decimaal
	4: pixel[7:0] <= 8'd16;   // heel expliciet
	5: pixel <= 32;           // veeg er mijn botten aan : laat de compiler het maar scalen.
	6: pixel <= 8'h40;
	7: pixel <= 8'h80;
		endcase
	
// ofwel dit :

      pixel <= (8'd1 <<pix_sel)  // 0000_0001 met 'pix_sel' plaatsen naar links geschoven.

	always @(posedge clk50) begin
		counter <= counter + 1'b1;
		red <= pwm_duty[0] > counter;
		green <= pwm_duty[1] > counter;
		blue <= pwm_duty[2] > counter;

	end


endmodule

Op 13 november 2007 21:38:47 schreef fotoopa:
reg [7:0] pwm_duty [2:0];

hier begrijp ik niet wat je wilt?

das een array van arrays.

met andere woorden : een array van 3 (2 tot 0) variabelen die allemaal pwm_duty heten en elk 8 bit breed zijn [7:0].

LET OP !!! dit kan ALLEEN in verilog 2001 en hoger !! de orignele IEEE1364 kan dat NIET !

voor mensen die quartus gebruiken : in de projcet settings aangeven dat je V2001 gebruikt ! anders krijg je een tros errors !

Op 13 november 2007 20:53:24 schreef Jeroen Boere:
WARNING:Xst:2734 - Property "use_dsp48" is not applicable for this technology.

dsp48 is een hardware block in oa de Virtexen en ook Spartan als ik het goed heb. Het is een blok waar oa een multiplier, adder ed in zit. Dit om efficient DSP functies te kunnen bouwen. Waarschijnlijk heb je ergens een optie "use dsp48" aan staan en gebruik je een FPGA waar die macro niet in zit.

@ fotoopa: Zoals FE zei: dit is een array (afgekeken van een ander voorbeeld in dit lange topic)

@F_E: bedankt! het definiëren van inputs is op jou manier overzichtelijker, en sneller te maken. Nu compileert hij zonder problemen (moest wel wat ;, END, etc extra zetten, maar dat geeft niets )
Is me nu een stuk duidelijk geworden.

@flipflop: kan kloppen dat m'n compiler start met mekkeren, gebruik namelijk een CPLD ipv FPGA

maar ik kan me nergens herinneren dat ik ergens iets van dsp48 aangezet heb

Nog even over dit:

teller <= teller

Zijn er situaties waarbij deze toevoeging ook echt uitmaakt? Want impliciet geld toch al dat een register hetzelfde blijft? Misschien dat het voor de duidelijkheid handig is (al is het een wat vreemd statement), maar als ik zo even wat kleine testjes doet lijkt het niet uit te maken of het er nou wel of niet staat. Het blijft dezelfde RTL geven.

@ F_E gaat die niet fout?

always @(posedge clk50) begin
counter <= counter + 1'b1;
		red <= pwm_duty[0] > counter;
		green <= pwm_duty[1] > counter;
		blue <= pwm_duty[2] > counter;
end

Je update de counter terweil je tegelijkertijd kijkt naar de counter.

Dus in dit geval kan het zijn dat in de zelfde cycle duty[0] vergeleken wordt met counter en duty[1] en duty[2] met counter+1 of andere volgorde simpel omdat de counter "te laat update?

Kun je dan niet beter "kijken" naar de counter buiten de always (posedge clk50) statement?

Dus

always @(posedge clk50) 
begin
                counter <= counter + 1'b1;
end
always
begin
		red <= pwm_duty[0] > counter;
		green <= pwm_duty[1] > counter;
		blue <= pwm_duty[2] > counter;
end

Je hebt nu dat red green en blue pas veranderen als de counter ook werkelijk veranderd is... maar (of zie ik het fout?)

Je moet uitkijken met het niet definieren van gevallen.

Je zag dat jeroen zo nu en dan een 1 toekende, en verder niks er over zei. Hij had eerst gedacht dat z'n registers dan nul zouden zijn/worden. Hier is kennelijk gedefinieerd dat als je niks toekend, ze dezelfde waarde zullen houden.

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".

Dus als je

case (somevar[2:0])
  0:out=0;
  1: out=1
  2: out=1;
  4: out=0;
  6: out=1;
  7: out=1;

opgeeft, dan is OR (somevar[0], somevar[1])de makkelijkste implementatie. Die geeft dan ook out=1 als in=3 of 5.

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.

Op 13 november 2007 23:04:24 schreef surge_me:
@ F_E gaat die niet fout?

always @(posedge clk50) begin
counter <= counter + 1'b1;
		red <= pwm_duty[0] > counter;
		green <= pwm_duty[1] > counter;
		blue <= pwm_duty[2] > counter;
end

Je update de counter terweil je tegelijkertijd kijkt naar de counter.

Nope. Je moet een beetje weten hoe bijvoorbeeld een teller werkt. De teller is een register, die iedere keer wat er aan de ingang aangeboden op de klokflank overneemt.

De truuk: counter <= counter + 1; betekent dus dat er combinatorisch "counter+1" wordt uitgerekend, en dat aan de ingang klaargezet om op de volgende klokflank het register in te gaan. Tijdens de hele klokperiode staat "counter" gewoon nog op een precieze waarde.

De assignments aan red, green en blue, werken op dezelfde manier. Tijdens de klokperiode is tijd om de combinatoriek die pwm_duty[0] < counter uitrekent te laten stabiliseren, en pas op de volgende clock gaat dat het registertje "red" in.

Mischien makkelijker uitgelegd: Alle statemtents binnen zo'n always @ posedge gaan ECHT TEGELIJK. dus red krijgt op PRECIES hetzelfde moment een nieuwe waarde als "counter". De vergelijking is dus met de oude counter, en nooit met counter+1.

je gebruikt beter haakjes ... leest makkelijker.

red <= (pwm_duty[0] > counter);
green <= (pwm_duty[1] > counter);
blue <= (pwm_duty[2] > counter);

eigenlijk kijk je of pwm_duty groter is dan counter

ik meen me te herinneren dat '>=' iets kleiner synthetiseert dan '>'

@ surge me :

<= kan je alleen gebruiken in een edge triggered event.
dus dat lukt niet.
bovendien maak je combinatorische circuits aan op dat moment. en comparatoren glitchen gelijk zot !. dat gaat me een geflikker van jewelste zijn op die leds.

door dat op te nemen in het CLK event worden die outputs gelatcht. dus van al die rotzooi ben je vanaf.

[Bericht gewijzigd door free_electron op woensdag 14 november 2007 00:08:54 (37%)]

Op 13 november 2007 23:36:10 schreef rew:
[...]
PRECIES hetzelfde moment een nieuwe waarde als "counter". De vergelijking is dus met de oude counter, en nooit met counter+1.

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..

Op 14 november 2007 00:06:50 schreef free_electron:

@ surge me :

<= kan je alleen gebruiken in een edge triggered event.
dus dat lukt niet.
bovendien maak je combinatorische circuits aan op dat moment.

Ja maar het updaten van die clock is edge trigerd .. always@(posedge)..

En als je combinatorische logica voed met een geklokt signaal maakt het volgens mij niets uit