This article provides a comprehensive methodology that highlights the best practices for mixed-language design integration and automatically comes up with an option for designers to select the optimal method for integration. There are broadly five ways of making mixed-language connections. Pros and cons of each of these approaches and their comparison is described in terms of the usage scenarios, performance implications of using one versus the other, delta cycle value update concerns, and more. A step-by-step guideline based on decision-making trees that designers can follow to help them decide which approach best suits their particular mixed-language integration scenario is also discussed.
Showing posts with label Best Practices. Show all posts
Showing posts with label Best Practices. Show all posts
Home » Posts filed under Best Practices
Being efficient while Working Remotely
I am sure many of you have worked off-site and telecommuted for employers using email, chat, and web-based collaboration apps. But working with people in different cities and time zones with minimal visual interaction presents a whole new set of challenges. While the tools available for working remotely are better than ever, it's how you use them that really counts. Constant and clear communication is the key to a good remote working relationship. Here are some best practices I've found for working remotely online.[Article Via Elaine, Qualcomm]
Best Practices for Reducing Risk through Environmental Compliance Data Collection
Complying with the variety of environmental regulations has become a challenging task for electronics OEMs (Original Equipment Manufacturers). There are frequent changes to RoHS regulations and exemptions; the REACH SVHC list may be revised up to twice a year; large OEMs are developing their own unique requirements. This white paper describes GreenSoft's data collection services for RoHS/REACH/Full Disclosure Material Data. This overview illustrates some of the procedures and tools of analysis during data collection process that can help your company reduce risk in the compliance management for all your products.
Are latches really bad for a design?
It is not completely correct to say that we have to avoid latches in our designs. In one of our recent projects we went a good extent debating only the disadvantges of using latches and then we had to can all the latches because many were not convinced. There are cases where you can safely use latches, just that you have to be little careful and the designer needs to be really sure of the impending functionality. In this post lets look at all possible cases where latches are preferred and where they are not. If you think if any of the statements are wrong, lets have a healthy debate.
The bad guys (Please add more):
1. One of the main reasons that latches are not used in designs is due to combinational loop back and subsequent oscillation which creates super problems in simulation, and also simulation Vs synthesis mismatches.
2. Due to controllability issues in latches unlike FF's, they can significantly harm STA/DFT and thereby reduce coverage in both cases.
3. The major factor for the above uncontrollability are Glitches in the enable pin of the latches that can cause unrecoverable failure
4. Last but not the least.. :-) the biggest culprit of all... inferred latches after synthesis due to bad coding styles.
Advantages:
1. Latches consume less power and area compared to FF's
2. If the design is not power aware, FF's are prefered and almost all the latches could be replaced by FF's without affaecting functionality.
3. Remember that the decode of a latched address can begin before the latch is actually closed..:-)
Corrective Measures:
1. A glitch-free enable helps if latches are unavoidable.
2. If you are synthesizing the code that generates the enable, please consider the direct instantiation of the logic using gates that drives the enable to the latch. Now you can be double sure!
3. A good input hold time ensures that the data is held long enough before you close the latch. If your latch enable is derived from a clock, the latch will lag the clock, requiring the latch's D inputs to be held valid after the clock edge.
NOTE: The latch has a disadvantage of being "transparent" till the clock makes the latch the value of the input. The FF samples the input on the risinf or falling edge of the clock.
Bottomline:
If you are not careful.... when developing synchronous digital designs, latches can generate asynchronous circuits that become unstable.
The bad guys (Please add more):
1. One of the main reasons that latches are not used in designs is due to combinational loop back and subsequent oscillation which creates super problems in simulation, and also simulation Vs synthesis mismatches.
2. Due to controllability issues in latches unlike FF's, they can significantly harm STA/DFT and thereby reduce coverage in both cases.
3. The major factor for the above uncontrollability are Glitches in the enable pin of the latches that can cause unrecoverable failure
4. Last but not the least.. :-) the biggest culprit of all... inferred latches after synthesis due to bad coding styles.
Advantages:
1. Latches consume less power and area compared to FF's
2. If the design is not power aware, FF's are prefered and almost all the latches could be replaced by FF's without affaecting functionality.
3. Remember that the decode of a latched address can begin before the latch is actually closed..:-)
Corrective Measures:
1. A glitch-free enable helps if latches are unavoidable.
2. If you are synthesizing the code that generates the enable, please consider the direct instantiation of the logic using gates that drives the enable to the latch. Now you can be double sure!
3. A good input hold time ensures that the data is held long enough before you close the latch. If your latch enable is derived from a clock, the latch will lag the clock, requiring the latch's D inputs to be held valid after the clock edge.
NOTE: The latch has a disadvantage of being "transparent" till the clock makes the latch the value of the input. The FF samples the input on the risinf or falling edge of the clock.
Bottomline:
If you are not careful.... when developing synchronous digital designs, latches can generate asynchronous circuits that become unstable.
