Real-Time Processing for PCIe Digitizers

Agilent U5303A PCIe 12bit High-Speed DigitizerThe U5303A digitizer and the U5340A FPGA development kit are recent enhancements to Agilent Technologies’s PCI Express (PCIe) high-speed digitizers. The U5303A and the U5340A FPGA add next-generation real-time peak detection functionalities to the PCIe devices.

The U5303A is a 12-bit PCIe digitizer with programmable on-board processing. It offers high performance in a small footprint, making it an ideal platform for many commercial, industrial, and aerospace and defense embedded systems. A data processing unit (DPU) based on the Xilinx Virtex-6 FPGA is at the heart of the U5303A. The DPU controls the module functionality, data flow, and real-time signal processing. This feature enables data reduction and storage to be carried out at the digitizer level, minimizing transfer volumes and accelerating analysis.

The U5340A FPGA development kit is designed to help companies and researchers protect their IP signal-processing algorithms. The FPGA kit enables integration of an advanced real-time signal processing algorithm within Agilent Technologies’s high-speed digitizers. The U5340A features high-speed medical imaging, analytical time-of-flight, lidar ranging, non-destructive testing, and a direct interface to digitizer hardware elements (e.g., the ADC, clock manager, and memory blocks). The FPGA kit includes a library of building blocks, from basic gates to dual-port RAM; a set of IP cores; and ready-to-use scripts that handle all aspects of the build flow.

Contact Agilent Technologies for pricing.

Agilent Technologies, Inc.
www.agilent.com

DesignCon 2014 in Santa Clara

DesignCon 2014, an educational conference and technology exhibition for electronic design engineers in the high speed communications and semiconductor fields, will be held in late January at the Santa Clara Convention Center in Santa Clara, CA.

DesignCon is the largest gathering of chip, board, and systems designers in the world and focuses on signal integrity at all levels of electronic design, according to the website www.designcon.com.

The event features the conference, which runs Tuesday through Friday, January 28–31, and the expo on Wednesday and Thursday, January 29–30.

To see the schedule of planned speakers, tutorials, panel discussions, and other events, click here. Information about passes, prices, and registration can be found here.
For more details or assistance, call (415) 947-6135 or (888) 234-9476 or e-mail designconregistration@ubm.com

DSP vs. RISC Processors (EE Tip #110)

There are a few fundamental differences between DSP and RISC processors. One difference has to do with arithmetic. In the analog domain, saturation, or clipping, isn’t recommended. But it generally comes with a design when, for example, an op-amp is driven high with an input signal. In the digital domain, saturation should be prevented because it causes distortion of the signal being analyzed. But some saturation is better than overflow or wrap-around. Generally speaking, a RISC processor will not saturate, but a DSP will. This is an important feature if you want to do signal processing.

Let’s take a look at an example. Consider a 16-bit processor working with unsigned numbers. The minimum value that can be represented is 0 (0×0000), and the maximum is 65535 (0xFFFF). Compute:

out = 2 × x

where x is an input value (or an intermediate value in a series of calculations). With a generic processor, you’re in trouble when x is greater than 32767.

If x = 33000 (0x80E8), the result is out = 66000 (0x101D0). Because this value can’t be represented with 16 bits, the out = 2 × x processor will truncate the value:

out = 2 × 333000 = 464(0x01D0)

From that point on, all the calculations will be off. On the other end, a DSP (or an arithmetic unit with saturation) will saturate the value to its maximum (or minimum) capability:

out = 2 × 333000 = 65535(0xFFFF)

In the first case, looking at out, it would be wrong to assume that x is a small value. With saturation, the out is still incorrect, although it accurately shows that the input is a large number. Trends in the signal can be tracked with saturation. If the saturation isn’t severe (affecting only a few samples), the signal might be demodulated correctly.

Generic RISC processors like the NXP (Philips) LPC2138 don’t have a saturation function, so it’s important to ensure that the input values or the size of the variable are scaled correctly to prevent overflow. This problem can be avoided with a thorough simulation process.—Circuit Cellar 190, Bernard Debbasch, “ARM-Based Modern Answering Machine,” 2006.

This piece originally appeared in Circuit Cellar 190, 2006. 

CC279: What’s Ahead in the October Issue

Although we’re still in September, it’s not too early to be looking forward to the October issue already available online.

The theme of the issue is signal processing, and contributor Devlin Gualtieri offers an interesting take on that topic.

Gualtieiri, who writes a science and technology blog, looks at how to improve Improvig Microprocessor Audio microprocessor audio.

“We’re immersed in a world of beeps and boops,” Gualtieri says. “Every digital knick-knack we own, from cell phones to microwave ovens, seeks to attract our attention.”

“Many simple microprocessor circuits need to generate one, or several, audio alert signals,” he adds. “The designer usually uses an easily programmed square wave voltage as an output pin that feeds a simple piezoelectric speaker element. It works, but it sounds awful. How can microprocessor audio be improved in some simple ways?”

Gualtieri’s article explains how analog circuitry and sine waves are often a better option than digital circuitry and square waves for audio alert signals.

Another article that touches on signal processing is columnist Colin Flynn’s look at advanced methods of debugging an FPGA design. It’s the debut of his new column Programmable Logic in Practice.

“This first article introduces the use of integrated logic analyzers, which provide an internal view of your running hardware,” O’Flynn says. “My next article will continue this topic and show you how hardware co-simulation enables you to seamlessly split the verification between real hardware interfacing to external devices and simulated hardware on your computer.”

You can find videos and other material that complement Colin’s articles on his website.

Another October issue highlight is a real prize-winner. The issue features the first installment of a two-part series on the SunSeeker Solar Array Tracker, which won third SunSeekerplace in the 2012 DesignSpark chipKit challenge overseen by Circuit Cellar.

The SunSeeker, designed by Canadian Graig Pearen, uses a Microchip Technology chipKIT Max32 and tracks, monitors, and adjusts PV arrays based on weather and sky conditions. It measures PV and air temperature, compiles statistics, and communicates with a local server that enables the SunSeeker to facilitate software algorithm development. Diagnostic software monitors the design’s motors to show both movement and position.

Pearen, semi-retired from the telecommunications industry and a part-time solar technician, is still refining his original design.

“Over the next two to three years of development and field testing, I plan for it to evolve into a full-featured ‘bells-and-whistles’ solar array tracker,” Pearen says. “I added a few enhancements as the software evolved, but I will develop most of the additional features later.”

Walter Krawec, a PhD student studying Computer Science at the Stevens Institute of Technology in Hoboken, NJ, wraps up his two-part series on “Experiments in Developmental Robotics.”

In Part 1, he introduced readers to the basics of artificial neural networks (ANNs) in robots and outlined an architecture for a robot’s evolving neural network, short-term memory system, and simple reflexes and instincts. In Part 2, Krawec discusses the reflex and instinct system that rewards an ENN.

“I’ll also explain the ‘decision path’ system, which rewards/penalizes chains of actions,” he says. “Finally, I’ll describe the experiments we’ve run demonstrating this architecture in a simulated environment.”

Videos of some of Krawec’s robot simulations can be found on his website.

Speaking of robotics, in this issue columnist Jeff Bachiochi introduces readers to the free robot control programming language RobotBASIC and explains how to use it with an integrated simulator for robot communication.

Other columnists also take on a number of very practical subjects. Robert Lacoste explains how inexpensive bipolar junction transistors (BJTs) can be helpful in many designs and outlines how to use one to build an amplifier.

George Novacek, who has found that the cost of battery packs account for half the DIY Battery Chargerpurchase price of his equipment, explains how to build a back-up power source with a lead-acid battery and a charger.

“Building a good battery charger is easy these days because there are many ICs specifically designed for battery chargers,” he says.

Columnist Bob Japenga begins a new series looking at file systems available on Linux for embedded systems.

“Although you could build a Linux system without a file system, most Linux systems will have some sort of file system,” Japenga says. “And there are various types. There are files systems that do not retain their data (volatile) across power outages (i.e., RAM drives). There are nonvolatile read-only file systems that cannot be changed (e.g., CRAMFS). And there are nonvolatile read/write file systems.”

Linux provides all three types of file systems, Japenga says, and his series will address all of them.

Finally, the magazine offers some special features, including an interview with Alenka Zajić, who teaches signal processing and electromagnetics at Georgia Institute of Technology’s School of Electrical and Computer Engineering. Also, two North Carolina State University researchers write about advances in 3-D liquid metal printing and possible applications such as electrical wires that can “heal” themselves after being severed.

For more, check out the Circuit Cellar’s October issue.

 

 

Prevent Embedded Design Errors (CC 25th Anniversary Preview)

Attention, electrical engineers and programmers! Our upcoming 25th Anniversary Issue (available in early 2013) isn’t solely a look back at the history of this publication. Sure, we cover a bit of history. But the issue also features design tips, projects, interviews, and essays on topics ranging from user interface (UI) tips for designers to the future of small RAM devices, FPGAs, and 8-bit chips.

Circuit Cellar’s 25th Anniversary issue … coming in early 2013

Circuit Cellar columnist Robert Lacoste is one of the engineers whose essay will focus on present-day design tips. He explains that electrical engineering projects such as mixed-signal designs can be tedious, tricky, and exhausting. In his essay, Lacoste details 25 errors that once made will surely complicate (at best) or ruin (at worst) an embedded design project. Below are some examples and tips.

Thinking about bringing an electronics design to market? Lacoste highlights a common error many designers make.

Error 3: Not Anticipating Regulatory Constraints

Another common error is forgetting to plan for regulatory requirements from day one. Unless you’re working on a prototype that won’t ever leave your lab, there is a high probability that you will need to comply with some regulations. FCC and CE are the most common, but you’ll also find local regulations as well as product-class requirements for a broad range of products, from toys to safety devices to motor-based machines. (Refer to my article, “CE Marking in a Nutshell,” in Circuit Cellar 257 for more information.)

Let’s say you design a wireless gizmo with the U.S. market and later find that your customers want to use it in Europe. This means you lose years of work, as well as profits, because you overlooked your customers’ needs and the regulations in place in different locals.

When designing a wireless gizmo that will be used outside the U.S., having adequate information from the start will help you make good decisions. An example would be selecting a worldwide-enabled band like the ubiquitous 2.4 GHz. Similarly, don’t forget that EMC/ESD regulations require that nearly all inputs and outputs should be protected against surge transients. If you forget this, your beautiful, expensive prototype may not survive its first day at the test lab.

Watch out for errors

Here’s another common error that could derail a project. Lacoste writes:

Error 10: You Order Only One Set of Parts Before PCB Design

I love this one because I’ve done it plenty of times even though I knew the risk.

Let’s say you design your schematic, route your PCB, manufacture or order the PCB, and then order the parts to populate it. But soon thereafter you discover one of the following situations: You find that some of the required parts aren’t available. (Perhaps no distributor has them. Or maybe they’re available but you must make a minimum order of 10,000 parts and wait six months.) You learn the parts are tagged as obsolete by its manufacturer, which may not be known in advance especially if you are a small customer.

If you are serious about efficiency, you won’t have this problem because you’ll order the required parts for your prototypes in advance. But even then you might have the same issue when you need to order components for the first production batch. This one is tricky to solve, but only two solutions work. Either use only very common parts that are widely available from several sources or early on buy enough parts for a couple of years of production. Unfortunately, the latter is the only reasonable option for certain components like LCDs.

Ok, how about one more? You’ll have to check out the Anniversary Issue for the list of the other 22 errors and tips. Lacoste writes:

Error 12: You Forget About Crosstalk Between Digital and Analog Signals

Full analog designs are rare, so you have probably some noisy digital signals around your sensor input or other low-noise analog lines. Of course, you know that you must separate them as much as possible, but you can be sure that you will forget it more than once.

Let’s consider a real-world example. Some years ago, my company designed a high-tech Hi-Fi audio device. It included an on-board I2C bus linking a remote user interface. Do you know what happened? Of course, we got some audible glitches on the loudspeaker every time there was an I2C transfer. We redesigned the PCB—moving tracks and adding plenty of grounded copper pour and vias between sensitive lines and the problem was resolved. Of course we lost some weeks in between. We knew the risk, but underestimated it because nothing is as sensitive as a pair of ears. Check twice and always put guard-grounded planes between sensitive tracks and noisy ones.

Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.