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.

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