Ensure all inputs are initialized before starting the clocks. This
avoids any problems which might occur due to everything being
initialized at once.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Instead of calculating clock periods based on the desired frequncy,
specify the periods diretly. This silences the following kind of error
caused by floating point rounding:
Unable to accurately represent 8000.000000000001(sec) with the simulator precision of 1e-12
Fixes: d351291 ("Initial commit")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
There were two unused variables; remove them. The wrong type of
assignments were used; fix them.
Fixes: d351291 ("Initial commit")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Without this state, receiving would immediately go low. However, figure
24-11 shows that receiving should go low only after an additional code
group (the second idle) is received.
Fixes: d351291 ("Initial commit")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
When the PMA has no new data for us, idle should be determined based on
raw_bits[11:2]. However, we just calculated that last cycle, so we can
reuse it.
Fixes: d351291 ("Initial commit")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
There's no strict requirement for us to handle linke failures immediately.
The PMA's link timer will ensure the signal stays low, so we don't have to
worry about missing it. This fixes some strange Xs during initialization.
Fixes: d351291 ("Initial commit")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Sean Anderson