Forgot login?   Register
  Subscribe to Defense Tech Briefs  
  • Home
  • News
  • Features
  • Tech Briefs
  • Videos
  • Products
  • Events
  • eZines

Meeting the Demand for Complex Communications Design

Thursday, April 01 2010

Page 1 of 2

Communications engineers today must design to accommodate changing missions, shorter product lifecycles, and increasing computer power. As a result, they create hybrid systems that include RF, high-speed signal processing, lower-speed signal processing, and controls logic and control systems.

Figure 1. Top-level view of a GPS system, including transmitter with timing error, channel model withDoppler frequency shift, and receiver with timing and Doppler recovery loops. The model containsnumerous levels of hierarchy.
Figure 1. Top-level view of a GPS system, including transmitter with timing error, channel model withDoppler frequency shift, and receiver with timing and Doppler recovery loops. The model containsnumerous levels of hierarchy.
In the initial stages of the design process, it is often unclear whether to use analog or digital components, and what portion of a design should be implemented in software or hardware. System designers and implementers make their best guess on how to partition the design, which might result in sub-optimal designs and system performance. Typically, it is only near the end of the design process that the system designers and implementers can know whether their initial guess meets system performance requirements. If it doesn’t, significant rework needs to be done, which leads to cost and time overruns on the project. To address these challenges earlier in the design process, communications engineers have adopted Model-Based Design.

With Model-Based Design, engineers develop an executable model, often referred to as an executable specification, which is independent of the implementation. Within this model, design and system engineers can develop, test, and partition the design prior to implementation and integration. This approach enables them to find errors early in the process, when errors are easier and less expensive to fix.

Often the initial algorithm is developed in floating point using textual-based languages such as MATLAB or C/C++. Example tasks could include designing filter cascades for digital up/down conversion or developing carrier tracking loops. The algorithm engineer focuses on verifying that the signal processing algorithm meets the design objectives, such as fitting the system response within a specified frequency mask or tracking expected Doppler profiles.

After testing the algorithm, the model can be further elaborated with the implementation details, and the system performance can be verified against the design objectives with the additional implementation details. For example, if the target for the algorithm is a field-programmable gate array (FPGA), then fixed-point details must be added to the model, and system performance must be assessed to confirm that objectives are still met. Also at this stage, the effect of introducing non-ideal component performance to the system model can be assessed. For example, RF amplifier behavior can be added to the model using measured S-parameter data. Typically, RF amplifier behavior is modeled and analyzed in the frequency domain, while the communications algorithm is developed in the complex-time domain. By combining these models into a common executable modeling environment, system-level behavior and performance metrics such as bit-error rate (BER) can be determined.

When the algorithm elaboration is complete and the system-level performance is verified in the model, testing can be done on the host with different implementation languages to uncover errors introduced in the implementation. For example, if part of the algorithm is partitioned for low-speed signal processing on a DSP, the implementation of the algorithm will be C/C++. In this case, engineers can use automatic code generation to rapidly create a prototype implementation that can be tested in the modeling environment with the same test vectors used to verify the model performance. Similarly, if the target is a high-speed implementation on an ASIC or FPGA, then automatic code generation can be used to create an HDL implementation that can be tested within Simulink and an EDA simulator, such as ModelSim from Mentor Graphics, Incisive from Cadence, or Discovery from Synopsis.


«StartPrev12NextEnd»

Topics

  • Alternative Fuels
  • Biomass
  • Energy Storage
  • Geothermal Power
  • Government Initiatives
  • Energy Efficiency
  • Renewable Energy
  • Environmental Monitoring
  • Remediation Technologies
  • Solar Power
  • Wind Power
  • Transportation
  • LEDs/Lighting
  • Batteries
  • Hydrogen
  • Thermoelectrics
  • Hydropower
  • Recycling
  • Carbon Dioxide
  • Energy Harvesting
  • Smart Grid
  • Waste-to-Energy

Most Popular

  1. Paintable Solar Cells
  2. Introducing the First Solar & Wind e-zine
  3. Batteries Made From Ordinary Paper
  4. Process Cleans Wastewater, Generates Electricity, Desalinates Seawater
  5. Bacteria Turns Carbon Dioxide Into Liquid Fuel
  6. New Nano-Material Could Revolutionize Solar Panels and Batteries
  7. Using Plastics to Make Solar Cells More Cost-Effective
  8. New Pathway to Forming Hydrogen Storage Compounds
  9. Generating Hydrogen from Water

Featured Video

A new lab at the National Institute of Standards and Technology (NIST) is dedicated to improving the quality of light that LEDs produce. Take a look inside the lab in this video.
Read More >>

© 2009-2010 Tech Briefs Media Group

  • About
  • Contact
  • Advertising
  • Privacy
  • Defense Tech Briefs
  • Embedded Technology
  • NASA Tech Briefs