[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