Modular processor debug core connection for programmable chip systems

Methods and apparatus are provided for implementing a semiconductor device with a debug core separate from a processor core. The user configurable debug core can be customized to include one or more debug core submodules. Each debug core submodule is generally associated with a particular debug feature such as trace generation, performance counters, or hardware triggers. The debug core can be driven through a variety of interfaces to allow debugging, monitoring, and control of processor operations.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to semiconductor devices. More specifically, the present invention relates to methods and apparatus for implementing a semiconductor device with a debug core separate from a processor core.

2. Description of Related Art

A processor can perform a variety of processing activities, such as executing particular operations associated with a program. In order to determine the validity and efficiency of processor operations, debug mechanisms are often used to analyze and evaluate processor operations.

However, techniques and mechanisms for efficiently implementing various debug mechanisms associated with a processor are limited. In one example, debug mechanisms are integrated with the processor at design time by the processor vendor in a fixed manner. As such, the ability to change the debug mechanisms is substantially limited. Few third-party created debug mechanisms can be incorporated. In general, there is no way for a user to “mix and match” debug features in a deployed system.

It is therefore desirable to provide improved methods and apparatus for optimizing implementation of debug mechanisms, thereby enhancing the ease and flexibility of incorporating a variety of debug features as needed.

SUMMARY OF THE INVENTION

Methods and apparatus are provided for implementing a semiconductor device with a debug core separate from a processor core. The user configurable debug core can be customized to include one or more debug core submodules. Each debug core submodule is generally associated with a particular debug feature such as trace generation, performance counters, or hardware triggers. The debug core can be driven through a variety of interfaces to allow debugging, monitoring, and control of processor operations.

In one aspect, a method for implementing a device is provided. A processor core for implementation on the device is provided. A debug core associated with the processor core is selected. The debug core is operable to allow control and monitoring of the processor core. The debug core and a debug port associated with the processor core are connected. The debug core and the processor core are implemented on the device. In general, the debug core may include multiple debug core submodules. Therefore, the ease of integrating debug features with the processor core on the device can be realized.

In another aspect, a programmable chip is provided. The programmable chip includes a processor core and a debug core. The processor core includes a debug interface. The debug core includes multiple debug core submodules. The debug core is coupled to the processor core and operable to control and monitor the processor core through the debug interface. The debug core is associated with a debug core interface that allows access to the debug core submodules. As such, debug features can be flexibly integrated into the programmable chip as needed.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.

Furthermore, techniques and mechanisms of the present invention will sometimes be described in singular form for clarity. However, it should be noted that some embodiments can include multiple iterations of a technique or multiple instantiations of a mechanism unless noted otherwise. For example, a processor is used in a variety of contexts. However, it will be appreciated that multiple processors can also be used while remaining within the scope of the present invention.

Methods and apparatus are provided for debugging a processor core. Any logic or mechanism used to debug, monitor, and/or control processor operation is referred to herein as a debug core. In one example, a debug core is associated with a processor core on a programmable chip system. Modularizing the debug core allows efficient implementation of various debug features for use with the processor core. In some cases, a modular debug core may include multiple debug core submodules for performing various debug features. In general, both the debug core and the processor core can be part of a system implemented on a device.

According to various embodiments, the processor core (i.e., CPU) and the debug core are handled as separate components (e.g., modules) by using a design tool such as SOPC Builder available from Altera Corporation of San Jose, Calif. Using the design tool, a user can choose various combinations of processor and debug features for implementation in a system. In addition, the user can import new debug features (e.g., via modular debug cores or debug core submodules) as needed (e.g., from third-party vendors). The design tool is typically operable to handle the connections between the debug core, the processor core, and any other component of the system with which the debug core communicates (e.g., an external host).

Systems where the debug logic is fixedly integrated with the CPU logic typically have a fixed set of debug functionalities, thereby limiting the ability to customize the processing system. However, the techniques and mechanisms of the present invention improve the ability to customize a processing system via modular debug logic plug-ins (e.g., modular debug core; debug core submodule). Modular debug logic plug-ins allow user configurable debug logic to be added to a CPU so that, for example, third parties could provide enhanced debug logic (e.g., as intellectual property or IP blocks) which could be added to the CPU “in the field” as required by a particular user application. The debug core can be driven using a variety of interfaces such as a JTAG interface.

FIG. 1Ais a diagrammatic representation showing one example of a system100on a device having a debug mechanism106integrated in a fixed manner. The device can either be an application-specific integrated chip (ASIC), a field programmable gate array (FPGA), an application-specific standard product (ASSP), or another suitable semiconductor device. As shown, system100includes a processor core102having a variety of integrated components. These components may include memory104, registers108, control logic110, and communication access node112(e.g., a Joint Test Action Group (JTAG) interface/node). Each component is generally interconnected in such a manner that debug mechanism106can debug processor core102.

For instance, debug mechanism106may be integrated in memory104so that it can be accessed by control logic110to debug processor core102. The results from debugging processor core102may be stored in registers108, which can be accessed by a user via communication access node112. In any case, debug mechanism106is fixed so that changes to debug mechanism106are limited. As such, the debug features are limited to whatever is initially provided by debug mechanism106. In one example, the debug mechanism106may provide only a limited set of hardware triggers, preventing a user from customizing a set of hardware triggers to meet particular needs. In another example, the debug mechanism106may be able to measure processor performance but may not be able to measure processor performance to a fine enough degree of precision.

FIG. 1Bis a diagrammatic representation showing one example of a system120on a device that can use the techniques and mechanisms of the present invention. As shown, system120includes a processor core122. Processor core122includes a standard control interface134, which may be used to connect to debug mechanism126. Standard control interface134is operable to receive any suitable number of debug mechanisms126. Since debug mechanism126is a separate component (e.g., modular debug core; debug core submodule), which is not fixedly integrated with processor core122, debug mechanism126may be interchanged with another debug mechanism126or modified with a set of debug features as needed (e.g., “in the field”). A communication access node132is provided in system120to allow access to at least a portion of debug mechanism126and processor core122.

FIG. 2is a diagrammatic representation of a debug system with a modular debug core204on a device202according to various embodiments of the present invention. In addition to debug core204, the debug system may include any suitable number of components, such as a JTAG master206and a memory208, to debug a processor core210(e.g., Nios II CPU available from Altera Corporation of San Jose, Calif.). Each component, including processor core210, can be handled separately in configuring the debug system. Each component is generally selectable and customizable/parameterizable by the user. Further, the component may be readily available as an IP block from a library of components.

The debug system can allow users to control and observe processor core execution of instructions. The debug system may include both software and hardware components. According to a specific embodiment, the software components include a debug monitor. The debug monitor provides the ability to read and write memory, read and write CPU registers, and control the operation of debug core204. The hardware component may include JTAG master206and debug core204. The software components may run on a host computer.

In general, the software components of the debug system can be implemented together with a design tool. The design tool may be used to facilitate implementation of a system, including the debug system, on a device. For instance, interconnects212for connecting the various system components can be automatically or manually performed with the use of the design tool. Typically, the components can be interconnected via corresponding interfaces/ports214. Some interfaces/ports correspond to master interfaces/ports whereas other interfaces/ports correspond to slave interfaces/ports. There can also be interfaces/ports available for interconnecting to other components of another device. The type of interfaces/ports (e.g., Avalon interface available from Altera Corporation of San Jose, Calif.) used may depend on the application. The debug system can allow the user to download applications, manage breakpoints, single-step code, display variable values, and perform other debug functions. The debug system can also provide build management and/or project management.

JTAG master206can connect to a JTAG hub in the ASIC or FPGA and can have an Avalon master interface. JTAG master206provides JTAG access to the registers in debug core204. On the other hand, debug core204is operable to debug (e.g., break/interrupt) processor core210under various conditions and to record, compress, and/or store execution traces. Generally, debug core204can provide any suitable debug feature for the application. Some example features are the ability to break the CPU; single-step the CPU; reset the CPU and/or the entire SOPC Builder system; provide JTAG access to debug core registers; provide JTAG access to debug RAM; provide instruction triggers; provide data triggers; provide external triggers; provide multi-level triggers; provide instruction and data trace; facilitate on-chip or off-chip trace storage; and provide performance counters.

FIG. 3is a diagrammatic representation of a system300with a modular debug core302having multiple debug core submodules304(i.e.,304a-f) in a device according to various embodiments of the present invention. Debug core302can be coupled to a JTAG master310, a processor core314, and any other associated system component312(e.g.,312a,312b). Interconnects306may be used to interconnect (e.g., via corresponding interfaces/ports308) debug core302, debug core submodules304, JTAG master310, processor core314, and any other associated system component312. Interconnecting the components may be done manually (e.g., via a user) or automatically (e.g., via a design tool). As shown, interfaces/ports308may include an Avalon master interface (M), an Avalon slave interface (S), a debug interface (D), a trace interface (T), and an event interface (E). Interfaces/ports308can be configured based on the functionality of the associated system component. For instance, a master interface can be configured for a master component (e.g., processor core314) whereas a slave interface can be configured for a slave component (e.g., debug core302).

According to a specific embodiment, debug core302has two Avalon slave interfaces308: a debug slave and a system slave. The debug slave normally connects to JTAG master310, but may connect to any component with an Avalon master interface. The system slave typically connects to the instruction and data masters of processor core314(e.g., Nios II CPU available from Altera Corporation of San Jose, Calif.). The debug and system slaves can be independent interfaces.

In general, debug core302include several debug core submodules304with one or more memory locations accessible to the debug slave or system slave interfaces. Each of these submodules304may have one or more Avalon slave interfaces used to access these memory locations. Debug core302is operable to combine these Avalon slave interfaces together to create the debug slave and the system slave interfaces.

Debug Core302may include any suitable number of debug core submodules304. For example, debug core302may include a monitor RAM submodule304a, a control submodule304b, a trigger submodule304c, a performance counter submodule304d, a trace compression submodule304e, and an off-chip trace submodule304f. In general, any of the debug core submodules304may be included or omitted from debug core302. That is, some debug core submodules304are optional. However, in some instances depending on the application, a debug core submodule (e.g., monitor RAM submodule304a; control submodule304b) can be configured to be always included in debug core302. As such, debug core302can be changed to include or omit certain debug core submodules304, thereby increasing the flexibility to adapt to a users preference or application. For example, certain debug core submodules304can be omitted entirely or replaced with a third-party version.

Any logic or mechanism associated with debug core302that stores debug instructions and/or data is referred to herein as a monitor RAM submodule. According to a specific embodiment, monitor RAM submodule304astores instructions and/or data for the debug monitor. Monitor RAM submodule304ais generally present in a system. Monitor RAM submodule304acan be a 256×32 true dual-port synchronous RAM. As shown inFIG. 3, one port is connected to the Avalon debug slave interface308and the other to the Avalon system slave interface308. Both ports may be configured to have registered inputs and unregistered outputs. The system slave interface308may be used to write to monitor RAM submodule304aupon any suitable condition, such as when an Avalon input signal called “debugaccess” is true. This signal can be driven by processor core314and is true while in debug mode.

Next, control submodule304bis generally responsible for breaking, single-stepping, and/or resetting processor core314. Any logic or mechanism associated with debug core302that can control processor core314is referred to herein as a control submodule. According to a specific embodiment, control submodule304bincludes logic that is present when debugging is to be performed. As shown, control submodule304bmay have one Avalon slave port connected to the debug slave interface308and another Avalon slave port connected to the system slave interface308. Typically, all associated registers are accessible to the debug slave interface. Further, registers required by monitor RAM submodule304bto communicate with the host are accessible to the system slave interface. In some cases, registers can only be written when the Avalon input signal called “debugaccess” is true.

Control submodule304bcan break/interrupt processor core314under many situations. For example, the breaking/interrupting can occur under a pause execution (asynchronous), an instruction trigger (synchronous), a data trigger (asynchronous due to skid), or an external signal (asynchronous) situation. When control submodule304bbreaks processor core314, it may assert a break request signal (brk_req) and hold it until processor core314drives the break acknowledge signal (brk_ack) height for a certain duration (e.g., one cycle).

Processor core314may include a debug mode bit when the debug facility is present. It can be set to true when processor core314accepts a break and then set to false when processor core314successfully executes a BRET instruction. The value of this bit can be provided to control submodule304bfrom processor core314. It can also be used to determine when the debug monitor code is active.

When debug is present, processor core314can include an output signal to its data masters called “debugaccess”. This signal can be set to true when processor core314is in debug mode and false otherwise. It can be used to enable write access to the debug monitor RAM304aas well as any on-chip memory components that were configured as ROMs. The first use prevents accidental writes to the monitor RAM304awhen processor core314is not in debug mode. The second use allows downloads of new ROM contents during development.

Control submodule304bmay also include a debug IENABLE register analogous to a CPU IENABLE register. The debug IENABLE register output is generally provided to processor core314. Processor core314logically ANDs the debug IENABLE register with its own CPU IENABLE register. The debug IENABLE register can be used by the debug system to control which interrupts are allowed during debug operations. In general, interrupts are disabled when single-stepping processor core314. The size of the debug IENABLE register can be computed by processor core314and provided to control submodule304b. Processor core314can also provide a 32-bit constant mask to force unused interrupt bits to zero, thereby reducing logic element usage.

Control submodule304bmay be operable to drive a single-step signal to processor core314. Processor core314may observe the value of this signal when exiting debug mode. If the value is set, processor core314may enter debug mode again. If an interrupt is pending and not masked by the debug IENABLE register, the processor core can execute a first instruction of the exception handler.

In general, control submodule304bincludes one or more static configuration registers accessible to the Avalon debug port. These can be read-only registers that include information about what debug core facilities are present. The host can query these registers to determine the configuration of debug core302. The contents of these registers can include items such as the number of instruction triggers, off-chip traces, performance monitors, etc., present.

Next, a trigger submodule304cmay be operable to implement the instruction, data, and/or external triggers. Any logic or mechanism associated with debug core302that can trigger an event/action responsive to a condition is referred to herein as a trigger submodule. Trigger submodule304cmay be connected to the processor core's debug and event ports. Triggers cause actions/events to occur when their conditions become true. Parameters associated with each trigger's action and condition configuration can be stored in debug slave accessible registers.

There are typically three kinds of triggers: instruction, data, and external. The condition for instruction triggers can be based on an instruction address. The condition for data triggers can be based on a data address and/or data value for load/store instructions. The condition for external triggers can be based on an external trigger input signal. Instruction and data trigger conditions are generally qualified with valid instructions so that any speculatively dispatched instruction is killed/eliminated before completion can be ignored. According to a specific embodiment, triggers are disabled while in debug mode. Further, triggers often operate independently of each other and cannot be combined.

Triggers can be configured with different levels. For instance, four trigger levels can be shared by all of the triggers. A trigger condition may be qualified with one of the four trigger levels. This allows for multi-level triggers so that triggers can be sequenced. A trigger action may cause the trigger level to increment. Typically, the host/user can have the ability to manually set the current trigger level.

Multiple instruction triggers can be supported. For instance, up to 16 instruction triggers can be supported. Each instruction trigger can perform an equality comparison with the CPU instruction address. Similarly, multiple data triggers can be supported. For instance, up to 16 data triggers can be supported. Each data trigger can perform a range comparison with the CPU data address, a masked comparison with the CPU data value, and/or is further qualified by load, store, or load/store.

The range comparison may include an inclusive range with the minimum and maximum values ranging from zero to the largest data address. The range comparison may degenerate to a single data address by setting the minimum and maximum to the desired data address. A masked data comparison may include a logical AND of the CPU data value with a 32-bit mask followed by an equality comparison with the desired data value. If a memory management unit (MMU) is present, virtual addresses can be used.

External triggers are also supported by the present invention. This can be an input signal to debug core302. It can be pulsed high for one cycle to cause a trigger. The trigger can be held until the associated action is completed. If the external trigger is pulsed high before the action completes, it can be ignored.

When a trigger condition is satisfied, any suitable action depending on the application may occur. For example, one or more of the following actions may occur: break the CPU; pulse external trigger-out signal for one cycle; enable trace; disable trace; enable data trace; disable data trace; allow data trace for the associated load/store instruction (e.g., data triggers); trigger trace (e.g., pre-trigger, post-trigger); enable performance counters; disable performance counters; increment the trigger count performance counter; increment trigger level. If multiple triggers may cause conflicting actions (e.g. enable trace and disable trace), a priority scheme may be implemented. For example, the following priority scheme may be enforced (highest to lowest): external trigger, instruction trigger, data trigger. Within each type of trigger, the one with the lowest index is often given priority.

A trigger may include a skid, which can be defined as the maximum number of instructions between the instruction associated with the trigger condition and a trigger action taking effect. Skid is often caused by pipelined CPUs, which don't provide all values used for trigger conditions at the same time. Instruction triggers tend to fire earlier than data triggers because the instruction address is known at the beginning of the pipeline and the sources for the data triggers (data address, store data, and load data) are known later. In general, skid should be minimized (typically it should just be a few instructions in a worst-case scenario). In some cases, zero skid may be required. For example, an instruction trigger may have a zero skid requirement for all actions. For another example, a data trigger may have a zero skid requirement for all actions except breaking the CPU.

Next, performance counter submodule304dgenerally counts CPU events. Any logic or mechanism associated with debug core302that measures the performance of processor core314is referred to herein as a performance counter submodule. According to a specific embodiment, two 40-bit performance counters may be present. Each counter may be configured by a programmable register to count the events. Triggers may be used to enable/disable performance monitors or the user may manually control them via a programmable control register. The events are typically a function of processor core314. Table 1 lists some sample performance counter events.

TABLE 1NameCoresDescriptionCycleAllTrue every cycle performance countersenabled.Instruction executedAllInstruction was successfully retired.Branch mispredicteds/fConditional branch instruction mispredicted.Branch correctlys/fConditional branch instruction correctlypredictedpredicted.I-cache misss/fExecuted instruction missed in I-cache.D-cache load missfCacheable load instruction missed inD-cache.D-cache load hitfCacheable load instruction hit in D-cache.D-cache store missFCacheable store instruction missedin D-cache.D-cache store hitFCacheable store instruction hit in D-cache.Trigger<n>AllTrigger <n> was true.

Next, trace compression submodule304eis generally configured to create a stream of compressed trace information. Any logic or mechanism associated with debug core302that traces processor core314is referred to herein as a trace compression submodule. According to a specific embodiment, trace compression submodule304eis operable to compress the trace information from processor core314and store it in an on-chip FIFO. The FIFO can be either drained by the host via the debug interfaces or by dedicated pins if an off-chip trace submodule304fis present.

The trace can be composed of instruction trace and data trace. Instruction trace generally records enough information for the host to reconstruct the program counter (instruction address) of all executed instructions. Data trace generally records the data address and data value of load/store instructions, the data address of flush instructions, and the data value for rdctl instructions. Compressing trace information often represents a trade-off between compressor complexity and compression rate. The compression scheme should take the characteristics of the target device (e.g., FPGA, ASIC, etc.) into account.

A trace may be composed of a series of frames. A frame is often composed of an array of packets. Packets are encoded so that the decompressor on the host can identify the packet type, contents, and length. Each frame may be decompressed by the host independently of the other frames. The compressed trace may also be encoded so that a new frame may be detected even if the host starts decompressing the trace in the middle of a frame. The host may search the trace for the first new frame and start decompressing the trace. The beginning of a trace frame may include the instruction address of the first instruction traced in that frame. It also may indicate if there is any gap in the trace between the new frame and the previous frame.

A host may have access to the instruction memory image associated with the trace (e.g., by having access to an application ELF file). This can reduce the amount of information that is recorded for an instruction trace since the host can examine the current instruction and use that to help determine the next program counter value. The host may also have access to the system description file. Instructions can be grouped into the following types, as shown in Table 2, based on how to determine the next PC:

Referring to Table 2, the taken/not-taken and trap/no-trap conditions can be mutually exclusive (e.g., where conditional branches are always implemented). As such, a boolean status can share the same bit and the host can differentiate its meaning based on the instruction type.

It should be noted that interrupts are generally recorded with an exception packet. The packet includes a mechanism for determining which instruction was interrupted (because some instructions may have no associated trace packet). This mechanism can be similar to an instruction offset into the frame or the PC of the interrupted instruction.

Support for data trace (data address and data value) can be optionally added (e.g., by the user). When present, data trace can be enabled or disabled by the user via a programmable control register. Data trace and instruction are generally mixed together in the same trace file. When the host decompresses the trace including both instruction and data trace, it is able to identify the instruction associated with the data trace information. Data trace may be enabled or disabled at any time while instruction trace stays active.

Trace compression submodule304emay support multiple debug capture modes. According to a specific embodiment, two capture modes are supported: full-capture and partial-capture. In full-capture mode, trace compression submodule304emay stall processor core314to prevent losing trace information (e.g., prevents FIFO overflows). In partial-capture mode and while data trace is active, trace compression submodule304emay temporarily disable data trace if the FIFO reaches a particular buffer level, for example, 90% full. If data trace is not enabled, trace compression submodule304emay discard all new trace information until the FIFO reaches a particular buffer level, for example, 50% full. However, this may result in gaps in the instruction trace. When trace is started again, a new frame can be generated.

Any suitable trace compression rate may be implemented with the present invention. For instance, instruction trace only compression may achieve a maximum average bandwidth of 9 bits per instruction. Data trace compression may achieve a maximum average bandwidth of 18 bits per instruction. Further, any suitable trace position may be implemented. For instance, the user may specify the amount of trace acquired before the trigger event via a programmable register. Table 3 shows some sample trace trigger positions.

TABLE 3NameDescriptionPre-triggerSaves ⅛thof trace before the trigger and ⅞thafterthe triggerPost-triggerSaves ⅞thof trace before the trigger and ⅛thafterthe triggermanual-triggerUser manually enables/disables trace

Next, off-chip trace submodule304fis generally operable to send compressed trace to an external trace storage device (e.g., via off-chip trace pins312b). Any logic or mechanism associated with debug core302that communicates with an external trace storage device is referred to herein as an off-chip trace submodule. Off-chip trace submodule304fcan accept compressed trace from trace compression submodule304eand send it to an off-chip trace storage device via the trace port. According to a specific embodiment, the trace port includes one output pin for the trace clock, 18 output pins for trace data, and one optional output pin for trigger out. The trace clock may have any suitable range for the application (e.g., from 20 MHz to 133.33 MHz). The off-chip trace storage device may record the value of the trace data on every clock cycle. Off-chip trace submodule304fmay be operable to skip over any empty portion in the trace compression FIFO if present. In another specific embodiment, off-chip trace submodule304fis compatible with the FS/2 trace capture pod and/or the Lauderbach trace capture pod, which are pods commonly known to persons skilled in the art.

FIG. 4is a process flow diagram showing the implementation of a device with a modular debug core and a processor core. At402, a processor core is provided. At404, a debug core is selected. In one example, the debug core is parameterizable by the user. At406, a debug core submodule can also be selected. Here, any number of debug core submodules can be added or removed. At408, the debug core and processor core are connected. In one example, the connections are made manually by a user. In another example, the connections can be made automatically according to a predetermined manner. At410, the debug core and processor core are implemented on the device.

It should be noted that althoughFIG. 4is used to describe one example of implementing a device with a modular debug core and a processor core, many other examples and configurations are possible. Furthermore, any part of the diagram can be modified or repeated to fit the particular application but are not described here for clarity. For example, the entire process flow diagram can be repeated for multiple debug cores and processor cores.

Although the techniques and mechanisms of the present invention or applicable to a variety of different processors including general purpose processors, video accelerators, cryptography accelerators, digital signal processors, microcontrollers, etc., the techniques and mechanisms of the present invention or particularly applicable to soft core processors on programmable chips and programmable chip systems.

FIG. 5is a diagrammatic representation showing one example of a system on a programmable chip that can be used to implement the techniques of the present invention. The system includes peripheral devices and peripheral interfaces. Peripheral devices and peripheral interfaces are herein referred to as components. The system on a programmable chip includes a processor core501and an Ethernet component503as well as peripheral components UART511, PIO513, timer515, and data memory517. In some examples, the Ethernet component503is instead a debug core, a Digital Signal Processing (DSP) core, a cryptography accelerator, or a video processor. It should be noted that the system can include both on-chip memory517and off-chip memory. In one example, the data memory517can support variable latency or fixed latency access. The components are interconnected using an interconnection fabric507. Any mechanism or logic for connecting components in a system is referred to herein as an interconnection fabric. In one example, the interconnection fabric is a bus. In another example, the interconnection fabric is a secondary side arbitration fabric.

The programmable chip uses different types of resources that can be interchangeably used in different allocations to implement the system on a programmable chip. In one example, the programmable chip uses logic elements for implementing each of the various components on the programmable chip.

Logic elements typically can be implemented using components such as antifuses, static RAM, and EPROMS. Any mechanism on a programmable chip that performs an operation on a given number of input lines to provide one or more outputs based on information programmed is herein referred to as a logic element. Some logic elements are implemented as combinations of look up tables and switches for performing Boolean operations on input lines. In one example, a logic element includes a 16-bit SRAM lookup table (LUT) that can implement an arbitrary 4-input logic function, circuitry that forms a fast carry chain and a fast cascade chain, a register and preset/reset logic for the register.

The techniques and mechanisms of the present invention allow the implementation of a system on a programmable chip from a high-level language program. In one example, variable latency and fixed latency can be supported on a system using a conventional bus architecture.

A system bus typically has a set width (e.g. 64 bits, 128 bits) and allows only one primary component to actively use the bus at any one time. In conventional systems, only one primary component can access any one of the given secondary components at any given time. Multiple primary components accessing secondary components in a manner that would cause data bit collisions if performed on the same data lines is referred to herein as accessing secondary components at the same time.

In one example, an Ethernet component is accessing a secondary PIO. While the Ethernet component is accessing the secondary PIO, a processor can not access an SDRAM through a peripheral interface even if both the primary streaming output device and the peripheral interface are available.

According to various embodiments of the present invention, it is recognized that a bus is no longer required in certain applications such as system on a chip, system on a programmable chip, and other computer system implementations. A device such as a programmable logic device (PLD) or a field programmable gate array (FPGA) using a hardware descriptor language (HDL) is herein referred to as a programmable chip or a programmable device. Instead of implementing complicated bus sharing schemes using mechanisms such as splitting, the bus itself can be eliminated to improve system performance.

According to specific embodiments, it is recognized that primary components and secondary components need not be routed through a construct such as a bus. By not routing signals through a bus, a streaming output device can be implemented in a much more efficient manner. The conventional data and address lines that make up the bus are no longer the resource in contention. Instead, secondary components are resources in contention, as the number of physical lines connected to each secondary component in a system can be fixed. Furthermore, by not using a bus, interconnection flexibility is enhanced. For example, an Ethernet component can be allocated a variety of ports for directly accessing a memory and the only resource in contention would be the memory.

Consequently, a system bus arbitrator associated with all the secondary components in a computer system is no longer needed. Instead, secondary components themselves that may be accessed by more than one primary component are assigned individual secondary side arbitrators. An arbitrator that corresponds to a specific secondary component accessible by more than one primary component is referred to herein as a secondary side arbitrator. In one embodiment, there is a secondary side arbitrator for each secondary component in a computer system. In other embodiments, there is a secondary side arbitrator for selected secondary components in a system. The techniques of the present invention recognize that Ethernet component support for high-level language programs can be more efficiently and effectively provided in a system by using secondary side arbitration.

FIG. 6is a diagrammatic representation showing one example of a system using secondary side arbitration, sometimes referred to as slave side arbitration, simultaneous multiple primary components, or simultaneous multiple masters. A system using individual arbitrators that correspond to individual secondary components accessible by more than one primary component is referred to herein as a secondary side arbitration system. The secondary side arbitration system no longer requires a bus or a system bus arbitrator that prevents a second primary component from accessing a second secondary component when a first primary component is accessing a first secondary component. According to various embodiments, a secondary component such as peripheral interface625is associated with a secondary side arbitrator651. However, secondary components UART621and PIO623are not associated with any arbitrator. In one example, secondary component UART621and secondary PIO623can only be accessed by primary CPU613and not by primary Ethernet device615. A secondary memory component625, however, can be accessed by both primary CPU613and primary Ethernet device615.

According to various embodiments, a secondary side arbitrator651allows a first secondary component in a system to be accessed by a first primary component at the same time a second secondary component in the system is accessed by a second primary component. For example, peripheral interface625can be accessed by primary Ethernet615through secondary side arbitrator651at the same time, secondary UART621is accessed by primary CPU613.

By allowing a CPU to access a secondary component at the same time another primary component such as a streaming output device or an Ethernet component is accessing memory, bus bottlenecks can be reduced. By using the simultaneous multiple primary component architecture, more direct connections between components can also be supported.

FIG. 7is a diagrammatic representation showing implementation of a system on a programmable chip. An input stage701receives selection information typically from a user for logic such as a processor core as well as other components such as a modular debug core/debug core submodule to be implemented on an electronic device. In one example, the input received is in the form of a high-level language program. A generator program705creates a logic description and provides the logic description along with other customized logic to any of a variety of synthesis tools, place and route programs, and logic configuration tools to allow a logic description to be implemented on an electronic device.

In one example, an input stage701often allows selection and parameterization of components to be used on an electronic device. The input stage701also allows configuration of variable or fixed latency support. In some examples, components provided to an input stage include intellectual property functions, megafunctions, and intellectual property cores. The input stage701may be a graphical user interface using wizards for allowing efficient or convenient entry of information. The input stage may also be a text interface or a program reading a data file such as a spreadsheet, database table, or schematic to acquire selection information. The input stage701produces an output including information about the various modules selected.

In typical implementations, the generator program705can identify the selections and generate a logic description with information for implementing the various modules. The generator program705can be a Perl script creating HDL files such as Verilog, Abel, VHDL, and AHDL files from the module information entered by a user. In one example, the generator program identifies a portion of a high-level language program to accelerate. The other code is left for execution on a processor core. According to various embodiments, the generator program705identifies pointers and provides ports for each pointer. One tool with generator program capabilities is System on a Programmable Chip (SOPC) Builder available from Altera Corporation of San Jose, Calif. The generator program705also provides information to a synthesis tool707to allow HDL files to be automatically synthesized. In some examples, a logic description is provided directly by a designer. Hookups between various components selected by a user are also interconnected by a generator program. Some of the available synthesis tools are Leonardo Spectrum, available from Mentor Graphics Corporation of Wilsonville, Oreg. and Synplify available from Synplicity Corporation of Sunnyvale, Calif. The HDL files may include technology specific code readable only by a synthesis tool. The HDL files at this point may also be passed to a simulation tool.

As will be appreciated by one of skill in the art, the input stage701, generator program705, and synthesis tool707can be separate programs. The interface between the separate programs can be a database file, a log, or simply messages transmitted between the programs. For example, instead of writing a file to storage, the input stage701can send messages directly to the generator program705to allow the generator program to create a logic description703. Similarly, the generator program can provide information directly to the synthesis tool instead of writing HDL files. Similarly, input stage701, generator program705, and synthesis tool707can be integrated into a single program.

A user may select various modules and an integrated program can then take the user selections and output a logic description in the form of a synthesized netlist without intermediate files. Any mechanism for depicting the logic to be implemented on an electronic device is referred to herein as a logic description. According to various embodiments, a logic description is an HDL file such as a VHDL, Abel, AHDL, or Verilog file. A logic description may be in various stages of processing between the user selection of components and parameters to the final configuration of the device. According to other embodiments, a logic description is a synthesized netlist such as an Electronic Design Interchange Format Input File (EDF file). An EDF file is one example of a synthesized netlist file that can be output by the synthesis tool707.

A synthesis tool707can take HDL files and output EDF files. Tools for synthesis allow the implementation of the logic design on an electronic device. Some of the available synthesis tools are Leonardo Spectrum, available from Mentor Graphics Corporation of Wilsonville, Oreg. and Synplify available from Synplicity Corporation of Sunnyvale, Calif. Various synthesized netlist formats will be appreciated by one of skill in the art.

A verification stage713typically follows the synthesis stage707. The verification stage checks the accuracy of the design to ensure that an intermediate or final design realizes the expected requirements. A verification stage typically includes simulation tools and timing analysis tools. Tools for simulation allow the application of inputs and the observation of outputs without having to implement a physical device. Simulation tools provide designers with cost effective and efficient mechanisms for both functional and timing verification of a design. Functional verification involves the circuit's logical operation independent of timing considerations. Parameters such as gate delays are disregarded.

Timing verification involves the analysis of the design's operation with timing delays. Setup, hold, and other timing requirements for sequential devices such as flip-flops are confirmed. Some available simulation tools include Synopsys VCS, VSS, and Scirocco, available from Synopsys Corporation of Sunnyvale, Calif. and Cadence NC-Verilog and NC-VHDL available from Cadence Design Systems of San Jose, Calif. After the verification stage713, the synthesized netlist file can be provided to physical design tools719including place and route and configuration tools. A place and route tool typically locates logic cells on specific logic elements of a target hardware device and connects wires between the inputs and outputs of the various logic elements in accordance with logic required to implement an electronic design. The device can also be physically tested at723.

For programmable logic devices, a programmable logic configuration stage can take the output of the place and route tool to program the logic device with the user selected and parameterized modules. According to various embodiments, the place and route tool and the logic configuration stage are provided in the Quartus Development Tool, available from Altera Corporation of San Jose, Calif. As will be appreciated by one of skill in the art, a variety of synthesis, place and route, and programmable logic configuration tools can be tested using various techniques of the present invention.

As noted above, different stages and programs can be integrated in a variety of manners. According to one embodiment, the input stage701, the generator program705, the synthesis tool707, the verification tools713, and physical design tools719are integrated into a single program. The various stages are automatically run and transparent to a user. The program can receive the user selected modules, generate a logic description depicting logic for implementing the various selected modules, and implement the electronic device. As will be appreciated by one of skill in the art, HDL files and EDF files are mere examples of a logic description. Other file formats as well as internal program representations are other examples of a logic description.

FIG. 8illustrates a typical computer system that can be used to implement a programmable chip. The computer system800includes any number of processors802(also referred to as central processing units, or CPUs) that are coupled to devices including memory806(typically a random access memory, or “RAM”), memory804(typically a read only memory, or “ROM”). The processors802can be configured to generate a test sequences for any designated processor. As is well known in the art, memory804acts to transfer data and instructions uni-directionally to the CPU and memory806is used typically to transfer data and instructions in a bi-directional manner.

Both of these memory devices may include any suitable type of the computer-readable media described above. A mass storage device808is also coupled bi-directionally to CPU802and provides additional data storage capacity and may include any of the computer-readable media described above. The mass storage device808may be used to store programs, data and the like and is typically a secondary storage medium such as a hard disk that is slower than memory. The mass storage device808can be used to hold a library or database of prepackaged logic or intellectual property functions (e.g., modular debug core; debug core submodule), as well as information on generating particular configurations. It will be appreciated that the information retained within the mass storage device808, may, in appropriate cases, be incorporated in standard fashion as part of memory806as virtual memory. A specific mass storage device such as a CD-ROM814may also pass data uni-directionally to the CPU.

CPU802is also coupled to an interface810that includes one or more input/output devices such as such as video monitors, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, or other well-known input devices such as, of course, other computers. Finally, CPU802optionally may be coupled to a computer or telecommunications network using a network connection as shown generally at812. With such a network connection, it is contemplated that the CPU might receive information from the network, or might output information to the network in the course of performing the above-described method steps. It should be noted that the system800may also be associated with devices for transferring completed designs onto a programmable chip. The above-described devices and materials will be familiar to those of skill in the computer hardware and software arts.

The hardware elements described above may be configured (usually temporarily) to act as multiple software modules for performing the operations of this invention. For example, instructions for running a generator program, input stage (e.g., a wizard), and/or compiler may be stored on mass storage device808or814and executed on CPU802in conjunction with primary memory806.

One of the many advantages that the present invention provides is that the user (e.g., system designer) has access to, and control over, a potentially richer set of debug features. The user can also choose debug features instead of being limited to the set from the factory (e.g., processor vendor). Further, debugging the processor can be performed using different configurations. For instance, debugging the processor can be done via a communication access node (e.g., JTAG node) or any complementary component (e.g., Avalon master) such as another processor on the same die. These advantages allow more flexible debug, monitoring, and control systems to assist system developments on a device.

While the invention has been particularly shown and described with reference to specific embodiments thereof, it will be understood by those skilled in the art that changes in the form and details of the disclosed embodiments may be made without departing from the spirit or scope of the invention. For example, embodiments of the present invention may be employed with a variety of primary and secondary components and should not be restricted to the ones mentioned above. It is therefore intended that the invention be interpreted to include all variations and equivalents that fall within the true spirit and scope of the present invention.