spec7_write_design: harmonize led_pps name

added processing system io

updated general cores for axi_wb fix

# Conflicts:
#	ip_cores/general-cores

changed pci_rst_n to perst_n, linked to wrc.bin

linked to wrc.bin

linked to wrc.bin

corrected .bram file

corrected .bram file

corrected .bram file

moved axi related files to general-cores (branch: pascal-axi)

Fixed some bugs

updated general cores with right manifest

Updated tcl, added wrapper

WRITE design clk_10m_p/n_i input is ibufds plus add XDC property for non-clock capable pins.

added BMM_INFO_DESIGN property to XDC

Add prsnt_m2c_l_i input pin. Prevents prsnt_m2c_l line to be influenced by a non driven FPGA pin after configuration done.
(it did break the JTAG chain after configuration.

New statistics data was added to diag/snmp array. To ensure
backward-comapatibity between MIB versions, this new data needs
to be added at the end. Thus, now we need to inject dbg_word and
magic number in the middle.

The diag_ver is not bumped because the change is backward-compatible.

This was previously implemented but got lost when the fixed latency
instreamers was re-done. The idea is to compensate for internal
delays, so that the tx/rx_valid signals are as close to the
configured latency as possible.

Corrected simulation accordingly: the simulation also corrected for
delays.

For simulation, the second duration is forced to be shorter with the
generic g_sim_cycle_counter_range. The problem is that the tai/cycle
counters are still counting full seconds, the trick was done only
when calculating the delay in function f_cycles_counter_range()
in fixed_latency_ts_match.vhd. This worked fine unless the timestamps
were at the edge of the "shorter" second and fixed-latency was
enabled. In such case, it happened that the time of releasing
data from streamers was calcualted for TAI+1, yet TAI was incremented
after the "true" second, not the shorter one. So, the simulation
was stuck.

To avoid messing up with PPS gen in which the tai/cycles are
generated, for simulation the tai/cycle values are overriden
in the xwr_streamer top module. This "alternative" TAI time
is counted from the time when time_valid goes HIGH.

This solution should work for streamers, provided that tx/rx
instances have the time_valid go HIGH more or less at the same time.
As far as I can tell, this is usually the case.