This application is related to U.S. patent application Ser. No. 14/318,114, filed on Jun. 27, 2014, which is incorporated herein by reference in its entirety.
Field of the Disclosure
The present disclosure relates generally to processing systems and, more particularly, to a memory physical layer interface in a processing system.
Description of the Related Art
Processing systems such as systems-on-a-chip (SOCs) use memory to store data or instructions for later use. For example, an SOC may include processing units such as central processing units (CPUs), graphics processing units (GPUs), and accelerated processing units (APUs) that can read instructions or data from memory, perform operations using the instructions or data, and then write the results back into the memory. Processing systems may include a memory physical layer interface for controlling access to a memory module such as dynamic random access memory (DRAM) that can be used to store information so that the stored information can be accessed by the processing units during operation of the processing system. The memory physical layer interface in a processing system is conventionally referred to as a “memory PHY.” A memory controller is typically used to control operation of the memory PHY.
The memory PHY typically is trained using sequences exchanged over an interface between the memory PHY and the DRAM before data can be accurately read from the DRAM or written to the DRAM. A training sequence may include multiple commands such as read commands, write commands, activate commands, or other commands that are used to perform other operations. The memory PHY or the DRAM may require commands in the training sequence to be separated by a specified delay time interval. For example, when a write command is followed by a read command, the DRAM may require a delay of 8 cycles between the write command and the read command. The delay time interval may be different for different types of commands. For example, the delay time interval between two write commands may be different than the delay time interval between a write command and a read command. The delay time interval may also be different for different types of DRAM and may change as new DRAM designs or timing standards are introduced.
The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.
Conventional training sequences use a predetermined sequence of commands that are separated by predetermined delay time intervals. Consequently, conventional training sequences cannot be modified, e.g., to account for the different timing requirements of different DRAM designs. However, as discussed herein, delay time intervals between commands issued to a DRAM may be different for different types of commands and the delay time interval may also be different for different types of DRAM and may change as new DRAM designs are introduced. To account for timing requirements of different memory PHY or DRAM designs, training sequences can be flexibly defined by a programmable training engine that is implemented in the memory PHY. The training engine may be programmed using instruction words that include a first field to indicate a command and a second field to indicate a delay time interval that is to elapse before executing the command. Some embodiments of the instruction words may also include other fields that indicate a DRAM address used by the command, a bank of the DRAM used by the command, a repetition count for the command, and the like. Some embodiments of the memory PHY include registers for holding the instruction words and a start bit that can be written to initiate execution of the instruction words stored in the registers.
Incorporating the delay time interval into the instruction word allows programmers to create training sequences that meet the requirements of different types of DRAM, as well as supporting the development of future training sequences that can meet the as-yet-unknown requirements of future DRAM designs. Furthermore, although two commands may need to be separated by a particular delay time interval, some embodiments of the memory PHY or DRAM may allow another type of command to be performed between the two commands. The delay time intervals indicated in the instruction words for the commands may therefore be set to values that allow the intermediate command to be executed while still meeting the delay time interval requirements for the other two commands.
The CPU processor core 105 includes a basic input/output system (BIOS) 120 that may be implemented in hardware, firmware, software, or a combination thereof. Some embodiments of the BIOS 120 are used to initialize or test components of the APU 100, e.g., in response to a system including the APU 100 being powered on or booted up. The BIOS 120 may also be used to load an operating system. Instructions or commands generated by the BIOS 120 may be conveyed to other locations in the APU 100 using one or more data pipelines (not shown in
The APU 100 shown in
The memory controller 130 may control the operation of other memory modules such as the DRAM 135 using signals transmitted via a memory physical layer interface 140, which may be referred to as a memory PHY 140. The memory PHY 140 includes the circuitry used to drive signals that govern operation of the other memory modules that may be coupled to the APU 100. For example, the memory PHY 140 may provide signals that control reading, writing, refreshing, or erasing portions of a memory module such as the DRAM 135. The memory PHY 140 may be able to operate at different operating points, which may be determined by an operating frequency and/or operating voltage of the memory PHY 140. For example, the other SOC logic 125 may include a clock 145 provides a clock signal to govern synchronization in the memory PHY 140 and/or the memory controller 130 and a reference voltage (VDD) 150 that governs the voltage used by the memory PHY 140 and/or the memory controller 130.
The memory PHY 140 should be trained in order to improve the read or write performance during communication between the memory PHY 140 and the DRAM 135. The memory PHY 140 therefore includes integrated training control logic 155 that is used to generate training sequences or commands, transmit the training sequences or commands to the DRAM 135, receive signals generated by the DRAM 135 in response to the transmitting sequences or commands, and adjust the read/write parameters of the memory PHY 140 based on the responses from the DRAM 135. Integrating the training control logic 155 into the memory PHY 140 has a number of advantages over the conventional practice of training the memory PHY 140 using algorithms implemented in the BIOS 120. Post-processing and/or seeding of the training algorithm used by the training control logic 155 may be reduced or eliminated by removing the need to transmit training sequences over a data pipeline between the BIOS 120 and the memory PHY 140.
Some embodiments of the training control logic 155 include a microcontroller and one or more training engines for generating training sequences and using the training sequences to configure operation of the memory PHY 140. For example, the training control logic 155 may include a training engine that generates at-speed programmable sequences of commands for delivery to the DRAM 135. The training control logic 155 may also include (or have access to) one or more registers to store instruction words that include information identifying one or more commands that may be used to form the at-speed programmable sequences. The instruction words may also include information indicating a delay associated with the command, as well as other information. The training control logic 155 may then insert the indicated delay between the command and other commands in the command sequence, as discussed herein.
The controller 215 may interact with a BIOS such as the BIOS 120 shown in
The controller 215 is coupled to a first training engine 220, which also may be referred to as an address command state machine (ACSM) 220. The ACSM 220 generates commands that may be provided to the DRAM 210 during training of the memory PHY 205. The programmable commands may be generated “at speed” for embodiments of the first training engine 220 that are implemented in hardware as an integrated part of the memory PHY 205. Commands generated by the ACSM 220 may include read commands to read information from a specified location in the DRAM 210, write commands to write information to a specified location in the DRAM 210 and other commands such as activate commands. Some embodiments of the ACSM 220 may generate loopback commands that combine concurrent read and write commands that drive signals to the physical pins of the memory PHY 205, which are then returned along paths through the memory PHY 205. Loopback commands may therefore be used to test the memory PHY 205 without requiring that the DRAM 210 be connected to the physical pins of the memory PHY 205. Some embodiments of the ACSM 220 may generate looped commands that repetitively perform one or more commands with a specified delay between the commands, looping or repeating on a single instruction during execution, looping over multiple commands in a sequence, and the like.
One or more registers 222 are accessible, e.g., they may be read or written, by the ACSM 220. The registers 222 shown in
The registers 222 are used to store instruction words 223 that each include information indicating a command and a timing delay associated with the command. The instruction words 223 may be written into the registers 222 by the controller 215. The timing delay indicates a delay that is to be inserted between the command in the instruction word and other commands, e.g., commands in other instruction words 223. The timing delay may be inserted before the corresponding command is executed or after the corresponding command is executed. In some embodiments, the instruction words 223 may also include other information such as a command repetition count that indicates a number of repetitions of the command indicated in the instruction word, an address in an external memory such as the DRAM 210, algorithmic address generation control information that can be used to generate addresses for accessing the DRAM 210, a bank in the external memory, and the like. The algorithmic address generation control information may include information used to define polynomials for random selection of addresses, information for incrementing addresses, address offsets or strides, information used to rotate addresses, and the like.
Some embodiments of the registers 222 may also include a memory location 224 for storing one or more control bits that may be used to indicate information such as start addresses, sequence loop addresses, and the like. The ACSM 220 may initiate execution of one or more commands or command sequences in response to the controller 215 writing a predetermined value of the start bit to the memory location 224. Some embodiments of the instruction words 223 stored in the registers 222 may include a terminate bit that can be used to terminate execution of a sequence of commands by writing a particular value of the terminate bit into the instruction word.
The controller 215 is also coupled to a second training engine 225, which may be referred to as a PRBS pattern generator checker (PPGC) 225. Some embodiments of the PPGC 225 are programmable and can generate data streams that are used as the training sequences for training the memory PHY 205. For example, the PPGC 225 may generate a data stream for any 16-bit (or less) polynomial in response to signaling provided by the controller 215. Some embodiments of the PPGC 225 include a separate generator 235 that is used to generate the training sequence and a checker 230 that is used to check synchronization of the read or write streams that include the training sequences that flow between the memory PHY 205 and the DRAM 210. Operation of the PPGC 225 may be controlled by signaling received from the ACSM 220. For example, the ACSM 220 may provide signaling that sequences execution of operations such as generating the training sequences at the generator 235.
The controller 215 is also coupled to a third training engine, which may be referred to as a data training state machine (DTSM) 240. The DTSM 240 compares traffic received from the DRAM 210 to the training sequences provided to the DRAM 210 to determine whether to adjust timing parameters or voltage offset parameters used by the memory PHY 205. For example, the PPGC 225 may provide representations of the training sequences to the DTSM 240 for comparison to the sequences returned from the DRAM 210 during read training or write training of the memory PHY 205. Prior to starting a training loop, the controller 215 may configure the DTSM 240 to control timing parameters or voltage offset parameters used by the memory PHY 205. The controller 215 may then program the ACSM 220 and the PPGC 225 to drive one or more training sequences. The DTSM 240 may then compare the training sequences generated by the PPGC 225 to sequences that have been received from the DRAM 210. For example, the DTSM 240 may correlate the training sequences and the receive sequences at a plurality of different delays. Based on the comparison, the DTSM 240 decides whether to adjust the timing parameters or the voltage offset parameters, e.g., by incrementing or decrementing one or more of these parameters. For example, a timing offset may be increased or decreased based on the delay determined based on the correlation of the training sequences and the receive sequences. Some embodiments of the DTSM 240 may also implement data filters or binary adders with upper or lower threshold comparison logic to train to a data contour eye position.
Sets of first-in-first-out (FIFO) buffers may be used to buffer the training sequences before being provided to the DRAM 210 and to buffer received sequences after being received from the DRAM 210. For example, a set of outbound FIFO buffers 245 may be used to buffer the outbound traffic and a set of inbound FIFO buffers 250 may be used to buffer the inbound traffic. One or more receivers 255 may be used to receive signals over channels to the DRAM 210 and provide them to the inbound FIFO buffer 250. One or more drivers 260, 265 may be used to transmit signals from the outbound FIFO buffer 245 over the channels to the DRAM 210. For example, the driver 260 may be used to drive data (DQ) or timing (DQS) signals onto the channel 270 and the receiver 255 may receive data (DQ) or timing (DQS) signals over the channel 270. For another example, the driver 265 may be used to drive addresses (ADDR) or commands (CMD) over the channel 275 to the DRAM 210. Timing delays and voltage offsets used by the receivers 255 or the drivers 260, 265 may be adjusted.
The memory PHY 205 includes timing/voltage control logic 280. The DTSM 240 may provide signals to the timing/voltage control logic 280 to indicate adjustments to the timing parameters. For example, the DTSM 240 may instruct the timing/voltage control logic 280 to increment or decrement timing delays or voltage offsets based on comparisons of training sequences provided to the DRAM 210 and sequences received from the DRAM 210. The timing/voltage control logic 280 may then provide control signals to the receivers 255 or the drivers 260, 265 to adjust the timing delays or voltage offsets used by the receivers 255 or the drivers 260, 265. Some embodiments of the timing/voltage control logic 280 may be used to adjust timing delays or voltage offsets in multiple stages such as a receive enable stage, a write leveling stage, a read training stage, a write training stage, and a stage for determining voltage levels of a data eye contour for the interface between the memory PHY 205 and the DRAM 210.
Some embodiments of the instruction word 300 also include a field 315 for storing information indicating a command repetition count that indicates the number of times that the command indicated in the field 305 should be repeated. The command delay indicated in the field 310 may be applied to each repetition of the command. A field 320 may include an address associated with the command indicated in the field 305. The address may indicate a location in an external memory (such as the DRAM 210 shown in
The first command read by the training engine is a write command 410, which is executed following a delay 415 that is at least as long as the predetermined time interval indicated by the command delay in the instruction word. The training engine may then read the next instruction word from the registers. The next instruction word includes information indicating that the next command is a read command 420. In some embodiments, a predetermined amount of time may be required to elapse between performing a write command that writes information to the external memory and performing a read command that reads information from the external memory. The required latency may depend on the characteristics of the external memory such as the type of DRAM that is connected to the memory PHY that implements the training engine. Programmers may therefore indicate an appropriate command delay between the write command 410 and the subsequent read command 420 in a command delay field of the instruction word. The training engine may therefore delay execution of the read command 420 for a time interval 425 that is at least as long as the predetermined time interval indicated by the command delay in the instruction word.
The training engine may read a subsequent instruction word from the registers. In some embodiments, the subsequent instruction word includes information identifying a read command 430 that is used to read information from the external memory following the previous read command 420. A predetermined time interval may be required to elapse between performing two consecutive read commands 420, 430 and this time interval may be indicated in the command delay field in the instruction word. The training engine may therefore delay execution of the read command 430 for a time interval 435 that is at least as long as the predetermined time interval indicated by the command delay in the instruction word. The predetermined time interval that should elapse between two consecutive read commands 420, 430 may be different than the predetermined time interval that should elapse between a write command 410 and a read command 420.
Generally speaking, the time intervals that should elapse between different types of commands may depend on the types of commands, the order in which the commands are performed, or other characteristics of the commands, the memory PHY, or external memory including different dual in-line memory modules (DIMMs). For example, different DIMMs may be located at different distances relative to the memory PHY and consequently communications between the memory PHY and the different DIMMs may experience different transport delays. The delays indicated in the instruction words may be used to account for the different transport delays, e.g. to prevent information returned in response to a read command issued to the most distant DIMM from colliding with (or arriving at the memory PHY after) information returned in response to a subsequent read command issued to a DIMM that is closer to the memory PHY. Including the command delay field in the instruction word provides programmers with the flexibility to adapt the command sequence 400 to the requirements of particular embodiments.
The next two commands include a read command 520 and one or more other commands 525. The read command 520 should be executed with a latency 530 relative to the write command 510. The other command 525 can be executed without any particular latency relative to the write command 510 or the read command 520, or with a relatively small latency relative to the latency 530. The delays 535, 540 in the instruction words associated with the read command 520 and the other command 525 may therefore be configured so that the sum of the two delays 535, 540 is at least as large as the latency 530. The training engine may therefore execute the other command 525 after the delay 535 and subsequently execute the read command 520 after the delay 540, which also satisfies the requirement that the read command 520 be executed with a latency 530 relative to the write command 510.
Some embodiments of the instruction word may include a command repetition field that indicates a number of repetitions of the command in the instruction word. At decision block 630, the training engine determines whether the command has been repeated for a number of repetitions that is less than a command repetition count indicated in the command repetition field. If the number of repetitions is less than the command repetition count, indicating that the command should be repeated at least one more time, the training engine determines the appropriate delay at decision block 615 and executes the command at the block 620, possibly after waiting for the indicated delay at block 625. The method 600 may flow to decision block 630 once the number of repetitions is greater than or equal to the command repetition count. Some embodiments of the training engine may maintain a counter to keep track of the number of repetitions of the command.
At decision block 635, the training engine determines whether to terminate the command sequence with the current instruction word. In some embodiments, the command sequence may be terminated in response to a terminate bit being set in the current instruction word. If the training engine determines that the command sequence is not to be terminated, the training engine may advance to the next instruction word (at block 640), e.g., by advancing the start pointer to the next register. The method 600 may then flow to block 610, where the next instruction word is read from the register. If the training engine determines that the command sequence is to be terminated, the command sequence may be terminated the method 600 may end by unsetting the start bit at block 645.
At block 705, the training control logic performs receive enable training to determine when to enable the memory PHY to receive data over the interface with the DRAM. Some embodiments perform receive enable training by transmitting a read commands to read a selected address from the DRAM. The read commands are interspersed with a sequence of bubbles that generate corresponding sequences of bubbles in the signals received from the DRAM. The training control logic then monitors signals received from the DRAM to align the time of command generation in the memory PHY to the time the command response from the DRAM is returned to the memory PHY. The bubble spacing time interval range is sized so as to be greater than the worst case round trip latency plus any internal memory PHY and DRAM latencies in the path. This avoids any potential aliasing of the command response association with an earlier or later response. The memory PHY may be configured to stay in a continuous read state during the receive enable training stage. For example, the controller 215 may configure the ACSM 220, PPGC 225, and DTSM 240 and then initiate the training stage. The ACSM 220 may issue commands/addresses to write a training sequence to the DRAM 210 and then issue commands/addresses to read the training sequence back from the DRAM 210. In some embodiments, no information is actually written to the DRAM 210 in response to the issued commands and the DQ bus is ignored. Only the returned DQS is monitored. The issued command is therefore similar to a read command but the DTSM 240 does not care what data is returned in response to the command. The DTSM 240 is only interested in adjusting the timing of the DQS strobe that comes back from DRAM 210. The training sequence may be generated by the PPGC 225 and provided to the DRAM 210. The DTSM 240 may then correlate receive data from the DRAM 210 with the training sequence to identify the round-trip delay and instruct the timing/voltage control logic 280 to tune the parameters for the appropriate receivers/drivers such as the receivers 255 and the drivers 260, 265 to null the detected round trip delay.
At block 710, the training logic performs write leveling to align clock signals used by the memory PHY to clock signals used by the DRAM. Some embodiments of the training logic may therefore transmit a memory PHY clock signal and a timing (DQS) signal that is used to sample the value of the clock at the DRAM. The training logic may then use the sampled value of the DRAM clock returned on the DQ bus to align the memory PHY clock and the DRAM clock, e.g., by introducing delays to align the DQS signal with a memory clock phase that is internal to the DRAM. For example, in response to signaling from the controller 215, the ACSM 220 may generate a write command that causes a memory PHY clock signal including a rising edge and a DQS signal that is provided to the DRAM 210 to sample the memory clock in the DRAM. The write command may be generated based on information read from registers 222, as discussed herein. The sampled value of the DRAM clock may then be returned to the memory PHY 205. The checker 230 in the PPGC 225 generates an internal comparison value and provides this value to the DTSM 240. The DTSM 240 may then compare the internal comparison value to the sampled clock signal value received from the DRAM 210 and generate adjustment signals based on the comparison to align the write DQS to the clock in the DRAM 210. The DTSM 240 may then instruct the timing/voltage control logic 280 to tune the timing parameters for the receivers 255 and the drivers 260, 265 to synchronize the memory PHY clock and the DRAM clock. For example, if the internal comparison value is “0” and the sampled value of the DRAM clock is “1,” the DTSM 240 may instruct the timing/voltage control logic 280 to advance the timing of the memory PHY 205 by a predetermined amount of time. If the internal comparison value is “1” and the sampled value of the DRAM clock is “1,” the DTSM 240 may instruct the timing/voltage control logic 282 delay the timing of the memory PHY 205 by a predetermined amount of time. This process may be iterated to tune the synchronization of the memory PHY clock and the DRAM clock to within a predetermined tolerance.
At block 715, the training logic performs read/write phase training to determine the one-dimensional time boundaries of the data eye contour based on the read/write data paths between the memory PHY and the DRAM. Some embodiments of the training logic may therefore transmit a series of commands to write a training sequence into addresses in the DRAM and then loop-read the training sequences out of the addressed locations of the DRAM at different delays to determine the one-dimensional time boundaries of the data eye contour. For example, in response to signaling from the controller 215, the ACSM 220 may issue commands to write one or more sequences generated by the PPGC 225 to one or more addresses in the DRAM 210. The ACSM 220 may then issue a series of read commands to the addresses in the DRAM 210 that are looped with different delay values. Some embodiments of the command sequences may be generated by the ACSM 220 based on information read from instruction words in the registers 222, as discussed herein. The DTSM 240 may then compare the received sequences for each of the looped read commands to the provided training sequences to determine the left edge and the right edge of the data eye contour. The DTSM 240 may then instruct the timing/voltage control logic 280 to tune the timing parameters, e.g., the phase, for the receivers 255 to correspond to a predetermined location in the data eye contour such as the midpoint between the left edge and the right edge.
At block 720, the training logic performs two-dimensional (2D) read/write phase training to determine the voltage levels of the data eye contour based on the read/write data paths between the memory PHY and the DRAM. Some embodiments of the training logic may therefore transmit a series of read/write commands to read and write training sequences to and from the DRAM. The series of read/write commands may be performed using different timing delays and different voltage offsets to determine the voltage levels in the data eye contour. For example, in response to signaling from the controller 215, the ACSM 220 may issue commands to write one or more sequences generated by the PPGC 225 to one or more addresses in the DRAM 210 using an initial timing delay. The ACSM 220 may then issue a series of looped read commands to the addresses in the DRAM 210. The read/write commands may be issued concurrently with providing different values of the voltage offset to the receivers 255 or the drivers 260, 265. Some embodiments of the command sequences may be generated by the ACSM 220 based on information read from instruction words in the registers 222, as discussed herein. The DTSM 240 may then compare the received sequences for each of the looped read commands to the provided training sequences to determine the voltage levels between the left edge and the right edge of the data eye contour for the initial timing delay. The timing delay may be changed (e.g., incremented or decremented) and the process of determining the voltage levels may be repeated. This process may be iterated to determine the two-dimensional data eye contour over a range of timing delays and voltage levels. Some embodiments may instead iteratively choose voltage levels and loop over timing delays for the selected voltage level to determine the two-dimensional data eye contour.
The DTSM 240 instructs the timing/voltage control logic 280 to tune the timing delays and the voltage offsets for the receivers 255 or the drivers 260, 265 to correspond to a location in the data eye contour that provides the best voltage level and timing delay. Adjustments to the timing delays or the voltage offsets can be determined based on numbers of correct samples and incorrect samples in sampled training data. Some embodiments of the DTSM 240 may determine the optimal timing delay and voltage offset based on a predetermined ratio of correct samples to incorrect samples in sampled training data. For example, the DTSM 240 may tune the timing delay and the voltage offset until the ratio of the number of correct samples to the number of incorrect samples received by the memory PHY 205 is at or below the predetermined ratio. Some embodiments of the DTSM 240 may use the predetermined ratio to alter the shape of the data eye contour with the expectation that a better optimal training position could be determined. For example, the 2D eye contour could be expanded or contracted based on the predetermined ratio. Other alterations to the shape of the 2-D data eye contour are also possible.
In some embodiments, the apparatus and techniques described above are implemented in a system comprising one or more integrated circuit (IC) devices (also referred to as integrated circuit packages or microchips), such as the memory PHY described above with reference to
A computer readable storage medium may include any storage medium, or combination of storage media, accessible by a computer system during use to provide instructions and/or data to the computer system. Such storage media can include, but is not limited to, optical media (e.g., compact disc (CD), digital versatile disc (DVD), Blu-Ray disc), magnetic media (e.g., floppy disc, magnetic tape, or magnetic hard drive), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or Flash memory), or microelectromechanical systems (MEMS)-based storage media. The computer readable storage medium may be embedded in the computing system (e.g., system RAM or ROM), fixedly attached to the computing system (e.g., a magnetic hard drive), removably attached to the computing system (e.g., an optical disc or Universal Serial Bus (USB)-based Flash memory), or coupled to the computer system via a wired or wireless network (e.g., network accessible storage (NAS)).
At block 802 a functional specification for the IC device is generated. The functional specification (often referred to as a micro architecture specification (MAS)) may be represented by any of a variety of programming languages or modeling languages, including C, C++, SystemC, Simulink, or MATLAB.
At block 804, the functional specification is used to generate hardware description code representative of the hardware of the IC device. In some embodiments, the hardware description code is represented using at least one Hardware Description Language (HDL), which comprises any of a variety of computer languages, specification languages, or modeling languages for the formal description and design of the circuits of the IC device. The generated HDL code typically represents the operation of the circuits of the IC device, the design and organization of the circuits, and tests to verify correct operation of the IC device through simulation. Examples of HDL include Analog HDL (AHDL), Verilog HDL, SystemVerilog HDL, and VHDL. For IC devices implementing synchronized digital circuits, the hardware descriptor code may include register transfer level (RTL) code to provide an abstract representation of the operations of the synchronous digital circuits. For other types of circuitry, the hardware descriptor code may include behavior-level code to provide an abstract representation of the circuitry's operation. The HDL model represented by the hardware description code typically is subjected to one or more rounds of simulation and debugging to pass design verification.
After verifying the design represented by the hardware description code, at block 806 a synthesis tool is used to synthesize the hardware description code to generate code representing or defining an initial physical implementation of the circuitry of the IC device. In some embodiments, the synthesis tool generates one or more netlists comprising circuit device instances (e.g., gates, transistors, resistors, capacitors, inductors, diodes, etc.) and the nets, or connections, between the circuit device instances. Alternatively, all or a portion of a netlist can be generated manually without the use of a synthesis tool. As with the hardware description code, the netlists may be subjected to one or more test and verification processes before a final set of one or more netlists is generated.
Alternatively, a schematic editor tool can be used to draft a schematic of circuitry of the IC device and a schematic capture tool then may be used to capture the resulting circuit diagram and to generate one or more netlists (stored on a computer readable media) representing the components and connectivity of the circuit diagram. The captured circuit diagram may then be subjected to one or more rounds of simulation for testing and verification.
At block 808, one or more EDA tools use the netlists produced at block 806 to generate code representing the physical layout of the circuitry of the IC device. This process can include, for example, a placement tool using the netlists to determine or fix the location of each element of the circuitry of the IC device. Further, a routing tool builds on the placement process to add and route the wires needed to connect the circuit elements in accordance with the netlist(s). The resulting code represents a three-dimensional model of the IC device. The code may be represented in a database file format, such as, for example, the Graphic Database System II (GDSII) format. Data in this format typically represents geometric shapes, text labels, and other information about the circuit layout in hierarchical form.
At block 810, the physical layout code (e.g., GDSII code) is provided to a manufacturing facility, which uses the physical layout code to configure or otherwise adapt fabrication tools of the manufacturing facility (e.g., through mask works) to fabricate the IC device. That is, the physical layout code may be programmed into one or more computer systems, which may then control, in whole or part, the operation of the tools of the manufacturing facility or the manufacturing operations performed therein.
In some embodiments, certain aspects of the techniques described above may implemented by one or more processors of a processing system executing software. The software comprises one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer readable storage medium. The software can include the instructions and certain data that, when executed by the one or more processors, manipulate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer readable storage medium can include, for example, a magnetic or optical disk storage device, solid state storage devices such as Flash memory, a cache, random access memory (RAM) or other non-volatile memory device or devices, and the like. The executable instructions stored on the non-transitory computer readable storage medium may be in source code, assembly language code, object code, or other instruction format that is interpreted or otherwise executable by one or more processors.
Note that not all of the activities or elements described above in the general description are required, that a portion of a specific activity or device may not be required, and that one or more further activities may be performed, or elements included, in addition to those described. Still further, the order in which activities are listed are not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present disclosure as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present disclosure.
Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any feature(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature of any or all the claims. Moreover, the particular embodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.
Number | Name | Date | Kind |
---|---|---|---|
5940876 | Pickett | Aug 1999 | A |
7647467 | Hutsell et al. | Jan 2010 | B1 |
8386722 | Wang et al. | Feb 2013 | B1 |
20030236641 | Liou | Dec 2003 | A1 |
20050156646 | Liou | Jul 2005 | A1 |
20050228915 | Saripalli | Oct 2005 | A1 |
20070121399 | Bains | May 2007 | A1 |
20080256282 | Guo | Oct 2008 | A1 |
20100100711 | Kaplan | Apr 2010 | A1 |
20100257397 | Schoenborn | Oct 2010 | A1 |
20100275037 | Lee et al. | Oct 2010 | A1 |
20120066445 | Searles | Mar 2012 | A1 |
20120126868 | Machnicki et al. | May 2012 | A1 |
20120250433 | Jeon | Oct 2012 | A1 |
20120284576 | Housty et al. | Nov 2012 | A1 |
20120307577 | Sriadibhatla | Dec 2012 | A1 |
20130044796 | Haldar | Feb 2013 | A1 |
20130124904 | Wang | May 2013 | A1 |
20130151796 | Gupta | Jun 2013 | A1 |
20130155788 | Brandl et al. | Jun 2013 | A1 |
20130318285 | Pignatelli | Nov 2013 | A1 |
20130340231 | Lu | Dec 2013 | A1 |
20140006675 | Meir | Jan 2014 | A1 |
20140043918 | Ellis et al. | Feb 2014 | A1 |
20140063991 | Ji | Mar 2014 | A1 |
20140079399 | Goswami | Mar 2014 | A1 |
20140108683 | Thayer | Apr 2014 | A1 |
20140114887 | Iyer et al. | Apr 2014 | A1 |
Number | Date | Country |
---|---|---|
2616946 | Jun 2014 | EP |
2006260071 | Sep 2006 | JP |
1020120077315 | Jan 2014 | KR |
Entry |
---|
Non-Final Office Action dated Nov. 5, 2015 for U.S. Appl. No. 14/318,144, 19 pages. |
International Search Report correlating to PCT/US2015/037172 dated Sep. 21, 2015, 9 pages. |
Written Opinion correlating to PCT/US2015/037172 dated Sep. 21, 2015, 7 pages. |
Final Office Action dated Apr. 27, 2016 for U.S. Appl. No. 14/318,144, 10 pages. |
Advisory Action dated Jul. 15, 2016 for U.S. Appl. No. 14/318,114, 3 pages. |
International Search Report and Written Opinion correlating to PCT/US2015/037158 dated Sep. 15, 2015, 9 pages. |
International Preliminary Report on Patentability correlating to PCT/US15/037210 dated Dec. 27, 2016, 6 pages. |
International Preliminary Report on Patentability correlating to PCT/US15/037172 dated Dec. 27, 2016, 8 pages. |
U.S. Appl. No. 14/318,114, filed Jun. 27, 2014, entitled “Integrated Controller for Training Memory Physical Layer Interface”. |
Non-Final Office dated Aug. 25, 2016 for U.S. Appl. No. 14/318,114, 7 pages. |
Extended European Search Report and Written Opinion dated Oct. 12, 2017 for EP Application No. 15 812 029.5, 7 pages. |
Extended European Search Report dated Aug. 28, 2017 for EP Application No. 15 811 645.9, 7 pages. |
Chinese office action and translation thereof dated Jan. 11, 2018 for Chinese Application No. 201580016122.2, 21 pages. |
Translation of Second Office Action dated Aug. 3, 2018 for Chinese Application No. 201580016122.2, 10 pages. |
Translation of the Office Action dated Oct. 15, 2018 for Japanese Application No. 2016-558772, 7 pages. |
Number | Date | Country | |
---|---|---|---|
20150378956 A1 | Dec 2015 | US |