[Cryptech Core] nit: reset low or high
Павел Шатов
meisterpaul1 at yandex.ru
Wed Mar 11 07:51:47 UTC 2015
On 10.03.2015 20:29, Paul Selkirk wrote:
> This is mostly for Joachim and Pavel, but spammed to the list so we have
> a record of design decisions.
>
> Joachim's cores have an active-low reset line, while Pavel (and Bunnie)
> have active-high reset. AFAICT Joachim gets an active-low reset from the
> Terasic board, and just propagates it to the other cores in his design.
> Where I'm mixing cores from different authors, I have to remember which
> ones are low and which are high. So e.g. in the Terasic design, we have
> reset_n port at the top-level, which I invert to sys_rst for
> core_selector. In hash_selector, this gets re-inverted back to reset_n
> for the sha cores.
>
> Is there a technical reason to prefer active-low, or should I change all
> derived/propagated resets to be active-high for consistency?
>
Hello!
As Peter has already pointed out, external reset signals coming to an
FPGA are in virtually all cases active-low. On the other hand all Xilinx
IP cores and primitives have active-high reset inputs, so it makes sense
to make all internal reset inputs and outputs active-high for
consistency. This strategy leads to a very simple rule: the only
active-low reset (if there is one) should be in the top-level module,
where external ports are declared, all the other resets should be
active-high.
I tried to adhere to this strategy in the baseline project for Novena:
top-level port reset_mcu_b is active-low, this signal is used to reset
clock manager module. Clock manager is also reset when input clock is
missing or DCM is not locked, so it effectively combines three reset
signals and generates a new one (sys_rst), which is active-high, because
it was generated internally in an FPGA.
Regarding Terasic design, my suggestion to invert the top-level reset
signal and then distribute this inverted active-high reset downstream.
Yes, different authors have different understanding of reset. This may
trigger a long dispute of whether you need reset at all, whether it
should be active-high or active-low, whether it should be sync or async,
etc. I suggest to just pick a reset strategy and make sure that all the
code adheres to it, we don't have that much code so far. Is it possible
to modify Joachim's SHA cores to have active-high reset?
--
With best regards,
Pavel Shatov
More information about the Core
mailing list