Op 8 september 2007 17:16:28 schreef RES:
[...]

Zet de voor en nadelen maar op een rij met de PIC/AVR.
PIC/AVR zijn.

- voordelig (1 a 2 euro voor de kleintjes)
- goed verkrijgbaar (AVR in mindere mate)
- vrij snel
- flexible (ADC, UART, Analog Comparator, TWI, USI, PWM)
- DIP behuizing (even snel wat in elkaar draaien op gaatjesprint)
- veel projecten en software online te vinden

das kwatsj ...

- fpga kost ook haast niks.
- zijn goed verkrijgbaar
- veeeeeeel sneller dan pic of avr of eendert wat
- DIp is voor 'ouwe krotters'
- ook vele projecten te vinden en vele software.
- ook flexibel. fpga is wel digitaal ding. probeer eens op je PIC een I2S interface te maken ?... dat wordt ene ramp. in FPGA ? is direct geklonken.

houdt het steek ? neen. je mag cpu niet vergelijken met fpga. is totaal anders.

waarom zo weinig gebruikers ? dan hebben we het over hobby .. in de industrie wordt fpga evenveel gebruikt als CPU ( zoniet meer )

het probleem bij fpga is dat de drempel hoger is en de leercurve steiler. maar dat was in het begin ook met cpu's zo.

maar tegenwoordig zijn er ook goede devkits ( terasic bordje voor 50 euro . is de kostprijs van pic starterkit )

het verschil is ook dat vor cpu er 'simpele' dingetjes zijn. terwijl FPGA's alleen wordne gebruikt als je met een CPU niet toekomt...

Op 8 september 2007 20:05:58 schreef free_electron:
[...]
het verschil is ook dat vor cpu er 'simpele' dingetjes zijn. terwijl FPGA's alleen wordne gebruikt als je met een CPU niet toekomt...

Gast leer lezen: hier dus!

:)

Vergelijken is idd. niet te doen. Dan kan je een FPGA beter vergelijken met een GAL20V8.

Maar, let op je tellen! Die 'ouwe krotters' zal ik niet licht vergeten. En als dat zo te pas komt, zal de wraak zoet zijn, snotneus! :-7

[Dat was voor ons aller FE bedoeld, uiteraard]

Nu we het toch over de microcontroller en fpga hebben.

Wat moet ik me voorstellen bij SystemC en VerilogC? Zijn dit hogere programmeertalen (zoals C/Basic bij micro's)? En VHDL/Verilog lagere programmeertalen (zoals het assembler bij micro's)? En mogen we ook verwachten dat grotere projecten grotendeels in SystemC/VerilogC worden geschreven?

Mijn vraag even kort samengevat, hoe past SystemC/VerilogC in het VHDL/Verilog plaatje bij FPGA's.

Ik voel een enooooorm verhaal aan komen.....

Op 8 september 2007 20:12:28 schreef surge_me:
[...]

Gast leer lezen: hier dus!

:)

ela ! daar gaat het wel over CPLD's he !. das weer iets anders.

CPLD's moet je eerder ze als 'glue logica' en suport funties.
als we event terug blikken (voor de 'ouwe krotters' gelijk ik :face it pros .. als e ind de elctronica kunt zeggen dat je nog met 1206 smd's gewerkt hebt ben je al een 'ouwe taart'. we gebruikt at nu nog 1206... veel te groot jong. )) in de jare 80 zette jeeen systeem in elkaar met 6502 / 6809 / 8031 / een paar eproms , een paar ams , een address decoder (74138)en een pak ttls voor allerhade extra logica.
daarvoo diene CPLD's. smijt al die TTL weg en duw dat in de CPLD. klaar.

vandaag worden CPL's gebruikt daar waar je de CPU wilt ontlasten van tijdrovend werk. zoals keyboard scanning , rotary encoding ,address decodering, leds en diplays multiplexen etc. kortom alle werk waar de cpu teveel cycli moet aan spenderen (repetitieve dinen zoals keyboard scanning zou de cpu x keer per econemoten gaan doen. ditto voor disply muxing. de cpu kan zijn tijd beter spenderen. )

alsook het verstrekken van blokken hardware ( paar PWMpjes hier , paar I/O's daar etc )die nou net te kort zijn in de microconroller.

met andere woorde alles wat vroeger met ttl en een paar dingen zoals 8253 en 8284 opgelost werden duw je nu in een CP. tis makkeijker om je bord te layoen en als later blijkt dat je toch nog iets vergeten bent pas je de cpld code even aan.

een FPGA is een ander verhaal ....
FGA wordt gebruikt om grote blokken logica te maken die owfel niet kant en klaar te koop zijn en die ook niet even eenvoudig implementeerbaar zijn in software simpelweg omdat et teveel tijd vraagt.

ik geef een voorbeeld. ( iets waar ik nu toevallig mebezig ben )

een motor draait 15000 toeren / minuut (SCSI disks )
de motor heeft 16 polen verdeeld over 3 fasen. daar kome dus 3x16x15000 pulsen per minuut uit.

om de motor contant te houden wordt het tijd interval tussen 2 poolovergangen gemeten. dat moet dus 12000 x per seconde gemeten worden... met een resolutie in het nanoseconden bereik. dit is al verschrikkeijk moeilijk met een CPU...
er moet daar telkens een berekning op gemaakt worden (integer die egenlijk een fixed point bevat ) en het resultaat moet als 48 bits woord terug uitgeschoven worden naar de chip die de spoelen stuurt...
48 bits .. 12000 x per seconde is een clock van 57 MHz ... als je dat moet bitbangen moet je al minstens op het 4 dubbel draaien met een CPU. en we hebben nog niet eens de berekening gedaan.

en ondertussen moeten we nog een gans pak andere dingen afwerken ook.

daar worden dus FPGA's voor gebruikt. je implemeteert dat in hardware en het vliegt vooruit.
ik heb een pipelined syseem: een hardware counter doet de metin. als de meting klaar is verwerkt de rekenunit de data in welgeteld 9 clockticks ... een hardware shifter clockt dat pakket naar buiten aan dik 150 MHz. de correctiedata voor de volgende stap staat dus al klaar halverwege de commutatie naar de volgende spoel.
de resterene tijd wordt gebruikt om de 'huishouding' te doen.

een ander voorbeeldje:
dat 48 bit pakket bevat sommeerdere variabele. 3 bits voor it , 9 bit voo dat , 5 bit voor nog iets anders.
telkens je een transfer moet doen, moet je cpu dat 'pakketje' aanmaken. dus das alleaal AND OR en shiftwerk voor de cpu
ik heb een blok logica gemaakt in de FPGA

voor elke 'veld' is er een apart adress. voor de CPU is dat gewoon een stuk ram waarin hij kan lezen en schrijven. dus in de cpu code staan daar gewoon variabelen ( gemapt op een specifiek adress )
als er een schrijfopdracht gebeurt in die 'ram' schiet er een grote state machien in gang. die state machiene neemt in 1 clocktik ( het schijven in ram gebeurt op rising edge. de state machiene vuurt af op de falling edge van de write opratie ) al de noodzakelijke data en zet dat ineen 48 bit register. dat gebeurt dus in 1 clocktik ,onafhankelijk hoe complex die informatie is. De machiene zet een flag die aangeeft dat de data klaar is voor verzending en een ander blok schuift de boel uit.

omgekkeerd voor het lezen ook. de cpu vraagt ewoon aan om een register te lezen. de state machiene doet dit autonoom, splits het terugkerene 48 woord op in de losse blokjes ,zet die in een andere ram en de cpu kan lezen. al dat tijdrovende data-assembleer en disassembleer werk is verdwenen.

En SystemC en SystemVerilog ...

voor het moment is dat 'spielerij' die dingen zijn experimenteel en worden nog niet echt gebruikt

systemC is een heel stricte implemeantie van de C++ taal met een aantal speciale extra's. de SystmC compiler kan dat blok code (code is sequenieel )vertalen naar hardware die als logische poorten kan geimplemeteerd worden. maar het gaat veel verder dan dat. je kan ook routines gaan pipelinen.

stel je hebt een functie in C die getal telkens met 2 vermenigvuldigd. (shift left )

dat moet geberuen opblokken data van 1000 bytes .. voor een cpu is dat veel werk. hij moet 1000 x een shift opratie doen.
als je dat in SystemC doet kost je dat niks , maar dan ook totaal niks. geen gates, geen tijd.
al wat er gebeurt is dat dat je een getal ergens op zet (daar staat zels geen geheugen )en dat alle bits , behalve de laatste er uit komen

d0 komt op d1 te staan , d1 op d2 enzovoort. de uitgaande d0 hang gewoon aan grond.

de bedoeing van sytemC is dus om 'sequentiele code' te kunnen paralleiseren en acceleren als hardware.
Dit is wel bedoeld als een modelleertaal om paralelle systemen te maken!. als je dat later effectief wilt gaan synthetiseren komt daar nog een gans ander verhaal bij...

SystemVerilog is dan weer iets anders ...
met systmverilog zijn we een aantal dingen die we als programmeur gewend zijn (structs en multidimensionel arrays ) gaan toevoegen. de synthesizer is dus slimmer geworden

andere zaken zijn duidelijker geworden.
in verilog en vhdl is het soms mogelijk dat de synthesizer niet echt maakt wat jij bedoelde. daar is een eind aan gekomen. in plaats van 'always' kan je nu specifieren dat een bepaald blok expliciet combintorisch is of explicit met flipflops of latches moet gemaakt worden.

Op 8 september 2007 23:16:19 schreef free_electron:
andere zaken zijn duidelijker geworden.
in verilog en vhdl is het soms mogelijk dat de synthesizer niet echt maakt wat jij bedoelde. daar is een eind aan gekomen. in plaats van 'always' kan je nu specifieren dat een bepaald blok expliciet combintorisch is of explicit met flipflops of latches moet gemaakt worden.

Dat laatste kan ik niet helemaal plaaten. Bedoel je dat dit in SysVerilog zit? In "gewoon" Verilog is het toch ook exact gedefinieerd wanneer je FF/latch/combinatoriek krijgt? Ik heb daar nog nooit verrassingen gezien.

mope. dat kan gebeuren.
zeker wanneer je geen volledige cases schrijft.


always @( posedge clk) begin
    Z <= y;
end

of dit 

always @( posedge clk) begin
    if (clk) Z <= y; else Z <=Z;
end

in bovenstaande : hoe wordt het gemaakt ? wat is er ene latch en wat wordt een flipflop ? ( GROOT ! verschil )

in systemverilog schrijf je


always_ff @( posedge clk) begin
    Z <= y;
end

dan ben je zeker dat het een flipflop is.

Ik bespeur hier toch een voordeel van VHDL boven Verilog. In VHDL wordt dit al geregeld. Zodra iets gerelateerd is aan een klok, krijg je flipflops. Structs zitten volgens mij ook al standaard in VHDL. Zijn ze Verilog aan het opknappen zodat het op VHDL gaat lijken?

[Bericht gewijzigd door Nico.c op (15%)]

Op 9 september 2007 17:00:34 schreef free_electron:


always @( posedge clk) begin
    Z <= y;
end

of dit 

always @( posedge clk) begin
    if (clk) Z <= y; else Z <=Z;
end

Ok, de sysVerilog constructie is duidelijk. Je haalt de onzekerheid eruit.
Maar nu je voorbeeld. Beide gevallen zijn een FF, geen latch. Immers, een latch krijg je _alleen_ als je niet alle gevallen uitschrijft.
vb 1: op elke clk flank is er een assignment naar Z. Z is altijd gedefineerd, dus het is een FF.
vb 2: Is een beetje een vreemde, omdat je de clk weer in de combinatoriek opneemt. Foei! Maar het wordt ook in dit geval geen latch omdat in alle standen van clk Z gedefineerd is.
Je zou een latch krijgen in dit geval:


always @( posedge clk)
    if (inA) Z <= y;

of:

always @( posedge clk)
    if (inA) A <= y; else B <= y;

In het laatste geval krijg je zelfs 2 latches (of bedoelde je je 2e voorbeeld ook zo?).

@Nico: ik vraag me af of je gelijk hebt. Volgens mij is het ook in VHDL zo dat je een latch krijgt als je niet bij elke clk tick een assignment doet. Net als in mn voorbeeld hierboven. (al twijfel ik even of dat ook zo is als je 'event gebruikt, een latch is immers nivo gevoelig op z'n clk)

[Bericht gewijzigd door flipflop op (13%)]

Op 9 september 2007 18:53:52 schreef flipflop:Je zou een latch krijgen in dit geval:


always @( posedge clk)
    if (inA) Z <= y;

of:

always @( posedge clk)
    if (inA) A <= y; else B <= y;

In het laatste geval krijg je zelfs 2 latches (of bedoelde je je 2e voorbeeld ook zo?).

Ik heb dit zopas getest in Quartus en met de RTL viewer nagezien en die gebruikt voor alle 3 de uitgangen een DFFE.
Geen latch te bespeuren....

grrr. tis alijd moeilijk om ene voorbeeld te vinden wat verkeerd kan gaan.

we proberen deze dan.



always @(clock)   y = a;

wat wordt dat ?
een latch ? of wordt dat een combinatorisch ding (een bus met en enable ? ).... rarara .. stel dat die Y ene open drain uitgang is ..



always @(clock) y=a; else y=y;

soms heel verwarrend. het kwaad zit hem altijd in een klein staartje. ( let op dat ik geen <= gebruik maar ene blocking assignment ... )

in systemverilog is dat probleem weg.

je schrijft gewoon


always_comb 
  if(clock) y=a; 

en het is combinatorisch.


always_latch 
   if (clock) y=a;

en het zit in een latch.

let ook op dat je in systemverilog geen sensitivity lijsten meer opgeeft. de synthesizer bouwt zelf de sensitivity op. ( nu kan dat omdat de synthesizer op voorhand weet wat voor vlees hij in dekuip heeft ( .. moet steken .. :p )

Op 9 september 2007 20:46:10 schreef fotoopa:
[...]

Ik heb dit zopas getest in Quartus en met de RTL viewer nagezien en die gebruikt voor alle 3 de uitgangen een DFFE.
Geen latch te bespeuren....

haal de posedge eens weg. als je edge sensitivity hebt krijg je automatisch flipflops .

Op 9 september 2007 18:53:52 schreef flipflop:
@Nico: ik vraag me af of je gelijk hebt. Volgens mij is het ook in VHDL zo dat je een latch krijgt als je niet bij elke clk tick een assignment doet. Net als in mn voorbeeld hierboven. (al twijfel ik even of dat ook zo is als je 'event gebruikt, een latch is immers nivo gevoelig op z'n clk)

In VHDL is het veel eenduidiger:

architecture BEHAVIORAL of demo is

signal a: std_logic;
signal b: std_logic;
signal c: std_logic;
signal d: std_logic;
signal en: std_logic;
signal clk: std_logic;

begin

--flipflop
flipflopproc: process(clk)
begin
if rising_edge(clk) and en='1' then
a <=c;
end if;
end process;

--latch
latchproc: process(en)
begin
if en=1 then
b<=c;
end if;
end process;

--en een nog viezere latch
when en='1' then d<=c;

end BEHAVIORAL;

Dus je mijn vraag blijft:

- Wat is de reden waarom jullie nog niet gestart zijn met CPLD of FPGA ?

-------

Ben uberhaubt nog niet bezig met microcontrollers enzo.

Waarom ? Ziet er heel moeilijk uit, en zou zo op eerste oog
niet weten waar ik moet beginnen.

Tijd en geld speeld natuurlijk ook een rol ;)

Prive ben ik nog niet gestart omdat ik nog geen goed adres heb waar ik tegen redelijke kosten (en dus ook geen extreme) verzendkosten) een FPGA kan kopen. Ik zoek een Xilinx Spartan2 of 3. Da's de enige reden.
Verder is het gewoon een taal leren, VHDL of Verilog, dus da's geen reden om ermee te beginnen. Dat geldt ook voor C of elke andere taal.

Nog even over mijn voorbeelden hierboven: [schaammode on] dat klopt niet helemaal. Wordt al gecorrigeerd door anderen, maar het verschil tussen FF en latch wordt uiteraard gemaakt door "posedge" of 'event. Je krijgt wel een latch als je combinatoriek beschrijft en de assignment wordt niet in alle gevallen gedaan. Dan krijg je een latch. Nico's verhaal is ok.
Verder staat me bij dat je in Synopsys ook een latch krijgt als je een signal vergeet op te nemen in de sensitivity list, maar ik kan zo niet verklaren waarom dat is. Kortom: het blijft zeker uitkijken.

[Bericht gewijzigd door flipflop op (45%)]

ik ben sinds vrijdag half begonnen (lees me aan het orienteren in de software), maar voor mij was de reden de hoge instapkosten van fpga's en cpld's.

in eerste instantie was dat ook het geval bij µC's en dat loopt nu ook goed.

maar al het begin is moeilijk
maar ben nu wel trotse eigenaar van een maxII DE-NANO board

Op 10 september 2007 19:49:00 schreef timmie:

maar al het begin is moeilijk
maar ben nu wel trotse eigenaar van een maxII DE-NANO board

Heb je al de quartus software geinstaleerd en een van de voorbeelden gecompileerd?

Voor xilinx CPLD moet je wel andere software tools downloaden (1.5Gb) en installeren. De verilog voorbeelden zouden in beide gevallen moeten werken mits natuurlijk device en I/O's en de juiste tools te gebruiken.
Schema entry is niet uitwisselbaar!

Op 10 september 2007 19:49:00 schreef timmie:
ik ben sinds vrijdag half begonnen (lees me aan het orienteren in de software), maar voor mij was de reden de hoge instapkosten van fpga's en cpld's.

in eerste instantie was dat ook het geval bij µC's en dat loopt nu ook goed.

maar al het begin is moeilijk
maar ben nu wel trotse eigenaar van een maxII DE-NANO board

net als ik, vanavond even de software en alles getest. Had van het weekend niet echt de tijd gehad. :)

Op 10 september 2007 19:58:01 schreef fotoopa:
[...]

Heb je al de quartus software geinstaleerd en een van de voorbeelden gecompileerd?

Voor xilinx CPLD moet je wel andere software tools downloaden (1.5Gb) en installeren. De verilog voorbeelden zouden in beide gevallen moeten werken mits natuurlijk device en I/O's en de juiste tools te gebruiken.
Schema entry is niet uitwisselbaar!

Compileren van de teller met schemaentry werkt en downloaden werkt nu ook.

Had even problemen om de USB blaster aan het werk te krijgen, maar is gelukt.

[Bericht gewijzigd door jovak op (36%)]

blaster geen problemen mee gwoon inf toe wijzen.

alleen de software en hoe je moet beginnen is me niet duidelijk

Op 10 september 2007 21:31:33 schreef timmie:
blaster geen problemen mee gwoon inf toe wijzen.

alleen de software en hoe je moet beginnen is me niet duidelijk

Zelfde probleem hier, maar ik ga morgen avond verder. en dan maar eens stap voor stap bij houden wat ik doe. Kan F_E of Fotoopa mee kijken :)

zelfde idee hier.
heb nu wel eindelijk een licentie(die kreeg ik in eerste instanstantie niet:S)

Op 10 september 2007 22:54:56 schreef timmie:
zelfde idee hier.
heb nu wel eindelijk een licentie(die kreeg ik in eerste instanstantie niet:S)

Oh dat had ik al wel snel voorelkaar. half jaar geleden al eens geregistreerd om iets te doen met quartus. alleen is er toen niet van gekomen wegens gebrek aan hardware en tijd.

blijkbaar is het de eerste keren iets fout gegaan net kreeg ik hem binnen een halve minuut binnen dus

Ik stel voor als er vragen zijn rond het opstarten van Quartus of van de voorbeelden dit verder in de topic van "CPLD-FPGA eenvoudigevoorbeelden" verder te zetten. Hier in deze link

Dan worden die problemen meer gebundeld. Ik vermoed eens dat de FPGA printjes van xantus zullen geleverd zijn er daar nog meer nieuwe gebruikers en vragen zullen bijkomen.