ADM-XRC SDK 2.8.1 User Guide (Linux)
© Copyright 2001-2009 Alpha Data


The plxddsm2 component

Overview

HDL source code

Signals

Usage

Overview

NOTE: this component supersedes the plxddsm component.

The plxddsm2 component is part of the localbus package and provides the control mechanism for a demand-mode DMA channel in a local bus interface within an FPGA design. This component cannot be used in isolation; it cooperates with the plxdssm component in order to provide a complete local bus interface with the capability to perform demand-mode DMA.

HDL source code

Projects making use of this component must include all of the following source files (relative to root of SDK installation):

fpga/vhdl/common/localbus/localbus_pkg.vhd
fpga/vhdl/common/localbus/plxddsm2.vhd

Signals

The signals of this interface to and from the user application are as follows:

Signal Type Function Note
burst in Allow bursting during demand-mode DMA local bus cycle

This signal is ignored unless a local bus cycle is in progress.

If this signal is asserted while a demand-mode DMA local bus cycle is in progress, ldreq_o_l remains asserted. If this signal is deasserted while a demand-mode DMA local bus cycle is in progress, ldreq_o_l is deasserted.
1
clk in Local bus clock

This port must be driven by the clock that drives the local bus interface of the FPGA design.
 
idle out Interface idle

This status output indicates whether or not the plxddsm2 instance is currently handling a demand-mode DMA local bus cycle. It may be asserted for two reasons:
  1. There is no cycle in progress on the local bus.
  2. There is a cycle in progress on the local bus, but the qlads signal was not asserted at the beginning of the cycle, meaning that the FPGA determined that it was not the target of a demand-mode DMA local bus cycle.
 
lblast in LBLAST# in

This input must be driven by an active high version of the LBLAST# signal from the local bus.
 
lbterm in LBTERM# in

This input must be driven by an active high version of the LBTERM# signal from the local bus.
 
ldreq_o_l out LDREQ# out

This output must drive one of the LDREQ# pins on the local bus.
 
lready in LREADY# in

This input must be driven by an active high version of the LREADY# signal from the local bus.
 
qlads in Qualified address strobe

This input should be pulsed for one clock cycle, when a local bus cycle begins. This signal is typically generated by qualifying the LADS# signal by simple address decoding along with the corresponding LDACK# signal. In most cases, the FHOLDA signal is also used.
 
ready in Data ready

The user application should assert this signal when it is ready to transfer data during a local bus cycle. This signal should be the same as the ready signal that is input to the associated plxdssm instance.
 
request in Request demand-mode DMA local bus cycle

This signal is ignored when a demand-mode DMA local bus cycle is in progress.

The user application should assert this signal when it wishes to initiate a demand-mode DMA cycle. If request is asserted while no demand-mode DMA local bus cycle is in progress, plxddsm2 will assert ldreq_o_l.

request should be held asserted until the requested demand-mode DMA cycle occurs, and may be held asserted over multiple demand-mode DMA cycles if desired.
1, 2
rst in Asynchronous reset

This port may be driven by an asynchronous reset for the local bus interface, or tied to logic 0 (if not required).
 
sr in Synchronous reset

This port may be driven by a synchronous reset for the local bus interface, or tied to logic 0 (if not required).
 

Notes

  1. Both the request and burst signals are used to generate ldreq_o_l, but which one is used at a given moment depends on whether or not there is a demand-mode DMA local bus cycle in progress. If no cycle is in progress, ldreq_o_l is generated from request. If a cycle is in progress, ldreq_o_l is generated from burst.
  2. The purpose of the request signal is different to that of the ready signal. The ready signal permits data transfer to occur in a local bus cycle that has already started. The request signal, on the other hand, is used to control whether or not the PCI-to-local bus Bridge generates demand-mode DMA local bus cycles.

    Deasserting request prevents plxddsm2 from asserting ldreq_o_l which in turn prevents the PCI-to-local bus Bridge from generating further demand-mode DMA cycles for a given DMA channel. Asserting request causes plxddsm2 to assert ldreq_o_l, which in turns allows the PCI-to-local bus Bridge to generate demand-mode DMA cycles for a given DMA channel.

Usage

This component works by snooping on demand-mode DMA local bus cycles. When no demand-mode DMA local bus cycle is in progress, plxddsm2 asserts ldreq_o_l if and only if its request input is asserted. During a demand-mode DMA local bus cycle, plxddsm2 asserts ldreq_o_l if and only if its burst input is asserted. Thus, the possible values of request and burst yield the following behaviour:

request burst Behavior
0 X Not requesting a demand-mode DMA cycle.
1 0 Requesting a demand-mode DMA cycle, but after the demand-mode DMA cycle begins, pause the DMA transfer as early as possible by deasserting ldreq_o_l.
1 1 Requesting a demand-mode DMA cycle, and keep ldreq_o_l asserted so as not to pause the DMA transfer.

The purpose of request and burst is to enable a data source or sink within the target FPGA to exercise control over the burst length. This is necessary when, for example, data is being sourced onto the local bus from a FIFO, and the FIFO is almost empty. FIFO underflow must be prevented by limiting the burst length of the next demand-mode DMA cycle. For a typical application where a FIFO sources data that is being read by demand-mode DMA cycles, the request and burst signals might work as follows:

Another way that the target FPGA can control burst length is via the stop signal of the plxdssm component. That signal can be used to terminate a demand-mode DMA local bus cycle (although it doesn't necessarily pause a demand-mode transfer), and together with request and burst, offers the most flexibility in controlling a demand-mode DMA transfer.

For each DMA channel that is to be used in demand-mode, there must be one instance of plxddsm2. Each instance of plxddsm2 is associated with one bit of the LDACK# and LDREQ# busses. Regardless of how many instances of plxddsm2 are required, exactly one instance of plxdssm is also required in order to complete the local bus interface.

The following figure illustrates a plxddsm2 instance connected to the one and only plxdssm instance, along with connections to the local bus and backend.

There are a couple of things to note about the above example:

  1. The generation of qlads causes the plxddsm2 instance to ignore local bus cycles for which the FPGA is not the target, or for which are not demand-mode DMA cycles. This generally requires only the simplest of address decoders, and an expression such as
    dd_qlads(0) <= not lads_l and not ldack_l(0) and not fholda and not la(23)
    
    often suffices. The above example uses bit 0 of LDACK# to qualify LADS#, implying that DMA channel 0 is being used. If DMA channel 1 were being used, the following expression could be used instead:
    dd_qlads(1) <= not lads_l and not ldack_l(1) and not fholda and not la(23)
    
    In other words, each plxddsm2 instance requires its own qlads signal, which should not be same as the qlads signal for the plxdssm instance.
  2. The control logic for generating the ready should be that of the plxdssm instance. The ready signal should be the same one that is input to the plxdssm instance.
  3. The logic for generating request depends on whether a given demand-mode DMA channel is being used to (a) read or (b) write the FPGA:
  4. To add an additional demand-mode DMA channel, everything within the shaded area of the above figure should be replicated, and a different LDACK# and LDREQ# pair chosen.

 


 Top of page