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.

modules/swcore: bugfix, make sure that IB does not request force_free before start page is written to the LL

If frame is to be dropped while only one page (start page) was used, then the
start page is written two times to the Linked List. First time, with the inter
page as the next_page; second time with next_page set to 0, and EOF high. That's
because inter page was not yet used so only start_page should be force-freed.
It happened once in a while that IB was requesting force_free of a received
frame before start_page with EOF was written to the linked list. Therefore
freeing module was making a mess by trying to force free the start_page, then
the inter page (which was not used in fact) and then trying to read next inter
page (which was not there...).
With this commit I try to make sure that start page is always written to the LL
before force-free request goes from IB to the freeing module.

modules/swcore: bugfix in allocator, read new free page sooner when there are again some pages available

This one fixes the situation when allocFSM in one of the input blocks requests
usecount set and new allocation (S_PCKSTART_SET_AND_REQ state) while out_nomem
is just before the transition from high to low. In that case arbiter grants
access to this Input Block request (because setting usecount does not require
out_nomem to be '0'). Then, we expect first allocation immediatelly after
out_nomem is 0, but reading next page happens only when out_nomem_d1 is '0'.
That's too late and the same page address was given to two subsequent allocation
requests.
The fix forces q_read aligned to out_nomem_d0 to read earlier next allocation
address. In addition, _done_ for allocation is now generated only if there was a
valid page address read in advance from the memory (to prevent double
allocations of the same page).

The problem occured in swc_page_alloc_ram_bug.vhd when there were no more free
pages (out_nomem_d1='1') and input block was requesting allocation and setting
usecnt (alloc FSM in S_PCKSTART_SET_AND_REQ). The operation was _done_ because
there is always one free page read in advance, prepared to be allocated to a
requesting input block and set usecnt does not depend on out_nomem_d1.
However, reading of the next free page from the memory was done only on
alloc_req, only if there were still some free pages (q_read_p0 <= alloc_req &
!out_nomem_d1).
That means allocator was holding address of the page just allocated to one of
the input blocks, and was giving the same address to the next one requesting
allocation (if in the meantime out_nomem_d1 went to '0').
To fix that I've added one register keeping information if the page read from
the memory was already given to any requestor. If it was then I do _read_ of the
new page imediately after there are some new pages (out_nomem_d1 = '0') so that
it is ready when next time somebody asks.

When it turns out we have to drop frame (e.g. because memory is full) and we get
this information on page boundary, next inter page is already being requested.
However, we do not use previously allocated inter page, that means we lose
previously allocated page forever.
In most of the cases, the conditional statement prevents such situation by
checking mpm_dlast = '0'. But mpm_dlast is delayed by 1 clock cycle, that's why
I added checking for tp_drop. Now, if we get in the same cycle mpm_pg_req and
tp_drop, then we don't make a new inter page request.

In the situation when RCV fsm was dropping the whole frame (no pages were used)
it was not raising force_free request. However, transfer fsm always waits for
force free to be done once it gets to DROP state. This commit adds rp_drop_no_ff
signal which is asserted by RCV fsm when it goes to DROP, but does not request
force free.

Without this fix, when previous frame was whole dropped, transfer fsm was still
in DROP state, while RCV fsm was going to S_IDLE. In that case, RCV fsm saw
tp_drop high and it was doing force_free of a correctly received frame (the one
before dropped frame).
The conditional statement is needed, but it had to be fixed to work according to
description in the comment - i.e. dropping frame when RTU decision is very late.

Fix for the issue 1063. In short, we need to keep in reset clock alignment fifo
in the endpoint (native Virtex-6 FIFO) until GTX is locked and produces rx
clock. That's what Xilinx document _ug363_ says. Otherwise, if this FIFO is not
reset correctly I get strange behavior like asserting empty_o and almost_full_o
in the same time.