confusion with ADC/DAC interface implementation
in [FPGA]
|
Prev: Synplify synthesis error
Next: OFFSET and OFFSET out
From: alkosd on 22 Apr 2010 20:41 Hi, i am confused regarding the ADC/DAC interface implementation on FPGA. I have read a code where after serialising the input data of 16 bits in 16 clock cycles, the interface logic loops (in vain?) for another 16 cyles before serialising the next data. can#t understand why? why the serialisation of the next data is not done immediately. moreover, should the serialisation clock rate be 16 higher than the data stream clock rate? Sorry but i could not find a documentation detailing all the synchronization mechanism. cheers :)
From: alkosd on 23 Apr 2010 16:00 > Find the datasheets and (hopefully) all should become clear, thank you for the advice. I got the datasheet at last! i'll work on the details now. thank you again
From: Górski Adam on 23 Apr 2010 11:18 alkosd(a)yahoo.co.uk pisze: > Hi, > i am confused regarding the ADC/DAC interface implementation on FPGA. > I have read a code where after serialising the input data of 16 bits > in 16 clock cycles, the interface logic loops (in vain?) for another > 16 cyles before serialising the next data. can#t understand why? why > the serialisation of the next data is not done immediately. moreover, > should the serialisation clock rate be 16 higher than the data stream > clock rate? Sorry but i could not find a documentation detailing all > the synchronization mechanism. > > cheers :) Hi, Please specify your ADC DAC type. BR Adam
From: HT-Lab on 23 Apr 2010 11:49 <alkosd(a)yahoo.co.uk> wrote in message news:3bf71478-a08c-4165-9af5-98edd3548e89(a)8g2000yqz.googlegroups.com... > Hi, > i am confused regarding the ADC/DAC interface implementation on FPGA. > I have read a code where after serialising the input data of 16 bits > in 16 clock cycles, the interface logic loops (in vain?) for another > 16 cyles before serialising the next data. can#t understand why? As suggested by others your question is very vague, however, some SPI ADC have the option to stream out the LSB first. In order to do this you first need to stream out the MSB_first word and then you can read the LSB_first word (this makes perfect sense for a successive approximation ADC). Thus in the LSB case you need 2 sets of n-bit clock cycles. Find the datasheets and (hopefully) all should become clear, Hans www.ht-lab.com > why > the serialisation of the next data is not done immediately. moreover, > should the serialisation clock rate be 16 higher than the data stream > clock rate? Sorry but i could not find a documentation detailing all > the synchronization mechanism. > > cheers :)
From: KJ on 22 Apr 2010 21:42
On Apr 22, 8:41 pm, alk...(a)yahoo.co.uk wrote: > Hi, > i am confused regarding the ADC/DAC interface implementation on FPGA. > I have read a code where after serialising the input data of 16 bits > in 16 clock cycles, the interface logic loops (in vain?) for another > 16 cyles before serialising the next data. can#t understand why? Because things work as they are designed...not as they are intended. Do you have a specific question or are you trolling and asking the group to fathom why some unlisted code that is implemented in an FPGA either keeps reading from an ADC or keeps writing to a DAC or perhaps both? > why > the serialisation of the next data is not done immediately. moreover, Thought you just said it tried again, as you say "in vain?"...sounds immediate to me > should the serialisation clock rate be 16 higher than the data stream > clock rate? If the ADC shifts out 16 bits of data, then yes it would need to be at least 16 times as fast as you'd like to sample the analog data. > Sorry but i could not find a documentation detailing all > the synchronization mechanism. > Are you asking the group to find the documentation for you? What you need is the datasheet for whatever ADC or DAC that you're talking about. Try a more informed posting after you've put some though into your question and provide some actual details of what you don't understand and you'll likely get better responses. KJ |