DSP en FPGA gezocht

Waarom doe je die dsp dingen niet ook in je FPGA?

Altera heeft een prima toolbox voor Simulink (DSP Builder) en daar kun je mee simuleren wat je wilt, als het eenmaal werkt kun je een (2 maanden) gratis licentie aanvragen en je simulink model omzetten naar hardware...

Xilinx zal ook wel zoiets hebben.

Voor die ram zou ik gewoon extern ram nemen en je data die je snel nodig hebt in je interne ram van je FPGA stoppen (je kunt denken aan filter coefficienten etc.)

Weg schrijven naar ram gebeurt vrij snel en ik denk dat je dat wel kan doen terweil je aan het sampelen bent

Op 18 maart 2007 10:40:51 schreef surge_me:
Waarom doe je die dsp dingen niet ook in je FPGA?
Altera heeft een prima toolbox voor Simulink (DSP Builder) en daar kun je mee simuleren wat je wilt, als het eenmaal werkt kun je een (2 maanden) gratis licentie aanvragen en je simulink model omzetten naar hardware...

Omdat ik het algoritme snel wil kunnen aanpassen aan de toepassing (type array, type analyse, ...) En dat gaat nu eenmaal sneller in SW dan in HW. En tijdens ontwikkelfase is het zowiezo interessanter om dat allemaal in SW te doen. Synthese duurt altijd langer dan compilatie. Maar inderdaad, het is wel een interessante optie voor latern zal ze onthouden

Voor die ram zou ik gewoon extern ram nemen en je data die je snel nodig hebt in je interne ram van je FPGA stoppen (je kunt denken aan filter coefficienten etc.)

Weg schrijven naar ram gebeurt vrij snel en ik denk dat je dat wel kan doen terweil je aan het sampelen bent

Her probleem is dat de sampling van alle kanalen simultaan moet gebeuren, en dat het interessant zou zijn om voor elk kanaal een apparte RAM te hebben (dan kan ik die later in de FPGA als hele blokken toevoegen, een blok HW per kanaal)

Op 18 maart 2007 10:46:33 schreef stecj366:
[...]

Her probleem is dat de sampling van alle kanalen simultaan moet gebeuren, en dat het interessant zou zijn om voor elk kanaal een apparte RAM te hebben (dan kan ik die later in de FPGA als hele blokken toevoegen, een blok HW per kanaal)

250Khz sampeling is enorm traag voor een ram. Je kunt alle 32 channels parallel sampelen en via mux in je FPGA in dezelfde externe RAM stoppen. Je hebt tijd zat om dit te doen aan die "trage" sampeling. Ik weet niet als je RAM eigenlijk als fifo moet werken, maar indien nodig kun je dat ook zo oplossen. Ik heb dat heel veel gedaan bij xrray beeld verwerking waar tot 16 rijen beeld in dezelfde fifo werd gestopt voor verwerking in de filters. Die data ging aan 5MHz sampeling en werd op hoge snelheid in een fifo gepomt en om dan ten gepaste tijd te kunnen uitlezen. Het voordeel is dat je maar 1 RAM of fifo nodig hebt ipv soms 32.

Ik had in totaal zo 24 externe fifo's die elk nog eens 16 lijnen videodata bevatten. Data werd wel parrallel ingeschreven en uitgelezen. Resultaat moest via de PCI van de PC naar de applicatie.

edit:
voor 12 bit breedte kun je ofwel je data opsplitsen door na elkaar 4+8 bits per channel te schrijven ofwel 2 ram's breedte te nemen waardoor je werkfrequentie en multiplexing wordt gehalveerd tov de eerste methode.

Op 18 maart 2007 11:31:58 schreef fotoopa:
[...]
250Khz sampeling is enorm traag voor een ram. Je kunt alle 32 channels parallel sampelen en via mux in je FPGA in dezelfde externe RAM stoppen. Je hebt tijd zat om dit te doen aan die "trage" sampeling.

Dat is dan schrijven naar de RAM aan 8Mhz. Ik wist niet dat dit te doen was.

Ik weet niet als je RAM eigenlijk als fifo moet werken, maar indien nodig kun je dat ook zo oplossen. Ik heb dat heel veel gedaan bij xrray beeld verwerking waar tot 16 rijen beeld in dezelfde fifo werd gestopt voor verwerking in de filters. Die data ging aan 5MHz sampeling en werd op hoge snelheid in een fifo gepomt en om dan ten gepaste tijd te kunnen uitlezen. Het voordeel is dat je maar 1 RAM of fifo nodig hebt ipv soms 32.

Neen, de data moet willekeurig kunnen gelezen worden, niet via een FIFO. Dus is een conventionele RAM nodig. Je moet je het zo voorstellen: Er wordt een puls verzonden via een conventionele transducer. Dan wordt gedurende een variable tijd (max. 100msec) een "opname" gemaakt van de echo's die terug komen. Die data moet dan verwerkt worden en de output doorgegeven worden aan een hoofdprocessor.

Dan wordt er opnieuw een puls uitgezonden en begint het spelletje opnieuw.

Een RAM zal dan de beste oplossing zijn. Het eenvoudigste is een SRAM, die gaan heel gemakkelijk tot zelfs op 20 nsec wat 50 MHz lees/schrijf snelheid is.

Ik zie dat je zelfs niet gelijktijdig moet in en uitlezen. Dat moest ik wel kunnen maar daarvoor werd een cyclus in 2 delen gemaakt waardoor de read en write functie's eigenlijk sequentieel gebeurden maar praktisch werd dit gelijktijdig waargenomen.

Gewone SRAM ligt veelal rond de 60 nsec. Met een FPGA is dit eerder traag.

Je opgave is relatief traag, vandaar dat ik mij ook een beetje afvraag waarom niet alles in de FPGA zou kunnen. Maar ik vermoed dat het je voorliefde is voor software waar je meer ervaring mee hebt en daardoor het als vlotter beschouwd. Opzich niet slecht, het is gewoon een manier van werken.

Veel hangt af van wat verwerken van de data is. Dit is moeilijker in te schatten voor een buitenstaander vandaar dat je software oplossing hiervoor eenvoudiger kan uitvallen.

(omdat ik er ervaring mee heb), zou ik overwegen om de MCP3202 van Microchip te gebruiken. Je hebt wel 32 van die dingen nodig om 32 kanalen aan te kunnen. (Je zou liever 4 MCP3208's gebruiken, maar dan is het te langzaam).

Je moet dan op de FPGA kijken welke kanalen je samen en welke je per chip los moet doen. Volgens mij mag je de clock en chip select lijnen aan mekaar hangen, en dan de data los van mekaar houden. Dan kan je de 32 kanalen tegelijk samplen en uitlezen.

Een Altera Cyclone (1) met een externe SRAM moet dit allemaal aankunnen.

Als je de boel via USB naar de PC wilt hebben kan je een FTDI 245 gebruiken (of die modernere 2232 of hoe die ook heet). Dan kan je de boel in de PC verwerken. Of dat snel genoeg is, of dat je een DSP nodig hebt, kan ik niet inschatten. Of de 1Mbyte per seconde die je over de FTDI haalt voldoende is, weet ik ook niet.

Wat voor budget heb je? Misschien is het verstandiger om dan een development board te kopen en daar aanpassingen op te doen.

Waarom wil je floating point berekeningen doen? Is fixed point niet voldoende? Want DSP's met hardware floating point is namelijk veel duurder dan zonder.

Ik heb op school met een DSP board gewerkt, er zit een TI DSP en xilinx FPGA er op. Het is wel een fixed point apparaat. Het voordeel is dat je niet zelf de hardware moet ontwerpen, scheelt je een hoop tijd en zorgen.
http://focus.ti.com/docs/toolsw/folders/print/tmdsevm642.html

Op 18 maart 2007 18:23:05 schreef miniK0bo:
Wat voor budget heb je? Misschien is het verstandiger om dan een development board te kopen en daar aanpassingen op te doen.

Waarom wil je floating point berekeningen doen? Is fixed point niet voldoende? Want DSP's met hardware floating point is namelijk veel duurder dan zonder.

Ik heb op school met een DSP board gewerkt, er zit een TI DSP en xilinx FPGA er op. Het is wel een fixed point apparaat. Het voordeel is dat je niet zelf de hardware moet ontwerpen, scheelt je een hoop tijd en zorgen.
http://focus.ti.com/docs/toolsw/folders/print/tmdsevm642.html

Budget: genoeg

Ik sta zeer zeker open voor dev. boards... Scheelt inderdaad een hoop kopzorgen.

Floating point is niet uitermate noodzakelijk, maar aangezien de prijs toch niet doorslaggevend is kan een FP DSP er wel af...

Je opgave is relatief traag, vandaar dat ik mij ook een beetje afvraag waarom niet alles in de FPGA zou kunnen. Maar ik vermoed dat het je voorliefde is voor software waar je meer ervaring mee hebt en daardoor het als vlotter beschouwd. Opzich niet slecht, het is gewoon een manier van werken.

Ik denk dat de DSP taken die ik ga moeten uitvoeren vrij moeilijk in echte HW te realiseren valt... Hilbert transform bv, ik zou begot ni weten hoe ik dat in HW ga moeten oplossen. En complexe algoritmes lijken mij toch iets eenvoudiger te maken in software. Ik heb wel redelijk wat ervaring met HW design (slechte dan ), en dat is dan ook een van de redenen dat ik een DSP verkies.

Op 18 maart 2007 22:32:53 schreef stecj366:
[...]

Ik denk dat de DSP taken die ik ga moeten uitvoeren vrij moeilijk in echte HW te realiseren valt... Hilbert transform bv, ik zou begot ni weten hoe ik dat in HW ga moeten oplossen. En complexe algoritmes lijken mij toch iets eenvoudiger te maken in software. Ik heb wel redelijk wat ervaring met HW design, en dat is dan ook een van de redenen dat ik een DSP verkies.

Oké nu begrijp ik het waarom die software keuze!

Oké, nu na de examens komt dan de start van het doctoraat dichter, en ga ik me weer focussen op het project.

Waarschijnlijk zal de sampling inderdaad met een FPGA gaan gebeuren, dan een SRAM die de gegevens opslaat, en dan een DSP voor de processing.

Nu mijn vraag naar de SRAM: bestaat die in dual port versie, zodat ik tegelijkertijd kan lezen en schrijven? En liefst met een seriele interface, omdat dit het maken van een PCB aanzienlijk vereenvoudigd. En wat is zo de maximale grootte dat die dingen kunnen hebben?

EDIT: Ik heb eens wat op farnell rond gekeken, en er zijn er toch een aantal die mij interesseren. Maar de meeste hebben een parallele interface. Kent iemand een SRAM die 1Mx16 (of iets dergelijks) heeft met seriele interface (liefst dan dual ported). Met 1Mx16 bedoel ik dus 1M plaatsen van 16 bit. (is dit de correcte interpretatie?)

Dual port zat ik ook aan te denken toen ik het topic las. Serieel zou ik niet doen (als het al bestaat). Dat lijkt me niet snel genoeg, zeker niet omdat je over snelheden van 8MHz praat. En omdat je met twee "poorten" zit (DSP en FPGA) die beide de SRAM delen wordt de benodigde snelheid nog hoger.
Ik zou een lekker brede bus nemen, desnoods een paar SRAMmen parallel zodat je de schrijf/lees snelheid zo laag mogelijk kunt houden. Misschien heb je wat reserve later nog nodig.

Op 14 juli 2007 10:11:06 schreef flipflop:
Dual port zat ik ook aan te denken toen ik het topic las. Serieel zou ik niet doen (als het al bestaat). Dat lijkt me niet snel genoeg, zeker niet omdat je over snelheden van 8MHz praat. En omdat je met twee "poorten" zit (DSP en FPGA) die beide de SRAM delen wordt de benodigde snelheid nog hoger.
Ik zou een lekker brede bus nemen, desnoods een paar SRAMmen parallel zodat je de schrijf/lees snelheid zo laag mogelijk kunt houden. Misschien heb je wat reserve later nog nodig.

Ja inderdaad, ik ga de SRAM ook zeker overdimensioneren om later niet helemaal opnieuw te moeten beginnen. Zou wat zonde zijn... Parallel dan maar, zal ook wel lukken (en die blackfins hebben ook een parallele bus, dus dat lukt wel). Nu de enige dual ported SRams die ik op farnell gezien hebt zijn te klein voor wat ik er mee wil doen. Maar kon je niet een aantal SRams combineren om zo meer plaats te krijgen?

Maar wat bedoelen ze nu eigenlijk met 1M*16? Mij lijkt dit dus 1M plaatsen van 2byte, dus in totaal 2Mbyte. Maar op farnell zie ik dan groottes van 16Mbyte, waardoor ik niet meer echt kan volgen.

Kent er iemand een Devboard met FPGA en grote DP Ram?

Ik zou een lekker brede bus nemen, desnoods een paar SRAMmen parallel zodat je de schrijf/lees snelheid zo laag mogelijk kunt houden. Misschien heb je wat reserve later nog nodig.

Zo gek snel vind ik het niet met samples op 250kHz. Gebruik zelf de CY7C1041CV33-12ZXC (4MBit) op 80MHz. Bij een ADC die samples op 250kHz kan je makkelijk in je FPGA hiervan een dualports RAM maken. Zelfs de IS62WV1288BL-55HLI (1MBit) zou dat nog kunnen (max 18MHz). Deze kost bij digikey maar €1,84.

Kent er iemand een Devboard met FPGA en grote DP Ram?

Grote DP RAM ga je niet vinden. De grootste die ik heb kunnen vinden zijn max 1Mbit en kosten al een vermogen. Je bent dan zo €60 kwijt voor 1Mbit.

Maar wat bedoelen ze nu eigenlijk met 1M*16? Mij lijkt dit dus 1M plaatsen van 2byte, dus in totaal 2Mbyte. Maar op farnell zie ik dan groottes van 16Mbyte, waardoor ik niet meer echt kan volgen.

Dat zal 16Mb (MegaBit) zijn, dus 2MB (MegaByte). Totale grote van RAM word meestal aangegeven in bits en niet bytes omdat je daar niets aan heb bij RAM van 9 of 18 breed.

Wat je zou kunnen doen is een DSP nemen waarmee je met behulp van DMA de FPGA kunt uitlezen. Dan laat je de SDRAM of DDR geheugencontroller van de DSP het vuile werk opknappen.

Ik zou voor een Analog Devices DSP kiezen vanwege de goede GCC ondersteuning. Ik heb weleens met een Blackfin DSP gewerkt en ik moet zeggen dat die zich heel prettig laten programmeren en zich ook goed voor 'general purpose' werk lenen. Je kunt er zelfs Linux op draaien. Dan heb je al een platform waarmee je met de buitenwereld kunt communiceren. De DSPs van Texas Instruments kunnen dit niet of op een hele omslachtige manier.

Op 14 juli 2007 12:07:23 schreef xantus:
[...]
Dat zal 16Mb (MegaBit) zijn, dus 2MB (MegaByte). Totale grote van RAM word meestal aangegeven in bits en niet bytes omdat je daar niets aan heb bij RAM van 9 of 18 breed.

Ok, dat is dan ook duidelijk

Op 14 juli 2007 12:07:23 schreef xantus:
[...]
Zo gek snel vind ik het niet met samples op 250kHz. Gebruik zelf de CY7C1041CV33-12ZXC (4MBit) op 80MHz. Bij een ADC die samples op 250kHz kan je makkelijk in je FPGA hiervan een dualports RAM maken. Zelfs de IS62WV1288BL-55HLI (1MBit) zou dat nog kunnen (max 18MHz). Deze kost bij digikey maar €1,84.

Het dual port maken van de RAM, hoe zit dit ongeveer in elkaar? Het moet eigenlijk geen complete DP ram zijn. De ene kant moet enkel schrijven, en de andere kant enkel lezen. Het lezen zou veel sneller moeten kunnen dan 250kHz, liefst zo snel mogelijk, omdat ik de data snel nodig heb bij het processen.

[...]
Grote DP RAM ga je niet vinden. De grootste die ik heb kunnen vinden zijn max 1Mbit en kosten al een vermogen. Je bent dan zo €60 kwijt voor 1Mbit.

Mja, dan geen out-of-the-box DPRam.

Op 14 juli 2007 12:41:53 schreef Nico.c:
Wat je zou kunnen doen is een DSP nemen waarmee je met behulp van DMA de FPGA kunt uitlezen. Dan laat je de SDRAM of DDR geheugencontroller van de DSP het vuile werk opknappen.

Dus dan hangt de FPGA direct aan de DSP, en de SRAM ook aan de DSP. De FPGA doet dan enkel de sampling en heeft per kanaal een register, en de DSP leest dan die 32 registers uit en slaat ze op in de SRAM (via DMA). Dit DMA verhaal, houdt dat niet in dat de processor transfers kan doen in het geheugen zonder dat de processorcore erbij betrokken is? Hoe moet ik dat dan zien? Kan ik de FPGA opnemen in de geheugenmap van de processor, en ik breng dan een aantal adreslijntjes naar de FPGA, en hang de uitgangen van de FPGA aan de databus van de DSP?

dus we krijgen dan:

ADC---|
ADC-----> FPGA ---> DSP ---> SRAM
ADC---|

Ik zou voor een Analog Devices DSP kiezen vanwege de goede GCC ondersteuning. Ik heb weleens met een Blackfin DSP gewerkt en ik moet zeggen dat die zich heel prettig laten programmeren en zich ook goed voor 'general purpose' werk lenen. Je kunt er zelfs Linux op draaien. Dan heb je al een platform waarmee je met de buitenwereld kunt communiceren. De DSPs van Texas Instruments kunnen dit niet of op een hele omslachtige manier.

Ik was van plan een blackfin te gaan gebruiken, werd me aangeraden door een ex docent. Hij heeft ook een TCP/IP library gemaakt voor de blackfin, en die kon ik ook gebruiken.

Die Blackfin kan ook DMA als ik me niet vergis...

Op 14 juli 2007 10:37:50 schreef stecj366:
Maar wat bedoelen ze nu eigenlijk met 1M*16? Mij lijkt dit dus 1M plaatsen van 2byte, dus in totaal 2Mbyte. Maar op

Je hebt dan wel een 16 bits databus. Je leest altijd een WORD tegelijk. Was misschien al duidelijk, maar ik zag het niet zo expliciet in voorgaande antwoorden.

Op 18 maart 2007 10:31:45 schreef stecj366:
Hallo,

1) veel RAM heeft (100ms samplen aan 250kHz, pakweg 12 bit resolutie = 292kbyte per channel. Er zouden tot 32 kanalen nodig zijn, dus in totaal 9MB.) Nu weet ik niet of 9MB intern in een FPGA bestaat...

De processor moet in C te programmeren zijn (goede compiler is dan geen overbodige luxe). Nu heb ik in één topic gelezen dat de 8051f120 menige DSP's op "z'n sokken klopt". F_E: kan je je nader verklaren?

de f120 heeft een hardware MAC engine aan boord. ideaal voor dsp achtige dingen. en het ding haalt 100 mips ...

maar. speel eens met sopc builder van altera.

stop ene nios II cpu in je fpga, hang er een grote externe razendsnelle aram aan ( een syc sram van cypress bijvoorbeeld de CY7C1061 of 1041 ) kost 5 dollar

en met de C to hardware compiler kan je je echte speciale routines compileren naar nios instructies. je kan ganse subroutines uitvoeren in hardware.. niks sneller dn dat.

download quartus 7.1 en de nios devkit .

Op 14 juli 2007 17:48:14 schreef stecj366:
registers uit en slaat ze op in de SRAM (via DMA). Dit DMA verhaal, houdt dat niet in dat de processor transfers kan doen in het geheugen zonder dat de processorcore erbij betrokken is? Hoe moet ik dat dan zien? Kan ik de FPGA opnemen in de geheugenmap van de processor, en ik breng dan een aantal adreslijntjes naar de FPGA, en hang de uitgangen van de FPGA aan de databus van de DSP?

dus we krijgen dan:

ADC---|
ADC-----> FPGA ---> DSP ---> SRAM
ADC---|

[...]

Ik was van plan een blackfin te gaan gebruiken, werd me aangeraden door een ex docent. Hij heeft ook een TCP/IP library gemaakt voor de blackfin, en die kon ik ook gebruiken.

Die Blackfin kan ook DMA als ik me niet vergis...

Dat kan, maar gezien jouw specs heb je helemaal geen FPGA nodig. De Blackfin (en de meeste andere DSPs) kan direct met meerdere A/D converters praten en de data in hapklare brokken inlezen. Dat maakt het ontwerp alleen maar makkelijker.

Een FPGA is alleen nodig als je heel veel snelheid nodig hebt of een aantal niet standaard onderdelen in een kleine ruimte bij elkaar wilt zetten. Jouw project voldoet aan geen van beide criteria

Het dual port maken van de RAM, hoe zit dit ongeveer in elkaar?

simpel voorgesteld zo:

             Memory Controller                 SRAM
            +------------------------+        +-----+
            |  +---+                 |        |     |
addr_1[] -->|->| R |------+          |        |     |
data_1[] <->|<>| E |<---+ |          |        |     |
rw_1     -->|->| G |--+ | |          |        |     |
            |  +---+  | | +->|\      |        |     |
clk_1    -->|---/\    | +--->| \     |        |     |
            |         +----->|M \--->|------->|addr |
            |  +---+         |U  \<->|<------>|data |
addr_2[] -->|->| R |-------->|X /--->|------->|rw   |
data_2[] <->|<>| E |<------->| /     |        |     |
rw_2     -->|->| G |-------->|/|     |        |     |
            |  +---+     +-----+---+ |        |     |
clk_2    -->|---/\       | DP_CTRL | |        |     |
            |            +---------+ |        |     |
            |                 /\     |        |     |
m_clk    -->|-----------------+----->|------->|clk  |
            +------------------------+        +-----+

Of terwijl, stel dat clk_1==clk_2. Dan neem je m_clk = 2*clk_1 zodat je in 1 periode van clk_1 2x een RAM operatie kan doen, 1x van ***_1 en 1x van ***_2.

Ik ben nu bezig met het ontwikkelen van een bordje met een Cyclone II FPGA en SDRAM geheugen (tot 64MB ongeveer). Het is binnekort klaar, dan post ik wel meer informatie.

Op 14 juli 2007 20:12:57 schreef flipflop:
[...]
Je hebt dan wel een 16 bits databus. Je leest altijd een WORD tegelijk. Was misschien al duidelijk, maar ik zag het niet zo expliciet in voorgaande antwoorden.

Ja dat was ondertussen al duidelijk, toch bedankt

Op 14 juli 2007 20:26:22 schreef free_electron:
[...]
maar. speel eens met sopc builder van altera.

stop ene nios II cpu in je fpga, hang er een grote externe razendsnelle aram aan ( een syc sram van cypress bijvoorbeeld de CY7C1061 of 1041 ) kost 5 dollar

en met de C to hardware compiler kan je je echte speciale routines compileren naar nios instructies. je kan ganse subroutines uitvoeren in hardware.. niks sneller dn dat.

download quartus 7.1 en de nios devkit .

Ja, dat is eventueel ook nog wel een optie. Ik heb al met zo een tool gewerkt bij Xilinx, maar ik moet toch wel toegeven dat het vrij omslachtig werkte... Vooral de snelheid viel me tegen (van het synthetiseren). Ik zal dan eventueel toch eens de overstap moeten gaan maken vrees ik Maar dan zou ik een dev board met een altera FPGA kunnen gebruiken, daar een kaartje voor men ADC's voor maken en het is in orde. Ik ga de software eens bekijken. Eventueel nog suggesties voor board/ADC's, of lijkt je het zelf bouwen van een board toch zinvoller?

EDIT: Ik heb eens wat video tutorials van altera bekeken, en wat altera hier biedt aan functionaliteit is echt wel schokkend... Volledige routines implementeren in hardware... Straf. Maar ik stel me hier wel wat vragen bij. Is het echt altijd zo simpel als ze aangeven in hun tutorials? Kan je echt elke routine accelereren? Eender welke?

En die avalon interface, is dat wat te doen om daar een slave voor te maken? Zodat ik de ADC controllers mee kan opnemen in het systeem?

Op 14 juli 2007 20:44:28 schreef Nico.c:
[...]

Dat kan, maar gezien jouw specs heb je helemaal geen FPGA nodig. De Blackfin (en de meeste andere DSPs) kan direct met meerdere A/D converters praten en de data in hapklare brokken inlezen. Dat maakt het ontwerp alleen maar makkelijker.

Ook 32 ADC's tegelijk tegen 250kHz (vrij synchroon is hier belangrijk), zonder dat de DSP constant zich bezig houdt met het samplen?

Op 14 juli 2007 21:08:26 schreef xantus:
[...]

Mooie figuur...

Of terwijl, stel dat clk_1==clk_2. Dan neem je m_clk = 2*clk_1 zodat je in 1 periode van clk_1 2x een RAM operatie kan doen, 1x van ***_1 en 1x van ***_2.

Ok, duidelijk, en niet al te moeilijk te implementeren lijkt me.

Op 14 juli 2007 21:45:35 schreef miniK0bo:
Ik ben nu bezig met het ontwikkelen van een bordje met een Cyclone II FPGA en SDRAM geheugen (tot 64MB ongeveer). Het is binnekort klaar, dan post ik wel meer informatie.

Bedankt!

Op 15 juli 2007 08:25:24 schreef stecj366:
Ook 32 ADC's tegelijk tegen 250kHz (vrij synchroon is hier belangrijk), zonder dat de DSP constant zich bezig houdt met het samplen?

De meeste DSPs hebben een aantal speciale bussen voor A/D converters. Deze bussen werken autonoom samen met de A/D converters en zetten de gesamplede data voor je klaar op een plek in het geheugen met behulp van DMA. Je bent wel een beetje geheugen bandbreedte kwijt, maar het kost verders vrijwel geen processortijd. Het synchroon samplen regelen de A/D converters ook intern (als je de juiste kiest).

Lees de datasheets van diverse DSPs en A/D converters maar eens door en kijk wat ze te bieden hebben op dit gebied.

Momenteel denk ik er sterk over na om Altera FPGA en Nios II te gaan gebruiken. De software die ik nu van het web heb gedownload werkt heel intuïtief en goed. De zaken die ik nodig heb zijn allemaal aanwezig, en de functies zoals offloaden van routines naar hardware zijn fenomenaal.

Nu had ik wel een vraag mbt de gratis versies. Hebben deze allemaal de functies die ik juist heb aangehaald, of ga ik uiteindelijk toch software moeten aankopen om de full werking te verkrijgen?

Ik denk persoonlijk dat het interessant is om een dev board met een dikke fpga te nemen. Welke zouden jullie aanraden (dus sampling, Filtering, Nios processor, interne ram, ...) en dan heb ik ethernet, usb progger, expantion connector en SRAM nodig. Iemand een goed idee (ben niet zo thuis in de altera wereld)

DE2 board? kun je krijgen via terasic
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&amp…

Je moet maar even kijken, het kost iets van 269$ voor universiteiten dus even kijken of je het via het education program kunt krijgen.

Voor niosII moet je (afhankelijk van welke nios je gebruikt) betalen. Deze zit standaard bij een betaalde versie van Quartus (dacht ik?)

Als je simultaan wilt sampelen (dus niet via een bus, maar alles direct) dan heb je met die 32 12 bit ADC wel een serieus IO probleem, 384 IO pinnen zijn wel een probleem....

Als je alles bundelt via een of meerder bus(en) dan valt het dan wel weer mee.

Maar wil je met dit apparaat een antenne array uit gaan lezen? Om iets als deterministische bundelvorming te doen, om te zien waar een zender staat t.o.v de antenne array?

dit is dan iets dat je wel interessant zult vinden:
http://casper.berkeley.edu/papers/beamforming.pdf

[Bericht gewijzigd door surge_me op zondag 15 juli 2007 12:49:47 (17%)]