[Cryptech Core] nit: reset low or high

[Basil Dolmatov]

Outside the chip - "active-low, async"
Inside the chip, but outside cores, on distribution bus - "active-low, async"

Inside cores - "anything that core needed"
Transformation of signal should be done near the place, where it will be used, if it needs transformation. 


dol@ с iPad

> 12 марта 2015 г., в 7:23, Paul Selkirk <paul at psgd.org> написал(а):
> 
>> On 03/11/2015 03:51 AM, Павел Шатов wrote:
>> 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.
> 
> Thank you, you correctly interpreted my question. If we're using macros
> or IP that expect active-high reset, that's a technical reason to prefer
> active-high within the cores.
> 
> 
>> On 03/11/2015 05:04 AM, Joachim Strömbergson wrote:
>> We had this discussion before and decided on active low reset.
>> The cores used to also have asynch reset, but since the cores are
>> primarily for FPGAs having synch reset is ok.
> 
> I don't recall the conversation about reset levels, so I apologize for
> rehashing it. I do vaguely recall a conversation about synch vs asynch
> reset, but I didn't have an informed opinion then (nor do I now).
> 
>> We can change all other cores, but I'd rather keep the cores active
>> low and if needed (as in Xilinx) just invert the reset signal before
>> feeding the CT sub system.
> 
> So we have one vote for active-high, and one for active-low. I'm not an
> FPGA guy, so I don't have a strong opinion, but I know inconsistency
> when I see it, so I do have a strong opinion that it should be one or
> the other.
> 
>                paul
> _______________________________________________
> Core mailing list
> Core at cryptech.is
> https://lists.cryptech.is/listinfo/core