[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