Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
glen herrmannsfeldt wrote: > There were some interesting designs that Peter Alfke used to > come up with, but he knew which were and were not going to work. > > Among others, he has a divide by 2.5 counter. (I don't think > it uses these tricks, but is interesting anyway.) They can > be used for clocking on rising and falling edge, though. Yes, this is an interesting design. If you are a senior engineer at Xilinx, you are allowed to do such interesting things, which might fail in simulators, but works nice in FPGAs. My designs are sometimes the other way: works in simulators, but fails in real FPGAs :-) -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142676
glen herrmannsfeldt wrote: > This reminds me of the stories of Cray using PC board traces > to delay signals such that they would arrive at the desired > time at the destination gate. > Completely standard practice. Look at any motherbhoard since the '386 went out of style, but especially any with DDR memories or PCI slots, and you will see "squiggles" in the traces to lengthen the wires that came out too short in the routing. Obviously, you can't make a wire shorter without finding a more efficient route between the endpoints. If all signals on a bus need equal length, then you add length to the short ones. > Basically, if you take a signal, delay it by two different values, > then feed the two into an XOR gate, you will get a pulse with > a length depending on the difference in the delay. But, yeah, what the OP suggests sounds like a VERY hard way to do things, get very unpredictable results, generally find a lot of frustration. JonArticle: 142677
Jon Elson <jmelson@wustl.edu> wrote: < glen herrmannsfeldt wrote: <> This reminds me of the stories of Cray using PC board traces <> to delay signals such that they would arrive at the desired <> time at the destination gate. < Completely standard practice. Look at any motherbhoard since the '386 < went out of style, but especially any with DDR memories or PCI slots, < and you will see "squiggles" in the traces to lengthen the wires that < came out too short in the routing. Obviously, you can't make a wire < shorter without finding a more efficient route between the endpoints. < If all signals on a bus need equal length, then you add length to the < short ones. I have noticed those. The same problem, but on a shorter time scale. <> Basically, if you take a signal, delay it by two different values, <> then feed the two into an XOR gate, you will get a pulse with <> a length depending on the difference in the delay. < But, yeah, what the OP suggests sounds like a VERY hard way < to do things, get very unpredictable results, generally find < a lot of frustration. Maybe the frustration is the idea for the whole project. That is, a practical demonstration of the advantages of synchronous design. It does seem much harder in an FPGA than with TTL gates, though. Especially with TTL you can build an analog delay with continuous delay time, adjust it, and watch what happens. Much harder to do that inside the FPGA. -- glenArticle: 142678
On Aug 25, 1:56=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Jon Elson <jmel...@wustl.edu> wrote: > < glen herrmannsfeldt wrote: > > <> This reminds me of the stories of Cray using PC board traces > <> to delay signals such that they would arrive at the desired > <> time at the destination gate. =A0 > > < Completely standard practice. =A0Look at any motherbhoard since the '38= 6 > < went out of style, but especially any with DDR memories or PCI slots, > < and you will see "squiggles" in the traces to lengthen the wires that > < came out too short in the routing. =A0Obviously, you can't make a wire > < shorter without finding a more efficient route between the endpoints. > < If all signals on a bus need equal length, then you add length to the > < short ones. > > I have noticed those. =A0The same problem, but on a shorter > time scale. =A0 > > <> Basically, if you take a signal, delay it by two different values, > <> then feed the two into an XOR gate, you will get a pulse with > <> a length depending on the difference in the delay. > > < But, yeah, what the OP suggests sounds like a VERY hard way > < to do things, get very unpredictable results, generally find > < a lot of frustration. > > Maybe the frustration is the idea for the whole project. > That is, a practical demonstration of the advantages of > synchronous design. =A0 > > It does seem much harder in an FPGA than with TTL gates, though. > Especially with TTL you can build an analog delay with continuous > delay time, adjust it, and watch what happens. =A0Much harder to > do that inside the FPGA. > > -- glen Maybe the goal is not to create asynchronous delays, but rather a multiphase clock, each phase offset from the next by much less than a clock period. DDR would be the simplest form of this. AndyArticle: 142679
Hello-- I'm setting up a circuit where I need to write data to a DAC at the same time as read data from 8 ADCs. I need to shift a data word out to the DAC to set an output voltage. At the same time, I need to read data from each ADC. The DAC and the ADCs all communicate over SPI. The maximum sampling rate of each 18-bit ADC is 400 kHz. The maximum update rate of each 16-bit DAC is 400 kHz, the same as the sampling rate as the ADC. Sampling from each ADC is triggered using a /TRIGGER pin. I believe that it is possible to daisy-chain the ADCs. Perhaps the best way to do this is to use a FPGA. I suppose that I would set up a separate SPI bus for each ADC and DAC, and separate /CS lines. All of the ADCs and DACs would not be on the same SPI bus. As the data is harvested from each ADC, I could shift the data into SDRAM. Once the measurement sequence is complete, the main system micro- controller could read the data from the FPGA SDRAM by using the FPGA as an SPI slave. Is this a good way to proceed? My first initiative is to perhaps use a Cyclone III FPGA with 3.3V SDRAM logic, although I think that there are probably other FPGAs that could work just as well. Are there any free/gratis megafunction solutions for SPI and communication with SDRAM logic? What should I choose to be the clock speed on the FPGA, based on the maximum SPI bus rates? The DAC has a maximum SPI clock of 30 MHz, and the max clock speed of the ADC is at least 50 MHz.Article: 142680
On Aug 26, 7:54=A0am, Nicholas Kinar <n.ki...@usask.ca> wrote: > Hello-- > > I'm setting up a circuit where I need to write data to a DAC at the same > time as read data from 8 ADCs. > > I need to shift a data word out to the DAC to set an output voltage. =A0A= t > the same time, I need to read data from each ADC. > > The DAC and the ADCs all communicate over SPI. =A0The maximum sampling > rate of each 18-bit ADC is 400 kHz. =A0The maximum update rate of each > 16-bit DAC is 400 kHz, the same as the sampling rate as the ADC. > > Sampling from each ADC is triggered using a /TRIGGER pin. =A0I believe > that it is possible to daisy-chain the ADCs. > > Perhaps the best way to do this is to use a FPGA. =A0I suppose that I > would set up a separate SPI bus for each ADC and DAC, and separate /CS > lines. All of the ADCs and DACs would not be on the same SPI bus. > > As the data is harvested from each ADC, I could shift the data into > SDRAM. Once the measurement sequence is complete, the main system micro- > controller could read the data from the FPGA SDRAM by using the FPGA as > an SPI slave. > > Is this a good way to proceed? My first initiative is to perhaps use a > Cyclone III FPGA with 3.3V SDRAM logic, although I think that there are > probably other FPGAs that could work just as well. > > Are there any free/gratis megafunction solutions for SPI and > communication with SDRAM logic? > > What should I choose to be the clock speed on the FPGA, based on the > maximum SPI bus rates? =A0The DAC has a maximum SPI clock of 30 MHz, and > the max clock speed of the ADC is at least 50 MHz. why do you think you need SDRAM? what you need is just a statemachine-sequencer-special purpose SPI engine that places the results into dual port block ram (available in any FPGA) and as you requests are not standard you need to write the code from scratch AnttiArticle: 142681
Antti.Lukats@googlemail.com wrote: > why do you think you need SDRAM? > > what you need is just a statemachine-sequencer-special purpose SPI > engine > that places the results into dual port block ram (available in any > FPGA) This depends on how long he wants to sample. If he needs some kilobytes, block RAM would be ok. If it is below a megabyte, I would suggest SRAM, because it is much easier to write your own VHDL code for it. And I would use a ready made module, like this one, at least for the prototyping phase, if it is going to be a product: http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_48&products_id=81 More expensive, but with more pins and SDRAM instead of SRAM: http://www.enterpoint.co.uk/moelbryn/darnaw1.html -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142682
Thanks for your response, Antti. > > why do you think you need SDRAM? > Perhaps to store large amounts of data from all of the 6 ADCSs? > what you need is just a statemachine-sequencer-special purpose SPI > engine > that places the results into dual port block ram (available in any > FPGA) > That is an interesting idea. But how much RAM do I generally have available? > and as you requests are not standard you need to write the code from > scratch Would SPI be a challenge to implement in the way that I have described?Article: 142683
Frank Buss wrote: > Antti.Lukats@googlemail.com wrote: > >> why do you think you need SDRAM? >> >> what you need is just a statemachine-sequencer-special purpose SPI >> engine >> that places the results into dual port block ram (available in any >> FPGA) > > This depends on how long he wants to sample. If he needs some kilobytes, > block RAM would be ok. If it is below a megabyte, I would suggest SRAM, > because it is much easier to write your own VHDL code for it. And I would > use a ready made module, like this one, at least for the prototyping phase, > if it is going to be a product: > > http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_48&products_id=81 > > More expensive, but with more pins and SDRAM instead of SRAM: > > http://www.enterpoint.co.uk/moelbryn/darnaw1.html > Sounds good, Frank. Thank you for your response. Do you think that most of this stuff could be easily done in Verilog as well? SRAM sounds nice, but isn't there some sort of reference implementation/plugin/megafunction for accessing this type of memory?Article: 142684
On Aug 26, 8:40=A0am, Nicholas Kinar <n.ki...@usask.ca> wrote: > Thanks for your response, Antti. > > > > > why do you think you need SDRAM? > > Perhaps to store large amounts of data from all of the 6 ADCSs? > > > what you need is just a statemachine-sequencer-special purpose SPI > > engine > > that places the results into dual port block ram (available in any > > FPGA) > > That is an interesting idea. But how much RAM do I generally have availab= le? > > > and as you requests are not standard you need to write the code from > > scratch > > Would SPI be a challenge to implement in the way that I have described? SPI =3D VERY simple SRAM =3D SIMPLE the amount of BRAM depends on the FPGA, i think smallest cyclone-3 has 66 KByte (smallest spartan3a has only 6KByte) for SRAM, well there are of course IP cores that use SRAM, but those are most like soft-processor bus attachments, so not necessarily much help for you but SRAM access is really very simple, not compared to the pain that it is needed for SDRAM GOP200 module is real nice small cute thing, I have one on my desk too trenz is also very soon having S3ADSP low cost modules with SDRAM / but S3ADSP1800 has already 126KB of BRAM AnttiArticle: 142685
Nicholas Kinar <n.kinar@usask.ca> wrote: < I'm setting up a circuit where I need to write data to a DAC at the same < time as read data from 8 ADCs. < I need to shift a data word out to the DAC to set an output voltage. At < the same time, I need to read data from each ADC. < The DAC and the ADCs all communicate over SPI. The maximum sampling < rate of each 18-bit ADC is 400 kHz. The maximum update rate of each < 16-bit DAC is 400 kHz, the same as the sampling rate as the ADC. How fast is SPI? < Sampling from each ADC is triggered using a /TRIGGER pin. I believe < that it is possible to daisy-chain the ADCs. Maybe not if the bus isn't that fast. < Perhaps the best way to do this is to use a FPGA. I suppose that I < would set up a separate SPI bus for each ADC and DAC, and separate /CS < lines. All of the ADCs and DACs would not be on the same SPI bus. Separate SPI bus would allow each to run at full speed. < As the data is harvested from each ADC, I could shift the data into < SDRAM. Once the measurement sequence is complete, the main system micro- < controller could read the data from the FPGA SDRAM by using the FPGA as < an SPI slave. Why store it in SDRAM? Process it and send it out immediately. Well, 400kHz isn't so fast, but you could just build a state machine in the FPGA. Otherwise you might just as well use any old processor. -- glenArticle: 142686
> > SPI = VERY simple > SRAM = SIMPLE > Yes, I agree that SPI and SRAM are simple. > > GOP200 module is real nice small cute thing, I have one on my desk too > trenz is also very soon having S3ADSP low cost modules with SDRAM > / but S3ADSP1800 has already 126KB of BRAM > > Antti I'll check it out, thanks Antti.Article: 142687
Thanks, Glen. > How fast is SPI? > Maximum 30MHz, I believe. > > Why store it in SDRAM? Process it and send it out immediately. > Perhaps what this would guarantee is "real-time," especially when working with Linux-based microcontrollers. > Well, 400kHz isn't so fast, but you could just build a state > machine in the FPGA. Otherwise you might just as well use > any old processor. > Sure, even if the processor is running Linux, "almost real-time" is sometimes less complex than real-time. Perhaps all of the ADCs and the DAC could be wired to the same bus?Article: 142688
On Aug 25, 1:36=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > Look at documentation for the simulator's "drivers" command; this may hel= p you > identify the unwanted signal source. > To add on to Brian's suggestion... Then, after having identified the offending drivers, but before you put the change in to fix the problem, try this: 1. Change the data type for that signal from 'std_logic' (or 'std_logic_vector') to 'std_ulogic' (or 'std_ulogic_vector'). 2. Recompile and watch the compiler immediately flag the multiple drivers for you without any debug effort or newsgroup posting. 3. Ask yourself if you really like spending your time debugging this type of error or if having the compiler flag it for you isn't the better way to go? 4. Throw mental darts at the picture of whoever first taught you VHDL and told you that std_logic was the way to define signals with little or no mention of std_ulogic. 5. Start using std_ulogic for signals that can only be driven by one driver (hint: that's most signals) Kevin JenningsArticle: 142689
On 26 Aug., 06:54, Nicholas Kinar <n.ki...@usask.ca> wrote: > Hello-- > > I'm setting up a circuit where I need to write data to a DAC at the same > time as read data from 8 ADCs. > > I need to shift a data word out to the DAC to set an output voltage. =A0A= t > the same time, I need to read data from each ADC. > > The DAC and the ADCs all communicate over SPI. =A0The maximum sampling > rate of each 18-bit ADC is 400 kHz. =A0The maximum update rate of each > 16-bit DAC is 400 kHz, the same as the sampling rate as the ADC. > > Sampling from each ADC is triggered using a /TRIGGER pin. =A0I believe > that it is possible to daisy-chain the ADCs. > > Perhaps the best way to do this is to use a FPGA. =A0I suppose that I > would set up a separate SPI bus for each ADC and DAC, and separate /CS > lines. All of the ADCs and DACs would not be on the same SPI bus. > > As the data is harvested from each ADC, I could shift the data into > SDRAM. Once the measurement sequence is complete, the main system micro- > controller could read the data from the FPGA SDRAM by using the FPGA as > an SPI slave. > > Is this a good way to proceed? My first initiative is to perhaps use a > Cyclone III FPGA with 3.3V SDRAM logic, although I think that there are > probably other FPGAs that could work just as well. > > Are there any free/gratis megafunction solutions for SPI and > communication with SDRAM logic? > > What should I choose to be the clock speed on the FPGA, based on the > maximum SPI bus rates? =A0The DAC has a maximum SPI clock of 30 MHz, and > the max clock speed of the ADC is at least 50 MHz. shouldn't need to read and write at the same time if the ADCs have a trigger pin, write the DAC value, hit the trigger to all ADCs, with a fast spi clk there's then plenty of time to read the ADCs one at a time before the next cycle -LasseArticle: 142690
> > shouldn't need to read and write at the same time if the ADCs have a > trigger pin, > > write the DAC value, hit the trigger to all ADCs, with a fast spi clk > there's then > plenty of time to read the ADCs one at a time before the next cycle > > -Lasse > What would be an approximate latency on the measurement? Would it be more than possible to use a single microcontroller instead of a FPGA?Article: 142691
Nicholas Kinar wrote: > Sounds good, Frank. Thank you for your response. Do you think that most > of this stuff could be easily done in Verilog as well? Yes. I prefer VHDL, because the compiler warns me more than Verilog, if I write dumb code :-) > SRAM sounds nice, but isn't there some sort of reference > implementation/plugin/megafunction for accessing this type of memory? SRAM is simple. I would just read the datasheet and implement the timing diagrams, integrated with your statemachine for the ADCs and reading from your main CPU. This could be easier than to figure out how to use a megafunction, maybe with lots of options you'll never need, but which you have to understand and to configure. For SDRAM I would use a megafunction, if available, because this would be more difficult to write your own code for it. But if you don't need to cache lots of data, e.g. if your main CPU is running some kind of realtime OS, like some realtime Linux patch, then maybe you have to cache only a small amount of data (depends on the maximum latency of your operating system and your realtime, i.e. no-bit-loss, requirements) and block RAM is sufficient. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142692
Nicholas Kinar wrote: > What would be an approximate latency on the measurement? Would it be > more than possible to use a single microcontroller instead of a FPGA? Most SPI ports for microcontrollers are too slow to handle your requirements, if you don't access the ADCs in parallel. You have 8 ADCs, each with 18 bit and max. 400 kHz. This means 57.6 MHz SPI clock, for the data only. And usually there is some overhead in the SPI communication, like padding to 24 bits, setting chipselect, register adressing etc. and maybe your ADCs don't like 57 MHz SPI clock either. Even if you read the data with a FPGA, you should think how to transfer it to your main CPU. Using SPI could be difficult, because you'll need more than 57 MHz, if you don't transfer continously. If the main CPU is the master, the FPGA has to sample 57 MHz SPI clock, which means you'll need more than 150 MHz FPGA clock, if you want fail safe detection. This means more expensive FPGAs, because with lots of wide logic, like saving multiple 18 bit words, it gets slower and your maximum allowed clock maybe slower than 150 MHz, or you'll need some FIFO and multiple clock inside the FPGA. One main advantage of FPGAs is the parallel processing. In VHDL you can write one entity and instantiate it multiple times, even with loops, but maybe this is possible with Verilog, too. This accumulates the data in parallel. Then use a parallel interface to your main CPU, if it is possible, to read the cached and deserialized data. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142693
On Aug 27, 5:17=A0am, Nicholas Kinar <n.ki...@usask.ca> wrote: > > What would be an approximate latency on the measurement? =A0Would it be > more than possible to use a single microcontroller instead of a FPGA? What latency can you tolerate, in absolute terms, and jitter ? 'at the same time' is not telling us much! With a SPI system even if the clocks are sync, what you shift in, will be well time advanced from what the DAC finally updates to. What else happens between the 8 ADC's and the 1? DAC. ? What are your actual data rates ? In the simplest system, you could use Logic to assist a host uC, to manage 9 SPI ports as a Multichannel Par/SPI peripheral. The smallest FPGA would manage that, or even a medium-CPLD. -jgArticle: 142694
> Yes. I prefer VHDL, because the compiler warns me more than Verilog, if I > write dumb code :-) > Agreed. I'm like that as well too! > SRAM is simple. I would just read the datasheet and implement the timing > diagrams, integrated with your statemachine for the ADCs and reading from > your main CPU. This could be easier than to figure out how to use a > megafunction, maybe with lots of options you'll never need, but which you > have to understand and to configure. For SDRAM I would use a megafunction, > if available, because this would be more difficult to write your own code > for it. I think that there's such a megafunction for SRAM and SDRAM available in Quartus II from Altera. Is this freely licensable? > > But if you don't need to cache lots of data, e.g. if your main CPU is > running some kind of realtime OS, like some realtime Linux patch, then > maybe you have to cache only a small amount of data (depends on the maximum > latency of your operating system and your realtime, i.e. no-bit-loss, > requirements) and block RAM is sufficient. > Would it be possible to have the FPGA copy the data into SDRAM rather than stream all of the data through to the main processor? My application involves sampling data from the ADC for only ~1.0 seconds. Then what I would have to do is process the data. So it would be possible for the data to be leisurely transferred to the master by setting up the FPGA as an SPI slave.Article: 142695
> > Most SPI ports for microcontrollers are too slow to handle your > requirements, if you don't access the ADCs in parallel. You have 8 ADCs, > each with 18 bit and max. 400 kHz. This means 57.6 MHz SPI clock, for the > data only. And usually there is some overhead in the SPI communication, > like padding to 24 bits, setting chipselect, register adressing etc. and > maybe your ADCs don't like 57 MHz SPI clock either. I'm using the AD7690 SAR ADC from Analog Devices. This particular ADC has a serial SPI bus. > > Even if you read the data with a FPGA, you should think how to transfer it > to your main CPU. Using SPI could be difficult, because you'll need more > than 57 MHz, if you don't transfer continously. If the main CPU is the > master, the FPGA has to sample 57 MHz SPI clock, which means you'll need > more than 150 MHz FPGA clock, if you want fail safe detection. This means > more expensive FPGAs, because with lots of wide logic, like saving multiple > 18 bit words, it gets slower and your maximum allowed clock maybe slower > than 150 MHz, or you'll need some FIFO and multiple clock inside the FPGA. > The total time of measurement is ~1 second. So the ADCs and the DAC will only be operating for ~1s. Would it be better to simply have the FPGA cache the data in SRAM/SDRAM, and then have the main microcontroller read the data from the FPGA as a slave? Would this still work, or are there still challenges associated with using serial ADCs with a FPGA? > One main advantage of FPGAs is the parallel processing. In VHDL you can > write one entity and instantiate it multiple times, even with loops, but > maybe this is possible with Verilog, too. This accumulates the data in > parallel. Then use a parallel interface to your main CPU, if it is > possible, to read the cached and deserialized data. > I'm using the AVR32 AP7001 from Atmel. There's only a parallel memory bus on this processor. Unfortunately, there's no specialized bus for just communicating with the FPGA.Article: 142696
> > Most SPI ports for microcontrollers are too slow to handle your > requirements, if you don't access the ADCs in parallel. You have 8 ADCs, BTW, I could reduce the number of ADCs from 8 to 6. Would this help to reduce the throughput requirements somewhat?Article: 142697
Thanks for your response, jg! > > What latency can you tolerate, in absolute terms, and jitter ? > 'at the same time' is not telling us much! I can't tolerate much latency since what I am doing is using the DAC to produce a waveform which is then used as the input for a Linear Time Invariant system. The outputs of the system are being digitized at the same time by the 8 ADCs. I am interested in determining the impulse response of the device under test, knowing the input and the output of the system. How much latency would this type of application tolerate? Perhaps as little as can be attained. > > What else happens between the 8 ADC's and the 1? DAC. ? I need a way to perhaps cache the data. The idea is to run the ADCs for ~1 second sampling time, and then process the data. > > What are your actual data rates ? > > In the simplest system, you could use Logic to assist a host uC, to > manage 9 SPI ports as a Multichannel Par/SPI peripheral. > The smallest FPGA would manage that, or even a medium-CPLD. > That's really quite an interesting idea. I need to sample at a minimum rate of 200 kHz.Article: 142698
Nicholas Kinar wrote: > I can't tolerate much latency since what I am doing is using the DAC to > produce a waveform which is then used as the input for a Linear Time > Invariant system. The outputs of the system are being digitized at the > same time by the 8 ADCs. I am interested in determining the impulse > response of the device under test, knowing the input and the output of > the system. > > How much latency would this type of application tolerate? Perhaps as > little as can be attained. I think jg means, if you have to generate the DAC signal in response of the ADC signals and how much latency you can tolerate, e.g. you measure some ADC value and then 1 ms later you need to generate a new calculated DAC value. I've found this page for Linear Time Invariant system: http://en.wikipedia.org/wiki/LTI_system_theory If I understand it correctly, you don't need to do some realtime calculation for the DAC in response to the ADC? You just generate 1 s of pre-calculated data at the DAC and at the same time read 1 s data from the ADCs? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142699
Nicholas Kinar wrote: > I'm using the AVR32 AP7001 from Atmel. There's only a parallel memory > bus on this processor. Unfortunately, there's no specialized bus for > just communicating with the FPGA. So this is the chip you are using? http://www.atmel.com/dyn/resources/prod_documents/doc32015.pdf From the datasheet there are at least the following ports, which could be used for communicating with the FPGA: - SRAM interface: Yes, the FPGA can behave like a SRAM. This is as simple as accessing a SRAM from a FPGA, just the other way around - SSC interface: With 150 MHz master clock, this works up to 75 MHz, so should be fine for reading the ADCs I've used the SRAM interface with another system with a CPU and a FPGA. From the CPU side this is the simplest communication way, because you just write and read from memory locations. The FPGA gets the chipselect, decodes the address and provides the data or reads in the data. Maybe DMA transfer is possible, too. SSC is another nice interface. I've used this in another Atmel chip (9g20) with PDC transfer. This makes it really easy, compared to the usual DMA setup procedure: You just setup the number of words you want to receive, the address to which it should write and then it reads the SSC interface and issues an interrupt when done. The drawback would be, that you are at the limit with the speed for the SSC for 400 kHz for 8 ADCs, but it should work. With SRAM you'll have lots of bandwith. Make sure to clock the FPGA with the master clock, then you don't need to do edge detection and the like. Maybe this works: Use block RAM for a small ringbuffer for the ADC and DAC values, generate interrupts on FIFO thresholds and use the DMA on the CPU side to transfer the data. SRAM PCB routing to the FPGA could be more difficult than the SSC interface. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z