Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Why do I need on-chip fifo memory core for buffering?

Status
Not open for further replies.

wannaknow

Junior Member level 2
Joined
Apr 9, 2015
Messages
20
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
252
Hi,

I have an issue where the rate the data is sent to serial port (50Hz) is way faster than the serial port can receive (8Hz).

Basically, what I have is, data is sent from fpga vhdl block to NIos II system, Nios II system sends the data to serial port, Matlab access the serial port to real time plot the graph.

So, I wanted to go for the buffering approach. I am using Quartus 12.1 sp1, vhdl and Nios II programmed in C code for DE0-Nano. In Qsys, I am using a few cores such as timer, sdram, uart, pios etc.

I am totally new to buffering and its hardware interface... I have a few questions:

1. May I know why do I need to use on-chip fifo memory core for this purpose? Can't we just buffer the data in SDRAM? Forgive this newbie question

2.Can we combine both uart ip core with fifo core, or are they to be done separately?

3. I am confused whether I should use an avalon fifoed uart or any fifo will do? I know there is on-chip fifo memory in Qsys, i am using SDRAM in my system


4. I could not find design examples that use fifo, mind to share the link?

Appreciate your time, thank you very much.
 

1) Yes, you could use SDRAM for buffering, but the FIFO is MUCH easier. The FIFO will tell you when it's got data available, when it's empty, when it's full, etc. The SDRAM won't.
2) I don't know about Quartus, but I don't believe you'll find a UART core with built in FIFO, you'll need two separate cores, but it's not really a big deal.
3) It depends on your design; use whatever's easiest. There's no need to complicate things with Avalon if you're not already using it.
4) Really?
 
1) Yes, you could use SDRAM for buffering, but the FIFO is MUCH easier. The FIFO will tell you when it's got data available, when it's empty, when it's full, etc. The SDRAM won't.
2) I don't know about Quartus, but I don't believe you'll find a UART core with built in FIFO, you'll need two separate cores, but it's not really a big deal.
3) It depends on your design; use whatever's easiest. There's no need to complicate things with Avalon if you're not already using it.
4) Really?

The FIFO would be easier from a hardware standpoint if you weren't using a Qsys design, the FIFOs in Qsys as I recall were for streaming Avalon interfaces. Given that you are already using Qsys and a Nios-II running with DRAM you are probably better off having the Nios-II buffer the data in the DRAM.

Though given the lack of requirements supplied that might not be feasible as there may be way too much stuff running on the Nios to handle moving the data into the DRAM and managing the buffer pointers.

If you use the UART core they might (emphasis on might) have some option to increase the buffer size used.

More importantly you do understand that if the 50 Hz transmit is continuous no mater how large you make the buffer you eventually will overflow the buffer and lose data, as 50 Hz is bigger than 8 Hz. Therefore you have to guarantee by design that the 50 Hz side only sends 8 Hz worth of data on average and limits the 50 Hz rate bursts to whatever FIFO/DRAM depth you have available.
 
The FIFO would be easier from a hardware standpoint if you weren't using a Qsys design, the FIFOs in Qsys as I recall were for streaming Avalon interfaces. Given that you are already using Qsys and a Nios-II running with DRAM you are probably better off having the Nios-II buffer the data in the DRAM.

Though given the lack of requirements supplied that might not be feasible as there may be way too much stuff running on the Nios to handle moving the data into the DRAM and managing the buffer pointers.

If you use the UART core they might (emphasis on might) have some option to increase the buffer size used.

More importantly you do understand that if the 50 Hz transmit is continuous no mater how large you make the buffer you eventually will overflow the buffer and lose data, as 50 Hz is bigger than 8 Hz. Therefore you have to guarantee by design that the 50 Hz side only sends 8 Hz worth of data on average and limits the 50 Hz rate bursts to whatever FIFO/DRAM depth you have available.

Thank you for your reply.

Regarding your last paragraph, the rate the data is sent to serial port (50Hz) is way faster than the serial port can receive (8Hz), my question is, how by using say buffering in SDRAM will help in this context? By doing so, I will still be losing some of the cycles? Am I right?

Do you mind to elaborate this statement "you have to guarantee by design that the 50 Hz side only sends 8 Hz worth of data on average and limits the 50 Hz rate bursts to whatever FIFO/DRAM depth you have available."

If I could not limit the 50 Hz side to only send 8 Hz data, eventually I will lose some data.... Forgive me, I don't quite understand what I can do in this aspect...


Thank you in advance.

- - - Updated - - -

1) Yes, you could use SDRAM for buffering, but the FIFO is MUCH easier. The FIFO will tell you when it's got data available, when it's empty, when it's full, etc. The SDRAM won't.
2) I don't know about Quartus, but I don't believe you'll find a UART core with built in FIFO, you'll need two separate cores, but it's not really a big deal.
3) It depends on your design; use whatever's easiest. There's no need to complicate things with Avalon if you're not already using it.
4) Really?

Thank you very much for your reply..
Forgive me for newbie question. What is the difference between "buffering in sdram" and "writing a data to the sdram"?
 

I dont know if this is feasible. What I am tempted to do, since the rate I can plot a graph is slower than the rate the incoming signal is read.

If I know the beginning of every incoming signal let say this point is indicated by a count=0, everytime I detect count=0, I know it is the beginning of each incoming signal, I keep track of how many cycles, let say, I only want to plot the graph every 10 cycles of the incoming signals, I plot cycle no.1, skip 10 cycles, plot cycle no. 11, skip cycle no.12 to 20, next plot cycle no. 21 etc ...in other words, it means I will lose some cycles in between which I am okay with this.

1. Do you think this method make any sense?

2. Do I still need buffering in this case?

3. How do I know how many cycles I need to skip? I assume it would depend on the incoming signal rate (50 Hz) and plot/receive rate (say 8 Hz), But I am not entirely clear about how to calculate...

The incoming signal (50 Hz) is from fpga vhdl, NIos system can read at 50 Mhz, but serial port receive rate or Matlab plot rate is 8 Hz.

Appreciate any input...thank you
 

I dont know if this is feasible. What I am tempted to do, since the rate I can plot a graph is slower than the rate the incoming signal is read.

If I know the beginning of every incoming signal let say this point is indicated by a count=0, everytime I detect count=0, I know it is the beginning of each incoming signal, I keep track of how many cycles, let say, I only want to plot the graph every 10 cycles of the incoming signals, I plot cycle no.1, skip 10 cycles, plot cycle no. 11, skip cycle no.12 to 20, next plot cycle no. 21 etc ...in other words, it means I will lose some cycles in between which I am okay with this.

1. Do you think this method make any sense?

2. Do I still need buffering in this case?

3. How do I know how many cycles I need to skip? I assume it would depend on the incoming signal rate (50 Hz) and plot/receive rate (say 8 Hz), But I am not entirely clear about how to calculate...

The incoming signal (50 Hz) is from fpga vhdl, NIos system can read at 50 Mhz, but serial port receive rate or Matlab plot rate is 8 Hz.

Appreciate any input...thank you

Then you have a real time requirement, so...
a) speed up the graphing
b) slow down the data acquisition
c) decimated the data before sending

or do all of the above. Your description seems to be about doing c.


Your educational institution must not believe in assigning a the "Fill-Drain a Tank" type word problem to their students. That is the typical introduction to queuing (buffering) that you'll see.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top