FPGA Probleem

Volgens mij is dit een schoolvraag.

Ik heb nul ervaring met FPGA's, maar is je FPGA niet gewoon te "klein", en zijn er daarom geen vrije resources meer als hij het probeert in te passen?

Ik heb ook het idee dat je FPGA vol zit. Probeer een echte HDL zoals verilog of VHDL te gebruiken in plaats van java, scheelt waarschijnlijk flink in resources.

Die FPGA mag geen enkel probleem hebben met een beetje PWM-en. Ik ben niet bekend met het programmeren van FPGAs in Java maar ik vind anderhalf uur compilen voor iets banaals als dit toch wel erg extreem. Volgens mij gaat er iets anders mis (geen idee wat).

Dank ook voor de LabView product key

De FPGA is vol. Dat zou niet mogen met een paar PWM dingetjes. Misschien kun je beter in een HDL werken ipv Java (wist niet dat dat bestond?). Dit is een heel grote en krachtige fpga trouwens.

3 pwms .. java ?!? LABVIEW ?!? en 3 uur compileren !:!:!

/\_
( huilen met de pet op )

Ik verhuis naar india.. als we zo door gaan dan is de westerse wereld een 'has-been' binnen een paar jaar...

3 PWM's 'gescheten' in 2 minuten in verilog :

module pwm3(in clk,reset,wr
            in [7:0] data,
            in [1:0] addr,
            out reg pwm1,pwm2,pwm3)

reg [7:0] pwmval1,pwmval2,pwmval3,pwmctr;

always@(posedge clk) begin
   if (wr) case addr
               0: pwmval1<=data;
               1: pwmval2<=data;
               3: pwmval3<=data;
           endcase

   pwmctr <=  pwmctr + 1;
   pwm1   <= (pwmctr < pwmval1); 
   pwm2   <= (pwmctr < pwmval2); 
   pwm3   <= (pwmctr < pwmval3); 

   if (reset) begin
      pwmval1 <=0;
      pwmval2 <=0;
      pwmval3 <=0;
   end
end

endmodule

tis moeilijk he..
en 't synthetiseert binnen de minuut op een ouwe pentium 4 met 256 meg ram...

en hier zijn 3 BRM's

module pwm3(in clk,reset,wr
            in [7:0] data,
            in [1:0] addr,
            out reg pwm1,pwm2,pwm3)

reg [7:0] pwmval1,pwmval2,pwmval3,pwmctr1,pwmctr2,pwmctr3;

always@(posedge clk) begin
   if (wr) case addr
               0: pwmval1<=data;
               1: pwmval2<=data;
               3: pwmval3<=data;
           endcase

   pwmctr1 <=  pwmctr1 + pwmval1;
   pwmctr2 <=  pwmctr2 + pwmval2;
   pwmctr3 <=  pwmctr3 + pwmval3;
   pwm1   <= pwmctr1[7]; 
   pwm2   <= pwmctr2[7]; 
   pwm3   <= pwmctr3[7]; 

   if (reset) begin
      pwmval1 <=0;
      pwmval2 <=0;
      pwmval3 <=0;
   end
end

endmodule

en dat compileert even snel en is slechts weinig groter.

maar van een BRM zullen ze wel nog nooit gehoord hebben zeker op de 'java op crapview' kakschool ?

Ehh. je bedoelt "one bit DA"?

Volgens mij moet je

pwm1 = pwmctrl[8];

hebben. En bovendien moet die weer iedere clock naar nul gezet worden.

Volgens mij heeft zoals jij het schrijft iedere output altijd een 50% dutycycle, maar een frequentie die afhankelijk is van de waarde.

Volgens mij moet het iets zijn als:

reg [8:0] pwmctr1;
...
pwmctr1 <= '0' & pwmctr1[7:0] + '0' & pwmval1;
pwm1 <= pwmctr1[8];    // Deze mag combinatorisch, ik weet niet hoe je dat opschrijft. 

move /Schoolvragen.

Ik heb dit programma ook ooit gebruikt. De oplossing voor het probleem is heel eenvoudig. Ik heb gekeken in mijn oud verslag en dit is wat je moet doen om het 'making system configuration' sneller te laten gaan en te verhinderen dat het stilvalt voor het klaar is.

Bijvoorbeeld:
Board.loadBoardConfig("genesysVirtex.dat");

gebruik bestanden zoeken, zoek op genesysVirtex.dat, kopieer het bestand naar de map waar de java bestanden staan.

Nu moet je het .dat bestand openen met kladblok en deze regel aanpassen
van javaImplementRTL=always_try naar javaImplementRTL=_debug_force_softcore

Dit is men te weten gekomen door het bedrijf dat het gemaakt heeft te contacteren, ik denk niet dat dat ergens staat.

Bedankt princess of evil,

Ik heb je oplossing getest en dit leek een magic bullet te zijn want de compilatie duurde maar 10 minuten en gaf geen fout, helaas toen ik de file op de FPGA wou zetten waren er 2 problemen:

De labview usb interface werkt blijkbaar niet meer, je hoort steeds het windows geluidje van apparaat aangesloten/afgesloten en de lijst in apparaatbeheer begint helemaal te flippen. Na ongeveer 10 seconden kwam het windows blauwe scherm en moest de pc opniew gestart worden.

Ik had de labview interface dan maar eventjes weggedaan en gewoon de PWM manueel ingesteld op een vaste waarde. Dit werkt, maar de pwm is heel onnauwkeurig, zowel de frequentie als de duty cycle.

Zonder de aanpassing aan genesysVirtex.dat en zonder labview interface kan ik dat wel compilen, en de pwm is dan nauwkeurig. Ik heb uitgezocht hoe je kunt opvragen hoe hard de fpga vol is en ik heb het volgende opgemerkt:
Enkel 1 PWM: 17% LUT Mapped
3 PWM: 43% LUT Mapped
Enkel Labview: 81% LUT Mapped
Alles samen: 100% LUT Mapped, 29% of design not mapped.

Met de aanpassing aan de file krijg ik:
Enkel 1 PWM: 29% LUT Mapped
3 PWM: 28% LUT Mapped
Enkel Labview: 30% LUT Mapped
Alles samen: 29% LUT Mapped
Dit vond ik zeer vreemd omdat de belasting blijkbaar niet meer afhangt van wat de FPGA moet doen, ik heb dan een file gemaakt die LED0 aanzet en verder niks:
28% LUT Mapped

Ik moet wel opmerken dat javaImplementRTL bij mij op virtex_heur stond ipv always_try.

Ik heb gekeken naar de oplossing van free_electron maar ik weet niet hoe ik die kan toepassen, ik heb een lege file aangemaakt en het erin geplakt maar er komen meteen tientallen fouten in eclipse.

Het enige dat de FPGA moet doen is 3 pwm signalen opwekken waarbij de duty cycle instelbaar is via labview op de computer, en 2 digitale inputs doorgeven aan labview. Helaas lijkt juist de verbinding met labview heel moeilijk omdat die 81% van de FPGA gebruikt. Ik kan aan de labviewConnection niets veranderen omdat dit een door de school aangekochte IP is waar de broncode niet bijzit (anders kon ik misschien alles verwijderen wat ik niet gebruik zodat hij kleiner wordt).

Ik heb dan ook zoals andere mensen voorgesteld hebben gekeken naar VHDL, dit ziet er een ingewikkelde manier uit om de FPGA te programmeren maar dat moet wel te leren zijn. Ik vraag me dan wel af hoe ik in vhdl een verbinding kan opzetten met labview. Ik heb met google hierop gezocht maar heb weinig concreets kunnen vinden.

Misschien heb je hier wat aan: Klik

VHDL/Verilog gaat niet werken in Eclipse. Hiervoor ben je andere programmas nodig. Hoewel ik het nut van Java in een FPGA niet zie, zou ik het toch lekker daarbij laten. Je hebt immers de ontwikkelomgeving en alle configs al. Wat ik echter niet snap is hoe het komt dat zelfs het aanzetten van een ledje zoveel ruimte op de FPGA moet kosten. Hoe wordt de Java-code omgezet? Draait er een of andere Java-engine op de FPGA of wordt de code omgezet in een HDL-taal?

Ik heb geen ervaring met die java compiler, maar het lijkt alsof je met die force softcore de java laat uitvoeren door een cpu die in de fpga wordt geplaatst. De afmetingen daarvan zullen weinig afhangen van het programma dat erop staat (hoogstens de rom en ram een beetje groter of kleiner). Dat de USB niet meer werkt en PWM onnauwkeurig is kan dan wel omdat realtime eisen wellicht niet meer gehaald worden.

Enkel 1 PWM: 17% LUT Mapped zou echt niet mogen. Op die FPGA moet je een kleine computer kunnen emuleren.

Een verbinding met labview in VHDL maken is niet zo lastig, je kunt misschien best een UART maken of van internet plukken en dan over de RS232 poort communiceren. Of ergens een USB interface halen.

Hoi

Anderhalve maand verder is het eindelijk gelukt. Ik heb de 3 PWM generatoren samen gezet in 1 java bestand. Dit paste nog net niet. Ik heb dan zelfs contact gehad met de firma die de FPGA software geleverd heeft en die raadden aan om 2 FPGA borden te gebruiken, 1 voor de labview interface en 1 voor de PWM. Dat leek me wat veel van het goede. Ik heb gezien dat het mogelijk is om ipv te compileren naar een .bit bestand dat je ook vhdl code kunt laten genereren. Ik heb deze bekeken, en zo lang bekeken dat ik volgens mij vhdl geleerd heb, en gezien dat er in de labview interface heel veel code stak die de licentie op de interface verifieert en als die klopt een bit op 1 zet (licence.vhd). Ik heb die code vervangen door een leeg stukje programma dat gewoon die bit op 1 zet. Dan alle vhdl bestanden ingeladen in ISE WebPack en opniew compilatie gedaan en het paste wonder boven wonder.

Nu is het probleem dat de PWM eigenlijk 16 bit zou moeten zijn, aangepast, stukje vervangen, gecompiled, en het past weer niet! Ik heb dan de VHDL code die de tellers maakt bekeken maar daar is niet aan uit de kunnen want het zijn 7459 lijnen. Bovendien terwijl in die labview interface de variablen namen hadden als 'lic_test_suc' is dat hier 'astrojavapro3a20e4f281' waardoor de code totaal niet te volgen is.

Nu ben ik aan het twijfelen wat ik ga doen, ik denk dat ik ondertussen voldoende VHDL ken om de hele applicatie in VHDL te schrijven. De toepassing zou op een batterij moeten werken, wat nu al lastig is. Ik heb dat FPGA board, de infrarode afstandssensor, DAQ en de embedded computer met labview eens aangesloten op een wattmeter en dat was 102W. Bovendien is het erg groot. De PWM met labview zelf maken ging niet want dat was te onnauwkeurig.

Ik heb dan wat verder rondgezocht en zag dat er ook kleine processoren (arduino) waren. Deze kunnen wel geen labview draaien maar dat is denk ik geen probleem. Al wat er moet gebeuren is de analoge spanning (0-4.4V) van de afstandssensor inlezen en dan enkele eenvoudige berekeningen doen en de 3 PWM signalen instellen.

Ik denk dat het met zo'n arduino perfect moet kunnen om dit te maken waardoor de hele fpga en labview en de pc enz niet nodig is. Denken jullie ook dat dat gaat?

Anders ga ik het herschrijven volledig in VHDL. Ik heb opgezocht dat USB nogal moeilijk te schrijven is maar het signaal dat uit de seriele poort komt ziet er makkelijk uit om te programmeren. Allesinds is die Astro PRO Hardware Studio die ze hier op school hebben gekocht heel dikke (en dure, schijnt het) brol.

Ik heb dan zelfs contact gehad met de firma die de FPGA software geleverd heeft en die raadden aan om 2 FPGA borden

Ik heb dan de VHDL code die de tellers maakt bekeken maar daar is niet aan uit de kunnen want het zijn 7459 lijnen.

'lic_test_suc'

volgens mij moet daar 'ks' acterstaan

batterij, FPGA board, de infrarode afstandssensor, DAQ en de embedded computer , 102W.

Allesinds is die Astro PRO Hardware Studio die ze hier op school hebben gekocht heel dikke (en dure, schijnt het) brol.

doe me een lol en gooi gans die boel in een bak met etsmiddel. liefst op vrijdagavond... zo zijn toekomstige studenten gevrijwaard van dit soort shit.

Kan makkelijk met de arduino. Wel heel dom trouwens dat die labview ip core zijn licentie nakijkt op de FPGA, met wss een heel stuk cryptografische logica dat ziek veel plaats inneemt, en dat je dat dan kan omzeilen door wat code te deleten...