CPLD-FPGA eenvoudige voorbeelden.

opgelet ! bij CPLD's is dat inderdaad zo. maar bij een FPGA NIET !. de configuratie bitstream loopt namelijk door de flipflops ... ze gebruiken de flipflops zelf als een deel van de shifter. de toestand daar is onbekend. je MOET initialiseren.

bij een CPLD heeft elke fuse zijn eigen bit. de boel wordt parallel geladen. bij een FPGA niet. daar wordt de boel serieel ingeschoven.

enfin.

hier is een simpeler blokje code

module piano_toetsen
	(
        input              RESET,
	input	    [3:0]  KEY,
	output	reg [3:0]  LED
	);

assign KEY_HIT = & KEY;
always @( ~KEY_HIT , RESET) begin
   if (RESET) LED <= 4'b0001; 
   else 
   case (KEY)
     4'b 0111,
     4'b 1011,
     4'b 1101,
     4'b 1110 : LED <= ~KEY;
     default : LED <= LED ;
   endcase
end
endmodule 

en het ontdenderd meteen ook de ingangen.
compileer dit effe en doe me dan de volgende lol.

na compilatie : klik op Tools - Netlist Viewer - RTL viewer.

er floept een venster open. je gaat daar dat blokje zien staan. als je met je muis over dat blokje gaat zul je de cursor zien veranderen
dubbelklik op het blokje. je krijgt nu een mooi intenr schema te zien van wat de synthesizer gemaakt heeft.

Pas dan de code als volgt aan :

module piano_toetsen
	(
        input              RESET,
	input	    [3:0]  KEY,
	output	reg [3:0]  LED
	);

assign KEY_HIT = & KEY;
always @(negedge KEY_HIT ,posedge RESET) begin
   if (RESET) LED <= 4'b0001; 
   else 
   case (KEY)
     4'b 0111,
     4'b 1011,
     4'b 1101,
     4'b 1110 : LED <= ~KEY;
     default : LED <= LED ;
   endcase
end
endmodule 

zou perfect moeten werken... maar doet het helaas niet.
ga terug naar tools , netlist viewer RTL viewer.

schijnt te kloppen. maar als je goed kijkt zie je waarom het niet werkt.
de flipflops worden nu geclockt vanuit de AND gate die op KEYS zit.
de flipflops zijn echter alleen ge-enabled vanuit de grote decoder en OR gate.

de looptijd van de signalen doorheen de decoder is langer dan de looptijd door de AND gate.
bijgevolg worden de flipflops pas ge-enabled als de clockpuls al lang voorbij is !

dit is een voorbeeld van correcte code die in de praktijk totaal niet werkt omdat je tegen andere problemen aan loopt.

die RTL viewer is heel interessant als je aan het expermineteren bent. je krijgt een redelijk goed diagramma van wat er nu precies in de chip zit. ( wat daar staat is geen gewoon schema meer, maar effectief wat er in de chip geprogrammeerd zit. dus met alle minimalisatie en mapping op de aanwezige blokken. )

In iedere geval een duidelijk voorbeeld! Ik had die functie eigenlijk nog niet gebruikt. weer wat bijgeleerd!

Maar ik werk toch altijd anders, eigenlijk ga ik bijna altijd alles gaan clokken, dit vergt meer LE's maar het werkt toch beter.

In de meeste gevallen zijn er voldoende LE's in je chip. En ja mijn voorbeeld was ook ontdenderd gezien ik enkel de flank nam. moest die toch nog langer denderen dan blijft hij toch correct gestuurd want eenmaal houden blijft gehouden tot een andere switch's ergens gedrukt is. Je mag zelfs de eerste drukknop ingedrukt blijven houden en naar de tweede gaan, dan nog werkt het zoals vooropgesteld.

In verilog kan je een initial block maken:

initial begin
  reg_x = 5;
end

Of gewoon direct:

reg [4:0] reg_x = 5;

Is meer iets voor simulatie maar volgens mij wordt het ook gesynthetiseerd wanneer mogelijk. Ik had het net eens in een simpel PWM dingetje getest op de counter maar in de simulatie gaat de counter dan opeens achteruit lopen! Heel vaag. Als ik de initialisatie weglaat loopt ie gewoon weer vooruit zoals ontworpen.

Op 6 september 2007 17:05:20 schreef fotoopa:
Ik veronderstel dat je het hebt over de CFM, UFM blokken. Want de CPLD zelf mag je zoveel als je wilt herprogrammeren, daar staat niet zozeer een limiet op of die is heel hoog. Het gaat hem enkel over die interne flash zelf en de configuratie blok die zorgt voor de interface met je CPLD. Maar zo zal je het wel gebruikt hebben.

Het CFM blok is toch de configuratie? Volgens mij kun je dus de CPLD maar 100 keer (gegarandeerd) configureren.

Op 6 september 2007 18:51:40 schreef madwizard:
[...]
Het CFM blok is toch de configuratie? Volgens mij kun je dus de CPLD maar 100 keer (gegarandeerd) configureren.

Nee ik geloof het niet. Die CFM blok is direct verbonden aan de flash en wordt geprogrammeerd samen met je type acces dat je met die flash configureerd. Eenmaal die config gedaan is moet je daar niet meer aankomen, vb lezen parrallel 8 bit breedte in een blok van 1K. Je mag nu de flash inhoud wijzigen zonder die flash configuratie te wijzigen. Daarom zijn er afzonderlijke instellingen in de programmer. Die 100 maal slaat zeker niet op de CPLD zelf, trouwens het staat letterlijk in die voetnota voorwat die 100 beperking is.

Enfin zo zie ik het.

Uit de Quartus documentatie:

The on-chip configuration flash memory (CFM) block provides the nonvolatile storage for all of the SRAM configuration information for MAX II devices. The CFM stores the design's configuration pattern in a reprogrammable flash array. Data downloaded from the CFM at power-up configures the logic and I/O, providing instant-on operation. The CFM is programmed via the JTAG interface and cannot be edited by the user.

Dit is toch echt de configuratie volgens mij, als je een MAX II via JAM/STAPL programmeert zie je ook 'programming CFM' voorbij komen, wat ook het grootste deel van de tijd in beslag neemt, vervolgens 'programming UFM' (dat hoeft dus niet per se) maar voor de rest wordt er niets geprogrammeerd.

Op 6 september 2007 19:09:07 schreef madwizard:
Uit de Quartus documentatie:
The CFM stores the design's configuration pattern in a reprogrammable flash array.

.
Ja maar dit is voor het flash config gedeelte, niet voor de CPLD zelf. Trouwens als ik de CPLD programmeer staan die beide functie af en zou ik geen nieuwe inhoud in de CPLD kunnen krijgen..... Dat hij iets doorstuurt, kan wel maar daarom gebruikt hij het nog niet. of kun jet het daar niet afzetten, wat je wel kunt via de USBblaster/programmer.

[Bericht gewijzigd door fotoopa op donderdag 6 september 2007 19:31:40 (39%)]

Je had net heel even in je post een FAQ van Altera waar juist ook in stond dat de CFM de configuratie bevat. Maar je hebt het weer verwijderd.

Volgens mij is er geen andere manier om de MAX II te configureren dan via de CFM. Dat het vinkje niet aanstaat bij het programmeren is wat vreemd maar volgens mij wordt het toch weggeschreven, die vinkjes zijn meer om subonderdelen specifiek wel of niet te doen, als je het vinkje bij de pof aanzet gaan de andere twee (CFM, UFM) ook mee, alleen kun je ze weer uitzetten ook.

De FAQ:

Problem
Is it possible to in-system programmability (ISP) update or program a MAX® II device design in the Configuration Flash Memory (CFM) without overwriting the contents of the User Flash Memory (UFM)?

Solution
Yes, it is possible to ISP program the MAX II device design in the CFM without overwriting the content of the UFM. The opposite is also true - you can ISP program the UFM contents without overwriting the MAX II device design in the CFM. The Quartus II Programmer provides the option to individually program :

* The MAX II device design stored in the CFM block
* The entire user flash memory (UFM) block
* Or the entire MAX II device (CFM and UFM content)

Voorlopig is het in ieder geval onduidelijk maar als dit zo is moeten ze dan geen voetnota maken dat die beperking enkel voor CFM,UFM is. Het is ook heel onlogisch dat ze een device zouden maken die je maar 100 maal kunt programmeren, vooral gezien die beperking er nog nooit geweest is voor de CPLD's.

update:

Hum...
Het ziet er idd naar uit dat de CFM de flash is die de volledige configuratie bevat van de CPLD. Die CPLD zou dus ook ram based zijn waarbij de config rom ingebakken zit. hij zou bijgevolg bij powerup de config data van de CFM blok overlezen naar zijn ram en dan starten. ( rond de 300 msec)

Waarom ze dan die UFM afzonderlijk kunnen afzetten in de programmer begrijp ik niet. Die 100 maal zal wel een veilige limiet zijn maar blijkbaar wordt er maar weinig over gekakeld op de web.

Als experimenteer board zit je wel gauw aan een redelijk aantal. Enfin de tijd zal het uitwijzen Maar ik denk dat je gelijk heb. 100 maal is gegarandeerd, de rest gaan we ondervinden.

Op 6 september 2007 19:44:40 schreef fotoopa:
Hum...
Het ziet er idd naar uit dat de CFM de flash is die de volledige configuratie bevat van de CPLD. Die CPLD zou dus ook ram based zijn waarbij de config rom ingebakken zit. hij zou bijgevolg bij powerup de config data van de CFM blok overlezen naar zijn ram en dan starten. ( rond de 300 msec)

Inderdaad, het is bijna een FPGA met ingebouwde config rom. De MAX II's liggen sowieso erg dicht bij de FPGA architectuur.

Waarom ze dan die UFM afzonderlijk kunnen afzetten in de programmer begrijp ik niet.

Die UFM is voor je eigen flash data dus het is praktisch dat je dat af kunt schermen bij een update zodat je je data niet kwijtraakt.

Die 100 maal zal wel een veilige limiet zijn maar blijkbaar wordt er maar weinig over gekakeld op de web.

Is weinig over te vinden ja, wel een russisch forum waar een beetje dezelfde discussie liep. CPLDs worden in gebruik natuurlijk niet heel vaak geprogrammeerd, maar tijdens de ontwikkeling wel.

Als experimenteer board zit je wel gauw aan een redelijk aantal. Enfin de tijd zal het uitwijzen Maar ik denk dat je gelijk heb. 100 maal is gegarandeerd, de rest gaan we ondervinden.

Ik vind het ook vreemd dat ze er toch een ontwikkelbord voor gemaakt hebben. Ik vraag me af of terasic dit zich wel gerealiseerd heeft (hoewel ze volgens mij nauw samenwerken met altera), het is natuurlijk vrij vervelend als ze allemaal bordjes terugkrijgen die niet meer werken na 100 keer programmeren. Het zal wel loslopen, tenzij het echt een speciaal soort flash is wat lastiger in goede conditie te houden is moet het gewoon een flink aantal keren te programmeren zijn. Maar als je een ontwikkelbordje maakt weegt de garantie dat het ook zo vaak lukt misschien zwaarder.

Ik las ook ergens dat in de oudere MAX series (7000) EEPROM werd gebruikt, weet niet of dat waar is maar dat is misschien minder vaak te programmeren. Misschien dat de garantie van 100 keer iets is wat daar uit overgebleven is en niet meer van toepassing is op het flash van de MAX II, maar dat zou ook wel weer suf zijn.

T'ja ze noemen hem micro kit en spreken nergens over een beperking in het aantal keren programmeren. Ze werken idd heel nauw samen met Altera. Trouwens eerst hadden ze de nieuwste cyclone III kit bij hen staan maar die in nu gemoved naar de Altera site, terwijl ze nu recent wel een oplossing gemaakt hebben voor hun speciale HSMC connector die ze gebruikten. Nu hebben ze daarvoor een tussenprintje gemaakt om terug op de normale I/O 40 pins flatcable te komen.

Maar je gebruikt toch ook al een hele tijd die MAX II dus die zal je ook wel al een heel behoorljk aantal keren hergeprogrammeerd hebben. Enfin, ik heb 2 van die kits, het eentje is nog origineel heb hem enkel even aangelegd om te zien of het origineel testprogramma liep en weer in de doos gestoken. Ik ga de eerste kit intens gebruiken en dan zien we maar.

Spijtig dat de FPGA boardjes van xantus zo een grote vertraging hebben. Maar opzich is dit voor mij geen probleem gezien mijn voorraad aan alternatieven.

Ik heb ook gezien dat in je ander project je CPLD iets te klein is. Eigenlijk zou je het prototype moeten maken in een veel groter ontwikkelings board, zoals de DE1 of DE2 of die nieuwe met de cyclone III. Eens alles werkt kun je perfect bepalen in welke chip je het kunt implementeren. Zo werkten we vroeger ook heel veel op het werk. Dan heb je die beperkingen niet tijdens je ontwikkeling.

Op 6 september 2007 21:31:05 schreef fotoopa:
Eens alles werkt kun je perfect bepalen in welke chip je het kunt implementeren. Zo werkten we vroeger ook heel veel op het werk. Dan heb je die beperkingen niet tijdens je ontwikkeling.

Op deze manier heb ik tijdens mijn afstudeer stage de Flex10k van altera het grootste model gebruikt in de simulaties. Uiteindelijk was er dan nog ruimte voor wat andere simpelere functies die ook nodig waren op het bord in dat project.

(Helaas dat het ontwerp niet gebruikt mocht worden van de opdrachtgevers)

Als de altera op het terasic bordje niet meer te programeren is, heb ik nog altijd de bitblaster functie van het bordje. Die waarde blijft het behouden. bestel ik wel een paar andere FPGA's en programeer die.

Met dat in gedachte heb ik ook dit bordje ,wat fotoopa heeft, besteld.

[Bericht gewijzigd door jovak op donderdag 6 september 2007 23:19:26 (57%)]

Op 6 september 2007 21:31:05 schreef fotoopa:
Ik heb ook gezien dat in je ander project je CPLD iets te klein is. Eigenlijk zou je het prototype moeten maken in een veel groter ontwikkelings board, zoals de DE1 of DE2 of die nieuwe met de cyclone III.

Dat had waarschijnlijk beter geweest ja, het bordje is ook een beetje ontworpen terwijl ik het CPLD/FPGA gebeuren aan het leren was dus dan is het wat lastiger inschatten.
En devboards zijn leuk maar je zit ook met PCB layout. Al die connectors e.d. geven een andere situatie dan wanneer de ICs centimeters van elkaar af zitten op een custom printje. Zeker als het later aan anderen verkocht moet worden moet het gewoon goed in elkaar zitten

Maar goed een tweede prototype zat sowieso in de planning en dit bordje heb ik al gigantisch veel aan gehad. Op de tweede komt waarschijnlijk een EP2C5 (kleinste Cyclone II). Dat moet zeker wel voldoende zijn. Helaas alleen wel weer 1.2V nodig, een config ROM en een schone PLL voeding. Maar het is de moeite.

Later komt er misschien nog een versie die ook HD video aan kan, dat moet zo op de FPGA kunnen dan, alleen de video chip wordt anders. Vanwege de complexiteit (100 pins ipv 32, veel meer connectors, 5x zoveel stroomverbruik, lastige dissipatie met heatpad SMD packages) laat ik dat nu nog achterwege en hou ik het bij normaal PAL composiet en s-video.

HD video is inderdaad geen probleem voor een fpga. Standaard voor HD video (720p en 1080i SMPTE en ITU) draait op 74.25MHz 20bit parallel. Hedendaagse FPGA's draaien daar de hand niet voor om. Het wordt lastiger wanneer je ook 1080p wilt toepassen, dan moet je op 148.5Mhz clocken. Goed te doen hoor, maar dit vereist wel extra aandacht in de FPGA. Dan hebben we het nog niet over de PCB eisen natuurlijk.

Hoe wil je de uitvoer van HD video doen btw? HDMI? HD-SDI? Ik heb ervaring met beide formaten, dus als je vragen hebt stel ze gerust

Op 5 september 2007 17:05:37 schreef free_electron:
nog een blokje ; een 7 segment decodertje wat 0..9 en ook ABCDEF laat zien ( dus ene full hex decoder )

....

always begin
  if (ca_cc==1) segment_out = ~segment ; else segment_out = segment;
  case (data)
   //  DCBA             GFEDCBA            
   4'b 0000 : segment = 0111111;
   4'b 0001 : segment = 0000110;
   4'b 0010 : segment = 1011011;
.........

Hé je segment toekenning is hier niet als binaire waarde gedaan maar als integer.
beter zal zijn:

always begin
  if (ca_cc==1) segment_out = ~segment ; else segment_out = segment;
  case (data)
   //  DCBA                GFEDCBA            
   4'b 0000 : segment = 7'b0111111;
   4'b 0001 : segment = 7'b0000110;
   4'b 0010 : segment = 7'b1011011;
........

Daarmee stuurt hij de juiste segmenten aan. Kun je het origineel ook aanpassen zodat een gebruiker later geen probleem heeft?

Wat gaat er mis als ik de error :" Error: Top-level design entity "pwm_led" is undefined" krijg.

Bij het maken van je project geef je een top level entity naam op, waarschijnlijk heb je daar pwm_led ingevuld.

Er moet vervolgens een entity zijn met die naam wat het hoogste niveau is van het design, dus waar begonnen wordt met compileren (vergelijkbaar met een main routine of entrypoint bij het programmeren).

Je kunt een blokkenschema gebruiken als top-level entity, of een verilog module. In beide gevallen moeten ze precies zo heten als de naam die je opgegeven hebt. Bij een blokkenschema moet het bestand zo heten dacht ik, bij verilog file als top level moet de modulenaam gelijk zijn.

Bij een project heb je 3 entry's die juist moeten zijn:
- workings directory
- project name
- top-level entry

Doorgaans zijn die de naam van de map waar je programma instaat en zijn de 3 entry's dezelfde.

Heb je dit niet zo gemoemd dan moet daar een aanpassing voor gemaakt worden. Vandaar dat het altijd eenvoudiger is om de map dezelfde naam te geven als de top-level entry.

pasop de module naam moet daar ook mee overeenkomen.

in het geval pwm_led gaat het best door

- map: pwm_led
- pwm_led.v je hoofdprogramma is
- module pwm_led(......) heeft als eerste lijn van je project.

oeps, te laat afgedrukt, madwizard was voor....

Ja bedankt! dat was het.

Hier nog een kleine toepassing.

functie:

We hebben 4 druktoetsen. Daarmee gaan we 2 binaire 4 bit tellers sturen.
Toets 1 en 2 zijn voor teller_a toets1 = up,toets2 = down.
Toets 3 en 4 zijn voor teller_b toets3 = up,toets4 = down.
Teller_a stuurt de eerste 4 leds ( actief low)
Teller_b stuurt de volgende 4 leds ( actief low)

leds worden als binaire waarden weer gegeven.
Toetsen zijn antidender gemaakt via een extra register.
De input clk die 50Mhz is wordt eerst gedeeld via een 11 bit teller.

Bij zware antidender kun je de clockdeler nog meer delen of een 2de register per toets gebruiken.
Het programma:

module druktoets_teller(
	input		clk_50,	// Dit is onze standaard clock
	input		key0,	// Dit zijn onze 4 drukknopjes
	input		key1,	// Dit zijn onze 4 drukknopjes
	input		key2,	// Dit zijn onze 4 drukknopjes
	input		key3,	// Dit zijn onze 4 drukknopjes
	output		led0,	// Dit zijn onze led uitgangen
	output		led1,	// Dit zijn onze led uitgangen
	output		led2,	// Dit zijn onze led uitgangen
	output		led3,	// Dit zijn onze led uitgangen
	output		led4,	// Dit zijn onze led uitgangen
	output		led5,	// Dit zijn onze led uitgangen
	output		led6,	// Dit zijn onze led uitgangen
	output		led7	// Dit zijn onze led uitgangen
	);

reg 		key0_reg;	// register voor flank detectie knop0 
reg 		key1_reg;	// register voor flank detectie knop1 
reg 		key2_reg;	// register voor flank detectie knop2
reg 		key3_reg;	// register voor flank detectie knop3
reg	[10:0] 	clk_deler;
reg	[3:0]	teller_a;
reg	[3:0]	teller_b;

assign {led3,led2,led1,led0} = ~teller_a; // leds zijn low actief
assign {led7,led6,led5,led4} = ~teller_b; // leds zijn low actief

always @ (posedge clk_50)
begin
clk_deler <= clk_deler +1'b1;	// slowdown met onze standaard clok
end

always @ (posedge clk_deler[10])	
begin
	key0_reg <= key0;
	key1_reg <= key1;
	key2_reg <= key2;
	key3_reg <= key3;
if (key0_reg & !key0 )teller_a <= teller_a + 1'b1; // teller_a verhogen
if (key1_reg & !key1 )teller_a <= teller_a - 1'b1; // teller_a verlagen
if (key2_reg & !key2 )teller_b <= teller_b + 1'b1; // teller_b verhogen
if (key3_reg & !key3 )teller_b <= teller_b - 1'b1; // teller_b verlagen
end
endmodule

Ik denk dat ik morgen wat hardware halen(soldeerpinnen, flatcable).
Mooi is dat: tiepvauten, nieuwe syntax verilog 2001, CFM/UFM wel of geen 100 keer garantie.
Het doet me goed "doorgewinterde CPLD-FPGA mannen" ook hun twijfels hebben, het soms niet allemaal weten en daarbij van elkaar leren, net zo goed als de nieuwelingen.
Stukjes eenvoudige code om het te leren zijn zeer nuttig.
Heb vanavond zitten pielen Quartus. Dan zit je hier als eerzaam burger, weet wat een .doc, .xls, .bmp-file is en dan wordt je vervolgens doodgegooid met een serie afkortingen waar mijn managers jaloers op zouden worden.
Je begint met: piano_toetsen.v en eindigt na wat klikken met een flinke kwak aan nieuwe bestanden.
Maar goed. Ze zullen wel nut hebben en met een beetje goede wil komt er een dag dat ze onmisbaar voor me zijn.
Mannen: keep up the good work onder het motto: wie zaait zal oogsten. (Leuke afkorting voor mijn projectenmap: WZZO)

Oh ja: stel ik hang aan alle uitgangen led's. Dan zit ik al gauw aan zeg 80*20mA=~1,5A? Bakt mij chipje dan niet heel erg?

20mA door een led ? das veeeeeelst te veel.
een led licht al goed op met 5 milliampere. als je hi-eff leds gebruikt zijn die al content met 1 a 2 mA ....

over al die bestanden die gecreerd worden hoef je je niks van aan te trekken. dat is allemaal intern spul voor Quartus.

het enige wat je hoed te doen is een map aanmaken. daar creer je ene project in. dan voeg je dingen toe zoals een toplevel schema ( BDF file : block design file )
plak daarin al je pootjes ( inputs en outputs )
dan voeg je files to aan je project. .v of .vhd files of desnoods andere bdf's

voor elk blokje wat je maakt vraag je aan qaurtus om een 'symbol' aan te maken.
die symbols zet je dan in je toplevel. trekt wat draden ertussen en compileert.
dan maak je een vwf file aan ( vector waveForm ) en je simuleert de boel ( later kan je dan simlatie files maken met verilog )

eenmal de boel wertk. klik je de programmer aan en quartus zet dat in je chip.

van al die tussenfiles die gecreerd worden hoef je je niks aan te trekken. heel vele van die dingen zijn compilatierapporten en files die gecreerd worden om te kunnen interfacen met andere tools.

das wel een punt in quartus .. er zou een knop moeten zijn : kuis alle scratch files op... quartus is nogal een sloddervos. gelukkig gebruiken ze telkens dezelfde scratch files.

er zullen er waarchijnlijk wel zijn die hun wenkbrauwne optrekken als ik zeg om een schema te gebruiken als toplevel... maar het is echt heel nuttig.
je ziet mooi welk blokje er tegen welk ander blokje 'praat' en hoe de boel aan elkaar geknoopt is.
veel makkelijker dan 30.000 lijnen tektst door te lezen om dan half te snappen hoe iets aan elkaar hangt.

ik heb nu een 'serieus' blok ( 17000 Le's... de 2c35 zit na routing voor bijna 60% vol ) neemt dik 3 uur in beslag om te compileren. )
das nog altijd een top level schema. en voor bepaalde functieblokken zit daar eerst een subschema in. en daar staan dan de blokjes waarchter de nodige verilog code zit.

bepaalde andere dingen zijn dan direct zichtbaar. zoals bij voorbeel de enables van Io pinnen. dat zijn effectief TRI celletjes die daar getekend staan. de knopen op de juist manier met een lijntje aan elkaar. zo zie je direct wie er op welk moment gestuurd word. veel duidelijker dan in 35 files te gaan zien of een blok dat nu wel of niet gebruikt. je zou die tri celletjes ook in verilog kunnen stoppen. ( die TRI's worden gebruikt voor hotplugging. als er een 'break' gedtecteerd wordt schakelen al die io poten in TRI. sommige ios komen van blok 1 , andere komen van blok 2. blok drie stuurt dan weer verschillende io banken met elk hun eigen 'break' die verdeeld wordt.

veel simpeler om dat schematisch op te lossen.

die IO poten staan daar toch getekend. groeper ze per connector, zet er de buffers voor en stuur de enable poot. klaar.

onze 'grote' designers doen dat ook allemaal zo. de interne modules worden zoveel mogelijk 'geschreven' . en de modules worden dan met een schema aan elkaar gelijmd waar ook de io infrastructuur in schemavorm zit.
je wilt immers ten alle tijde zeker zijn dat de protectie mechanismes correct geimplementeerd zijn. ( je wilt niet om de haverklap je bord uitroken omdat er een cel niet op het juiste moemtn afgeschakeld word , of omdat iemand zich vergist heeft in de verilog en ergens een stuurginaal vergeten is mee te nemen in de decision logic.

wat daar op dat schema staat is zeker juist. ( is visueel veel makkelijker te controleren. )

een ander voordeel is dat je zo elk blok onafhankelijk kan testen. elk blok heeft een 'test schema en een 'test' waveform. elk blokje compileert snel en simuleert snel. eenmaal het correct werkt : symbooltje in het grote schema zetten en verbinden. tijdens de nachtelijke full compile wordt dat dan meegenomen. ik kan niet telkens 3 uur wachten om de boel te kunnen testen.

toplevel is een processorblok ( nios met alle toeters en bellen ) , ene i/o blok , een memory blok.
de nios is een blok wat uit sopc builder komt.

dat io blok is weer een schema. daar zie je de addressdecoder staan met elk 'onderdeel'. de GPIO blokken , de SIE die tegen onze chip praat , en alle andere peripherie.

ditto voor het memory blok. das een schema en daar staan dan de cache blokken ,de dprams en alle ander spul inclusief hun decoders.

als je in je verilog file de adressen definieert als 'parameter' krijg je op dat schema een mooie tabel te zien met wie er waar zit gemapt. heel handig als je later code gaat schrijven.

je hebt een mooi spiekbriefje.

Op 5 september 2007 18:00:42 schreef fotoopa:
Eigenlijk wachten we allang op je beloofde boek, maar het vergt allemaal zoveel tijd.

Misschien dat free ipv een 'papieren boek', een 'online versie' kan schrijven, met updates en gebruikersvragen? Als ik zie wat voor lappen tekst-ie hier soms inklopt...

(maar goed, ik snap wel dat je dan zit met de rechten etc...)

[Bericht gewijzigd door alex278 op zaterdag 8 september 2007 00:12:12 (13%)]

Op 8 september 2007 00:10:47 schreef alex278:
[...]

Misschien dat free een soort van 'online' boek kan schrijven, met updates en gebruikersvragen? Als ik zie wat voor lappen tekst-ie hier soms inklopt...

voor de stats: hij is bezig met een boek

Op 8 september 2007 00:11:55 schreef Jeroen Boere:
[...]

voor de stats: hij is bezig met een boek

Ja, weet ik. Zie edit. Maar als ik zelf teksten schrijf dan gaat dat stukken makkelijker in interactie met iemand anders, dan dat ik achter m'n bureautje briljant moet gaan zitten wezen, en de ultieme afleiding of beschrijving van weetikveelwat moet opschrijven.