[Cryptech Core] proposed core reorganization
Павел Шатов
meisterpaul1 at yandex.ru
Thu Mar 5 09:04:12 UTC 2015
On 05.03.2015 1:48, Paul Selkirk wrote:
> The choice to put core_selector under platform was somewhat arbitrary.
> It could also go under comm, since it sits between the communication
> channel and the crypto cores.
It makes sense, I agree.
The only problem that I see right now is eim_regs.v module. This module
contains some global (board-level) registers, like board type and
firmware version. It is not related to EIM (it is not a communication
channel, it is a set of board-specific registers), so it definitely
should go under platform/novena. It was originally named novena_regs.v,
we should have another such file (plarform/terasic_c5g/terasic_regs.v)
with different board type value.
Here we face another problem. We need to have common hash_selector.v,
that will instantiate novena_regs.v for Novena and terasic_regs.v for
Terasic board. Two options are possible:
1. Use conditional synthesis and instantiate appropriate modules inside
of hash_selector.v in `ifdef NOVENA and `ifdef TERASIC blocks. I don't
know why you dislike conditional synthesis, it is a common trick. Yes,
it looks ugly at times, but universality involves increased complexity,
you can't do anything about it.
2. Make hash_selector_novena.v that instantiates novena_regs.v and
hash_selector_terasic.v that instantiates terasic_regs.v. This way hash
selector becomes in fact platform-specific and your decision to place
core_selector under platform makes even more sense.
--
With best regards,
Pavel Shatov
More information about the Core
mailing list