Configurable Timing ParametersFlexROM III gives you control over some of its timing parameters. If you are not a hardware type then these options may not make much sense. Don't worry about it. The default settings will almost always work. These options are provided to enhance the emulator's robustness in particularly noisy targets or targets that violate some of our specs. Even in those rare cases, you should be able to make reasonably well-informed selections based on the descriptions below and minimal help from your hardware engineer. Throughout this section, we will be talking about control signals and timing requirements. To keep things readable, we need to agree on some acronyms. The follow acronyms are commonly used when talking about memory devices:
|CS||Chip Select||Enables the device when driven low|
|OE||Output Enable||Enables the devices output buffers if CS is active|
|WT||Write Enable||Enables a WRITE cycle if the CS is active|
|BHE||Byte High Enable||Selects D8-15 for any valid cycles|
|BLE||Byte Low Enable||Selects D0-7 for any valid cycles|
|Tacc||Address Access Time||Time from address stable to valid data out|
|Tcs||Chip Select Access Time||Time from CS enabled to valid data out|
|Toe||Output Enable Access Time||Time from OE enabled to valid data out|
|Twp||Write Pulse Width Time||WT line is held active during a write cycle|
|Tcr||Cycle Recovery Time||Time between the end of a cycle and the beginning of the next. A cycle ends when CS goes inactive or both OE and WT go inactive. A cycle begins when CS is active AND either OE or WT goes active.|
NOTE: It is somewhat of a misnomer to talk about a device's ACCESS TIME. There really is not a single access time spec. The device will provide data only after meeting ALL access time specs. Generally, when we say a device has a '70ns access time' we are referring to the Tacc spec which is usually equal to the Tcs spec.
Fast CS AccessNormally, FlexROM III drives its SRAM CS (chip select) lines with a buffered version of your target's CS line and provides stable data 45ns after the last transition on address or after CS goes active - whichever is later.
Enabling FAST CS ACCESS causes FlexROM III to force its SRAM CS lines always active. FlexROM III's output buffers are still gated with your target CS so the emulator continues to honor all target control signals. This reduces the emulator's Tcs access time from 45ns to 12ns.
Many targets will decode their CS signal off of address lines. This makes the Tcs the determining factor in setting its ACCESS time requirements. The Tacc might be 45ns but due to decoding delays, the Tcs could be 30 - 40ns. In this situation, the FAST CS option would allow our 45ns emulator to function properly in a target that normally requires a 30-40ns emulator.
You normally would not turn this option on unless your target has a Tcs requirement of < 45ns and its addresses are stable before CS is activated.
Turning on this option will result in higher operating current requirements and could increase system noise in targets that have extended periods of address line float.
Fast OE AccessNormally, FlexROM III drives its SRAM OE (output enable) lines with a buffered version of your target's OE line and provides stable data 45ns after the last transition on address or after CS goes active, or 30ns after OE goes active - whichever is later.
Enabling FAST OE ACCESS causes FlexROM III to force its SRAM OE lines always active. FlexROM III's output buffers are still gated with your target OE so the emulator continues to honor all target control signals. This reduces the emulator's OE access time from 30ns to 12ns.
Turning on this option will result in slightly higher operating current requirements and could increase system noise in some targets during target writes to the emulator.
You normally would not turn on this option unless your target has a Toe timing specification of < 30ns. However, it generally does not hurt to do so.
It is acceptable to use FAST CS and FAST OE at the same time.
FilteringFlexROM III provides the ability to filter noise out of the target's control signals before using them to control the SRAMs or to detect the end of valid cycles (for arbitration, snap-shot & trigger). Any noise on a control signal while it is active can corrupt a target write or cut into the read margins. Filtering out this noise greatly improves emulator performance in noisy environments.
The up side to filtering is a more robust emulator. The trade-off (there's ALWAYS a trade-off) is that the greater the filtering, the longer it takes to determine that the cycle really ended. For example, if we are filtering out pulses shorter than 20ns, the true end of cycle must obviously last somewhat longer than 20ns or we will filter it out as noise. Even if end-of-cycle gets filtered out, the target can usually continue to function properly. The end-of-cycle detection is used to update our SNAP-SHOT register, the trigger circuit and to terminate target write cycles.
The default settings enable the control line filters and sets them to minimum filtering. This is a reasonable default that allows full speed access on most targets. In fact, most targets could increase the filtering to MAX and still meet timing.
The only time you may have to turn off filtering is if:
- The target does writes to the emulator OR you are doing READY mode arbitrated accesses.
- AND the target has very short cycle recovery times
- AND the target has fast access time (45ns) requirements
If you are not doing arbitrated accesses to the emulator and the target does not write to the emulator, you can usually add as much filtering as you want. In this situation, too much filtering on a target with short recovery times would result in the SNAP-SHOT & trigger circuits failing to update, but the target would function correctly as long the LATCHING options (see next section) are left at their defaults.
LatchingFlexROM III always latches the address lines during a target write. This enables it to enforce proper address hold times to the SRAM despite varying path delays or sloppy target timing. By default, they are only held stable while the target CS and WT signals are BOTH active.
In some cases, it might be desirable to latch the addresses on reads as well as writes or to latch them as soon as CS goes active. To avoid latching noise, it is sometimes desirable to delay latching until some time after the control signal. Most system noise occurs immediately after control signal transitions. Delaying the actual freezing allows the signals to settle.
FlexROM III gives you the ability to select the source that triggers the latch and how long AFTER the trigger it will wait before actually freezing the signals.
The latching options and possible reasons you would want to use them are listed below.
Latch on CS activeThis triggers the latch when CS goes active, irrespective of WT or OE. You might choose this setting if your system has a very narrow WT active signal. Latching the addresses much earlier in the cycle may make it possible to operate in a target that violates our MNIMUM Twp spec of 25ns.
It may also allow us to operate properly in a target that generates noise on the address lines while the write cycle is in process. Once a write has started, it is illegal to change the address lines. Any noise on the address lines during the write will corrupt one or more memory locations. Some targets will have stable addresses just before the WT goes active, but generate noise right after or during the WT active. Latching earlier in the cycle makes us immune to these violations.
DO NOT USE THIS SETTING IF YOUR TARGET PERMANENTLY GROUNDS (ENABLES) THE CS SIGNAL.
You also would NOT want to use this setting if your target does burst reads to the emulator. This occurs when the target asserts CS and OE and then does a sequence of ADDRESS - controlled reads without releasing either CS or OE between each access. In this case, you could use the 'LATCH on CS and NOT OE' setting.
Latch on CS and WT active (default)This triggers the latch when we see BOTH CS active and WT active. This is the default setting. It is appropriate in most cases.
Latch on CS and either WT or OEThis latches the addresses when CS is active AND EITHER WT or OE are active. This might be appropriate if noise on the address lines is causing access time violations. 'LATCH on CS ACTIVE' is another option if your target does not have its CS line grounded and it does not do burst-reads.
Latch on CS and NOT OEThis setting triggers the latch when CS goes active, but then RELEASES the address lines if it sees OE go active. This allows us to do early latching if desired but still support targets that do burst-reads.
Latch Delay EnableThis option specifies IF (and how much) we delay actually freezing the address lines after a signal triggers latching. Most address line noise occurs immediately after control signals activate or when the emulator begins driving data back to the target. Being able to delay latching the address until after the noise settles down makes it possible for us to be immune to it.
The default setting is Latch Delay is ENABLED and set to its minimum delay setting.