标签: processor

The concept of time is simple yet complex. In its simplest form, it's the counting of a regular, repeating pattern. On the opposite end, we would have to turn to Einstein. Thankfully, this story resides on the simple side. You see, before the advent of the real-time clock, electrical engineers scurried hither and yon in search of ways to calculate time accurately in their circuits. One very convenient source of a regular, repeating pattern was the 60Hz line frequency coming from the wall outlet. It was a very stable source in the US, and so long as it was stable, your machine would work fine. But if ever a crack appeared in the stability of the 60Hz source, the entire machine could be compromised. This was the case on the idle Tuesday morning our story begins. Giant pillars of white smoke soared high in the air from the large, concrete stacks that reached up into the clear blue sky. It was easy to find parking in the large lot when I arrived at the paper-making plant nestled on the outskirts of Richmond, Va. The smell of sulphur was thick, and the rumble of the large trucks carrying trees filled the air as they entered the plant. It was a short walk to the visitor's desk, where I was met by the man who had called me a few days earlier. "Damn thing doesn't work," he had said. I get that a lot. He led me to the not-working microwave solids analyser. This simple machine consists of a microwave, a balance, and an embedded computer. It heats a sample to remove all the moisture, and the computer uses the difference in weight to calculate the per cent moisture in the sample. I placed a test sample in the machine and pressed the start button. Immediately, problems were apparent. On the grey scale display, the system clock was counting down the time. The problem was it was counting way too fast. It had counted down more than two minutes, but my gut, verified by a clock on the cinderblock wall, told me less than a minute had gone by. I pressed the stop button, and another problem revealed itself. Instead of the usual single beep, I got three. It acted as if I had pressed the button a couple of times. It appeared I had debouncing as well as timing issues. It was then that I clued in on the A/C line and took a closer look. I was in for a shock.   This video and the scope screen captures above were taken directly from the 120V wall socket via a 10-to-1 stepdown wall-wart transformer using a 10x probe. As you can see, the signal is very dirty. I concluded the source of the noise was probably from one of the large paper rolling machines running elsewhere in the plant. I had identified the problem. But I still did not know how the dirty signal was causing the timing and debouncing issues and how to fix them. I had to solve a before I could even begin to approach how to fix the issues. Like any good technician, I dug into the schematic. It wasn't long until I discovered a small circuit that appeared to be converting the A/C line frequency into a 5V clock signal. The output was routed to one of the pins of the 80188 Intel processor.   I knew I had to get a scope on pin 6 of the opto-coupler (U7) to see if the noise on the A/C line was getting through.     So the noise from the A/C line was getting through the opto-coupler in the form of problematic leading and trailing edges. It was so bad that the scope had a hard time locking on to the frequency, as seen above. I did not have access to firmware, but my theory was sound. I believed that the 80188 computer was using this very signal to generate its definition of time—every 120 leading-edge counts was equal to one second in the firmware. And in this case, all the spikes on the leading edges were being counted, as well. This would cause the system's internal clock to run too fast. Also, I knew the switch debouncing was done in firmware. This code is dependent on accurate delay times. If the system clock were running too fast, that would mean the delay times would be too short, and the debouncing code would not work properly. Yessss! I had found the source of the problem, theoretically at least. Now, how to fix it. Long story short, I concluded that it would be easiest to simply replace the signal. I would remove the opto-coupler IC and use a microcontroller to generate a clean signal and route it to the processor.   Above is the schematic. (I realised I had taken the scope readings in the previous images off U6 instead of U7. U7 produces a 10 per cent duty cycle 120Hz signal, as opposed to 50 per cent.) Below is the code to generate the 10 per cent duty cycle 120Hz signal. while (true) { { output_high(PIN_A2); delay_us(833); output_low(PIN_A2); delay_us(7600); } } I made a board using toner transfer. I removed the opto-coupler, and used the empty socket to supply power to my board and route the clean signal to the processor.     I installed it in the instrument the next day, and everything worked perfectly. The timing was accurate, and no more debouncing issues. I had the board done from a board house and installed it a few weeks later. The instrument has been working well ever since.     This article was submitted by Will Sweatman, a field engineer, as part of Frankenstein's Fix, a design contest hosted by EE Times (US).

Whether we like it or not, business is complicated and full of compromises, but some compromises make the whole system fail.   As engineers, we often focus our efforts on the details of a product design. Some engineers specialize in blank-slate design. Others focus on test and quality engineering. Still others provide expert guidance for manufacturing processes. It seems that, no matter what the industry, "almost acceptable" products have become the norm for what we collectively have come to believe is "good."   I'm not saying that every component of every product isn't good. But to me, "product" means my entire experience, from researching for products to selecting candidate solutions to purchasing the chosen product to receiving it. For me, a failure in any part of this supply chain engagement results in, at best, an almost acceptable product.   I've recently encountered a series of almost acceptable products -- not because the items themselves were poorly designed or manufactured, but because other aspects of the product experience were unacceptable.   A year ago, a company with which I was consulting received a sample of a PCIe chassis, backplane, and enclosure. The fit and finish were excellent -- the sheet metal was bright plated, and the seams were welded. This was a great solution for a new design challenge to repackage a research machine into a commercially acceptable enclosure. Based on experience, I thought this enclosure would give us a fighting chance to pass electromagnetic emissions standards for the new machine. We ordered a chassis and enclosure based on the sample unit we'd evaluated. What we received was vastly different from the evaluation unit.   I recently had dinner with executives from the company, and I asked about the change. They were surprised by the difference in what we'd evaluated and what we received. It seems that we had evaluated a Mil-Spec chassis and enclosure, but our understanding was that it was the commercial unit. We subsequently discovered that the salesperson had ordered a commercial evaluation unit, but evidently a Mil-Spec counterpart had been shipped by mistake. The jury is out on this almost adequate product. The executives inform me that the commercial unit with the same essential electronics that we use passes FCC part B. We'll see.   How about another almost adequate product? I recently received a single-board computer with a dual Xeon processor and 48 GB of DDR3 RAM. It's a powerful board that can handle the data it will be required to process. It's pretty nice for a dual-slot board. The only problem is that it isn't really a dual-slot card. Yes, the card itself occupies two slots of the PCIe backplane, but the cabling from the peripherals in the front of the enclosure requires another two slots. Also, perhaps the missed failure in this case is the fact that the custom heat sink requires cooling fans to be placed on top of the heat sink. The supplier's answer? "Customers put a short board next to this card for airflow."   Here's yet another almost adequate item from a colleague of mine. A medical device design requires a medical grade isolated UPS. After significant research and paper evaluation, a UPS was selected. It weighs more than 70 pounds. He ordered a single unit of this multi-thousand-dollar UPS and waited patiently for it to arrive. The big day came, and a truck arrived with the unit. It was heavy -- more than 100 pounds. The packaging material was pretty destroyed during the shipping process. Damage to the UPS itself wasn't visible until the box had been removed. Inside a second box was a collection of UPS pieces that had been part of the original unit. The UPS had come loose from its mini shipping pallet and evidently had traveled from Texas to California bouncing all of its 70+ pounds on the now-destroyed faceplate.   Of course, shipping accidents do happen. Another unit was shipped to replace the first unit. This arrived in a box that had been secured with duct tape. It too had broken loose from its pallet and had a destroyed front panel.   It was not exactly amusing that both of these units had wood attached to the faceplate with wood screws. Even if the shipping hadn't damaged the UPS, the wood screws holding a piece of wood onto the faceplate would have been enough to return the damaged unit.   Try entry number three -- another distributor, another order, another delivery. This time, the box came off in the hands of the delivery person. Once again, wood screws went through the wood and into the faceplate. Finally, my colleague called the manufacturer. The company agreed to ship a unit direct, even though its corporate policy was to send small orders through a distributor. This fourth unit looks like it has arrived intact, with no wood screws holding wood on to the faceplate.   These anecdotes illustrate three ways that products can become almost adequate: a change in production methods, a grossly inadequate datasheet, and shipping failures. We haven't considered the almost adequate design decisions that are all around us: the Christmas lights that might last a few dozen hours before they fail, "long-life" compact fluorescent light bulbs that fail as fast as their incandescent cousins, supermarket bagels that are moldy when the bag is opened only a few hours after they are bought. The list goes on and on.   There are some truly good products, but all too often we accept mediocrity. It's time to do away with "almost adequate" and make "good" mean what it says. There's no room for wiggling out by redefining words.   Henry Davis is an independent contractor.

After several years of hype, multi-core and multiple-CPU embedded systems are now becoming mainstream. There are numerous articles about multi-core design that address different hardware architectures (homogeneous and heterogeneous multi-core) and software architectures (AMP: asymmetrical multi-processing and SMP: symmetrical multi-processing). In this article the development of an AMP system is outlined, highlighting various challenges that were addressed. What is unusual is that the design was completed in 1981! It often appears that there is nothing truly new in the world. With technology, it is often a question of the time being right. The programming languages that we use nowadays are mostly developments of 30-40 year old technology. The current enthusiasm for multi-core designs is really nothing new either. Browsing the literature turns up titles like "Multi-core is Here Now" that have been appearing for at least 5 years. But multi-core goes back further still. I was working on a multi-core system in 1980 ... How it all started It was my first job out of college and I worked for a company that made materials testing instruments – large machines and systems that stressed and broke things under controlled conditions. The use of computer or microprocessor control was new. Hitherto, the machines had been controlled by racks of analogue electronics, with meters and chart recorders providing results. I worked in the division that provided the computer control. Initially, the approach was simply to link a mini-computer to a traditional console. The next – and, at the time, brave – step was to replace the entire console with a microprocessor where a keypad enabled input of parameters and selection of settings from menus on a screen. Of course, a mouse or touch screen might have been better, but that technology would not appear for some years. The project to which I was assigned was to facilitate the "user programmability" of the new microprocessor-controlled machines – the "User Programmability Option" or "UPO". It was decided that the best way to provide this capability would be to add an additional computer instead of potentially compromising the real-time behaviour of the controlling microprocessor. This is exactly how I might advise a customer today who is designing a multi-core system with real-time and non-real-time components. The processors The advanced console was built around a Texas Instruments 9900 microprocessor, which was one of the first true 16bit, single-chip devices on the market. It had an advanced architecture, with some interesting pros and cons: it could intrinsically support multi-threading in a very simple way, with context saving accommodated in hardware; but its registers were mostly RAM based, which, at the time, was a significant performance limiter. The instruction set and addressing modes bore some similarity to the 68000. I recall that the documentation was confusing, as the bits were numbered backwards, with the most significant bit being #0. This part of the system was programmed in Forth code (see code below). I have no idea why this design decision was made, but I found the language intriguing and my interest persists. The UPO computer was an SBC-11. The "11" came from the internal processor, which was essentially a DEC PDP-11, a mini-computer which was familiar to us at the time. "SBC" was apparently short for "shoe box computer", because that is what it looked like. I have a suspicion that this was a joke and it actually stood for "single board computer", as it does today. We implemented user programmability using a variant of the BASIC language, with some extensions to access capabilities of the testing machine. Interprocessor communications Using multiple CPUs (or cores) presents a variety of challenges. One is the division of labour, which was reasonably straightforward in this case. Another is communication between the processors ... In designing the UPO, we considered a number of means by which the two CPUs might be connected. As they were separate boxes, serial and parallel connections were considered. But we were concerned about any possible compromise of the real-time performance of the console microprocessor. Also, we did not want the user to be faced with the UPO freezing while it waited for attention from the console. So, clearly a buffering mechanism was needed and shared memory seemed to be a good option. A small memory board was designed. I have no idea of the hardware architecture, except that I seem to recall that the TI-9900 had priority over the SB-11, as it could not afford to be delayed by slow memory access. If I remember correctly, the board was 2K (words, probably). Protocol It was down to us to define a protocol for communication, so we aimed to produce something that was simple and reliable. We divided the memory into two halves; one was a buffer for communication from the UPO to the console and the other for the opposite direction. The first word of each buffer was for a command/status code, which was simply a non-zero value. We did not use interrupts. The receiving CPU just polled the first word when appropriate, awaiting a non-zero value. When a command was found, any data could be copied and the command word cleared to zero, indicating that the processing was complete. So, the UPO sending a command to the console might go through a sequence like this: * Write data to the buffer . * Write a command to the first word. * Poll the word, waiting for it to become zero. If it was expecting a response, it would then start monitoring the other buffer. Of course, there were other facilities to handle a situation where one CPU did not respond after a timeout period. Nowadays, multi-core and multi-chip systems have a variety of interconnection technologies, but shared memory is still common. A number of standardised protocols have been developed over the years, including derivatives of TCP/IP. In recent years, the Multicore Association produced the Multicore Communications API (MCAPI), which is rapidly gaining broad acceptance in multi-core embedded system designs. Challenges When we hooked up the shared memory and started to send test messages between the processors, we hit a problem: they seemed to get scrambled. At first we assumed that there was a problem with the memory board, but it was checked by the hardware guys who pronounced it healthy. Then we spotted a pattern: the bytes of each 16bit word were getting swapped. We thought that it was a wiring problem with the board, but studying the schematics and the board layout showed no error. Of course, the reason for the problem was that the two CPUs were different architectures, from different manufacturers, each of whom had a different idea about which byte went where in the word. Now I would describe one as big-endian and the other as little-endian, but I did not have the vocabulary back then. An adjustment to the board design could have made this problem go away. But of course it was too late for that. So we had to resort to the age-old method to rectify a problem found late in the design process: fix it in the software. I simply put a byte swap on one side of the interface and the other side was none the wiser. How would I do it now? In the end, we got the UPO working to our satisfaction and I think we even sold a few of them. It is interesting to consider how I might build such a system now, thirty-odd years later. First off, I would design the console as a multi-core system. There would probably be one core that would do non-real-time work (user interface, data storage, networking, etc.) and maybe two more to do real-time work like data sampling and control of the servo-hydraulics.ÿThe UPO would just be an app on a standard Windows PC with a USB interface to the console. I have no insight into how the company builds testing systems now, but it would be interesting to compare notes with my 2013 counterparts. Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor Embedded (the Mentor Graphics Embedded Software Division), and is based in the UK.  

Time is a simple yet complex concept. In its simplest form, it's the counting of a regular, repeating pattern. On the opposite end, we would have to turn to Einstein. Thankfully, this story resides on the simple side. You see, before the advent of the real-time clock, electrical engineers scurried hither and yon in search of ways to calculate time accurately in their circuits. One very convenient source of a regular, repeating pattern was the 60Hz line frequency coming from the wall outlet. It was a very stable source in the US, and so long as it was stable, your machine would work fine. But if ever a crack appeared in the stability of the 60Hz source, the entire machine could be compromised. This was the case on the idle Tuesday morning our story begins. Giant pillars of white smoke soared high in the air from the large, concrete stacks that reached up into the clear blue sky. It was easy to find parking in the large lot when I arrived at the paper-making plant nestled on the outskirts of Richmond, Va. The smell of sulphur was thick, and the rumble of the large trucks carrying trees filled the air as they entered the plant. It was a short walk to the visitor's desk, where I was met by the man who had called me a few days earlier. "Damn thing doesn't work," he had said. I get that a lot. He led me to the not-working microwave solids analyser. This simple machine consists of a microwave, a balance, and an embedded computer. It heats a sample to remove all the moisture, and the computer uses the difference in weight to calculate the per cent moisture in the sample. I placed a test sample in the machine and pressed the start button. Immediately, problems were apparent. On the grey scale display, the system clock was counting down the time. The problem was it was counting way too fast. It had counted down more than two minutes, but my gut, verified by a clock on the cinderblock wall, told me less than a minute had gone by. I pressed the stop button, and another problem revealed itself. Instead of the usual single beep, I got three. It acted as if I had pressed the button a couple of times. It appeared I had debouncing as well as timing issues. It was then that I clued in on the A/C line and took a closer look. I was in for a shock.   This video and the scope screen captures above were taken directly from the 120V wall socket via a 10-to-1 stepdown wall-wart transformer using a 10x probe. As you can see, the signal is very dirty. I concluded the source of the noise was probably from one of the large paper rolling machines running elsewhere in the plant. I had identified the problem. But I still did not know how the dirty signal was causing the timing and debouncing issues and how to fix them. I had to solve a before I could even begin to approach how to fix the issues. Like any good technician, I dug into the schematic. It wasn't long until I discovered a small circuit that appeared to be converting the A/C line frequency into a 5V clock signal. The output was routed to one of the pins of the 80188 Intel processor.   I knew I had to get a scope on pin 6 of the opto-coupler (U7) to see if the noise on the A/C line was getting through.     So the noise from the A/C line was getting through the opto-coupler in the form of problematic leading and trailing edges. It was so bad that the scope had a hard time locking on to the frequency, as seen above. I did not have access to firmware, but my theory was sound. I believed that the 80188 computer was using this very signal to generate its definition of time—every 120 leading-edge counts was equal to one second in the firmware. And in this case, all the spikes on the leading edges were being counted, as well. This would cause the system's internal clock to run too fast. Also, I knew the switch debouncing was done in firmware. This code is dependent on accurate delay times. If the system clock were running too fast, that would mean the delay times would be too short, and the debouncing code would not work properly. Yessss! I had found the source of the problem, theoretically at least. Now, how to fix it. Long story short, I concluded that it would be easiest to simply replace the signal. I would remove the opto-coupler IC and use a microcontroller to generate a clean signal and route it to the processor.   Above is the schematic. (I realised I had taken the scope readings in the previous images off U6 instead of U7. U7 produces a 10 per cent duty cycle 120Hz signal, as opposed to 50 per cent.) Below is the code to generate the 10 per cent duty cycle 120Hz signal. while (true) { { output_high(PIN_A2); delay_us(833); output_low(PIN_A2); delay_us(7600); } } I made a board using toner transfer. I removed the opto-coupler, and used the empty socket to supply power to my board and route the clean signal to the processor.     I installed it in the instrument the next day, and everything worked perfectly. The timing was accurate, and no more debouncing issues. I had the board done from a board house and installed it a few weeks later. The instrument has been working well ever since.     This article was submitted by Will Sweatman, a field engineer, as part of Frankenstein's Fix, a design contest hosted by EE Times (US).  

In this blog, we continue with our focus on intellectual property. Last time , we looked at the question of who verifies the IP. This time, we look at a very different question. How do IP providers protect themselves? I posed the question to some industry leaders and here are some of their responses: Michael Munsey, director of product management, Semiconductor Solutions, Dassault Systèmes "This may be the single largest area for improvement in semiconductor IP and the issue of protection is even larger than just for IP providers. IP integrators also need to know where their IP was sourced from and whether they have the rights to use that IP. For example, I may receive a piece of IP from a partner to only use in a design that I am doing for that partner. Once integrated, I need to make sure that the larger system containing that IP is not used in other designs. My partner may require that I provide documentation that shows how that IP is protected. IP protection needs to be part of the supply chain, including not only protection for the IP source, but protections and reporting for access to the IP. Audit trails are needed to indicate where the IP is used, and guarantee that it is only used in approved places." John Koeter, vice president of marketing, Solutions Group, Synopsys "There are multiple avenues to protect IP but the most prevalent is contractual protection with audit rights, which is standard in the industry." Susan Peterson, product marketing group director and Tom Hackett, senior product marketing manager, Cadence "Contractual protections along with developing tagging technology does provide protection for IP providers. Cadence relies on our contracts to ensure our rights are protected. Additionally, our customers are sophisticated technology providers who understand the value of protecting IP rights and aid us in ensuring our rights are protected." Mike Gianfagna, vice president of corporate marketing, Atrenta "IP tagging holds a lot of promise to address this issue—it requires collaboration by a lot of folks in the IP ecosystem." Eran Briman, vice president of marketing, CEVA "Because of all of the additional areas required to deliver a successful processor IP, theft is not as much a problem as it may be for standard IPs. Tools, software, etc., are needed to get the most out of processor IPs, so having the architecture alone would not be enough. At CEVA we validate our licensees before we commit to work with them and verify their internal IP protection systems and methodologies. Also, we can provide protected DSP models or even hard macros to some end markets if necessary." Jacek Hanke, Piotr Kandora, Tomasz Krzyzak, Digital Core Design "The problem of IP theft will be always an issue because there are companies who don't care about it. We've seen a variety of approaches to protect against theft such as licensing the IP at a site level or do business only with trusted companies. From our perspective, almost 15 years company's market experience brought solutions, which seem to be sufficient to protect us. Some of them are known, for example: circuit extraction, netlist generation, or data mining algorithms. There could be also included security tagging system using side channel attack techniques. But most of the techniques are companies' 'know how'—and they are protected almost as strong as the IP Core itself. "It is very difficult to prevent illegitimate uses of IP cores whether it's intentional or unintended. The identification of IP cores becomes the last means for any IP core providers to prove illegitimate usages of their IP cores. Luckily every IP Core is being sold for separate licence agreement, which protect the IP and is a first step to execute the vendor's property rights. There are also highly specialised companies that provide sophisticated solutions. They are good enough to provide an independent analysis which can be a proof when property rights are violated. Thankfully, IP thefts are just a margin of the whole IP business."   Brian Bailey EE Times