[Oberon] Development boards
Joerg
joerg.straube at iaeth.ch
Sat May 2 14:53:39 CEST 2020
In telecommunications, very roughly there are three types of boards you can plug in a modular telecom gear:
- CPU boards, where typically the protocol layer is handled in SW
- FPGA boards, where all the heavy signal processing mainly on the lower ISO layers 1 and 2 is done (mainly the user plane)
- ASIC boards doing the same as FPGA boards but cheaper and with much lower power consumption.
Why are there FPGA boards and not ASIC everywhere, if ASIC is cheaper and uses less electricity? The main reason is flexibility and time to market. In the beginning of a new standard like 5G mobile, the standard changes often and new modulation techniques are explored. This can only be done with FPGA, as you need the raw HW performance a SW running on a CPU can never provide, but you need the flexibilty to „quickly“ change your HW design to adopt to new ideas and algorithms.
After the standard is mature and does not change anymore (like eg VDSL) you start to cost optimize your product; all your proven and working FPGA logic will be burnt into a highly specialized ASIC for mass production.
br
Jörg
> Am 02.05.2020 um 07:21 schrieb Chris Burrows <chris at cfbsoftware.com>:
>
>
>>
>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Skulski, Wojciech
>> Sent: Saturday, 2 May 2020 12:24 PM
>> To: ETH Oberon and related systems
>> Subject: Re: [Oberon] Development boards
>>
>> Peter asked:
>>
>>> Is hardware really an issue?
>>
>> Yes it is, especially when it is absent.
>>
>>> Is FPGA essential?
>>
>> It depends for what. In this group we are talking of a neat System-On-
>> Chip composed of the most standard peripherals (SPI, PS/2 driver, SRAM,
>> and video) driven with a neat and very simple 32 bit CPU capable of up to
>> 75 MHz. It is a small system. Why not replace it with ... (type the name
>> of your favorite) which is of course much better, cheaper, and more
>> popular (continue the list).
>>
>> However, the FPGAs can also be used differently. Our 32-channel digitizer
>> which we are developing at SkuTek is processing 32 parallel streams of
>> 14-bit samples collected at 100 MHz on each channel. The FPGA is
>> continuously processing 32*14*100 = 44,800 Mbits/s = 5,600 megabytes per
>> second. (Neglecting the subtle difference between MB and MiB.) There are
>> several dozens fixed operations in each channel for triggering, baseline
>> removal, feature detection, and waveform storage. All operations run in
>> parallel. The performance of this FPGA is staggering. And to impress you
>> even more, the FPGA costs about $2k per chip. Just the FPGA.
>>
>
> I am impressed.
>
> Ever since I first got my hands on an FPGA with Project Oberon I have been
> itching to spend more time to explore the full potential of these devices.
> Although the Artix-7 devices used in the Arty boards is not as pricey as
> yours (about $35 a chip) there is still a whole heap of unused functionality
> after the RISC5 CPU and peripherals have been installed. So far (with much
> appreciated help from Magnus and Paul) I have managed to add an I2C
> controller, and the minor mod to the CPU instruction set to enable efficient
> processing of CASE statements.
>
> Other simple experiments I am interested in doing include:
>
> * Modify the instruction set further to provide an autoincrement capability
> to Load and Store (as mentioned here recently)
> * Implement new instructions corresponding to ARM's REV, REV16, REVSH, and
> RBIT instructions. They reverse bytes or bits within words or halfwords. My
> understanding is that efficient versions of these are very useful in
> algorithms used in Cryptography.
>
> Those are just a couple of examples. The possibilities that RISC5 and these
> FPGAs give an embedded systems engineer are only limited by their
> imagination! I can foresee a great demand for engineers with such skills in
> the very near future - if not already,
>
> Regards,
> Chris Burrows
> CFB Software
> https://www.astrobe.com
>
>
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
More information about the Oberon
mailing list