AWR eBooks

Best Practices for Efficient and Effective Planar EM Simulation 19 www.cadence.com/go/awr Best Practice Tip #9: The AWR AXIEM simulator can be set to use various available computer resources. Understand how to set the number of cores, simulation priority, and remote simulation options, if available. The designer has control over how the AWR AXIEM simulator uses resources on the computer and can even use computers on remote machines. A modern computer has one or more central processing units (CPUs). A typical CPU is, in turn, composed of multiple cores, which can function as independent processing units. For example, an engineer's laptop has four physical cores. The AWR AXIEM simulator can take advantage of all of these cores; the software is written to parallelize its numerical computations where possible. This can occur in the matrix fill and solve, as well as the frequency sweeping in AFS. The speedup is never perfect, of course; ideally, it would be four times as fast for a four-core machine, but in reality, a more typical number is 3.2. Eight cores provide about a 5.6 speedup and beyond eight cores, there is little speedup for typical cases. There also is the concept of a thread in computing. A thread is a program carrying out a sequential group of instructions and using a block of memory. A single physical core can run multiple threads if the computer is set for hyperthreading (hyper- threading is hardware dependent and set up at the computer's system level outside of AWR Microwave Office software). To see if a Microsoft Windows machine is set for hyperthreading, look at the resource monitor under the performance monitor of the task manager. This shows the number of virtual processors on the machine. For example, if hyperthreaded for 2X is set, twice as many logical core graphs will be seen as the physical cores on the machine. A physical core might run two threads concurrently, which means two jobs are being processed at the same time. Whether this results in a faster simulation depends on how the code is written. At some point, running many threads on one core will slow the machine down, as the core must switch from one job to another, resulting in a state called "thrashing." For the AWR AXIEM simulator, two threads will run a job twice as fast as one thread. In the case of the AWR Analyst simulator, performance is not affected by using hyperthreading; it does speed up when multiple physical cores are used. Beyond that, the machine slows down. So, the optimal setting for AWR AXIEM software is two threads per physical core, and a maximum of eight cores. The job scheduler menu under the options settings of the EM structure can control how the simulator uses the computational resources of the machine. The Max Threads Per Job setting controls how many of the cores the simulator can use. With the computer set to two threads per core (set in the OS) there are eight threads on a four-core machine available. Usually, this number is set to 0, where "0" means use everything available. In this example, eight threads would run on four cores. Notice that the number of threads that can be run is also limited by the license. A single AWR AXIEM license can run up to eight threads. The AWR AXIEM simulator can also be set up to run remotely on other machines. In this scenario, a system administrator sets up a machine on the local network to be the job server machine. Depending on how the network is set up, the job server machine then decides which remote machine will simulate an AWR AXIEM job. A network can be as simple as one remote machine or as complicated as several computer nodes of varying degrees of computational power and memory availability. The job server machine can be set up to know if a machine is considered "fast" or has a large amount of memory. The designer sets up the job preferences under the Job Scheduler tab in the EM project options. Typical options include whether the job should only be run locally, or remotely, and whether any machine can be used or only one with high performance or a large amount of random access memory (RAM). When the simulate button is pressed, the job scheduler sends the job out to the appropriate machine and when completed, the results are returned to the local machine. A designer can run several concurrent AWR AXIEM jobs in this manner, with the caveat that each remote machine will take an AWR AXIEM license. Obviously, the site must have enough licenses available if all the jobs are to run at the same time. EM extraction cannot take advantage of remote simulation as it is run synchronously. There is no concept of an independent process, and therefore no way to ship the EM simulation to a remote machine. Best Practice Tip #10: Check results with the passivity and energy measurements. There is no rigorous, mathematical way to know for sure if an AWR AXIEM result is correct. There is no substitute for engineering experience, comparing to experimental measurements if possible, comparing to modeled results, or other methods. The designer should start with problems that have known answers and build up to more complicated geometries. For example, start with one or two lines, and see if things are making sense. There are two quick measurements, passivity and energy conservation (or the sum of powers), that can be used on any S-parameter file. They will not tell the designer if an answer is correct, but they can indicate if there are problems or at least if the answer makes some physical sense. Both measurements are under the Linear Measurements section of the built-in measurements. They should not be used with adB scale. If an S-parameter file is passive, the structure it represents cannot generate energy. An amplifier, in contrast, has a non-passive S-parameter matrix. EM simulation results should be passive, as non-passive S-parameters mean the data are not physical. For example, the software could have a bad calibration or the AFS sweep algorithm could be failing.

• Cover