| Age | Commit message (Collapse) | Author |
|---|
|
Changed all copyrights from Nordunet to Commons Conservancy, since they've
been the copyright holder since the end of 2018.
|
|
|
|
* take advantage of the cascade paths between DSP slices
* decrease latency of operation
|
|
|
|
|
|
* flush console after each ladder iteration for smoother progress output
* ability to truncate internal powering ladder loop at desired step (this will
only work when using simulation mode, obviously)
|
|
|
|
|
|
- unified clock enable for A:B and C ports
- A:B and C ports now always have fixed 1-cycle latency
- added new Z multiplexor modes in the generic wrapper
|
|
|
|
|
|
the subtle math overflow bug introduced while switching to DSP-based partial
multiplication product recombination.
|
|
|
|
* optional two-stage pipeline for A&B ports
|
|
|
|
|
|
|
|
file, not hardcoded widths.
|
|
wrapper names.
|
|
|
|
necessary changes to make it work after the general worker update. Also moved
debug simulation-time code into a separate file.
|
|
|
|
|
|
|
|
|
|
OPMODE, ALUMODE and CARRYINSEL ports, thus more defined constants.
|
|
(modular subtraction was split into three micro-operations instead of one).
|
|
|
|
|
|
|
|
|
|
* cosmetic rename of Verilog include file
|
|
for addition instead of fabric logic. This opcode is only necessary when in
CRT mode and is executed once per entire exponentiation to recombine the two
"easier" exponentiations. This was the final change necessary to get rid of
using fabric math in the general worker module.
|
|
bank address space sweep, during the first pass (a-b) and (a-b+n) were
computed, during the second pass either the former or the latter quantity was
written to the output bank (depending on the very last borrow flag value).
This is no longer possible, since the FSM now only generates one "interleaved"
address space sweep. The solution is to split one complex modular subtraction
operation into simpler sub-operations. Currently modular subtraction is
achieved by running a sequence of three micro-operations:
* MODULAR_SUBTRACT_X computes (a-b) and latches the final borrow flag
* MODULAR_SUBTRACT_Y computes (a-b+n)
* MODULAR_SUBTRACT_Z writes either (a-b) or (a-b+n) into the output bank
depending on the latched value of the borrow flag
Unfortunately we can't compute both (a-b) and (a-b+n) during one address space
sweep, since fully pipelined adder/subtractor DSP slice has 2-cycle latency.
|
|
actually in the critical paths of the ModExpNG core and are plaguing the place
and route tools. I was barely able to achieve timing closure at 180 MHz even
with the highest Map and PaR effort levels. This means that any further clock
frequency increase is effectively impossible, moreover any small change in the
design may prevent it from meeting timing constants. The obvious solution is to
use DSP slices not only for modular multiplication, but also for supporting
math operations. When fully pipelined, they can be clocked even faster then the
block memory, so there definitely should not be any timing problems with them.
The general worker module does three things that currently involve fabric-based
math operations:
* carry propagation (conversion to non-redundant repsesentation)
* modular subtraction
* regular addition
This commit adds four DSP slice instances and makes the carry propagation
opcode use DSP slice products instead of fabric logic.
|
|
is responsible for doing certain supporting operations (mostly moving operands
between banks and doing some simple math operations, such as modular
subtraction and regular addition). Depending on the particular operation, one
of three bank address space sweep patterns was used:
* one-pass (for things like carry propagation)
* two-pass (for things like modular subtraction that produce intermediate
values in the process)
* one-pass interleaved (for copying when only either CRT_?.X or CRT_?.Y is
rewritten: we can only write to X and Y simultaneously, so we have to
interleave reads from the source bank with reads from the destination bank
and overwrite the destination with its just read value, otherwise the second
destination operand is lost)
I initially coded three FSMs, one for each of the address space sweeps and
triggered one of them depending on the opcode, but that turned out too
complicated. There's now only one FSM that always does the "one-pass
interleaved" pattern, whereas the second read (from the destination bank) is
inhibited when not need by the opcode.
|
|
|
|
|
|
|
|
outputs were going directry into a LUT-based ternary adder which was causing
timing problems. Added a layer of flip-flops, so instead of BRAM -> LUT -> FF
we have BRAM -> FF -> LUT -> FF. This increases core latency by
(number_of_supporting_modular_multiplications + number_of_exponent_bits) ticks.
|
|
The FSM previously had four states encoded using two bits, so the next state
logic didn't have a default case, since all the possible states were used.
Addition of the fifth state required one more state bit, so the FSM now has
five states out eight possible and a default case is thus necessary.
|
|
|
|
and DECODE. Apparently one clock cycle is not enough to entirely decode an
instruction, so decoding now takes two clock cycles (DECODE_1 and DECODE_2).
This seems to solve the problem. If we run into more timing violations here, we
can add an extra DECODE_3 cycle and register the currently combinatorial
uop_opcode_* flags at DECODE_2. This fix increases the core's latency by 59/32
clock cycles (CRT/non-CRT mode) plus two extra clock cycles per each bit of the
exponent.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
