09.03.2013 Views

Processor Local Bus Functional Model Toolkit User's Manual

Processor Local Bus Functional Model Toolkit User's Manual

Processor Local Bus Functional Model Toolkit User's Manual

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

This parameter specifies the seed to be used for the auto data feature of the model. The slave<br />

model forms a seed using this root_seed and the byte address. The user may change the initial<br />

seed to change the random number sequences which are generated, which in turn will produce<br />

varying slave data.<br />

6.4.2 Mem_Init () Command<br />

The mem_init command initializes slave memory at simulation time 0.<br />

• addr = [4 byte]<br />

This parameter specifies the 32-bit address.<br />

• data = [4 byte]<br />

This parameter specifies the slave memory data to initialize in the corresponding PLB device.<br />

6.4.3 Read_Response (), Write_Response () Commands<br />

These commands specify attributes for a slave cycle read or write response when an address decode<br />

is true. Read_response commands are used to initialize the PLB slave response.<br />

• * aack_delay = [integer] default=0<br />

This parameter specifies the number of clocks to wait before asserting Sl_addrAck from the time<br />

PLB_PAValid or PLB_SAValid is active. For example, an aack_delay value of 0 will assert<br />

Sl_addrAck together with PLB_PAValid and an aack_delay of 1 will assert Sl_addrAck one clock<br />

after PLB_PAValid is recognized.<br />

• * rearb_delay = [integer] default=0<br />

This parameter specifies the number of clocks to wait before asserting the Sl_rearbitrate signal<br />

from the clock that PLB_PAValid was previously asserted. No Sl_addrAck is asserted if the<br />

rearb_delay parameter is used. Note that rearb_delay is not a valid configuration.<br />

• * dack_delay = [integer] default=0<br />

This parameter specifies the number of clocks to wait before asserting the first data acknowledge<br />

control signal for a read_response or write_response. This parameter is relative to the earliest legal<br />

assertion of Sl_rdDAck and Sl_wrDAck. For example, a DAck_delay value of 0 for a<br />

read_response causes the Sl_rdDAck signal to be asserted 2 clocks after Sl_addrAck is asserted,<br />

which is the earliest legal PLB slave data response time for the first Sl_rdDAck. A DAck_delay<br />

value of 0 for a write_response causes the Sl_wrDAck signal to be asserted together with the<br />

Sl_addrAck assertion, which is the earliest legal PLB slave data response time for the first<br />

Sl_wrDAck.<br />

For line and burst transfers, the dack_delay parameter can be used to specify delays between<br />

dacks for a multiple data beat transfer. This is accomplished with the following syntax:<br />

read_response(dack_delay=2*) or configure(dack_delay=2*)<br />

These bfl statements will produce a delay of 2 between dacks for a line or burst transfer.<br />

Another available option is to specify different delays between dacks for a multiple data beat<br />

transfer. This is accomplished with the following syntax:<br />

read_response(dack_delay=2-3-4-5)<br />

46 <strong>Processor</strong> <strong>Local</strong> <strong>Bus</strong> <strong>Functional</strong> <strong>Model</strong> <strong>Toolkit</strong> Version 4.9.2

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!