SDF Domain

Synchronous dataflow (SDF) is a statically scheduled dataflow domain in MLDesigner.

”Statically scheduled” means that the firing order of the primitives is determined once, during the start-up phase. The firing order will be strictly periodic. The SDF domain in MLDesigner is one of the most mature and common, with a large library of primitives and demo programs. It is a simulation domain, but the model of computation is the same as that used in most of the code generation domains. A number of different schedulers, including parallelizing schedulers, have been developed for this model.

It is assumed that you are familiar with the SDF model of computation. We also assume you are familiar with writing primitives for the SDF domain (see Designing Primitives) Since most of the examples given there are from the SDF domain, there is only a little more information to add here.

Setting SDF Porthole Parameters

All primitives in the SDF domain must follow the basic SDF principle. The number of particles consumed or produced on any porthole does not change within the simulation runs. These numbers are given for each porthole as part of the primitive definition. Most primitives consume just one particle on each input and produce just one particle on each output. In these cases, no special action is required, since the porthole SDF parameters will be set to one by default. However, if the numbers differ from one, the primitive definition must reflect this. For example, the FFTCx primitive has a size parameter that specifies how many input samples are given. The value of that parameter specifies the number of samples required at the input in order for the primitive to fire. The following line in the setup method of the primitive is used to make this information available to the scheduler.

input.setSDFParams (int(size), int(size)-1);

The name of the input porthole is input. The first argument to setSDFParams specifies how many samples are consumed by the primitive when it fires. It is the same as the number of samples required in order to enable the primitive. The second argument to setSDFParams specifies how many past samples (before the most recent one) will be accessed by the primitive when it fires.

If the number of particles produced or consumed is independent from any parameters, then it may be declared right along with the declaration of the input, in the .pl file. For example,

input
{
  name      { signalIn }
  type      { complex }
  numTokens { 2 }
  desc      { Complex input that consumes 2 input particles. }
}