The symptom of this bug is that about 3% of the time a WR endpoint will
power-up such that it always fails to reach track phase state.  This is
caused by the endpoint dropping the first PTP packet after calibration.

The packet is dropped, because it is misclassified. This happens because
it is possible for the U_match_buffer and fab_pipe in the RX path to
become desynchronized. When this happens, packets receive the classification
of the previous packet. Since calibration is slow, it is virtually assured
that a BOOTP request is seen, leading to the misclassification of the
following PTP packet.

The U_match_buffer can become desynchronized multiple ways, but the one we
saw "in the wild" is due to the lowering of PFCR0 in wrpc-sw during packet
filter configuration.  Due to an unsafe transfer from clk_sys to clk_rx in
ep_packet_filter:p_gen_status, it is possible for the transition of PFCR0 to
cause a glitch that sets done_int high, even though there is no packet being
processed.  This puts an excess class tag into U_match_buffer, which leads
to the mismatch between packets and classes.  This patch fixes the transfer.

Unfortunately, even after this patch, it is my opinion that this code
remains completely unsafe.  The core problem is that desynchronization of
U_match_buffer and fab_pipe is possible at all.  This is a very brittle
design.  One can imagine many scenarios that can lead to this state, after
which point the WR endpoint will never recover.  A simple example: consider
a packet arriving while PFCR0 is switched.  ep_rx_path:mbuf_we can then
pulse twice, once, or never for the packet depending on the race condition
between ematch_done and pfilter_done.  If this happens, the RX path will
remain permanently desynchronized.

The softpll_ng takes in a reset line from the sys clock domain.
It instantiates several dmtd_with_deglitcher FSMs which need reset.

The symptom of this bug is that on 3% of power-ups, some of the
deglitchers will not issue tags, because they power-on into an
undefined FSM state. This is caused by feeding the reset from a
different clock domain, leading to a race condition on release.

There was some code that probably used to solve this issue, whereby
the sys reset was synchronized to the clk_dmtd_i. However, the
softpll_ng instantiates multiple deglitchers, each in a different
domain and thus this single synchronizer chain can not work for all
of the deglitcher instances.

The fix is simple: synchronize the reset for each clock domain.

When using a 1GHz WR-synchronous sample clock to drive LVDS, the
phase between the clock enable and VCO should be -1.5 periods.

There was a bug in the project whereby the altera_phase core was
misconfigured to move the WR ref in relation to the TX clock, while
forgetting to move the LVDS VCO and enable clocks. Now that this
phase shift is applied equally to all PLL outputs, the work around
discovered in commit 34d0a504 is not necessary.

By chance we were always using altera_phase with 3 outputs.
The aligned and sync_rstn matrices were thus square 3x3.

When using more outputs, it became clear the types were wrong and
had set the columns to be rows. No logic was changed; only the shape
of the matrix of signals.

C++ and command-line interface for the TLU.

Tested with modelsim and quartus.

These registers control an eca channel, not a queue.
Fix the definitions so as not to conflict with new registers
that actually DO control an action queue.

Following up the last commit, this adds channel meta-data to the
WB interface of the ECA action queue. This supports software in
determining which queue is connected to which channel.

In a complex design, there are many receiving components connected
to ECA channels. Some of these may have their own WB bus logic. It
is useful to be able to determine which WB slave corresponds to which
ECA channel. This commit adds meta-data that can make the link.

Under higher load of traffic SOF was being detected while main FSM was
not yet done with sending frame. That caused OOB FSM to reset and "tx
timestamp never became available" warnings in WR PTP Core software.

This change is necessary for network control/monitor tool in order to read the GUI command output.
The GUI command output can not be stored into a 1024 bytes fifo.

This branch adds changes needed to unify all the GSI form-factors.