Re-loading checkpoint after write_bitstream

[nelsobe]

It seems that in fuzzer.py:fuzzer() the code is trying to go through and set a single property:value pair on each cell. Doing this minimizes bit pollution caused when other properties are also set on the same cell (you can't separate out the bits).

To do so, the code:

1. Fills the design with tiles of the needed type and then places a single cell of the proper type, and then writes a checkpoint (in the checkpoints directory) of that design.
2. It then moves on and applies a single property:value combination to each cell, incrementing a cell counter as it goes.

For some tile types, however, there are so many properties and values that you run out of cells to apply them to. As such, the code detects this (when calling get_next_count()) and, writes a bitstream for the existing design and then starts a new design so it can continue applying properties to cells.

Except it doesn't start a new design. Rather, it simply (a) resets its cell counter and (b) continues on applying property values starting again with cell C_0. Thus, the properties accumulate, meaning each of the cells in later specimens does not contain just one set property:value combination but rather contain the accumulation of the previous specimens' property:value pairs as well.

It would seem the proper approach would be to reload the checkpoint saved above (with the cells placed onto the tiles but in their default states) before proceeding again after a write_bitstream. The code does not do that. The fix is would trivial: in get_next_count() after calling gen_bitstream() do open_checkpoint() and then disable_drc().

[nelsobe]

The suggested fix is in data_generator.py::get_next_count(). See comment.