Document architectural basics

[sy2002]

Gentlemen, it is great, that @MJoergen is diving into the hardware architecture / FPGA architecture of QNICE-FGA from scratch, because this shows us, where we might want to add those findings to something like doc/fpga-architecture.md some day. This issue is for now meant to collect links to questions and/or explanations to simplify finding points to document. I guess such a document would be a living thing and never really "complete" but I guess "something is always better than nothing" :-) I would start with that in V1.7 or later and if you want to contribute to this document already pre V1.7 or post V1.7 feel free ;-)

Here are the first links in the collection:

• WAIT_FOR_DATA explanations: CPU bus functional test #55 (comment)

• Explanation of how to build a device that is capable of interrupts (Daisy Chains) and how the situation of colliding requests need to be handled to avoid race conditions: Daisy chain leads to Combinatorial Loop warning and no bitstream #48 (comment) and Timer Interrupt Hardware: Check Edge Cases and Stability #45 and Simulation: Timer Interrupt Hardware: Test Daisy Chaining Edge Case #42

• Maybe also explanation of how to avoid combinatorial loops when building a Daisy Chained interrupt device:
  Daisy chain leads to Combinatorial Loop warning and no bitstream #48

• Mention how devices should behave on the bus (maybe after we have done Tristate Refactoring #30)

• Maybe additionally some best practices to avoid critical warnings in future: Refactor code to remove critical warnings in Vivado #34

P.S.: There is a really nice free online timing diagram generator where in 1min you can make professionally looking timing diagrams and which we can use, just in case our doc/fpga-architecture.md needs some timing diagrams: https://wavedrom.com/ We might have a doc/fpga-architecture subfolder where we store the Wavedrom JSON source files for diagrams (for later easy editing) as well as the PNGs of the digrams that we want to embedd into the MD file.

P.S.2: We might want to make sure that the document in issue #15 is more on the assembler programming side, and the to-be-made document of this issue is more on the hardware side of things.

[sy2002]

How MMIO devices should behave, e.g. as written here

   -- Merge data outputs from all devices into a single data input to the CPU.
   -- This requires that all devices output 0's when not selected.

Also here is another explanation which is useful for this architecture document.