|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?注册
x
本帖最后由 cjsb37 于 2013-4-29 09:17 编辑
These tips are intended to show you how to build reliable designs for your FPGA. These tips apply to any vendor of FPGAs, and are not used to “fix” the FPGA, but the design. Lots of designers create designs that fail because they do not follow these guidelines. Note that these tips can vary somewhat for CPLDs.
Don’t gate clocks
Don’t route clock signals through the Look-Up Tables (LUTs). These “internally generated clock signals” can glitch easily.
Instead of routing this signal to the clock port of the synchronous elements in the FPGA, route them to the clock enable port.
Not gating clocks also reduces the number of clock signals routed inside the FPGA.
If you do not have a clock enable resource on each register, this will be implemented as an input to the combinatorial logic driving the register (LUT).
Use the global routing resources
This reduces clock skew which makes the design more likely to run reliably.
Virtex has fewer global routing resources that are intended for the distribution of clock signals only.
Older families have more global routing resources that can be used for any control signal (CE, Set, Reset, etc.).
Use the MaxSkew attribute in the UCF on control signals that are routed on general interconnect, especially clocks.
Register your Asynchronous input signals
This means signals which are not registered by the same clock frequency as the FPGA registers may need to be registered, or use a synchronization circuit.
Consider using the IOB flip-flop to register your input. Note that these flip-flops often have variable set-up and hold times.
Synchronization circuits may also be necessary for transferring signals between clock domains within the FPGA. Remember that synchronization circuits can prevent set-up and hold time violations on asynchronous inputs. which can cause failure of the circuit due to metastability.
Design with a Synchronous Set/Reset
Use of Asynchronous Set/Reset can easily create circuits that glitch.
Use the Global Set/Reset (GSR) resources in the older device families to reduce the skew on a set/reset.
Don’t use the GSR in Virtex. The GSR has too much delay and general interconnect will distribute this signal quickly.
Choose the best State Machine Encoding scheme
Binary encoding is good for creating small (less than 16 states) FSMs in FPGAs. Larger FSMs require too much Next state logic and perform slower when binary encoded.
One-Hot encoding is good for building larger FSMs since it requires very little Next state logic. OHE is more reliable than Binary encoding, because fewer bits change at once making the circuit less likely to glitch. OHE leaves a lot of unused states in the FSM and also uses a lot of registers (but there are a lot of registers in FPGAs).
Gray encoding of your state machine uses less resources than OHE and also gets good speed. Gray encoding is also the most reliable encoding technique, because only one bit changes per transition. However, Gray encoding requires the designer to be very aware of the coding technique chosen when simulating the FSM, and this is often a pain.
Note that custom encoding can be an excellent solution if there are not many cases where more than one bit changes at once.
Creating your Binary FSM in the Virtex Block Ram resources can create a reliable FSM by transitioning all the bits at once.
Properly code your FSM
Do not leave undefined states in your FSM. Use a default statement or point the unused states to a reset state.
Do not infer latches in your FSM. This builds unreliable circuits with designs that mix registers and latches. Assign all outputs a value when in every branch of an if/then and case statement. Use an Else or When Others statement to fix this.
Use a Case statement. This will create a faster FSM since If/Then statements create priority encoders, which infer multiple levels of logic.
Try to avoid causing ground bounce in your design.
Ground bounce can occur when many output pins simultaneously switch (SSO). It is accentuated when many of the output pins are assigned fast slew rate.
Ground bounce causes the functionality of the circuit to appear random. This is caused by the device’s internal ground rising above the board level ground. When this happens some of the registers may trigger twice.
Always use sufficient decoupling capacitors.
Never assign fast slew rate to all of your output pins. Instead assign fast slew rate to those output paths that need a little bit better performance.
Consider alternative coding techniques for your counters and state machines so that all of the bits do not transition at once.
Add an extra ground pin to the design. Tie an unused output pin near the SSO pins to ground, and externally connect this to the board’s ground plane. This pin should be using the LVTTL I/O standard with the highest drive capability.
Note that the Virtex E/EM differential I/O standards (LVDS, BLVDS, and LVPECL) should not ever encounter ground bounce.
Consider alternative techniques to create your counters
Binary encoded counters can suffer from the same problems as binary encoded FSMs.
Gray code and Johnson counters have only one bit transition at once, and are thus more reliable than binary encoded counters. Consider using these when possible or necessary.
In general, when these design techniques are followed, your design has a greater chance of working properly. This also means that you can reduce your simulation effort and complete your design sooner.
|
|