tag:blogger.com,1999:blog-41888892585264513282017-12-17T03:59:49.163-08:00VLSI Design Verification For Sharing ASIC/FPGA Design Verification ExperiencesJagdishnoreply@blogger.comBlogger17125tag:blogger.com,1999:blog-4188889258526451328.post-83641943839697607652016-12-20T09:05:00.000-08:002016-12-20T09:05:08.285-08:00CallbacksCallback is a method that is executed every time a known event occurs<br /><br /><ul><li>&nbsp;Testbench notification</li><li>Access occurs to the memory</li><li>Packet/Transaction is processed</li><li>No polling required</li></ul><div>Example uses of Callbacks</div><div><ul><li>End to end checking of data from testbench to DUT to testbench</li><li>Error injection</li><li>Check for spurious or unnecessary transactions</li><li>Collect functional coverage statistics&nbsp;</li></ul></div>Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-82335470246877959702016-08-18T01:21:00.000-07:002016-08-18T01:21:29.429-07:00Verification goalThe goal of verification is complete testing the design according to specification with the highest quality in the shortest period of time.<br /><br />Environment creation and testcase development<br />Coverage<br />Finding bugs in early stage<br />Mixedsignal, Clock and reset<br />GLS<br /><br /><br />Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-83955728829689460992016-08-18T00:53:00.000-07:002016-08-18T00:53:05.705-07:00Functional Coverage<br /><ul><li>FC is watchdog and extra check&nbsp;</li><li>&nbsp;Checks both Design and its Verification Qualities&nbsp;</li><li>helps develop new testcases for verification completeness&nbsp;</li></ul><div>To implement Functional Coverage we need to understand Design Spec&nbsp;</div><div><br /></div><div><br /></div><br /><br />Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-90819307124228216002016-04-24T23:29:00.005-07:002016-07-15T11:34:57.821-07:00SV constraint exampleConstraint c_valid_rate;<br /><br /><h4><div style="text-align: justify;"><span style="color: red;">constraint</span> phyFrameRandFullSeq::c_valid_rate {</div>&nbsp; &nbsp; <span style="color: red;">Solve</span> mPktType <span style="color: red;">before</span> mBaseRate;<br /><span style="color: red;">if&nbsp;</span>(mPktType == WIFIDOT) {<br />&nbsp;mBaseRate <span style="color: red;">inside</span> {1, 2, 5, 11};<br />} <span style="color: red;">else if</span>(mPktType == WIFIDOT1) {<br />mBaseRate inside { 6,12, 18} ;<br />&nbsp; }<br />}</h4>Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-16366690225805553172009-08-01T05:41:00.001-07:002009-08-01T05:41:47.643-07:00Leadership - Training by Spreadminds<img style="visibility:hidden;width:0px;height:0px;" border=0 width=0 height=0 src="http://counters.gigya.com/wildfire/IMP/CXNID=2000002.0NXC/bHQ9MTI*OTEzMDg*MTE1NyZwdD*xMjQ5MTMwODY1NTk2JnA9MTAxOTEmZD1MSV9zdl8lMGElMDlwcmVzZW5*YXRpb24lMDkmbj1ibG9nZ2VyJmc9MSZvPWI5NTMyZGNjMjYzNTQxYWU4NzA*NTQ5ZWRkMTUzOTNkJm9mPTA=.gif" /><div style='width:425px;text-align:left'><object style='margin:0px' width='425' height='355'><param name='movie' value='http://static.slideshare.net/swf/ssplayer2.swf?doc=leadership-trainingv1-1227410222472541-9&stripped_title=leadership-training-by-spreadminds-presentation' /><param name='allowFullScreen' value='true'/><param name='allowScriptAccess' value='always'/><embed src='http://static.slideshare.net/swf/ssplayer2.swf?doc=leadership-trainingv1-1227410222472541-9&stripped_title=leadership-training-by-spreadminds-presentation' type='application/x-shockwave-flash' allowscriptaccess='always' allowfullscreen='true' width='425' height='355'></embed></object></div>Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-81409427717626068982009-08-01T05:33:00.001-07:002009-08-01T05:33:34.171-07:00So You Want To Be A Consultant?<img style="visibility:hidden;width:0px;height:0px;" border=0 width=0 height=0 src="http://counters.gigya.com/wildfire/IMP/CXNID=2000002.0NXC/bHQ9MTI*OTEzMDM1MTI*NiZwdD*xMjQ5MTMwMzcyMDQ*JnA9MTAxOTEmZD1MSV9zdl8lMGElMDlwcmVzZW5*YXRpb24lMDkmbj1ibG9nZ2VyJmc9MSZvPWI5NTMyZGNjMjYzNTQxYWU4NzA*NTQ5ZWRkMTUzOTNkJm9mPTA=.gif" /><div style='width:425px;text-align:left'><object style='margin:0px' width='425' height='355'><param name='movie' value='http://static.slideshare.net/swf/ssplayer2.swf?doc=stout-so-you-want-to-be-a-consultant-1234548336147370-1&stripped_title=so-you-want-to-be-a-consultant' /><param name='allowFullScreen' value='true'/><param name='allowScriptAccess' value='always'/><embed src='http://static.slideshare.net/swf/ssplayer2.swf?doc=stout-so-you-want-to-be-a-consultant-1234548336147370-1&stripped_title=so-you-want-to-be-a-consultant' type='application/x-shockwave-flash' allowscriptaccess='always' allowfullscreen='true' width='425' height='355'></embed></object></div>Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-87645449073986621512009-08-01T05:15:00.001-07:002009-08-01T05:15:49.023-07:00Leadership Training<img style="visibility:hidden;width:0px;height:0px;" border=0 width=0 height=0 src="http://counters.gigya.com/wildfire/IMP/CXNID=2000002.0NXC/bHQ9MTI*OTEyOTE5MDcxMyZwdD*xMjQ5MTI5MzEwMzAwJnA9MTAxOTEmZD1MSV9zdl8lMGElMDlwcmVzZW5*YXRpb24lMDkmbj1ibG9nZ2VyJmc9MSZvPWI5NTMyZGNjMjYzNTQxYWU4NzA*NTQ5ZWRkMTUzOTNkJm9mPTA=.gif" /><div style='width:425px;text-align:left'><object style='margin:0px' width='425' height='355'><param name='movie' value='http://static.slideshare.net/swf/ssplayer2.swf?doc=tmt081001-1222922304173182-9&stripped_title=leadership-training-presentation' /><param name='allowFullScreen' value='true'/><param name='allowScriptAccess' value='always'/><embed src='http://static.slideshare.net/swf/ssplayer2.swf?doc=tmt081001-1222922304173182-9&stripped_title=leadership-training-presentation' type='application/x-shockwave-flash' allowscriptaccess='always' allowfullscreen='true' width='425' height='355'></embed></object></div>Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-3485499934364235982009-08-01T04:46:00.001-07:002009-08-01T04:46:01.720-07:00Biotechnology Marketing 101 Your Company<img style="visibility:hidden;width:0px;height:0px;" border=0 width=0 height=0 src="http://counters.gigya.com/wildfire/IMP/CXNID=2000002.0NXC/bHQ9MTI*OTA1NTQwNTEzMyZwdD*xMjQ5MTI3NTE4NjMwJnA9MTAxOTEmZD1MSV9zdl8lMGElMDlwcmVzZW5*YXRpb24lMDkmbj1ibG9nZ2VyJmc9MSZvPWI5NTMyZGNjMjYzNTQxYWU4NzA*NTQ5ZWRkMTUzOTNkJm9mPTA=.gif" /><div style='width:425px;text-align:left'><object style='margin:0px' width='425' height='355'><param name='movie' value='http://static.slideshare.net/swf/ssplayer2.swf?doc=BiotechnologyMarketing101YourCompany-123479945372-phpapp01&stripped_title=Biotechnology-Marketing-101Your-Company' /><param name='allowFullScreen' value='true'/><param name='allowScriptAccess' value='always'/><embed src='http://static.slideshare.net/swf/ssplayer2.swf?doc=BiotechnologyMarketing101YourCompany-123479945372-phpapp01&stripped_title=Biotechnology-Marketing-101Your-Company' type='application/x-shockwave-flash' allowscriptaccess='always' allowfullscreen='true' width='425' height='355'></embed></object></div>Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-51037410380242961152008-02-18T22:55:00.000-08:002008-02-18T22:56:42.753-08:00Terminalogy<span style="font-size:130%;"><strong>Antenna Effect</strong></span>: During the processing of VLSI chips,the wafers can<br />collect charges.If a long metal line is getting connected to a gate<br />(which typically will be) ,and if this strip of metal collects<br />enough charges to breakdown the gate,the gate gets damaged<br />permanently. TO avoid this people use various techniques like going<br />to one metal above and coming back if they think that the metal strip<br />is very long.Other technique is to have a diode connected to the<br />metal line in a proper direction to discharge these extra charges.<br /><br /><strong>Electromigration:</strong> As the name suggests,when very large currents flow<br />in a metal and if the metal is not able to carry that much current,<br />it(the metal strip) may get knocked out creating a open here,and<br />short somewhere else(plausible).Basically the metal width and<br />thickness should be sufficient to carry that much current.This is a<br />reliability issue.It can happen at any "micron" technology,not only<br />sub-micron.<br /><br /><strong>Cross-talk:</strong> This term is interchangeably used with coupling<br />capacitance. It is self-explanatory.<br /><br />The reason for antenna effect is still debated.Whatever the reson is<br />like the metal line connected to a gate getting charged or<br />someother,if the metal line length to gate area is more than some<br />critical value,it is seen that gate gets damaged.So people tend to<br />limit the length of the metal line.<br /><br />Are you considering the issue of cross-talk. Cross-talk is related to<br />line length and proximity of two lines. Thus, long adjacent lines can<br />couple better than short lines. Is this what you consider? Or, are<br />you purposely limiting the length of the line because of some other<br />manufacturing issue. Why impose a rule unless you understand the<br />reason?<br /><br />Crosstalk is dynamic problem,ie when the device is in operation,it is<br />a speed issue,not a reliability issue.But,the thing being talked<br />about here is a reliability issue and it is related to the process.<br />The above section talks about the charges that would build up on the<br />metal interconnects during high energy plasma processes such as dry<br />etching in fabrication. These charges may eventually end up at and<br />cause damage to the thin gate oxide of the transistors. The charge<br />build up is understood to be due to plasma non-uniformity in the<br />reactors. The effect can be partly be prevented by maintaining<br />uniform plasma in the reactor as well as by providing on-chip<br />protection elements such as clamp diodes across thin gate oxides.<br />Design rules that take into account the antenna ratios i.e., for a<br />given gate oxide area, the maximum interconnect length and area that<br />can be supported before a protection diode is needed are usually<br />followed.<br /><br />Antenna efects are are long floating interconnects that acts as<br />temporary capacitors during the metalisation process.Because a<br />conducting path to ground does not exist at the time of metalisation,<br />a random discharge from the floating nodes can cause permanent gate<br />oxide damage. Since it is a mater of capacitance, length and other<br />dimensions of the interconnect also plays a role. Solution: Inserting<br />buffers or diodes near the input pins to provide conducting path to<br />ground eleminates this problem And there is a way to minimize the no.<br />of charges collected by floating node by inserting jumpers.Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-288733548999596172008-01-31T02:41:00.001-08:002008-01-31T02:38:19.365-08:00Using model-based design in signal integrity engineering <DIV>Using model-based design in signal integrity engineering <BR><IMG height=5 alt="" hspace=0 src="http://i.cmpnet.com/rfdesignline/blank.gif" width=2 border=0><BR><SPAN class=orange12BOLD></SPAN><BR><IMG height=3 alt="" hspace=0 src="http://i.cmpnet.com/rfdesignline/blank.gif" width=2 border=0><BR> <TABLE cellSpacing=0 cellPadding=0 width=420 border=0> <TBODY> <TR> <TD align=left width=200><SPAN class=byline>By Colin Warwick, The MathWorks </SPAN></TD> <TD align=right width=200></TD></TR></TBODY></TABLE><!--body--><A href="http://www.rfdesignline.com/">RF</A> techniques, originally developed for wireless communication projects, are being repurposed to solve the increasingly complex problem of preserving signal integrity in high-speed data transmission between chips joined by backplanes and printed circuit boards. These pin-to-pin connections are becoming mini-communication systems in their own right. In parallel, Model-Based Design is being adopted for these projects to significantly speed the design process, through a graphical environment with prebuilt, optimized algorithms and blocks. This article addresses the convergence of these two trends. <P><B>Planning a typical application</B><BR>We'll use Model-Based Design and <A href="http://www.rfdesignline.com/encyclopedia/defineterm.jhtml?term=RF&amp;x=&amp;y=">RF</A> techniques to create an impairment model of the backplane that is used as a test environment in both the modeling and design phases for the development of mitigating algorithms. <P>The first step is to use a vector <A href="http://www.rfdesignline.com/encyclopedia/defineterm.jhtml?term=network analyzer&amp;x=&amp;y=">network analyzer</A> (VNA) to measure the frequency-domain response of the backplane and record it in an S4P (four-port) Touchstone file. Modified rational functions are then used to fit the frequency domain data to a time-domain behavioral transfer function. The resulting transfer function is used as a test environment in the development of mitigating algorithms in a Simulink® model. A Verilog-A version of the transfer function is generated for verification of the circuit design. The circuit design can be based on the model and completed using electronic design automation (EDA) tools. <P><B>Signal integrity challenges</B><BR>The increasing speeds used in telecommunication and data communication infrastructures have made it more difficult than ever to achieve data transmission at sufficiently low bit error rates (BERs). A signal sent from a gigabit per second transmitter on the I/O pin of one chip travels first along a trace on a plug-in card, then across a backplane to another plug-in card that contains the receiving chip. The signal often becomes degraded by intersymbol interference (ISI), frequency-selective attenuation, and <A href="http://www.rfdesignline.com/howto/201001723">crosstalk</A>. The ISI impairment is caused by reflections, typically caused in turn by impedance mismatch at various interconnection discontinuities. These impairments become more severe as the data rate increases. By contrast, when data rates are below 1 Gb/s, we can rely on a fairly flat backplane frequency response. Also, the echoes of previous pulses decay before the next one comes along, so ISI is less of an issue. <P>Today, data rates are usually well above 1 Gb/s, so the echo decay time is longer than the pulse spacing, and the received pulse is mixed up with echoes of the previous pulse. The job of signal integrity engineering is to mitigate this and other impairments. Design of adequate mitigating algorithms, such as a pre-emphasis filter for the transmitter and a decision feedback equalizer (DFE) for the receiver, requires an accurate model of the impairment. <P>The fact that the backplanes and the chips with the I/O transceivers are produced by different companies increases the complexity of the design process. In order to facilitate a dialog between these two groups, equipment manufacturers develop behavioral models of the backplane. Semiconductor companies use these models as a test environment for transceiver design. Chip companies furnish behavioral models of the I/O design so that backplane makers can check the range of backplane designs in which the transceiver can operate successfully. The design process naturally involves a fair amount of iteration because when the equipment manufacturer changes a design it may change the test environment for the chip maker and vice versa. The companies involved typically go back and forth modifying their designs and models until the complete system meets performance specifications. <!--end body--></P><!--body--><B>Applying the modified rational function method</B><BR>We can simplify the design process for the data transmission application using Model-Based Design. The transmission line will be modeled as a modified rational function using <A href="http://www.mathworks.com/products/matlab/">MATLAB</A> and <A href="http://www.mathworks.com/products/rftoolbox/">RF Toolbox </A>. A modified rational function is a transfer function in the form of a particular type of Laplace transform. The general Laplace transform is the integral over time of a function of time <I>f(t)</I> with a complex sine wave <I>e<SUP>-st</SUP></I> <P> <CENTER><IMG src="http://i.cmpnet.com/rfdesignline/2007/07/MW_Eq1.gif"></CENTER><BR> <P>In the modified rational function, f(s) consists of residues <I>c<SUB>j</SUB></I>and poles <I>a<SUB>j</SUB></I>which are complex conjugate pairs. Correspondingly in the time domain, <I>f(t)</I> consists of a direct feed term <I>d&#948;(t-t<SUB>d</SUB>)</I> plus a set of exponentially decaying sine waves, which begin after the principle delay t<SUB>d</SUB> <P> <CENTER><IMG src="http://i.cmpnet.com/rfdesignline/2007/07/MW_Eq2.gif"></CENTER><BR> <P>The modified rational function has the following advantages: <BR> <UL> <LI>We can achieve the same level of accuracy as the IFFT method, with a model that is one or two orders of magnitude simpler. <LI>Model order reduction can be used to trade off complexity and accuracy through the use of fitting parameters. <LI>Typical VNA data has a low frequency cutoff at around 20 to 50 MHz, so an extrapolation to <A href="http://www.rfdesignline.com/encyclopedia/defineterm.jhtml?term=DC&amp;x=&amp;y=">DC</A> is needed. With IFFT models, there is nothing to prevent the extrapolated phase from being nonzero, which corresponds to a nonphysical delay. <LI>This can be avoided by writing a constraint algorithm, but this takes time. In contrast, rational models represent a physical transmission line. So the phase on extrapolation to DC is inherently zero, avoiding the need for constraint algorithms. <LI>The physical correspondence between the model and transmission line also provides greater insight when building mitigating algorithms. For example, seeing what poles exist on the transmission line is very helpful when building the DFE. </LI></UL> <P><B>Fitting a rational function to VNA data</B><BR>The first step is creating a model of the impairment using S4P data from the VNA. In this example, the S4P data includes about 1,500 frequencies from 50 MHz to 50 GHz. After reading the file into MATLAB via the RF Toolbox read function, we use the s2sdd function to extract the equivalent differential two-port behavior of this four-port network. The next step is to compute the transfer function and rational model. The frequency domain transfer function of the two-port parameters is calculated with the "s2tf" function. Then the "rationalfit" function is used to compute the time-domain modified rational function. The end result is that about 24,000 data points are condensed into a simple 48-pole rational function fit. <P><!--end body--></P> <DIV></DIV><!--body-->We can check the rational function and visualize it in MATLAB and RF Toolbox before the next step, which is to run a script that reformats the backplane model for use in Simulink. <P> <CENTER><IMG src="http://i.cmpnet.com/rfdesignline/2007/07/MWorks_Fig1.jpg"></CENTER><BR><I> <CENTER>1. Frequency response (above left) of a rational function model created from measured S-parameters. The model was used to create the eye diagram (above right) for analyzing intersymbol interference.</I></CENTER> <P> <P><B>Modeling the backplane in Simulink</B><BR>The reformatting script works by setting the coefficients of several existing Simulink blocks, joining them into a simple structure, and collecting the result in a subsystem. The poles and residues of the rational function model are converted into numerator and denominator form for use in the Laplace Transform transfer function blocks. Each transfer function block represents either one real pole and residue or a pair of complex conjugate poles and residues. Either way, each transfer function block always has real coefficients. <P>In this example, the rational function model contains two real poles and residues and 10 pairs of complex poles and residues, so the model contains 12 transfer function blocks. The principle delay is modeled with a Transport Delay block. Then the subsystem is exercised by connecting a simple test harness consisting of a random message source connected to input. Scopes and a BER meter are used to quantify the impairment. Once the subsystem is performing as expected, the next stage, not covered in detail here, is to develop models of the mitigating algorithms, such as pre-emphasis filters and DFEs. <P> <CENTER><IMG src="http://i.cmpnet.com/rfdesignline/2007/07/MWorksFig2.jpg"></CENTER><BR><I> <CENTER>2. The rational function model can be used in a Model-Based Design workflow, where algorithms that mitigate the impairment (such as preemphasis and equalization) are developed.</I></CENTER> <P><!--end body--></P> <DIV></DIV><!--body--><B>Modeling the Backplane in EDA tools</B><BR>We can use popular EDA tools to create the circuit-level design based on the algorithms we modeled. To verify the design we'd like to reuse the impairment model in the EDA environment. We can do this by exporting the modified rational function once more, this time as a behavioral Verilog-A module, a preferred form for EDA tools. <P>The module includes the Verilog-A "laplace_nd()" function with the appropriate numerator/denominator coefficients. The principle delay is created using the Verilog-A "absdelay()" function. We can then run this Verilog-A module inside an EDA tool to verify the design of the circuitry that implements the mitigating algorithms. <P> <CENTER><IMG src="http://i.cmpnet.com/rfdesignline/2007/07/MWorksFig3.jpg"></CENTER><BR><I> <CENTER>3. The rational function model can be exported in Verilog-A behavioral format. This module is then imported into a mixed-signal circuit simulator, and is used in the design phase of Model-Based Design.</I></CENTER> <P><B>Design success</B><BR>This example shows how system architects are using RF techniques and Model-Based Design to rapidly develop signal integrity systems and algorithms. Model-Based Design involves the creation of executable models in a block diagram design environment using blocks that represent algorithms or subsystems. A key to the success of Model-Based Design is the existence of libraries of prebuilt standard data transmission algorithms or blocks, such as digital filters, transforms, and spectral analysis tools. Libraries of visual blocks enable BER plots, constellation diagrams, and eye diagrams to be quickly and easily added to models. <P>These libraries enable systems to be built extremely quickly by dragging and dropping the algorithms or blocks from a library into the model and then joining the blocks. This flexibility also enables models to be changed very easily and quickly. The result is that engineers can focus their efforts on what's important, namely the algorithms and systems being tested. <P>Model-Based Design offers several major advantages for signal integrity engineering. The biggest is that models can be changed much more easily and rapidly than <A href="http://www.rfdesignline.com/encyclopedia/defineterm.jhtml?term=C&amp;x=&amp;y=">C</A> code. The behavior of blocks can be changed quickly by altering their parameters. Structural changes can be made promptly by adding or removing blocks from a model by dragging and dropping " without the need to recompile the model. The results of changes can be examined using the visual blocks, for example, to show the BER after code has been added to a model. This allows different designs and algorithms to be evaluated extremely quickly. C-coded models cannot offer this level of flexibility. This makes Model-Based Design especially appropriate to signal integrity engineering. <P><B>About the Author</B><BR>Colin Warwick is an RF Product Manager at The MathWorks. He is focused on the verification of RF, analog, and mixed-signal subsystems in the context of Model-Based Design for signal processing and communications applications. Colin can be reached at colin.warwick@mathworks.com. <P><B>Related Articles</B><BR><A href="http://www.rfdesignline.com/howto/201001723">Tip of the week: Six ways to avoid cross-talk interference </A><BR> <P><A href="http://www.rfdesignline.com/showArticle.jhtml;?articleID=198500666">Signal integrity approaches meet the multi-Gbps design challenge</A><BR> <P><A href="http://www.rfdesignline.com/showArticle.jhtml;?articleID=196802887">Basics of chip/package codesign in a large flipchip application</A><BR></P></DIV>Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-83709170308760014102008-01-31T02:41:00.000-08:002008-01-31T02:37:31.706-08:00Signal integrity approaches meet the multi-Gbps design challenge <DIV><SPAN class=storyHEADLINE>start:Signal integrity approaches meet the multi-Gbps design challenge</SPAN> <BR><IMG height=5 alt="" hspace=0 src="http://i.cmpnet.com/rfdesignline/blank.gif" width=2 border=0><BR><SPAN class=orange12BOLD>High-speed data paths now lie on the critical path of product development; you can combine multiple approaches, including S-parameters, for effective signal-integrity analysis </SPAN><BR><IMG height=3 alt="" hspace=0 src="http://i.cmpnet.com/rfdesignline/blank.gif" width=2 border=0><BR> <TABLE cellSpacing=0 cellPadding=0 width=420 border=0> <TBODY> <TR> <TD align=left width=200><SPAN class=byline>By Dr. Mike Heimlich, Applied Wave Research, Inc. and Dr. Scott Wedge, Synopsys, Inc. </SPAN></TD> <TD align=right width=200></TD></TR></TBODY></TABLE><!--body-->The wireless explosion has spawned a frontier with countless market opportunities for communications companies. The increasing complexity of today's electronics products, however, has created a myriad of issues for designing and bringing to market these technology-rich applications. Electronic design automation (EDA) software is an important tool in the product generation process, and a key concern inherent in the design of next-generation, high-performance communications products is complex cross-domain signal <A href="http://www.planetanalog.com/encyclopedia/defineterm.jhtml?term=integrity&amp;x=&amp;y=">integrity</A> (SI) issues. <BR> <P> <P>Signal integrity (SI) analysis has traditionally been used as a verification step prior to releasing a design for manufacturing. This methodology served the high-speed design community well as <A href="http://www.planetanalog.com/encyclopedia/defineterm.jhtml?term=clock&amp;x=&amp;y=">clock</A> frequencies and data rates pushed through 100 <A href="http://www.planetanalog.com/encyclopedia/defineterm.jhtml?term=MHz&amp;x=&amp;y=">MHz</A> and approached 1 GHz. But with today's communications designs with data rates of 3 to 5 gigabits/sec (Gbps) and beyond, the fundamental assumptions that used to permit "fixing up" the timing at the end of the design cycle are no longer viable. High-speed data paths now lie on the critical path of product development and a new, more proactive approach to SI is needed. <BR> <P> <P><B>Multi-Gbps design challenges</B><BR> <P>The design of high-frequency (above 1 GHz) interconnects can be an issue across all parts of the design, from on the chip itself, moving off the chip and through the packaging, and onto the board, or all of these at the same time. Communications companies who are developing products with increasing frequencies and <A href="http://www.planetanalog.com/encyclopedia/defineterm.jhtml?term=edge&amp;x=&amp;y=">edge</A> rates, and using traditional printed circuit board (PCB) signal-integrity solutions, are finding that their designs look good in simulation (<B>Figure 1a</B>), but when they build and measure their prototypes they get very different and disappointing results (<B>Figure 1b</B>). <BR> <P> <P> <CENTER><A href="http://i.cmpnet.com/planetanalog/2007/03/C0171-Figure1a.gif"><IMG height=230 src="http://i.cmpnet.com/planetanalog/2007/03/C0171-Figure1a.gif" width=350 border=0></A><BR><I>. </U></I><BR><I>(Click on image to enlarge.) </I></A></CENTER><BR> <P> <P> <CENTER><A href="http://i.cmpnet.com/planetanalog/2007/03/C0171-Figure1b.gif"><IMG height=240 src="http://i.cmpnet.com/planetanalog/2007/03/C0171-Figure1b.gif" width=350 border=0></A><BR><I>Figure 1 (a) and (b). Simulated design results (upper image) vs. measured prototype results (lower image). <P></U></I><BR><I>(Click on image to enlarge.) </I></A></CENTER><BR> <P> <P>Consequently, they find themselves spending excessive time and money on redesigns, re-spins, and experimenting on the test bench, adding cost to their final products not only with additional "fix-it" components (capacitors, inductors, etc.) but ultimately in lost time-to-market opportunities. <BR> <P> <P>Why such large discrepancies between simulated and measured results? At frequencies up to several hundreds of MHz, interconnects can be modeled as lumped, passive-element RLGC or RLCK models. This modeling technique has been effective since the days when SI issues first surfaced starting with 33 MHz PC designs. A single lumped-element equivalent circuit model for interconnects was sufficient to capture high-frequency effects, and allow SI analysis to confirm that timing constraints and signal quality requirements were met. <BR> <P> <P>But at <A href="http://www.planetanalog.com/encyclopedia/defineterm.jhtml?term=GHz&amp;x=&amp;y=">GHz</A> frequencies, with clock edges measured in picoseconds, the old lumped element approximations become grossly inadequate. Interconnects must now be modeled as coupled transmission lines with propagation and loss characteristics having strong frequency dependence due to dispersion, skin effect, and dielectric loss. The result is that the commonly-used RLCK modeling and simulation technology can no longer provide accurate or dependable results. High-frequency models and simulation technology must be incorporated to design, simulate, and validate a manufactured product that will actually work as designed. <BR> <P> <P><B>Figure 2</B> displays a spectral analysis of a 1 GHz pseudorandom binary sequence (PRBS) waveform with 100 ps rise/fall edges. <BR> <P> <CENTER><A href="http://i.cmpnet.com/planetanalog/2007/03/C0171-Figure2.gif"><IMG height=240 src="http://i.cmpnet.com/planetanalog/2007/03/C0171-Figure2.gif" width=350 border=0></A><BR><I>Figure 2. Spectral analysis of a 1-GHz PRBS waveform </U></I><BR><I>(Click on image to enlarge.) </I></A></CENTER><BR> <P>The RLCG models provide enough accuracy up to about 1 GHz, but as this spectrum plot shows, depending upon the system signal-to-noise ratio (SNR), there is significant frequency content from a 1 GHz data rate out to 20 GHz and beyond. <BR> <P> <P>Besides the speed of the signals and edge rates, designing across different manufacturing domains is also a critical issue. In order to optimize system-in-package (SiP) or module designs, it is important to be able to co-design individual die across packaging and sometimes with the PCB. In order to increase confidence in the design, the effects of all components in the signal path should be considered concurrently. A good design system must have the ability to simulate the entire path, including the IC or at least the IC I/O buffers, at the transistor level for the most accurate and dependable results. But most flows today are based on tools that do not permit this kind of seamless interaction between chip and board, and the electrical and physical domains. <BR> <P> <P><B>Efficient design requires modern data modeling</B> <BR> <P>Traditional EDA tools architectures were developed in the late 1980's and early 90's. The state of the art then was to have a unique database for each step of the design flow and to then integrate databases with layers and layers of software called "frameworks" (<B>Figure 3</B>). <BR> <P> <CENTER><A href="http://i.cmpnet.com/planetanalog/2007/03/C0171-Figure3.gif"><IMG style="WIDTH: 604px; HEIGHT: 324px" height=150 src="http://i.cmpnet.com/planetanalog/2007/03/C0171-Figure3.gif" width=350 border=0></A><BR><I>Figure 3. Traditional EDA tools with separate data files for each step vs. modern solutions with a single unified data model. </U></I><BR><I>(Click on image to enlarge.) </I></A></CENTER><BR> <P>The result was that each step of the design processor "view" of the designhad its own database and its own use-model. This delivers a very serial flow, with any given engineer only able to master one or two steps or tools in the flow. The result is that the design is spread out over many different tools, and it is difficult or impossible to ensure that all the data is synchronized. Synchronization of the design can take hours, days, or weeks, if it happens at all. <BR> <P> <P>More modern solutions have been introduced in the past ten years which offer a completely different approach through a single, unified data model. These include several new technologies that have recently matured: C++ and object-oriented design, and component object modeling and databases. The newer solutions, such as AWR's SI® design suite, which was used in the design methodology for this paper, enable all of the tools or views needed to design GHz electronics to be inherently synchronized by using the same database. <BR> <P> <P>This results in much shorter design cycles, because there is no extra effort needed to synchronize the design. Such an arrangement of single database with multiple tools/views is sometimes referred to as a unifying or unified data model (UDM). With a UDM, there is also no penalty in terms of time or data lost (from incomplete translations) in switching between different steps in the flow. <BR> <P> <P>For the SI analysis flow in flux at multi-Gbps rates, the UDM is a potential solution. Rather than having to wait until very late in the flow to have access to completed layouts for post-layout SI analysis, the UDM provides early incremental access of electromagnetic (EM) simulation results to the SI engineer prior to, or as part of, formal PCB layout. In this way, interconnects for critical serial links can not only be designed before the integrating PCB layout step, they can also be analyzed post-layout, thereby providing a greater degree of certainty that the interconnects will perform adequately at frequency. <BR> <P> <P>Furthermore, the UDM has the ability to concurrently manage multiple stack-ups, or technology files, representing the ICs, their packages, the PCB, and all associated die-to-board electrical models. This gives the SI designer much more flexibility for verification. No longer is it necessary to extract macro-models of IC-level components for simulation with package- and PCB-level models. The SI engineer can now co-design module-level interconnects with driver and receiver circuitry at the transistor level, while including the effects of bond-wires and surface mount PCB devices. Packaging limitations and die constraints can be taken into account early in the design process. This avoids after-the-fact design problems that can result from oversimplified off-die load models, and eliminates the painful debugging process of trying to fix them. <BR> <P> <P><B>Chip/package/board simulations</B><BR> <P>In addition to a UDM for concurrency and co-design, powerful simulation technology is needed that can analyze the diverse set of component models comprising signal integrity data links. <B>Figure 4</B> depicts this need schematically. <BR> <P> <CENTER><A href="http://i.cmpnet.com/planetanalog/2007/03/C0171-Figure4.gif"></A><IMG style="WIDTH: 1017px; HEIGHT: 422px" height=544 src="http://i.cmpnet.com/planetanalog/2007/03/C0171-Figure4.gif" width=1240><BR><I>Figure 4. Gigabit applications involve modeling a chain of components. </U></I><BR><I>(Click on image to enlarge.) </I></A></CENTER><BR> <P>Transistor-level IC models are needed for accurate I/O buffer and serializer/deserialer (SERDES) phase locked loop (PLL) simulations. Transmission line and S-parameter models are needed for accurate package and interconnect simulations. <BR> <P> <P>One of the very few circuit simulation products addressing this challenge is HSPICE® from Synopsys, Inc. For over 25 years, HSPICE has been the standard in IC circuit simulation. All major foundries provide HSPICE transistor models for sign-off simulation, and chip vendors provide either IBIS or triple-DES encrypted netlists for HSPICE simulation. <BR> <P> <P>The IC-level modeling support of HSPICE is therefore considered the most validated and trustworthy SI solution available. In addition, HSPICE provides two significant technologies for modeling off-chip components: a generalized modeling capability for lossy coupled transmission lines, and the ability to perform simulations directly from S-parameter data sets. <BR> <P> <P>Coupled transmission lines are modeled in HSPICE using an approach based on distributed RLGC matrices referred to as the W-element. The approach is very general and applicable for most interconnect systems, due in part to the ability to represent any number of coupled interconnects, and an ability to handle substantial frequency dependence. Any system of uniform coupled transmission lines can be characterized with RLGC matrices. <BR> <P> <P>Unlike the RLCG models of the past that map to simple lumped-element equivalents, RLGC matrices represent a complete mathematical description of the complex distributed propagation characteristics of coupled transmission line systems. Matrix values can be derived from physical trace geometry, using electromagnetic field solvers (such as HSPICE's built-in 2D EM solver), or by converting from the propagation and impedance parameters used in board-level transmission line component libraries. <BR> <P> <P>Frequency-dependent RLGC matrix values are critical for modeling GHz loss effects due to skin effect (conductors) and loss tangent (dielectrics). Interconnects also possess dispersion at GHz frequencies, resulting in frequency-dependent propagation factors, which are also captured as RLGC frequency dependence. Such methods have allowed W-element models to align with measured data at frequencies as high as 40-110 GHz. <BR> <P> <P>But the most impressive aspect of the W-element is its ability to provide fast and accurate time-domain simulations. Most tools that use frequency-domain models for time-domain simulation employ convolution calculations that are notoriously slow. The W-element, however, uses techniques that efficiently separate propagation, reflection, and loss factors, enabling fast recursive convolution while ensuring causality and passivity. <BR> <P> <P><B>S-parameters fuel successful SI design</B><BR> <P>S-parameters, also called scattering parameters, have become the preferred method for characterizing passive components which are not well modeled by SPICE or transmission line methods. S-parameter data sets may originate from EM simulation, from direct vector network analyzer measurements, or from a linear circuit simulation of portions of an SI link. There is a definite trend towards encapsulating much of the off-chip design into a few large S-parameter data sets. In the case of IC package models, very large S-parameter data files may be involved. Efficient handling of such data has therefore become a priority for SI simulation. <BR> <P> <P>The HSPICE S-element allows S-parameter data files to be used directly for simulation. Convolution calculations are performed automatically for time-domain simulation. Several options are available for handling S-parameter data in the most efficient ways possible. For large data files used to represent IC packages, HSPICE generates reduced order models (ROM) that can be efficiently analyzed with recursive convolution. <BR> <P> <P>When S-parameter data is available for transmission lines, the data can be used as input for specifying a W-element model (<B>Figure 5</B>). <BR> <P> <CENTER><A href="http://i.cmpnet.com/planetanalog/2007/03/C0171-Figure5.gif"><IMG style="WIDTH: 505px; HEIGHT: 722px" height=515 src="http://i.cmpnet.com/planetanalog/2007/03/C0171-Figure5.gif" width=350 border=0></A><BR><I>Figure 5. HSPICE supports several options for S-parameter data input, including the ability to extract W-element transmission line models from scattering parameter data. </U></I><BR><I>(Click on image to enlarge.) </I></A></CENTER><BR> <P>Transmission-line propagation and RLGC values are then calculated automatically, allowing the W-element to apply fast recursive convolution calculations for time-domain simulation. HSPICE includes a variety of advanced sS-parameter data interpolation and extrapolation schemes to handle things such as proper behavior at DC (zero frequency), insufficient data sampling at resonant frequencies, and smoothing for noisy measurements. <BR> <P> <P>A solution based on a unified data model, combined with the SI simulation strengths of HSPICE, offers unique design flow advantages to meet the needs for multi-Gbps SI design and simulation. The design software adaptively maps complete chip/package/board links into simulation-ready HSPICE models. For distributed elements, models can be mapped from a passive element library validated for microwave applications, up to and beyond 100 GHz, into the HSPICE W-element for single schematic co-simulation in frequency- and time-domains. <BR> <P> <P>The HSPICE software also includes a special interface layer for rational function approximations of S-parameter data sets. Using Foster's canonical form, the interface enforces passivity and guarantees causality for HSPICE time-domain simulation, whether directly from S-parameter data files or the result of integrated, concurrent EM analyses within the design suite. This, combined with HSPICE's trustworthy IC device and IBIS models, provides a comprehensive chip/package/board signal integrity simulation solution. High data-rate signal paths can be designed with on-chip and off-chip awareness, and then taken to fabrication by exporting to enterprise PCB tools. <BR> <P> <P><B>Conclusion</B><BR> <P>The design of next-generation, high-performance communications products requires the consideration of complex cross-domain SI issues. This paper has outlined a modern SI design methodology that utilizes a top-down approach to IC, packaging, and PCB SI, enabling engineers to meet the challenges presented by multi-Gbps design issues. This approach solves many SI issues early in the design phase, prior to analysis, saving design iterations and shortening time-to-manufacture. <P><B>About the authors</B><BR><B><I>Scott Wedge</B></I>, Ph.D (wedge@synopsys.com) is a senior staff engineer with <A href="http://www.synopsys.com/">Synopsys Corporation</A>. He has authored numerous technical papers on RF/microwave theory and design, is a former Howard Hughes Doctoral Fellow, and holds two patents in RF/microwave technology. <P><B><I>Mike Heimlich</B></I>, Ph.D (mike@appwave.com) is the microwave market segment director for <A href="http://http://www.appwave.com">Applied Wave Research, Inc</A>. He has published papers in many technical journals and proceedings on MMIC and module design and EDA tool integration, and holds a patent in EDA tool integration. <P><!--end body--></P><BR><IMG height=5 alt="" hspace=0 src="http://i.cmpnet.com/rfdesignline/blank.gif" width=2 border=0></DIV>Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-40438776698705116222008-01-31T02:21:00.000-08:002008-01-31T02:17:30.184-08:00FPGA-Based Prototyping - "Productivity to Burn"<DIV> <TABLE cellSpacing=0 cellPadding=0 width="100%" border=0> <TBODY> <TR> <TD vAlign=top align=left colSpan=2> <P class=storytitle>FPGA-Based Prototyping - "Productivity to Burn"</P><SPAN class=storysubheadline>This article highlights recent tool advances that can help you setup, implement, and verify your FPGA-based ASIC prototype faster than ever before.</SPAN><BR></TD></TR><!-- AUTHOR | PRINT EMAIL DISCUSS --> <TR> <TD class=storyauthor vAlign=top align=left colSpan=2>By Lee Hansen (Xilinx) and Doug Amos (Synplicity) </TD></TR> <TR> <TD class=storypagenumber vAlign=top align=left><IMG height=5 alt="" src="http://i.cmpnet.com/pldesignline/spacer.gif" width=50 border=0><BR><!-- PAGE NUMBERS --><!-- PAGE NUMBERS --><IMG height=5 alt="" src="http://i.cmpnet.com/pldesignline/spacer.gif" width=50 border=0><BR></TD></TR><!-- DATE / EMAIL THIS - PRINT THIS --> <TR> <TD class=storysiteoriginator vAlign=top align=left><!-- remove http:// substring (if present) from the url --><A class=blue12 href="http://www.pldesignline.com/;jsessionid=JMQGVJQ2WNDXCQSNDLPSKH0CJUNN2JVN" target=_blank>Programmable Logic DesignLine</A> <BR><SPAN class=storydateline>(01/30/2008 2:02 PM EST)</SPAN> </TD></TR><!-- SPACER --> <TR> <TD vAlign=top align=left colSpan=2><IMG height=5 alt="" src="http://i.cmpnet.com/pldesignline/spacer.gif" width=50 border=0><BR></TD></TR><!-- ARTICLE BODY --> <TR> <TD vAlign=top align=left colSpan=2><!--body-->These days, a large portion of ASIC, SoC, and ASSP designs are at least partially prototyped in one or more FPGAs. This amounts to many thousands of prototyping projects per year. Compared with other ASIC verification methods, however, FPGA Prototyping is mistakenly seen by many as an ad-hoc mix of tools that must be cobbled together by hand. In reality, powerful integrated tools, platforms, and expertise exist that greatly improve the productivity of FPGA-based <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=ASIC&amp;x=&amp;y=">ASIC</A> prototyping. This article highlights recent tool advances that can help you set-up, implement, and verify your prototype faster than ever before. <P><B>Prototype setup</B><BR> <P><B><I>Use the right FPGAs</I></B><BR>ASIC designs are generally larger  and often faster  than FPGA Devices, and they tend to push the envelopes of FPGA performance and density. Thus, we will almost always be using the largest FPGAs (in the fastest speed grade) available. Anything less might seem to save money, but in the end could make timing closure harder to reach or make the design harder to fit (or both). <P>Less obvious is the fact that we should also use the device in a package with the most available I/O pins and with the most flexible support for clocking, voltage, and I/O standards. The <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=I/O&amp;x=&amp;y=">I/O</A> often becomes the most valuable resource on the devices, especially when designs are partitioned across multiple FPGAs. Synplicity builds <I>HAPS (High-Performance ASIC Prototyping System)</I> boards using the largest Xilinx devices  namely the Virtex-5 LXC5V330 in the -2 speed grade and the 1760 ball grid array package. <P><B><I>Design partitioning</I></B><BR>If a design takes up more than 70% to 80% of the largest FPGA available to you, then it is worth considering partitioning it across more than one device. Some designs have natural and obvious partitions based on existing hierarchical boundaries. The aim is to ensure that we do not create new critical paths in the design that cross between FPGAs on the board. <P>In order to address this, Synplicity's Certify tool has numerous partitioning aids from low level block zippering up to completely automatic full-RTL partitioning. These allow as much or as little manipulation of the design as required to meet the performance goals, but all involve no changes at all to the original ASIC RTL. <P>An important manipulation of the design that Certify can perform without changing the RTL is to automatically add I/O pin <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=multiplexing&amp;x=&amp;y=">multiplexing</A> between FPGAs. This uses time-sharing of the wires between the FPGAs so that they carry two or more signals, thereby alleviating potential I/O bottlenecks which often arise at the <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=partition&amp;x=&amp;y=">partition</A> boundaries. <P>Many of Certify's partitioning aids have been developed to meet the needs of users performing hundreds of partitioning projects within major Semiconductor and System labs since 1999. <P><B><I>RTL manipulation</I></B><BR>ASIC designs often contain design features that are FPGA-Hostile. For example, ASIC designs are typically sprinkled with instantiations of elements or macros from ASIC technology libraries or <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=macro&amp;x=&amp;y=">macro</A> generators. This leaves "black-box" holes in the RTL for which some functionality must be described in order to complete the FPGA implementation. Some of this functionality is provided automatically by Certify, which can extract the required RTL from the ASIC <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=library&amp;x=&amp;y=">library</A> itself. Synopsys DesignWare instantiations are dealt with automatically in a similar way. <P>Another FPGA-hostile facet associated with many ASIC designs is their complex clocking structures. Multiple clock domains, <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=asynchronous&amp;x=&amp;y=">asynchronous</A> parallel channels, and gated clocking trees will quickly overflow the global synchronous clock resources of even the largest FPGAs. Certify will automatically simplify gated or generated clock networks back to a common system <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=clock&amp;x=&amp;y=">clock</A> and build the required enable signal to ensure equivalent functional behavior. An example of this is shown in <I>Fig 1</I>. The result is to match to the resources available inside the FPGA. <P> <CENTER><IMG src="http://i.cmpnet.com/pldesignline/2008/01/xi-syn-01.gif" border=0><BR><I>1. Automatic gated clock conversion.</I></CENTER> <P><B>Implementation and verification</B><BR> <P><B><I>Fast design iterations</I></B><BR>Implementation is a critical phase in the FPGA prototyping flow. The partitioned design may undergo many iterations as bugs are discovered and fixed, or design blocks are tweaked and re-tweaked for higher performance. <P>It is very important to keep this iteration loop as short as possible. However, the combination of leading-edge ASIC designs in the multi-million system gate range, and stretch performance goals to model real-world operation, can lead to lengthy synthesis and place-and-route passes. The great advantage that FPGAs offer for debugging and design exploration begins to diminish when using traditional FPGA flows and large design sizes. The answer is to use incremental implementation methods. <P>Xilinx's ISE 9.2i design <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=software&amp;x=&amp;y=">software</A> offers a technology called <I>SmartCompile</I> which is ideal for the ASIC prototyping flow. Designed to speed up the implementation flow by 2-to-6 times versus traditional flows, <I>SmartCompile</I> is comprised of three components: <I>SmartPreview</I>, <I>SmartGuide</I>, and <I>Partitions</I> (not to be confused with multi-FPGA Partitioning). <P><I>SmartPreview</I> allows you to halt the ISE tool flow in mid-stream to see how a particular implementation pass is proceeding. While halted, you can check key implementation information like the number of timing violations, the timing score, or the number of constraints met so far. You can even save the intermediate design and timing reports and create a bitstream for lab debug. If the implementation is proceeding as expected you can resume the pass; or you cancel a run that is not proceeding as planned, thereby saving valuable design time. <P><I>SmartGuide</I> delivers automated incremental design to the FPGA design flow. SmartGuide can speed up the implementation phase by 2-to-6 times depending on design size and hierarchy setup. <P>With <I>SmartGuide</I> turned on, your first full implementation run is "guided", or marked for component and route placement. Let's say after a debug session you decide to make a design tweak and change one HDL source. As you re-enter the implementation flow, <I>SmartGuide</I> examines the hierarchy and identifies where the design needs to be re-implemented. Where possible, <I>SmartGuide</I> will reuse the placement and routing that didn't change from the prior implementation pass, thereby speeding up the re-implementation flow (sometimes dramatically). <P>Synplicity and Xilinx have collaborated closely, as part of our Timing Closure Task Force, to enforce name consistency in both tools. This means that names remain constant from run to run of the Synthesis and Place-and-Route, thus ensuring best possible guided flow results. <P>Some incremental tool flows can produce worse timing paths from having to route around "locked" modules, but <I>SmartGuide</I> has the ability to identify critical timing paths and  if necessary  free up portions of an otherwise unchanged module for re-implementation, emphasizing critical paths and keeping timing a priority. <P>The third component of <I>SmartCompile</I> is <I>Partitions</I>, which offers the ability to completely lock down a completed module's placement and routing. In this way, a debugged "known-good" module or piece of purchased <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=IP&amp;x=&amp;y=">IP</A> can be implemented and then set aside while you concentrate on debugging your other modules, while still enjoying the benefits of an incremental implementation flow. Partitions can be locked down early in the tool flow by using Compile Point Technology within the Synplify Pro and Synplify Premier synthesis tools. The partition information is automatically passed on to ISE. <P>All the components of <I>SmartCompile</I> work directly with either Xilinx or Synplicity synthesis and can cut the implementation flow for large designs by between 2 and 6 times. <I>SmartCompile</I> delivers more time for critical module debug, thereby freeing the engineer from watching lengthy and cryptic synthesis and place-and-route runs. <!--end body--><BR><BR><STRONG>Verification<BR></STRONG>This is typically where the majority of your time is spent on a prototyping project. The ability to debug any portion of the design quickly and accurately is critical to project success. Let us consider two methods for embedding Virtual Logic Analyzers into the design so as to allow logic and embedded software designers to debug their FPGAs in real time. The two methods are Chipscope Pro from Xilinx and Identify Pro with TotalRecall Technology from Synplicity. </P> <P><B><I>ChipScope Pro</I></B><BR>With the ChipScope Pro system  which is available as a separately purchased option to Xilinx ISE software  design problems can be quickly found while the <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=chip&amp;x=&amp;y=">chip</A> is running on the board and interacting with the rest of the system. Then, leveraging the FPGA's re-programmability, design changes can be quickly implemented and sent back to the device on board in a matter of minutes through the FPGA programming cable. <P>The ChipScope Pro package of tools includes a set of configurable and synthesizable software debug cores that are either instantiated into your FPGA design during HDL capture or inserted directly into the project netlist (<I>Fig 2</I>). Following implementation, using these cores you can view any internal signal within the FPGA. <P> <CENTER><IMG src="http://i.cmpnet.com/pldesignline/2008/01/xi-syn-02.jpg" border=0><BR><I>2. ChipScope Pro core insertion options.</I></CENTER> <P>Signals are captured at or near <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=operating system&amp;x=&amp;y=">operating system</A> speed and then brought out through the programming interface, thereby freeing up pins for your design as opposed to gobbling them up for debug. And ChipScope Pro is one of the only tools that allow you to change probe points without having to re-synthesize and re-route your design. Using the ISE FPGA Editor, you can change signal probe points and then quickly reprogram your FPGA and debug a whole new set of signals in a matter of minutes. <P>You can analyze captured signals through the ChipScope Pro software logic analyzer. This is an advanced <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=display&amp;x=&amp;y=">display</A> and debug tool that makes logic and embedded bus analysis easy. The ChipScope Pro logic analyzer supports multiple window views, and bus plotting can be in either data-versus-time or data-versus-data formats. Capture <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=mode&amp;x=&amp;y=">mode</A> lets you compare data captured after multiple trigger events; meanwhile signal filtering lets you ignore data that's not critical to your analysis, thereby saving you <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=memory&amp;x=&amp;y=">memory</A> and analysis time. Using the listing viewer, you can import <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=bus&amp;x=&amp;y=">bus</A> token files and view instructions in the order they occur. <P>To facilitate <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=processor&amp;x=&amp;y=">processor</A> system debug environments that use software debuggers in addition to ChipScope Pro tools, you can share the JTAG connection to the FPGA with the ChipScope Pro analyzer. <P>In addition to providing data capture capabilities, the ChipScope Pro system also includes the Virtual I/O console, the <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=interface&amp;x=&amp;y=">interface</A> to the industry's first real-time virtual input/output core. Through the Virtual I/O console, you can set virtual inputs and pulse trains and view <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=output&amp;x=&amp;y=">output</A> activity. <P>ChipScope Pro tools can run in server/client mode over a TCP/IP connection. You can sit in your office while debugging a board next door in the lab or on the other side of the world. You can share a single prototyping board in the lab with other debug engineers on your team. <P><B>Identify RTL Debugger</B><BR>Going beyond beyond the functionality of ChipScope Pro, Synplicity's Identify tool makes is possible to perform the on-chip debug at multiple hierarchical points within the RTL source and to do this without altering the source at all. Identify uses an automated instrumentation technique in order to create and attach sampling, trigger and communication logic into each FPGA forming the prototype as required. <P>Waveform views such as those seen in the ChipScope Pro logic analyzer are possible, but a significant added bonus is that the samples and triggers are overlaid onto the RTL <A href="http://www.pldesignline.com/encyclopedia/defineterm.jhtml?term=source code&amp;x=&amp;y=">source code</A> using the same symbolic names as in the RTL. Thus, for example, it is possible to see the actual value of an enumerated type in which a state machine is captured on the FPGA. Triggers may be set in a similar way, using the source name-space. A unique benefit is that triggers can be set for when a particular line of RTL is reached, much like a software engineer would set breakpoints in a program. <P><B>Identify Pro with TotalRecall Technology</B><BR>Newly available in a superset of Identify  called Identify Pro  is Synplicity's TotalRecall full visibility debug technology (see also Programmable Logic DesignLine article <A href="http://www.pldesignline.com/196801895" target=_new>196801895</A> titled <A href="http://www.pldesignline.com/196801895" target=_new>How to achieve 100% visibility with FPGA-based ASIC prototypes running at real-time speeds</A>). <P>Whereas ChipScope Pro and Identify rely on sample points to be set in advance, Identify Pro with TotalRecall provides visibility into the entire design. This allows the automatic extraction of a testcase from the FPGA and rerun in a standalone simulator. Upon a trigger occurring in the FPGA, the full status of the module under test (not just certain sample points) is captured as it was many thousands of clocks BEFORE the trigger occurred. <P>This module state is extracted and converted for use in the users' own simulator. A significant advantage is that the testbench for the simulator is also extracted from the FPGA, so that the module under test is re-stimulated with the actual inputs it had received from the point at which the module's state was captured, right up to the point at which the trigger occurred. <P>Once in the simulator, the full suite of analysis tools including single-step, force, freeze etc. can be brought to bear. The prototype is freed up for further verification task while the simulation takes place. <P><B>Summary  putting it all together</B><BR>In conclusion, significant and continual progress in FPGA devices, Synthesis, Place-and-Route tools, and debug capabilities has made FPGA prototyping much more accessible and useful to ASIC verification teams than ever before. <P>Observability and controllability have been added to the already unchallenged superior performance of FPGA prototypes to offer cheap, fast platforms for RTL debug and software integration into real world test environments. If you are ready to explore the benefits of FPGA Prototyping, Synplicity and Xilinx are ready to help you to prototype your project. <P>Xilinx offers the most advanced silicon, software, and support available in FPGA prototyping, while Synplicity has created a complete prototyping environment  called the Confirma Platform  which includes leading prototyping hardware based on Virtex-5 FPGAs and the EDA tools mentioned in this article. For more information, go to <A href="http://www.xilinx.com/" target=_new>www.xilinx.com</A> or <A href="http://www.synplicity.com/" target=_new>www.synplicity.com</A> </P></TD></TR></TBODY></TABLE></DIV> <P><FONT size=2></FONT>&nbsp;</P><FONT face=Arial color=#000000 size=3> <P>&nbsp;</P></FONT>Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-41262940613461877942008-01-28T05:46:00.000-08:002008-01-28T05:50:54.315-08:00Tackle team-based FPGA designTackle team-based FPGA design<br /><br />You see them at almost every user seminar or industry trade show workshop: the Methodology Managers from XYZ Corporation, who describe the system they use to help the company make sense of the intellectual property (IP) produced by their design teams. And it's got to be a daunting task--development staff working in different time zones; language barriers; software tool versions to track and synchronize; VHDL/Verilog/C/C++, CAD databases. All of these (and more) diminish the reusability of any design module. You can respect the role these managers play and envy the sanity they bring to the organization.<br />But XYZ Corporation is a large company. How does a small or midsize firm like yours grapple with this imposing housekeeping chore?<br /><br />Distributed design teams happen. With the right mix of specialty tools and culture, it's becoming more practical to create and manage distributed FPGA design teams by using modular FPGA design methods that allow multiple designers to work on parts of a single design independently.<br /><br />Collaborative design<br />The benefits of collaboration are intuitive enough. Use the best people for the job, no matter where they are. Assign more people to the project when the schedule or feature set isn't flexible (and they seldom are). And, ideally, a natural and beneficial consequence of a partitioned design task is that FPGA building blocks (or IP modules) are created that can be reused for enhanced for derivative products.<br /><br />Sometimes collaboration is imperative, if only because the one person knowledgeable about a particular task is in a different time zone from everyone else. Just as software teams might use a driver or GUI specialist, FPGA design teams might include a high-speed I/O specialist, a DSP designer, and a guru who knows the tools and the ins and outs of timing closure.<br /><br />The scale of the designs intended for high-capacity FPGAs creates a formidable, likely impossible, demand for one or two design engineers to deliver the required content. It's often necessary to assign multiple engineers to the job.<br /><br />FPGA design tools haven't provided much support for partitioning design work across multiple engineers until recently. Advances in FPGA design planning and place-and-route (PAR) tools, however, now help support a modular design style and complement synthesis and simulation tools that have traditionally supported design teams. Contemporary FPGA design tools are more aware of modular IP, can accommodate distributed development, and are focused on high-capacity devices.<br /><br />Modular FPGA design<br />Modular FPGA design is an approach that enables multiple designers to work independently on parts of a single design. In this approach, a lead designer creates the top-level design; the rest of the design team works on constituent designs that will be merged into one cohesive design in the final assembly stage.<br /><br />All major FPGA vendors now support a modular implementation strategy. Altera's LogicLock, Lattice Semiconductor's Block Modular Design method, and Xilinx's Modular Design Flow all provide strategies and tools that support partitioning, independent implementation, and assembly of design modules.1, 2, 3<br /><br />Figure 1 illustrates an FPGA design partitioned across a team. The convention for most FPGA tools today is to allocate a branch of the design hierarchy to a team member, along with some "budget" for timing and device resources. That engineer can then establish a logical user hierarchy to whatever degree is appropriate for that design module.<br /><br /><br /><a href="http://4.bp.blogspot.com/_e6JO8zk2riM/R53c5l1C2oI/AAAAAAAAAIY/oaCNAswnLnM/s1600-h/fpga1.gif"><img id="BLOGGER_PHOTO_ID_5160523630001707650" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="http://4.bp.blogspot.com/_e6JO8zk2riM/R53c5l1C2oI/AAAAAAAAAIY/oaCNAswnLnM/s320/fpga1.gif" border="0" /></a><br /><br />Device-resource budgeting is a recent advancement in FPGA implementation tools that makes it possible for a subset of the design to be implemented independently of other design modules. A distinct advantage of this block-style flow is the ability to update the logic in any of the blocks while preserving the placement and performance of the surrounding blocks. The block-style flow enables the design tools to focus on new blocks or those that are changed. Being able to isolate and work on individual blocks shortens potentially long run times since, given a smaller design problem, PAR tools will typically produce better results sooner. Individual blocks can be implemented and updated separately, enabling quicker iterations and a more rapid path to design closure. In some cases, blocks can be reused in other designs, further leveraging resources and shortening those design cycles. From the perspective of a team collaborating on an embedded system, this makes future revisions of the platform more straightforward and faster to expand or modify.<br /><br />Team-based design naturally works best for larger designs that can be easily partitioned into self-contained regions of the chip. Thorough preliminary planning, iterative experiments, and explicit, deliberate, and clear communication among design team members are all essential to ensure the partitioned designs work together in the final assembly step of the process.<br /><br />Of course, partitioning the design presents challenges as well as benefits. For example, if the design architect's initial floor plan doesn't budget enough resources for a certain module, some sort of refinement loop is needed so a team member can negotiate for more room. Timing objectives also are likely to be handed down to team members and may not be as easily met as those for a design that is not floor-planned. The design architect must account for the availability of features such as high-performance embedded memories, DSP functions, and high fan-out routing spines because these anchor and size regions for each block. Given that contemporary FPGA architectures are a mixture of programmable fabric and rows of embedded functions, it can be awkward to create a block diagram that nicely accommodates the design logic. In this regard, modular design both benefits and suffers from a handmade floor plan where placement algorithms are constrained by the borders of each block.<br /><br />What follows is a typical procedure for modular FPGA design that's common among the leading FPGA vendors. Figure 2 illustrates a typical data flow in a modular FPGA design<br /><br /><br /><a href="http://3.bp.blogspot.com/_e6JO8zk2riM/R53c6V1C2pI/AAAAAAAAAIg/a7OA312VLz4/s1600-h/fpga2.gif"><img id="BLOGGER_PHOTO_ID_5160523642886609554" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="http://3.bp.blogspot.com/_e6JO8zk2riM/R53c6V1C2pI/AAAAAAAAAIg/a7OA312VLz4/s320/fpga2.gif" border="0" /></a><br /><br />1. Partition the top-level design and synthesize design modules<br /><br />Create a top-level design, along with constituent design modules, in HDL. The top-level design serves as the design documentation and is also the first opportunity to influence the performance results of the design. By using FPGA-friendly design-partitioning principles, you can dramatically reduce overall design time by simplifying the coding, synthesis, simulation, floor-planning, and optimization phases of the design. Here good guidelines include:<br /><br />• Sub-blocks should be synchronous with registered outputs. Registering outputs helps the synthesis tool implement the combinatorial logic and registers into the same logic block. Registering outputs also makes the application of timing constraints easier, since it eliminates potential problems with logic optimization across design boundaries.<br /><br />• Related combinatorial and arithmetic logic should be collected into the same design module. Keeping related combinatorial terms and arithmetic in the same design module allows sharing of logic hardware resources. It also allows a synthesis tool to optimize the entire critical path in a single operation.<br /><br />• Separate logic with different optimization goals. Separating critical paths from non-critical paths will make logic synthesis more efficient. If one portion of a design module needs to be optimized for area and a second portion needs to be optimized for speed, those portions should be separated into two design modules.<br /><br />As this top-level partitioning is underway, team members are also (in theory) modeling design modules. The order of operation isn't so important here, as long as each design module will eventually comply with the architect's top-level connections and organization. Even without a clear picture of the FPGA resources needed to implement all design modules, the team at least has the luxury of simulating and verifying the function of any combination of design modules by mixing register-transfer-level (RTL) logic with gate-level logic.<br /><br />2. Create a floorplan, place blocks, and optimize<br /><br />This step is the most critical one in the process. It includes area budgeting and reserving space in the top-level design for constituent blocks, determining I/O for each block along with the device's external I/Os, and determining the position of each block relative to the others.<br /><br />FPGA design tools ease block floor planning with the following utilities:<br /><br />• A schematic view of the register-transfer-level description (RTL) will help you view the data paths of the design along with the relative order of design modules. This view makes it obvious where blocks should be located relative to external I/Os.<br /><br />• An abstract graphical floor plan view is used to size and anchor blocks. Once blocks are defined to hold one or more design modules, logical connections can be shown as "flywires" superimposed on the device resource floor plan. Heavily interconnected blocks will be placed adjacent to one another, while covering enough physical resources to accommodate the design logic.<br /><br />Some systems allow you to direct which side of the block the logical interconnect will enter or exit to help define the data flow. Commonly recommended guidelines for this step include:<br /><br />• Lock global logic resources like PLL/DLL-driven clocks and the external I/O plan. The floor plan should also define optimal positions for global logic such as clock drivers (whether they are programmable I/Os or embedded PLL/DLL) and external signals, with an eye toward signal types and the device's package organization. FPGAs may provide specialized I/O drivers for double-data-rate (DDR) or serializer/deserializer (SERDES) interfaces at specific locations of the device package, so you must account for these locations in the block floor plan.<br /><br />• Define design module timing objectives. Performance objectives are defined by assigning physical and timing preferences in the respective FPGA synthesis tool.<br /><br />• Place and orient blocks. At this point, you will budget device resources such as lookup tables (LUTs), registers, and memory or DSP elements by reserving a region (or block) of the floor plan. The resources allocated can be handled in a top-down manner based on rough estimates, or bottom-up based on the actual results produced by logic synthesis of a block. It's essential that the block's region is large enough to accommodate the design module's logic and allow for adequate I/O resources. The relative position and orientation of the blocks will depend largely on the device's internal interconnect. Modern FPGA tools provide floor-planning utilities to help visualize block interconnect and the physical resources available.<br /><br />Ideally, this step is done in parallel with logic synthesis to help size the regions. This is almost always an iterative process because it's unlikely you'll get the floor plan right the first time. Some FPGA systems will automatically size regions based on logic consumption and allow blocks to include or exclude other logic, depending on resource needs.<br /><br />3. Block-level PAR<br /><br />This step implements each block with the top-level design constraints applied. This step must be completed before final assembly can be performed and is done in parallel with Step 2 but requires that the top-level floor plan with region constraints be completed.<br /><br />Successful block implementation will depend largely on the preferences assigned for area budgeting and reservation and I/O placement determined in the previous step. If incorrect, repeat Steps 3 and 4.<br /><br />The HDL design files for each block are generally synthesized into Electronic Design Interchange Format (EDIF) netlists. The FPGA software then imports the EDIF files. This step is required for all team members. The synthesis can be performed in any order.<br /><br />4. Top-level assembly<br /><br />In this final step, merge all the blocks into one cohesive design. The top-level design file must be configured and all blocks implemented before the design can be assembled. Successful assembly depends primarily upon the decisions made in Step 3 and the successful implementation of all constituent blocks.<br /><br />Design example<br />This design example illustrates the application of modular FPGA design by a development team charged to implement a large communications design. The modular approach was an attractive means to partition, implement, and stabilize a significant portion of the design.<br /><br />For the team creating a reference design demonstrating an orthogonal frequency-division multiplexing (OFDM) application, the objective was to establish timing and resource use for a major design module, which served as the Viterbi algorithm. The design module was targeted for a particular block/region of the floor plan composed of programmable function units (PFUs) and embedded block RAM (EBR). The team observed that overall PAR time decreased significantly versus the entire flattened design. In this case, the FPGA implementation tool treated block region resources as sharable, which allowed the top-level PAR phase to take advantage of the unused resources of the block region allocated for the design block. This was useful because the Viterbi module relied on both EBRs and a number of PFUs, but a side effect of rectangular block regions meant the architect had to enclose more EBRs in the block region than it practically needed. At assembly time, however, a top-level FFT block was able to use the excess EBRs.<br /><br />The moral of the story for this team's partition effort was not to make more blocks than absolutely necessary in order to avoid over-constraining the layout. Since only one block was defined, the data path was not locked and the remaining "floating" logic naturally landed next to related logic of the block.<br /><br />This project was a success story for the modular design technique. The team concluded that modular design would be highly useful when using IP blocks for the sake of standalone PAR. Modular design permitted timing closure of the Viterbi block in one step, and then the remainder of the design logic during assembly, leaving PAR results of the Viterbi block stable.<br /><br />Going modular<br />New modular FPGA design techniques provide major advantages to distributed design teams. Portions of an entire design can be approached independently, allowing multiple designers to work in parallel. Working in parallel enables the application of additional resources, as necessary, to particular design modules.<br /><br />Functional modules can be analyzed separately. This affords you a better vantage point from which to debug or enhance designs, because design problems can be traced to a specific portion of the design.<br /><br />The timing of each constituent functional module is preserved because each module can be assigned to a particular region on the device, and the tools are constrained to use resources from that region.<br /><br />The modular flow can be used for performance optimization and preservation: it can be used to place modules into regions in a device's floor plan. Because modular assignments are generally hierarchical, teams have more control over the placement and performance of modules and groups of modules. Typically, a block's region size, state, width, height, and origin can be modified.<br /><br />All the leading FPGA vendors provide some type of a modular design method that follows a typical procedure of partitioning, floor planning, block implementation, and assembly.<br /><br />Troy Scott has been helping design, document, test, and promote EDA products for about 14 years. He is a product marketing engineer at Lattice Semiconductor Corporation. Troy holds a BSCE from Oregon Institute of Technology and a Graduate Certificate in Computer Architecture and Design from Portland State University. He welcomes feedback and can be reached at <a href="mailto:troy.scott@latticesemi.com">troy.scott@latticesemi.com</a>.<br /><br /><a name="endnotes"></a>Endnotes:1. Altera's LogicLock: <a href="http://www.altera.com/products/software/products/quartus2/design/qts-logiclock.html" target="new">www.altera.com/products/software/products/quartus2/design/qts-logiclock.html</a><br />2. Lattice Semiconductor's Block Modular Design method: <a href="http://www.latticesemi.com/products/designsoftware/isplever/projectmanagement.cfm" target="new">www.latticesemi.com/products/designsoftware/isplever/projectmanagement.cfm</a><br />3. Xilinx's Modular Design Flow: <a href="http://www.xilinx.com/ise/advanced/modflow.htm" target="new">www.xilinx.com/ise/advanced/modflow.htm</a>Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-65871933932281900752008-01-28T04:34:00.000-08:002008-01-28T05:55:01.600-08:00Design a clock divide-by-3 circuit with 50% duty cycle<p>The basic insight was to notice that if you are doing a divide by 3 and wanna keep the duty cycle at 50% you have to use the falling edge of the clock as well.<br />The trick is how to come up with a minimal design, implementing as little as possible flip-flops, logic and guaranteeing glitch free divided clock. </p><br /><p>Most solutions that came in, utilized 4 or 5 flip flops plus a lot more logic than I believe is necessary. The solution, which I believe is minimal requires 3 flops - two working on the rising edge of the clock and generating a count-to-3 counter and an additional flop working on the falling edge of the clock.</p><p>A count-to-3 counter can be achieved with 2 flops and a NOR or a NAND gate only, as depicted below. These counters are also very robust and do not have a "stuck state". </p><br /><a href="http://3.bp.blogspot.com/_e6JO8zk2riM/R53eOV1C2qI/AAAAAAAAAIo/oa89_Vz4YZI/s1600-h/1.bmp"><img id="BLOGGER_PHOTO_ID_5160525085995621026" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="http://3.bp.blogspot.com/_e6JO8zk2riM/R53eOV1C2qI/AAAAAAAAAIo/oa89_Vz4YZI/s320/1.bmp" border="0" /></a> The idea now is to use the falling edge of the clock to sample one of the counter bits and generate simply a delayed version of it.<br />We will then use some more logic (preferably as little as possible) to combine the rising edge bits and falling edge bit in a way that will generate a divide by 3 output (with respect to out incoming clock).<br /><p>The easiest way (IMHO) to actually solve this, is by drawing the wave forms and simply playing around. Here is what I came up with, which I believe to be <em>the optimal solution for this approach</em> - but you are more than welcome to question me!</p><br /><a href="http://1.bp.blogspot.com/_e6JO8zk2riM/R53eO11C2rI/AAAAAAAAAIw/xEwIOom4BQw/s1600-h/2.bmp"><img id="BLOGGER_PHOTO_ID_5160525094585555634" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="http://1.bp.blogspot.com/_e6JO8zk2riM/R53eO11C2rI/AAAAAAAAAIw/xEwIOom4BQw/s320/2.bmp" border="0" /></a><br /><p><span style="font-size:100%;">and here is also the wave form diagram that describes the operation of the circuit, I guess it is self-explanatory.</span></p><span style="font-family:Arial;color:#000000;"><br /><a href="http://4.bp.blogspot.com/_e6JO8zk2riM/R53ePl1C2sI/AAAAAAAAAI4/7Y-mWB3zYNU/s1600-h/3.bmp"><img id="BLOGGER_PHOTO_ID_5160525107470457538" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="http://4.bp.blogspot.com/_e6JO8zk2riM/R53ePl1C2sI/AAAAAAAAAI4/7Y-mWB3zYNU/s320/3.bmp" border="0" /></a> One more interesting point about this implementation is that it does not require reset! The circuit will wake up in some state and will arrive a steady state operation that will generate a divide by 3 clock on its own. </span>Jagdishnoreply@blogger.com6tag:blogger.com,1999:blog-4188889258526451328.post-66982380301054552092008-01-03T00:53:00.001-08:002008-01-03T00:57:47.117-08:00List of Company AddressesList of Company Addresses<br />X-Vision Software<br />945, 24th Main<br />IInd Phase, J.P.Nagar<br />Bangalore - 560 078<br />Phone: 646634<br /><br /><br />Worldscope Disclosure India Pvt. Ltd.<br />106, First Floor, Gandhi Bazaar Road<br />Basavanagudi<br />Bangalore - 560004<br /><br /><br />Wishbone Systems Pvt. Ltd.<br />968, 12th Main Road<br />HAL II Stage<br />Bangalore - 560 008<br />Phone: 5276717 Fax: 5276717<br /><br /><br />Wipro Systems Ltd.<br />3rd Floor, S.B.Towers<br />No.88, M.G.Road<br />Bangalore - 560 001<br />Phone: 5586202, 5588583 Fax: 5587984<br /><br />Wipro InfoTech Group<br />88 MG Road,<br />Bangalore - 560001<br />Phone: 5588422<br />Fax: 5586657<br /><br /><br />Wipro GE Medical Systems<br />Plot No. 4, Kadugodi Indl. Area<br />Sadaramangala<br />Bangalore - 560057<br />Phone: 8452923/25/26<br /><br /><br />Visual Engineering Services (I) Ltd.<br />A-313, Block III, KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore - 561229<br />Verifone India Pvt. Ltd.<br />Indian Express Building<br />Dr. Ambedkar Road<br />Bangalore - 560 001<br />Phone: 2269920, 2269924 Fax: 229938<br /><br /><br />Unitech Systems (India) Pvt. Ltd.<br />III Floor, Classic Court<br />9/1, Richmond Road<br />Bangalore - 560 025<br />Phone: 2216442<br /><br /><br />Ultra Business Machines<br />II Floor, St. Patrick's Complex,<br />157 Brigade Road,<br />Bangalore - 560025<br />Phone. : 5585618/983<br />Fax: 5588626<br /><br />Trigent Software Ltd.<br />620, 80 Feet Road<br />8th Block, Koramangala<br />Bangalore - 560 095<br /><br /><br />Thompsum Technologies (P) Ltd.<br />No. 29, Beratina Agrahara<br />Singasandra Post, Hosur Road<br />Bangalore - 560 068<br />Texas Instruments (India) Pvt. Ltd.<br />71, Millers Road<br />Sona Towers<br />Bangalore - 560 052<br />Phone: 2254235, 2259007<br />Fax: 2257024<br /><br /><br />Telsoft<br />84, IInd Main, Indranagar<br />Bangalore - 560 038<br />Phone: 5581986 Fax: 5581968<br />Tektronix India Ltd.<br />Tek Tower, Hayes Road,<br />Bangalore - 560025<br />Phone. : 2275577<br />Fax: 2275588<br /><br /><br />Tata Information System Ltd.<br />Golden Enclave Tower 'B'<br />Airport Road<br />Bangalore - 560 017<br />Phone: 5262355, 5267117, and 5269299<br />Fax: 5587374, 5583344, and 5587413<br />Tata Elxsi (India) Ltd.<br />No.123, Richmond Road<br />Bangalore - 560025<br />Phone: 563956, 564872 Fax: 583168<br /><br /><br />Tangerine Geoscience<br />15/8, Primrose Road<br />Bangalore - 560025<br />Phone: 5580357<br /><br /><br />Synopsys Development India (P) Ltd.<br />C/o KAMG, 5th Floor<br />Shariff Chambers, 14 Cunningham Road<br />Bangalore - 560 052<br />Phone: 2204600 Fax: 2204300<br /><br /><br />Stem Logic<br />1281, 21st Main JP Nagar,<br />II Phase<br />Bangalore - 560078<br />Phone. : 649054, 647304<br />Fax: 647753<br /><br /><br />Squire Systems<br />57/9, Manipal Center, 47,<br />Dickenson Road,<br />Bangalore - 560042<br />Phone. : 5594477<br /><br /><br />Spectra Innovations India Pvt. Ltd.<br />Unit 5822, Manipal Center,<br />47, Dikenson Road<br />Bangalore - 560002<br />Phone. : 5588322, 5583977<br />Fax: 5586872<br /><br /><br />Sonata<br />1st Floor, APS Trust Building<br />Bull Temple Road, N.R.Colony<br />Bangalore - 5589722 Fax: 5585092<br /><br /><br />Software Development Systems<br />85, Narayanappa Block,<br />RT nagar II Block,<br />Bangalore - 560032<br />Phone. : 551568, 5535874<br />Fax: 5531874<br />Siemens Information Pvt. Ltd.,<br />No. 29, Infantry Road<br />Bangalore 560 001<br />Phone: 5543547/48<br />Fax: 2212418<br /><br /><br />Siemens Communications S/W Ltd.,<br />Raheja Towers, 10th Floor<br />M.G Road<br />Bangalore 560 001<br />Phone: 5594067<br />Fax: 5594069<br /><br /><br />Sibcomm Technology (P) Ltd.,<br />A-308, Block III<br />KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore 561 229<br /><br /><br />Shankti Design Pvt. Ltd<br />5/5, First Main Road<br />Jayamahal Extension<br />Bangalore 560 046<br />Phone: 560 046<br /><br /><br />Search (India) Pvt. Ltd<br />Flat No. 211, Block III,<br />KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore 561 229<br />Phone: 2221987<br />Fax: 2239508<br /><br /><br />Samyog Software<br />"Saugandh" 476/A<br />13th Cross, 28th Main<br />1st Phase, J.P Nagar<br />Bangalore 560 078<br />Phone: 6614281<br /><br /><br />SPAN Systems<br />939, 23rd Main, 38th Cross<br />4th T Block, Jaya Nagar<br />Bangalore - 560041<br />Phone: 6639596 Fax: 6631304<br />SE Technology Ltd.,<br />A-205/206, Block III<br />KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore 561 229<br /><br /><br />Rothwell Systems Pvt. Ltd.<br />130/5, Infantry Road<br />Balaji Complex<br />Bangalore - 560 001<br />Phone: 576950<br /><br /><br />R &amp; R Software<br />73, 1st Floor, 7th A Cross<br />4th B Block, Koramangala<br />Bangalore - 560 034<br />Phone: 534175<br /><br /><br />Processware Systems (P) Ltd.<br />33, Patalamma Temple Street,<br />Basanagudi,<br />Bangalore - 560004<br />Phone. : 6614163, 622188<br />Fax: 6629635<br /><br /><br />Premium Logic System Ltd.<br />No. 214, IInd Main Road<br />HIG House, RMV IInd Stage<br />Bangalore - 560094<br />Phone: 2212134<br /><br /><br />Premier Computers Consultancy Services<br />1/2, Krishna Road Basavanagudi,<br />Bangalore - 560004<br />Phone. : 621004<br /><br /><br />Pinero Ltd.<br />A-306, Block III, KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore - 561 229<br /><br /><br />Pharma Systems Pvt. Ltd.<br />199f, 27th Cross Road<br />7th 'B' Main, Jayanagar<br />Bangalore - 560 011<br /><br /><br />Peutronics Pvt. Ltd.<br />331-336, Raheja Arcade,<br />Koramangala,<br />Bangalore - 560095<br />Phone. : 5533156<br />Fax: 5533986<br /><br /><br />Perpetyal Power Technologies<br />842 A, 100 Ft Road, Indiranagar,<br />Bangalore - 560038<br />Phone. : 5254315, 8520407<br />Fax: 5297706<br /><br /><br />OCS International Pvt. Ltd.<br />No. 863D, 12th Main<br />IIIrd Block, Koramangala<br />Bangalore - 560 034<br />Phone: 530649, 5534903 Fax: 5533022<br />Nuko Information (India) Pvt. Ltd.<br />B-110, Block III, KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore - 561 229<br /><br /><br />Novell Software Development (India) Ltd.<br />A.M. Industrial Estate No. 49/1 &amp; 49/3<br />Garevebhavi Palya, 7th Mile Hosur Road<br />Bangalore - 560 068<br />Phone: 2219982/83 Fax: 2219929<br /><br /><br />Nobel Systems<br />6/1, Connaught Road<br />Queens Road Cross,<br />Bangalore - 560 052<br />Phone: 2266560, 2251040 Fax: 2256790<br /><br /><br />Netquest India Pvt. Ltd.<br />224/16, Ramana Maharshi Road<br />Bangalore - 560 080<br />Phone: 3312966, 3312967<br /><br /><br />NATSEM India Designs Pvt. Ltd.<br />1014 First Floor<br />3rd Cross, 13th Main, HAL 2nd Stage<br />Bangalore - 560 008<br />Phone: 5262110, Fax: 5543369<br /><br /><br />Multimedia Station Inc.<br />501, 5th Cross,<br />HMT Layout, Ganga Nagar<br />Bangalore - 560032<br />Motorola India Ltd.<br />108, Gavipuram Guttahalli,<br />Off Bull Temple Road,<br />Bangalore - 560019<br />Phone: 6612973/4/5<br />Fax: 6612977<br /><br /><br />Motorola India Electronics Pvt. Ltd.<br />Presidency, No. 1, St. Marks Road<br />Bangalore - 560071<br />Phone: 2218545 Fax: 2210841<br /><br /><br />Motor Industries Co. Ltd. (MICO)<br />Hosur Road, Adugodi<br />Bangalore - 560 030<br />Phone: 2220088 Fax: 2212728<br /><br /><br />Microland Ltd.<br />58, 80 Feet Road,<br />Koramangala Block 7,<br />Bangalore - 560095<br />Phone: 5534340<br />Fax: 5534992<br /><br /><br />Microcon Instruments and Systems<br />722/22 10th A Main Road<br />4th Block, Jayanagar<br />Bangalore - 560 001<br />Phone: 6633862 Fax: 6633862<br /><br /><br />Mentor Systems Solutions Pvt. Ltd.<br />5th Floor, AI-Tower<br />Golden Enclave Airport Road<br />Bangalore - 5263615, 5263751<br />Fax: 5586606<br /><br /><br />Menon Information Technology<br />No. 20(32), Lakshmi Towers<br />R.V.Road, Basavanagudi<br />Bangalore - 560 004<br />Phone: 3312528 Fax: 3312528<br /><br /><br />Macmet India Ltd.<br />40, Langford Road<br />Bangalore - 560025<br />Phone: 2238699 Fax: 2213984<br />Telex: (0845) 8152 MCMT<br /><br /><br />Linc Software Service Pvt. Ltd.<br />C-211, Block III, KSSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore - 561 229<br /><br /><br />Learn Soft<br />1 Floor Venkatadri Complex,<br />83, Richmond Road,<br />Bangalore - 560025<br />Phone. : 2217350, 2243616<br /><br /><br />LEC India Software Center (P) Ltd.<br />12th Floor, DU Parc Trinity, M.G.Road<br />Bangalore - 560 001<br /><br /><br />Kirloskar Multimedia Ltd. Cresent Towers, No.32/1 &amp; 32/2 Cresent Road, High Grounds<br />Bangalore - 560 001<br />Phone: 3363357 Fax: 2200016<br />Kirloskar Computer Services Ltd.<br />P.B.No. 5570, Malleswaram West<br />Bangalore - 560 055<br />Phone: 3322280, 3322082, 3322583<br /><br /><br />Kiefer &amp; Vettinger Information Sys P Ltd.<br />Jayaram &amp; Jayaram, 7/3, E Block, 1st Floor<br />Unity Building, Mission Road<br />Bangalore - 560 002<br />Phone: 2235264 Fax: 2223968<br /><br /><br />Intrak Software Systems Private Ltd.<br />702, 6A Cross, III Block<br />Koramangala<br />Bangalore - 560 034<br />Internet Systems (P) Ltd.<br />328/14, HBR Complex,<br />15 Th Cross, Jayanagar, II Block,<br />Bangalore - 560011<br />Phone. : 6639496<br />Fax: 6633706<br /><br /><br />International Computech Engg. Services<br />A-212, B-209/210, Block III, KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore - 561229<br />Intercope (India) Pvt. Ltd.<br />No. 41, 1st Cross, 3rd Main<br />Domlur 2nd Stage<br />Bangalore - 560071<br />Phone: 5278596 Fax: 5265351<br />E-mail: icope@stpb.soft.net<br />Integra Macro Systems Pvt. Ltd.<br />G 5&amp;6, Swiss Complex<br />No.33, Race Course Road<br />Bangalore - 560 001<br />Phone: 226007, 2267027 Fax: 2203928<br />Innovation Tech. Transfer (I) Pvt. Ltd.<br />1/5 Santosh Complex<br />Armugam Circle, Basavanagudi<br />Bangalore - 560 004<br />Phone: 6612226 Fax: 6612571<br /><br /><br />Information Mang. Res.(I) Pvt. Ltd.<br />Industrial Factory Building No. 38/1<br />Naganthapura Village, Singasandra Post<br />Bangalore - 561 221<br />Informatics Group<br />337, Karuna Complex, III Floor,<br />Sampige Road, Malleswaram,<br />Bangalore- 560003<br />Phone. : 3365940<br />Fax: 3367867<br /><br /><br />Indian Telephone Industries<br />Bangalore Complex, Dooravaninagar<br />Bangalore - 560 016<br />Phone: 8511211 Fax: 8511724<br /><br /><br />India Computer Center<br />11, King Street,<br />Richmond Town,<br />Bangalore - 560025<br />Phone. : 2215662, 2273921<br />Fax: 3320200<br /><br /><br />Imagine Information Technology Ltd.<br />No. 813, South Block, Eighth Floor<br />Manipal Centre, 47, Dickinson Road<br />Bangalore - 560 042<br /><br /><br />ITC Ltd.<br />B-309, Block III, KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore - 561229<br /><br /><br />IT Solutions India pvt. Ltd.<br />17, 3rd Floor, Southend Road<br />Basavanagudi<br />Bangalore - 6622153, 6617345, 6617346 Fax: 662154<br /><br /><br />IMR India Ltd.<br />38/4, Naganathapura Village,<br />Singasandra Post,<br />Bangalore - 560068<br />Phone: 5537691<br />Fax: 5532850<br /><br /><br />Honeywell Ltd.<br />Block III, KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore - 561 229<br /><br /><br />Hinditron Tektronics Instruments Ltd.<br />5, Crescent Road<br />High Grounds<br />Bangalore - 560 001<br />Phone: 2265470/71 Fax: 2250669<br /><br /><br />Hierarchial Object Oriented Dev. Comp.<br />Duplex Flats, A &amp; C Chandra Apartments<br />82 Infantry Road<br />Bangalore - 560 001<br /><br /><br />Heuristix Systems Pvt. Ltd.<br />239/A-1, 10th Cross, RMV Extension<br />Bangalore - 560080<br />Phone: 3340496, 3346589, and 3341740<br />Fax: 5586287 Telex: (0845) 2696,8055<br /><br /><br />Health Scribe India (P) Ltd.<br />B-202/B-203, Block III, KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore - 561 229<br /><br /><br />Gulftech India Pvt. Ltd.<br />No. 2008, 100 Feet Road<br />HAL II Stage<br />Bangalore - 560 056<br />Phone: 5561672, 5585152 Fax: 5580101<br /><br /><br />Genesys Interactive Systems (I) Pvt. Ltd.<br />F-5, First Floor, Hall Mark Appartments<br />1 Wheeler Road, Fraser Towen<br />Bangalore - 560 005<br />Phone: 5542078 Fax: 5542078<br /><br /><br />Faculties India Systems Services<br />#14, 8th Main Road, Malleswaram<br />Bangalore - 560 003<br />Phone: 3349594 Fax: 3346185<br />E-mail: gen-info@facind.com<br />Eurolink Overseas Pvt.<br />F-2, Block B-1<br />Mohan Co-op Industrial Estate<br />New Delhi - 110 044<br />Phone: 6948617, 6941831, 6941832 Fax: 6943732<br /><br /><br />Fidelio India Pvt. Ltd.<br />No.60, 4th Main Road<br />Domlur II Stage<br />Bangalore - 560 038<br />Phone: 5260691-93 Fax: 5260695<br /><br /><br />Esseven Infotech Ltd.<br />375, 1st Cross, 9th Main<br />Judges Colony, R.T.Nagar<br />Bangalore - 560 032<br />Phone: 3336730<br /><br /><br />Esseven Infotech Ltd.<br />289, 15 Main,<br />Malleswaram,<br />Bangalore - 560003<br />Phone. : 3312374, 3311730<br />Fax: 3311922<br /><br /><br />Equinox Solutions Pvt. Ltd.<br />130/1, Ulsoor Road<br />Bangalore - 560 042<br /><br /><br />Easi Technologies Pvt. Ltd.<br />204/C, 6th Main, 27th cross<br />III Block, Jayanagar<br />Bangalore - 560 004<br />Phone: 6631375 Fax: 6633888<br />EWI Engineers &amp; Consultants (I) Pvt. Ltd.<br />C/o S.Rao &amp; Co., Chartered Accountants, 300/1D<br />16th Cross Road, Upper Palace Orchards<br />Bangalore - 560 080<br />Phone: 3312528, 3313677 Fax: 3313679<br /><br /><br />EMpower India<br />No.414, I Cross, 7th Main Road<br />HAL II Stage<br />Bangalore - 560 008<br /><br /><br />EMRC Engineering Mechanics Research India (P) Ltd.<br />907, Barton Center,<br />84 MG Road,<br />Bangalore - 560001<br />Phone. : 5550298, 5594770, and 5586576<br />Fax: 5594770<br />Deutsche Software (India) Pvt. Ltd.<br />VIII Floor, Raheja Towers, 26-27, M. G. Road<br />Bangalore - 560001<br />Phone: 5596314, 5596320 Fax: 5597439<br /><br /><br />Deneb Hitech India Pvt. Ltd.<br />No.15, IAT Buildings<br />Millers Tank Bed, Queens Road<br />Bangalore - 560 052<br />Phone: 2205121 Fax: 564163<br /><br /><br />Decision Software India<br />26, Victoria Road<br />Bangalore - 560047<br />Phone: 560665, 579087 Fax: 226674, 2251468<br /><br /><br />Deccan Logitech Pvt. Ltd.<br />40, II Main, C.K.C. Garden<br />Mission Road<br />Bangalore - 560 067<br />Phone: 2224622 Fax: 2240866<br /><br /><br />DTA Software<br />3568/2, 4th Cross 15 th G main,<br />HAL, 2nd Stage,<br />Bangalore - 560038<br />Phone. : 5260921, 5261912<br />Fax: 5261911<br />DSM Soft (P) Ltd.<br />9, 15th Cross Street<br />Shastri Nagar, Adayar<br />Madras - 600 020<br />Phone: 4913878, 4911376 Fax: 4910847<br /><br /><br />DTA Software Pvt. Ltd.<br />15A, Kalpavriksha<br />12, Race Course Road, Madhavnagar<br />Bangalore - 560 001<br />Phone: 2261371 Fax: 2205469<br /><br /><br />DDMS Simulations S/W Consult Ltd.<br />657, 31st Cross, 11th Main<br />4th Block, Jayanagar<br />Bangalore - 560 011<br />Phone: 6634668 Fax: 6634229<br /><br /><br />DDE-ORD Systems Ltd.<br />29, Shanti Road, Shanti Nagar<br />Bangalore - 560 027<br />Phone: 2237674 Fax: 2236204<br /><br /><br />Cyber Systems<br />106, 1st Floor,<br />HAL II Stage,<br />Bangalore - 560075<br />Phone: 5283543<br />Fax: 5283543<br />Cyber Marketing<br />22, Koramangala Industrial Area<br />Bangalore 560091<br />Phone: 5534711<br />Fax: 5532427<br />Email: cminfo@geonexus.com<br /><br /><br />Cranes Software International<br />No. 5, Airport Road,<br />Domlur Layout<br />Bangalore - 560071<br />Phone: 5549338<br />Fax: 5546299<br /><br /><br />Cosystems (India) Pvt. Ltd.<br />9/2, 6th Floor, Dhondusa Complex<br />Residency Road<br />Bangalore - 560 025<br />Phone: 2271852, 2240994 Fax: 2261468<br />Coromandel Solutions (P) Ltd.<br />(Since Changed To Intgra Technosoft Private Limited)<br />CSL House, 1 Cross I Block, Jayanagar<br />Bangalore - 560011<br />Phone: 6647924 Fax: 6654669<br /><br /><br />Complete Business Solutions (I) Ltd.<br />19, Annaswamy Mudaliar Road<br />Bangalore - 560 042<br />Phone: 560188 Fax: 560188<br /><br /><br />Client Server System<br />45/7, Vinayaka Complex<br />II Floor, Presidency Cross Road<br />Bangalore - 560 001<br />Phone: 5598421<br /><br /><br />Clearview Technologies Private Ltd.<br />280, 21st Main, I Phase, II Stage<br />BTM Layout<br />Bangalore - 560 076<br />Phone: 6640636<br /><br /><br />Chandra Chemical Enterprises Ltd.<br />A-312, Block III, KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore - 561 229<br /><br /><br />Celsuistech Systems<br />S-175, Block III, KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore - 561 229<br /><br /><br />Capsoft India Pvt. Ltd.<br />No.401, IVth Floor, Hoysala Apartments<br />Cunningham Road<br />Bangalore - 560 052<br />Phone: 2204724 Fax: 2204987<br /><br /><br />Cantech Infor. Systems Pvt. Ltd.<br />308, Brigade Gardens, 19 Church Street<br />Bangalore - 560 001<br />Phone: 5594397 Fax: 5594398<br /><br /><br />Calogic Technology India Pvt. Ltd.<br />63, Palace Road<br />Bangalore-560 052<br />Phone: 2202565 Fax: 2202565<br /><br /><br />Cadus International Pvt. Ltd.<br />A-203, Blue Cross Chambers,<br />11, Infantry Road Cross,<br />Bangalore - 560001<br />Phone. : 5598502, 5598743<br />Fax: 6610863<br /><br /><br />CG Smith Software Ltd.<br />1-A, Peenya Ind. Estate, Peenya<br />Bangalore<br />Phone: 8391663 Fax: 8391665<br /><br /><br />CCE Software<br />(A Division Of Chandras Chemicals Ent. Ltd.)<br />A - 312, Software Technlogy Park , III Block , KSSIDC Building<br />Hosur Road , Electronics City<br />Bangalore - 561229<br />Phone: 8520989 Fax: 5533022<br /><br /><br />Building Network Automation<br />146, Shantala Plaza,<br />VII Main, XIV Cross Malleswaram,<br />Bangalore - 560003<br />Phone: 3345451, 3341902<br />Fax: 3314313<br /><br /><br />Britannia Industries Ltd.<br />Airport Road,Vimanpura<br />Bangalore - 560017<br />Phone: 560065, 561749 Fax: 560355<br />Telex: (0845) 8575<br /><br /><br />Bharat Electronics Ltd.<br />Software Export Department<br />144, Shubharam Complex, Ist Floor, M .G. Road<br />Bangalore - 560013<br />Phone: 5582367, 5583853 Fax: 543675<br />Telex: (0845) 8485 SOFX IN<br /><br /><br />Baysoft Private Limited<br />No. 30, Church Street<br />Bangalore - 560001<br />Phone: 5598939, 5598940 Fax: 5598941<br /><br /><br />BAeHAL Software Pvt. Ltd.<br />Airport Lane, HAL Estate<br />Bangalore - 560017<br />Phone: 5275867, 5262927 Fax: 5270915<br /><br /><br />Autodesk Inc.<br />206, Raheja Plaza, 17, Commissarait Road<br />Shoolay Tank Bed Area,<br />Bangalore - 564939<br />Phone: 564928, 564939<br />Fax: 564897<br /><br /><br />Authorisation Systems (I) Pvt. Ltd.<br />No. 502 Westiminister, 43, Cunningham Road<br />Bangalore - 560 052<br />Phone: 2205114/ 2205839<br />Aspect-DCM Pvt. Ltd.<br />Leo Complex, Vth Floor, Residency Road Cross-<br />Bangalore - 560 025<br />Phone: 5585342/1267 Fax: 5585238<br /><br /><br />Arcus Technology Pvt. Ltd.<br />201, Embassy Chambers<br />No.5, Vittal Mallya Road<br />Bangalore - 560 001<br />Phone: 2217307 Fax: 2210336<br />Analog Devices India Pvt. Ltd.<br />4/2, Samrah Plaza, 1st Floor, St. Marks Road<br />Bangalore - 560 001<br /><br /><br />Ampersand Software Applications Ltd.<br />No. 68, 14th Cross, R.T. Nagar 1 Block<br />Bangalore - 560032<br />Phone: 3336173<br />Fax: 3333891<br /><br /><br />Altair Software India Pvt. Ltd.<br />A-109, Block III, KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore - 561 229<br /><br /><br />Advanced Micronic Devices Ltd.<br />65, Arun Complex, DVG Road Basavangudi<br />Bangalore - 560004<br />Phone: 600631, 605224, 607800, and 604502<br />Fax: 6608785 Telex: (0845) 8332MDBG IN<br />E-mail: 74022,1564@compurserve.com<br />Aditi Technologies Pvt. Ltd.<br />224/16, Ramana Maharshi Road<br />Bangalore<br />Phone: 3312966, 3312967 Fax: 3346201<br />Email: Kp@aditi.com<br /><br /><br />AL Information Technology<br />A-105, Block III, KSSIDC Multi Storied Complex<br />Keonics Electronics City, Hosur Road<br />Bangalore - 561 229<br />AI Soft Pvt. Ltd.<br />910, Brigade Towers, Brigade Road<br />Bangalore - 560025<br />Phone: 2218262, 2218263<br />Fax: 2215604<br /><br /><br />Mentors Systems Solutions Pvt. Ltd.<br />5 Th Floor, A1 Tower, Golden Enclave, Airport Road<br />Bangalore - 560017<br />Phone: 5263615, 5263751 Fax: 5261418<br /><br /><br />Manhattan Associates Software (P) Ltd.<br />657, 11th Main, 31 st Cross, 4th Block, Jayanagar<br />Bangalore - 560011<br />Phone: 6634668 Fax: 6634229<br />Infosys Technologies Ltd.<br />Plot No. 44, 3rd Cross<br />Electronics City, Hosur Road<br />Bangalore - 561229<br />Phone: 8520261/2/8520270 Fax: 8520361/2<br />E-mail: nandan_mn@inf.com, freshers@inf.com<br />Index Computing Pvt. Ltd.<br />Sharrif Chambers, 14, Cuningham Road<br />Bangalore - 560052<br />Phone: 2250689 Telex: (0845) 8555, 8992<br /><br /><br />Hewlett-Packard (I) Software Operations Pvt. Ltd.<br />No. 29 , Cunnigham Road<br />Bangalore - 560050<br />Phone: 2265595, 2261254/1554/1075/5931 Fax: 2200196<br /><br /><br />BPL Systems and Projects Ltd.<br />64, Church Street<br />Bangalore - 560001<br />Phone: 91 (80) 5586598, 5597389<br />Fax: 91 (80) 5586971<br /><br /><br />BFL Software Ltd.<br />45/3, Gopalakrishna Complex, Residency Road<br />Bangalore - 560025<br />Phone: 5588722 Fax: 5581918<br />E-mail: bflgen@uranium.bfl.soft.net<br />Ashok Leyland Information Technology Ltd.<br />218/219, Raheja Chambers<br />12, Museum Road<br />Bangalore - 560001<br />Phone: 5587811, 5597924<br />Fax: 5584708<br /><br /><br />Advanced Synergic Microsystems Ltd.<br />80/2, Lussane Court, Richmond Road<br />Bangalore 560025<br />Phone: 2270547, 2274121/122<br />Fax: 2240548, 2273606<br />Telex: (0845) 2298 IFTK IN<br /><br /><br />Vishes Technologies<br />325, Chinmaya Mission Hospital Road,<br />Indranagar,<br />Bangalore - 560038<br />Phone. : 560050, 565600<br />Fax: 5565090<br />Srujana Technology<br />1037, Dr. Rajkumar Road,<br />IV Block Rajajinagar,<br />Bangalore - 560010<br />Phone. : 3380710, 3303175<br />Fax: 3388074<br /><br /><br />Select Systems &amp; Software (P) Ltd.<br />3050, 80 Ft Road,<br />HAL III Stage Indiranagar,<br />Bangalore - 560008<br />Phone. : 5281765<br />Fax: 5299033<br /><br /><br />SS Computers<br />Dugar House, 19,<br />Edward Road, Queen Road Cross,<br />Bangalore - 560052<br />Phone. : 2264884<br />Fax: 2255127<br /><br /><br />SRG Systems ( P ) Ltd.<br />35/3/A, Langford Road,<br />Bangalore - 560025<br />Phone. : 2233276, 2235246<br />Fax: 2218781<br />Ramsoft Technologies<br />4/1, XXII Cross-, VIII Main,<br />III Block, Jayanagar,<br />Bangalore - 560011<br />Phone. : 647152, 648102<br />Fax: 6631303<br /><br /><br />Nashsoft Systems<br />41, Lavelle Road,<br />Bangalore - 560001<br />Phone. : 2213345, 2271655<br />Fax: 2271657<br />Narmatha Electronics Centre<br />55, 13 A, Main Road,<br />Hanumanthanagar,<br />Bangalore - 560050<br />Phone. : 6019116<br />Inventa Software (India) Pvt. Ltd.<br />2, Nandidurg Road,<br />Benson Town,<br />Bangalore - 560046<br />Phone. : 3333427, 3335549<br />Fax: 3336026<br /><br /><br />Encompass Software &amp; Systems<br />129, Silver Lake Terrace,<br />167, Richmond Road,<br />Bangalore - 560025<br />Phone. : 5584068, 5584866<br />Fax: 5574322<br /><br /><br />Dharma Computers<br />#94, 4th B Cross Industrail Layout,<br />Koramangala V Block,<br />Bangalore - 560095<br />Phone. : 5533622, 5534601, and 5537114<br />Fax: 5537115<br /><br /><br />Cranes Software International<br />NO. 5, Airport Road,<br />Domlur Layout<br />Bangalore - 560071<br />Phone: 5549338<br />Fax: 5546299<br /><br />Brainware Infotech<br />92, Anjaneya, Temple Street,<br />Basavanagudi,<br />Bangalore - 560004<br />Phone. : 6616867, 6616895<br /><br /><br />3SE<br />8th Floor, Diamond Jubilee Commerecial Complex,<br />Hudson Circle,<br />Bangalore - 5600027<br />Phone. : 2211143<br />Fax: 2211152<br /><br /><br />Pertech Computers Ltd.<br />IV Floor, Shiv Shankar Plaza<br />19, Lalbagh Road,<br />Bangalore - 560027<br />Phone: 91 (80) 2240087, 2273349<br />Fax: 91 (80) 2273286<br /><br /><br />PSI Data Systems Ltd.<br />Shrutta Complex, 19, Primrose Road<br />Bangalore - 560025<br />Phone: 91 (80) 5585726<br />Fax: 91 (80) 5588298<br />Telex: (0845) 3056 PSIE IN<br /><br /><br />Mascot Systems pvt. Ltd.<br />A-208, Block III, Software Technology Park<br />KSSIDC Complex, Electronics City<br />Bangalore - 561229<br />Phone: 8520959, 8520960/1 Fax: 8520958<br /><br /><br />Digital Equipment (India) Ltd.<br />(A Subsidiary of Digitial Equipment Corporation, USA)<br />Digital Park, 92, Industrial Suburb II Stage, Yeshwanthpur<br />Bangalore - 560022<br />Phone: 3374785 Fax: 3374601<br />Telex: (0845) 8758<br /><br /><br />Repro Press (P) Ltd.<br />108, Ramanashree Chambers<br />37, Lady Curzon Road,<br />Bangalore - 560001<br />Phone: 91 (80) 5592938, 5598304<br />Fax: 91 (80) 5592938<br />Transoft International (P) Ltd.<br />No. 724, 24th Main Road<br />VI Phase, J.P.Nagar<br />Bangalore - 560078<br />Phone: 6633731<br /><br /><br /><br /><br /><br /><br /><br /><br />Web sites for jobs and placements:<br /><br />www.4work.com<br />www.bestjobsusa.com<br />www.careerbuilder.com<br />http://www.careermag.com<br />http://www.cdiis.com<br />http://WWW.CNC.CA<br />http://www.ctg.com: 80/onlresum.htm<br /><a href="http://www.dice.dlinc.com:8181/" goog_docs_charindex="23088">http://www.dice.dlinc.com:8181</a><br />http://www.edpcs.com<br />http://www.jobcenter.com<br />http://www.lcsjobs.com<br />http://www.MetroIS.com<br />http://www.net-temps.com<br />http://WWW.RECRUITAD.COM<br />http://WWW.SABEREDGE.COM<br />www.career.com<br />www.careercast.com<br />www.careerconnections.com<br />www.careerexchange.com<br />www.careermag.com<br />www.careermart.com<br />www.careermosaic.com<br />www.careerpath.com<br />www.careerweb.com<br />www.ciol.com<br />www.computerjobs.com<br />www.cweb.com<br />www.dice.com<br />www.dice.com<br />www.headhunter.org<br />www.hightechjobs.com<br />www.hotjobs.com<br />www.ibmcorporation.com<br />www.indoscape.com<br />www.jobcenter.com<br />www.jobdirect.com<br /><a href="http://www.jobjungle.com/" goog_docs_charindex="23732">www.jobjungle.com</a><br />www.jobs.com<br />www.jobserv.com<br /><a href="http://www.jobsite.com/" goog_docs_charindex="23789">www.jobsite.com</a> <br />www.jobtrack.com <br />www.londoncareers.com<br />www.monsterboard.com<br />www.net-temps.com<br />www.occ.com<br />www.occ.com<br />www.overseasjobs.com<br />www.showbizjobs.com<br />www.singaporecareers.com<br />www.softwarejobs.com<br />www.taps.com<br />www.technology_jobs.com<br />www.vjf.com<br />www.winjobs.co<br /><br /><a href="http://www.naukri.com/" goog_docs_charindex="24122">www.naukri.com</a> <a href="http://www.careersindia.com/" goog_docs_charindex="24143">www.careersindia.com</a> www.placementindia.com<br />www.alltimejobs.com<br /><br /><br /><br />Mail ids of HR<br /><br />ameetaroy @ hotmail.com<br />ANURAG@ADITI.COM<br />asterix @ india.dharma.com<br />bagga @ magix.com.in<br />bangalore @ universal_sw.com<br />blr_cv @ kindlesystems.com<br />bnravi @ vsnl.com<br />bslisd@vsnl.com<br />bslisd@vsnl.com<br /> career @ integramicro.com<br />careers @ inf.com<br />careers @ its.soft.net<br />careers@its.soft.net<br />careers@its.soft.net;<br />clblr @ hotmail.com<br /> crvcon @ vsnl.com<br />fresh_options @ yahoo.com<br />gr @ allsoft.com<br />hr.rbin@in.bosch.com<br />hr.rbin@in.bosch.com;<br />hr@isdc.savesmart.com<br />hr@isdc.savesmart.com<br />hr@sohm.soft.net<br />hr@sohm.soft.net<br />hr_cv @ kindlesystems.com<br />hrd@bsil.com<br />hrd@bsil.com;<br />hrd@icope.com<br />hrd@sonata-software.com<br />hrderp@bsil.com<br />hrderp@bsil.com<br />hrindia @ synopsys.com<br />hr-india@icode.com<br />hr-india@icode.com<br />hrsearch @ md2.vsnl.net.in<br />humint @ vsnl.net.in<br />idc-hrd@informix.com<br />idc-hrd@informix.com;<br />india @ cae.ca<br />india.issoft@axcess.net.in<br />india.issoft@axcess.net.in;<br />info @ uispl.com<br />insyst@vsnl.com<br />insyst@vsnl.com;<br />java @ g-c-i.com<br />jdarbar @ blr.vsnl.net.in<br />jobs @ kcsl.com<br />jobs @ octon.com<br />joinus @ axes_mach01.dsccc.com<br />kpapola @ trans_tech.com<br />krijal @ shakti.ncst.ernet.in<br />Linkers @ bgl.vsnl.net.in<br />manojpk @ giasbm01.vsnl.net.in<br />manushri@blr.pin.philips.com<br />mktig @ usa.india.com<br />nat @ rttsindia.com<br />nrupa @ satyam.net.in<br />optimum @ cyberway.com.sq<br />pentaban@bgl.vsnl.net.in<br />pnvgopali @ vsnl.com<br />rajesh @ iic.com<br />rect @ apcosoft.soft.net<br />resume @ Wipinfo.soft.net<br />rpsoft @ satyam.net.in<br />sudhakar@siverline.com<br />teamhr @ htcinc.com<br />tmiblr @ satyam.net.in<br />tspahwa @ hewitt.com<br />udhakar@siverline.com<br />Want2B @ aditi.com<br />want2B@aditi.com<br /><br /><br /> <br />This is a list of HR persons of various companies in B'lore!<br /><br />Doc files send to:<br /><br />1. Dss@Blr.Vsnl.Net.In Datamatics Simi<br />3441369<br />2. Pegote@Poboxes.Com Pegotei Morgan Sridevi<br />5588001/101<br /><br />3. Resume@Blr.Vsnl.Net.In Resource Mgmt<br /> Nikitha 509 7575<br /><br />4. Jobs@Sampoorna.Com Sampoorna Juliet 529 4330<br /> 5. Vista@Bgl.Vsnl.Net.In Vista Cons Sheila<br /> Mathews 2227439/ 5634<br /><br /> 6. Tmi.Blr@Smb.Sprintrpg.Ems.Vsnl.Net.In<br /> Tmi Rajani 5292701/8488<br /> 7. Abcit@Giasbg01.Vsnl.Net.In Abc Cons<br /> 5589438/529190<br /> 8. Sridhar@Blr.Vsnl.Net.In 6671750/73909<br /> 9. Crvcon@Giasbg01.Vsnl.Net.In Crv Cons<br /> 6644576/36493<br /> 10. Alphine@Blr.Vsnl.Net.In Alphine Cons<br /> 11. Headhunter.Mas@Rmb.Sprintrpg.Ems.Vsnl.Net.I<br /> n 643894<br /> 12. Venugopal.Pnv@Gems.Vsnl.Net.In<br /> P.N.Venugopal Ass. P.N.Venugopal<br /><br /> 13. Eurolink@Blr.Vsnl.Net.In Euro Link<br /> 14. Hrd@Altair.Soft.Net Altair 2220092<br /> 15. Itpeople@Blr.Vsnl.Net.In I.T.People 5597700<br /><br /> 16. Btiblr@Blr.Vsnl.Net.In Bti Consulta.<br /> 5591266/63<br /> 17. Medha@Giasbg01.Vsnl.Net.In Medha Cons<br /> 18. Neeraj@blr.vsnl.net.in Neeraj Jaipuria<br /> 2285452/456<br /> 19. Milialex@hotmail.com Lavora Cons Mili<br /> Alex 5542525<br /><br /> 20. scottk@bgl.vsnl.net.in IT Convergence<br /> Nagendra/Scott 5599955 (9 lines)<br /><br /> 21. arunt@giasbga.vsnl.net.in<br /> 22. ebsinfo@blr.vsnl.net Ebs Info<br /> 23. jessy@it.soft.net IT Solutions Mr.Jessy<br /> 6655122<br /> 24. liaizone@hotmail.com Liaizonei Deepak<br /> 5286682<br /> 25. nichi@blr.vsnl.net.in<br /><br /> 26. nucleus@vsnl.com Nucleus Preethi<br /> 5256071<br /><br /> 27. orbitinc@blr.vsnl.net.in 6649979-80<br /><br /> 28. sgl@bgl.vsnl.net.in<br /><br /> 29. snova@giasbg01.vsnl.net.in<br /><br /> 30. tram@blr.vsnl.net.in Personal Network<br /> Prathima 6711318<br /><br /> 31. mindpro@blr.vsnl.net.in Mind Cons Anil<br /> Kumar 2994030<br /><br /> 32. Contact Cons Latha 5281847<br /><br /> 33. HRM Cons Madhu 3441369<br /><br /> 34. hrd@bluestar.co.in bluestar<br /><br /> 35. careers@iis.stpn.soft.net<br /><br /> 36. resumes@india.hp.com HP<br /><br /> 37. resumes@ssil-india.com siemens<br />-<br /> 38. career@mahindrabt.com mahindra bti<br /> 39. idchrd@in.oracle.com oracle india<br /> Smitha 2256099<br /> 40. nigam@larsantech.wiprobt.ems.vsnl.net.in<br /> 41. resumes@fitjobs.com<br /> 42. mcsin@giasbm01.vsnl.net.in<br /> 43. ailindia@bom5.vsnl.net.in<br /> 44. bsiisd@giasbg01.vsnl.net.in<br /> 45. netcons@bom3.vsnl.net.in<br /> 46. resume-bombay@foundsoft.com<br /> 47. parity@bom3.vsnl.net.in<br /> 48. g.inyian@sap-ag.de sap<br /> 49. DSQ Software 5593847<br /><br /> 50. jayanji@hotmail.com ALP Career Chithra<br /> 2259616<br /><br /> 51. Ampersand Sunitha 3336173/6388<br /><br /> 52. BAEHAL Sandya 5268684/5296678<br /><br /> 53. Ellise Software Meera/CS Murali<br /> 5092523-25<br /><br /> 54. HCL Perot 6680312,86<br /><br /> 55. Kshema Technologies 2272933<br /><br /> 56. Omam Cons 5252387/5295094<br /><br /> 57. orbitinc@blr.vsnl.net.in Orbit Cons<br /> 6649979-80<br /><br /> 58. PSI Data Systems 5585726-27<br /><br /> 59. Skiline Software 2211961<br /><br /> 60. sourcecodeintl@vsnl.com SourceCode Intl<br /> Neeraj 2285452,56<br /><br /> 61. sgl@bgl.vsnl.net.in Sunitha Global<br /> Vikram 8420500,19,21<br /><br /> 62. Tata Infotech 5284681<br /><br /> 63. william_ms@hotmail.com Willys<br /> Placements Mosses 5243990<br /><br />Text Files Send to:<br />trsanjay@blr.vsnl.net.in<br /><br />Without Attachments Send to:<br />career@hiso.honeywell.com<br /><br /><br /><br /> <br />Fresher recruiting companies in Bangalore:<br /><br />a) HONEY WELL<br />b) INFOSYS TECH LTD<br />c) ORACLE SOFTWARE INDIA LTD<br />d) IBM GLOBAL SERVICES<br />e) IT SOLUTIONS<br />f) SILICON AUTOMATION SYSTEMS ( Electronics Background)<br />g) MOTOROLA (Electronics Background)<br />h) ADITI SYSTEMS<br />i) DIGITAL SOFTWAREJagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-25204269891359072982008-01-03T00:29:00.000-08:002008-01-03T00:24:48.405-08:00 FPGA I/O - When To Go Serial <DIV>&nbsp;</DIV> <DIV class=OutlookMessageHeader dir=ltr align=left><STRONG><FONT size=2><FONT color=#336699><SPAN class=style1>FPGA I/O  When To Go Serial </SPAN><BR></FONT></FONT></STRONG><EM>by Brock J. LaMeres, Agilent Technologies </EM></DIV> <DIV> <TABLE width=415 align=center border=0> <TBODY> <TR> <TD><IMG height=293 src="http://www.fpgajournal.com/articles/images/20040803_agilent_lead.jpg" width=400 NOSEND="1"></TD></TR></TBODY></TABLE> <P align=left>Over the past decade, FPGAs have gained a foothold as one of the most used building blocks in digital systems. The flexibility of an FPGA allows designers to decrease hardware design cycles while adding inherent feature upgradability in the final product. In addition, the data rates of modern FPGAs are competing with CMOS ASICs, thus allowing the needed system performance to be achieved using what was once only a proto-typing vehicle. </P> <P align=left>The data rates of modern FPGAs are giving designers the freedom to create their own application specific busses. However, designers are quickly learning the pitfalls of running I/O at high speeds. Factors such as channel-to-channel skew, jitter, and aperture window size are limiting the theoretical data rates of the FPGAs specifications. To address these issues, FPGA system designers are following suit to their ASIC predecessors and adopting I/O architectures that inherently reduce the effect of the above-mentioned factors. </P> <P align=left>This article will present the most popular I/O architectures in use today. In addition, the factors that degrade the performance of the I/O will be discussed for each architecture. Finally, a guide for selecting the appropriate I/O architecture for the application will be presented. </P> <TABLE width=525 align=center border=0> <TBODY> <TR> <TD> <DIV align=center><IMG height=333 src="http://www.fpgajournal.com/articles/images/20040803_agilent_1.gif" width=500 NOSEND="1"></DIV></TD></TR> <TR> <TD> <DIV align=center><STRONG>Figure 1. Modern digital systems are using FPGAs due to their flexibility and speed. Designers are facing the pitfalls of running I/O at high speeds. </STRONG></DIV></TD></TR></TBODY></TABLE> <P align=left><STRONG><FONT size=2><FONT color=#336699><SPAN class=style1>I/O CLOCKING ARCHITECTURES</SPAN><BR></FONT></FONT>Synchronous Clocking </STRONG></P> <P align=left>Synchronous clocking is the most widely used clocking scheme in digital systems. In this type of clocking, there is one clock that is distributed to all synchronous logic in the system. All transactions occur at a particular edge of this one clock. This type of clocking has the advantage that it is relatively simple to implement. However, in order to ensure timing accuracy, the clock distribution network must be matched in electrical length to all of the synchronous logic in the system. This becomes increasingly difficult when clock paths enter FPGAs with complex logic and connect multiple FPGAs that are created with various processes and different packaging. The variation in IC process and construction leads to timing error that degrades the performance of this type of clocking. Another limitation is that after a clocking event, the next clock must wait until the data has successfully traveled from one FPGA to the other. Examples of this type of architecture are the Pentium I uP, the PCI bus, and SDRAM memory.</P> <H2 class=style1>Source Synchronous Clocking </H2> <P align=left>Source Synchronous Clocking was developed to address the difficulty that synchronous clocking has with matching the clock distribution paths to each element in the system. In this type of clocking, the circuit that is producing the data pattern will create its own clock that is transferred along with the data. Generating the clock in the same geographical location as the data in addition to having the clock traverse the same media as the data bus creates a much tighter timing correlation. The tighter timing means that the data valid windows of the data being latched are better aligned with the clock used to latch them. This reduced channel-to-channel skew allows data transfer rates to exceed that of a synchronous architecture. Examples of this type of architecture are Intel's IA32 front side bus and DDR memory. </P> <P class=style1 align=left>Embedded Clocking </P> <P align=left>Source synchronous clocking is prone to the same channel-to-channel skew as synchronous timing, albeit at a much higher data rate. The difference in process variation and interconnect structure between channels within an FPGA will contribute to channel-to-channel skew no matter how tightly the clock is coupled to the multiple signals. To address this problem, embedded clocking was invented. In embedded clocking, the data is encoded in a manner that will guarantee a certain number of transitions per time (i.e., 8B/10B encoding). By ensuring that the data will transition a certain percentage of unit time, a PLL can then lock to the data stream. In embedded clocking, a PLL is used at the receiver that will lock onto the incoming data stream and create a clock based off of the transition frequency. This clock is then centered within the data valid window. The drawback of this type of clocking is that the clock centering is only valid for the data channel to which the PLL has locked. However, the data rate for an individual channel is only limited by its jitter margin and aperture window. This type of clocking can achieve extremely high data rates (&gt; 2.5Gb/s) relative to synchronous and source synchronous designs. This type of design requires more complex circuitry at both the driver and receiver but the data rates achieved are so much higher than previous architectures that the channel counts can be reduced while still delivering an overall throughput increase.</P> <TABLE cellSpacing=0 cellPadding=1 width=575 align=center border=1> <TBODY> <TR> <TD> <DIV align=center><IMG height=345 src="http://www.fpgajournal.com/articles/images/20040803_agilent_2.gif" width=550 NOSEND="1"></DIV></TD></TR> <TR> <TD> <DIV align=center><STRONG>Figure 2. FPGA Designers are changing their I/O architectures to overcome the signal integrity issues that arise when running at fast data rates. </STRONG></DIV></TD></TR></TBODY></TABLE> <H1 class=style1>FACTORS IN SELECTING AN I/O ARCHITECTURE </H1> <P align=left>The total throughput (or digital bandwidth) is defined as the number of symbols that can be transmitted per second. This depends on the Unit Interval that can be achieved per channel and the number of channels used in to the I/O architecture. </P> <P align=left><IMG height=89 src="http://www.fpgajournal.com/articles/images/20040803_agilent_text.gif" width=280 NOSEND="1"></P> <P align=left><STRONG>Channel-to-Channel Skew </STRONG></P> <P align=left>Channel-to-channel skew refers to the time difference of the data valid windows between various signal paths. This issue is due to electrical length differences in the physical signal paths. These paths vary for each channel due to the implementation of the circuit. </P> <P align=left>The skew between channels will limit the data rate of the I/O architecture. This is because the synchronizing clock for the data signals must be placed such that it can successfully latch in all of the data channels in the bus. To achieve this placement, the net data valid window of all of the overlaid channels must be large enough for the clock to be placed within. The more channels that are used increase the chance for channel-to-channel skew. As more channels are used, the net data valid window will decrease thus reducing the maximum transfer rate. </P> <P align=left>There are two main sources of skew. The first is the electrical length mismatch on the IC. The majority of this mismatch comes from the packaging interconnect. When using an FPGA, the complex logic can also be a major factor. As CMOS dies approach sizes of 20mmX20mm and packages reach signal counts into the thousands, the difference in channel path length becomes considerable. The on-chip skew is also exacerbated by the fact that signals are being driven from one large FPGA package to another. This can effectively double the skew due to on-chip path length. </P> <P align=left>The second source of skew is due to channel mismatch on the PCB. This skew is due to either a physical mismatch of PCB traces on the same layer or a propagation delay mismatch of PCB traces on different layers. The following figure shows an example of channel-to-channel skew. </P> <TABLE width=575 align=center border=0> <TBODY> <TR> <TD> <DIV align=center><IMG height=457 src="http://www.fpgajournal.com/articles/images/20040803_agilent_3.gif" width=550 NOSEND="1"></DIV></TD></TR> <TR> <TD> <DIV align=center><STRONG>Figure 3. Tools such as logic analyzers can give designers an in-sight into the net channel-to-channel skew that the FPGAs are experiencing. This measurement was taken using a tool called "Eye Finder" from Agilent Technologies, Inc. Note the data valid window size shrinkage when all of the signals in the bus are overlaid. </STRONG></DIV></TD></TR></TBODY></TABLE> <P align=left><STRONG>Jitter </STRONG></P> <P align=left>Jitter is a term that describes the timing uncertainty within a Unit Interval. Said otherwise, jitter is the amount of time within a UI in which it cannot be guaranteed that the data is at a stable logic level. This uncertainty region will limit how small of a UI can be used while still transmitting reliable data. The two major subsets of Jitter are deterministic and non-deterministic jitter. </P> <P align=left><EM>Deterministic Jitter<BR></EM>Deterministic jitter refers to sources of jitter that can be calculated. For example, if a product is specified to operate with 5% power supply variation, then the timing uncertainty due to supply drop needs to be considered in the data rate specification. While how much timing uncertainly will vary from application to application, the entire range of timing uncertainty must be accounted for. Some possible sources of deterministic jitter can be process variation, ISI, reflections, simultaneous switching noise, power supply droop, and RC load variation. These sources can all be quantified in the design and added to a timing uncertainly stackup. The worst-case impact of each of these sources must be accounted for in a stable design. </P> <P align=left><EM>Non-Deterministic Jitter <BR></EM>Non-deterministic jitter refers to statistical sources of timing uncertainty. These are sources in which the noise contribution is modeled by their probability distribution rather than their worst-case value. Traditionally these sources are modeled using a Gaussian distribution. The figures-of-merit for these sources are their RMS value or standard deviation. For these types of sources, the worst-case impact does not need to be accounted for since statistically it will happen infrequently. Instead, a <EM>bit error rate</EM> is used to predict system stability. A few examples of these types of noise sources are thermal and shot noise. Multiple sources of statistical noise are accounted for using an RMS summation to find the net contribution of statistical noise. </P> <P align=left>Jitter can be very difficult to predict. Typically its contribution is found using jitter measurement techniques in an oscilloscope. By allowing an acquisition to accumulate for a relatively large amount of time, the distribution of jitter can be found. A note on this technique is that all of the sources of jitter are measured simultaneously. While this has the drawback of not isolating individual sources, it is usually the only method available to FPGA designers. </P> <TABLE width=575 align=center border=0> <TBODY> <TR> <TD> <DIV align=center><IMG height=351 src="http://www.fpgajournal.com/articles/images/20040803_agilent_4.jpg" width=550 NOSEND="1"></DIV></TD></TR> <TR> <TD> <DIV align=center><STRONG>Figure 4. Jitter measurement taken on a 2.5Gb/s signal using a 54750A sampling oscilloscope. Note the histogram used to find the jitter distribution. </STRONG></DIV></TD></TR></TBODY></TABLE> <P align=left><STRONG>Receiver Aperture Window </STRONG></P> <P align=left>The final contribution to the speed of an I/O design is the aperture window of the receiving element. This is traditionally called setup and hold but refers to the minimum time that the data must be stable before and after the timing event in order for the receiver to capture the symbol. The aperture window must be able to fit within the net data valid window of all of the overlaid data channels to ensure successful data collection. FPGA manufacturers will specify this value. However, complex logic and data path variation will degrade the ideal specification. In most cases a measurement is needed. </P> <P align=left><STRONG>Calculation of Throughput </STRONG></P> <P>The combination of channel-to-channel skew, jitter, and receiver aperture dictate how fast the I/O design can operate. We define the channel-to-channel skew as the time difference between the transition regions of two channels when operating in the same phase (i.e., intending to transmit a symbol at the same time). The following equations relate the total bit transfer rate per channel to the sources of error described above. </P> <P align=left><IMG height=89 src="http://www.fpgajournal.com/articles/images/20040803_agilent_text2.gif" width=225 NOSEND="1"> </P> <H1 class=style1>SELECTING AN FPGA I/O ARCHITECTURE </H1> <P align=left>The first step in selecting an I/O architecture is determining the design's data throughput requirement. Once this is defined, I/O architectures can be evaluated for selection. This is an interactive process requiring measurement data. All of the factors, channel-to-channel skew, jitter, aperture window, will increase as signals are added to the I/O design. The best way to find these contributions is through empirical data from oscilloscopes and logic analyzers. </P> <P align=left>Starting with the simple synchronous architecture, signals can be added to increase the overall throughput. As signals are added, the degradation factors must be observed. At some point, the addition of signals is no longer practical because of the adverse signal integrity contributions, the main contribution being channel-to-channel skew. </P> <P align=left>At this point, the source synchronous architecture can be explored. The major advantage of this architecture is that it dramatically reduces the channel-to-channel skew within a data group. At some point the channel-to-channel skew will again become an issue, but at a much higher data rate. The skew in this architecture will be on the same order of magnitude as the jitter contribution. </P> <P align=left>Finally, the embedded clock architecture can be examined. This architecture has the advantage in that there is no channel-to-channel skew due to the clock/data recovery design. In addition, the jitter is reduced because there is no longer a data channel <EM>and</EM> a clock channel that possess jitter. This architecture will be limited only by the jitter and aperture window contribution. </P> <P align=left>If industry I/O standards are observed, they typically fall into the following table of data rates. </P> <TABLE cellSpacing=0 cellPadding=1 width=400 align=center border=1> <TBODY> <TR> <TD> <P align=center><STRONG>Individual Channel Data Rate </STRONG></P></TD> <TD> <P align=center><STRONG>Clocking Scheme </STRONG></P></TD></TR> <TR> <TD vAlign=bottom> <P align=center>DC  300 Mb/s </P></TD> <TD vAlign=bottom> <P align=center>Synchronous </P></TD></TR> <TR> <TD vAlign=bottom> <P align=center>300 Mb/s - 2Gb/s </P></TD> <TD vAlign=bottom> <P align=center>Source Synchronous </P></TD></TR> <TR> <TD vAlign=bottom> <P align=center>&gt; 2G/bs </P></TD> <TD vAlign=bottom> <P align=center>Embedded Clock </P></TD></TR></TBODY></TABLE> <DIV align=center><SPAN class=style3><STRONG><FONT size=1>Table 1. <BR>Per channel data rates observed in industry for the clocking architectures presented. <BR>This illustrates the evolution of I/O architecture of both ASICs and in FPGAs. </FONT></STRONG></SPAN></DIV> <P><STRONG>&nbsp;CONCLUSION </STRONG></P> <P align=left>As FPGA speeds have increased over the past decade, designers are using FPGAs as an alternative to ASICs. However, designers are quickly discovering that the increased FPGA speeds are leading to the same signal integrity problems that ASIC designers have been facing for years. As signals are added to an I/O architecture to increase the total throughput, the channel-to-channel skew, jitter, and aperture window contributions are increased. To address these problems, FPGA designers must turn to different clocking architectures. In order to maintain the trend of increased system data rates, a designer using FPGAs must first understand all of the contributions to the unit interval reduction in order to be successful. </P> <P align=left><EM>Brock J. LaMeres, Agilent Technologies </EM></P> <P align=left>August 3, 2004 </P> <P align=left>---------------------------------------------------</P> <P align=left><EM>About the Author: <STRONG>Brock LaMeres</STRONG> received his B.S.E.E. from Montana State University and his M.S.E.E. from the University of Colorado. He is currently a hardware design engineer for Agilent Technologies, where he designs high-speed printed circuit boards used in logic analyzers. He is also a part-time instructor in microprocessor systems at the University of Colorado in Colorado Springs. His research interests include modeling and characterization of transport systems and high-speed digital design. </EM></P></DIV> <P><FONT size=2><BR></FONT>&nbsp;</P><FONT face=Arial color=#000000 size=3> <P>&nbsp;</P></FONT>Jagdishnoreply@blogger.com0tag:blogger.com,1999:blog-4188889258526451328.post-79804309977339473052008-01-03T00:12:00.000-08:002008-01-03T00:19:31.890-08:00Thoughts of VLSI Design Engineer<span style="color:#000099;"><strong>Lets now try to study the mind of an Good RTL designer</strong></span><br /><br />As soon as the Designer has a specification to write an RTL. He studies his neighbours(his nearby modules ) to know who gives him data and to who he has to deliver the data.<br />so his first work is to prepare the stub file(skeleton of ports list). say the clock names,reset signals, input and output signals, scan signals…<br />Now he has the stub file ready he can pass it on to the placement person(if he is interested in preparing the floorplan).<br />Now his next thought is to prepare a micro-architecture of the specification, study the electrical specifcation and prepare the timing-diagrams required of his module. As well he needs to think of internal partitioning of the blocks to minimize the complexity involved and to concentrate well.<br />Study on Bus-Architectures which are the performance booster's<br /><a href="http://www.vlsichipdesign.com/busarchitectures.html" target="_blank">http://www.vlsichipdesign.com/busarchitectures.html</a><br />Now the Designer has studied his specification well now internally in his mind he discusses about the various trade-off's like<br />* Memory or a Register Files (pro's and Con's).<br />* Synchronous reset or Asynchronous Resets.<br />* How to ensure that the DFT(Design for Test) related clocks to reach all the flops.<br /><a href="http://www.vlsichipdesign.com/test.html" target="_blank">http://www.vlsichipdesign.com/test.html </a><br />* In case of any cross-clocking or in case if his design has multi-clocking structures need to better understand the data transfer mechanism , like hand-shaking, FIFO requirements, depth of FIFO, synchronizers and all to prevent Metastability and ensure proper data transfer.<br /><a href="http://www.vlsichipdesign.com/FIFO_depth.html" target="_blank">http://www.vlsichipdesign.com/FIFO_depth.html</a><br />* Understanding of Good Coding Styles<br /><a href="http://www.vlsichipdesign.com/verilog_coding_styles.html" target="_blank">http://www.vlsichipdesign.com/verilog_coding_styles.html</a><br />* Understanding of Timing Requirements in the design (Scenario's where Falsepath's/Multicycle-paths ).<br />To understand how to achieve faster timing closure<br /><a href="http://www.vlsichipdesign.com/timing_closure.html" target="_blank">http://www.vlsichipdesign.com/timing_closure.html</a><br />To understand the concepts of Static Timing Analysis<br /><a href="http://www.vlsichipdesign.com/static%20timing%20analysis.html" target="_blank">http://www.vlsichipdesign.com/static%20timing%20analysis.html</a><br />To understand what all to think while preparing the Design timing constraints<br /><a href="http://www.vlsichipdesign.com/synopsys_constraints.html" target="_blank">http://www.vlsichipdesign.com/synopsys_constraints.html</a><br />* Understand the depth of the combinational logic between sequential: This could be an issue for meeting timing requirements if the logic levels are more and increase in the test-pattern generation in the DFT.<br />* how to write an RTL how generic it could be.<br />* How to write RTL so that it could be power friendly like have module enable signal's, and enable signal generation logic so that automatic clock-gating insertion is friendly<br /><a href="http://www.vlsichipdesign.com/clockondemand.html" target="_blank">http://www.vlsichipdesign.com/clockondemand.html</a><br />* How to write an RTL so that it is friendly for Verification(say Assertion based tools to generate on Assertions).<br />To understand the various Verification Methodologies<br /><a href="http://www.vlsichipdesign.com/asic_verification.html" target="_blank">http://www.vlsichipdesign.com/asic_verification.html </a><br />* Writing Synthesis Friendly RTL Coding.(say for example the code synthesis to a priority-encoder for a requirement of a MUX, the code comes with a latch in case if all the possible states are not defined in a switch-case statement or else mentioning with a default switch and things like that).<br />* Writing RTL power optimized. in case if the requirement is for using DVFS(Dynamic Voltage Frequency scaling) then preserving the states of the control register's(Decision makers of the design) with a State retention based flops some thought ahh..<br />To know the various Sources of power dissipation in an CMOS design<br /><a href="http://www.vlsichipdesign.com/power_in_CMOS.html" target="_blank">http://www.vlsichipdesign.com/power_in_CMOS.html </a><br />these are the few thoughts….Jagdishnoreply@blogger.com0