- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello
How do i increase the receive buffer size.... till now i have done following... 1. increase the receive Depth of TSE Mac... 2. Increase the MAXBIGPKTS from 30 to 512 in "ipport.h" 3. Increase the NUMBIGBUFS in "ipport.h" from 30 to 512 4. putting .heap and .stack in different memory region but till now there is no success. i have a image server who sends 512 UDP packet of size 512....on another end nios based receiver is running his job is to collect all these UDP packet in either internal or external memory...and send serieally to other cyclone device for further processing... currently i am able to receive 4 UDP packets of size 512...not more then that.. regards kaushal- Tags:
- Define
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you use the "reassign base address" option afterwards? It should move all your components addresses again, and hopefully solve the overlap problems.
I see you have an Avalon Clock crossing bridge too, try to lock it to address 0 too if you still have problems. I think it is the one responsible for the last error (ddr2_bot.s1 appears at more than one address). Also check that you don't have any component with an Avalon Slave interface that is connected to both sides of a pipeline bridge. This could confuse SOPC builder.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanking you for your prompt reply,
yes, i have assign the base address option afterword, I am using Quartus 11.0 SP1, it has assign base address, rather then reassign base address (see windscreen), i hop both things are same. what is the role of descriptor memory in this case, i connect it's read and write port to SGDMA descriptor read and write port. With Regards kaushal- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes that's the right name. Sorry about that.
Ensure that your components are only connected behind the pipeline/clock crossing bridges. If as an example you have: CUP Data master > pb_cpu_to_flash > flash, then you shouldn't have any direct connection between the CPU Data master and the flash. They should only be connected through the bridges. The assign base address should really solve your problem, it just needs to move the ddr or the flash to prevent overlapping...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The descritor memory holds some parameters for the SGDMA, such as start address for a transfer, number of bytes, etc... They should be connected to the SGDMA descriptors read/write masters, and the CPU data master.
I think you need to declare the descriptors addresses somewhere in ipport.h too.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello There,
After following all the instruction/suggestion given by forum peoples my sopc wont be an error free it always says some connection error, some address overlapping error etc. i am attaching the entire project please suggest/comment what went wrong in my sopc file, i am trying to add on-chip memory (packet memory) to hold the UDP packet (512 packet of size 512 )coming from remote terminal at a very high speed. i have add a On-Chip Memory (Packet memory duel port), and it's S1 port connected to SGDMA read and write, S2 port connected to CPU tightly coupled Data master (no other connection on these two port S1 and S2). connect the descriptive memory to descriptive read and write port of SGDMA. made the base address of pipeline and clock crossing bridge is to zero., i have also ensure that CPU Data master connected only pb_cpu_to_flash and flash and no other direct connection between CPU data master and flash With regards kaushal- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Daixiewn,
yes i ensure that my components are only connected behind the pipeline/clock crossing bridges. the way you says in your post, CUP Data master > pb_cpu_to_flash > flash, then there is no direct connection between the CPU Data master and the flash. They should only be connected through the bridges. i have reassign base address too but it won't able to solve problem. Regards kaushal- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It seems that SOPC Builder isn't able to map the peripherals in your system when forcing the bridges to address 0 to prevent an address shift. It is strange, in my experience this always worked...
I tried a different strategy. I unlocked all the bridge addresses, and saw after the base address assignment that there are two block that use two addresses: ddr2_bot and descriptor_memory. I collapse all the components (View menu) to have a better overview. Upon a first look I saw that you had some pipelines that weren't very useful. If you use a clock crossing bridge you don't really need to combine it with a pipeline bridge. So I removed pb_dma_to_ddr2, pb_cpu_to_io and pb_cpu_to_flash. Then I reran an assign base address. Then I right click on ddr2_bot, go to connections > s1 and see that it is connected to pb_cpu_to_ddr2_bot and ccb_dma_to_ddr2. Since locking those two bridges to 0 didn't work I tried to do the contrary. I locked the pipeline bridge from the cpu to its current address (0x08000000) and modified and locked the address on the other pipeline bridge to match. Then I did the same thing with the descriptor memory. I locked the ccb_cpu_to_io address to 0x10000000 and modified and locked the pb_dma_to_descriptor_ram to the same address.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You are welcome :) It's the first time I see SOPC builder having such a hard time automatically assigning addresses to components, I don't know exactly why...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have done the following steps to add the On-Chip memory to receive the incoming UDP packet.
1. Add an On Chip Memory (6553) through SOPC builder. 2. Generate the System 3. Compile the Nios-II Processor 4. Do the Desire Changes in IPPORT.H file (please see the attached ALTERA_PKT_MEM file this is the desire section of ipport.h file). This changes is as par readme file from the Ethernet_Accel_Design.Zip (Title: enabling the fast packet memory optimization) 5. After that I run the code on nios processor: and resultant nothing happen I mean TSE_MAC not initialize etc totally blank console. Otherwise it shows the initilize the tse_mac, outo_negtation, then simple_socket starting up, ip address is 192.168.1.205 etc 6. Is my SOPC connection of descriptor memory is properly connected or something missing…? 7. Do I add something in Nios BSP editor as this packet memory visible in BSP Editor?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A Quick Update: what is different between ncpballoc and ncpalloc, as ALTERA_PKT_MEM required ncpballoc, so each time i add these changes in ipport.h it generate the attached error's
1. it says undeclared TRUE and FALSE then take out the TRUE and FALSE statement outside the loop, this error disappear (attached print-screen: error.jpg) 2. it says ncpballoc undefined refrence then i defined this in ipport.h just below # define ALTERA_TRIPLE_SPEED_MAC, char *ncpballoc(unsigned size); void ncpbfree(* ptr); attached print-screen error3.jpg and ncpballoc_error.jpg regards kaushal- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- #define ALTERA_PKT_MEM 1 # define ALTERA_PKT_MEM PACKET_MEM_BASE # define ALTERA_PKT_MEM PACKET_MEM_SPAN --- Quote End --- Those should be 3 different defines, the word document shows: --- Quote Start --- #define ALTERA_MRAM_FOR_PACKETS 1 # define ALTERA_MRAM_ALLOC_BASE PACKET_MEM_BASE # define ALTERA_MRAM_ALLOC_SPAN PACKET_MEM_SPAN --- Quote End --- In your code you are redefining 3 times the same symbol. You also have to add the optimizations.c file from the Ethernet Accel Design example to your own project, so that it can find references to the ncpballoc functions. I don't see any connection to the descriptors memory on your SOPC screenshot.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hello
Daixiwen please see the attached print screen for descriptor memory decriptor_mem.jpg. i have correct the ipport.h and add the optimization.c file to my project and compile the project in Nios II-Eclips initially my configuration is: packet memory size is 65536 (packet_mem_High.jpeg) and Tse mac fifo depths 2048x32 (packet_mem_High.jpeg & Project_Info.jpeg) i have got the error saying :: panic: out of mem then i reduce the TSE_MAC FIFO Depth (2048x32 to 512x32) and keeping Packet memory size fix (65536) (plz see tse_512x32_on_chip_32768.jpeg) again i got the same error "panic: out of mem", then reduce the Packet memory from 65536 to 32768 (plz see attached on_chip_mem_32768.jpeg) and again i got the same error "panic: out of mem". shouild i further reduce the packet memory size, i have Altera Embedded Development Board having Cyclone-III Device. earlier when i do not using packet memory, i put TSE_MAC FIFO Depth to its maximum level (There is slider button on tse_mac) at that time i am not facing any such errors. and able to receive 450 UDP packet of Size 512. Regards kaushal- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can leave the fifo length to its maximum value, this memory is made with the FPGA's M9X blocks and isn't seen by the software.
The cause of this panic is that the TCP/IP stack doesn't have enough space in your packet memory to allocate all its buffers. Reducing the packet memory size actually made things worse. You should put back the packet memory to 64k in SOPC builder and modify ipport.h to ask the stack to allocate less buffers, so that it sticks in your packet memory. If you have a look at your word document, it is described in step 3. The total number of bytes allocated by the stack is NUMBIGBUFS*BIGBUFSIZE+LILBUFSIZE*NUMLILBUFS, and this number must be less than the size of your packet memory. As you can't reduce BIGBUFSIZE the best option is to reduce the number of buffers, NUMBIGBUFS and NUMLILBUFS.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oh and I forgot... don't forget to make a backup copy of your modified ipport.h, because this file is erased each time you clean your project, and replaced each time you change something to the bsp/software library configuration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello there,
I have make FIFO to its maximum value and that is 65536 x 32 Bits (Attached Print screen of TSE FIFO). And On chip memory is 65535 x 32. I don’t have any idea what become the descriptor memory size? i have made following changes in ipport.h #define NUMBIGBUFS 512 #define NUMLILBUFS 1 /* some maximum packet buffer numbers */ #define MAXBIGPKTS 512 #define MAXLILPKTS 1 #define MAXPACKETS (MAXLILPKTS+MAXBIGPKTS) #define BIGBUFSIZE 512*200 #define LILBUFSIZE 1//128 Which satisified the equation NUMBIGBUFS*BIGBUFSIZE+LILBUFSIZE*NUMLILBUFS = Size is equal oa less then packet memory that mean That is 512*512*200+1*1 = 52,428,800 Or 52,428,800/1024 = 51,200 <65535 (packet mmory) and still i got the same error saying "panic: out of mem" regards kaushal- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't understand your calculation. The total calculated sive is 52MBytes, which is too much by far... why do you divide by 1024?
The idea behind those buffers is to being able to store as many packets as possible in memory and waste as little as possible. The main idea is that there are usually two cases: small packets (such as DHCP request/answers, ICMP, TCP connection requests or acknowledges) and big packets that contain data. Big packets are limited to the maximum you can send through Ethernet, which is 1536 bytes. For the small packets 128 is a good limit. You shouldn't change those two values, except if you have a good reason to think it will optimize memory usage in your specific application. You should rather change the number of packet buffers to fill the packet memory. Using NUMBIGBUFS and NUMLILBUF at 30 with BIGBUFSIZE at 1536 and LILBUFSIZE at 128 should fit in a 65536 bytes packet memory. As for the descriptors I don't remember how the driver uses them. 1k is more than enough, but you need to check in the driver code how it allocates the descriptors and see if you need to change anything to use your dedicated memories. It may be easier to forget about descriptor memory for now, connect the dma descriptor masters to the main memory and let the driver as it is.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello There,
You are right, I though these values is in bits’ but these values is in bytes. Anyway as you suggest, i have given NUMBIGBUFS = 30, MAXBIGPKT = 30 and BIGBUFSIZE = 1536, though there is no error (like in previous case: "panic: out of mem"), but during receiving (run time) the packet it again says [tse_sgdma_read_init] fatal error: no free buffer for RX Init error -21 on net[0] (Please see the print-screen forthis error). This BIGBUFSIZE which we are making 1536 is the place where all the receive packet stays or this is the maximum size of packet received FROM REMOTE MACHINE? In my specific application i have maximum UDP packet size is 512 bytes, so shouild i make this BIGBUFSIZE is 512? And as i am aspecting 512 (in number) UDP packets from remote machine so could i make my MAXBIGPKTS = 512. But if i do so, it not satisfied the condation numbigbufs*bigbufsize+lilbufsize*numlilbufs <=packet memory size (which is 65536 or 64kb) And again says "panic: out of mem" *what is the maximum value that i can assign to on-chip-memory (packet memory), is it 64k or 512k or something else? Please comment on this Regards Kaushal- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What you could do is indeed to increase NUMBIGBUFS to 512, and re-use the main memory instead of the on-chip RAM. It will be slower but it might be able to store all your UDP packets.
The maximum size of the on-chip memory depends on the FPGA that you have. An EP3C120 has about 300kbytes on integrated RAM, but some of it is also used by the CPU's caches, and the TSE FIFOs.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
is there no way u can restrict what is being sent or reduce the speed it comes at?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Warlax,
Actually remote Ethernet Camera is from Some Other vendor, i just request him to slow down just for testing purpose not for specific application. and i have already done this excerise (slow down the UDP packet speed) in this way i have receive all the packets and there is no issue at all. kaushal- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page