This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Factors that determine load time of images from flash

Prodigy 425 points

Replies: 3

Views: 1541

As most users might be aware, DLP LightCrafter4500 EVM and/or DLPC350 DLP controller supports pattern sequencing from either of the following input sources – 1) Images stored in flash memory 2) video port.

 

As documented in DLP LightCrafter4500 user’s guide section 4.1 on pattern sequences, when patterns are sourced from images stored in flash memory, the golden rule in order for the pattern sequence to work well is that sum_exposure must be greater than image_load_time

Where

Sum_exposure is the sum of exposure times of individual patterns contained in a given 24-bit image and

Image_load_time is the time it takes for the next 24-bit image to be loaded from flash to RAM.

 

DLP LightCrafter4500 GUI provides a control to measure the actual load time of each 24-bit image stored in flash under “Pattern Sequence” tab “Image Load timing” subtab (in version 3.0.0 of the tool). TI recommends that the actual load time of each image be measured using this tool in order to ensure that sum_exposure of each image is conforming to rule above.

 

Quite a number of Lightcrafter4500 users have expressed interest in knowing the various factors that influence the actual image load time. Some others are interested in being able to compute/predict the load time for an image without having to actually load it on the EVM and measuring it using the GUI tool. They like to use this information for getting a ball park estimate of the pattern rates that they can achieve for a given set of flash images.

 

This article discusses those factors that affect the compression of flash images and resultant load times.

 

Fastest pattern rate:-

A pattern sequence that uses a maximum of 2 24-bit images from flash can support the fastest pattern rate. Such a sequence can have use a total of <=48 bits. 48 1-bit patterns, or 6 8-bit patterns or any such combination of patterns that adds up to a total of <=48 bits. In this case, patterns are pre-loaded from flash to DLPC350 internal RAM upfront and once loaded individual patterns can be displayed at the fastest rate independent of the pattern load time (1-bit at 4225hz; 8-bit at 120hz; see datasheet for more).

 

When total number of bits > 48; and thus need to use more than 2 24-bit images from flash:-

 

1)      If patterns used are like the one shown below, where intensity/bit/color varies in the X-direction, but the pattern is identical in the Y direction, that is row0, row1….., row1140 are all identical –

  • In this case compression stores only row0 and decompression replicates row0 to form 1140 rows. (If you are using the GUI to create flash image, GUI automatically chooses this compression if all rows are identical).
  • Compressed image size is very small and does not vary much based on the pattern content.
  • For such images, load time is relatively constant and is about 100ms. The constant part of load time is very large compared to flash speed dependent variable part.
  • When flash access time was increased from 100ns to 200ns, the typical load time only increased from 100ms to 110ms for such images.
  • 100ms load time will translate to 30 8-bit patterns per second.

 

2)      If patterns used are not made up of identical rows as shown below –

  • In this case RLE compressed bitmaps are stored in flash. The size of compressed image will vary dependent on the pattern.
  • Load time (of each 24-bit pattern from flash) will be directly proportional to the compressed image size.
  • Load time will also be proportional to the flash access time.

If

B is the size of compressed image in bytes and

Tns is the flash read access time in nanoseconds,

 

A further note on Tns:- The read access time is different for different flash parts and is specified in their datasheet. Ideally, the DLPC350 firmware should be changed to program the flash read access to match with the flash part being used. However, until the latest release (v3.0) the DLPR350PROM or the firmware does not provide a command interface to configure the flash read wait states; instead it is fixed at 100ns. So one should assume Tns=100 for all practical purposes. But actual flash Tns will tell you the actual best case load time possible. Please approach TI with a request to optimize the flash access time if you think that will be huge for your project.

 

Then approximate load time of such an image from flash to RAM in milliseconds TLoadMs is

TLoadMs = 65 + ( (B/2) * (Tns + 13.334)) / (1000000 * 0.6) )

 

Here,

The constant factor 65ms is coming from the software overheads and set up times which is independent of flash access time,

B/2 because flash is read 16-bits (2 bytes) per access,

The constant 13.334 nanosecond needs to be added to the flash read access time due to a constant additional access overhead,

The factor of .6 is because 60% happens to be the slice of time that the flash DMA is getting access to the flash bus.

 

So the above equation will evaluate to a load time of approx. 360ms for a full uncompressed image of 912x1140x3 bytes (2.88 MB) on a 100ns flash, 310ms for a 2.4MB compressed image size, 150ms for a 1.18MB image and so on…

 

Please bear in mind that the actual load time for a given image (which can be measured using the GUI tool) may differ from the above estimate by 5-10%. The above equation may be used for a quick estimation of achievable pattern speeds, however it is recommended that the actual load time be measured using the GUI and the EVM before deciding the final pattern rates and exposure times.

 

The above equation is derived from a limited set of data points involving 10 different image sizes and 3 different flash access times. Below I have given the test images, their size, flash access times and corresponding measured and computed image load times..

Image

Size (bytes)

Measured Load Time (ms)

Access time (ns)

Computed load time

LCr4500_splash

483360

110

100

110.6509352

LCr_H

138752

80

100

78.10443264

LCr_V

46656

80

100

69.40642592

Emorro_35

1448288

215

100

201.7835602

color_ramp

1245696

150

100

182.6497587

Emorro_15

442032

110

100

106.7477122

ElMorro

3021184

360

100

350.3357229

ElMorro_25

1360432

200

100

193.4860002

ElMorro_half

1988640

260

100

252.8171048

ElMorro_75

2517056

310

100

302.7233539

LCr4500_splash

483360

100

70

98.5669352

LCr_H

138752

80

70

74.63563264

LCr_V

46656

80

70

68.24002592

Emorro_35

1448288

170

70

165.5763602

color_ramp

1245696

115

70

151.5073587

Emorro_15

442032

105

70

95.69691224

ElMorro

3021184

275

70

274.8061229

ElMorro_25

1360432

168

70

159.4752002

ElMorro_half

1988640

200

70

203.1011048

ElMorro_75

2517056

240

70

239.7969539

LCr4500_splash

483360

162

206

153.3477352

LCr_H

138752

80

206

90.36085931

LCr_V

46656

80

206

73.52770592

Emorro_35

1448288

374

206

329.7156668

color_ramp

1245696

295

206

292.6862387

Emorro_15

442032

166

206

145.7938722

ElMorro

3021184

700

206

617.2069762

ElMorro_25

1360432

360

206

313.6574936

ElMorro_half

1988640

488

206

428.4803048

ElMorro_75

2517056

600

206

525.0633006

3 Replies

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.