Cycle-accurate simulation

[jgottula]

If we ultimately decide to go down the path of cycle-accurate simulation, we'll need to (a) determine how to modify the block/noodle stuff to accommodate this, and (b) determine what constraints this puts on the overall system (could we still get away with multithreading; how to make sure feedback works; can we batch blocks to any extent; etc.).

Replace Block::work with two new functions:

• simPropogate: use registers' outputs to do combinatorial logic
• simClockEdge: load the results of the combinatorial logic into the registers' inputs

Previously, I was thinking that we would have a fast, threaded mode of the scheduler for high level design of blocks, and then a slower, serialized mode for creating test vectors to do verification. Now that cycle-accurate simulation has been brought up, might it make sense to have two versions of Noodles?

• High Level Noodles, which is like the current program; would be threaded and fast, but not cycle- or register-accurate; wouldn't be able to generate 100%-hardware-accurate test vectors. Hopefully the blocks written for High Level Noodles would be reusable in the future because they aren't tied to the hardware implementation.
• Low Level Noodles, which would be a new separate version; would be non-threaded and slow, but cycle- and register-accurate; designed to be able to generate 100%-hardware-accurate test vectors. The blocks written for Low Level Noodles would be more tedious and less likely to be reusable because they are intimately involved in hardware implementation details.

This bifurcation would require writing a High-Level implementation and Low-Level implementation of each block, which sounds like duplication of effort. But it has the advantage of retaining the relative ease of writing and simulating blocks' overall function without worrying about the implementation stuff, while still being able to also do cycle-accurate verification when you want to do that.

Or maybe this would just increase the amount of work you'd have to do, since now you'd have to make sure the High-Level and Low-Level blocks really do the same thing.

Good idea, bad idea?

[bgottula]

Now that I'm further along in the design of a high-speed DSP project, it's becoming more clear that cycle-accurate simulation is not as critical of a priority as I had thought, and in fact it is actually somewhat undesirable from a verification standpoint. I was able to design a very complex multirate filter and the hardware verification was definitely somewhat painful, but not unbearably so. By keeping the software implementation as a straightforward implementation of the original DSP algorithm it can serve as a reliable reference to confirm that the process of refactoring the algorithm to work in hardware did not change the math. In the case of the high-speed multirate filter, hardware constraints required the FPGA engineer to significantly refactor the algorithm to support the required throughput, meet timing, and efficiently utilize DSP slices and RAM. However this refactoring was very complex and introduced a number of bugs which were caught by comparison with the software model which had not undergone such manipulations. I think most of the debugging value of the software model would have been lost had I tried to mimic the hardware too closely.

[bgottula]

Conclusion: We won't directly support cycle-accurate simulation in Noodles.