This uses a new data structure for net.users that allows gaps, so
removing a port from a net is no longer an O(n) operation on the number
of users the net has.
Signed-off-by: gatecat <gatecat@ds0.me>
Checks that every ALU54B is correctly connected to two MULT18X18Ds:
* SIGNEDIA and SIGNEDIB connected to SIGNEDP
* MA and MB connected to P
* A and B connected to {ROA, ROB}
Diamond enforces these requirements; the connections are fixed
in any event so no other connection is possible.
This replaces the arch-specific DelayInfo structure with new DelayPair
(min/max only) and DelayQuad (min/max for both rise and fall) structures
that form part of common code.
This further reduces the amount of arch-specific code; and also provides
useful data structures for timing analysis which will need to delay
with pairs/quads of delays as it is improved.
While there may be a small performance cost to arches that didn't
separate the rise/fall cases (arches that aren't currently separating
the min/max cases just need to be fixed...) in DelayInfo, my expectation
is that inlining will mean this doesn't make much difference.
Signed-off-by: gatecat <gatecat@ds0.me>
This makes the difference clearer between the general arch API that
everyone must implement; and helper functions specific to one arch.
Signed-off-by: D. Shah <dave@ds0.me>
This uses the new IdStringList API to store bel names for the ECP5. Note
that other arches and the GUI do not yet build with this
proof-of-concept patch.
getBelByName still uses the old implementation and could be more
efficiently implemented with further development.
Signed-off-by: D. Shah <dave@ds0.me>
If the REG_INPUTA_CLK and REG_INPUTB_CLK values are set, then we should
use the faster setup/hold timings for the 18x8 multiplier.
Similarly, check the value of REG_OUTPUT_CLK for whether or not to use
faster timings for the output.
This is based on how I currently understand the registers to work - if
anyone knows the actual rules for when each timing applies please do
chime in to correct this implementation if necessary.
Along the same lines, this PR does not address the case when the
pipeline registers are enabled, since it is not clear to me how exactly
that affects the timing.
