executable specification for system design -凯发k8网页登录

model-based design

model-based design uses a system-level model at the center of the development process. before partitioning the system-level model among various design teams, the initial system model, developed by the system engineer, is validated against requirements and standards. with a validated error-free executable specification, design and implementation go smoothly. as the design progresses, verification can include co-simulation and testing with hardware-in-the-loop.

figure 2: model-based design -- a system-level model is at the center of the development process

rather than talking about all the elements in the development flow, this example focuses on how model-based design aids your engineering teams. the idea is to enable the system engineer to initially create an executable specification in the form of a simulink model that can be distributed to design teams. a team, such as the rf team, will devise a subsystem, extract a verification model and import it into the rf toolbox. the rf team then returns the solution to the system engineer, who reevaluates the overall performance of the system with the impairments from the rf subsystem. the design teams can go back and forth, iterating to find an optimal solution as the design proceeds. perhaps the rf section can use a more efficient or less costly device if the signal processing algorithms are altered. or, perhaps a small increase in fixed-point wordlength can free up some of the implementation loss budgeted, and enable a lower cost rf component to be used. the opportunities for cross-domain optimization are enhanced by this model-based design methodology.

baseline model: communications toolbox™ with no rf modeling

open('rfb_receiver_0.slx')

the model rfb_receiver_0.slx shows the kind of communication system toolbox model that inspired the creation of the rf blockset equivalent baseband library. note that this is a simple model for illustrative purposes. communications toolbox includes more complex models of wcdma, 802.11, dvb-s2, etc. however, the concepts presented can be applied to more complex models as well.

the simple wireless communication system consists of a message source, qam modulator, root raised cosine filter and an awgn channel. the model is an executable specification, and is used to validate the specification against requirements and acceptance criteria, "at a ber of 1e-3, the eb/no must be no greater than 1db above the theoretical bound for 16qam."

to validate the spec, you can use a previously saved bertool session file rfb_receiver_0.ber. to find this file, type the following command at the matlab prompt

which rfb_receiver_0.ber

open the bertool using the matlab command bertool. from the file==>open session... dialog box, navigate to the saved session rfb_receiver_0.ber. now click on the monte carlo tab, and then click on the run button. a figure like the one below is generated:

figure 3: ber versus eb/no plot without rf impairments

the eb/no for a given ber value is a little higher than the theoretical bound because of implementation losses. (in the present case, the main loss is due to the finite length of the root raised cosine filters.) but the degradation is within acceptance criteria.

adding rf specifications to the baseline model

open('rfb_receiver_1.slx')

let's elaborate the baseline model and see how it changes with additional refinement using rf blockset components. the first step is to replace the awgn block with a path loss block (shown in the preceding figure in cyan); this will lower the signal level close to the end of range value. the path loss (in db) required to bring the unit power (1w) down to a given eb/no (also in db) at the receiver input is:

path_loss = 10*log10(k*t_ref*b*m)   ebno   nf

where k is boltzmann's constant (~1.38e-23 j/k), t_ref is the ieee® standard noise reference temperature (290k), b is the noise bandwidth (~50 mhz in this case), and nf is the receiver noise figure in db.

next, the cyan-colored rf receiver subsystem and agc blocks are included. the agc block is a consequence of using realistic signal levels required by the demodulator.

the rf receiver subsystem examined

open('rfb_receiver_1.slx')
open_system('rfb_receiver_1/rf receiver')

now examine the rf receiver subsystem, which is a cascaded model of a super heterodyne receiver. the receiver uses blocks from the rf blockset equivalent baseband library. the simulink signal enters the rf domain through a gateway "input port" block. notice that the connectors after the gateway are different. the standard simulink arrows have been replaced with rf connection lines. this is to remind us that rf signals are bidirectional. the receiver is a cascade of components each represented as a 2-port network: a filter, a lna, a mixer, and an if strip. the output port, in this case, is not only the gateway back to simulink but also represents an ideal quadrature down conversion mixer. here is a framework or architecture for a receiver that is not yet designed. an executable specification for the rf engineer has been created. each stage of the rf subsystem includes a budget for the overall gain, noise and nonlinearities, as shown in the following figure.

figure 4: specification of amplifier block parameters

as an example of budgeting, consider the front end filter in the above figure. the s-parameters are specified at a single frequency point using the first element of the gainvec array that was entered into the base workspace using the postloadfcn* under the callbacks tab in the model properties panel. each element of the array refers to a stage, so the index 1 refers to the first stage. values for oip3, on the nonlinearity data tab, and for noise figure, on the noise data tab, are similarly specified.

figure 5: specification of complex baseband-equivalent simulation parameters

now open the input port block. this port contains parameters that apply to the overall rf subsystem. a narrowband modeling approach is used to capture the in-band effects that impact downstream signal processing blocks. the range of frequencies is specified through the center frequency parameter, the sample time parameter (which is 1/bandwidth), and the finite impulse response filter length parameter (which is the length of the impulse response filters that are used in modeling rf components). a longer length time-domain filter will give finer frequency-domain resolution within the specified bandwidth. to model mismatch at the input of the first component, source impedance is also specified here. notice the "add noise" checkbox. to include noise in the simulation, you must select this "add noise" checkbox.

figure 6: noise modeling with the rf blockset equivalent baseband library

the awgn block models overall noise as a signal-to-noise ratio. by contrast, blocks from the rf blockset equivalent baseband library model noise by adding the noise contribution of each block individually. for each block, the noise is modeled using an appropriate formulation determined by the set of noise parameters supplied for that block. once the noise for each block is calculated, the overall system noise model is developed. this overall model includes the position of each block in the cascade (i.e., includes the gain of the subsequent stages).

figure 7: ber versus eb/no plot with rf impairments

plots of ber versus eb/no comparing the theoretical, baseline and baseline with rf impairments models are given in figure 7. this is a simple illustration of the convenience afforded by the model-based design methodology. at this point in the process, an executable specification has been developed. this specification will be used by teams to design their subsystems. in the case of the rf subsystem, the abstract rf blocks will be replaced by discrete components. as each rf block is realized, its effect on the system's design criteria can be assessed.

bdclose('rfb_receiver_0');
bdclose('rfb_receiver_1');

see also

related topics