Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
On 04/12/2010 05:22 PM, Vikram Ragukumar wrote: Matt, In our effort to distill the gemac core and related logic, we have pulled out the following module under u2_core SERDES, Dsp core, UART, external RAM interface and the buffer pool The mac is all contained in simple_gemac, and above that in simple_gemac_wrapper: which is instantiated in u2_core. Most of the buffering happens in simple_gemac_wrapper in the fifo_2clock_cascade files. (a) Is any buffering for the gemac done using buffers in the buffer pool or is it ok to eliminate that module all together ? Yes, it does buffering. You can get rid of it, but then you'll need to create a module which holds the FIFO contents until there is a complete packet. Otherwise, the ethernet will start sending the packet before you have a complete packet there. (b) The synthesis report currently shows that 24 BRAM's are being used by the design. Does this sound about right ? Are there modules unrelated to gemac or aeMB that we can pull out, to reduce BRAM usage ? You're going to need to do your own exploration. ISE has a feature to tell you which modules are using block rams. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
Matt, In our effort to distill the gemac core and related logic, we have pulled out the following module under u2_core SERDES, Dsp core, UART, external RAM interface and the buffer pool The mac is all contained in simple_gemac, and above that in simple_gemac_wrapper: which is instantiated in u2_core. Most of the buffering happens in simple_gemac_wrapper in the fifo_2clock_cascade files. (a) Is any buffering for the gemac done using buffers in the buffer pool or is it ok to eliminate that module all together ? (b) The synthesis report currently shows that 24 BRAM's are being used by the design. Does this sound about right ? Are there modules unrelated to gemac or aeMB that we can pull out, to reduce BRAM usage ? Thanks and Regards, Vikram. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
My understanding is that it takes 3 BUFGs and one DCM for tri-mode (maybe one more of each for RGMII support but I don't see that) and, between this and other USRP2 needs, you ran into the limit of 8. Is that accurate? Or would 10/100/1000 support would take more than 3... I can't say how many clocks a _good_ 10/100/1G system would need, but the Opencore required 4. One thing to keep in mind is that while there are theoretically 8 global clocks in the S3, other limitations mean that it can be difficult to use all 8. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
Matt- My understanding is that it takes 3 BUFGs and one DCM for tri-mode (maybe one more of each for RGMII support but I don't see that) and, between this and other USRP2 needs, you ran into the limit of 8. Is that accurate? Or would 10/100/1000 support would take more than 3... I can't say how many clocks a _good_ 10/100/1G system would need, but the Opencore required 4. One thing to keep in mind is that while there are theoretically 8 global clocks in the S3, other limitations mean that it can be difficult to use all 8. Ok thanks Matt. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
Matt, 3) Do you have an FPGA internal achitecture block diagram of any type? Is there another group you're aware of doing such major modification FPGA work that we might talk to? There were some on the wiki at one time. If they're not still there I'll post a talk I did which covers the architecture. I have looked at the wiki (http://gnuradio.org/redmine/wiki/gnuradio), however i was not able to find any block diagrams for the internal architecture of the FPGA for USRP2. I still might not be look in the correct place. Could you please point me in the right direction ? It would be nice if you could post the presentation that you made, that covered the architecture. Thanks and Regards, Vikram. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
On 04/07/2010 05:58 PM, Vikram Ragukumar wrote: Matt, Thank you for your email. The mac is all contained in simple_gemac, and above that in simple_gemac_wrapper: http://code.ettus.com/redmine/ettus/projects/fpga/repository/revisions/master/show/usrp2/simple_gemac simple_gemac_wrapper in the fifo_2clock_cascade files. which is instantiated in u2_core. Most of the buffering happens in I would just start with the u2_core and simple_gemac_wrapper. If you're not using the SERDES, that is a good place to start ripping out. Does this imply that we can pull out the aeMB core, the 32K RAM and the buffer pool under module u2_core ? You can pull out whatever you want. Start from scratch if you like. But if you take out the processor, you'll need to find some other way to get the peripherals (DAC, clock gen, lsdac, etc.) programmed. To carry out preliminary testing we need to be able to pass data to the gemac and configure appropriate control registers. Could you please suggest what existing modules we could reuse to send data to the gemac ? You're going to need to look at the code. The processor does all that now. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
Matt- About Vikram's 10/100 mode question, we were wondering if it's a design flaw; i.e. something wrong from the start in the original opencores.org source, or if it's fixable but hasn't been a high priority item given USRP2's high data rate requirements. But then I found this post: http://www.ruby-forum.com/topic/143084 So I guess the former. If there are any hints you can give on what's wrong, we can take a look. Maybe our guys can get it working. Eventually I got completely fed up with the opencores gige core and wrote a completely new one from scratch (the simple_gemac). It only does gigabit, though. Ok. One of the main problems with 10/100/1000 in a spartan is that you need a large number of clocks and the S3 is constrained. My understanding is that it takes 3 BUFGs and one DCM for tri-mode (maybe one more of each for RGMII support but I don't see that) and, between this and other USRP2 needs, you ran into the limit of 8. Is that accurate? Or would 10/100/1000 support would take more than 3... If you just want 10/100 and can live without gigabit, I would suggest doing that, as it will save 1 or 2 clocks. Ok... maybe we can implement both modes if we're careful. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
Matt, Thank you for your email. The mac is all contained in simple_gemac, and above that in simple_gemac_wrapper: http://code.ettus.com/redmine/ettus/projects/fpga/repository/revisions/master/show/usrp2/simple_gemac simple_gemac_wrapper in the fifo_2clock_cascade files. which is instantiated in u2_core. Most of the buffering happens in I would just start with the u2_core and simple_gemac_wrapper. If you're not using the SERDES, that is a good place to start ripping out. Does this imply that we can pull out the aeMB core, the 32K RAM and the buffer pool under module u2_core ? To carry out preliminary testing we need to be able to pass data to the gemac and configure appropriate control registers. Could you please suggest what existing modules we could reuse to send data to the gemac ? 3) Do you have an FPGA internal achitecture block diagram of any type? Is there another group you're aware of doing such major modification FPGA work that we might talk to? There were some on the wiki at one time. If they're not still there I'll post a talk I did which covers the architecture. I have looked at the wiki (http://gnuradio.org/redmine/wiki/gnuradio), however i was not able to find any block diagrams for the internal architecture of the FPGA for USRP2. I still might not be look at the right place. Could you please point me in the right direction ? From forum discussions over the past couple of months it appears that USRP2 does not support the 10/100 mode. Could you please help us understand the work effort involved in getting the 10/100 mode working ? Thanks and Regards, Vikram. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
Matt- About Vikram's 10/100 mode question, we were wondering if it's a design flaw; i.e. something wrong from the start in the original opencores.org source, or if it's fixable but hasn't been a high priority item given USRP2's high data rate requirements. But then I found this post: http://www.ruby-forum.com/topic/143084 So I guess the former. If there are any hints you can give on what's wrong, we can take a look. Maybe our guys can get it working. -Jeff Thank you for your email. The mac is all contained in simple_gemac, and above that in simple_gemac_wrapper: http://code.ettus.com/redmine/ettus/projects/fpga/repository/revisions/master/show/usrp2/simple_gemac simple_gemac_wrapper in the fifo_2clock_cascade files. which is instantiated in u2_core. Most of the buffering happens in I would just start with the u2_core and simple_gemac_wrapper. If you're not using the SERDES, that is a good place to start ripping out. Does this imply that we can pull out the aeMB core, the 32K RAM and the buffer pool under module u2_core ? To carry out preliminary testing we need to be able to pass data to the gemac and configure appropriate control registers. Could you please suggest what existing modules we could reuse to send data to the gemac ? 3) Do you have an FPGA internal achitecture block diagram of any type? Is there another group you're aware of doing such major modification FPGA work that we might talk to? There were some on the wiki at one time. If they're not still there I'll post a talk I did which covers the architecture. I have looked at the wiki (http://gnuradio.org/redmine/wiki/gnuradio), however i was not able to find any block diagrams for the internal architecture of the FPGA for USRP2. I still might not be look at the right place. Could you please point me in the right direction ? From forum discussions over the past couple of months it appears that USRP2 does not support the 10/100 mode. Could you please help us understand the work effort involved in getting the 10/100 mode working ? Thanks and Regards, Vikram. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
