Patent Description:
As ADAS and AV systems progress towards fully autonomous operation, it would be beneficial to protect data generated by these systems.

<CIT> relates to a method and system to efficiently detect/correct memory errors. A command and an address associated with a data transaction may be received. Parity information associated with the command/address may be received. In response to detecting a parity error, a data array of a memory device may be locked. An indicator indicating the parity error may be sent. A first portion of a memory page to store data may be reserved. A second portion of the memory page to store error correction codes associated with the data may be reserved. The second portion's size may equal or exceed the error correction code capacity needed for the maximum possible data stored in the first portion. A cache line of data may be stored in the first portion. An error correction code associated with the cache line of data may be stored in the second portion.

The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar parts. While several illustrative embodiments are described herein, modifications, adaptations and other implementations are possible. For example, substitutions, additions, or modifications may be made to the components illustrated in the drawings, and the illustrative methods described herein may be modified by substituting, reordering, removing, or adding steps to the disclosed methods. Accordingly, the following detailed description may be not limited to the disclosed embodiments and examples.

Disclosed embodiments provide systems and methods that can be used as part of or in combination with autonomous navigation/driving and/or driver assist technology features. Driver assist technology refers to any suitable technology to assist drivers in the navigation and/or control of their vehicles, such as FCW, LDW and TSR, as opposed to fully autonomous driving.

One embodiment of the invention provides a method for error correction, the method includes opening a selected row of a memory bank out of multiple memory banks of a dynamic memory module; receiving selected data sub-blocks, while the selected row is open, by the dynamic memory module, wherein the selected data sub-blocks are received over a communication link and are targeted to be written to the selected row; calculating, while the selected row is open and by an error correction unit, selected error correction code sub-blocks that are related to the selected data sub-blocks; caching the selected error correction code sub-blocks in a cache memory that differs from the dynamic memory module; writing, to the selected row, the selected error correction code sub-blocks while the selected row is open; wherein the writing includes sending the selected error correction code sub-blocks to the dynamic memory module over the communication link; and closing the selected row. The writing of the selected error correction code sub-blocks to the dynamic memory module is triggered by a need to clean a state of the dynamic memory controller before entering low power modes.

Another embodiment of the invention provides a system having error correction capabilities, the system includes a dynamic memory controller, a dynamic memory module that is coupled to a communication link; a cache memory, and an error correction code unit; wherein the dynamic memory controller is arranged to (a) open a selected row of a memory bank out of multiple memory banks of a dynamic memory module; (b) receive, while the selected row is open, selected data sub-blocks that are targeted to be written to the selected row; wherein the dynamic memory module is configured to receive the selected data sub-blocks from the dynamic memory controller and over a communication link; wherein the error correction unit is arranged to calculate, while the selected row is open, selected error correction code sub-blocks that are related to the selected data sub-blocks; wherein the cache memory differs from the dynamic memory module and is arranged to cache the selected error correction code sub-blocks; wherein the dynamic memory controller is also arranged to (a) send the selected error correction code sub-blocks to the dynamic memory module over the communication link; (b) write, to the selected row and over the communication link, the selected error correction code sub-blocks while the selected row is open; and (c) close the selected row. The writing of the selected error correction code sub-blocks to the dynamic memory module is triggered by a need to clean a state of the dynamic memory controller before entering low power modes.

A further embodiment of the invention provides a computer program product that stores instructions that once executed by a computerized system may cause the computerized system to execute the steps of: opening a selected row of a memory bank out of multiple memory banks of a dynamic memory module; receiving selected data sub-blocks, while the selected row is open, by the dynamic memory module; wherein the selected data sub-blocks are received over a communication link and are targeted to be written to the selected row; calculating, while the selected row is open and by an error correction unit, selected error correction code sub-blocks that are related to the selected data sub-blocks; caching the selected error correction code sub-blocks in a cache memory that differs from the dynamic memory module; writing, to the selected row, the selected error correction code sub-blocks while the selected row is open; wherein the writing includes sending the selected error correction code sub-blocks to the dynamic memory module over the communication link; and closing the selected row. The writing of the selected error correction code sub-blocks to the dynamic memory module is triggered by a need to clean a state of the dynamic memory controller before entering low power modes.

The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate various disclosed embodiments. In the drawings:.

Before discussing in detail examples of features of the error correction coding and memory management of a dynamic memory module of a system that may provide a variety of features related to autonomous driving, semi-autonomous driving and/or driver assist technology.

The system may be arranged to process images of an environment ahead of a vehicle navigating a road for training a neural networks or deep learning algorithms to estimate a future path of a vehicle based on images or feature of the processing of images of an environment ahead of a vehicle navigating a road using a trained neural network to estimate a future path of the vehicle.

There may be provided various possible implementations and configurations of a vehicle mountable system that can be used for carrying out and implementing the methods according to examples of the presently disclosed subject matter. In some embodiments, various examples of the system can be mounted in a vehicle and can be operated while the vehicle is in motion. In some embodiments, the system can implement the methods according to examples of the presently disclosed subject matter.

However, it would be appreciated that embodiments of the present disclosure are not limited to scenarios where a suspected upright object indication is caused by a high-grade road. The suspected upright object indication can be associated with various other circumstances and can result from other types of image data and also from data that is not image based or is not exclusively image based, as well.

<FIG>, to which reference is now made, is a block diagram representation of a system consistent with the disclosed embodiments. System <NUM> can include various components depending on the requirements of a particular implementation. In some examples, system <NUM> can include a processing unit <NUM>, an image acquisition unit <NUM> and one or more memory units <NUM>, <NUM>. Processing unit <NUM> can include one or more processing devices. In some embodiments, processing unit <NUM> can include an application processor <NUM>, an image processor <NUM>, or any other suitable processing device. Similarly, image acquisition unit <NUM> can include any number of image acquisition devices and components depending on the requirements of a particular application. In some embodiments, image acquisition unit <NUM> can include one or more image capture devices (e.g., cameras), such as image capture device <NUM>, image capture device <NUM>, and image capture device <NUM>. In some embodiments, system <NUM> can also include a data interface <NUM> communicatively connecting processing unit <NUM> to image acquisition device <NUM>. For example, data interface <NUM> can include any wired and/or wireless link or links for transmitting image data acquired by image acquisition device <NUM> to processing unit <NUM>.

Both application processor <NUM> and image processor <NUM> can include various types of processing devices. For example, either or both of application processor <NUM> and image processor <NUM> can include one or more microprocessors, preprocessors (such as image preprocessors), graphics processors, central processing units (CPUs), support circuits, digital signal processors, integrated circuits, memory, or any other types of devices suitable for running applications and for image processing and analysis. In some embodiments, application processor <NUM> and/or image processor <NUM> can include any type of single or multi-core processor, mobile device microcontroller, central processing unit, etc. Various processing devices can be used, including, for example, processors available from manufacturers such as Intel®, AMD®, etc. and can include various architectures (e.g., x86 processor, ARM®, etc.).

In some embodiments, application processor <NUM> and/or image processor <NUM> can include any of the EyeQ series of processor chips available from Mobileye®. These processor designs each include multiple processing units with local memory and instruction sets. Such processors may include video inputs for receiving image data from multiple image sensors and may also include video out capabilities. In one example, the EyeQ2® uses <NUM>-micron technology operating at <NUM>. The EyeQ2® architecture has two floating point, hyper-thread <NUM>-bit RISC CPUs (MIPS32® <NUM>® cores), five Vision Computing Engines (VCE), three Vector Microcode Processors (VMP®), Denali <NUM>-bit Mobile DDR Controller, <NUM>-bit internal Sonics Interconnect, dual <NUM>-bit Video input and <NUM>-bit Video output controllers, <NUM> channels DMA and several peripherals. The MIPS34K CPU manages the five VCEs, three VMP. and the DMA, the second MIPS34K CPU and the multi-channel DMA as well as the other peripherals. The five VCEs, three VMP® and the MIPS34K CPU can perform intensive vision computations required by multi-function bundle applications. In another example, the EyeQ3®, which is a third-generation processor and is six times more powerful that the EyeQ2®, may be used in the disclosed examples. In yet another example, the EyeQ4®, the fourth-generation processor, may be used in the disclosed examples.

While <FIG> depicts two separate processing devices included in processing unit <NUM>, more or fewer processing devices can be used. For example, in some examples, a single processing device may be used to accomplish the tasks of application processor <NUM> and image processor <NUM>. In other embodiments, these tasks can be performed by more than two processing devices.

Processing unit <NUM> can include various types of devices. For example, processing unit <NUM> may include various devices, such as a controller, an image preprocessor, a central processing unit (CPU), support circuits, digital signal processors, integrated circuits, memory, or any other types of devices for image processing and analysis. The image preprocessor can include a video processor for capturing, digitizing, and processing the imagery from the image sensors. The CPU can include any number of microcontrollers or microprocessors. The support circuits can be any number of circuits generally well known in the art, including cache, power supply, clock, and input-output circuits. The memory can store software that, when executed by the processor, controls the operation of the system. The memory can include databases and image processing software, including a trained system, such as a neural network, for example. The memory can include any number of random access memories, read only memories, flash memories, disk drives, optical storage, removable storage, and other types of storage. In one instance, the memory can be separate from the processing unit <NUM>. In another instance, the memory can be integrated into the processing unit <NUM>.

Each memory <NUM>, <NUM> can include software instructions that when executed by a processor (e.g., application processor <NUM> and/or image processor <NUM>), can control operation of various aspects of system <NUM>. These memory units can include various databases and image processing software. The memory units can include random access memory, read only memory, flash memory, disk drives, optical storage, tape storage, removable storage, and/or any other types of storage. In some examples, memory units <NUM>, <NUM> can be separate from the application processor <NUM> and/or image processor <NUM>. In other embodiments, these memory units can be integrated into application processor <NUM> and/or image processor <NUM>.

In some embodiments, the system can include a position sensor <NUM>. The position sensor <NUM> can include any type of device suitable for determining a location associated with at least one component of system <NUM>. In some embodiments, position sensor <NUM> can include a GPS receiver. Such receivers can determine a user position and velocity by processing signals broadcasted by global positioning system satellites. Position information from position sensor <NUM> can be made available to application processor <NUM> and/or image processor <NUM>.

In some embodiments, the system <NUM> can be operatively connectible to various systems, devices and units onboard a vehicle in which the system <NUM> can be mounted, and through any suitable interfaces (e.g., a communication bus) the system <NUM> can communicate with the vehicle's systems. Examples of vehicle systems with which the system <NUM> can cooperate include: a throttling system, a braking system, and a steering system.

In some embodiments, the system <NUM> can include a user interface <NUM>. User interface <NUM> can include any device suitable for providing information to or for receiving inputs from one or more users of system <NUM>, including, for example, a touchscreen, microphone, keyboard, pointer devices, track wheels, cameras, knobs, buttons, etc. Information can be provided by the system <NUM>, through the user interface <NUM>, to the user.

In some embodiments, the system <NUM> can include a map database <NUM>. The map database <NUM> can include any type of database for storing digital map data. In some examples, map database <NUM> can include data relating to a position, in a reference coordinate system, of various items, including roads, water features, geographic features, points of interest, etc. Map database <NUM> can store not only the locations of such items, but also descriptors relating to those items, including, for example, names associated with any of the stored features and other information about them. For example, locations and types of known obstacles can be included in the database, information about a topography of a road or a grade of certain points along a road, etc. In some embodiments, map database <NUM> can be physically located with other components of system <NUM>. Alternatively or additionally, map database <NUM> or a portion thereof can be located remotely with respect to other components of system <NUM> (e.g., processing unit <NUM>). In such embodiments, information from map database <NUM> can be downloaded over a wired or wireless data connection to a network (e.g., over a cellular network and/or the Internet, etc.).

Image capture devices <NUM>, <NUM>, and <NUM> can each include any type of device suitable for capturing at least one image from an environment. Moreover, any number of image capture devices can be used to acquire images for input to the image processor. Some examples of the presently disclosed subject matter can include or can be implemented with only a single-image capture device, while other examples can include or can be implemented with two, three, or even four or more image capture devices. Image capture devices <NUM>, <NUM>, and <NUM> will be further described with reference to <FIG>, below.

It would be appreciated that the system <NUM> can include or can be operatively associated with other types of sensors, including for example: an acoustic sensor, a RF sensor (e.g., radar transceiver), a LIDAR sensor. Such sensors can be used independently of or in cooperation with the image acquisition device <NUM>. For example, the data from the radar system (not shown) can be used for validating the processed information that is received from processing images acquired by the image acquisition device <NUM>, e.g., to filter certain false positives resulting from processing images acquired by the image acquisition device <NUM>, or it can be combined with or otherwise compliment the image data from the image acquisition device <NUM>, or some processed variation or derivative of the image data from the image acquisition device <NUM>.

System <NUM>, or various components thereof, can be incorporated into various different platforms. In some embodiments, system <NUM> may be included on a vehicle <NUM>, as shown in <FIG>. For example, vehicle <NUM> can be equipped with a processing unit <NUM> and any of the other components of system <NUM>, as described above relative to <FIG>. While in some embodiments vehicle <NUM> can be equipped with only a single-image capture device (e.g., camera), in other embodiments, such as those discussed in connection with <FIG>, multiple image capture devices can be used. For example, either of image capture devices <NUM> and <NUM> of vehicle <NUM>, as shown in <FIG>, can be part of an ADAS (Advanced Driver Assistance Systems) imaging set.

The image capture devices included on vehicle <NUM> as part of the image acquisition unit <NUM> can be positioned at any suitable location. In some embodiments, as shown in <FIG> and 3A-3C, image capture device <NUM> can be located in the vicinity of the rearview mirror. This position may provide a line of sight similar to that of the driver of vehicle <NUM>, which can aid in determining what is and is not visible to the driver.

Other locations for the image capture devices of image acquisition unit <NUM> can also be used. For example, image capture device <NUM> can be located on or in a bumper of vehicle <NUM>. Such a location can be especially suitable for image capture devices having a wide field of view. The line of sight of bumper-located image capture devices can be different from that of the driver. The image capture devices (e.g., image capture devices <NUM>, <NUM>, and <NUM>) can also be located in other locations. For example, the image capture devices may be located on or in one or both of the side mirrors of vehicle <NUM>, on the roof of vehicle <NUM>, on the hood of vehicle <NUM>, on the trunk of vehicle <NUM>, on the sides of vehicle <NUM>, mounted on, positioned behind, or positioned in front of any of the windows of vehicle <NUM>, and mounted in or near light figures on the front and/or back of vehicle <NUM>, etc. The image capture unit <NUM>, or an image capture device that is one of a plurality of image capture devices that are used in an image capture unit <NUM>, can have a field-of-view (FOV) that is different than the FOV of a driver of a vehicle, and not always see the same objects. In one example, the FOV of the image acquisition unit <NUM> can extend beyond the FOV of a typical driver and can thus image objects which are outside the FOV of the driver. In yet another example, the FOV of the image acquisition unit <NUM> is some portion of the FOV of the driver. In some embodiments, the FOV of the image acquisition unit <NUM> corresponding to a sector which covers an area of a road ahead of a vehicle and possibly also surroundings of the road.

In addition to image capture devices, vehicle <NUM> can be include various other components of system <NUM>. For example, processing unit <NUM> may be included on vehicle <NUM> either integrated with or separate from an engine control unit (ECU) of the vehicle. Vehicle <NUM> may also be equipped with a position sensor <NUM>, such as a GPS receiver and may also include a map database <NUM> and memory units <NUM> and <NUM>.

<FIG> is a diagrammatic side view representation of a vehicle imaging system according to examples of the presently disclosed subject matter. <FIG> is a diagrammatic top view illustration of the example shown in <FIG>. As illustrated in <FIG>, the disclosed examples can include a vehicle <NUM> including in its body a system <NUM> with a first image capture device <NUM> positioned in the vicinity of the rearview mirror and/or near the driver of vehicle <NUM>, a second image capture device <NUM> positioned on or in a bumper region (e.g., one of bumper regions <NUM>) of vehicle <NUM>, and a processing unit <NUM>.

As illustrated in <FIG>, image capture devices <NUM> and <NUM> may both be positioned in the vicinity of the rearview mirror and/or near the driver of vehicle <NUM>. Additionally, while two image capture devices <NUM> and <NUM> are shown in <FIG> and <FIG>, it should be understood that other embodiments may include more than two image capture devices. For example, in the embodiment shown in <FIG>, first, second, and third image capture devices <NUM>, <NUM>, and <NUM>, are included in the system <NUM> of vehicle <NUM>.

As shown in <FIG>, image capture devices <NUM>, <NUM>, and <NUM> may be positioned in the vicinity of the rearview mirror and/or near the driver seat of vehicle <NUM>. The disclosed examples are not limited to any particular number and configuration of the image capture devices, and the image capture devices may be positioned in any appropriate location within and/or on vehicle <NUM>.

It is also to be understood that disclosed embodiments are not limited to a particular type of vehicle <NUM> and may be applicable to all types of vehicles including automobiles, trucks, trailers, motorcycles, bicycles, self-balancing transport devices and other types of vehicles.

The first image capture device <NUM> can include any suitable type of image capture device. Image capture device <NUM> can include an optical axis. In one instance, the image capture device <NUM> can include an Aptina M9V024 WVGA sensor with a global shutter. In another example, a rolling shutter sensor can be used. Image acquisition unit <NUM>, and any image capture device which is implemented as part of the image acquisition unit <NUM>, can have any desired image resolution. For example, image capture device <NUM> can provide a resolution of 1280x960 pixels and can include a rolling shutter.

Image acquisition unit <NUM>, and any image capture device which is implemented as part of the image acquisition unit <NUM>, can include various optical elements. In some embodiments one or more lenses can be included, for example, to provide a desired focal length and field of view for the image acquisition unit <NUM>, and for any image capture device which is implemented as part of the image acquisition unit <NUM>. In some examples, an image capture device which is implemented as part of the image acquisition unit <NUM> can include or be associated with any optical elements, such as a <NUM> lens or a <NUM> lens, for example. In some examples, image capture device <NUM> can be arranged to capture images having a desired (and known) field-of-view (FOV).

The first image capture device <NUM> may have a scan rate associated with acquisition of each of the first series of image scan lines. The scan rate may refer to a rate at which an image sensor can acquire image data associated with each pixel included in a particular scan line.

<FIG> is a diagrammatic representation of vehicle control systems, according to examples of the presently disclosed subject matter. As indicated in <FIG>, vehicle <NUM> can include throttling system <NUM>, braking system <NUM>, and steering system <NUM>. System <NUM> can provide inputs (e.g., control signals) to one or more of throttling system <NUM>, braking system <NUM>, and steering system <NUM> over one or more data links (e.g., any wired and/or wireless link or links for transmitting data). For example, based on analysis of images acquired by image capture devices <NUM>, <NUM>, and/or <NUM>, system <NUM> can provide control signals to one or more of throttling system <NUM>, braking system <NUM>, and steering system <NUM> to navigate vehicle <NUM> (e.g., by causing an acceleration, a turn, a lane shift, etc.). Further, system <NUM> can receive inputs from one or more of throttling system <NUM>, braking system <NUM>, and steering system <NUM> indicating operating conditions of vehicle <NUM> (e.g., speed, whether vehicle <NUM> is braking and/or turning, etc.).

As shown in <FIG>, vehicle <NUM> may also include a user interface <NUM> for interacting with a driver or a passenger of vehicle <NUM>. For example, user interface <NUM> in a vehicle application may include a touch screen <NUM>, knobs <NUM>, buttons <NUM>, and a microphone <NUM>. A driver or passenger of vehicle <NUM> may also use handles (e.g., located on or near the steering column of vehicle <NUM> including, for example, turn signal handles), buttons (e.g., located on the steering wheel of vehicle <NUM>), and the like, to interact with system <NUM>. In some embodiments, microphone <NUM> may be positioned adjacent to a rearview mirror <NUM>. Similarly, in some embodiments, image capture device <NUM> may be located near rearview mirror <NUM>. In some embodiments, user interface <NUM> may also include one or more speakers <NUM> (e.g., speakers of a vehicle audio system). For example, system <NUM> may provide various notifications (e.g., alerts) via speakers <NUM>.

As will be appreciated by a person skilled in the art having the benefit of this disclosure, numerous variations and/or modifications may be made to the foregoing disclosed embodiments. For example, not all components are essential for the operation of system <NUM>. Further, any component may be located in any appropriate part of system <NUM> and the components may be rearranged into a variety of configurations while providing the functionality of the disclosed embodiments. Therefore, the foregoing configurations are examples and, regardless of the configurations discussed above, system <NUM> can provide a wide range of functionality to analyze the surroundings of vehicle <NUM> and, in response to this analysis, navigate and/or otherwise control and/or operate vehicle <NUM>. Navigation, control, and/or operation of vehicle <NUM> may include enabling and/or disabling (directly or via intermediary controllers, such as the controllers mentioned above) various features, components, devices, modes, systems, and/or subsystems associated with vehicle <NUM>. Navigation, control, and/or operation may alternately or additionally include interaction with a user, driver, passenger, passerby, and/or other vehicle or user, which may be located inside or outside vehicle <NUM>, for example by providing visual, audio, haptic, and/or other sensory alerts and/or indications.

As discussed below in further detail and consistent with various disclosed embodiments, system <NUM> may provide a variety of features related to autonomous driving, semi-autonomous driving and/or driver assist technology. For example, system <NUM> may analyze image data, position data (e.g., GPS location information), map data, speed data, and/or data from sensors included in vehicle <NUM>. System <NUM> may collect the data for analysis from, for example, image acquisition unit <NUM>, position sensor <NUM>, and other sensors. Further, system <NUM> may analyze the collected data to determine whether or not vehicle <NUM> should take a certain action, and then automatically take the determined action without human intervention. It would be appreciated that in some cases, the actions taken automatically by the vehicle are under human supervision, and the ability of the human to intervene adjust abort or override the machine action is enabled under certain circumstances or at all times. For example, when vehicle <NUM> navigates without human intervention, system <NUM> may automatically control the braking, acceleration, and/or steering of vehicle <NUM> (e.g., by sending control signals to one or more of throttling system <NUM>, braking system <NUM>, and steering system <NUM>). Further, system <NUM> may analyze the collected data and issue warnings, indications, recommendations, alerts, or instructions to a driver, passenger, user, or other person inside or outside of the vehicle (or to other vehicles) based on the analysis of the collected data. Additional details regarding the various embodiments that are provided by system <NUM> are provided below.

The system may apply error correction coding in a highly efficient manner in terms of throughput and low latency. The arrangement of data sub-blocks and error correction code sub-blocks at the same row, the writing of data sub-blocks and error correction sub-blocks to a row of a dynamic memory module while the row is open may increase the write throughput by a factor of two and the caching of the error correction blocks in a cache memory may also increase the reading throughput by a factor of two.

This increase in reading and writing throughput dramatically reduces the penalty associated with error correction - and enables to apply error correction coding (ECC) even to (but not necessarily to) all the regions in the dynamic memory module, for example (but not limited to) sensor images - and not only code.

Applying ECC on sensor images and especially lower resolution images such as radar sensor acquired images and LIDAR sensor acquired images increases the reliability of such images, reduces required level of redundancy and so allows using fewer number of sensors - thereby reducing the cost of the system, simplifying the system and reducing the size, and energy consumption of the system. Accordingly - applying the ECC on LIDAR images may replace the need of using redundant LIDAR sensors to compensate for LIDAR image errors.

The low penalty associated with applying the ECC may ease the applying of ECC on the images acquired by the image acquisition unit <NUM> and also on any processed image (or temporary data) generated during any one out of autonomous driving operations, semi-autonomous driving operations and/or driver assist technology operations such as but not limited to automatic lane tracking, pedestrian detection, autonomous breaking, and the like.

Applying ECC on code and on data of various types increases the reliability of the outputs of the system and allows to operate the vehicle in a more optimal manner- even with lower safeguards.

Applying ECC on code and on data of various types reduces the chances of failures, reduces the system Failure In Time (FIT) parameter - and provides a more robust system.

<FIG> and <FIG> illustrates an example of a dynamic memory module <NUM> and a dynamic memory controller <NUM>. The dynamic memory module may be a DRAM and/or a DDR (double data rate) memory module. In some of the examples below it is assumed that the dynamic memory module is a DDR memory module.

An in-line ECC configuration may be used - in which the error correction sub-blocks (also referred to as ECC sub-blocks) and data sub-blocks are sent (from the dynamic memory module and to the dynamic memory module) over the same communication link - in a serial manner. Thus, ECC bits and data bits are sent over the same pins (or other interface) of the dynamic memory module - in a serial manner. The in-line ECC configuration may require only a single dynamic memory module for storing the ECC and data and is LPDDR4 compliant.

The dynamic memory module may be, for example, any one of memory modules <NUM> and <NUM> of <FIG>.

The dynamic memory module <NUM> may receive (over communication link <NUM>) data sub-blocks that originated from data generators such as application processor <NUM> and image processor <NUM> of <FIG> (or from any other data generator).

The dynamic memory module <NUM> may output (over communication link <NUM>) data sub-blocks to data consumers such as application processor <NUM> and image processor <NUM> of <FIG> (or to any other data consumer).

In <FIG> the dynamic memory controller is coupled to an ECC unit <NUM>. In <FIG> the ECC unit <NUM> is included in the dynamic memory controller <NUM>.

The dynamic memory module <NUM> may include one or more memory banks.

<FIG> illustrates a single memory bank <NUM> while <FIG> illustrates eight memory banks <NUM>-<NUM>. The dynamic memory module <NUM> may include any number of memory banks. For DDR use performance reasons, it's beneficial to store the ECC blocks together with the corresponding data blocks in the same DDR row.

During write operations the ECC unit <NUM> may apply ECC operations on incoming data sub-blocks to provide ECC sub-blocks.

Every data write to DDR requires the corresponding ECC generation and subsequent ECC write to ECC cache/buffer (<NUM>).

Any ECC that is buffered in DDR controller for write data, should be written to memory at some point.

There may be various possible triggers for writing the ECC to DDR. According to the invention, the trigger for writing the ECC to DDR is need to clean the DDR controller state before entering into low power modes.

A further trigger may be a need to buffer other data commands and LRU ECC may need to be replaced.

During read operations the ECC unit <NUM> may apply ECC check on data sub-blocks read from the dynamic memory module <NUM> in order to detect errors and correct errors. Every data read from DDR requires a subsequent corresponding ECC read, unless this particular ECC is already present in ECC cache/buffer.

The ECC unit <NUM> may perform ECC operations (generation or check) on all the data stored in the dynamic memory module <NUM> or on predefined regions of the dynamic memory module <NUM> that require ECC protection.

<FIG> illustrates a row <NUM>(<NUM>) of memory bank <NUM> of dynamic memory module <NUM> that stores seven data blocks <NUM>-<NUM> and an ECC block <NUM>. Memory bank <NUM> may have any number of rows - and rows <NUM>(<NUM>), <NUM>(<NUM>) and <NUM>(<NUM>) are only examples of some of the rows of memory bank <NUM>.

Each data block may include multiple data sub-blocks - for example data sub-blocks <NUM>(<NUM>)-<NUM>(<NUM>) of data block <NUM>. The data sub-blocks may be transferred during one or more data bursts.

ECC block <NUM> may include ECC sub-blocks - for example ECC sub-blocks <NUM>(<NUM>,<NUM>)-<NUM>(<NUM>,<NUM>) that are related to data sub-blocks <NUM>(<NUM>)-<NUM>(<NUM>).

The data blocks and the ECC block may be <NUM>-byte long and each sub-block may be <NUM>-byte long. Other sizes may be supported. The relationship between the size and/or number of the ECC block and the size and/or number of data blocks per row may differ from those illustrated in <FIG>.

An ECC sub-block may be calculated by the ECC unit <NUM> whenever a data sub-block is received or in a later point of time.

An ECC sub-block may be cached in an ECC cache <NUM> before the ECC sub-block is written to the dynamic memory module <NUM>. The ECC sub-block may be written to the dynamic memory module <NUM> at any time after the ECC sub-block is calculated. ECC cache <NUM> is just an example or a memory unit that may store the ECC sub-block. For example- a buffer may be used for storing the ECC sub-block.

Dynamic memory module <NUM> may include one or more memory banks. In each memory bank, up to a single row may be opened (activated) at a time.

A write operation to a certain row (that is currently closed) of the dynamic memory module <NUM> requires to close another row (that is currently open), activate the certain row and write one or more data sub-blocks to the certain row.

It has been found that it is highly beneficial to write to the certain row all ECC sub-blocks that (a) are related to data sub-blocks stored in that certain row and (b) were generated while the certain row is still open - before the certain row is closed.

Writing the ECC sub-blocks related to the certain row- after the certain row is closed - required to close a currently active row, activate (again) the certain row and write one or more ECC sub-blocks to the certain row. This process is time and DDR bandwidth consuming.

For example - Writing the ECC sub-blocks related to the certain row- after the certain row is closed - Every <NUM> bursts of data, the current row should be PRECHARGED and another ECC row activated and written. The latencies are: <MAT>.

Wherein tRP - Row precharge time; tRCD - RAS-to-CAS delay (RAS - row activation strobe, CAS - column activation strobe) and WL - write latency. And wherein it is assumed that tRP=tRCD=RL=WL = <NUM> cycles and burst length = <NUM> (<NUM> bytes, <NUM> cycles).

For example - Writing the ECC sub-blocks related to the certain row- before the certain row is closed - Every <NUM> bursts of data, the additional <NUM> burst of ECC should be written to same row. ECC does not require additional PRECHARGE/ACTIVATE command and can be written back to back with the data. The latencies are: tRP+tRCD+WL+<NUM>*(<NUM>data+<NUM>ECC)*<NUM> = 312cycles. Yet for another example of parameters that may be used Activation: tRP=tRCD=RL=WL = <NUM> cycles and burst length = <NUM> (<NUM> bytes, <NUM> cycles).

The dynamic memory controller <NUM> controls the various operations related to the dynamic memory module <NUM> (including the write operation, the pre-charging operation and the activating operation) and may determine when to perform the writing of the one or more ECC sub-blocks before the certain row is closed.

The dynamic memory controller <NUM> may receive access requests (denoted <NUM> in <FIG>) and convert these access requests to dynamic memory controller commands such as pre-charging row, activate row and read or write row (see box <NUM> in <FIG>).

<FIG> illustrates two triplets of dynamic memory controller commands:.

It should be noted that after activating the row multiple read and/or write commands may be executed.

It is beneficial to write to row <NUM>(<NUM>) all the ECC sub-blocks calculated during the execution of the third command (read or write row <NUM>(<NUM>)) before the execution of the fourth command (pre-charge row <NUM>(<NUM>)).

Thus - the dynamic memory controller commands may include:.

Figure <NUM> illustrates two timing diagrams <NUM> and <NUM>.

Timing diagram <NUM> illustrates the following sequence of events (T denotes a point in time):.

It is noted that event <NUM> may follow event <NUM>, that events <NUM> and <NUM> may occur simultaneously.

It should be noted that the writing of the data sub-blocks to the dynamic memory module may be executed upon a reception of a single data sub-block, that multiple data sub-blocks may be aggregated before they are written to the dynamic memory module, and the like.

Timing diagram <NUM> illustrates two repetitions of events <NUM>, <NUM> and <NUM> before the occurrence of event <NUM>.

<FIG> is a flow chart that illustrates method <NUM>.

Method <NUM> may start by step <NUM> of activating a certain row of a dynamic memory module.

Step <NUM> may be triggered by a write command that is received by a dynamic memory controller.

Step <NUM> may be followed by step <NUM> of receiving (by a dynamic memory controller) a data sub-block to be written to the certain row of the dynamic memory module.

A data sub-block to be written to (or targeted to) the certain row may be associated (by the dynamic memory controller or by another entity) with address information that indicates that the data-sub-block should be written to the certain row.

Step <NUM> may be followed by steps <NUM> and <NUM>.

Step <NUM> may include calculating an ECC sub-block related to (protecting) the data sub-block.

Step <NUM> may include writing the data sub-block to the dynamic memory module over the communication link.

Steps <NUM> and <NUM> may be followed by step <NUM> of writing one or more ECC sub-blocks to the certain row before the certain row is pre-charged.

The writing of the data unit to the dynamic memory module includes sending the data unit over the communication link.

Method <NUM> utilizes the in-line ECC configuration - the same communication line is used for conveying data bits and ECC bits - at different points of time.

Steps <NUM>-<NUM> may be repeated for multiple rows - especially one row after the other. Each iteration a row is selected and after steps <NUM>-<NUM> are executed the method may be executed in relation to a new selected row. The certain row of <FIG> is an example of a selected row.

Method <NUM> may, for example, be executed as a part of a ADAS operation and/or an autonomous vehicle operation. Method <NUM> may be used for any other purpose.

<FIG> illustrates a method <NUM> that further includes step <NUM> of storing the ECC sub-block related to the data sub-block in a cache memory (for example ECC cache <NUM> of <FIG>). Step <NUM> follows step <NUM> and precedes step <NUM>.

Multiple iterations of steps <NUM>, <NUM> and <NUM> may occur between the execution of steps <NUM> and <NUM>.

Any reference to a system should be applied, mutatis mutandis to a method that is executed by a system and/or to a computer program product that stores instructions that once executed by the system will cause the system to execute the method. The computer program product is non-transitory and may be, for example, an integrated circuit, a magnetic memory, an optical memory, a disk, and the like.

Any reference to method should be applied, mutatis mutandis to a system that is configured to execute the method and/or to a computer program product that stores instructions that once executed by the system will cause the system to execute the method.

Any reference to a computer program product should be applied, mutatis mutandis to a method that is executed by a system and/or a system that is configured to execute the instructions stored in the computer program product.

The term "and/or" is additionally or alternatively.

In the foregoing specification, the invention has been described with reference to specific examples of embodiments of the invention. It will, however, be evident that various modifications and changes may be made therein without departing from the broader scope of the invention as set forth in the appended claims.

Moreover, the terms "front," "back," "top," "bottom," "over," "under" and the like in the description and in the claims, if any, are used for descriptive purposes and not necessarily for describing permanent relative positions. It is understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the invention described herein are, for example, capable of operation in other orientations than those illustrated or otherwise described herein.

Any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality may be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected," or "operably coupled," to each other to achieve the desired functionality.

Furthermore, those skilled in the art will recognize that boundaries between the above described operations merely illustrative. The multiple operations may be combined into a single operation, a single operation may be distributed in additional operations and operations may be executed at least partially overlapping in time. Moreover, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be altered in various other embodiments.

However, other modifications, variations and alternatives are also possible. The specifications and drawings are, accordingly, to be regarded in an illustrative rather than in a restrictive sense.

The phrase "may be X" indicates that condition X may be fulfilled. This phrase also suggests that condition X may not be fulfilled. For example - any reference to a system as including a certain component should also cover the scenario in which the system does not include the certain component.

The terms "including", "comprising", "having", "consisting" and "consisting essentially of" are used in an interchangeable manner. For example- any method may include at least the steps included in the figures and/or in the specification, only the steps included in the figures and/or the specification. The same applies to the system and the mobile computer.

Also for example, in one embodiment, the illustrated examples may be implemented as circuitry located on a single integrated circuit or within a same device. Alternatively, the examples may be implemented as any number of separate integrated circuits or separate devices interconnected with each other in a suitable manner.

Also for example, the examples, or portions thereof, may implemented as soft or code representations of physical circuitry or of logical representations convertible into physical circuitry, such as in a hardware description language of any appropriate type.

Also, the invention is not limited to physical devices or units implemented in non-programmable hardware but can also be applied in programmable devices or units able to perform the desired device functions by operating in accordance with suitable program code, such as mainframes, minicomputers, servers, workstations, personal computers, notepads, personal digital assistants, electronic games, automotive and other embedded systems, cell phones and various other wireless devices, commonly denoted in this application as 'computer systems'.

The word 'comprising' does not exclude the presence of other elements or steps then those listed in a claim. Furthermore, the terms "a" or "an," as used herein, are defined as one as or more than one. Also, the use of introductory phrases such as "at least one " and "one or more " in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles "a " or "an " limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases "one or more " or "at least one " and indefinite articles such as "a " or "an. Unless stated otherwise, terms such as "first" and "second" are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements the mere fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage.

While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents will now occur to those of ordinary skill in the art.

Any combination of any component of any component and/or unit of system that is illustrated in any of the figures and/or specification and/or the claims may be provided.

Any combination of any system illustrated in any of the figures and/or specification and/or the claims may be provided.

Any combination of steps, operations and/or methods illustrated in any of the figures and/or specification and/or the claims may be provided.

Any combination of operations illustrated in any of the figures and/or specification and/or the claims may be provided.

Any combination of methods illustrated in any of the figures and/or specification and/or the claims may be provided.

Claim 1:
A method for error correction, the method comprises the steps of:
opening a selected row (<NUM>(<NUM>)) of a memory bank (<NUM>) out of multiple memory banks (<NUM>, <NUM>) of a dynamic memory module (<NUM>);
receiving selected data sub-blocks (<NUM>(<NUM>), ..., (<NUM>(<NUM>)), while the selected row (<NUM>(<NUM>)) is open, by the dynamic memory module (<NUM>), wherein the selected data sub-blocks (<NUM>(<NUM>), ..., (<NUM>(<NUM>)) are received over a communication link and are targeted to be written to the selected row (<NUM>(<NUM>));
calculating, while the selected row (<NUM>(<NUM>)) is open and by an error correction unit (<NUM>), selected error correction code sub-blocks (<NUM>(<NUM>,<NUM>), ..., <NUM>(<NUM>,<NUM>)) that are related to the selected data sub-blocks (<NUM>(<NUM>), ..., (<NUM>(<NUM>));
caching the selected error correction code sub-blocks (<NUM>(<NUM>,<NUM>), ..., <NUM>(<NUM>,<NUM>)) in a cache memory (<NUM>) that differs from the dynamic memory module (<NUM>);
closing the selected row (<NUM>(<NUM>)); and
writing, by a dynamic memory controller and to the selected row (<NUM>(<NUM>)), the selected error correction code sub-blocks (<NUM>(<NUM>,<NUM>), ..., <NUM>(<NUM>,<NUM>)) while the selected row (<NUM>(<NUM>)) is open, wherein the writing comprises sending the selected error correction code sub-blocks (<NUM>(<NUM>,<NUM>), ..., <NUM>(<NUM>,<NUM>)) to the dynamic memory module (<NUM>) over the communication link;
characterized in that
the writing of the selected error correction code sub-blocks to the dynamic memory module (<NUM>) is triggered by a need to clean a state of the dynamic memory controller (<NUM>) before entering low power modes.