Linux Kernel Debugging and Profiling, With and Without OCI
Officer McReady scratched his head in confusion. “OK, tell me again why you think Bostwick stole the papers?”
“Because, well, first of all I thought he was going to, see?” he started.
“Why did you think that?”
“Well, something was up. I had some of the documents on my desk, and Debra had some on her desk, and then they were gone. And we found them on his desk. That was just weird; why was he gathering these things up? It wasn’t even his project!”
“OK, but just because it’s weird doesn’t mean he stole the papers.”
“Yeah, but after we all left, he was the only one here. I had this iggy feeling in my gut about this, so I sorta hung around outside. After about 15 minutes, this courier guy shows up and leaves with a big manila envelope fulla papers. And about 5 minutes after that Bostwick takes off. And now the papers are gone.”
“OK, but did you actually see what was in the envelope?”
“No, it was closed.”
“So we have no proof that the envelope had these papers in it.”
“Well, no, but what else would it be?”
“It could have been anything; you guys got more papers in here than all the bathrooms in Shea Stadium put together. I never seen so many papers. I have no idea how you guys keep it straight. Hell, it’s probably lost, not stolen. Besides, if you were so sure something was going to happen, why didn’t you stay in the building, or go back in?”
“Because if I did, he’d know, and obviously he wouldn’t take them then, would he... I mean, what am I supposed to do? If I watch him, he won’t do it. If I don’t watch him, then I can’t prove he did it. Either way, I lose!”
FPGA Journal Turns Five
Five fabulous years after removing the “press” from “trade-press,” FPGA Journal has pushed out over 5 million e-mails, over 5 hundred original articles, over 5 thousand news stories, and dozens of webcasts through its servers. You, our audience, have told us often what you like and want – useful, interesting, and entertaining articles; a focus on topics important to engineers; objective and insightful analysis; up-to-date industry news; non-boring webcasts; and a sense of humor. Well, four out of five isn’t too bad.
Our parent company – Techfocus Media, Inc. has been good to us as well. Like any good parent, it has supplied us with siblings. Our first sister publication, Embedded Technology Journal, is turning three this week and is well out of its “toddler” phase. Editor and industry luminary Jim Turley is leading that publication and bringing some of the best editorial and analysis articles in the embedded space today. Bryon Moyer is heading our newest addition – IC Design and Verification Journal, and that publication is growing rapidly in a technology area that has been almost completely abandoned by the majority of the trade press.
“So where are you off to this week?” a neighbour asked. “Paris and Munich,” I replied. “Oh, very nice,” he said. Well, perhaps.
Actually, apart from the bus from the airport to the hotel, the hotel in Paris could have been a company event anywhere in the world. It was Freescale’s Paris Technical Forum, where they gather together customers and prospective customers (around 600 people in total) from across Europe and present a series of technical papers and tutorials alongside a small scale exhibition (Technology Lab) with booths from partners as well as their own product streams. It is a single vendor version of the ESC or embedded world, in essence. Since they have a bunch of senior company people present, including recently appointed CEO, Rich Beyer, the company also uses this as an opportunity to update the press and analyst community.
A Look at FRAM and MRAM Technologies
[Editor’s warning: this article contains multiple instances of polysyllabic scientific jargon. Reader discretion is advised.]
Two non-volatile memory technologies have been making some low-level play over the last little while, and it’s pretty easy to confuse the two or think that they’re somehow related. One is a relative old-timer; one is a newcomer. But for many designers, they may both be unfamiliar. In fact they have pretty much nothing to do with each other from the standpoint of how they work. The question that remains, however, is whether they will vie for the same designs.
The first is the more venerable of the two, FRAM, or FeRAM: Ferroelectric RAM. Now the “ferro” bit in there would indicate iron, and we all know that iron is magnetic. And in fact, the name “ferroelectric” is derived by analogy to “ferromagnetic.” Its operation is even said to be similar to that of the ferrite core memories of yore. So it’s easy to slip into the assumption that FRAMs are somehow related to other magnetic-based memories.
Electronic System Level (ESL) design claims to offer not just a quicker path from concept to hardware, but a cost-effective one when targeting platform FPGAs. And yet some hold out on ESL due to concern over the netlist’s quality of results (QoR)—a path from concept-to-silicon is not of much use if it does not meet performance and area requirements.
Quality-of-results, however, not only depends on ESL synthesis itself but its interaction with downstream tools. For example, given that high-level algorithms are commonly specified in C++, the best algorithmic synthesis tools take standard ANSI C++ as input and automatically produce RTL based on user-defined design goals. This in turn must go through RTL synthesis and FPGA place-and-route before it reaches real hardware, as depicted in Figure 1. Hence, the extent of integration among these various stages can affect whether or not design goals are met.
Mitrion-C to RTL instead of C to RTL
It has long been a dream of big-picture systems engineering visionaries to crack the barrier between hardware and software. Traditionally, the amount of effort required to take software features and accelerate them by turning them into dedicated hardware has been high and not easily done at the last minute when, for example, a coding bottleneck that needs hardware acceleration is uncovered right before release time.
This is, of course, the impetus behind the many flavors of C-to-RTL that have arisen over the years. From the early days of Handel C to the present, much effort has been made – and unfortunately, less-than-proportionate success achieved – in an attempt to make the implementation of a software algorithm fungible in the sense that, given a function, it could be done in software or hardware with no significant effort required for one or the other. While FPGAs have been the primary targets for the resulting hardware implementations, higher-end tools have also targeted dedicated silicon for functions cast in hardware on an SoC.