HANDS-ON PROJECT: Lies, damn lies, and benchmarks: The race for the truth is on

With apologies to Benjamin Disraeli, his definition of the three kinds of lies applies as well to programmable-logic benchmarking as it does to statistics. This hands-on project takes a fresh look at quantifying programmable-logic-device capacity, efficiency, and performance.

By Brian Dipert, Technical Editor -- EDN, May 27, 1999

How many times have you pondered all the variables of designing with programmable logic and wondered if your design would fit into a particular device? The number of variables, after all, can be mind-boggling: gate count, types of logic circuits, types of memory circuits, ratio of logic to memory, silicon vendor's architecture, silicon vendor's device, design-entry method, software vendor's tool set, revision number of the tool set, and more. And, oh yeah, what if you use another vendor's device or tools instead? Further complicate the issue by specifying programmable-logic-device package and speed to get a more exact feel for the price you'll pay, and you've just summarized the dialogues I see posted dozens of times each week on Internet news group comp.arch.fpga. These are tough questions, and to date the programmable-logic manufacturers have made little constructive progress in making them easier to answer.

In the vendor's (brief) defense, the answers depend on numerous factors and change with each new revision of front- and back-end design tools, even if the device architecture remains constant. But the silicon companies, along with their software partners, have a vested interest in accentuating the positive attributes of their products and downplaying the ubiquitous trade-offs. This situation has negatively impacted all benchmarking efforts, creating more work for you. The comp.arch.fpga postings help spread the word, but even with the help of Web site DejaNews (www.dejanews.com), it's nearly impossible to keep up with—not to mention apply—all the discussion traffic.

I'd like to commend the programmable-logic vendors in Table 1 and Table 2, as well as synthesis vendor Synopsys, which agreed to participate in this benchmarking study. I based this study on the design in last year's "synthesis shoot-out" project (Reference 1 and Reference 2). Before I discuss this year's project in more detail, though, let's first consider why benchmarking is so difficult and why previous efforts have missed their mark.

Too many variables

The factors that impact your benchmarking results begin with your choice of design-entry method. It's a widely accepted fact that schematic-based designs are faster, smaller, and more efficient than synthesis-derived alternatives. Today's trend, however, is away from schematic entry and toward synthesis, because increasingly important time-to-market pressures and the desire for design reuse favor a synthesis-based approach. Synthesis results can approach those of schematics if the software does a good job of mapping the design to the target silicon architecture. Results will suffer, though, if the synthesis compiler instead creates a netlist comprising generic, low-level, ASIC logic elements and forces the back-end tools to reassemble them into the more coarsely grained programmable-logic-device structures.

Synthesis tools commonly import silicon-vendor-developed library files that they use for technology mapping. Occasionally, though, synthesis vendors themselves develop the libraries, such as with the Synopsys FPGA Express software that this study uses. This approach might produce better results, but the delay in developing support might also limit your vendor and device options. You can also help the synthesis process along by instantiating silicon-vendor-developed, predefined logic and memory components. However, this task unfortunately makes your source code less portable to other silicon architectures.

The synthesis compiler is only the first part of the design flow. Next, the task turns to the silicon-vendor-developed fitter (for CPLDs) or place-and-route software (for FPGAs). A good job of synthesis-technology mapping in the front end can greatly help the back-end tools; a bad job can be worse than no mapping at all. Back-end-tool developers must balance compilation results with speed. Depending on your computing-hardware capabilities and design practices, you may be unable to tolerate several-times-longer compiling in exchange for a slightly smaller or faster design.

Vendors put a great deal of focus on back-end software, especially as they gain a better understanding of their architectures' capabilities. When you upgrade to new versions of back-end tools, you may see dramatically better results. For example, in last year's synthesis shoot-out, I saw significant improvements in some cases when moving from Xilinx's Alliance Version 1.4 to Version 1.5 (Reference 3).

You can also have a big impact on the results. Most front- and back-end tools offer you at least coarse-granularity options, such as low-versus-high effort (a primary determinant of compilation time) and area-versus-speed priority, and some products provide a number of interim settings. You can also help—or sometimes hinder—the tool's ability to optimize by predefining pinout and required timings. Preserving or eliminating the design hierarchy, as the source files and their interconnection define it, gives unpredictable results. Therefore, you often need to run your design twice through the flow—first retaining the hierarchy and then purging it to see which does a better job.

In perhaps the most extreme example of user intervention, design consultants and other power users employ the common trick of manually placing portions of the design's circuitry on the chip with floorplanning software or source-code instantiations instead of relying on automatic placement algorithms. If the design contains a high percentage of datapath elements, the time you take for manual floorplanning can be well-spent. If the design has few datapath elements, it's usually better to just let the software have a crack at the design. As the automated placement algorithms get better with time, the need for manual floorplanning also diminishes.

Device dependencies

Next, consider the silicon. Focusing first on the logic structures themselves, product-term-rich CPLD architectures and register-abundant FPGA organizations reveal their strengths with different designs (Figure 1 and Figure 2). Advanced versions of both programmable-logic devices, using techniques such as variable-grain logic blocks, multiple levels of routing structures, and high macrocell counts, attempt to circumvent the differences between them. Perhaps the most radical example of the blending of CPLD and FPGA capabilities is Altera's (www.altera.com) Apex family (Figure 3). For more information on the primary differences between CPLDs and FPGAs, see References 4 to 7.

What about the routing between logic blocks? Advanced lithographies are not only shrinking transistors, but also allowing for more metal layers. Silicon vendors are taking advantage of this trend by increasing the amount and variety of on-chip intralogic- and interlogic-block interconnection in the hope that it won't be the limiting factor in your ability to fit your design into their parts. However, as transistor switching speeds continue to rise, routing delays increasingly define a circuit's performance, especially if it spans multiple logic blocks because of a less-than-perfect fit. The means by which vendors stitch together multiple routing traces can have an even more dramatic effect on the performance you see (Figure 4).

Choosing the right routing trace for each signal and appropriately allocating from the fixed number of variable-length resources a chip provides are key criteria not only for an FPGA's place-and-route software but also for both global- and hierarchical-matrixed CPLDs. To reduce routing delays, some companies, such as DynaChip (www.dyna.com) and Xilinx with its Virtex line, are integrating on-chip active repeaters analogous to the signal amplifiers that data-communications and telecommunications networks use.

On-chip memory is the most common embedded "core," found primarily in FPGAs but also present in a few differentiated CPLDs. Using embedded memory—for data buffers and, occasionally, for fast multipliers, complex state machines, and the like—is more efficient than the register-derived alternative. However, some designs can't use embedded memory: In these cases, it does nothing but waste precious silicon. A spectrum of embedded-memory approaches vies for your attention: from numerous small arrays derived from logic-block look-up tables to a few large discrete arrays. And some companies offer multiple memory alternatives on one chip (Figure 5). Embedded memory is more than just SRAM bits; the amount and type of dedicated periphery logic around each array can help or hinder your implementation of such structures as multiport RAMs, content-addressable memory, and FIFO buffers.

Now, consider the host of secondary, usually vendor-proprietary device features. For CPLDs, these features include more robust switching matrices, wider per-logic-block signal fan-in, enhanced macrocell register configurability, and even supplemental product-term PLAs. FPGAs have their share of enhancements, as well: AND gates for fast multipliers, carry chains, digital-delay-locked loops, PLLs, and more. And both CPLDs and FPGAs offer internal three-state buffers and a variety of I/O-buffer structures, some with their own optional registers, others with extensive flexibility in the electrical interfaces they can implement, and most with user-configurable slew rates.

Just as with embedded memory, these secondary enhancements are often a superior alternative to using generic on- or off-chip logic resources to implement the same circuit, but only if you require them. If a benchmark circuit needs these resources, if the chip provides them, and if the design software enables them, the chip's benchmark results positively reflect the synergy. If any item in this chain is missing, though, the benchmark doesn't reflect these features' presence.

Vendor-developed benchmarks

As long as programmable-logic vendors have existed, so too have their self-published benchmarks. These benchmarks frequently take the form of a list of circuits, such as n-input counters, n-bit adders, and the like; some measure of performance, such as maximum clock frequency and input-to-output propagation delay; plus the number of logic blocks consumed or some other metric of design size and efficiency. Sometimes, the vendor even "graciously" provides equivalent specifications for the same circuits implemented in competitors' devices. Are these data sets useful? Well, not really. Granted, they do provide a measure of the "raw" silicon performance and usability. However, numerous factors combine to make vendor-published numbers a less-than-comprehensive means of comparing various devices.

First, you should check to see what design-entry method the vendor used: synthesis, schematic, or a handcrafted netlist (analogous to a machine-language-coded software program). Even with a VHDL- or Verilog-sourced circuit, the vendor may have heavily influenced compilation by defining pinout and timing, manually floorplanning, and determining other parameters. Are the counter's registers located directly adjacent to the input and output pins, and how does performance change as the circuit moves elsewhere and routing delay becomes a factor?

Xilinx, for example, gave a demonstration at February's Association for Computing Machinery FPGA conference in Monterey, CA. The demonstration showed a frequency-counter circuit operating at greater-than-1-GHz toggle rates. This speed is an impressive testimonial to how far FPGA technology has progressed in the last several years. However, the circuit was functionally simple and happened to be on one side of the die, directly next to relevant device inputs and outputs. Toggle frequencies on circuits containing only one or a few registers provide limited correlation to the performance you'll see using the device on real-life designs.

Face it: The vendors know their silicon better than you do and more than you should be expected to. They also have the luxury of a comparatively infinite amount of time to handcraft the design and rerun multiple configuration scenarios to create the best results. Without a full set of timing specifications, performance numbers may be essentially meaningless. What good is it to know how fast a counter clocks if you don't know what the input setup-and-hold requirements and clock-to-output delays are?

If the vendor does an us-versus-them comparison, even further tighten your skeptic's hat. Did the vendor just happen to pick a set of circuits that fit nicely into its logic-block structure and poorly into the other guy's alternative? Or did the company exploit some proprietary secondary feature that your designs will never use? Is the vendor comparing its latest and greatest state-of-the-art device with a competitor's several-generations-older alternative? And you cannot realistically expect any programmable-logic vendor to know how or to want to optimize its competitors' design tools as well as its own.

Industry-developed benchmarks

Partially in response to widespread customer skepticism of vendor-published benchmarks, which nevertheless continue to exist to this day, a group of programmable-logic vendors in 1991 formed the Programmable Electronics Performance (PREP) Corp; independent consultant Stan Baker oversaw the proceedings. PREP has now disbanded. (Ironically, the Web site, www.prep.org, shut down just as I submitted the first draft of this article.) PREP nevertheless deserves some explanation. I used PREP as a case study of both what to do and what not to do as I planned my own benchmarking project.

PREP's goals were laudable: to create a meaningful, unbiased set of tests that would measure gate count, usablegate count, and speed of various architectures and devices. Almost every programmable-logic manufacturer had at least one spokesperson who attended PREP meetings, representing product lines that spanned from several-dozen-macrocell simple PLDs to several-tens-of-thousands-of-gates FPGAs. Inherent in that diversity was PREP's first roadblock.

One of the guiding principles of PREP was that all reference circuits must fit into all devices from all manufacturers. As a result, each circuit ended up being small. Examples included 8-bit counters, 13-transition state machines, and 4-bit multiply/accumulators. The objective of the PREP exercise was to "step and repeat"—put multiple iterations of a designed logic circuit onto one die—as many copies of a circuit into a chip as possible, often routing one iteration's outputs into the next iteration's inputs. Aside from the fact that the logic structures thus created didn't represent meaningful real-life circuits, they didn't heavily stress the on-chip signal-routing networks.

Vendors that put proprietary features on their devices weren't happy with the "generic" nature of the PREP benchmark circuits, which didn't allow the vendors to use these features and thereby differentiate themselves. To determine performance, the vendors measured the maximum internal and external clock frequencies of the logic structure after each circuit iteration and then published the best, worst, and average of these numbers. With nine PREP circuits, for example, this approach resulted in 27 performance specifications for each device, package, and speed combination, plus a corresponding set of numbers for implemented design size and efficiency.

It's probably no surprise, therefore, to hear that "specsmanship" reared its ugly head. To "simplify" the PREP results provided to potential customers, some companies averaged the numbers into a smaller set but in a way that was incompatible with their competitors. Other companies printed only some of the numbers—invariably, those that made them look good. Design-entry methods were inconsistent among the vendors, and it's difficult to imagine that typical time-, knowledge-, and funding-constrained systems engineers trying to use one of the chips could replicate the results obtained by silicon engineers, who have copious amounts of time, money, and architecture knowledge at their fingertips.

The last straw for PREP occurred when at least one vendor, followed begrudgingly by the rest, found a loophole in the PREP specifications. This loophole meant that the vendors did not have to entirely step and repeat one of the circuits but instead shared a portion of one circuit iteration among all copies of the remainder. This approach violated the spirit of PREP, regardless of what the specification said, and it bitterly divided the group. If outside consultants, EDA companies, or end users had taken a more active role in PREP, perhaps it wouldn't have dissolved. Unfortunately, the silicon vendors couldn't manage to get along without strong external pressure, a scenario that often occurs in standards bodies.

A number of consultants have commented that, although the PREP numbers for each device were themselves not very meaningful, they had some comparative value when evaluated against similarly derived numbers for other devices from other manufacturers. Even with the PREP Web site offline, you still might occasionally stumble across a set of archived PREP results, although probably not on any devices announced after 1994. PREP broke new ground in the world of programmable-logic benchmarking, the organization comprised a lot of sharp people, and the founders' objectives were admirable. Unfortunately, they couldn't subdue their competitive juices long enough to complete their work.

My turn

In last year's Hands-On project, consultant Stephen Wasson and I defined a large but modular reference design containing a mix of logic and memory circuits, which I implemented in VHDL. I used this design and its subsets to benchmark three synthesis compilers, keeping the silicon platform (the Xilinx XC-4085XL), and therefore the back-end tool set (Alliance 1.4), constant in all cases. This time, I turned the project around, keeping the synthesis tool constant and varying the target programmable-logic devices and corresponding back-end tools.

To find out whether they would participate, I contacted silicon vendors Actel (www.actel.com), Altera, Atmel, Cypress Semiconductor (www.cypress.com), DynaChip, Lattice Semiconductor, Lucent Technologies, Philips, QuickLogic (www.quicklogic.com), Vantis, and Xilinx. I also contacted synthesis vendors Accolade Design Automation (www.acc-eda.com), Mentor Graphics subsidiary Exemplar Logic (www.exemplar.com), Synopsys, and Synplicity (www.synplicity.com).

Many companies include statements in their licensing agreements precluding publication of testing results without the vendor's permission, and I didn't feel like tangling with a bunch of lawyers, so I needed to obtain each company's consent to include them in the study. Programmable-logic manufacturers had access to last year's design files, which I planned to reuse this year, and they could select the device, package, and speed that I'd use. I didn't require that the device be available for sampling at press time, although I insisted that support for the device must exist in publicly available design-software versions. I also had no objection to running beta code but required that this software be released no later than 19990527.

Just as they did in last year's synthesis-shoot-out project, Exemplar Logic and Synplicity both passed on my offer to act as the common synthesis front end this year. In both cases, they didn't want to damage relationships with any of their programmable-logic partners if the results favored one company over another. Both Accolade and Synopsys were interested, however. I decided to go with Synopsys' FPGA Express version 3.12 because my newsgroup research indicates that it is a commonly used tool, because of my positive experiences with it in last year's study, and because it supports a range of devices. However, I'd like to rerun this project in the future using Accolade's tool set for a comparative set of data points. Altera and QuickLogic also declined to participate.

"There is a bit of a strong flinch reaction here to benchmarking efforts," said a company spokesman for Altera, also noting that the company had a busy year planned and was concerned that it might be unable to provide sufficient technical support. QuickLogic's reason for declining was that the logic and routing inefficiencies that a synthesis-based design causes would not sufficiently highlight the advantages of its antifuse-based FPGAs. I found QuickLogic's response strange because the company was one of the earliest and remains one of the most vigorous advocates of synthesis techniques in FPGA-targeted design.

The reason that I chose synthesis and VHDL in particular was that I believe one of the biggest shortcomings of PREP was that neither the design-entry method nor the design tools were standardized or extensively documented, making comparison of the results somewhat meaningless. Although plenty of you still design with schematics, vendor-proprietary languages such as Altera HDL, and other early high-level languages, such as Abel, Cupl, and Palasm, the general trend seems to be toward second-generation HDLs. My overall perception is that VHDL is more commonly used than Verilog for programmable logic, although this trend is shifting as more ASIC designers use high-density FPGAs and also depends on geographic region and company.

Even without Altera and QuickLogic, nine programmable-logic vendors had signed up by the end of January. Unfortunately, within a few weeks, the ranks were further depleted. Cypress Semiconductor withdrew after running the designs and realizing that it could fit only a limited percentage of them with the company's Ultra37000 product line (see sidebar "Interpreting the results"). Also, FPGA Express didn't support Actel's ProASICs, which Gatefield (www.gatefield.com) developed, or DynaChip's DY6000 FPGAs, and Synopsys couldn't add support for either of them in time for my deadlines.

Neither Actel nor DynaChip wanted me to evaluate a previous-generation device for which support existed, and I didn't want to break my "single-synthesis-tool" rule by using Synopsys' Design Compiler, which accepts silicon-vendor-developed libraries, instead of using FPGA Express' Synopsys-developed approach. As a result, you won't find numbers for Actel or DynaChip this time. Both vendors plan to run their own tests of my reference designs using Design Compiler, so check their Web sites. I hope to include Actel and DynaChip—as well as Altera, Cypress, and QuickLogic if they change their minds—in a future study, once the support issues are resolved.

Cypress' feedback brings up another set of differences between my study and the PREP benchmarks. As mentioned, at least one iteration of each PREP circuit had to fit into all vendors' devices, no matter how small. In contrast, my fully compiled reference design last year ranged from a bit more than 20,000 gates to almost 55,000 gates, depending on the synthesis tool and method of implementing the on-chip FIFO buffers. However, I've also compiled 14 subsets of the design as small as a few thousand gates and requiring only a few dozen registers. I encourage you to check either last year's articles or the Addendum for more information on the design, including detailed specifications in several file formats (see sidebar "Don't miss the Addendum").

Some design modules predominantly contain product-term logic, such as counters and state machines, whereas others predominantly contain arithmetic and datapath logic. Some designs use two 32X16-bit bidirectional FIFO buffers, constructed using registers for all vendors and using embedded memory if a device offers this feature. I compiled each vendor's designs in four ways, varying low-versus-high effort and area-versus-speed optimization in FPGA Express and making corresponding settings in the back-end tools when available.

I attempted to represent both the beginner (or the engineer designing with multiple vendors' devices and tools) and the experienced power user. I didn't attempt to constrain pinout or timing or to manually floorplan circuit locations. With my source code, I intentionally avoided making any of the architecture-specific optimizations the vendors recommend in their documentation.

After I turned over my testing results to the corresponding vendors, it was their turn to do optimization work, acting as power users. Vendors can employ two phases for this project. In the first phase, they must use the same target device, speed, package, and synthesis compiler—FPGA Express—that I did, although they can run upgrades of both the front- and back-end tools as long as they'll be publicly released at press time. They also can't modify my VHDL source code.

The list of what the vendors can do in this phase, though, gives them some innovation opportunity. They can guide the tools' automated algorithms with timing and pinout constraints and external attribute files. They can employ any of the documented tool settings, not just the rudimentary low-versus-high-effort and area-versus-speed variables. They can also override the fitter or place-and-route software with manual floorplanning of some or all of the design circuits.

The second phase of the vendors' optimization work includes all of the phase-one options, plus several potentially valuable additions. First, they can add vendor-specific attributes and alter the style of my VHDL coding as long as they don't change the circuits' functions. Without a robust set of simulation test vectors, I have to take their word for accepting this restriction. Second, they can use any synthesis compiler, as long as they obtain publication permission from the compiler vendor. For both phases, I require that the vendors provide not only their results but also a full set of tool-report files and an explanation of everything they did to obtain the results, so that, if necessary, I can duplicate their efforts.

Status and plans

I submitted the first draft of this article in late March. By then, I had obtained a loaner 450-MHz Pentium II with 256 Mbytes of synchronous DRAM from Intel (www.intel.com) and had installed all the necessary software and circumvented a few licensing problems. Just as I found last year, Windows 98 is surprisingly stable: I had no system crashes even when continuously running compilation sessions for several days. I had also modified last year's versions of the design files that instantiate RAM components, which were intended for Xilinx XC4000XL devices, to accommodate this year's participants.

Instead of manually clicking through the graphical-user-interface-based tool interfaces a few thousand times, I automated the design flow with scripts and batch files. This task necessitated that I learn Synopsys' FPGA Scripting Tool and tool-command language. I'm now generating netlists for five of the six vendors and suspect that a license file incompatibility is behind the last set of errors I've seen.

Most of the programmable-logic vendors claim that I can also script-operate their tools or run them from a set of DOS commands in a batch file. Assuming that I have no major problems getting this part of the design flow to work, I should be able to get the vendors my results on their devices (but not on their competitors' parts) within a month. This time frame leaves them several weeks for their optimization work, and everything should be in the Addendum by the time you read this.

Although I—not the vendors—defined this project, I polled them for suggestions and received valuable feedback that I included in the final plan. I'm anxious to see the vendors' optimized results, because I can think of several potential enhancements they could attempt that might significantly improve their results. Fine-tuning the timing constraints is one obvious activity.

By modifying the syntax of logic equations, it's sometimes possible to guide the compiler in cleanly mapping them to a given-sized logic-block structure. CPLDs can benefit from explicitly defined state values and modifications to the allowable maximum number of product terms allocated to each macrocell. One-hot state-machine encoding techniques tend to produce faster, more efficient results in FPGAs. The X1 and X2 transforms and the FIFOs are prime candidates for floorplanning or, minimally, defining the pinout to guide the data flow through the device. The front- and back-end tools contain a number of configuration options that I didn't set to values other than their defaults.

Finally, the front-end 32X16 FIFO buffer actually comprises four unidirectional 16X16 dual-port RAMs, because I converted the 32-bit host bus to a 16-bit internal bus, and, last year, I couldn't run each of the two ports in the instantiated RAM component at a different clock frequency. If one or more of this year's RAM components supports a X32 bus width and can operate under multiple clocks and if the vendors appropriately modify my design, the result could be significantly lower on-chip logic and memory usage.

I'd appreciate your feedback on this project. I hope to repeat this study on a regular basis and want to make sure it meets your needs. Whether positive or negative, your comments will undoubtedly be constructive, and I'd welcome a quick e-mail with your thoughts.

Table 1—Participating CPLD manufacturers and devices

Table 2—Participating FPGA manufacturers and devices

Author info

You can reach Technical Editor Brian Dipert at 1-916-454-5242, fax 1-916-454-5101, e-mail bdipert@pacbell.net.

1. Dipert, Brian, "Synthesis shoot-out at the EDN corral," EDN, Sept 11, 1998, pg 95.

2. Dipert, Brian, "Getting a handle on HDLs," EDN, May 7, 1998, pg 71.

3. "1998 Programmable-Logic Hands-On Project Addendum."

4. Dipert, Brian, "Counting on gate counts? Don't count on it,'' EDN, Aug 3, 1998, pg 52.

5. Dipert, Brian, "Moving beyond programmable logic: if, when, how?,'' EDN, Nov 20, 1997, pg 77.

6. Dipert, Brian, "Programmable logic: Beat the heat on power consumption,'' EDN, Aug 1, 1997, pg 57.

7. Dipert, Brian, "Shattering the programmable-logic speed barrier,'' EDN, May 22, 1997, pg 36.

ACKNOWLEDGMENT

Thanks to the following company representatives for their assistance during this project: Wendy Lockhart and Joseph Martinez from Atmel; Bertrand Leigh and Tim Schnettler from Lattice Semiconductor; Barry Britton and Curt Lansendorfer from Lucent Technologies; Reno Sanchez, Lester Sanders, and Chris Schnell from Philips; Alan Ma and Jackie Patterson from Synopsys; Gordon Hands and Jerry Long from Vantis; and Loren Lacy from Xilinx.

Talkback

We would love your feedback!

Post a comment

» View All Talkback Threads

• Resource Center
• Browse Categories
• Browse Companies

Featured Company

• Rohde & Schwarz

  

  Rohde & Schwarz is an independent group of companies specializing in electronics. It is a leading supplier of solutions in the fields of test and measurement, broadcasting, radiomonitoring and radiolocation, as well as secure communications... more

• Agilent Technologies

  Agilent Technologies Inc. (NYSE: A) is the world's premier measurement company and a technology leader in communications, electronics, life sciences and chemical analysis... more

---

Most Recent Resources

• Atmel's QTouch Library 2.0
• The Impact of Digital Oscilloscope Blind Time on Your Measurements
• LTE-Advanced Technology Introduction
• FREE Webcast: Demystifying TD-LTE: A separation from LTE FDD
• Near Field Communication (NFC) Technology and Measurements