Arm architecture is ruling the embedded world several years already. The combination of low power consumption, big performance, very good flexibility of available
offerings on the market make it choice No.1 for any new HW projects. It doesn't matter whether it will be IoT, pure embedded device or any other purpose built
device.
Communication interfaces, which are mostly used, changed with the evolution of the available platforms/SoCs. Starting initially with pure and simple RS-232, then
adding RS-422, RS-485, CAN, USB, Bluetooth, ZigBee, Wi-Fi and Ethernet.
The CPU performance of the Arm architecture not only allowed incorporating of
100Gb Ethernet controllers, but it also allowed for 1GB ethernet use, due to the ability to handle huge bandwidth. Having a big communication channel allowed the use of Arm in new territories.
We should also not forget that the constant development in the area of embedded systems communications moves the focus in industrial applications from CAN to Ethernet. This is valid not only for automation devices in manufacturing facilities, but also in automotive industry.
Now few words on how the Arm architecture is used in practice for embedded devices.
When we say Arm architecture, we mean the semiconductor design of various available Arm CPU cores. This design (again for specific Arm core(s)) can be purchased as Intellectual Property (IP). IP is a digital design file, describing the silicon chip.
Several silicon manufacturers use the Arm IP and manufacture Arm MCUs. These MCUs can be purchased and used in any new device design.
However, some of the companies design and produce their own proprietary silicon, which incorporates various IPs, so to provide specific functionality.
This proprietary silicon will include the Arm core/cores, memories, crypto engines, communication controllers, sensors, real-time clocks, etc.
If we focus on combining Arm functionality and Ethernet controller functionality, then at the end we will have either SoC or PCB, which will have Arm core(s) and Ethernet controller(s).
The Ethernet controller can be used for communication both in OS environment and barebone configuration. More simple designs use barebone software. If the device
is more complicated with more functionality then it usually uses Operating System (OS).A good example of such OS is FreeRTOS. Of course there are other lightweight OSs to chose from, both free and commercial. RTOS systems are made quite flexible and they can work with several available Internet Protocol stacks (this is the case with FreeRTOS mentioned above).
These stacks are designed in a way, so to allow easy integration with device drivers. Porting of existing barebone Ethernet controller driver to some OS's Internet Protocol stack may be an easy job, if the driver is wisely implemented.
If we are about to implement new Ethernet controller driver from scratch for barebone system, we need to carefully learn the Ethernet controller itself. This means to fully understand how it works and what control register it has. Having this done will allow to safely proceed with the implementation.
There are few tasks to be completed with regards to the controller:
1. Implement initialization procedure. It will set the proper configuration registers values, initialize/enable related interrupts (if any), so to allow the controller to function
properly.
2. Implement read data flow. In barebone environment this is usually a loop (even though it might run in interrupt mode), so to read all the data, which may have arrived to the controller's data pools. It involves transferring of the received packets into either the IP Stack buffers or some other user memory pools. Most frequently, the transfers are done via DMA controller of the ETH itself or some external one, for faster speed.
3. Implement write flow. This will be used to send packets. Again DMA is usually used for faster data transfers.
4. Last but not least - a comprehensive error handling and status reporting
Once the driver code is prepared we should make it running (debug it). In case we use PCB with Arm CPU and Ethernet controller on it, then we will follow the well known process of debugging the implementation with usual tools (JTAG debugger, other available debugger, logs, console prints, etc.).
What is more interesting to mention here is what is the process in case we work on proprietary silicon, which might even not be physically present/ready/produced at the moment. There are few options how to work in this case and all of them include software simulation of the entire IC. The developer prepares the binary codes, which in turn are run in simulated environment.
We should note that the above mentioned Arm and other IPs are actually descriptive files, written in Hardware Description Language (HDL). One commonly used standardized HDL is Verilog. There are many available Verilog simulators (both free and commercial), which can be used to simulate the IP design in development and fix both HW design issues and any SW bugs. The dedicated software is run on simulated IP in simulated environment.
Using Verilog simulation takes quite long time to execute even short program. This is due to complexity of the simulation and the huge amount of internal operations, which should be executed. Actually the simulated IP is recreated virtually from signals level up. This allows for very detailed level of examination in case of need for both HW and SW bugs.
As a conclusion we can say that the Verilog simulation is powerful, but slow way to debug software for still non-existing hardware.
There are two more options available to speed up this process.
First one is to use specifically programmed FPGA, which will mimic the functionality of the developed IP. It will execute the software faster, but itself needs
to be created/developed.
The second option is to use dedicated simulation cloud. In this case the simulation happens in a data center with powerful servers. Thus the execution of the simulation will be very fast. the downside is that such simulation cloud service is quite expensive and should be used wisely. An example of such service is Palladium simulation from Cadence Design Systems, Inc.
Being able to develop and debug the Ethernet driver in parallel to IP design cuts significantly the overall time for any new product to market.
Mina Soft provides outsourcing of driver development (and any needed software) in such simulated environments.
