This saves some resources (memory in the switching core) as we no longer forward
frames to the endpoints that have no fiber connected.

When high loads of random length traffic was going through the switch, there
were situations that words_total for a new frame was set to
fetch_pg_words(=cur_ll.size) for the previous frame. If fetch_pg_words was a
small number the new frame was reported _done_ soon after it was started in the
OutputBlock. Therefore the rest of the frame was staying in the
async_shrink_fifo making a mess for subsequent frames. The final result was OB
hanging in the frozen_cycle state.

Otherwise, counter gets crazy when watchdog resets the swcore and feeds all the
endpoints and NIC with ack=1.

LVDS was too low for the discrete flip-flop. This was creating spikes on low
half of the signal on some switches.

modules/watchdog: make resetting sequence much longer to be sure we ack everything what is still in the buffers

Conflicts:

	top/scb_18ports/scb_top_synthesis.vhd
	top/scb_8ports/scb_top_synthesis.vhd

Conflicts:

	top/bare_top/scb_top_sim.vhd

modules/swcore: one more bugfix preventing the transfer FSM to be stuck forever in S_DROP on high traffic load

This time only one port was getting stuck (transfer FSM stuck in S_DROP)
once in a while during the 18-port 100% load snake test. In situations
when setting the usecnt was taking some longer time, it may happen that
RCV_FSM was requesting force_free and force_free was done before TP_FSM
went to S_DROP. In that case I register the mmu_force_free_done_i signal
in S_SET_USECNT so that it can be used later in S_DROP (if needed).

That's how it should be done. Otherwise we always have the race
condition. Especially on high traffic rate on many ports LL fsm has to
wait sometimes few clock cycles for the write request to be served. If
a force_free request was already generated, freeing of pages may always
go ahead of LL stored pages resulting in free fsm stuck in R_NEXT.

When IB in the swcore was stuck waiting for the start page allocation, port
fsm in the RTU was stuck in S_FINAL_MASK. If one new request managed to
arrive before endpoint got rtu_full signal, the response for that
request was lost. The result was misaligmnet of the rtu decisions with
frames in the IB of the swcore.

It happened for few frame sizes on 8p gateware with reduced page number,
that SOF was ariving right after EOF (when RCV FSM was in the S_IDLE)
state. This commit adds one register in RCV FSM to store any SOF that
occured before S_IDLE->S_READY transition of RCV_FSM.

The result of this bug was not swcore hang, but missing one SOF, so in
the end we had always one more RTU response than SOFs. Thus every frame
was being forwarded based on the RTU decision for a previous frame..