Modification to TCL build script were needed.
Move duplicated code to a common file where the changes apply once.

The WR TX path in the endpoint reset disparity to minus.
To do this, it needs the disparity from the transceiver.
Previously the disparity had to be delayed a few cycles.
At some point this must have changed.

Now the core goes back to sending
  0x17C = K28_5 minus
as commas after packet boundaries.

The new-fangled RX clock shifting alignment in arria5 does not work.
It is only able to shift 2 clock bits, leaving one (unreported) bit
that gets slipped, resulting in a randomly occuring +800ps offset.

Using manual bit alignment mode requires that we enable it using
the avalon-mm management interface, however. Hence the random values
we hard-wire into the phy_mgmt_* lines. Without writing a '1' to
rx_enapatternalign (bit 0) in register 0x85 (pcs8g_rx_wa_control)
you will only get a link 1/10th of the time as it does not align.

oops.

This allievates the need to shift the ref clock domain for arria2.

arria2 phy: allow asynchronous pll reset
arria5 phy: don't bother with a free clock

These paths are not covered by the SDC clock files, because they
can interact between outputs of the same PLL.

Allow any order (to/downto) of the natural_vector generic inputs.
Document and prove correctness of the phase trap.

phase: start-up assuming we need to shift => no glitchy resets

It will be useful in the future to control phases of all output clocks.
Split out and improve this functionality, and then gut the butis aligner.
There is also now no need to hard-ware phase offsets in the ref PLL.

Now that we reset all PLLs together, the transceiver lock must
not depend on clk_sys running.

The problems with white rabbit reliability on arria5 were due to
two problems, both due to the WR reference fPLL.

Problem #1:

The fPLLs do not lock properly at power-on. They often ended up with
outputs that are aligned to the VCO but not the input clock. This
caused problems because it destroys the ref-tx phase relationship.

This is solved by including a core to reset the PLLs.

Problem #2:

Both the fPLL and transceiver introduce delay relative to the WR input
clock. Unfortunately, timequest does NOT analysis this phase relationship.
In order to ensure a safe transfer between the domains, we must:
a) logic lock the clk_tx and clk_ref registers beside each other
b) find the right fPLL offset to feed the clk_tx

I tried every nanosecond phase offset and recorded the results of WR below:
   0 xoxoooooxxxxxx
1000 ................
2000 ................
3000 ...............
4000 ............
5000 .x.xx.xx.x..xxx
6000 xxxxxxxxxxxxxxx
7000 xxxxxxxxxxxxxx

. = successful track
x = sync phase hangs at -4000ps
o = track phase that goes crazy

When outputting multiple clocks from the same PLL, the arria5 does
not appear to maintain their phase relationships in direct mode.
Thus, switch them all to source synchronous to hold the relationship.

Furthermore, the fpga/spi-flash timing requires a -1.5ns offset.
I measure that it works with +9ns, +8ns and fails with +10ns and +7ns.
Thus, I set the flash phase to +8.5ns = -1.5ns.

In the FAIR project, we need to reproduce the BuTiS clock.
It runs at 200MHz and should be aligned to the PPS.
This commit adds a 200MHz clock output from the WR ref PLL.

A small core uses Altera's phase compensation feature to align
the 200MHz rising edge with the PPS, by leveraging a third 25MHz
output signal which can be used to detect the 125-200 relationship.

The final timing model is first available in quartus 13.0sp1