C952 Computer Architecture, catalog number ICSC 3120, is the three-CU architecture course in the WGU School of Technology, introducing the organisation and architecture of modern computer systems across performance, processor design, memory, input and output, and multiprocessors. It is the course that explains why the code you write behaves the way it does on real hardware, and the reason students find it unfamiliar is that every other computing course lets you treat the machine as an abstraction.
Performance reasoning is the thread through every topic
Architecture looks like five separate subjects and is really one question asked five times: where does the time go, and what can be done about it. Processor design answers it with instruction-level parallelism and pipelining. Memory answers it with a hierarchy that exploits locality. Input and output answers it by overlapping transfer with computation. Multiprocessors answer it by doing several things at once and paying a coordination cost for the privilege. Students who see the common question stop trying to memorise five sets of facts.
The quantitative habit is what the course is really building. Performance claims in architecture are always relative and always conditional: faster at what, under which workload, at what cost in power or area. A statement that a change made the system faster is not an architecture answer. A statement that it reduced average memory access time by a specific factor for a workload with a given hit rate, while adding latency to the miss path, is one. Rubric aspects in this subject are usually written to require that second form.
Instruction set architecture is the other idea worth isolating early, because it is the contract between everything above it and everything below. The set of instructions a processor exposes is what compilers target and what hardware implements, and holding it as an interface rather than as a list explains why the same program can run on machines with completely different internal designs. Students who grasp that separation find the processor material much easier, because pipelining, superscalar execution and out-of-order completion are all implementation strategies behind a fixed promise.
The memory hierarchy deserves special mention because it is where most students first meet the gap between the abstract machine and the real one. Caches exist because memory is slow relative to processors, and they work only because programs exhibit locality. Once that is held, a great deal of otherwise mysterious performance behaviour becomes predictable, including why two loops that compute the same result can differ in speed by an order of magnitude.
Reading the scoring detail before you plan
WGU keeps the scoring detail for each course inside your Course of Study rather than in the public catalog. Read it before planning, because School of Technology courses may be measured by a submitted performance assessment, by a proctored objective assessment, or by both, and quantitative architecture problems reward different preparation from written analysis.
Under a performance assessment, each aspect is scored independently against a three-point scale and a 2 in each one passes the task. Nothing averages, so a strong cache analysis does not compensate for an aspect on parallel systems that stayed descriptive. Head each section with the rubric's own noun.
The word budget, worked. Take six scored aspects and directions asking for roughly 1,900 words. Reserve 150 for framing and 130 for a close, leaving 1,620, about 270 words per aspect. In architecture, budget 60 words for the mechanism, 120 for the quantitative analysis with the calculation shown, 50 for the trade-off it imposes, and 40 for the workload dependence. Aspects that return are usually those describing a mechanism with no numbers and no trade-off, because architecture without trade-offs is marketing.
If your course carries a proctored component, work problems rather than reread chapters. Performance equations, cache calculations and speedup arithmetic are the testable content and they reward practice specifically.
A structure that fits an architecture analysis
Follow the task directions where they set a format. Where they leave room, this arrangement makes architecture reasoning visible and quantitative.
| Section | What belongs in it | How it gets scored |
|---|---|---|
| Workload | What the system is being asked to do, with the characteristics that matter | Frames every performance claim; unstated workload makes claims meaningless |
| Mechanism | The architectural feature under discussion and how it operates | Scored for accuracy and for operating detail rather than for naming |
| Quantitative analysis | The performance calculation with the formula, the inputs and the result | The highest-value section; visible working is required |
| Trade-off | What the feature costs in complexity, power, area or worst-case behaviour | Scored directly in most architecture rubrics and thin in most drafts |
| Workload dependence | Where the feature helps most and where it helps least or hurts | Scored for engineering judgement |
| Sources | Architecture references and any specification data used, APA formatted | Scored wherever citation is named |
Keep the units straight in every calculation. Cycles, seconds, instructions and bytes are all in play at once in this subject, and the discipline of carrying units through a performance calculation catches more errors than any other single habit.
Evidence craft in architecture writing
Architecture evidence is quantitative and comparative, so precision about conditions is the whole game.
- Show the performance calculation, including the formula and the inputs, rather than the result alone.
- State the workload and the assumptions behind every performance claim, including hit rates, instruction mixes and any stated frequency.
- Express improvements as ratios with the baseline named, since a speedup with no baseline is uninterpretable.
- Respect the limits of parallel speedup. The serial fraction of a workload bounds what any number of processors can achieve, and ignoring it produces claims that cannot be true.
- Cite specification or vendor data where you use real numbers, in APA, with the document and version.
- Write explanations in your own words; standard architecture descriptions are heavily reproduced text and WGU runs submissions through a similarity check.
The habit that most improves architecture writing is naming the workload where the feature fails. A cache helps until the working set exceeds it; a deep pipeline helps until branches become unpredictable; more cores help until coordination dominates. Naming the failure point is what turns a description into engineering analysis.
What separates Competent from a return
WGU records work as Competent or Not Competent, with no letter grades and no ordinary grade point average. Aspects are judged individually, so returns identify specific sections.
- Every scored aspect has a heading using the rubric's own wording.
- Every performance claim is quantified with a stated baseline and workload.
- Every calculation shows its formula, inputs and units.
- Every mechanism discussed has its trade-off named.
- Every parallel claim respects the bound imposed by the serial portion of the work.
Performance assessment work can be revised and resubmitted without a grade penalty, so a return costs time rather than standing. Terms are six months at a flat rate, so closing more courses inside a term is the only lever on effective cost per course.
Where a proctored objective assessment applies, the boundary is absolute. Proctored assessments are yours to sit. We prepare with worked performance problems, cache calculations and an honest readiness verdict, and we never ask for portal credentials.
Six mistakes students make in C952
- Describing mechanisms without numbers. Architecture is a quantitative discipline and unquantified claims cannot be scored as analysis.
- Claiming performance without a baseline. Faster than what, on which workload, is the whole content of the claim.
- Ignoring trade-offs. Every architectural feature costs something, and a submission that presents only benefits reads as uncritical.
- Overstating parallel speedup. The serial fraction bounds the result, and predictions that exceed it are wrong on their face.
- Mixing units. Cycles, seconds, instructions and bytes appear together constantly and unit discipline is what catches errors.
- Treating memory as flat. The hierarchy is the reason real performance departs from instruction counts.
- Leaving input, output and multiprocessors to the end. Both are coordination problems rather than speed problems, and a few worked examples in each removes most of the difficulty.
How support works on this course
Send your Course of Study for C952 with any rubric and task directions. What comes back is a quantification pass that puts formulas, inputs and baselines into claims that were written descriptively, trade-off statements for every mechanism you discuss, worked cache and performance problems in the areas where you are thin, and an aspect-mapped draft with units carried through every calculation.
Input and output and the multiprocessor material are the two areas students most often leave until last and most often underestimate. Both are about coordination rather than raw speed: a device transferring data while the processor works on something else, or several processors sharing memory without corrupting each other's view of it. The reasoning in both cases is about overlap and about what has to be synchronised, and a few worked examples in each area removes most of the difficulty.
Architecture pays off beyond the three competency units. Understanding the memory hierarchy and the cost of coordination changes how you write code for the rest of your career, which is why this course sits where it does on a computer science plan.
Questions students ask about C952
Is C952 the same course as ICSC 3120?
How much mathematics does C952 involve?
Will you sit a proctored assessment for me?
Describing architecture without the numbers?
Send your Course of Study and any rubric. You get a quantification pass, trade-off statements for every mechanism, worked performance problems, and aspect-mapped drafting.
Where C952 sits in WGU's programs
The July 2026 catalog places this code in 3 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.