USPatent applicationPatented

Providing code to a programmable device

Granted 15 Nov 2016 · 2 office actions

Life of the application

14 dated events
⤢ drag to zoom200820102012201420162018202020222024202620282030ProsecutionOwnershipTerm & fees
ProsecutionOwnershipTerm & feeshover for detail · click to open

Abstract

According to one embodiment, providing a bitstream to one or more programmable devices of a service unit card includes receiving the bitstream at a snooper of the service unit card. The snooper determines whether the bitstream is current. If the bitstream is current, the bitstream is loaded onto the programmable devices. If the bitstream is not current, the received bitstream is discarded, and a substitute bitstream is identified. The substitute bitstream is loaded onto the programmable devices.

Description

7 parts
›RELATED APPLICATION

This application claims benefit under 35 U.S.C. §119(e) of U.S. Provisional Application Ser. No. 61/093,602, entitled “System and Method for Substituting a Software Load Bitstream,” 0 filed Sep. 2, 2008, by Roy McNeil.

›TECHNICAL FIELD

This invention relates generally to the field of programmable devices and more specifically to providing code to a programmable device.

›BACKGROUND

Service unit cards may have devices that are loaded with software from a master controller. For example, a telecommunication node may have a shelf with a number of cards. A controller card may download software to be loaded onto programmable devices on other cards of the shelf.

›SUMMARY OF THE DISCLOSURE

In accordance with the present invention, disadvantages and problems associated with previous techniques for providing code to a programmable device may be reduced or eliminated.

According to one embodiment, providing a bitstream to one or more programmable devices of a service unit card includes receiving the bitstream at a snooper of the service unit card. The snooper determines whether the bitstream is current. If the bitstream is current, the bitstream is loaded onto the programmable devices. If the bitstream is not current, the received bitstream is discarded, and a substitute bitstream is identified. The substitute bitstream is loaded onto the programmable devices.

According to one embodiment, providing code to a service unit card includes determining, by a loader of the service unit card, whether downloaded code is current. If the downloaded code is current, the loader instructs a processor to execute the downloaded code stored in a memory of the card. If the downloaded code is not current, the loader instructs the processor to execute substitute code stored in other memories of the card.

Certain embodiments of the invention may provide one or more technical advantages. A technical advantage of one embodiment may be that an updated bitstream may be automatically substituted for an outdated bitstream downloaded from a master controller. The updated bitstream may be loaded onto a programmable device of a service unit card. A technical advantage of another embodiment may be that a processor of a service unit card may be instructed to execute updated code stored in a memory instead of outdated code downloaded from a master controller.

In the embodiments, software stored at the master controller may remain unchanged. Accordingly, the embodiments may allow for replacing service unit cards without updating the master controller. The embodiments may allow a service unit card to replace an existing card in order to provide replacement, updated, or different capabilities without affecting the customer. The embodiments may store the updated code on memory that is larger than that of the master controller, which may allow for larger updated code.

Certain embodiments of the invention may include none, some, or all of the above technical advantages. One or more other technical advantages may be readily apparent to one skilled in the art from the figures, descriptions, and claims included herein.

›BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and its features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

FIG. 1 illustrates an embodiment of a system for providing a bitstream to a programmable device;

FIG. 2 illustrates an embodiment of a system for providing code to a service unit card; and

FIG. 3 illustrates an embodiment of system for patching software.

›DETAILED DESCRIPTION OF THE DRAWINGS · 1 of 2

Embodiments of the present invention and its advantages are best understood by referring to FIGS. 1 through 3 of the drawings, like numerals being used for like and corresponding parts of the various drawings.

FIG. 1 illustrates an embodiment of a system 10 for providing a bitstream to a programmable device. In the illustrated embodiment, system 10 includes a master controller unit (MCU) card 20 and a service unit card 24 . MCU card 20 includes an MCU 30 . Service unit card 24 includes a loader 34 , one or more memories 38 ( a and/or b ), a snooper 40 , a bit bucket 44 , and one or more programmable devices, such as field programmable gate arrays (FPGAs) 48 ( a, b , . . . and/or n ). In other embodiments, MCU 30 may be located on service unit card 24 . The components of system 10 may be located at a shelf of a telecommunications node.

MCU 30 may represent any suitable master controller that controls a slave device, such as service unit cards. In certain embodiments, MCU 30 of MCU card 20 controls one or more service unit cards 24 . A service unit card 24 may perform telecommunications operations. Examples of service unit cards 24 include Digital Signal 1 (DS 1 ), Ethernet, Frame Relay, or optical line cards.

In certain embodiments, service unit card 24 may provide replacement, upgraded, or different capabilities to a telecommunications node. That is, service unit card 24 may replace inoperable devices, outdated devices, or devices with different capabilities. For example, RPR, APORT, and EPORT capabilities, may be provided on QLAN2, GLAN2, and FLAN2 cards.

Loader 34 downloads a bitstream from MCU 30 . Memory 38 may comprise any suitable memory, such as flash memory. Other examples of memory are discussed below. Memory 38 may be configured to store code. In certain embodiments, “code” may refer to a series of characters written according to a programming language that may be executed by a computing device. Examples of code include software and bitstreams.

In certain embodiments, memory 38 a stores code downloaded from MCU 30 , memory 38 b stores substitute code that may be pre-compiled and that programmable devices 48 may use. In certain embodiments, memory 38 b may be loaded with the substitute bitstream before the card is shipped. In certain embodiments, memories 38 may comprise a primary memory and a backup memory. The primary memory stores primary substitute code, and the backup memory stores backup substitute code that may be used if the primary substitute code is not available.

A substitute bitstream may be the result of any suitable situation. In particular embodiments, a new bitstream may be the result of using a new device, such as a new cost-reduced or a higher performance FPGA. The new FPGA may be transparent to the end customer. In other embodiments, a new bitstream may be the result of using a device (such as an FPGA) that includes an update for fixing latent bugs.

FPGAs 48 are examples of programmable devices that can execute code to perform operations. Other examples of programmable devices include application-specific integrated circuit (ASICs), complex programmable logic devices (CPLDs), central processing units (CPUs), controllers, digital signal processors, or other computing devices.

Snooper 40 provides substitute bitstreams to FPGAs 48 , if needed. In certain embodiments, snooper 40 receives a bitstream from memory 38 a during, for example, initialization, or power up. Snooper 40 determines whether the bitstream is current. Snooper 40 may examine a cyclic redundancy check (CRC) block to determine whether the bitstream is current. In certain embodiments, if a device revision level of a device is more current than a bitstream revision level of the bitstream, then bitstream may be regarded as not current.

If the bitstream is current, snooper 40 loads the bitstream onto the one or more devices. If the bitstream is not current, snooper 40 discards the received bitstream at, for example, bit bucket 44 . Snooper 40 then identifies a substitute bitstream stored in memory 38 b and loads the substitute bitstream onto FPGAs 48 .

FIG. 2 illustrates an embodiment of a system 110 for providing code to a service unit card 124 . In the illustrated embodiment, system 110 includes an MCU 130 and service unit card 124 . MCU 130 may be located on service unit card 124 or may be separate from service unit card 124 . Service unit card 124 includes a CPU 134 , memories 138 ( a, b , and/or c ), and a loader 140 coupled as shown. MCU 130 and memories 138 may be substantially similar to MCU 30 and memories 38 of FIG. 1 .

In certain embodiments, CPU 134 enters an initialization state and loads loader 140 onto service unit card 124 in response to entering the initialization state.

In certain embodiments, loader 140 determines whether downloaded code stored in memory 138 a is current. Loader 140 may determine whether code is current in a manner similar to that used by snooper 40 to determine whether a bitstream is current. If the downloaded code is current, loader 140 instructs CPU 134 to execute the downloaded code stored in memory 138 a . For example, loader 140 may instruct CPU 134 to retrieve code FPGA images from memory 138 a.

If the downloaded code is not current, loader 140 instructs CPU 134 to execute substitute code stored in primary memory 138 b (or secondary memory 138 c if primary memory 138 b is unavailable). For example, loader 140 may instruct processor 134 to retrieve code FPGA images from memory 138 b (or 138 c ).

FIG. 3 illustrates an embodiment of system 200 for patching software. In the illustrated embodiment, system 200 includes a software download (SWDL) manager 230 , a software download agent 232 , a bank directory 234 , and a patch directory 236 .

In certain embodiments, patch directory 236 stores software patch load modules and a monolith. The patches may be installed on patch directory 236 during the manufacturing process. Software download agent 232 receives a command to burn an initial program load. Software download agent 232 determines if there is a module to be patched according to the patch configuration file of patch directory 236 . Software download agent 232 then updates bank directory 234 to reflect the patch modules. Software download agent 232 then burns the patched monolith and informs software download manager 232 that the monolith has been patched.

›DETAILED DESCRIPTION OF THE DRAWINGS · 2 of 2

A component of the systems may include an interface, logic, memory, and/or other suitable element. An interface receives input, sends output, processes the input and/or output, and/or performs other suitable operation. An interface may comprise hardware and/or software.

Logic performs the operations of the component, for example, executes instructions to generate output from input. Logic may include hardware, software, and/or other logic. Logic may be encoded in one or more tangible media and may perform operations when executed by a computer. Certain logic, such as a processor, may manage the operation of a component. Examples of a processor include one or more computers, one or more microprocessors, one or more applications, and/or other logic.

In particular embodiments, the operations of the embodiments may be performed by one or more computer readable media encoded with a computer program, software, computer executable instructions, and/or instructions capable of being executed by a computer. In particular embodiments, the operations of the embodiments may be performed by one or more computer readable media storing, embodied with, and/or encoded with a computer program and/or having a stored and/or an encoded computer program.

A memory stores information. A memory may comprise one or more tangible, computer-readable, and/or computer-executable storage medium. Examples of memory include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), database and/or network storage (for example, a server), and/or other computer-readable medium.

Modifications, additions, or omissions may be made to the systems without departing from the scope of the invention. The components of the systems may be integrated or separated. Moreover, the operations of the systems may be performed by more, fewer, or other components. For example, the operations of loader 34 and snooper 40 may be performed by one component, or the operations of snooper 40 may be performed by more than one component. Additionally, operations of the systems may be performed using any suitable logic comprising software, hardware, and/or other logic. As used in this document, “each” refers to each member of a set or each member of a subset of a set.

Modifications, additions, or omissions may be made to the methods without departing from the scope of the invention. The methods may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order.

Although this disclosure has been described in terms of certain embodiments, alterations and permutations of the embodiments will be apparent to those skilled in the art. Accordingly, the above description of the embodiments does not constrain this disclosure. Other changes, substitutions, and alterations are possible without departing from the spirit and scope of this disclosure, as defined by the following claims.

Claims as granted

22 claims

Log in to read the claims of this application.

Log in to unlock

Classifications

6 codes
IPC · International Patent Classification
Section G — Physics
  • G06F9/445
  • G06F11/14
  • G06F12/16
  • G06F12/02
  • G06F9/44
Section H — Electricity
  • H03M13/09

Claim changes

Soon
Coming soonHow the claims changed between publication and grant

See which claims were amended, added or cancelled during examination, with every added and removed word marked.

AmendedAddedCancelledUnchanged

The published claims of this application are not paired with the granted ones in what we hold.

File wrapper

⤢ drag to zoom20102011201220132014201520162017USPTOApplicantNon-final rejectionResponse after finalNotice of allowance
USPTOApplicanthover for detail · click to open
Pendency
7.4 y
2,716 days filing → grant
Office actions
2
non-final + final
Responses
2
no RCE
Appeals
1
notices of appeal
Examiner
Steven Snyder
art unit 2184 · TC 2100
Citations: 42 back · 0 forward

See the full prosecution history — every USPTO and applicant action on this file, in order.

Log in to unlock

Documents

Log in to open the documents of this file: the application as filed, every office action and response, the notice of allowance.

Log in to unlock

Chain of title

⤢ drag to zoom20102012201420162018202020222024202620282030Owner 2
Titlehover for detail · click to open

See the full assignment history — every owner this patent has passed through, with recordation dates and reel/frame numbers.

Log in to unlock