You are not logged in.
I generated bitstream for COGMAC server.c & cogmac server.h. This bitstream is downloaded to first warp node.
Again, I generated bitstream for COGMAC client.c & cogmac client.h and this bitstream is downloaded to second warp node.
When i send video from the first warp node, second warp node is not receiving the video.
(Wire shark is showing that first warp node is sending packets . But, wireshark in the second warp node is not showing the reception of packets.)
Also, i set the warp node 1 is as : 0 and IP address as : 10.0.0.20
Warp node 2 Id as : 2 and IP address of the warp node 2 as : 10.0.0.2.
Please help me how i can make the warp node 2 to receive the video sent from warp node 1?
--venkat
Last edited by venkat (2012-Jul-19 06:47:59)
Offline
Same above problem is coming to me also. So, i thought, if Half_mac works, automatically, cog Mac works since both are very much similar.
Sir, One doubt. Please clarify this : What is the difference between halfMac_client_SW.c and halfMac_client_HW.c ? Which one should i use for updating bitstream in Half Mac?
Also, should i update the bitstream with the source files " halfmac_server.c & halfMac_client.c " taken combinedly ? or
Should i update the bitstream separately for HalfMac_server and HalfMacClient separately?
Please reply.
Thank you very much. -- Kalpana
Last edited by kalpana (2012-Jul-19 06:45:21)
Offline
Either the SW or HW variants should be fine. The difference is the use of the autoresponders in the FPGA fabric to generate ACK packets (HW) vs. the creation of those packets in the PPC (SW).
The server and client projects are completely independent. You'll need to generate a server bitstream for one board and a client bitstream for another.
COGMAC and HALFMAC aren't "supported" MACs. We created them by spinning off from the CSMAMAC reference design that existed around the last time of the last workshop we taught. I'd suggest making sure that CSMAMAC and NOMAC from a current up-to-date reference design work for you before trying to debug the workshop MACs.
Offline
Thank you very much for responding. I tried NOMAC and CSMA MAC. They are working fine. Now, i am trying with Half-Mac. I will see if it works or not.
One more doubt. To be able to generate executable.elf file, i have changed the stack size to 0X200 and heap size to 0x200 in the linker script.
after that i have generated bitstream. Bitstream was generated nicely.
My doubt is : does " changing the stack and heap sizes from 0x400 to 0x200 " affect any thing ? please tell me.
Thank you once again for responding. --Kalpana
Last edited by kalpana (2012-Jul-20 01:57:49)
Offline
Honestly, I've never had a very good intuition on what the heap and stack sizes should be. The code doesn't have any interrupts, so it's not like there can potentially be an arbitrarily long chain of context switches that each need to push stuff on the stack. So basically, there is some threshold above which things work well and below which things fail. I don't know the numbers off hand, but I believe the OFDM reference design has lots of BRAM left so you can overprovision the heap and stack just to be safe.
Regarding your specific question, are you saying that the reference design works with 0x200 but not with 0x400? That shouldn't be the case. Does the code actually generate into a bitstream at 0x400 or does it throw an error that the code size is too big for the BRAM its assigned to?
Offline
When executable.elf file was not created because of BRAM problems, i went to the "custom link" to change the stack and heap sizes. Then executable.elf file was created properly and i could generate bitstream. Thinking that if i could reduce stack and heap sizes, then there will be more memory left for the program.
Thank you for your reply. -- Kalpana
Offline