From cf8167215459811f8047f7c6d4f5972d924f6689 Mon Sep 17 00:00:00 2001 From: Rob Austein Date: Sun, 27 Sep 2015 13:17:55 -0400 Subject: Comments noting the strange history of the addressing scheme. --- config/config.py | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) (limited to 'config') diff --git a/config/config.py b/config/config.py index 970b339..4648f9d 100755 --- a/config/config.py +++ b/config/config.py @@ -3,6 +3,44 @@ Generate core_selector.v for a set of cores. """ +# History of cryptech bus addressing scheme, as best I understand it. +# +# The old old addressing scheme that Joachim and Paul came up with +# was: +# +# 3 bits of segment selector [16:14] +# 6 bits of core selector [13:8] +# 8 bits of register selector [7:0] +# +# modexp6s needed more register bits than that, so Pavel changed +# addressing within the math segment to: +# +# 3 bits of segment selector [16:14] +# 4 bits of core selector [13:10] +# 10 bits of register selector [9:0] +# +# Meanwhile, Paul eliminated segments entirely when writing the +# ancestor of this script, resulting in: +# +# 9 bits of core selector [16:8] +# 8 bits of register selector [7:0] +# +# Taking Pavel's and Paul's changes together, we want: +# +# 7 bits of core selector [16:10] +# 10 bits of register selector [9:0] +# +# Open issue: what effect does all this have on the sub-core muxing +# within trng cores? trng core plus its (currently) four sub-cores +# still takes up more than one new core slot even if trng uses the old +# scheme internally. How many slots should we allocate, and what +# addressing scheme is the trng core expecting to see? + +# Unrelated: Timing delays. Paul added extra registers to slow cores +# other than modexps6 down by one clock cycle, to compensate for the +# one cycle delay that seems to be built into the block memories that +# modexps6 uses. Templates will need to reflect that somehow. + def main(): """ Parse arguments and config file, generate core list, generate output. -- cgit v1.2.3