Neural-Networks-on-Silicon: A Curated Reading List for AI Chip Architecture

What problem a paper index solves that a search engine does not

Academic search returns what matches your query. It does not tell you which papers a working researcher in the field considers load-bearing. This repository is the second thing. Fengbin Tu, an Assistant Professor and Associate Director of the Institute of Integrated Circuits and Systems at The Hong Kong University of Science and Technology, states in the README that his main research interest is AI chip and system, and that he is collecting works on related topics. The list began as a collection of neural network accelerator papers and, per the description, has widened into a selection of research on deep learning and computer architecture. That widening matters: the entries are no longer only accelerator silicon but also the architecture work that surrounds it. The audience is narrow and identifiable. A PhD student entering the field, a hardware engineer moving from general-purpose CPU work into accelerator design, or a reviewer preparing to evaluate a submission all benefit from a pre-filtered venue list. Someone looking for a library to import does not.

How the repository is organised: venue and year, not topic

The structure is a two-level index. The top level is conference venue, and within each venue the entries are grouped by year. The table of contents walks from 2014 to 2026 and names the venues present in each year: ASPLOS, MICRO, ISCA, FPGA, DAC, ISSCC, HPCA, ICCAD, DATE, ASPDAC, VLSI, FPL, FCCM, HotChips and ASSCC. A reader looking for the lineage of a specific idea can follow one venue down the years, or scan one year across venues. The entries themselves are plain list items. Some carry a bolded title and an institution list in parentheses, such as DianNao at 2014 ASPLOS attributed to CAS and Inria, or Eyeriss at 2016 ISSCC attributed to MIT and NVIDIA. Others carry no bold and no institution. This inconsistency is not cosmetic: it changes how quickly you can triage the list. The bolded entries read as the author's own emphasis, and the unbolded ones read as a sweep of the proceedings. There is no topic tag, no keyword field, and no cross-reference between a paper and its successors, so tracing an idea from DianNao forward is manual work.

The annotations, and what they do and do not tell you

Most entries have no annotation at all. A minority carry a short note or a set of bullet points. The DeepBurning entry under 2016 DAC is the clearest example: it lists a hardware generator described as basic building blocks for neural networks plus an address generation unit in RTL, a compiler covering dynamic control flow and data layout in memory, and a closing remark that the authors simply report their framework and describe some stages. That last line is a judgement, not a summary, and it is the kind of thing a search engine will never surface. It is also the exception. For the overwhelming majority of papers you get a title and, sometimes, an institution. Treat the annotations as editorial signals about which papers the author engaged with closely, not as coverage. If you need to know what a paper contributes, the index will not tell you. It tells you that the paper exists, where it was published, and roughly who wrote it.

There is nothing to install, and that is the point

There is no build step, no package manifest, no configuration file and no command to run. The primary language field is unknown and no licence is declared in the repository metadata. What you do is clone or browse the repository and read the README, which is the entire artefact. If you want it locally, the default branch is master, so the usual clone followed by a checkout of master is the whole workflow. If you want to contribute, the README says welcome to join, and the mechanism is a pull request against that README adding a paper under the relevant venue and year heading. That is the entire contribution model. There is no schema to validate against, no CI described, and no template for how an entry should be formatted, which explains why some entries are bolded with institutions and others are bare titles. The low ceremony is what keeps the list maintainable by one person. It is also what keeps it inconsistent.

Where the list is thin, and where it will mislead you

The year coverage is uneven and the README shows it plainly. 2016 is dense: ISSCC, ISCA, MICRO, HPCA, DAC, FPGA, ICCAD, DATE, ASPDAC, VLSI and FPL all appear. By 2022 the venue set has narrowed to ISSCC, ISCA, MICRO, HPCA, ASPLOS and HotChips. For 2026 only ISSCC and HPCA are listed. You can read that two ways. It may reflect a deliberate narrowing toward the venues the author considers most relevant, or it may reflect the list being a work in progress for recent years, since the last push is dated 2026-03-30 and conference proceedings for a given year are not all published at the same time. The material here does not let you distinguish between those explanations, and you should not assume either. A second limitation is selection bias by construction. The README calls it a collection of papers that interest me. That is an honest description and also a warning: this is one researcher's filter, weighted toward the accelerator and architecture venues he publishes in, and it will not represent the field evenly. A third is that there is no licence file, so the terms under which the compilation itself can be reused are unstated. The papers are separately copyrighted by their publishers; the index is a list of citations, which is a different thing from the papers.

What to use instead when you need to run something

If your actual need is to simulate an accelerator, this repository is the wrong tool and no amount of reading it will change that. The relevant alternatives are the open simulator and benchmark projects that implement the ideas these papers describe. On the simulator side, Timeloop and its accompanying Accelergy energy model let you describe a spatial accelerator and get a mapped schedule with energy estimates; the approach is analytical modelling of a design space rather than a curated reading list. On the workload side, MLPerf Inference defines a benchmark suite with rules for submission and reproducibility, and its results are published as measured numbers rather than as paper titles. The difference in approach is stark. This repository answers where do I start reading. A simulator answers what happens if I arrange the MAC array this way. A benchmark suite answers how does my implementation compare under agreed conditions. None of them substitutes for the others, and the failure mode is treating a reading list as if it were a specification.

Maintenance cost and what the licence situation actually is

The maintenance burden here is editorial, not technical. Adding a year means adding a table-of-contents line and one heading per venue, then appending entries. That scales linearly and stays cheap. The cost that does grow is verification: as the list ages, links rot, paper titles get revised between preprint and proceedings versions, and the bolded emphasis the author applied in 2016 may no longer reflect how the field regards a paper. Nothing in the repository automates any of that. On licensing, there is no declared licence in the metadata supplied, which means you cannot assume any particular reuse right for the compilation. The individual papers are published by their respective venues and carry their own terms. Citing a paper you found here is normal academic practice and does not depend on this repository at all; redistributing the README as your own list is a different question and one you would need to resolve with the author. This is a description of what the metadata shows, not legal advice.

Editorial conclusion

Adopt this list if you are starting a literature review on AI accelerators and want a venue-organised spine to work from, or if you are preparing for a qualifying exam and need to know which ISSCC and ISCA papers define the field. Do not adopt it if you need a runnable simulator, a benchmark harness, or a maintained dataset with API stability: there is no code, no release, and no licence file in the repository. Verify three things before you rely on it. First, check whether the last push date reflects genuine additions or only a metadata touch. Second, open two or three of the linked venues and confirm the entries you care about are present for the most recent years, since 2026 lists only ISSCC and HPCA. Third, treat the short annotations as the author's selection rather than a neutral summary, and go to the papers themselves for anything you plan to cite.

Official sources

1. fengbintu/Neural-Networks-on-Silicon on GitHub
2. Issues
3. README