fpga design 6?1 rev. b ? 25 may. 98 scope this application note describes design practices that make a ulc conversion schedule shorter, and accom- plished with reduced risk. this note is recommended for a designer considering a conversion to a ulc, or for a de- signer before starting an fpga design. for the designer considering a conversion to a ulc, this application note will give background on the reasons for the questions in the ulc design checklist. for the designer just starting and fpga design, this application note shows that much can be done during the fpga design process to reduce the ulc conversion schedule and risk. this application note is probably not needed by an experienced asic designer, because the experienced asic designer is almost certain- ly following these design practices already. this application note is in three sections: overcoming timing difficulties ? an introduction to good design practices good design practices. good simulation practices. these ?good design practices? also apply to good fpga design, even if not converting to a ulc, and to good asic design. although following these practices is not mandatory, it is recommended. in all cases, for a ulc conversion, a feasi- bility study is done first to determine if a conversion should be successful. the feasibility study includes a de- termination of the degree of conformance to these practic- es, and an assessment of the degree of difficulty of a con- version. if these good design practices have been followed, it is virtually assured that the results of the feasi- bility study will be positive; if the practices have not been followed, there is a chance that the results of the feasibil- ity study will be negative. note that the effective use of cad/cae tools depends on the designer following these design practices. if good de- sign practices have been followed, the tools work much better, faster, with much less manual intervention, and re- port fewer errors and warnings that must be resolved by the ulc designer. overcoming timing difficulties ? an introduction to good design practices first a word about good fpga design practices. good fpga design practices include allowing margins for tim- ing variations. timing variations occur as the chip oper- ates over a temperature range, and due to fabrication pro- cess variations. when a designer uses trial and error in the system lab to design an fpga, with no system?level specification for the fpga and little knowledge of timing margins, the resulting fpga could be undependable over temperature and process. fpga designers should use good design practices, and simulation, to make sure that this does not happen. however, note that if the fpga op- erates in production without problems for some time, this is proof that it is likely that adequate timing margins exist. now, on to conversion considerations. converting the fpga design to anything else (not just ulcs) means re? targeting the design to a new set of timing parameters, similar to those of the fpga, but not exactly the same. a ulc is smaller and generally faster, like most asics, relative to an fpga. the fastness of the ulc can be a problem if the fpga requires long delays on some paths. on the other hand, the ulc can be slower than global clock (fast?path) features on fpgas, and this can be a problem if the signal travels across the chip. also, ulc setup and hold are usually different; ulc setup is about zero, and hold is about 2?5ns, whereas fpga setup and hold is generally the opposite. ulc designers know how to handle the conversions, but the conversion is much eas- ier if the fpga designer uses good design practices, and simulation. if the timing tolerances are known, atmel wireless & mi- crocontrollers assures that a successful fpga conversion can be achieved, whether or not the fpga has been simu- lated. this is assured by using atpg (automatic test program generation) and associated fault simulation/ grading. before tapeout of the ulc, the ulc vectors, whether generated by the customers? simulations or by atmel wireless & microcontrollers atpg, are tested on the fpga in an ic tester, where timing is analyzed, and functionality is verified if tester or simulation vectors are provided by the customer. note that only customer?provided vectors will check for correct functional operation; the atmel wireless & mi- crocontrollers atpg vectors are used to check logic con- formance to a customer specification and/or within toler- ance of the fpga timing, but these latter vectors do not check functionality (so the logic in the fpga had better represent the desired functionality). also note that only pin?to?pin vectors contribute to assuring the correctness good fpga design practices, aid fpga conversion to a ulc
fpga design 6 ? 2 rev. b ? 25 may. 98 of the conversion; simulation vectors that set internal nodes during simulation are welcome information but do not directly aid in checking the conversion. also, note the test vectors, used after fabrication, are created from cus- tomer ? provided vectors and may not reach 85% of fault coverage as required. in this case, atmel wireless & mi- crocontrollers inserts scan to increase fault coverage. of course, jtag is supported. atmel wireless & microcontrollers has proven tech- niques that have been used to convert hundreds of fpgas, many done when the original fpga designer was not available to answer questions. however, we al- ways do a (free) feasibility study to make sure that the conversion should succeed, and the result of the feasibil- ity study is generally positive. good design practices atmel wireless & microcontrollers ulc designers use a ? feasibility risk assessment ? checklist to record their analysis of the fpga submitted for a feasibility study. this checklist covers the design practices described in this application note, and it makes sure that the ulc de- signer assesses the potential problems in those areas where good design practices have not been followed and therefore there is increased risk that the conversion will take longer, or be unsuccessful, unless appropriate mea- sures are taken. this sheet is shown in figure 1. the fol- lowing paragraphs are a description of these items, in the same order, and same numbering, as the table.
fpga design 6 ? 3 rev. b ? 25 may. 98 figure 1. feasibility risk assessment (rev. 1) mask & company name: date: feasibility study designer(s): with vectors without vectors analyze the following (assign a risk factor if the ? good design practice ? has not been used) risk rating (0 ? 10; 10 is bad)* estimated extra days if need comments: 1. timing well ? specified (internal and external), i.e., a specification (with timing) 2. master clear (initialization); or small set of vectors to get to known state; a way to circumvent por (if any) 3. only ffs drive reset (no combinatorial logic driving reset) 4. avoided gated clocks 5. avoided internally ? generated clocks (used on ? chip) 6. avoided counters or control states over 10 bits without taps 7. glitches into a ff data ? in before clk 8. avoided combinatorial loops (including no home ? made ffs) 9. avoided internal tri ? states 10.avoided redundant or fault tolerant circuits 11.avoided global clocks too fast to meet tim- ing; & delay blocks or programmed delays; & deglitching circuits 12.avoided demand for high fault coverage, e.g., 95% 13.avoided special noise standards 14.avoided asynchronous circuits 15.no dynamic programming (fatal) totals: 1. write a specification on functionality and timing of the fpga. this is for the reasons described above. also, provide schematics and other items listed on the custom- er questionnaire. 2. use master clear, i.e., an asynchronous reset from an external pin. second best is a small set of vectors to get to a known state. this means that there must be a way to circumvent any por (power on reset), and rapidly get to a known state. timing cannot be verified using simula- tion if the logic cannot be efficiently taken to a known state. the same is true for fault simulation/grading (used to generate tests that determine if the fabrication process is ok, and if enough logic has been tested to assure a suc- cessful conversion ). (don ? t use a bi ? direct buffer on re- set, or clock inputs, because it will make a mess of the simulation vectors when it goes to the z state.) 3. use only ffs to drive reset (in addition to master clear). in other words, the reset to a ff needs to be syn- chronized and stabilized, and this is done by driving the reset from a data output of another ff, or else glitches can occur, causing errors. so, for example, the correct construction of a divide ? by ? 3 counter would be as shown in figure 2.
fpga design 6 ? 4 rev. b ? 25 may. 98 dq nq dq ck nq dq ck nq dq ck nq nck ck nr nr nr ck figure 2. correct construction of a divide ? by ? 3 counter also, if you need to generate a short pulse, instead of connecting a ff ? s q to its reset, do as shown in figure 3. dq nq dq ck nq ck ck in out r figure 3. if must make pulses, do it this way 4. try to minimize the use of gated clocks, because they cause more skew between the clock and the data. in lay- out, the skew can be a real challenge to accommodate. if the skew cannot be accommodated, spikes occur. of course, an enable on the clock that has been built into the cell library is ok, because this circuit is specially con- trolled by the cae tools, including the layout tools, but designer ? generated gated clocks cause errors and warn- ings by the cae tools and, if there are enough of them spread around the logic, layout may not be able to get rid of the skew everywhere, and the conversion may have to be aborted (aborted toward the end of the design phase, which means that much design time will have been wasted). 5. try to minimize internally generated and used clocks (created using sequential or combinatorial logic), because the distribution of such clock lines inside the chip are sub- ject to skew that may not be accounted for by clock tree generation software and thus will likely have skew prob- lems. this is similar to the problems in items 3 and 4. (so use of equations to generate clock signals in an fpga de- sign is not advised.) 6. try to keep counters, dividers, control state logic, etc., segments to less than 10 bits, as seen from the input/out- put pins, or add taps. if more than 10 bits, long counters should have taps for monitoring, or at least have a pre ? load function. these taps should somehow easily propa-
fpga design 6 ? 5 rev. b ? 25 may. 98 gate their data to output pins. the reason for this good practice is that the number of simulation vectors and test times required are too much without it. 7. construct logic to minimize glitches, and when a glitch is unavoidable, make sure that it settles out at the data in- put of a ff (flip flop) before this ff is clocked. also, glitches into reset, set, or clock inputs to a flip flop must be avoided; as stated above, we recommend not using combinatorial logic in reset, set, or clock in the first place. 8. avoid combinatorial loops (including combinatorial latches), and pulse generators. any combinatorial design whose proper operation depends on delays through logic elements is dangerous. this is especially true in ulcs and asics but is also true for fpgas. so don ? t design as- suming that the delay down any combinatorial path is pre- dictable, and that the difference in time down two differ- ent paths to the same destination is predictable. it isn ? t (unless very carefully controlled, as is done when creating the logic inside the cell of a cell library). pulse widths and delays vary substantially over temperature, process varia- tions, re ? layouts, and voltage variations. 9. internal tri ? states are best avoided, although we prob- ably can handle them with some difficulty. if internal tri ? states are unavoidable, avoid floating nodes. these can occur when all of the buffers driving a bus are disabled. add a buffer to drive the bus when all of the other buffers are off. 10. try to avoid redundant or fault tolerant circuits, al- though we can handle them with some difficulty. the dif- ficulty comes during re ? synthesis to the ulc, where re- dundant logic is minimized out (and thus must be manually added back in). please inform us if this type of circuitry is in your design. 11. minimize the use of global clocks (fast paths), delay blocks, programmed delays, and deglitching circuits, be- cause it is difficult (but generally not impossible) to match the timing. the global clock is only a problem when converting (to a ulc) if the signal travels across the chip. the delay blocks and programmed delays are problems because any function that depends on delay of the logic elements is difficult to reproduce (the min/max delay window in the converted material is too big), as explained in item 8 above. deglitching circuits are also difficult to reproduce for the same reason ? the min/max delay win- dow in the converted material is too big. 12. try not to insist on high fault coverage (e.g., 95%). although it sounds good to demand the same fault cover- age as on an asic, this adds to the time (and thus cost) of the conversion and does not provide the degree of benefit it does for an asic. first of all, asics are designed with design ? for ? test rules so that scan logic can be efficiently added, and its supporting cae tools will work efficiently. fpgas usually are not designed using these rules. the good design practices of this application note are nearly the same as the design ? for ? test rules for scan, so if these good design practices are followed completely, adding scan should not be a problem. however, if the practices are not rigorously followed, adding scan can take much time, and, in a few cases, may not be made to work proper- ly. (scan is a method where logic is added to each flip flop to allow all of the flip flops to be connected in a serial string in test mode so that test bits can be inserted and ex- tracted in/out of the ffs between each normal clock pulse, effectively turning the flip flops into i/o pins for test, thus eliminating the very negative effect of the flip flops on generating an effective test using just real i/o pins.) we try to achieve 85% fault coverage without adding scan. keep in mind that the merit of high fault coverage is that it provides a somewhat better check on the fabrication process ? it contributes nothing to the accuracy of the con- version. we have other ways to check the fabrication pro- cess, including conservative process and packaging yield monitoring, and iddq testing can be added if the custom- er deems it necessary. of course all of this will not be an issue if the fault coverage percentage gets to 95% without adding scan logic, as is often the case. on the other hand, at the other extreme, if the design has a big function but few pins in and/or out, e.g., a digital filter, we may not be able to achieve a great enough fault coverage percentage to be confident of the conversion, not to mention the mon- itoring of the processing. in other words, our primary concern is an accurate conversion, which depends on get- ting the fault coverage up using testing from the i/o pins only, and adding scan logic will not help this (at least at present ? day levels of relatively low logic usage in fpgas as converted). we have found that 85% test coverage is good; 60% is ok; and under 50% is definitely risky. 13. let us know about any noise requirements or stan- dards that must be met, because we can use our slow slew rate buffers to avoid noise problems (we have slew rate control). 14. try to use synchronous design as much as possible, because asynchronous design often depends on element delays, which, as we said in several places above, is diffi- cult to duplicate in a conversion. 15. no dynamic reprogramming if you plan to do a con- version. we can handle on ? board ram, but not if used for dynamic re ? programming. in other words, we can generally assure timing with one set of program parame- ters in an fpga but it gets too complicated when these pa- rameters are changed on the fly. so, in fact, we only hard ? wire the programmed parts. (note that this means that, for fpgas that use the daisy chain method of programming, we can convert all of this set of fpgas, or any fpgas that are not the master, but we can ? t be the master when the slaves are not our conversions, i.e., not if the slaves are expecting to be programmed. that is, our converted slaves simply pass the programming data down the daisy chain. our master cannot generate daisy chain program- ming information.)
fpga design 6 ? 6 rev. b ? 25 may. 98 good simulation practices why simulate? an fpga designer should simulate to: make sure that the fpga timing margins are adequate. save time in the lab by designing on the computer, and using simulation to make sure that functionality is right and that all functions have been provided. end up with an fpga in good shape for conversion to a ulc. learn the same design techniques that will prepare the designer for asic design. don ? t forget to follow the good design practices too. also, remember to always go back to the design file and simulations on the computer as the ? master ? of your de- sign. two kinds of simulation as has been discussed somewhat above, we are interested in two different kinds of simulation ? functional, and atpg ? based simulation with fault grading. definitions of these terms is not consistent in the industry, so let ? s make it clear that ? functional ? simulation is generated by the designer and is used to verify the design, whereas, atpg (automatic test program (testlist) generation) is software that is applied against a design file by a test engi- neer and it analyzes the circuit and generates test vectors for testers that exercise the logic such that any stuck ? at ? 1 or stuck ? at ? zero faults will propagate to the output pins and thus be detected. so note that atpg vectors have no idea about the function of the logic; they only try to exer- cise it to detect faults (whatever the functional use of the logic). atpg test was invented when functional test on testers started taking too long. it started with circuit boards, long before asics were invented. the atpg ? generated test exercises the combinational logic in just a few seconds on the tester. it is the sequential logic that causes the prohibi- tively long test times. a popular solution for this problem for asics, in conjunction with atpg, is adding scan log- ic to effectively get rid of the sequential logic in the test generation. as explained in item 12 above, scan makes more sense for asics than for ulcs. in the ulc & asic worlds, atpg testing is mainly in- tended to provide good parts testing to determine that the fabrication process for the ulc or asic is working prop- erly. it has nothing to do with verifying the design or proper functionality of the chip. so the less percentage of fault coverage, the less confident that the atpg test will catch ic processing faults. note however that atpg test- ing is essentially a static test, and dynamic faults may not be detected by it. also, stuck ? at faults don ? t include bridging faults, etc. so we ? re not talking a perfect per- centage when we achieve a certain percent of fault cover- age. however, one of the big appeals of this method is that is does indicate some relative degree of test coverage in the form of a percentage, whether it ? s exactly right or not. when generating atpg tests, the test engineer often starts with a subset of the functional tests vectors, if these type of vectors are available from the designer. the de- signer selects a few hundred or thousand functional vec- tors to ? prime ? the atpg testing. these vectors usually result in about 60% fault coverage. then the designer goes on to generate the atpg vectors, adding to the fault coverage. take special note that the designer, in functional simula- tion, may often set and monitor nodes other than the in- puts or output to the chip. these parts of the functional simulation are of no direct benefit to the atpg testing. atpg testing requires input/output vectors only. (but send all vectors for a conversion; all information is use- ful.) when creating functional vectors for simulation, think in terms of a limited number of vectors to achieve functional verification ? don ? t think in terms of real time, because real time takes too long. one second of real time of chip operation can be days of simulation time. one cannot af- ford to simulate por (power on reset) or things like real diagnostic programs. instead, one must devise simulation vectors that test the functionality in just a few hundred or thousand vectors. a 15k vector test on the tester should be the target (no extra charge); however well over 100k can be accommodated but may cost more (because of the cost of the tester time, which is hundreds of dollars per hour). simulation and conversion to ulcs in converting an fpga to a ulc, the atpg vectors pro- vide another use besides increasing the quality via better testing for detecting processing faults, and this additional use is that these vectors are used to check the timing, espe- cially i/o pin ? to ? pin timing, to make sure that the timing of the converted design into the ulc is within the neces- sary windows as compared to the timing of the fpga be- ing converted. in other words, the ulc designer takes any customer ? provided functional test vectors whose ? i/ os ? are at the i/os of the fpga and uses them in the front of his atpg program. the ulc designer then runs the atpg software to add more vectors. the resulting test is analyzed for timing compatibility with the fpga being converted. this is done before and after layout of the ulc. these tests are also applied to the fpga itself in an ic tester, after layout but before tapeout, of the ulc.
fpga design 6 ? 7 rev. b ? 25 may. 98 these test are also used in wafer probe test, prototype test (before sending the fabricated part to the customer for checkout), and production test. so these test vectors are targeted to several testers, using software made for that purpose. (note that the fpga designer ? generated atpg vectors would be welcome but an fpga designer likely won ? t be producing them because fpgas are built with- out benefit of fault grading. asic designs generally use fault grading.) what you can do so what can an fpga designer do to make conversions easier, in light of what is needed for the conversion? one thing is that the fpga designer can use simulations at the i/o pins as much as possible. it often works to simulate pieces of the design, and then combine the pieces and sim- ulate the whole (from the i/o pins). note however that each piece that is simulated requires the designer to set up a new simulation environment, which does take consider- able time. so it pays to plan how this will be done and how much time it will take to do it. doing all simulation from the i/o pins from the beginning is best, but only if the de- signer is confident that it will take less time to debug the design than if it were done in pieces first. obviously, large designs must be done in pieces. also, the more experi- enced designers can probably do larger pieces than the less experienced. another thing that will help in conversion is vectors that do not try to stress the clock skew or variations due to processing, temperature, layout, etc. depend on the envi- ronment options of the simulator for this (worst case tem- perature, etc., best case, normal, etc.). use good design practices and conservative design rules so that you are not tweaking the logic to make it work. if good design rules are followed, it is fine if the data ? just makes it ? to the next clock pulse. fpga vendor simulation tools the fpga vendors all provide simulation tools. they may charge extra for these tools. the books provided by the vendor teach how to do simulation. most also have on ? line help, and hotlines. further information, and the latest information, is found on the home page of the ven- dor ? s world wide web site. they all have email as well, which is very convenient. in addition, most have regular- ly ? scheduled training classes. conclusion give simulation a try if you haven ? t already. it will result in an fpga less likely to have problems in its application, and it will make conversion to a ulc much easier. give the good design practices a try too, and thus increase the quality of the parts, and conversion to a ulc will be a breeze!
|
