Many tools allow electronic designs to be assembled, simulated, debugged, and translated into hardware. In particular this can be done in the environments known as high level modeling systems (HLMS). In a HLMS the high level design (i.e., the design as the user sees it) can be quite different from what is implemented in hardware. In particular, clocks often are only implicit in a high level design, but must be explicit in hardware. Users need to control how implicit high level clocks are translated into explicit hardware clocks.
A high level design can be thought of as a collection of blocks that communicate with one another through signals. Signals are discrete time varying sequences of values. Some signals change rapidly, while others change less often.
In hardware, blocks become processing elements such as counters, registers, logic gates, etc., and signals become electrical impulses that travel between processing elements. In a synchronous electronic design, rates and offsets of signals are governed by clocks. The obvious way to implement a design having, for example, three signal rates is to use three separate hardware clocks. Another approach is to use a single clock together with three clock enables varying at appropriate rates.
These approaches can be mixed. For example, two of the three rates might be realized with a single clock but different enables, while the third might be realized with a second clock. A clock domain is the portion of a hardware design that is controlled by a single clock (but possibly different enables). Thus, a three rate design that has one clock but three enables has a single domain. If, instead, the design is implemented with the mixed approach described above, there are two domains.
The choice of domains is a detail of implementation. It is irrelevant in the high level view but essential when trying to minimize cost and maximize speed of hardware. For example, suppose a three rate design is to be realized in a field programmable gate array (FPGA) that is able to support at most two clock domains. The design can be implemented in the device, but only by using one or two domains. If using two domains is faster and requires no extra hardware, the user is likely to request two. Further cost and speed improvements may be possible by dictating which of the rates should be realized in the same domain. The problem, therefore, is to enable a user to have a high level and abstract view of a design, but nevertheless be able to specify how clock domains should be used in hardware.
Accordingly, there is a need for a method of and apparatus for specifying clock domains in a system level design tool.
Accordingly, there is a need for a method of and apparatus for verifying the correctness of a clock domain specification.
USPTO Backgrounds
USPTO Backgrounds