Hi Ian,Marcus The strobe signal in dsp_tx_glue is the back pressure signal. When this signal goes high 32 bits of data is read from vita_tx_chain.This strobe signal is actually depends on the rate we set in the terminal. I want to control the strobe signal that goes duc_chain to vita_tx_chain . Actually i need to read 4 bytes of data from vita_tx_chain after every 128 duc_in_strobe pulses.I do this because my module in dsp_tx_glue generates 128 samples from each 4 bytes of data read from vita_tx_chain. So my new strobe is high in every 128th duc_in_strobe but this arrangement works for only a few reads , after which the enable signal og dsp_tx_glue goes low.If I increase the delay between two file read, it does few more reads. Is this because the fifo's are overflowing? Can I achive my purpose in a different way? Can I keep the rate in duc_chain to what we set from terminal but read from vita_tx_chain 128 times slower so that my module in between takes care of the . Thanks Bhaskar

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bhaskar, though I'm certainly not the FPGA expert here, I'll try to get a clear understanding of what's going on ;) So: On 25.01.2014 15:28, BHASKAR BANERJEE wrote: I guess you're referring to fpga/usrp2/sdr_lib/dsp_tx_glue.v, signal name duc_in_strobe, right? I think that should be identical to the baseband strobe, bb_strobe, but I can't confirm that. I think that is a bit beyond my understanding of the FPGA architecture, but I do believe you :) So we're talking about signals connected in top/USRP2/u2_core.v, wherein we're considering the wire tx_strobe? Hm, this sounds nontrivial to say, can you figure out who disables duc_in_enable (am I on the right path?)? Anyway, if you're changes are not to sensitive, would you mind creating a github repo (or the like) with a branch containing the changes you've made, so that people might have a look at it? Um, of what? Actually, I'm not quite sure if vita_tx_chain is not sensitive to getting data; from your problem I guess it would be wiser to just keep the functionality as it is, and "just" add another module triggered by the same strobe that usually goes to vita_tx_chain, and taps into the same signals that you want to read, but only "forwards" them every 128th time, if this is the functionality you're looking for and timing allows it. But then again, I'm not an experienced HDL developer nor too familiar with the functionality of vita_tx*. Hope I could help you the least, Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS5kV2AAoJEAFxB7BbsDrLieEIAIs+AYNBrfU6Ayp5gtmkriDJ eNL5Sja6dfKbLaJpFD1XGV47mVn95obREjLr0vWV5wi6YXrqbJBcHukl+4wLoAQO f0ICuxIIWNe+MiYNhapOqUwu/aaWHW81tNgWDEcyEPwV+Mo/1IZXe2hpSa1fqw+e WDk5oOehlMqMHptmACoq1fXZMbN5mMWxSqV7NJknPPhRJgAKUctwLD6e+EW0GzBQ /pKZ/3tHSvju7AN4k7zvwJBDzDfW06wuLTuQbSRcb/9XTY3gwHhPGTr2WFzSTnBH 9TrOCWYbTnND0boG4GZYtxmzVw6pbLuAAe20RXUSl76A+NuKP0xGJGtqdwMSQqM= =hKzz -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, somehow your questions were magically edited out of my reply. So here I go, trying it anew: On 25.01.2014 15:28, BHASKAR BANERJEE wrote: > The strobe signal in dsp_tx_glue is the back pressure signal. I guess you're referring to fpga/usrp2/sdr_lib/dsp_tx_glue.v, signal name duc_in_strobe, right? I think that should be identical to the baseband strobe, bb_strobe, but I can't confirm that. > When this signal goes high 32 bits of data is read from > vita_tx_chain.This strobe signal is actually depends on the rate we > set in the terminal. I think that is a bit beyond my understanding of the FPGA architecture, but I do believe you. > I want to control the strobe signal that goes duc_chain to > vita_tx_chain . So we're talking about signals connected in top/USRP2/u2_core.v, wherein we're considering the wire tx_strobe? > Actually i need to read 4 bytes of data from vita_tx_chain after > every 128 duc_in_strobe pulses. I do this because my module in > dsp_tx_glue generates 128 samples from each 4 bytes of data read > from vita_tx_chain. So my new strobe is high in every 128th > duc_in_strobe but this arrangement works for only a few reads , > after which the enable signal og dsp_tx_glue goes low. If I > increase the delay between two file read, it does few more reads. Is this because the fifo's are overflowing? Hm, this sounds nontrivial to say, can you figure out who disables duc_in_enable (am I on the right path?)? Anyway, if you're changes are not to sensitive, would you mind creating a github repo (or the like) with a branch containing the changes you've made, so that people might have a look at it? > Can I achive my purpose in a different way? Can I keep the rate in > duc_chain to what we set from terminal but read from vita_tx_chain > 128 times slower so that my module in between takes care of the . Um, of what? Actually, I'm not quite sure if vita_tx_chain is not sensitive to getting data; from your problem I guess it would be wiser to just keep the functionality as it is, and "just" add another module triggered by the same strobe that usually goes to vita_tx_chain, and taps into the same signals that you want to read, but only "forwards" them every 128th time, if this is the functionality you're looking for and timing allows it. But then again, I'm not an experienced HDL developer nor too familiar with the functionality of vita_tx*. Hope I could help you the least, Marcus On 27.01.2014 12:39, Marcus Müller wrote: > Hi Bhaskar, > > though I'm certainly not the FPGA expert here, I'll try to get a > clear understanding of what's going on ;) So: > > On 25.01.2014 15:28, BHASKAR BANERJEE wrote: > > I guess you're referring to fpga/usrp2/sdr_lib/dsp_tx_glue.v, > signal name duc_in_strobe, right? I think that should be identical > to the baseband strobe, bb_strobe, but I can't confirm that. > > I think that is a bit beyond my understanding of the FPGA > architecture, but I do believe you :) > > So we're talking about signals connected in top/USRP2/u2_core.v, > wherein we're considering the wire tx_strobe? > > Hm, this sounds nontrivial to say, can you figure out who disables > duc_in_enable (am I on the right path?)? Anyway, if you're changes > are not to sensitive, would you mind creating a github repo (or the > like) with a branch containing the changes you've made, so that > people might have a look at it? > > Um, of what? Actually, I'm not quite sure if vita_tx_chain is not > sensitive to getting data; from your problem I guess it would be > wiser to just keep the functionality as it is, and "just" add > another module triggered by the same strobe that usually goes to > vita_tx_chain, and taps into the same signals that you want to > read, but only "forwards" them every 128th time, if this is the > functionality you're looking for and timing allows it. But then > again, I'm not an experienced HDL developer nor too familiar with > the functionality of vita_tx*. > > Hope I could help you the least, Marcus > > _______________________________________________ USRP-users mailing > list USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS5p8iAAoJEAFxB7BbsDrLE8MH+wdGZWSxO/QTPrt0AWSErxAY DkBYs7w2DZHkCdsMM63rVekLSsJG/9EnlELbrsXF7pqHQxiT+kuA7P0OjXAUwe+p FBDLvGqkFXaW2ghmnxMwI1ouZ9B6uj2adufnszzIwqj17b2sc+JvP0HMHrbCGoFn 5Oje5dHBmaDWCF5DddEqopMfTqqOCKQEAECcxtjRBP/oFLGdpwA0Ad6oKyiYZgHt LK+W7t3arrc6Lya469ADr/oySX6OimWlf2nWigL09EFswlcqHBgUtnSPkt2v7Dia UqZdbUfKAMX4KYjnlN+iGmNZO3TMciMxwmhelBrHOYdqgXUv5d6IRcj5IzTXNeE= =kuO8 -----END PGP SIGNATURE-----

Hi Marcus Thanks for the reply . Actually this is very important for me . I really appreciate your help. The Baseband strobe is identical to duc_in_strobe (In dsp_tx_glue ,it is just a pass through) .This signal is input to vita_tx_chain. Only when the strobe is high a 32 sample is read from vita_tx_chain. The duc_in-strobe is dependent on the rate that we set in the command prompt (eg tx_samples_from_file --file input.bin --type short --gain 0 --freq 474000000 -- rate 10000000 --repeat , in this case duc_in_strobe is high after every 10 cycles and if --rate 5000000 then duc_in_strobe is high every 20 cycles). I traced the enable signal which is going low after a few reads. This signal is run in vita_tx_chain. Run signal goes low when clear is high. Clear signal comes from a settings_reg . This settings_reg gives out a flush and a clear signal depending upon set_data, set_address and set stb. I found that when set_stb is high and set_addr == address (parameter inside setting_reg) then clear goes high. this set_addr is a part of sfc_rd signal in packet router.This sfc_rd signal contains some information from the ethernet packet. Can you tell me what is the purpose of this clear signal? and If the data transfer between computer and Ethernet is also dependent on the rate that I set in the command prompt. If I make the clear and flush signal 1'b0 then the error goes away (atleast for the number of samples visible in the buffer window) but I am not sure if it hamper the overall working of USRP. I am attaching a .rar file which conatains the snapshots of the changes and the changed dsp_tx_glues.v file.In this .rar file you will find that I am making duc_in_strobe high after every 32 nd cycle rather than 128 (just for testing purpose). Please have a look. Thanks Bhaskar On Mon, Jan 27, 2014 at 11:32 PM, Marcus Müller <marcus@hostalia.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sorry, somehow your questions were magically edited out of my reply. > So here I go, trying it anew: > > On 25.01.2014 15:28, BHASKAR BANERJEE wrote: > > The strobe signal in dsp_tx_glue is the back pressure signal. > > I guess you're referring to fpga/usrp2/sdr_lib/dsp_tx_glue.v, signal > name duc_in_strobe, right? I think that should be identical to the > baseband strobe, bb_strobe, but I can't confirm that. > > > When this signal goes high 32 bits of data is read from > > vita_tx_chain.This strobe signal is actually depends on the rate we > > set in the terminal. > > I think that is a bit beyond my understanding of the FPGA > architecture, but I do believe you. > > > I want to control the strobe signal that goes duc_chain to > > vita_tx_chain . > So we're talking about signals connected in top/USRP2/u2_core.v, > wherein we're considering the wire tx_strobe? > > > Actually i need to read 4 bytes of data from vita_tx_chain after > > every 128 duc_in_strobe pulses. I do this because my module in > > dsp_tx_glue generates 128 samples from each 4 bytes of data read > > from vita_tx_chain. So my new strobe is high in every 128th > > duc_in_strobe but this arrangement works for only a few reads , > > after which the enable signal og dsp_tx_glue goes low. If I > > increase the delay between two file read, it does few more reads. > > Is this because the fifo's are overflowing? > Hm, this sounds nontrivial to say, can you figure out who disables > duc_in_enable (am I on the right path?)? > Anyway, if you're changes are not to sensitive, would you mind > creating a github repo (or the like) with a branch containing the > changes you've made, so that people might have a look at it? > > > Can I achive my purpose in a different way? Can I keep the rate in > > duc_chain to what we set from terminal but read from vita_tx_chain > > 128 times slower so that my module in between takes care of the . > > > Um, of what? Actually, I'm not quite sure if vita_tx_chain is not > sensitive to getting data; from your problem I guess it would be wiser > to just keep the functionality as it is, and "just" add another module > triggered by the same strobe that usually goes to vita_tx_chain, and > taps into the same signals that you want to read, but only "forwards" > them every 128th time, if this is the functionality you're looking for > and timing allows it. But then again, I'm not an experienced HDL > developer nor too familiar with the functionality of vita_tx*. > > Hope I could help you the least, > Marcus > > On 27.01.2014 12:39, Marcus Müller wrote: > > Hi Bhaskar, > > > > though I'm certainly not the FPGA expert here, I'll try to get a > > clear understanding of what's going on ;) So: > > > > On 25.01.2014 15:28, BHASKAR BANERJEE wrote: > > > > I guess you're referring to fpga/usrp2/sdr_lib/dsp_tx_glue.v, > > signal name duc_in_strobe, right? I think that should be identical > > to the baseband strobe, bb_strobe, but I can't confirm that. > > > > I think that is a bit beyond my understanding of the FPGA > > architecture, but I do believe you :) > > > > So we're talking about signals connected in top/USRP2/u2_core.v, > > wherein we're considering the wire tx_strobe? > > > > Hm, this sounds nontrivial to say, can you figure out who disables > > duc_in_enable (am I on the right path?)? Anyway, if you're changes > > are not to sensitive, would you mind creating a github repo (or the > > like) with a branch containing the changes you've made, so that > > people might have a look at it? > > > > Um, of what? Actually, I'm not quite sure if vita_tx_chain is not > > sensitive to getting data; from your problem I guess it would be > > wiser to just keep the functionality as it is, and "just" add > > another module triggered by the same strobe that usually goes to > > vita_tx_chain, and taps into the same signals that you want to > > read, but only "forwards" them every 128th time, if this is the > > functionality you're looking for and timing allows it. But then > > again, I'm not an experienced HDL developer nor too familiar with > > the functionality of vita_tx*. > > > > Hope I could help you the least, Marcus > > > > _______________________________________________ USRP-users mailing > > list USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJS5p8iAAoJEAFxB7BbsDrLE8MH+wdGZWSxO/QTPrt0AWSErxAY > DkBYs7w2DZHkCdsMM63rVekLSsJG/9EnlELbrsXF7pqHQxiT+kuA7P0OjXAUwe+p > FBDLvGqkFXaW2ghmnxMwI1ouZ9B6uj2adufnszzIwqj17b2sc+JvP0HMHrbCGoFn > 5Oje5dHBmaDWCF5DddEqopMfTqqOCKQEAECcxtjRBP/oFLGdpwA0Ad6oKyiYZgHt > LK+W7t3arrc6Lya469ADr/oySX6OimWlf2nWigL09EFswlcqHBgUtnSPkt2v7Dia > UqZdbUfKAMX4KYjnlN+iGmNZO3TMciMxwmhelBrHOYdqgXUv5d6IRcj5IzTXNeE= > =kuO8 > -----END PGP SIGNATURE----- > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bhaskar, thanks for your nice feedback :) Means a lot to me. > I traced the enable signal which is going low after a few reads. > This signal is run in vita_tx_chain. Run signal goes low when clear > is high. Clear signal comes from a settings_reg . This settings_reg > gives out a flush and a clear signal depending upon set_data, > set_address and set stb. I found that when set_stb is high and > set_addr == address (parameter inside setting_reg) then clear goes > high. this set_addr is a part of sfc_rd signal in packet > router.This sfc_rd signal contains some information from the > ethernet packet. > > Can you tell me what is the purpose of this clear signal? and If > the data transfer between computer and Ethernet is also dependent > on the rate that I set in the command prompt. Sorry, can't help you much with that, since I don't really know what happens in the FPGA by heart. But there are some on this mailing list that might jump in :) Of course, the data rate is directly proportional to the sample rate, but I can't really say whether the USRP takes some measures to schedule the packages or just transmits them when they are there. > If I make the clear and flush signal 1'b0 then the error goes away > (atleast for the number of samples visible in the buffer window) > but I am not sure if it hamper the overall working of USRP. I have no knowledge about that. > > I am attaching a .rar file which conatains the snapshots of the > changes and the changed dsp_tx_glues.v file.In this .rar file you > will find that I am making duc_in_strobe high after every 32 nd > cycle rather than 128 (just for testing purpose). My unrar fails on the archive, and generally it is not a great idea to attach large archives to mailing list posts; can you upload the snapshots (I assume these are images) to an image hosting service (imgur or the like), and supply the source code changes either via git (which I prefer) or via pastebin or the like? > > Please have a look. I'm at work now and can't really have a look now; please don't expect too much, I'm not a seasoned HDL developer and most probably I won't find things that you might have done wrong. Greetings, Marcus > > On Mon, Jan 27, 2014 at 11:32 PM, Marcus Müller > <marcus@hostalia.de> wrote: > > Sorry, somehow your questions were magically edited out of my > reply. So here I go, trying it anew: > > On 25.01.2014 15:28, BHASKAR BANERJEE wrote: >>>> The strobe signal in dsp_tx_glue is the back pressure >>>> signal. > > I guess you're referring to fpga/usrp2/sdr_lib/dsp_tx_glue.v, > signal name duc_in_strobe, right? I think that should be identical > to the baseband strobe, bb_strobe, but I can't confirm that. > >>>> When this signal goes high 32 bits of data is read from >>>> vita_tx_chain.This strobe signal is actually depends on the >>>> rate we set in the terminal. > > I think that is a bit beyond my understanding of the FPGA > architecture, but I do believe you. > >>>> I want to control the strobe signal that goes duc_chain to >>>> vita_tx_chain . > So we're talking about signals connected in top/USRP2/u2_core.v, > wherein we're considering the wire tx_strobe? > >>>> Actually i need to read 4 bytes of data from vita_tx_chain >>>> after every 128 duc_in_strobe pulses. I do this because my >>>> module in dsp_tx_glue generates 128 samples from each 4 bytes >>>> of data read from vita_tx_chain. So my new strobe is high in >>>> every 128th duc_in_strobe but this arrangement works for only >>>> a few reads , after which the enable signal og dsp_tx_glue >>>> goes low. If I increase the delay between two file read, it >>>> does few more reads. > > Is this because the fifo's are overflowing? Hm, this sounds > nontrivial to say, can you figure out who disables duc_in_enable > (am I on the right path?)? Anyway, if you're changes are not to > sensitive, would you mind creating a github repo (or the like) with > a branch containing the changes you've made, so that people might > have a look at it? > >>>> Can I achive my purpose in a different way? Can I keep the >>>> rate in duc_chain to what we set from terminal but read from >>>> vita_tx_chain 128 times slower so that my module in between >>>> takes care of the . > > > Um, of what? Actually, I'm not quite sure if vita_tx_chain is not > sensitive to getting data; from your problem I guess it would be > wiser to just keep the functionality as it is, and "just" add > another module triggered by the same strobe that usually goes to > vita_tx_chain, and taps into the same signals that you want to > read, but only "forwards" them every 128th time, if this is the > functionality you're looking for and timing allows it. But then > again, I'm not an experienced HDL developer nor too familiar with > the functionality of vita_tx*. > > Hope I could help you the least, Marcus > > On 27.01.2014 12:39, Marcus Müller wrote: >>>> Hi Bhaskar, >>>> >>>> though I'm certainly not the FPGA expert here, I'll try to >>>> get a clear understanding of what's going on ;) So: >>>> >>>> On 25.01.2014 15:28, BHASKAR BANERJEE wrote: >>>> >>>> I guess you're referring to >>>> fpga/usrp2/sdr_lib/dsp_tx_glue.v, signal name duc_in_strobe, >>>> right? I think that should be identical to the baseband >>>> strobe, bb_strobe, but I can't confirm that. >>>> >>>> I think that is a bit beyond my understanding of the FPGA >>>> architecture, but I do believe you :) >>>> >>>> So we're talking about signals connected in >>>> top/USRP2/u2_core.v, wherein we're considering the wire >>>> tx_strobe? >>>> >>>> Hm, this sounds nontrivial to say, can you figure out who >>>> disables duc_in_enable (am I on the right path?)? Anyway, if >>>> you're changes are not to sensitive, would you mind creating >>>> a github repo (or the like) with a branch containing the >>>> changes you've made, so that people might have a look at it? >>>> >>>> Um, of what? Actually, I'm not quite sure if vita_tx_chain is >>>> not sensitive to getting data; from your problem I guess it >>>> would be wiser to just keep the functionality as it is, and >>>> "just" add another module triggered by the same strobe that >>>> usually goes to vita_tx_chain, and taps into the same signals >>>> that you want to read, but only "forwards" them every 128th >>>> time, if this is the functionality you're looking for and >>>> timing allows it. But then again, I'm not an experienced HDL >>>> developer nor too familiar with the functionality of >>>> vita_tx*. >>>> >>>> Hope I could help you the least, Marcus >>>> >>>> _______________________________________________ USRP-users >>>> mailing list USRP-users@lists.ettus.com >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>> >> >> >>>> _______________________________________________ >> USRP-users mailing list USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS6M4nAAoJEAFxB7BbsDrLR4YIAIwYoJkum2OYTHI8oNMXdoFj SmZPGPVVw0+CTpIIzXtQ9zjHRKbQG+7kie/yCaBSxrTxo86ejAvGWTPYCB9Nd8gY bBmwb5CFs7TUS5wMoQLdkc2N45Wg5+bJJIWpHq64JOo1TanynZ1PSEi96GI/vGeq z1wb4vzP+5z7/cEZ29PRB4suQrR15zTB/dJnBsSDCQZXer/GsoPXrkVxEVz+1EmF Ymo68sFREt1jqImp6EqfT5RK2hKy3QW2NOhP+KyBonCY0vILMYtiKVnjMcmfQBoG ycJHnHJQYP281U2Sipm9mUiS/375/7XxJDhpmvmQMUTkOTPgqTCi7BPIVM8HGoE= =eRlL -----END PGP SIGNATURE-----