View Single Post
  #5 (permalink)  
Old 01-05-2004, 09:35 AM
Muzaffer Kal
Guest
 
Posts: n/a
Default Re: is this a good idea

On 5 Jan 2004 01:01:03 -0800, [email protected] (Paul) wrote:

>"Jerry" <[email protected]> wrote in message news:<[email protected]>...
>> "Paul" <[email protected]> wrote in message
>> news:[email protected] om...
>> > Hi
>> >
>> > I know that the "reg"'s are all zeroes when powered on (on Xilinx
>> > FPGAs). Is this a good idea (assumption) to work on? Can I assume the
>> > same for ASIC development? that is I don't have to change my codes
>> > later on?
>> >
>> > Thanks.

>>
>> Its the worst idea I have seen on this newsgroup to assume the state of
>> registers at power up in an ASIC.
>> BAD BAD BAD, 300 lashes with a broken O'scope lead for the assumption.
>> Watch your simulator. It should have unknown in registers that were not
>> initialized.
>> Some registers initial state is a don't care, some are very critical, it all
>> depends on your design.
>>
>> Jer

>
>
>Can't I just tell the foundry that I need the regs to be zeroes at powered on?
>Anyone done this before?


No, reset is a functionality which needs to be designed in. There are
several reasons for this. One is that some methodologies require that
there be no asynchronous resets and and initialization be
synchronously loaded. But this requires a clock to work. Also async
reset flops are usually larger and slower than non-reset flops so it's
a plus if you don't need them. Also it doesn't depend on the foundry
but the cell library you use.

The best solution is to use asynchronous resets with external reset
being synchronized with two flops per each clock domain where the
reset signal is needed. This way you can time the reset recovery
constraint and there are NO metastability issues to be dealt with and
two flops are all that's needed. The two flops used in reset
synchronization are similar but not the same two flops which are used
in cross clock domain transfers.

Hope this helps,

Muzaffer Kal

http://www.dspia.com
ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations
Reply With Quote