Although the software radio (SDR) guidelines are "develop once, run anywhere", every time a hardware changes, all developments often have to start over. The industry has recognized that traditional development models based on text specifications have failed to meet the portability requirements of SDR hardware and software. This recognition has led to the creation of a new design approach for next generation communication radios. The method is based on a higher level abstract description, adopting the "model-based design" idea, and its core is based on the operability specification of "implementation-independent model (IIM)" and "specific implementation model (ISM)". The Joint Project Office (JPO) of the Joint Tactical Radio System (JTRS) has developed guidelines for the use of these operational specifications to maximize the potential of SDR.
The radios provided by SDR can be dynamically programmed to support different waveform standards, provide new features, improve system performance, and support new services. The current drivers of SDR development are mainly the US military, who want to implement the basic JTRS (Next Generation Communication System) on SDR. SDR will allow soldiers to communicate on a variety of communication systems and mimic the functionality of any radio with the addition of software. At the same time, an open and interoperable framework, especially defined by the Software Communications Architecture (SCA), can significantly reduce the cost of designing, deploying, and maintaining future radios. From the current point of view, due to the low cost advantage of SDR, many commercial wireless device manufacturers are gradually adopting the SDR architecture.
As an important branch of the JTRS project, SCA provides an open architecture framework that defines interoperability between various software and hardware. SCA also proposes a core framework (CF) designed to provide interoperability between different waveforms (similar to standards such as GSM and 802.11), which are used as commercial applications in commercial applications and can be downloaded to any supporting SCA. On the standard radio equipment.
Increased development complexityAlmost every major advance in communication technology poses a huge challenge for software and hardware design engineers, and SDR is no exception. Leading weapons contractors, electronic component suppliers and system integrators are currently developing next-generation SDRs and promise that new SDRs will revolutionize wireless communications, wireless devices will be interoperable, and new features will be added Software download to achieve.
Achieving communication between a wireless system and any waveform through a software program running on more flexible hardware would be a significant design challenge. In today's military or commercial wireless platforms, the hardware is optimized for waveforms, especially the RF portion is optimized for the narrow frequency band in which the radio operates. Moving from a dedicated design to a universal design will inevitably have an adverse impact on the system's real-time performance, power consumption and size.
Disadvantages of traditional design methodsSo far, most SDR design engineers have used traditional design methods: refine the specifications defined by the system architect into documentation, and use these documents to guide project teams focused on signal processing or RF engineering, and then define the hardware by these teams. Designing circuits, writing software, running simulations, testing, and generating large amounts of data that are used to verify that the final implementation results meet regulatory requirements.
An important issue with this approach is that many errors are often detected when all modules can be tested together during the prototype phase. If the prototype does not meet the specifications, the design engineer must determine whether the problem is due to system requirements, simulation models, interfaces, or target processors. Because the cost of solving problems increases as the size of the design increases, problems with the target processor will quickly increase development costs.
Key challenges of waveform portabilityAlthough these challenges are not easy to solve, they are much less difficult than the requirements of multi-target development. Every major development project must consider a variety of hardware options, including general purpose processors (GPPs), DSPs, FPGAs, and the choice of hardware is often determined until the development process reaches a certain stage. Even if the hardware has been selected, the design engineer must be prepared for hardware upgrades and form factor changes to completely change the direction of development, such as switching from DSP to FPGA. Traditional development methods are associated with specific hardware architectures, so in order to implement a new hardware platform, you must start over with the technical specifications.
Aware of the limitations of traditional design methods, the JTRS Joint Project Office proposed a new design approach. In this approach, the waveform specification is defined in an executable IIM (independent of the hardware specification) and one or more executable ISMs (related to the hardware specification). This approach has three advantages: First, IIM and ISM are single, explicit, and executable waveform specifications that can be shared between teams, departments, and contractors. Second, they provide a high-level design perspective for the system. Level analysis and trade-offs, and discover potential design and implementation errors; in the end, they reduce the cost of porting waveforms from one radio to another, while also supporting performance analysis, demand analysis tracking, and high-performance waveform design .
The IIM contains information that can be used to define, characterize, and verify waveform behavior. Waveform behavior can be verified and tracked to meet the requirements in the waveform requirements document. Waveform signal flow, control flow, and networking can be defined using information such as waveform subsystem boundaries, subsystem jitter, delay and timing requirements, subsystem processing requirements, and signal port sampling times. The executable IIM provides a test bench to verify that the waveform function modules or systems meet system requirements and verify their performance.
On the other hand, ISM reflects the details of the expected implementation when ported to a specific radio architecture. This model contains more information on assigning processing components to various processor resources, which allows design engineers to learn more about this implementation. It also includes a model of target processor execution time, latency, memory, and queue size, which allows waveform design engineers and subsequent porting efforts to understand the impact of resource changes at the system level, such as throughput, jitter, Delay, memory consumption, DC power and real-time performance.
Model-based design makes IIM and ISM a realityProven model-based design techniques include the IIM and ISM concepts. Unlike text-based methods (which rely on the interpretation of ever-changing design specification files), model-based design is based on the creation of block diagram executable specifications. Executable specifications eliminate design uncertainty and enable communication between the entire organization and customers, contractors, and suppliers. With model-based design, algorithm engineers, RF design engineers, software and hardware design engineers, and other development teams can collaborate to make design tradeoffs and evaluation scenarios that improve system performance and reduce costs.
The waveform's executable specification was originally defined at a high level, using pre-built elements and advanced algorithms, and includes other programmable languages ​​such as C, C++, Fortran, MATLAB, or HDL code. This specification is then executed to determine the performance that the algorithm or component in the current model can provide. By performing system behavior level simulations with different states, parameter values, and inputs, design engineers can quickly identify, isolate, and repair system design issues. Design engineers can quickly modify the design by adding, subtracting, or moving modules, or by changing parameters and immediately assessing the impact of these changes.
By simply changing parameters, design engineers can evaluate the impact of floating-point models (usually in the early stages of design) to fixed-point models. Fixed-point models are often used in the hardware implementation phase to reduce system size, memory, and power consumption.
In a text-based approach, the implementation of different components (whether hardware or software) is typically manually re-encoded, a process that is time consuming and error-prone. The model-based design consists of two models, IIM and ISM. The former consists of hardware-independent functional blocks, which are composed of modules optimized for specific hardware. As the development process evolves from the specification phase to the design, implementation, and validation of the overall system, the content of the model is more detailed, but it is always a single and clear representation of the system throughout the process.
While protecting design intellectual property, this model can be used to automatically generate code that can be used by many hardware platforms, including C code for GPP, C code and assembly code for DSP, and HDL for FPGAs. Code. The generation of automatic code can provide coding standards for the generated code, as the same construction can be used in every implementation. This approach eliminates manual coding errors and limits potential errors between the emulation code and the actual embedded code. Since the code can track the simulation directly, the error must occur during the execution of the interface or real-time constraints. Because these models are developed independently of embedded hardware, they can be easily ported to other platforms and reused in future systems.
Integrating test functionality into the model throughout the development process ensures design quality. Each model has a set of test vectors and a baseline of test results for each release. Constant verification and validation helps to identify problems early, making them easier and less expensive to solve. System-level models developed by system architects can be used in future design processes to validate the design from a system perspective, combined with actual simulation or test data.
Summary of this articleModel-based design is key in developing the development methods required for SDR. It supports automatic code generation and code portability on different hardware, software, and SCA core framework platforms. The SDR development process simplifies and is more efficient by establishing executable specifications, IIM and ISM models, and maintaining the traceability of the original waveform specifications to ensure continuous verification throughout the development process. Using this method to design and deploy SDR is simpler and more robust than traditional methods, thereby improving the performance and reliability of SDR systems and reducing design costs.
Ups Power Transformer,Computer Network System,Power Electronic Equipment,Power Transformer
SANON DOTRANSÂ Co., Ltd. , https://www.sntctransformer.com