umtrx fpga internal clocking

sergey kostanbaev sergey.kostanbaev at gmail.com
Tue Apr 15 10:59:09 UTC 2014


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.html>


More information about the UmTRX mailing list