Xillybus core customization for fft spectrometer application

Post a reply

Confirmation code
Enter the code exactly as it appears. All letters are case insensitive.
Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:
BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON
Topic review
   

Expand view Topic review: Xillybus core customization for fft spectrometer application

Re: Xillybus core customization for fft spectrometer applica

Post by support »

Hello,

/dev/xillybus_* device files, like many other device files in Linux, aren't files in the classic sense: They don't store the information like a disk file. It's just a well-established trick to communicate data. So nothing is really stored.

Instead, you have a stream of data. Once you've read some data from the device file, it's consumed and gone. Same goes the other way. What you write into a device file will appear once in the FIFO on the other side.

Regards,
Eli

Re: Xillybus core customization for fft spectrometer applica

Post by Guest »

Thank you,

Will try that !

Also, the data read from the fifo once to /dev/<fifo_name> will stay on the file until its overwritten by subsequents writes ?

Thanks,

Mugundhan

Re: Xillybus core customization for fft spectrometer applica

Post by support »

Hello,

The access of Xillybus device files should be done following classic UNIX practices, as Xillybus' driver is written to behave according to these.

Having said that, the Xillybus host application programming guide for Linux brings together much of what you need to know to get it done right:

http://xillybus.com/downloads/doc/xilly ... _linux.pdf

As for outputting to a plain file, it should be done the same way as outputting to a device file, so the guide can be referred to on this task as well.

Besides, the streamread/streamwrite sample programs in the Linux bundle are already written according to these guidelines. The only thing to be wary about is that the buffer size in these programs is too small, and should be replaced with a larger buffer that is allocated with malloc() or similar.

Regards,
Eli

Re: Xillybus core customization for fft spectrometer applica

Post by Guest »

Hello,

I was using cat and hexdump already. I'll try dd too. I was looking for some guidance from point of view of writing C codes for acquisition from /dev/<device name> and file write. I googled it, but didn't get what I wanted. So I thought I'd ask for your suggestion on this :)

Thanks !

Mugundhan

Re: Xillybus core customization for fft spectrometer applica

Post by support »

Hello,

The simplest way is to use the "cat" and "dd" standard UNIX command-line utilities. Just keep in mind that if the target disk is slower than the data arriving (which is usually the case) the possible depth of your capture depends a lot on the depth of the DMA buffers (configurable on the IP Core Factory) and the disk cache offered by the operating system.

For relatively short captures (say, a few MB) "dd" is the way to go, as it allow you to limit the amount of data read. For an instant view of the data, hexdump is handy.

You may also find this page useful:

http://xillybus.com/doc/bandwidth-guidelines

Regards,
Eli

Re: Xillybus core customization for fft spectrometer applica

Post by Guest »

Hello,

I was able to read out 8192*32 bit samples from fifo in burst mode. Now, I'd like to playaround on the host side. Can you point me to some references which will be useful for me to get started in reading the data coming via xillybus and storing it to a binary file ?

Thank you !

Mugundhan

Re: Xillybus core customization for fft spectrometer applica

Post by Guest »

Oh yeah, I connected the bus_clk to the read clock. What I tried to mean by floating was that if it was ok for the synthesizer to tie them to ground. Yeah, got the answer for that ! Thanks !

Re: Xillybus core customization for fft spectrometer applica

Post by support »

Hello,

There is no such things as "floating" in FPGA. If you don't assign a signal a value, the synthesizer assigns it a zero ("GND") and issues a (harmless) warning.

You didn't mention connecting the FIFO's empty signal to the Xillybus module however. I suppose you just forgot to mention that. And what's the "read clock" you did mention? "bus_clk" should go to the FIFO's read clock, and the write clock to the clock you're using to write with.

To your question: If you intend to ignore certain Xillybus streams on the host side, it's fine not to connect anything to the respective signals on the FPGA side. Or even delete the rows in the assignment list of the instantiation of the Xillybus module. The result will be that all that you write towards these streams is lost, and you'll read all zeros. Not that it matters.

Regards,
Eli

Re: Xillybus core customization for fft spectrometer applica

Post by mugundhan »

Hello Again Eli,

I modified the xillycapture module added a counter at 100 MHz, filling in a fifo and trying to transmit about 8192 4 byte counts. From the xillybus interface, I connected the read_32 fifo_rd_en signals, bus clock as the read enable and read clock for these signals. I have my own write logic, so I left the write_32 signals on the xillybus floating as I don't need them now. I also did the same for read_8 signals, where I have a 8 bit wide 64 byte deep fifo, where I only write, so I left the read signals floating. Is this ok ? or must these signals need be asserted to 0 or Vdd ?

Sorry for asking a very trivial question, but didn't want to progress without clarification ^_^ .

thank you !

Re: Xillybus core customization for fft spectrometer applica

Post by support »

Hello,

Indeed, if there is no more data to read, and a read() call is issued on the host, this call will wait until there is some data by sleeping ("blocking").

The purpose of the EOF signal is to allow the logic to send an EOF. In some applications it's desired to tell the host that "the data ends here". If you don't see what it's useful for, you probably don't need it. ;)

Regards,
Eli

Top