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..

Fix to commit
7618967d:"modules/swcore: bugfix, make sure that IB does not request
force_free before start page is written to the LL"
Making sure that start page was written to the LL is not enough. It has
to be valid, which means either have a pointer to the next page or EOF.

Another bug in the Input Block. I'm broken.. Was this module seriously
tested during development ?!

This time we have registers for in_pck_sof_reg and new_pck_first_page to
cover (hopefully) all the strange cases when SOF and EOF/ERR may be
rised (just before LL FSM goes to WRITE, LL FSM in SOF/EOF_ON_WR etc.)

modules/swcore: prevent TR FSM from being stuck in DROP when new SOF comes before LL EOF write of a previous frame

It happened that we had only one clock cycle break between EOF and SOF
for a new frame. In that case LL FSM was not detecting SOF and was not
going to SOF_ON_WR (SOF was already _low_ when LL FSM was in S_WRITE).
If the new frame was decided to be droped after writing only the first
data word to MPM, then we were never storing the new start page to the
FSM and a force_free request was masked. Transfer FSM was not getting
ffree_done and everything was stucked in DROP forever.

The fix adds in_pck_sof_d0 signal to let LL FSM go to S_SOF_ON_WR in the
situation described above. It also keeps _high_ state of
new_pck_first_page signal so that the new start page could be written to
LL when LL FSM goes to IDLE from S_SOF_ON_WR.

When pck_err occurred on the edge of two memory pages, status word with error
bit was written as the first word in the already used page. LL FSM was doing two
writes one after another with the same page addr, EOF and size 64 (first write)
and 1 (second write). Then if one of the Output Blocks was unlucky enough to
read LL between two writes, it was getting size = 64, while at the very
beginning of this page, status word was stored. This was making OB hang, not
freeing more pages and making the whole SWcore hang due to lack of free memory
pages.

LL FSM was writing twice
The fix is made of two parts:
 1. We must set mpm_dlast<='1' only for one cycle. If in_pck_eof happens right
    after in_pck_ere, then finish_rcv_pck is high for 2 cycles. When (as a
    result) mpm_dlast is high for 2 cycles, we go to unnecessary S_EOF_ON_WR in
    LL_FSM (on first mpm_dlast_d0 LL FSM goes to S_WRITE and if ll_wr_done_i
    does not come immediately after, we go to EOF_ON_WR).

2. If we got an error in received frame, RCV FSM stays in S_RCV_DATA for 2 last
   clock cycles and it was writing twice the last word into the MPM. This
   becomes a problem when ERR occurs at the edge of two pages. Then last word is
   written as 64-th word, then MPM requests next page, but does not get it and
   the same word is written to 1st position of the same page. The size for EOF
   is 64, and we end up having status word with error in the middle of our frame
   for Output Block. Thus we don't validate MPM write when we're for the 2nd
   time in S_RCV_DATA on pck_error.

If LL FSM goes through S_SOF_ON_WR state we have to ensure that the state of
mpm_dlast and new_pck_first_page is properly stored for S_IDLE state.
Otherwise, if RCV FSM is in S_RCV_DATA only for one cycle (and then goes to
DROP) we were not storing the start page with _valid_ and _eof_ high.