Seems like there are still limits on the FPGA side if it's desired to use OSS toolchains for it. For instance, SymbiFlow is missing Xilinx DSP support per https://symbiflow.github.io/. Do we foresee that to be an issue?
Anyway, personally, I'd go with 128MB RAM/64-128MB flash to enable future expansion, but I also haven't quoted pricing recently. FPGA offload would potentially reduce requirements, too. (BTW, I imagine actually building on the target would be rare. Cross compiling on a desktop or laptop PC will always be significantly faster, even taking transfer time into account.) -Mooneer K6AQ On Sat, Jul 18, 2020 at 4:27 PM glen english <g...@cortexrf.com.au> wrote: > I am designing an SM3000, and now is the time for input from users. > (input request below) > > ***** > Design Goals : > > High computational capability : So that our modems and codecs as they > become more advanced, are less constrained by the STM32F4 platform. > > Platform to be Linux so that development, updates, debugging is very > similar to the PC platform. > > To be low cost - so that the cost is not a barrier to entry. Not all of > us live in wealthy western countries. > > To be able to run advanced wideband modems and advanced speech codecs > like LPCnet-Codec2. > > To have platform capability (but maybe not on the PCB) to provide > advanced connectivity - to be able to provide features without having to > learn new platforms. > > To Fit in the SM1000 box. > > To be both Audio/USB interface (in the SM1000 package) , > > - and when piggyback boards permit, a standalone full digital radio. > > To have an open ecosystem/environment > > No special cooling requirements. > > To have the ARM processor core do as much as possible, and only use the > FPGA for what the ARM processor cannot do , or cannot do efficiently. > This means 'normal' people can code in the linux GNU eco system, and the > amount of specialized work in the FPGA is reduced. The FPGA will be > used for function blocks like accelerators and digital radio interfacing > > -------------- > > I have chosen the Xilinx Zynq XC7007S hybrid CortexA9 / FPGA . The > single core will give us 7x the computational power of the STM32F4 , and > that is before we use the NEON instruction unit. The FPGA has 1.8Mb of > variable aspect dual port block RAMs and 66 DSP units that will run at > 350 MHz if pipelined. The use of LPDDR2 will enable high power saving > options. > > ***********The input I need from developers is :*********** > > *** How much RAM do you think we need ? while linux will run in 16 MB > (just!) I was thinking 64 or 128 MBytes. RAM costs money and power, so > we cannot go overkill. W need enough room for verbose symbol tables, > debugging and maybe compilation on the target. > > How realistic is compile and linking large apps on the target with > limited RAM ? I have run into memory limitations with recent GCC > compilating on a constrained platform. OR do we just cross compile ? > > We need some room for a 2nd FPGA image (~ 10 Mbits) , so that we can > (partially or fully) reconfigure the FPGA between TX/RX if we run out > of configured fabric under some condition that I yet cannot think of. > > ***boot flash size: How much ? (linux image, FS) + FPGA images. flash > will be QSPI. 16MB? 32MB ? 64 MB ? agani, memory costs money, and every > dollar counts. 64 MBytes seems plenty to carry different options in the > one image. > > In most cases, for RAM and boot flash larger parts can be fitted with > same PCB design. > > *** > > The digital radio half (if used) will use a clean PLL+VCO synthesiser > chip so that phase noise issues to not cause problems for other uses > when operated at high power. Most small single chip radios are designed > for 100mW maximum and use at higher power, or large antennas pollutes > radio spectrum. > > To keep costs down, the radio will use < 65 Msps ADC and DAC, and will > notionally be a 28 MHz IF radio when used > 50 MHz. This is so it can > use many of the $50 transverter kits and modules available. > > On aliases , the 28 MHz IF radio It will be capable of operation at 146 > MHz but if you want 'base station' quality, you will need to use a > converter. > > -glen > > > > > _______________________________________________ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >
_______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2