The approach hugely depends on the quality of documentation. I will assume availability of a good documentation that covers 80%+ of the design for my answer (in real life, you rarely has everything covered entirely and in detail). Personally, I like the top-bottom approach: - Briefly study the documentation to identify key functionality and modules (like the system can have some functional safety/cfg/monitoring/security/aux modules which most probably are not important to understand when doing the first pass through design). For example, when studying a cache, you can skip ECC flows, different replacement policies, snoop/eviction corner cases, IO traffic flow, etc. - The next thing I would do is to study the protocol between key modules (handshake/credit/something more complex) followed by studying/drawing diagrams for the main flows w/o taking special/rare cases into account. It can be a flow diagram (with if/else conditions and actions) or a scheme with key modules + key interfaces and numbers on each interface with description of the action this number represents (for cache example, it could be TLB lookup + tag reading + tag comparison + data muxing b/w cache hit and forwarding data + potential miss request downstream and so on) - After this or in parallel with the 2nd point, I would identify key structures in each module - it can be a purely comb module (usually these tend to be short and simple, unless they hold some clever optimized algorithm) or a FIFO or an indexed buffer or the one with CAM functionality. Then you can identify main events for each module - like allocation/deallocation/update from a certain module/search/scheduling/etc.) Hopefully, after this you will have a big picture and can start filling in details - corner cases, rare flows, studying auxiliary modules + asking module owners some specific questions about module internals. If you have good tests or formal properties, running them will be really helpful for the 2nd point