Continue to Site

Welcome to

Welcome to our site! 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.

Data Traffic management in FPGA

Not open for further replies.


Newbie level 1
Jun 27, 2011
Reaction score
Trophy points
Activity points
I have 64 channels through which I expect (for the worst case) 24000 bits per second from each channel. The occurrence of data is random at any channel. I am sending the data through TCP/IP to a computer where it will be logged. Data loss is not accepted. What method should I follow? I am thinking of having stack mem. for each channel and consequently putting it over the TCP-IP but I fear that the total stack memory might be too large. Any suggestions?

This is what I understood from your description.please clarify.
You have 64 channels input to your design, from which you recieve data. This data should be send to a computer via TCP/IP. since you dont know when the data will come you want to store the data somewhere until its put in a tcp/ip packet and send over network??

What is your output data rate?
Are going to do the tcp/ip code yourself?

24000 = 0.024Mbps
64*0.024 = 1.536Mbps
for storage, 1.536E6 bps = 0.1831MB/s (1MB = 2^20, 1B = 8b)
16MB (SRAM) = 87.38s @ max rate.
256MB (DRAM)= 23min @ max rate
16GB (SDHC-Card, SPI)= 24.8 hours @ max rate
1TB (SATA) = ~2 months

you really shouldn't ever need to drop data. in the absolute worst case, you would have a little over 1 day to retransmit any missing data. basically, that allows the other side to lose the connection for about a day. With a HDD, the device can remain unconnected for up to two months and still not drop data.

for obvious reasons, this is something that would work well with a microcontroller or embedded micro. the low data rates and relatively complex logic requirements of TCP/IP make it a good choice.

Not open for further replies.

Part and Inventory Search

Welcome to