Final version of the testbench.Fully working with 6 different tests: flush, timeout, tx_thr, tx_max words, fxd latency, drop frames.

Changed data type block so it no longer has wrd_cnt, first and last_wrd fields. Not really required anymore

Working testbench. Runs 5 tests. Bug: does not cope with multiple block frames. only single block frames.

there were some unfortunate sequences of characters that made to fail
the compliation of the auto-generated altex documention. These
unfortunate sequences were removed

Work in progress. Rx tb will soon be deleted. Tx tb will be main one. Tx features testing working. Rx features must be fixed and also features relating to link quality (delay, drop frames, etx)

added setting of new generics, in particular important is the simulation
generic.

added wait at the beginning of simulation, otherwise the drivers attempts
to write data to tx_streamer when the reset is still LOW (there is 100us
wait before reset is asserted HIGH).

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.