FlexROM™ III Arbritration

NOTE: These items have been discontinued for a long time.
We no longer support these products or offer alternatives.

We retain these pages so that users can see what their existing tools support and to provide download links to the final documentation and software versions. We have a few replacement parts left, but not many. Available items have an 'ADD to CART' or 'Buy Now' button next to them. Otherwise they are not available.

logo has a few items in stock as well.


FlexROM III™ provides hardware based arbitration support. This hardware works with your target's hardware to affect arbitration, allowing you to read and write the emulator's memory while the target is accessing that same memory. This may be useful for updating data tables, strings or constants on-the-fly. The full-screen editor will even allow you to look into memory to see if the target left any messages there for you. Regardless of arbitration settings, FlexROM III will ALWAYS grant access to the HOST whenever the target is powered down or being held in reset. FlexROM III supports several different arbitration methods which are described below:


In Request/Grant arbitration, FlexROM II will assert a /REQUEST before each access to the memory space. The FlexROM III hardware arbiter will then wait until the target asserts a /GRANT signal before generating the memory cycle. At the completion of the access, FlexROM II will release the /REQUEST signal and return control of the memory space back to the target.

FlexROM III does not actually access the target's bus, but requesting access (and waiting for a grant) insures that the target will not attempt to interrupt our access to our memory. These arbitration signals (/REQUEST and /GRANT) could be connected to your target's BUS request/grant, DMA request/grant or similar control lines. Of course many micro-controllers do not support any type of bus mastering or DMA operations. Note that this is hardware based arbitration and very efficient. FlexROM III will release /REQUEST within 300ns after /GRANT is asserted.


In Ready Arbitration, FlexROM III inserts wait states into target cycles to affect arbitration. NOTE that this is radically different than simply slowing down your target with wait-states. FlexROM III will insert wait-states ONLY DURING COLLISIONS. Your target runs at full speed except during the brief moment in which the target attempts to access FlexROM III's memory while it is being accessed by the FlexROM II itself. This is a hardware based arbitration method.

The HOST posts a request to read or write to the emulator's memory space. FlexROM III hardware watches the target's accesses and waits for the end of a target access before starting its own access. This minimizes the chances of a collision (minimizing the impact of arbitration). Once FlexROM III sees a target access complete, it isolates its SRAM from the target and starts its own access. If the target starts an access before the FlexROM III has completed its access, FlexROM III asserts the /READY signal. This signal is held active until FlexROM III has completed its access, re-enabled the target side buffers and the memory has had time to complete the current target access. At this point, /READY is released and the HOST is notified that the access completed.

The /READY line should be connected to your target's wait-state circuitry.

Cycle Interleaving

This technique depends on the emulator's internal CYCLE time plus its target ACCESS time being less than the target's CYCLE time. Since FlexROM III avoids interrupting target accesses, and uses hardware based arbitration, it is possible to use CYCLE Interleaving if your target's memory CYCLE time is greater than 300ns. Many micro-controllers and some microprocessors meet this criterion.

To use this method, configure FlexROM II for READY mode arbitration, but leave the /READY line disconnected.

Cycle Paralleling

This technique depends on you being able to find a signal in your target that guarantees the HOST exclusive access to the emulator. This is often much easier than it sounds. For example, most processors cannot fetch from their code space at the same time they are reading or writing their data space. In such systems, you may be able to use the DATA WRITE line or the SRAM chip select signal to indicate to the emulator that it is OK for the HOST to access the emulator's memory. The idea is that as long as the target is busy writing to its DATA space, it won't attempt to access its code space and therefore could not collide with the HOST access. Other candidate signals might be IO READ, IO WRITE, or other peripheral chip selects. If your target offers none of these, you might be able to create a valid signal. You could instrument your firmware to periodically toggle an unused pin or access an unused but decoded memory or IO space to generate a stimulus that allows the emulator to gain access. To use this mode, configure the emulator for REQUEST/FEGRANT or REQUEST/REGRANT and attach the selected signal to the emulator's GRANT line. Do not connect the REQUEST line to anything. The target is GRANTING us access every time it accesses the SRAM in this case. The emulator will always wait for the START of a grant signal before initiating an access. The start is defined by a FALLING edge or a RISING edge of the signal, depending on which arbitration mode you selected (REGRANT or FEGRANT). The time from the START of this GRANT signal to the next time the target may need data from the emulator must be at least 300ns for this to work.


This is not true arbitration, but is worth mentioning. In some cases, arbitration is not really required, as long as the emulator does not tie up the bus too long. A good example of this is look-up data tables. We have several customers using this technique to do on-the-fly modifications to Engine Controller ROMs, wave-form synthesizer ROMs, graphics ROMs, character generator ROMs, etc. If your application uses the EPROM or FLASH device to hold data rather than code, and it can tolerate an occasional bad fetch (wrong data), it may be acceptable to simply allow FlexROM III to collide with the target during the access. Note that FlexROM III will not hold the target's bus or corrupt anything on the target's bus. It simply isolates itself from the target's address and data bus during its access, causing the target to fetch garbage during the collision. Each FlexROM III access will isolate it from the target for approximately 300ns. You have two options when using this method. You can configure FlexROM III for CYCLE Interleaving (ready mode, but do not connect the ready line). This has the advantage of minimizing the probability of a collision since FlexROM III will wait until it sees a valid target cycle end before starting its cycle. Also, we will only collide if the target cycle time is less than 300ns. The down-side is that if the target stops accessing the emulator's memory space or accesses it infrequently, arbitration will time out.

The other option is to configure FlexROM III for REQUEST/FE-GRANT arbitration and then short the REQUEST line to the GRANT line; ensuring that FlexROM III always receives an immediate grant. This method will always allow FlexROM III access to the memory, but will blindly disrupt any current target access.


Of course this is not arbitration, but it is always worth asking "Do I really need to arbitrate at all?" If the changes that you will make to the EPROM/FLASH will require re-starting the target to take affect (like code changes), arbitration is not required (or desired). Simply let FlexROM III assert reset during the modifications. FlexROM III will then be guaranteed access to the emulation memory and the target will be automatically re-started after the changes.