when streamers are used in a simulation of top entity, the startup
timer is needed, thought it should be appropriate for the simulation
time. when streamers are simulated alone, the startup timer is
not needed. the added generic allows to set the timer (i.e. override
the default value to zero)

small modifications modified signals names in xwrc_board_spec enity and package to much new WRPC release

32-bit counters would overflow after few hours of btrain traffic.
So, I increased counters to have max 64 bits and configured them
to have 50 bits, which should be sufficient for 50 years of traffic
with 500kHz.

Conflicts:

	modules/wr_streamers/xrtx_streamers_stats.vhd

I removed BTrain-specific debugging from wr_streamers. in that commit
I only updated *.wb file. now comes the update of wb-generated files

this is an hdl part of new (additional) diagnostics for WR PTP Core.
It allows to access diagnostics values through WB registers (e.g. PCI
bus). This is useful for integration of WR with CERN cotrols infrastructure,
such as FESA. It allows the host machine (of SPEC/SVEC/etc) to easily
access information about the health of WR PTP Core.

When frames were sent to close to each other (high frequency), the
timestamp of incoming frame would reset the delay counter of the
previously received frame. This could potentially cause infinite
fixed delay... Now, in such case, the counter is not reseted and
so the following (too closely) frame will be exposed to the user
immediatelly.

Such glitch happened after the autonegotation FSM was in pseudo
AN_ENABLED state caused by synced=LOW (in this state, link_ok is
HIGH). When synced goes HIGH, the FSM enters "proper" AN_ENABLED
state, it drives link_ok LOW.s All in all, this glitch is avoided
then we use delayed synced_d1 to produce the final link_ok_o.
I did it here to avoid any changes to autonegotiation state machine.

sending streamer frames when link is down causes weird behavior:
- the frames are counted as sent, while they are not
- some frames are dropped, depending on PHY implementation
- at startup, the link is reseted by software, so link is up for
  some time, then it goes down, than up again... mess

two additions:
- the dreq_o signal is gated with link_ok_i, so that frames cannot
  be sent when link is down
- startup counter which delays the start of sending frames

- removed unnecessary reference to spec_top in one testbench that
  did not use top
- removed obsolte cfg input signals - use default

the name of the top entity in the wr_streamers folder was missleading
(xwr_transmission). It was recommended to rename, which I did.
Additionally, names of two modules in wr_streamers start with gc_
which could indicate they are general-cores. This is not the case,
moreover the entity names did not have gc_. I removed the gc_

- added DISABLED state to FSM to explicitely sit in DISABLED state
  when the mechanism is not enabled (before it was in reset/ALLOW)
- changed std_logic_vectors to unsigned in number of places, this
  made the code more readable and concise
- defined constants with zero latency (instead of having signal)
- added delay to latency calculation so that the latency introduced
  by gc_sync_ffs is accounted for

There was a number of processes that did something depending on a
state. The asynch-process was replaced with "when" statement.
The stuff done in separate synchronous processes are now done in
the same process as FSM

private package, or fabric_pkg in case of fabric sink/source

commit

this generics sets the operation mode of streamers (rx-only, tx-only
or rx_and_tx)

streamer.

- when instantiating wr_transmission (top streamers), it is now possible
  to define that only RX or only TX or both (RX and TX) streamers are used.
  this is to save resources and still use all the other goodies added to
  the streamers and also wrpc/wr-cores (this configuration will be
  propagated to the top of board entity in the next commit. So, the
  user can still use the board (and even ref-design) and instantiate
  only reception (or tranmission) to save resources
- the statistics entity is now split into 3 entities (top, rx, tx)

- BTrain requires to set more parameters than just tx/rx_data_width
- it would be messy to have all the parameters in the top of each board
- I made a record with all tx/rx parameters and replaced the currently
  existing two generics that reach the top of svec/spec/vfchd_board
  with these record.
- Now, all the tx/rx parameters of tx/rx streamers can be set when
  using the "board" top
- Default constant is used with default values (defined ine streamers pkg)
- it is planed to have constant with default parameters for BTrain as well
  in the BTrain package. Possibly, the same policy can be used for other
  applications

- made the tx and rx streamer symmetric in terms of seeting the
  buffer size, now both have proper generics
- added proper descriptions
- added sanity checks for generics
- set (hopefully) more sensible defults

- corrected name of f_dbg_word_starting_at_byte (byte->bit)
- expanded description of g_rx_data_width
- added descriptions of g_rx_data_width and g_tx_data_width the info
  that they are required to be multiples of 16 bits

bin: modfied wrpc-sw for simulations to not perform SDB discovery, in order to speed-up simulation time

built from wrpc-sw using commit:
91ab423 sim main: disable discovery of peripherals via SDB to speed-up the simulation.

rx/tx streamers generics/ports

Set RCV_TERM_VTTRX to false. Now Rx Termination mode 2 is selected and active, as advised in ug386 for GbE

Tunable SFP WRT-SFPPT015SC caused trouble in the SPEC (Link Down). The receive amplitude is only 920 mVpp.
The Spartan6 PHY settings for Rx Termination were not conform any mode (see Xilinx UG386 Table 4-4 to 4-7).