| Previous journal: | Next journal: |
|---|---|
| 0056-2020-08-09.md | 0058-2020-08-11.md |
GT's QSPIFLASHSIM uses an approach where it assumes a hard-coded clock (10nS period, so 100MHz) and derives its other critical timing from that.
- It assumes that each tick (i.e. each call to
operator()) will advance the clock by some known amount automatically. - An example is where it defines
tPPto be 12 microseconds (i.e. 12×100 "ticks" of 10nS each, hence 12,000nS or 12µS), then uses it to start a programming cycle, and finally counts it down within each tick.
Alternatives would be to:
- Either: Use the approach above but instead of hard-coding the module to use 10nS increments, base all times on discrete nanoseconds and allow (re)definition of timing by the caller. Then time deltas could be based on the defined length of a single tick (rather than just 1 'unit'). It just means there might be cases where a timer ends up going below 0 rather than hitting exactly 0.
- OR: Let the caller tell us what the current time is (in nS), and we'll just hard-code all our known times in nanoseconds. That way, the caller can call us just when it wants to.
Another thing about the GT 'SIM' modules is that their operator() returns its result. This is pretty flexible because the result can be captured in a variable by the caller, then torn apart by the caller as it sees fit, and potentially fed into other module-under-test inputs. Alternatively, the operator() could be a tick() function that assigns its outputs via function call arguments (i.e. by-ref?). Maybe that's a bad idea, though, in case it doesn't properly get treated as an "assignment" handler, and also prevents us from easily manipulating the "wiring".
t02a now uses a skeleton SimROM class to simulate the ROM hardware. I will extend that soon to simulate timing.