From Alexander.Chemeris at fairwaves.co  Tue Apr  8 19:45:58 2014
From: Alexander.Chemeris at fairwaves.co (Alexander Chemeris)
Date: Tue, 8 Apr 2014 23:45:58 +0400
Subject: umtrx fpga internal clocking
In-Reply-To: <53444763.2050903@joshknows.com>
References: <53444763.2050903@joshknows.com>
Message-ID: <CABmJbFVHZ1vZGMs_GpeEVGfS-agGNnsrJhqyiO47orLzoJJo2A@mail.gmail.com>

Hi Josh,

On Tue, Apr 8, 2014 at 11:00 PM, Josh Blum <josh at joshknows.com> wrote:
> Hey guys,
>
> Please CC whoever appropriate.
>
> I have been looking over the u2plus_core.v and u2plus_umtrx_v2.v files
> with the intention of updating the vita rx/tx chains and dsp chains. I
> noticed a few interesting things about the clocking and I just wanted to
> confirm some of my assumptions, a few possible changes, and possibly
> share some knowledge.
>
> 1) vita chain/dsp core
> Inside the u2plus_core.v, there is a 13MHz clock (lms_clk) that is used
> to clock the time core and the dsps. The vita chain is clocked at 104MHz
> (dsp_clk). So for example, when the dsp strobes out 1 sample, does the
> vita_rx_chain see 8 of the same sample?
>
> My immediate concern is updating the vita and dsp chains. So, I really
> just need to understand the interaction between the dsp and the vita
> chain since they are crossing this 104/13Mhz clock domain.
>
> 2) usrp3 style vita framing/deframing
> Some time after umtrx was released, B200 came out. The FPGA architecture
> in B200 was changed from the earlier models to address dealing with
> these integrated frontend chips. Specifically, the ADC, DAC, DSP, and
> framing can all run on the same clock domain at full sample rate. This
> is accomplished because the vita framing happens on 64-bit wide bus to
> deal with the overhead of VITA headers. I suspect this architecture
> would be better fitting for the UmTRX.

I think the B200 architecture is better for UmTRX, but I'll let Andrew
and Sergey to decide, as they know the FPGA code much better.

> 3) u2plus_umtrx_v2.v
> It looks like the ADC and DAC IQ signals are clocked in/out on the
> positive and negative edges of the 13MHz clock. This is accomplished
> using a 26 MHz clock. So technically, this is another clock domain
> crossing between the 13/26MHz for the ADC/DAC signals. So, you should be
> able to accomplish the same effect in with just the 13MHz clock using
> the ODDR2 and IDDR2 xilinx modules.
>
> 4) digital loopback options?
> I was looking for a way to do a digital loopback inside the LMS. I wasnt
> sure if it was possible. Basically, if I set some value on the DAC pins,
> can I get the same value of the ADC pins? I saw registers for baseband
> loopback, but I think thats all analog. The idea is to self-test the bus
> timing by putting a test word into the IOs.

Unfortunately, there is no digital loopback in the LMS.
As you correctly note, the baseband loopback is actually analog.

> ---
> In any case, the most important issue is #1. I want to have a host build
> and image that is fully functional with latest UHD, lets say next week.
> And I would like to be able to first verify with your team that we
> havent lost any functionality, before further changes like the timed
> command core. Sounds OK to you?

Ok with me.

> Thanks,
> -josh
>
>
>
>



-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc. / ??? ???????
https://fairwaves.co



From plddesigner at gmail.com  Tue Apr  8 19:59:20 2014
From: plddesigner at gmail.com (Andrew Karpenkov)
Date: Tue, 8 Apr 2014 22:59:20 +0300
Subject: umtrx fpga internal clocking
In-Reply-To: <CABmJbFVHZ1vZGMs_GpeEVGfS-agGNnsrJhqyiO47orLzoJJo2A@mail.gmail.com>
References: <53444763.2050903@joshknows.com>
	<CABmJbFVHZ1vZGMs_GpeEVGfS-agGNnsrJhqyiO47orLzoJJo2A@mail.gmail.com>
Message-ID: <CACy-4b=OM-Q_CgkC49_xM-W3wJQGf=j0z=yYm7_kFe76tUMDDA@mail.gmail.com>

Hi, Josh.

Please, see my comments below.

1) vita chain/dsp core
> Inside the u2plus_core.v, there is a 13MHz clock (lms_clk) that is used
> to clock the time core and the dsps. The vita chain is clocked at 104MHz
> (dsp_clk). So for example, when the dsp strobes out 1 sample, does the
> vita_rx_chain see 8 of the same sample?
>
No. If you look at dsp_core_rx.v. You'll see that strobe signal is forming
at 104MHz (dsp_clk), not at adc_clk (13MHz).
I added some additional code in purpose of moving strobe signal from 13MHz
clock domain into 104MHz clock domain.
If needed, I can point you to the appropriate commit in our git repository.


2) usrp3 style vita framing/deframing

Some time after umtrx was released, B200 came out. The FPGA architecture
> in B200 was changed from the earlier models to address dealing with
> these integrated frontend chips. Specifically, the ADC, DAC, DSP, and
> framing can all run on the same clock domain at full sample rate. This
> is accomplished because the vita framing happens on 64-bit wide bus to
> deal with the overhead of VITA headers. I suspect this architecture
> would be better fitting for the UmTRX.

I mostly agree with you, but I need some time to look at B200 fpga code
more deeply.

3) u2plus_umtrx_v2.v
> It looks like the ADC and DAC IQ signals are clocked in/out on the
> positive and negative edges of the 13MHz clock. This is accomplished
> using a 26 MHz clock. So technically, this is another clock domain
> crossing between the 13/26MHz for the ADC/DAC signals. So, you should be
> able to accomplish the same effect in with just the 13MHz clock using
> the ODDR2 and IDDR2 xilinx modules.

Yes, but global clock for LMS chip must be twice higher then samples rate.
Therefore UmTRX have common 26MHz global clock source for FPGA and LMS
chips instead of 13MHz.

4) digital loopback options?
> I was looking for a way to do a digital loopback inside the LMS. I wasnt
> sure if it was possible. Basically, if I set some value on the DAC pins,
> can I get the same value of the ADC pins? I saw registers for baseband
> loopback, but I think thats all analog. The idea is to self-test the bus
> timing by putting a test word into the IOs.

In this question I agree with Alexander.  There is no digital loopback in
the LMS, only analog loopback.

Regards,
Andrew Karpenkov

? ?????????,
?????? ?????????


2014-04-08 22:45 GMT+03:00 Alexander Chemeris <
Alexander.Chemeris at fairwaves.co>:

> Hi Josh,
>
> On Tue, Apr 8, 2014 at 11:00 PM, Josh Blum <josh at joshknows.com> wrote:
> > Hey guys,
> >
> > Please CC whoever appropriate.
> >
> > I have been looking over the u2plus_core.v and u2plus_umtrx_v2.v files
> > with the intention of updating the vita rx/tx chains and dsp chains. I
> > noticed a few interesting things about the clocking and I just wanted to
> > confirm some of my assumptions, a few possible changes, and possibly
> > share some knowledge.
> >
> > 1) vita chain/dsp core
> > Inside the u2plus_core.v, there is a 13MHz clock (lms_clk) that is used
> > to clock the time core and the dsps. The vita chain is clocked at 104MHz
> > (dsp_clk). So for example, when the dsp strobes out 1 sample, does the
> > vita_rx_chain see 8 of the same sample?
> >
> > My immediate concern is updating the vita and dsp chains. So, I really
> > just need to understand the interaction between the dsp and the vita
> > chain since they are crossing this 104/13Mhz clock domain.
> >
> > 2) usrp3 style vita framing/deframing
> > Some time after umtrx was released, B200 came out. The FPGA architecture
> > in B200 was changed from the earlier models to address dealing with
> > these integrated frontend chips. Specifically, the ADC, DAC, DSP, and
> > framing can all run on the same clock domain at full sample rate. This
> > is accomplished because the vita framing happens on 64-bit wide bus to
> > deal with the overhead of VITA headers. I suspect this architecture
> > would be better fitting for the UmTRX.
>
> I think the B200 architecture is better for UmTRX, but I'll let Andrew
> and Sergey to decide, as they know the FPGA code much better.
>
> > 3) u2plus_umtrx_v2.v
> > It looks like the ADC and DAC IQ signals are clocked in/out on the
> > positive and negative edges of the 13MHz clock. This is accomplished
> > using a 26 MHz clock. So technically, this is another clock domain
> > crossing between the 13/26MHz for the ADC/DAC signals. So, you should be
> > able to accomplish the same effect in with just the 13MHz clock using
> > the ODDR2 and IDDR2 xilinx modules.
> >
> > 4) digital loopback options?
> > I was looking for a way to do a digital loopback inside the LMS. I wasnt
> > sure if it was possible. Basically, if I set some value on the DAC pins,
> > can I get the same value of the ADC pins? I saw registers for baseband
> > loopback, but I think thats all analog. The idea is to self-test the bus
> > timing by putting a test word into the IOs.
>
> Unfortunately, there is no digital loopback in the LMS.
> As you correctly note, the baseband loopback is actually analog.
>
> > ---
> > In any case, the most important issue is #1. I want to have a host build
> > and image that is fully functional with latest UHD, lets say next week.
> > And I would like to be able to first verify with your team that we
> > havent lost any functionality, before further changes like the timed
> > command core. Sounds OK to you?
>
> Ok with me.
>
> > Thanks,
> > -josh
> >
> >
> >
> >
>
>
>
> --
> Regards,
> Alexander Chemeris.
> CEO, Fairwaves, Inc. / ??? ???????
> https://fairwaves.co
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20140408/6827d596/attachment.htm>

From josh at joshknows.com  Tue Apr  8 23:25:02 2014
From: josh at joshknows.com (Josh Blum)
Date: Tue, 08 Apr 2014 16:25:02 -0700
Subject: umtrx fpga internal clocking
In-Reply-To: <CACy-4b=OM-Q_CgkC49_xM-W3wJQGf=j0z=yYm7_kFe76tUMDDA@mail.gmail.com>
References: <53444763.2050903@joshknows.com>
	<CABmJbFVHZ1vZGMs_GpeEVGfS-agGNnsrJhqyiO47orLzoJJo2A@mail.gmail.com>
	<CACy-4b=OM-Q_CgkC49_xM-W3wJQGf=j0z=yYm7_kFe76tUMDDA@mail.gmail.com>
Message-ID: <5344854E.3020209@joshknows.com>


>>
> No. If you look at dsp_core_rx.v. You'll see that strobe signal is forming
> at 104MHz (dsp_clk), not at adc_clk (13MHz).
> I added some additional code in purpose of moving strobe signal from 13MHz
> clock domain into 104MHz clock domain.
> If needed, I can point you to the appropriate commit in our git repository.
> 
> 

I see. I just got lost in the ifdefs. Those are the changes I was
looking for.

> 
> Yes, but global clock for LMS chip must be twice higher then samples rate.
> Therefore UmTRX have common 26MHz global clock source for FPGA and LMS
> chips instead of 13MHz.
> 

I see, the input clock is 26 MHz, ok makes sense.

Thanks!

So let me propose one more idea for thought. To avoid clock domain
crossing completely: We can use the existing usrp2 style design at 26
MHz. The rx/tx DSP, and vita framer/deframer all run at 26 MHz. The only
change needed is to pace the DSPs. For example, the rx input is only
good every other 26 MHz cycle, so add an input strobe to the RX DSP.
Similarly the TX DSP would have its input paced to take data every other
cycle. That way the 32-bit vita framers will have 2x clock cycles to do
the framing/deframing even when the DSP is running at full rate.

104MHz fifo bus in -> cross clock fifo to 26 MHz -> vita tx deframer ->
paced tx dsp -> out to dac

in from adc -> paced rx dsp -> vita rx deframer -> cross clock fifo to
104 MHz -> 104 MHz fifo bus out

Just a thought,
-josh



From plddesigner at gmail.com  Wed Apr  9 10:17:45 2014
From: plddesigner at gmail.com (Andrew Karpenkov)
Date: Wed, 9 Apr 2014 14:17:45 +0400
Subject: umtrx fpga internal clocking
In-Reply-To: <5344854E.3020209@joshknows.com>
References: <53444763.2050903@joshknows.com>
	<CABmJbFVHZ1vZGMs_GpeEVGfS-agGNnsrJhqyiO47orLzoJJo2A@mail.gmail.com>
	<CACy-4b=OM-Q_CgkC49_xM-W3wJQGf=j0z=yYm7_kFe76tUMDDA@mail.gmail.com>
	<5344854E.3020209@joshknows.com>
Message-ID: <CACy-4bkBmvLdja5DwNyTLHByCzo3Ej8i9mJ0kjouNO_o1G7X5Q@mail.gmail.com>

Josh,
I'm glad that I answered on most of yours questions. If you need some more
information, don't hesitate to contact with me.

104MHz fifo bus in -> cross clock fifo to 26 MHz -> vita tx deframer ->
> paced tx dsp -> out to dac
> in from adc -> paced rx dsp -> vita rx deframer -> cross clock fifo to
> 104 MHz -> 104 MHz fifo bus out


According to your idea. I think that this is fine, but are you're sure that
26MHz is enough for DSP calculations? In N2x0 DSP clock frequency was twice
higher than CPU clock.


Regards,
Andrew Karpenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20140409/818e6098/attachment.htm>

From josh at joshknows.com  Wed Apr  9 17:43:25 2014
From: josh at joshknows.com (Josh Blum)
Date: Wed, 09 Apr 2014 10:43:25 -0700
Subject: umtrx fpga internal clocking
In-Reply-To: <CACy-4bkBmvLdja5DwNyTLHByCzo3Ej8i9mJ0kjouNO_o1G7X5Q@mail.gmail.com>
References: <53444763.2050903@joshknows.com>
	<CABmJbFVHZ1vZGMs_GpeEVGfS-agGNnsrJhqyiO47orLzoJJo2A@mail.gmail.com>
	<CACy-4b=OM-Q_CgkC49_xM-W3wJQGf=j0z=yYm7_kFe76tUMDDA@mail.gmail.com>
	<5344854E.3020209@joshknows.com>
	<CACy-4bkBmvLdja5DwNyTLHByCzo3Ej8i9mJ0kjouNO_o1G7X5Q@mail.gmail.com>
Message-ID: <534586BD.5010201@joshknows.com>



On 04/09/2014 03:17 AM, Andrew Karpenkov wrote:
> Josh,
> I'm glad that I answered on most of yours questions. If you need some more
> information, don't hesitate to contact with me.
> 
> 104MHz fifo bus in -> cross clock fifo to 26 MHz -> vita tx deframer ->
>> paced tx dsp -> out to dac
>> in from adc -> paced rx dsp -> vita rx deframer -> cross clock fifo to
>> 104 MHz -> 104 MHz fifo bus out
> 
> 
> According to your idea. I think that this is fine, but are you're sure that
> 26MHz is enough for DSP calculations? In N2x0 DSP clock frequency was twice
> higher than CPU clock.
> 

Well technically, the DSP only needs to run as fast as the ADC/DAC
sample rate. In the current UMTRX design, the DSP calculations
themselves are running at 13 MHz. I'm only suggesting moving the VITA
framer/deframer into the same clock domain as the DSP units (26MHz). The
actual buffering, packet routing, fifo muxing, that sort of stuff will
stay in the 104MHz clock domain (it has to be faster because of
buffering/sending ethernet packets). And the CPU/ZPU/wishbone clock is
independent, and really only for low speed communications -- I would
simply keep this at 52 Mhz, but in fact, its clock rate isnt really
critical.

-josh



From plddesigner at gmail.com  Wed Apr  9 18:52:29 2014
From: plddesigner at gmail.com (Andrew Karpenkov)
Date: Wed, 9 Apr 2014 21:52:29 +0300
Subject: umtrx fpga internal clocking
In-Reply-To: <534586BD.5010201@joshknows.com>
References: <53444763.2050903@joshknows.com>
	<CABmJbFVHZ1vZGMs_GpeEVGfS-agGNnsrJhqyiO47orLzoJJo2A@mail.gmail.com>
	<CACy-4b=OM-Q_CgkC49_xM-W3wJQGf=j0z=yYm7_kFe76tUMDDA@mail.gmail.com>
	<5344854E.3020209@joshknows.com>
	<CACy-4bkBmvLdja5DwNyTLHByCzo3Ej8i9mJ0kjouNO_o1G7X5Q@mail.gmail.com>
	<534586BD.5010201@joshknows.com>
Message-ID: <CACy-4b=O0FBt9Ek9r1CU0uf+LoEPnMMC6k9861H23mews16Hjw@mail.gmail.com>

Ok. I understand.

I suppose that before make changes in current fpga code, we should make a
decision exactly which architecture more suitable for UmTRX, N2x0 or B200?
Sergey, Josh, what do you think about this, pro and con?

Unfortunately, I can look into B200 fpga code only at friday..

Regards,
Andrew Karpenkov


2014-04-09 20:43 GMT+03:00 Josh Blum <josh at joshknows.com>:

>
>
> On 04/09/2014 03:17 AM, Andrew Karpenkov wrote:
> > Josh,
> > I'm glad that I answered on most of yours questions. If you need some
> more
> > information, don't hesitate to contact with me.
> >
> > 104MHz fifo bus in -> cross clock fifo to 26 MHz -> vita tx deframer ->
> >> paced tx dsp -> out to dac
> >> in from adc -> paced rx dsp -> vita rx deframer -> cross clock fifo to
> >> 104 MHz -> 104 MHz fifo bus out
> >
> >
> > According to your idea. I think that this is fine, but are you're sure
> that
> > 26MHz is enough for DSP calculations? In N2x0 DSP clock frequency was
> twice
> > higher than CPU clock.
> >
>
> Well technically, the DSP only needs to run as fast as the ADC/DAC
> sample rate. In the current UMTRX design, the DSP calculations
> themselves are running at 13 MHz. I'm only suggesting moving the VITA
> framer/deframer into the same clock domain as the DSP units (26MHz). The
> actual buffering, packet routing, fifo muxing, that sort of stuff will
> stay in the 104MHz clock domain (it has to be faster because of
> buffering/sending ethernet packets). And the CPU/ZPU/wishbone clock is
> independent, and really only for low speed communications -- I would
> simply keep this at 52 Mhz, but in fact, its clock rate isnt really
> critical.
>
> -josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20140409/a18adbd7/attachment.htm>

From sergey.kostanbaev at gmail.com  Wed Apr  9 19:07:35 2014
From: sergey.kostanbaev at gmail.com (sergey kostanbaev)
Date: Wed, 9 Apr 2014 23:07:35 +0400
Subject: umtrx fpga internal clocking
In-Reply-To: <CACy-4b=O0FBt9Ek9r1CU0uf+LoEPnMMC6k9861H23mews16Hjw@mail.gmail.com>
References: <53444763.2050903@joshknows.com>
	<CABmJbFVHZ1vZGMs_GpeEVGfS-agGNnsrJhqyiO47orLzoJJo2A@mail.gmail.com>
	<CACy-4b=OM-Q_CgkC49_xM-W3wJQGf=j0z=yYm7_kFe76tUMDDA@mail.gmail.com>
	<5344854E.3020209@joshknows.com>
	<CACy-4bkBmvLdja5DwNyTLHByCzo3Ej8i9mJ0kjouNO_o1G7X5Q@mail.gmail.com>
	<534586BD.5010201@joshknows.com>
	<CACy-4b=O0FBt9Ek9r1CU0uf+LoEPnMMC6k9861H23mews16Hjw@mail.gmail.com>
Message-ID: <CAGtNMfPQ3vBZh11nF1FGu33uV42KepPMxPBQeJsjtMGzoVVE6A@mail.gmail.com>

I also haven't had a time to look at. Hopefully I'll look at Friday.
On Apr 9, 2014 10:52 PM, "Andrew Karpenkov" <plddesigner at gmail.com> wrote:

> Ok. I understand.
>
> I suppose that before make changes in current fpga code, we should make a
> decision exactly which architecture more suitable for UmTRX, N2x0 or B200?
> Sergey, Josh, what do you think about this, pro and con?
>
> Unfortunately, I can look into B200 fpga code only at friday..
>
> Regards,
> Andrew Karpenkov
>
>
> 2014-04-09 20:43 GMT+03:00 Josh Blum <josh at joshknows.com>:
>
>>
>>
>> On 04/09/2014 03:17 AM, Andrew Karpenkov wrote:
>> > Josh,
>> > I'm glad that I answered on most of yours questions. If you need some
>> more
>> > information, don't hesitate to contact with me.
>> >
>> > 104MHz fifo bus in -> cross clock fifo to 26 MHz -> vita tx deframer ->
>> >> paced tx dsp -> out to dac
>> >> in from adc -> paced rx dsp -> vita rx deframer -> cross clock fifo to
>> >> 104 MHz -> 104 MHz fifo bus out
>> >
>> >
>> > According to your idea. I think that this is fine, but are you're sure
>> that
>> > 26MHz is enough for DSP calculations? In N2x0 DSP clock frequency was
>> twice
>> > higher than CPU clock.
>> >
>>
>> Well technically, the DSP only needs to run as fast as the ADC/DAC
>> sample rate. In the current UMTRX design, the DSP calculations
>> themselves are running at 13 MHz. I'm only suggesting moving the VITA
>> framer/deframer into the same clock domain as the DSP units (26MHz). The
>> actual buffering, packet routing, fifo muxing, that sort of stuff will
>> stay in the 104MHz clock domain (it has to be faster because of
>> buffering/sending ethernet packets). And the CPU/ZPU/wishbone clock is
>> independent, and really only for low speed communications -- I would
>> simply keep this at 52 Mhz, but in fact, its clock rate isnt really
>> critical.
>>
>> -josh
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20140409/cf74af28/attachment.htm>

From plddesigner at gmail.com  Mon Apr 14 18:02:25 2014
From: plddesigner at gmail.com (Andrew Karpenkov)
Date: Mon, 14 Apr 2014 22:02:25 +0400
Subject: umtrx fpga internal clocking
In-Reply-To: <CAGtNMfPQ3vBZh11nF1FGu33uV42KepPMxPBQeJsjtMGzoVVE6A@mail.gmail.com>
References: <53444763.2050903@joshknows.com>
	<CABmJbFVHZ1vZGMs_GpeEVGfS-agGNnsrJhqyiO47orLzoJJo2A@mail.gmail.com>
	<CACy-4b=OM-Q_CgkC49_xM-W3wJQGf=j0z=yYm7_kFe76tUMDDA@mail.gmail.com>
	<5344854E.3020209@joshknows.com>
	<CACy-4bkBmvLdja5DwNyTLHByCzo3Ej8i9mJ0kjouNO_o1G7X5Q@mail.gmail.com>
	<534586BD.5010201@joshknows.com>
	<CACy-4b=O0FBt9Ek9r1CU0uf+LoEPnMMC6k9861H23mews16Hjw@mail.gmail.com>
	<CAGtNMfPQ3vBZh11nF1FGu33uV42KepPMxPBQeJsjtMGzoVVE6A@mail.gmail.com>
Message-ID: <CACy-4b=UD6RNa1uvFMxtQoaiV3KcNmJKdW3uxkkEvKm1cSG5eg@mail.gmail.com>

Hi guys,

I took a quick look at B2x0 architecture.
And the results is here:

   - There is no SRAM and utilization of internal block memory at Spartan 6
   XC6SLX150 is about 70%. So, either we use external memory, or we need to
   use a new fpga.
   - 2 TRX used about 45% of Spartan 6 XC6SLX150 Slices.
   - Instead of Wishbone bus there used AXI bus.
   - There is no CPU at all (hard logic).
   - I didn't find ICAP module here. But this is  very usefull for a far
   away installations.
   - Each DSP module has own reconfigurable vita timer. That's plus.
   - RX/TX control and  RX/TX framer are new, DSP(DUC, DDC and so on) the
   same.
   - There is no second signal from GPS module, only uart.
   - New serial_to_settings module for a working with devices through the
   I2C bus.
   - Overall code is very small and look pretty nice.
   - All required clock limitations are performed with large reserve. Input
   fpga clock is 40 MHz, internal system bus - 100 MHz, DSP clock frequency is
   the same with AD9361 DATA_CLK, 64.44MHz.

 Please, correct me, if I'm wrong.

I think that we need to use B2x0 architecture sooner or later. But this is
huge work for a adding SRAM, Ethernet, CPU, ICAP  into FPGA and UHD codes.
May be  easier to modify current fpga code than rework B210 code for UmTRX
architecture. Don't know..

Regards,
Andrew Karpenkov


2014-04-09 23:07 GMT+04:00 sergey kostanbaev <sergey.kostanbaev at gmail.com>:

> I also haven't had a time to look at. Hopefully I'll look at Friday.
> On Apr 9, 2014 10:52 PM, "Andrew Karpenkov" <plddesigner at gmail.com> wrote:
>
>> Ok. I understand.
>>
>> I suppose that before make changes in current fpga code, we should make a
>> decision exactly which architecture more suitable for UmTRX, N2x0 or B200?
>> Sergey, Josh, what do you think about this, pro and con?
>>
>> Unfortunately, I can look into B200 fpga code only at friday..
>>
>> Regards,
>> Andrew Karpenkov
>>
>>
>> 2014-04-09 20:43 GMT+03:00 Josh Blum <josh at joshknows.com>:
>>
>>>
>>>
>>> On 04/09/2014 03:17 AM, Andrew Karpenkov wrote:
>>> > Josh,
>>> > I'm glad that I answered on most of yours questions. If you need some
>>> more
>>> > information, don't hesitate to contact with me.
>>> >
>>> > 104MHz fifo bus in -> cross clock fifo to 26 MHz -> vita tx deframer ->
>>> >> paced tx dsp -> out to dac
>>> >> in from adc -> paced rx dsp -> vita rx deframer -> cross clock fifo to
>>> >> 104 MHz -> 104 MHz fifo bus out
>>> >
>>> >
>>> > According to your idea. I think that this is fine, but are you're sure
>>> that
>>> > 26MHz is enough for DSP calculations? In N2x0 DSP clock frequency was
>>> twice
>>> > higher than CPU clock.
>>> >
>>>
>>> Well technically, the DSP only needs to run as fast as the ADC/DAC
>>> sample rate. In the current UMTRX design, the DSP calculations
>>> themselves are running at 13 MHz. I'm only suggesting moving the VITA
>>> framer/deframer into the same clock domain as the DSP units (26MHz). The
>>> actual buffering, packet routing, fifo muxing, that sort of stuff will
>>> stay in the 104MHz clock domain (it has to be faster because of
>>> buffering/sending ethernet packets). And the CPU/ZPU/wishbone clock is
>>> independent, and really only for low speed communications -- I would
>>> simply keep this at 52 Mhz, but in fact, its clock rate isnt really
>>> critical.
>>>
>>> -josh
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20140414/63902642/attachment.htm>

From sergey.kostanbaev at gmail.com  Tue Apr 15 10:59:09 2014
From: sergey.kostanbaev at gmail.com (sergey kostanbaev)
Date: Tue, 15 Apr 2014 14:59:09 +0400
Subject: umtrx fpga internal clocking
In-Reply-To: <CACy-4b=UD6RNa1uvFMxtQoaiV3KcNmJKdW3uxkkEvKm1cSG5eg@mail.gmail.com>
References: <53444763.2050903@joshknows.com>
	<CABmJbFVHZ1vZGMs_GpeEVGfS-agGNnsrJhqyiO47orLzoJJo2A@mail.gmail.com>
	<CACy-4b=OM-Q_CgkC49_xM-W3wJQGf=j0z=yYm7_kFe76tUMDDA@mail.gmail.com>
	<5344854E.3020209@joshknows.com>
	<CACy-4bkBmvLdja5DwNyTLHByCzo3Ej8i9mJ0kjouNO_o1G7X5Q@mail.gmail.com>
	<534586BD.5010201@joshknows.com>
	<CACy-4b=O0FBt9Ek9r1CU0uf+LoEPnMMC6k9861H23mews16Hjw@mail.gmail.com>
	<CAGtNMfPQ3vBZh11nF1FGu33uV42KepPMxPBQeJsjtMGzoVVE6A@mail.gmail.com>
	<CACy-4b=UD6RNa1uvFMxtQoaiV3KcNmJKdW3uxkkEvKm1cSG5eg@mail.gmail.com>
Message-ID: <CAGtNMfOwki_S7wQ4S0Nw48bLQ7owOixWXAoiX_pcOHB205abng@mail.gmail.com>

Hi guys,

We cannot compare equally B2x0 and UmTRX, since
- B2x0 has CX3 USB3 interface which has ARM core inside and thus it doesn't
need a CPU inside FPGA
- Ethernet handling and USB is quite different, it's hard to have much code
in common. And SRAM is needed only for Ethernet handling.
- Also we're taking in mind to support PCIe at some time and PCIe needs
another handling interface.
So I don't think we need to move to B2x0 architecture completely.

Probably we can grab some good ideas from B2x0, something like this (but
I'm not sure that are really good)

   - Each DSP module has own reconfigurable vita timer. That's plus.
   - RX/TX control and  RX/TX framer are new, DSP(DUC, DDC and so on) the
   same.

What do you think about
Instead of Wishbone bus there used AXI bus.



On Mon, Apr 14, 2014 at 10:02 PM, Andrew Karpenkov <plddesigner at gmail.com>wrote:

> Hi guys,
>
> I took a quick look at B2x0 architecture.
> And the results is here:
>
>    - There is no SRAM and utilization of internal block memory at Spartan
>    6 XC6SLX150 is about 70%. So, either we use external memory, or we need to
>    use a new fpga.
>    - 2 TRX used about 45% of Spartan 6 XC6SLX150 Slices.
>    - Instead of Wishbone bus there used AXI bus.
>    - There is no CPU at all (hard logic).
>    - I didn't find ICAP module here. But this is  very usefull for a far
>    away installations.
>    - Each DSP module has own reconfigurable vita timer. That's plus.
>    - RX/TX control and  RX/TX framer are new, DSP(DUC, DDC and so on) the
>    same.
>    - There is no second signal from GPS module, only uart.
>    - New serial_to_settings module for a working with devices through the
>    I2C bus.
>    - Overall code is very small and look pretty nice.
>    - All required clock limitations are performed with large reserve.
>    Input fpga clock is 40 MHz, internal system bus - 100 MHz, DSP clock
>    frequency is the same with AD9361 DATA_CLK, 64.44MHz.
>
>  Please, correct me, if I'm wrong.
>
> I think that we need to use B2x0 architecture sooner or later. But this is
> huge work for a adding SRAM, Ethernet, CPU, ICAP  into FPGA and UHD codes.
> May be  easier to modify current fpga code than rework B210 code for UmTRX
> architecture. Don't know..
>
> Regards,
> Andrew Karpenkov
>
>
> 2014-04-09 23:07 GMT+04:00 sergey kostanbaev <sergey.kostanbaev at gmail.com>
> :
>
> I also haven't had a time to look at. Hopefully I'll look at Friday.
>> On Apr 9, 2014 10:52 PM, "Andrew Karpenkov" <plddesigner at gmail.com>
>> wrote:
>>
>>> Ok. I understand.
>>>
>>> I suppose that before make changes in current fpga code, we should make
>>> a decision exactly which architecture more suitable for UmTRX, N2x0 or B200?
>>> Sergey, Josh, what do you think about this, pro and con?
>>>
>>> Unfortunately, I can look into B200 fpga code only at friday..
>>>
>>> Regards,
>>> Andrew Karpenkov
>>>
>>>
>>> 2014-04-09 20:43 GMT+03:00 Josh Blum <josh at joshknows.com>:
>>>
>>>>
>>>>
>>>> On 04/09/2014 03:17 AM, Andrew Karpenkov wrote:
>>>> > Josh,
>>>> > I'm glad that I answered on most of yours questions. If you need some
>>>> more
>>>> > information, don't hesitate to contact with me.
>>>> >
>>>> > 104MHz fifo bus in -> cross clock fifo to 26 MHz -> vita tx deframer
>>>> ->
>>>> >> paced tx dsp -> out to dac
>>>> >> in from adc -> paced rx dsp -> vita rx deframer -> cross clock fifo
>>>> to
>>>> >> 104 MHz -> 104 MHz fifo bus out
>>>> >
>>>> >
>>>> > According to your idea. I think that this is fine, but are you're
>>>> sure that
>>>> > 26MHz is enough for DSP calculations? In N2x0 DSP clock frequency was
>>>> twice
>>>> > higher than CPU clock.
>>>> >
>>>>
>>>> Well technically, the DSP only needs to run as fast as the ADC/DAC
>>>> sample rate. In the current UMTRX design, the DSP calculations
>>>> themselves are running at 13 MHz. I'm only suggesting moving the VITA
>>>> framer/deframer into the same clock domain as the DSP units (26MHz). The
>>>> actual buffering, packet routing, fifo muxing, that sort of stuff will
>>>> stay in the 104MHz clock domain (it has to be faster because of
>>>> buffering/sending ethernet packets). And the CPU/ZPU/wishbone clock is
>>>> independent, and really only for low speed communications -- I would
>>>> simply keep this at 52 Mhz, but in fact, its clock rate isnt really
>>>> critical.
>>>>
>>>> -josh
>>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20140415/c28eff23/attachment.htm>

From andreysviyaz at gmail.com  Tue Apr 15 13:23:54 2014
From: andreysviyaz at gmail.com (Andrey Sviyazov)
Date: Tue, 15 Apr 2014 17:23:54 +0400
Subject: umtrx fpga internal clocking
In-Reply-To: <CAGtNMfOwki_S7wQ4S0Nw48bLQ7owOixWXAoiX_pcOHB205abng@mail.gmail.com>
References: <53444763.2050903@joshknows.com>
	<CABmJbFVHZ1vZGMs_GpeEVGfS-agGNnsrJhqyiO47orLzoJJo2A@mail.gmail.com>
	<CACy-4b=OM-Q_CgkC49_xM-W3wJQGf=j0z=yYm7_kFe76tUMDDA@mail.gmail.com>
	<5344854E.3020209@joshknows.com>
	<CACy-4bkBmvLdja5DwNyTLHByCzo3Ej8i9mJ0kjouNO_o1G7X5Q@mail.gmail.com>
	<534586BD.5010201@joshknows.com>
	<CACy-4b=O0FBt9Ek9r1CU0uf+LoEPnMMC6k9861H23mews16Hjw@mail.gmail.com>
	<CAGtNMfPQ3vBZh11nF1FGu33uV42KepPMxPBQeJsjtMGzoVVE6A@mail.gmail.com>
	<CACy-4b=UD6RNa1uvFMxtQoaiV3KcNmJKdW3uxkkEvKm1cSG5eg@mail.gmail.com>
	<CAGtNMfOwki_S7wQ4S0Nw48bLQ7owOixWXAoiX_pcOHB205abng@mail.gmail.com>
Message-ID: <CAE9ARExGyQy21bOh3QrebaPTW9Q116m89UyjFMS6u4kjd78i2g@mail.gmail.com>

We'll need stable and quite high sample rate for LTE.
So I'd like PCIe to communicate with embedded PC board or via something
like PCIe fiber optic modules.
But this might require more powerful FPGA.


Best regards,
Andrey Sviyazov.


2014-04-15 14:59 GMT+04:00 sergey kostanbaev <sergey.kostanbaev at gmail.com>:

> Hi guys,
>
> We cannot compare equally B2x0 and UmTRX, since
> - B2x0 has CX3 USB3 interface which has ARM core inside and thus it
> doesn't need a CPU inside FPGA
> - Ethernet handling and USB is quite different, it's hard to have much
> code in common. And SRAM is needed only for Ethernet handling.
> - Also we're taking in mind to support PCIe at some time and PCIe needs
> another handling interface.
> So I don't think we need to move to B2x0 architecture completely.
>
> Probably we can grab some good ideas from B2x0, something like this (but
> I'm not sure that are really good)
>
>
>    - Each DSP module has own reconfigurable vita timer. That's plus.
>    - RX/TX control and  RX/TX framer are new, DSP(DUC, DDC and so on) the
>    same.
>
> What do you think about
>
> Instead of Wishbone bus there used AXI bus.
>
>
>
> On Mon, Apr 14, 2014 at 10:02 PM, Andrew Karpenkov <plddesigner at gmail.com>wrote:
>
>> Hi guys,
>>
>> I took a quick look at B2x0 architecture.
>> And the results is here:
>>
>>    - There is no SRAM and utilization of internal block memory at
>>    Spartan 6 XC6SLX150 is about 70%. So, either we use external memory, or we
>>    need to use a new fpga.
>>    - 2 TRX used about 45% of Spartan 6 XC6SLX150 Slices.
>>    - Instead of Wishbone bus there used AXI bus.
>>    - There is no CPU at all (hard logic).
>>    - I didn't find ICAP module here. But this is  very usefull for a far
>>    away installations.
>>    - Each DSP module has own reconfigurable vita timer. That's plus.
>>    - RX/TX control and  RX/TX framer are new, DSP(DUC, DDC and so on)
>>    the same.
>>    - There is no second signal from GPS module, only uart.
>>    - New serial_to_settings module for a working with devices through
>>    the I2C bus.
>>    - Overall code is very small and look pretty nice.
>>    - All required clock limitations are performed with large reserve.
>>    Input fpga clock is 40 MHz, internal system bus - 100 MHz, DSP clock
>>    frequency is the same with AD9361 DATA_CLK, 64.44MHz.
>>
>>  Please, correct me, if I'm wrong.
>>
>> I think that we need to use B2x0 architecture sooner or later. But this
>> is huge work for a adding SRAM, Ethernet, CPU, ICAP  into FPGA and UHD
>> codes.
>> May be  easier to modify current fpga code than rework B210 code for
>> UmTRX architecture. Don't know..
>>
>> Regards,
>> Andrew Karpenkov
>>
>>
>> 2014-04-09 23:07 GMT+04:00 sergey kostanbaev <sergey.kostanbaev at gmail.com
>> >:
>>
>> I also haven't had a time to look at. Hopefully I'll look at Friday.
>>> On Apr 9, 2014 10:52 PM, "Andrew Karpenkov" <plddesigner at gmail.com>
>>> wrote:
>>>
>>>> Ok. I understand.
>>>>
>>>> I suppose that before make changes in current fpga code, we should make
>>>> a decision exactly which architecture more suitable for UmTRX, N2x0 or B200?
>>>> Sergey, Josh, what do you think about this, pro and con?
>>>>
>>>> Unfortunately, I can look into B200 fpga code only at friday..
>>>>
>>>> Regards,
>>>> Andrew Karpenkov
>>>>
>>>>
>>>> 2014-04-09 20:43 GMT+03:00 Josh Blum <josh at joshknows.com>:
>>>>
>>>>>
>>>>>
>>>>> On 04/09/2014 03:17 AM, Andrew Karpenkov wrote:
>>>>> > Josh,
>>>>> > I'm glad that I answered on most of yours questions. If you need
>>>>> some more
>>>>> > information, don't hesitate to contact with me.
>>>>> >
>>>>> > 104MHz fifo bus in -> cross clock fifo to 26 MHz -> vita tx deframer
>>>>> ->
>>>>> >> paced tx dsp -> out to dac
>>>>> >> in from adc -> paced rx dsp -> vita rx deframer -> cross clock fifo
>>>>> to
>>>>> >> 104 MHz -> 104 MHz fifo bus out
>>>>> >
>>>>> >
>>>>> > According to your idea. I think that this is fine, but are you're
>>>>> sure that
>>>>> > 26MHz is enough for DSP calculations? In N2x0 DSP clock frequency
>>>>> was twice
>>>>> > higher than CPU clock.
>>>>> >
>>>>>
>>>>> Well technically, the DSP only needs to run as fast as the ADC/DAC
>>>>> sample rate. In the current UMTRX design, the DSP calculations
>>>>> themselves are running at 13 MHz. I'm only suggesting moving the VITA
>>>>> framer/deframer into the same clock domain as the DSP units (26MHz).
>>>>> The
>>>>> actual buffering, packet routing, fifo muxing, that sort of stuff will
>>>>> stay in the 104MHz clock domain (it has to be faster because of
>>>>> buffering/sending ethernet packets). And the CPU/ZPU/wishbone clock is
>>>>> independent, and really only for low speed communications -- I would
>>>>> simply keep this at 52 Mhz, but in fact, its clock rate isnt really
>>>>> critical.
>>>>>
>>>>> -josh
>>>>>
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20140415/fd1e32fe/attachment.htm>

From josh at joshknows.com  Tue Apr 15 15:21:31 2014
From: josh at joshknows.com (Josh Blum)
Date: Tue, 15 Apr 2014 08:21:31 -0700
Subject: umtrx fpga internal clocking
In-Reply-To: <CAGtNMfOwki_S7wQ4S0Nw48bLQ7owOixWXAoiX_pcOHB205abng@mail.gmail.com>
References: <53444763.2050903@joshknows.com>	<CABmJbFVHZ1vZGMs_GpeEVGfS-agGNnsrJhqyiO47orLzoJJo2A@mail.gmail.com>	<CACy-4b=OM-Q_CgkC49_xM-W3wJQGf=j0z=yYm7_kFe76tUMDDA@mail.gmail.com>	<5344854E.3020209@joshknows.com>	<CACy-4bkBmvLdja5DwNyTLHByCzo3Ej8i9mJ0kjouNO_o1G7X5Q@mail.gmail.com>	<534586BD.5010201@joshknows.com>	<CACy-4b=O0FBt9Ek9r1CU0uf+LoEPnMMC6k9861H23mews16Hjw@mail.gmail.com>	<CAGtNMfPQ3vBZh11nF1FGu33uV42KepPMxPBQeJsjtMGzoVVE6A@mail.gmail.com>	<CACy-4b=UD6RNa1uvFMxtQoaiV3KcNmJKdW3uxkkEvKm1cSG5eg@mail.gmail.com>
	<CAGtNMfOwki_S7wQ4S0Nw48bLQ7owOixWXAoiX_pcOHB205abng@mail.gmail.com>
Message-ID: <534D4E7B.9020906@joshknows.com>



On 04/15/2014 03:59 AM, sergey kostanbaev wrote:
> Hi guys,
> 
> We cannot compare equally B2x0 and UmTRX, since
> - B2x0 has CX3 USB3 interface which has ARM core inside and thus it doesn't
> need a CPU inside FPGA
> - Ethernet handling and USB is quite different, it's hard to have much code
> in common. And SRAM is needed only for Ethernet handling.
> - Also we're taking in mind to support PCIe at some time and PCIe needs
> another handling interface.
> So I don't think we need to move to B2x0 architecture completely.
> 
> Probably we can grab some good ideas from B2x0, something like this (but
> I'm not sure that are really good)
> 
>    - Each DSP module has own reconfigurable vita timer. That's plus.
>    - RX/TX control and  RX/TX framer are new, DSP(DUC, DDC and so on) the
>    same.
> 
> What do you think about
> Instead of Wishbone bus there used AXI bus.
> 
> 

Also see X300:
https://github.com/EttusResearch/uhd/tree/master/fpga/usrp3/top/x300

Very similar design for the adc/dac side of things. But has external RAM
for buffering, network capabilities, a ZPU core inside. Definitely
bigger and more complex.

-josh



From wyjiang at ljshuoda.com  Tue Apr 29 07:33:32 2014
From: wyjiang at ljshuoda.com (=?GB2312?B?va/OxOL5?=)
Date: Tue, 29 Apr 2014 15:33:32 +0800
Subject: How about UmSEL
Message-ID: <2014042915332957404415@ljshuoda.com>

Hi, 

Is there anyone know about the UmSEL? I want to buy it, but I cannot find any information for sale.




Wenyi Jiang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20140429/7fb204f7/attachment.htm>