Squash: move into Gateway, get Scope from initial

[klin02]

No description provided.

[poemonsense]

Why do we need this? Different functionalities are intentionally implemented in different classes and files.

[klin02]

Why do we need this? Different functionalities are intentionally implemented in different classes and files.

There are two main reasons:

1. The two classes repeatedly implement fly-lines and share wb_int, leading to additional cost.
2. When replay feature is added, additional data paths and control condition are required between instances of Gateway and Squash in DifftestModule. Maybe it will bring more difficulties~

[poemonsense]

If they are moved to Gateway, why do we need squash.scala? We should think of how the code is organized and why we need the classes.

Some simple questions to get started:

• If all are moved to Gateway, and gateway supports squash, then what does Squash.scala implement?
• If gateway supports squash and squash supports squash, what are their differences?
• How to define the classes such that every class only implements their own functionalities and they can be transparent to each other. If we mix different things, the software code will not be extensible and scalable, such as the case you explained in reason 2

I'm just trying to make sure you have good understanding of the code structure. If you have clear answers for questions like those, I think it's OK to merge this PR. I'm not opposed to putting squash in gateway if the replay does need it.

[klin02]

Perhaps the code structure can be described as follows:

• Difftest will simply pass difftest signals to Gateway, and the processing of signals is transparent to it.
• Gateway will handles signals as its config. It may use Squash to squash them and DPIC (or some other style) to pass them. But how signals is squashed or passed is transparent to Gateway. In a way, Gateway may be regared as wrapper of Squash.
• It's true that some control logic is mixed in Gateway, like step, enable, dut_pos..., may be we can wrap them into another class.

Then the code flow will act as follows:

1. When difftest signals come in Gateway, it will be gatherd (by fly-lines) and fixed first. (Maybe use another module to wrapper the fix logic, I prepare to optimize it later so it can work for multi-core.)
2. Fixed signals come in Squash (if needed), output squashed or replayed data.
3. Processed signals come to a control module to get step, dut_pos, enable ...
4. Finally data along with control signals will use DPIC to transfer.

Now we expose code of 1 and 3 directly in GatewayEndpoint because it seems more flexible when code is frequently changed. I will make the code structure more clearly when relevant functions are accomplished~~

[poemonsense]

You can add the above explanation in code comments. In the future, you and others could understand it more clearly.

Make it a common practice as you develop the code. Will benefit your engineering much.