SEMINAR/STUDY LISTS

We have a series of unsupervised learning studies, called SCI (Seminars/Studies for CAMEL members' Interest). Currently, we focus on three research and study topics: i) computer architecture, ii) operating systems and iii) diverse application-level studies. You can review the list below:

Seminar/Study ListsView study list →

Note that to check all slides and videos we are performing for the studies, you need to join first

While computer architecture and operating-systems SCIs cover top-notch research topics published in tier-1 conferences in computer science and engineering, application-level studies deal with different topics per semester (e.g., recommendation systems, AI, machine learning, and FPGA topics to date). If you are not familiar with CS/CE style publications and research activities, please refer to the "conference list" reported KIISE or the following "for new students" section. To join each seminar or study group, please contact mj@camelab.org.

INTRODUCTION TO TOP-TIER CONFERENCES

Computer architecture and systems research is strongly conference-driven. In these fields, premier international conferences are primary venues for presenting mature, archival research results. A top-tier conference is not defined only by a low acceptance rate or a ranking label. It is a flagship research community with rigorous expert review and high expectations for originality, technical depth, experimental evidence, clarity, and potential impact.

CAMEL's research and publication culture

CAMEL primarily targets top-tier international conferences for its main research outcomes. This does not mean that every project must be submitted to the same venue, or that publications at specialized conferences and journals have no value. It means that we choose important problems and conduct the design, implementation, evaluation, and writing at the standard expected by leading international research communities.

This point is important for prospective students because laboratories can differ substantially even when they use similar terms such as computer architecture, systems, AI hardware, or memory. Each laboratory has its own research scope, publication culture, project pace, and expectations. Students should understand these differences before joining rather than discovering them only after beginning a degree. At CAMEL, members are expected to pursue ambitious, internationally competitive systems research and to improve the work through repeated design, prototyping, evaluation, discussion, and writing.

Primary venues studied and targeted by CAMEL

Our work commonly connects computer architecture, operating systems, storage, interconnects, and AI infrastructure. CAMEL members therefore regularly study recent papers from the following flagship venues:

• Computer architecture: ISCA, MICRO, ASPLOS, and HPCA
• Operating and computer systems: OSDI, SOSP, and USENIX ATC
• Storage and large-scale computing: FAST and SC

The appropriate venue depends on the central contribution and intended research community. A CXL controller, an operating-system mechanism, a datacenter SSD design, and an AI accelerator may require different evaluation methods and may belong at different venues. Venue selection should therefore follow research fit and contribution—not convenience or name alone. Because scopes, schedules, and review policies change, students should always consult the official call for papers and recent proceedings.

Current conference reference: KIISE CS Top Conference World Ranking The attached KIISE conference-list PDF is retained as a legacy reference rather than a current ranking.

What top-tier-oriented research requires

Students are not expected to arrive with a top-tier publication already. They are, however, expected to be willing to learn and practice the research process required to produce work at that level:

• Read recent papers and understand the closest prior work, assumptions, and unresolved limitations.
• Clearly explain why the problem matters, what is genuinely new, and which research community will benefit.
• Build a complete and credible implementation, simulator, prototype, or system rather than relying only on an initial idea.
• Evaluate against strong and relevant baselines using appropriate workloads, metrics, sensitivity studies, ablations, and analysis of limitations.
• Keep experiments reproducible and follow research ethics in data collection, attribution, implementation, and reporting.
• Repeatedly improve technical writing, figures, presentations, and responses to critical feedback.

For CAMEL's research, students should first build familiarity with three connected areas:

• Computer architecture and memory systems
• Operating systems and storage systems
• Distributed, parallel, and AI infrastructure systems

Students coming from circuits, VLSI, devices, or other lower-level fields do not need to master the entire computing stack at once. Start by reading recent papers in the areas above, identify the hardware/software interfaces involved, and expand toward the tools and methods introduced in the next section. What matters most at the beginning is a willingness to learn the full research context and to develop work that can withstand careful international peer review.

Back to Table of Contents

RESEARCH PREPARATION FOR PROSPECTIVE STUDENTS

This public guide is for undergraduate students and prospective members who are considering research in computer architecture and systems. You do not need to master every topic or tool below before contacting CAMEL or joining a research project. The goal is to understand what systems research looks like, build a useful foundation, and identify the areas you would like to learn more deeply.

Research tools change over time, and each project requires a different combination. Learning one specific simulator is therefore less important than learning how to ask a clear question, understand the system being studied, select an appropriate method, and produce evidence that others can verify.

CORE FOUNDATIONS

The following foundations make it much easier to begin architecture and systems research:

• Programming: Become comfortable with C or C++ for understanding low-level behavior and with Python for automation, data processing, and rapid experimentation. Basic data structures, memory management, debugging, and concurrency are especially useful.
• Linux and operating systems: Learn the command line, files and permissions, processes and threads, virtual memory, synchronization, storage I/O, and basic networking. The Linux kernel documentation is a long-term reference; beginners can start with coursework and small experiments rather than reading it from beginning to end.
• Computer architecture: Understand instructions, pipelines, caches, virtual memory, memory hierarchy, storage, accelerators, and interconnects well enough to explain where time, energy, and data movement occur.
• Version control and collaboration: Use Git to record changes, compare versions, review code, and collaborate without losing experimental history.
• Technical communication: Practice reading papers, summarizing the research question and contribution, drawing clear figures, and explaining results in writing and presentations.

A student does not need equal strength in every area. Hardware-oriented students may begin with digital design and RTL, while software-oriented students may begin with Linux, kernels, compilers, or storage. CAMEL projects often connect these layers, so members gradually learn to communicate across the hardware/software boundary.

HOW A SYSTEMS RESEARCH PROJECT USUALLY WORKS

A typical project is an iterative process rather than a straight path from an idea to a paper:

1. Understand the context. Read recent work, reproduce key observations when possible, and identify what current systems cannot do well.
2. Form a testable question. State the hypothesis, expected benefit, assumptions, and conditions under which the idea may fail.
3. Choose a method. Depending on the question, use analytical modeling, simulation, emulation, kernel or application software, RTL/FPGA prototypes, real hardware measurements, or a combination of them.
4. Build and validate. Check correctness before optimizing performance. Compare intermediate results with known behavior, specifications, or real systems.
5. Evaluate fairly. Select representative workloads, strong baselines, meaningful metrics, sensitivity studies, and ablations. Report limitations and unexpected results rather than hiding them.
6. Make the work reproducible. Record source versions, configurations, commands, datasets, random seeds, and machine details. Automate repeated experiments and preserve raw results.
7. Communicate and iterate. Improve the problem statement, implementation, evaluation, figures, and writing through discussion and critical feedback.

For top-tier-oriented research, using a sophisticated tool is not itself a contribution. The contribution comes from an important question, a sound idea, a credible implementation, and evidence strong enough to support the claims.

TOOL CATEGORIES YOU MAY ENCOUNTER

Instead of treating the following as a required checklist, view them as examples of tool categories used in modern CAMEL projects:

• Simulation and emulation: gem5 for detailed architecture studies and QEMU for machine and device emulation. Storage-focused projects may use CAMEL's prototype and open-source tools, including SimpleSSD, or extend a project-specific model.
• RTL and hardware prototyping: Hardware projects may use SystemVerilog, Verilator, FPGA platforms, logic analyzers, and vendor design tools to validate controllers, accelerators, and interconnects.
• System implementation and measurement: Projects may modify Linux kernels or device drivers, build microbenchmarks, use performance counters and tracing, and evaluate real SSDs, GPUs, CXL devices, or servers. Storage projects may also use tools such as fio or SPDK when appropriate.
• Automation and data analysis: Python, shell scripts, structured configuration files, statistics, and plotting tools help turn repeated experiments into traceable results and reduce manual errors.
• Reproducible environments: Build scripts, dependency records, virtual machines, and containers such as Docker help collaborators reproduce the same software environment.

Do not install or learn all of these tools at once. Start with the smallest toolchain needed for a concrete question, understand its assumptions and limitations, and add complexity only when the research requires it.

A PRACTICAL STARTING PATH

An undergraduate student who wants to explore CAMEL research can begin with the following sequence:

1. Complete introductory programming, computer architecture, and operating-systems coursework, or review equivalent open materials.
2. Become comfortable working in Linux and keeping a small project in Git.
3. Select one recent CAMEL or top-tier paper and write a one-page summary of its problem, key idea, methodology, and limitations.
4. Reproduce a small tutorial or experiment using one relevant tool, then change one parameter and explain the result with a simple plot.
5. Read the code and documentation behind the result instead of treating the tool as a black box.
6. Attend a seminar, internship, URP, or individual research project and discuss which layer—hardware, architecture, systems software, storage, or AI infrastructure—interests you most.

What CAMEL looks for at this stage is not a long list of tools or prior publications. Curiosity, programming discipline, intellectual honesty, persistence with difficult technical problems, and the ability to explain what you observed are more important. Students can then develop deeper expertise through guided projects and collaboration with other lab members.

Back to Table of Contents