标签: to

与被用于在今天的芯片越来越多频时钟，特别是在通信领域中，经常有必要在芯片运行的同时切换的时钟线的来源。这通常是通过在硬件中复用两个不同的频率的时钟源通过控制内部逻辑多路复用器选择线实现。 两个时钟的频率可能是完全无关的彼此或者它们可以是彼此的倍数。在这两种情况下，在开关的时候有时钟毛刺产生。时钟线上毛刺危害整个系统，因为毛刺可能被一些寄存器误以为时捕获延。   在这篇文章中，两种不同的避免干扰的方法。第一种方法处理时钟之间是倍数关系，第二处理时钟完全无关彼此。 原文：http://www.design-reuse.com/articles/5827/techniques-to-make-clock-switching-glitch-free.html http://wenku.baidu.com/link?url=xp4KTPQTTO6xQcKD32h7v_Eq0-qLZenkHQsjTrBWCxOQWzHuJggFSHKTYCyPZt5ZcdUyZL_qGT_UF10KYX_3HR-SIDGNapCmlqpbf-aPclK The problem with on-the-fly clock switching Figure 1 shows a simple implementation of a clock switch, using an AND-OR type multiplexer logic. The multiplexer has one control signal, named SELECT, which either propagates CLK0 to the output when set to “zero” or propagates CLK1 to the output when set to “one." A glitch may be caused due to immediate switching of the output from Current Clock source to the Next Clock source, when the SELECT value changes. Current Clock is the clock source currently selected while Next Clock is the clock source corresponding to the new SELECT value. The timing diagram in Figure 1 shows how a glitch is generated at the output, OUT CLOCK, when the SELECT control signal changes. The problem with this kind of switch is that the switch control signal can change any time with respect to the source clocks, thus creating a potential for chopping the output clock or creating a glitch at the output. The select control signal is most likely generated by a register driven by either of the two source clocks, which means that either it has a known timing relationship to both clocks, if both clocks are multiples of each other, or it may be asynchronous to at least one clock, if source clocks are not related in any way. Switching during either clock's high state needs to be avoided without having any idea about the frequencies or phase relationship of these clocks. Fixed delay can be used to induce the gap between the start and stop time of the two source clocks, but only if a fixed relationship exists between the two clock sources. It cannot be used where either the input frequencies are not known, or the clocks are not related.   Glitch protection for related clock sources A solution to prevent glitch at the output of a clock switch where source clocks are multiples of each other is presented in Fi gure 2. A negative edge triggered D flip-flop is inserted in the selection path for each of the clock sources. Registering the selection control at negative edge of the clock, along with enabling the selection only after other clock is de-selected first, provides excellent protection against glitches at the output. Registering the select signal at negative edge of the clock guarantees that no changes occur at the output while either of the clocks is at high level, thus protecting against chopping the output clock. Feedback from one clock's selection to the other enables the switch to wait for de-selection of the Current Clock before starting the propagation of the Next Clock, avoiding any glitches. The figure 2 timing diagram shows how the transition of the SELECT signal from 0 to 1 first stops propagation of CLK0 to the output at the proceeding falling edge of CLK0, then starts the propagation of CLK1 to the output at following negative edge of CLK1. There are three timing paths in this circuit that need special consideration — the SELECT control signal to either one of the two negative edge triggered flip flops, the output of DFF0 to input of DFF1, and the output of DFF1 to the input of DFF0. If the signal on any of these three paths changes at the same time as the capturing edge of the destination flip flop's clock, there is a small chance that the output of that register may become meta-stable, meaning it may go to a state between an ideal “one” and an ideal “zero.” A meta-stable state can be interpreted differently by the clock multiplexer and the enable feedback of the other flip flop. Therefore, it is required that capturing edges of both flip flops and the launch edge of the SELECT signal should be set apart from each other to avoid any asynchronous interfacing. This can be easily accomplished by using proper multi-cycle hold constraints or minimum delay constraints, as the timing relationship is known between the two clocks.   Figure2 -- Glitch-free clock switching for related clocks Fault tolerance At chip startup time, both flip flops DFF0 and DFF1 should be reset to the “zero” state so that neither one of the clocks is propagated initially. By starting both flip flops in “zero” state, fault tolerance is built into the clock switch. Let's say that one of the clocks was not toggling due to a fault at startup time. If the flip flop associated with the faulty clock had started up in “one” state, it would prevent the selection of other clock as the Next Clock, and its own state is not changeable due to lack of a running clock. By starting both flip flops in “zero” state, even if one of the source clocks is not running, there is still the ability to propagate the other good clock to the output of the switch. Glitch protection for unrelated clock sources The previous method of avoiding a glitch at the output of a clock switch requires the two cl ock sources to be multiples of each other, such that user can avoid signals to be asynchronous with either one of the clock domains. There is no mechanism to handle asynchronous signals in that implementation. This leads to the second method of implementing the clock switch with synchronizer circuits to avoid potential meta-stability caused by asynchronous signals. The source of asynchronous behavior could either the be SELECT signal or the feedback from one clock domain to the other, when the two clock sources are totally unrelated to each other. As shown in Figure 3, protection is provided against meta-stability by adding one extra stage of positive edge triggered flip flop for each of the clock sources. The positive edge triggered flip flop in each of the selection paths, along with the existing negative edge triggered flip flop, guards against potential meta-stability, which may be caused by asynchronous SELECT signal or asynchronous feedback from one clock domain to the other. A synchroniz er is simply two stages of flip flops, where the first stage helps stabilize data by latching it and later passing it on to the next stage to be interpreted by rest of the circuit.   Figure 3 -- Glitch-free clock switching for unrelated clocks Conclusion The hazard of generating a glitch on a clock line while switching between clock sources can be avoided with very little overhead by using the design techniques presented in this article. These techniques are fully scalable and can be extended to a clock switch for more than two clocks. For multiple clock sources, the select signal for each clock source will be enabled by feedback from all the other sources. Rafey Mahmud is a member of technical staff at Altera Corp. He has worked on several microprocessor and ASIC design projects.  

How can you get a firmware project out the door as soon as possible? Ship junk. Unprogrammed flash. One company I know grades developers on the size of the program; a cynic there could do very well by dumping Moby Dick (1,172,046B by my count) into memory. The system wouldn't work too well, or at all, but the project will beat all development records. The second fastest way is to ship insanely-high quality code. Deming, Juran, and the subsequent quality movement taught the manufacturing world that quality and speed go together. Quality stems from fabulous design that requires no rework; no rework means projects go out the door faster. Alas, in the firmware world that message never resonated. Most projects devote half the schedule to debugging (which implies the other half should be named "bugging"). Typical projects start with a minimum of design followed by a furious onslaught of coding, and then long days and nights wrestling with the debugger. Capers Jones 1 studied 4,000 late software projects and found that bugs are the biggest cause of schedule slippages. Benediktsson 2 showed that one can get the very highest level of safety-critical software for no additional cost, compared to the usual crap, by using the right processes. Bottom line: quality leads to shorter schedules. Here are some tips for accelerating schedules: 1. Focus relentless on quality. Never accept anything other than the best. Don't maintain a bug list; rather fix the bugs as soon as they are found. Bug lists always infer a bug deferral meeting, that time when everyone agrees on just how awful the shipped product will be. This is the only industry on the planet where we can (for now) ship known defective products. Sooner or later the lawyers will figure this out. A bug list produced in court will imply shoddy engineering... or even malpractice. 2. Requirements are hard. So spend time, often lots of time, eliciting them. Making changes late in the game will drastically curtail progress. Prototype when they aren't clear or when a GUI is involved. Similarly, invest in design and architecture up front. How much time? That depends on the size of the system, but NASA 3 showed the optimum amount (i.e., the minimum on the curve) can be as much as 40% of the schedule on huge projects. 3. Religiously use firmware and code inspections. I have observed that it's about impossible to consistently build world-class firmware unless it is all done to a reasonable standard. Happily, plenty of tools are available that will check the code against a standard. And couple this practice to the use of code inspections on all new code. Plenty 4 of research shows that inspections are far cheaper—faster—than the usual debugging and test. In fact, testing generally doesn't work 5 —it typically only exercises half the code. There are, however, mature tools that will greatly increase test coverage, and that will even automatically create test code. 4. The hardware is going to be late. Plan for it. When it finally shows up it will be full of problems. Our usual response is to be horrified that, well, it's late! But we know on the very first day of the project that will happen. Invent a solution. One of the most interesting technologies for this is virtualisation: you, or a vendor, builds a complete software model of the system. It is so complete that every bit of your embedded code will run on the model. Virtualisation products exist, and vendors have vast libraries of peripheral models. I was running one of these on my PC, but it was a Linux-based tool, so ran VMWare to simulate the Linux environment. The embedded system was based on Linux, so the system was simulating Linux simulating Linux—and it ran breathtakingly well. 5. Run your code through static analysers every night. That includes Lint, which is a syntax checker on steroids. Lint is a tough tool; it's one that takes some learning and configuration to reduce false positives. But it does find huge classes of very real, and very hard-to-find bugs. Also use a static analyser, one of those tools that does horrendous mathematical analysis of the code to infer run-time errors. In one case one of these tools found 28 null pointer dereferences in a single 200 KLOC infusion pump that was on the market. 6. Buy everything you can. Whether it's an RTOS, filesystem or a protocol stack, it's always cheaper to buy rather than build. And buy the absolute highest quality code possible. Be sure it has been qualified by a long service life, or even better by being used in a system certified to a safety-critical standard. Even if your product is as unhazardous as a TV remote control, why not use components that have been shown to be correct? 7. That last bit of advice applies to tools. Buy the best. A few $k, or even tens of $k, for tools is nothing. If a tool and the support given by the vendor can eek out even a 10% improvement in productivity, at a loaded salary of $150k or so it quickly pays for itself. 8. Use proactive debugging. OK—those last two words are my own invention, but it means assuming bugs will occur, and therefore seeding the code with constructs that automatically detect the defects. For example, the assert() macro can find bugs for as little as one 30th 6 of the cost of conventional debugging. 9. Include appropriate levels of security. Pretty much everything is getting hacked. Even a smart fork 7 today has Bluetooth and USB on board; that fork could be an attack vector into a network. Poor security means returns and recalls, or even lawsuits, so engineering effort will be squandered rather than invested in building new products. At the least, many products should have secure boot capabilities. Never have embedded systems been so complex as they are today. But we've never had such a wide body of knowledge about developing the code, and have access to tools of unprecedented power. It's important we exploit both resources. Endnotes: 1. Jones, Capers. Assessment and Control of Software Risks . Englewood Cliffs, N.J. Yourdon Press, 1994 2. Benediktsson, O. "Safety critical software and development productivity," The Second World Congress on Software Quality , Yokohama, Sept 25.-29, 2000 3. Dvorak, Dan and a cast of thousands. Flight Software Complexity , 2008 4. Wiegers, Karl. Peer Reviews in Software , 2001, and about a zillion other sources. 5. Glass, Robert. Facts and Fallacies of Software Engineering , 2002. 6. L. Briand, Labiche, Y., Sun, H. "Investigating the Use of Analysis Contracts to Support Fault Isolation in Object Oriented Code," Proceedings of International Symposium on Software Testing and Analysis , pp. 70-80, 2002. 7. www.hapilabs.com/products-hapifork.asp  

                                VGA TO HDMI 最佳解决方案 IT6613+CAT9883 一、方案简介 将VGA模拟信号和AUDIO信号转换成为高清格式的HDMI信号输出 二、应用领域 电脑主机、电脑笔记本、家庭DVD、家庭游戏机等带有VGA输出接口的视频产品 三、基本参数   IT6613 ·HDMI 1.4/ 3D TX ·1080p/12bit ·8ch Audio, HBR Audio ·100-pin LQFP   CAT9883C ·Triple ADC ·150/170MSPS – 8bit ·VGA or Component Input ·Color Space Conversion ·Auto Calibration     Eddie Ho /何泳标 eddie_ho@hkpowerplus.com 18926098883 柏华科技企业有限公司  

AV -TO- VGA 视频方案   连接示意图:   功能特点 ： 即插即用,无需安装任何软件,使用方便； 支持一路VIDEO,一路S-VIDEO输入,可用按键切换； 支持一路外部的VGA输入； 视频切换功能,可以在CVBS,S-VIDIO,VGA信号之间切换； 输出分辨率 ： 800X600@60Hz，800X600@75Hz，1024X768@60Hz，1280X1024@60Hz，1440X900@60Hz，1680X1050@60Hz，1920X1080@60Hz，1920X1200@60Hz； 带图像冻结功能； 自动制式切换功能,自适应NTSC和PAL制式； 图像清晰平稳不闪烁,色彩还原好,画面通透感极佳； 断电自动保存当前的工作状态。   性能介绍：     1   支持多种信号输入（S-VIDEO、CVBS、VGA）   2   将视频信号格式转换成倍频处理的高分辨率的VGA信号   3   支持全屏幕及水平满屏扫描，水平/垂直画面定位，水平/垂直屏幕调整   4   支持8种显示分辨率：800X600@60Hz — 1920X1200@60Hz   5   自适应PAL/NTSC制式，视频信号与VGA信号任意切换   6   图像亮度、对比度、色彩饱和度调节及图像冻结功能   7   输出信号:Composite VGA   8   电源供应：直流 DC 5V  1A 接口说明 :       名   称 说   明       (1)VGA In 接电脑主机       (2)BNC In 接视频源(如DVD、摄像头等)       (3)Svideo In 接S端子信号源       (4)VGA  Out 接电脑显示器       (5)DC 5V/1A       (6) 无 接电源 —— 按键功能 :     按键操作指令： ZOOM ：该按钮控制输出画面的缩放； AV/SV ：该按钮控制输入信号的切换； PIP：    该按钮实现AV/SV 转换器通过VGA连接在显示器上打开一个新的窗口。让你可以在使用电脑的同时观看到该窗口里的图像。按菜单，可以放大或缩小画面。按P.P按钮，可以实现画面的移动。 MODE： 该按钮控制输出信号的模式； MENU： 该按钮为菜单，控制设备中各项目的调节：亮度、对比度、色度 、色调、语言，同时按住P.P和PIP，可以更改项目数值 P.P：该按钮控制输出画面的分辨率调节。     深圳欣邺电子科技有限公司，国腾电子一级代理商。长期供应多款主打IC:GM7113、GM7123等。 联系方式： 公司网址：http://shinyek.com 商务QQ ：2544825113 手机：13510367354  传真：0755-86071153

HDMI ---VGA转换器   功能描述： 视频输入接口——HDMI HDMI输入格：720P,1080I,1080P 视频输出接口——VGA VGA输出分辨率:随输入的HDMI信号而变640x480*60Hz 、800*600@60Hz、1024*768@60Hz、1280*720@60Hz、1280*768@60Hz、1280*800@60Hz、1280*1024@60Hz、1360*768@60Hz、1600*1200@60Hz、 1920*1080@60Hz 音频输出接口——3.5mm HDMI输出格式：最高支持1080P/1.3 连接示意图：                     应用场景：   家用：让您的老显示器变成HDMI的高清显示器 行业用：能够在升级高清视频服务器时，无需购置新的HDMI监视设备   方案构成：   HDMI-VGA转换芯片 MCU HDMI Key     深圳欣邺电子科技有限公司，国腾电子一级代理商。长期供应多款主打IC:GM7113、GM7123等。 联系方式： 公司网址：http://shinyek.com 商务QQ ：2544825113 手机：13510367354  传真：0755-86071153