Patent Description:
ADAS and AV systems are required to process a significant amount of information (such as image pixels) in real time. This may involve accessing dynamic memory modules that store the information.

Dynamic memory modules may include multiple memory banks. The multiple memory banks may be arranged in groups of memory banks.

Some dynamic memory modules, such as fifth generation low power memory devices (LPDDR5), impose a significant time gap between consecutive accesses to the same group of memory banks.

There is a growing need to allow a high-throughput access to information stored in dynamic memory modules of ADAS and AV systems.

<CIT> describes a method of accessing a dynamic random access memory, wherein memory requests are converted to yield row address strobe commands and column address strobe commands. According to one aspect of this document, the execution of row address strobe commands and column address strobe commands related to memory banks on different chips is scheduled to be interleaved with each other. According to a further aspect of this document, the execution of column address strobe commands is scheduled to be interleaved between the execution of row address strobe commands for different rows in a memory bank.

<CIT> describes a method of accessing a dynamic random access memory, wherein the execution of commands related to different groups of subbanks is scheduled to be interleaved with each other.

<CIT> describes a memory subsystem refresh management that enables commands to access one or more identified banks across different bank groups, wherein a single command can cause the memory device to access banks in different bank groups.

<CIT> describes a memory controller, wherein a first memory access command and a portion of a second memory access command are stored in the same queue entry location of the memory queue if the first and second memory access commands refer to consecutive memory locations in the memory and wherein the first memory access command and the second memory access command are stored in different queue entry locations of the memory queue if the first and second memory access commands do not refer to consecutive memory locations in the memory.

<CIT> describes ways of increasing the size of a read pending queue in a memory controller. In an example, a read request for data in a memory having a physical address identification including row and column ID, a lookup is performed for a pending read transaction with a physical address ID having the same row ID as the incoming read request. In case of a hit, the column ID of the incoming request is appended to the physical address ID of the pending read transaction to form an appended read transaction.

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.

The invention provides a method according to claim <NUM> and a corresponding device and computer program product. Specific embodiments are set out in the dependent claims.

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.

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. 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>. 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. 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.).

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>. Alternatively, 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>.

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> 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>.

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.

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.

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. 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 arrangements, 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 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. 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 vehicle <NUM> can be equipped with only a single-image capture device (e.g., camera), in other examples, 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. 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. 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 <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 examples 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 examples 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. 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, 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 examples. 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 examples. 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.

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 system <NUM> are provided below.

Method <NUM> of <FIG> illustrates an embodiment of the present invention.

Method <NUM> is for accessing a dynamic memory module. The dynamic memory module may belong to an ADAS system or an AV system. The dynamic memory module may be LPDDR5 dynamic memory module - or any other dynamic memory module.

The method may be applied on sequential accesses - for example sequential reading or sequential writing of image data, filtering coefficients, instructions, and the like.

The dynamic memory controller includes multiple memory banks that are arranged in multiple groups of memory banks.

The dynamic memory module may include any number of memory banks per group, any number of overall memory banks, and there may be any number of memory banks per group.

The dynamic memory module may enforce a time gap between consecutive accesses to the same group of memory banks. This may be an inherent limitation of the dynamic memory module.

The time gap may be significant in the sense that its duration is of the order of a duration of a write or read operation of a burst of data atoms. The time gap may exceed the duration of the read or write operation of the burst of data atoms. The data atoms that are written (or read) during the burst may be regarded as a data sub-block.

Method <NUM> starts by step <NUM> of receiving, by a memory controller, a set of access requests for accessing the dynamic memory module.

The set of access requests may be received during one or more periods of time. There may be any number of access requests.

Non-limiting examples of access requests include a read request, a write request, and the like.

The receiving of the set of access requests may include storing the one or more access requests in any manner. For example - the set of access requests may be stored in one queue, in multiple queues, and the like. Different queues may be allocated to different memory banks and/or to different groups of memory banks.

Step <NUM> is followed by step <NUM> of converting the set of access requests to a set of commands.

The converting may be executed by a converter such as access request converter <NUM> of <FIG>.

The converting includes generating commands that fulfill the access requests. The converting includes adding commands that facilitate the execution of the access requests. The converting includes adding commands such as pre-charge, activate, and the like.

The commands of the set are classified to data-related commands (such as read and write) and to management commands (such as pre-charge and activate) that are not related to data.

A data related command may refer to a sub-block of data. For example, a read command may be a command to read a data sub-block.

The maintaining of the same status of different memory banks of different groups of memory banks and the lack of associated data allows a reduction of the memory space required for storing management commands.

Accordingly, a management command related to the second group of memory banks is represented by a flag or any other indicator that will be associated with a corresponding management command that is related to the first group of memory bank.

The representation of a management command by a flag or indicator may save memory space.

The set of commands includes multiple sub-sets of commands that are related to the multiple groups of memory banks.

The set of commands includes (a) a first sub-set of commands that are related to a first group of memory banks, and (b) a second sub-set of commands that are related to a second group of memory banks.

Step <NUM> is followed by step <NUM> of scheduling, by a scheduler of the memory controller, an execution of the first sub-set.

The scheduler may perform the scheduling without reading (or without taking into account) the second sub-set. This may save either time or allow the scheduler to operate at a lower frequency.

The scheduling may be regarded as a bottleneck of the access process as the scheduler may be required to scan a large number of commands per each scheduling cycle. By skipping some of the commands of the set, this may unblock the bottleneck.

Step <NUM> is followed by step <NUM> of scheduling an execution of the second sub-set to be interleaved with the execution of the first sub-set.

The interleaving contributes to the maintaining of the same status between different memory banks (or at least between corresponding memory banks that belong to different groups of memory banks).

Step <NUM> may be executed by an entity that differs from the scheduler. This entity may be a converter that may convert each command of the first sub-set to a pair of commands - a command of the sub-set of the commands and a corresponding command of the second sub-set of the commands. The first and second commands of the pair may share an operand.

The converter may be, for example, the scheduling decisions converter <NUM> of <FIG>.

It should be noted that steps <NUM> and <NUM> may be executed so that after the scheduling of one or more commands of the first sub-set, the method schedules the execution of one or more corresponding commands of the second sub-set.

Step <NUM> may be executed by adding, to each scheduler decision about a timing of execution of a first command of the first sub-set, another decision regarding a timing of an execution of a second command of the second sub-set, so that the execution of the second command immediately follows the execution of the first command.

The interleaving of the first and second command causes the first and second groups of memory banks (or at least a first memory bank of the first group and a second memory bank of the second group) to have substantially the same status. The same status allows the scheduler to schedule the execution of the commands of the first sub-set while ignoring the commands of the second sub-set.

Step <NUM> is followed by step <NUM> of executing the set of commands according to the schedule.

<FIG> is an example of a dynamic memory controller <NUM> and of a dynamic memory module <NUM>. The dynamic memory controller is configured to carry out the steps of method <NUM>.

For simplicity of explanation, it is assumed that there are four groups of memory banks and four memory banks per group. This is merely a non-limiting example of the number of groups of memory banks and of the number of memory banks per group of memory banks.

Dynamic memory module <NUM> includes sixteen memory banks Bank <NUM>(<NUM>) - Bank <NUM>(<NUM>) that are arranged in four groups of memory banks - Bank_Group_0 812A, Bank_Group_1 812B, Bank_Group_2 812C, and Bank_Group_3 812D.

First group of memory banks Bank _Group_0 812A includes first, fifth, ninth and thirteenth memory banks <NUM>(<NUM>), <NUM>(<NUM>), <NUM>(<NUM>) and <NUM>(<NUM>).

Second group of memory banks Bank_Group_1 812B includes second, sixth, tenth and fourteenth memory banks <NUM>(<NUM>), <NUM>(<NUM>), <NUM>(<NUM>) and <NUM>(<NUM>).

Third group of memory banks Bank _Group_2 812C includes third, seventh, eleventh and fifteenth memory banks <NUM>(<NUM>), <NUM>(<NUM>), <NUM>(<NUM>) and <NUM>(<NUM>).

Fourth group of memory banks Bank_Group_3 812D includes fourth, eighth, twelfth and sixteenth memory banks <NUM>(<NUM>), <NUM>(<NUM>), <NUM>(<NUM>) and <NUM>(<NUM>).

Any other mapping between memory banks and group of memory banks may be provided.

It is assumed that a sequential writing of data sub-blocks is converted to an interleaved writing of the data sub-blocks between the different groups of memory banks - so that the sequential writing is not penalized by the time gap introduced between successive writing to the same group.

For example- a first sequence of data sub-blocks may be written in an interleaved manner to the first and second groups of memory banks Bank _Group_0 812A and Bank_Group_1 812B.

In addition- and even parallel to the writing of the first sequence-a second sequence of data sub-blocks may be written in an interleaved manner to the third and fourth groups of memory banks Bank_Group_2 812C and Bank_Group_3 812D.

The dynamic memory controller <NUM> includes a memory module <NUM>, converter <NUM>, control unit <NUM>, scheduler <NUM>, scheduling decision converter <NUM>, and command execution unit <NUM>.

The dynamic memory controller <NUM> may include one or more integrated circuits. The memory module <NUM>, converter <NUM>, control unit <NUM>, scheduler <NUM>, scheduling decision converter <NUM>, and command execution unit <NUM> may be included in the one or more integrated circuits, may include one or more hardware accelerators, may be included in one or more processing circuits, wherein the one or more processing circuits may be constructed and arranged (for example be programmed, have certain structures, certain connectivity, and the like) to execute at least some of the steps of method <NUM>.

Memory module <NUM> may store access requests <NUM> and memory controller commands ("commands") <NUM>.

Converter <NUM> may be constructed and arranged to execute step <NUM> of method <NUM>. Accordingly, converter <NUM> may be constructed and arranged to convert the set of access requests <NUM> to a set of commands <NUM>.

Converter <NUM> may be constructed and arranged to generate pairs of management commands, wherein each pair of management commands includes (a) a first management command that is associated with the first group of memory banks, and (b) a second management command that is associated with the second group of memory banks. The converter <NUM> may be constructed and arranged to generate a compressed representation of the pair of management commands.

The above-mentioned set of commands includes (a) a first sub-set of commands that are related to a first group of memory banks, and (b) a second sub-set of commands that are related to a second group of memory banks.

Scheduler <NUM> may be constructed and arranged to execute step <NUM> of method <NUM>.

Accordingly, scheduler <NUM> may be constructed and arranged to schedule an execution of the first sub-set. This can be executed without reading the second sub-set.

Scheduling decision converter <NUM> may be constructed and arranged to execute step <NUM> of method <NUM>.

Accordingly, scheduling decision converter <NUM> may be constructed and arranged to schedule an execution of the second sub-set to be interleaved with the execution of the first sub-set.

Command execution unit <NUM> may be constructed and arranged to execute step <NUM> of method <NUM>.

Accordingly, command execution unit <NUM> may be constructed and arranged to execute the set of commands according to the schedule. This may include, for example, pre-charging, read and/or write operations, activating, refreshing, and the like.

<FIG> illustrates a sequence of data sub-blocks DSB0-DSB7 that are written in an interleaved manner to first and second memory banks <NUM>(<NUM>) and <NUM>(<NUM>).

<FIG> illustrates an example of a process.

A set of access requests <NUM> are fed to access request converter <NUM> that converts the set of access requests <NUM> to a set of commands that are stored in multiple queues - especially sixteen queues - <NUM>(<NUM>) to <NUM>(<NUM>) that are associated with the sixteen memory banks <NUM>(<NUM>) to <NUM>(<NUM>).

Scheduler <NUM> may access only some of these queues <NUM> in order to schedule only some of the commands. For example, assuming that the scheduler <NUM> has to schedule the first sub-set that are related to a first group of memory banks, then the scheduler <NUM> may access the queues <NUM> that store the first sub-set without accessing the queues that store the second sub-set.

For example, the scheduler <NUM> may access queues <NUM>(<NUM>), <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>) and not access queues <NUM>(<NUM>), <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>).

In another example, scheduler <NUM> may also access <NUM>(<NUM>), <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>) and not access queues <NUM>(<NUM>), <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>).

The scheduler <NUM> may output, during each scheduling iteration, a selected command <NUM>.

The scheduling decisions converter <NUM> converts the selected command <NUM> to a pair of commands that includes the selected command <NUM> and a corresponding command <NUM>. The selected command <NUM> and the corresponding command <NUM> are aimed to different groups of memory banks <NUM>. The corresponding command <NUM> may be retrieved from the queues <NUM> not accessed by the scheduler <NUM>.

The selected command <NUM> and the corresponding command <NUM> are executed by the command execution unit <NUM>.

<FIG> illustrates an example of a generation of a compressed representation of a pair of management commands.

Memory management command <NUM> is converted, by scheduling decision converter <NUM>, to a memory controller command and an indicator (collectively denoted <NUM>). The indicator may be a duplicate flag that indicates that the execution of the memory management command <NUM> should be immediately followed by the execution of a same memory management command, which will be aimed to another group of memory banks.

<FIG> illustrates an example of various commands.

<FIG> illustrates a portion <NUM>(<NUM>) of the memory controller commands <NUM> of <FIG>.

Each command may include an opcode (such as PRE - precharge, ACT - activate, RD - read, WR - write, and REFRESH- refresh), address bits, data (when applicable) and a flag (when applicable).

Management commands such as pre-charge and refresh also include a duplicate flag that indicates that they should be duplicated for one or more other groups of memory banks.

For example, a first PRE command that is aimed to a first memory bank of the first group of memory banks may include a duplicate flag. Accordingly, when the scheduler determines to execute the first PRE command, the dynamic memory controller also generates a second PRE command that is aimed to the second memory bank of the second group of memory banks- and schedules the second PRE command to be executed immediately after the execution of the first PRE command.

The interleaving may be applicable when the dynamic memory module is used to store error correction code (ECC).

<FIG> illustrates that the dynamic memory controller <NUM> may include an error correction code unit <NUM> that includes an ECC cache <NUM> for storing error correction codes sub-blocks.

<FIG> illustrates that the dynamic memory controller <NUM> may be coupled to an error correction code unit <NUM> that includes an ECC cache <NUM> for storing error correction codes sub-blocks.

Various examples of accessing a dynamic memory module and of storing ECC sub-blocks in the dynamic memory module are illustrated in PCT patent application <CIT> and are illustrated in CO-PENDING application titled "ERROR CORRECTION CODING IN A DYNAMIC MEMORY MODULE".

There is provided a method for accessing a dynamic memory module according to claim <NUM>.

The first and second groups of memory banks may belong to multiple memory banks of the dynamic memory module; and the method may include imposing, by the dynamic memory module, a time gap between consecutive input output accesses to a same group of memory banks.

The scheduling of the execution of the first sub-set may include accessing, by the scheduler, the first sub-set without accessing, by the scheduler, the second sub-set.

The scheduling of the execution of the first sub-set may include accessing, by the scheduler, a compressed representation of the group.

The scheduling of the execution of the second sub-set may include adding, to each scheduler decision about a timing of execution of a first command of the first sub-set, another decision regarding a timing of an execution of a second command of the second sub-set, so that the execution of the second command immediately follows the execution of the first command.

The second command and the first command may have a same operand.

The converting includes generating pairs of management commands; wherein each pair of management commands comprises (a) a first management command that is associated with the first group of memory banks, and (b) a second management command that is associated with the second group of memory banks; and storing each pair of management commands in a compressed form.

The storing of each pair of management commands in the compressed form includes storing, for each pair, (a) a single management command that is associated with one of the first and second groups of memory bank, and (b) an indication that a similar command should be generated for the other group of memory banks of the first and second groups of memory bank.

The management commands comprise a refresh command, a pre-charge command and an activate command.

The scheduling of the execution of the first sub-set may include grouping together access requests that are associated with a same row of a memory bank of the first group of memory bank.

The scheduling of the execution of the second sub-set may be performed by a command converter of the memory controller.

There is provided a computer program product that stores instructions that once executed by a memory controller cause the memory controller to execute the steps of a method according to claim <NUM>.

The first and second groups of memory banks may belong to multiple memory banks of the dynamic memory module; and the instructions may cause the memory controller to execute the steps of imposing, by the dynamic memory module, a time gap between consecutive input output accesses to a same group of memory banks.

The computer program product may include instructions for scheduling the execution of the second sub-set by a command converter of the memory controller.

There is provided a device that comprises a memory controller; wherein the memory controller is constructed and arranged to perform the steps of a method according to claim <NUM>.

The first and second groups of memory banks may belong to multiple memory banks of the dynamic memory module; and wherein the dynamic memory module is constructed and arranged to impose a time gap between consecutive input output accesses to a same group of memory banks.

The scheduler of the memory controller may be constructed and arranged to schedule the execution of the first sub-set by accessing the first sub-set without accessing, by the scheduler, the second sub-set.

The scheduler of the memory controller may be constructed and arranged to schedule the execution of the first sub-set by accessing a compressed representation of the group.

The scheduler of the memory controller may be constructed and arranged to schedule the execution of the second sub-set by adding, to each scheduler decision about a timing of execution of a first command of the first sub-set, another decision regarding a timing of an execution of a second command of the second sub-set, so that the execution of the second command immediately follows the execution of the first command.

The memory controller is constructed and arranged to convert the access request to commands by generating pairs of management commands; wherein each pair of management commands comprises (a) a first management command that is associated with the first group of memory banks, and (b) a second management command that is associated with the second group of memory banks; and store each pair of management commands in a compressed form.

The memory controller is constructed and arranged to store of each pair of management commands in the compressed form by storing, for each pair, (a) a single management command that is associated with one of the first and second groups of memory bank, and (b) an indication that a similar command should be generated for the other group of memory banks of the first and second groups of memory bank.

The scheduler of the memory controller may be constructed and arranged to schedule the execution of the first sub-set by grouping together access requests that are associated with a same row of a memory bank of the first group of memory bank.

The memory controller may include a command converter that is constructed and arranged to schedule an execution of the second sub-set.

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 scope of the invention determined by 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 are 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,.

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. 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. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the scope determined by the claims.

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 within the scope determined by the appended claims.

Any combination of any system illustrated in any of the figures and/or specification and/or the claims may be provided within the scope determined by the appended claims.

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

Any combination of operations illustrated in any of the figures and/or specification and/or the claims may be provided within the scope determined by the appended claims.

Any combination of methods illustrated in any of the figures and/or specification and/or the claims may be provided within the scope determined by the appended claims.

Claim 1:
A method for accessing a dynamic memory module, the method comprises:
receiving, by a memory controller, a set of access requests for accessing the dynamic memory module;
converting the access requests to a set of commands, wherein the set of commands comprise (a) a first sub-set of commands that are related to a first group of memory banks, and (b) a second sub-set of commands that are related to a second group of memory banks;
scheduling, by a scheduler of the memory controller, an execution of the first sub-set;
scheduling an execution of the second sub-set to be interleaved with the execution of the first sub-set; and
executing the set of commands as scheduled, wherein the converting comprises generating pairs of management commands wherein the management commands comprise a refresh command, a pre-charge command and an activate command and wherein each of these pairs of management commands comprises
(a) a first management command that is associated with the first group of memory banks, and
(b) a second management command that is associated with the second group of memory banks;
characterized in that the method further comprises storing each of these pairs of management commands in a compressed form, wherein the storing of each of these pairs of management commands in the compressed form comprises storing, for each pair, (a) a single management command that is associated with one of the first and second groups of memory bank, and (b) an indication that a similar command should be generated for the other group of memory banks of the first and second groups of memory bank.