This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/UmTRX@lists.osmocom.org/.
sergey kostanbaev sergey.kostanbaev at gmail.comHi 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>