8
\$\begingroup\$

I am coming from computer science background and wanting to study process calculus for use in asynchronous circuit design.

So, I am looking around the current practice on asynchronous circuits. There are many articles that say inability to increase clock speed leads to multi-core CPU architecture. However, none really say how the asynchronous coordination between cores is achieved.

I want you to confirm/correct my following assumptions about how current multi-core CPU handles asynchronous coordination:

  1. Each core has separate clock signals, which does not need to be in phase with each other. Otherwise, clock signal distribution problem would not really be solved, would it?
  2. The cores coordinate only on programming level. That is, doing test-and-set on some memory (RAM or register). And not something low-level like hand-shaking protocol using rendezvous circuit.
\$\endgroup\$
  • 1
    \$\begingroup\$ Large single-core CPU's have multiple clocks, used for power reduction. Some clocks are gated, some are dynamically slowed down. Add in another core and of course it has multiple clocks. Easier clock distribution is a side effect, but not the reason there are multiple clocks. \$\endgroup\$ – user3624 Jun 4 '13 at 18:50
  • 2
    \$\begingroup\$ Have a look at this paper on how to cross clock domains between different frequencies: w2.cadence.com/whitepapers/cdc_wp.pdf \$\endgroup\$ – pjc50 Jun 4 '13 at 19:05
  • 1
    \$\begingroup\$ (about clock signal distribution: a buffer tree where all leaf nodes have equal propagation time from the source is the solution. You can build this algorithmically. It's not trivial but it works) \$\endgroup\$ – pjc50 Jun 4 '13 at 19:08
  • 1
    \$\begingroup\$ Disadvantages of buffer trees are many: it can consume a majority of the power, and 10-30% of the available area. However, as our startup found, the main problem with asynchronous design is needing to change your entire software toolchain to use it effectively. IC companies are suprisingly conservative, due to the costs of manufacturing and risks of failure. \$\endgroup\$ – pjc50 Jun 4 '13 at 19:34
  • 1
    \$\begingroup\$ @pjc50 ISTR that some grid-layout, message-passing-oriented processor (possibly Tilera's?) had the clock "flow" left-to-right and bottom-to-top, since only nearest neighbors needed to directly communicate (kind of a variety of Globally Asynchronous Locally Synchronous). \$\endgroup\$ – Paul A. Clayton Jun 4 '13 at 23:41
1
\$\begingroup\$

You mix two independent (orthogonal) ideas in digital circuits theory: asynchronous circuits and multi-core processors.

Asynchronous circuits: circuits which have more than one clock, and the clocks are asynchronous (i.e. have non-constant and unpredictable phase relationship).

Some circuits may use two clocks (for example), but one is just a division by 2 of the other. These circuits are not asynchronous because there is known phase relationship between the two clocks, although the frequencies of the clocks are different.

You may have a single core CPU having few asynchronous clocks, and a multi-core CPU with all its cores running on the same clock (the latter is just an imaginary CPU - all real multi-core CPUs have many clocks which consist several mutually-asynchronous clock sets).

Asynchronous circuits is a major topic in digital design. The above explanation is basic.

Multi-core CPUs: few microprocessors (cores) connected in parallel which employ sophisticated hardware and software in order to achieve high performance.

The usual practice is to make the cores as independent as possible in terms of clocks/power/execution/etc. This allows dynamic (at run time) adjustment of CPUs activity (i.e. consumed power) to the actual needs of the system.

My impression is that what you're looking for is an explanation about multi-core CPUs, not asynchronous circuits.

This topic is much, much bigger than anything one can put in the answer.

The answers to your questions, though:

  1. The clocks used by different cores (to my best knowledge) have the same sources (can be more than one: crystal, VCO, ...). Each core (usually) has few mutually-asynchronous clock sets. Each core has dedicated clock gating and throttling logic which allow to turn-off or slow the clock, independently for each core. Again, if you're interested only in algorithmic aspect of cores' parallelism - forget about clocks (for now).
  2. You have just indicated the main aspect of cores' parallelism - how do you run multiple cores in parallel efficiently. This topic is huge, and contains both HW and SW solutions. From HW perspective, cores both modify a common memory and exchange control and status signals with sequencing logic and between themselves. The picture complicates a lot due to existence of caches - I'd suggest that you start from reading on caches, then cache coherency, and only then on cashes in multi-cores systems.

Hope this helps.

\$\endgroup\$
  • \$\begingroup\$ The fact that CPUs have to run at different speed doesn't imply that they have to be asynchronous. Having a window around each clock when signals are guaranteed not to change is extremely useful. Even if two modules have clock rates which are not multiples of each other, it may be useful to have both generated by a device which ensures they never switch too close together. \$\endgroup\$ – supercat Nov 23 '13 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.