Xillybus core customization for fft spectrometer application

[mugundhan]

Hello Eli,

I was able to implement successfully the xillydemo on my xupv5lx110t board. I was able to do loop back tests on my host computer. Just correct me if I'm wrong,
when we do the cat > /dev/xillybus_write_8 and cat /dev/xillybus_read_8 functions in the terminal, the 8 bit fifo's srst is deasserted and when data is typed into the pipe of write_8, the core (probably) holds the wr_en of the FIFO high for (length of data)/8 clocks and the data is written to the fifo. The rd_en is high since we opened the read pipe, thus enabling the loopback, after all the data is read, the empty is high and the core waits for this to go low again for taking data from the fifo.

Is this description right?

the use of eof is not still clear to me. but I'll try reading more on it from the fpga designer's guide

Thank you,

[support]

Hello,

Yes, the FIFO's srst signal is deasserted after the first "cat" operations is invoked (because one of user_w_write_8_open or user_r_read_8_open goes high).

And your description is indeed otherwise correct, even though it's not clear how you counted the clocks wr_en is asserted. What happens is that it's asserted one clock for each byte transmitted.

As for the EOF: If you don't have any need for the reading thread on the host to receive an end-of-file, just keep it deasserted.

Regards,
Eli

[mugundhan]

Hello,

I counted the clocks like, say, I type *HELLO*, the length of this is 40 bits or 5 bytes, so the wr_en has to be held high for 5 clock cycles to get this into the device pipe.

Thanks,

Mugundhan

[mugundhan]

One more question: Since the file pipes that appear in my /dev locations are actually the FIFOs in the fpga, and after the firmware reads out the contents of the FPGA, the empty will go 1, so anyway the core will not try to read from that FIFO no ? Then why the end of file signal ?

Thank you,

Mugundhan

[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

[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 !

[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

[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 !

[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

[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