[Cryptech Tech] ASIC implementation page on wiki

[Bernd Paysan]

Am Donnerstag, 14. August 2014, 11:19:15 schrieb Joachim Strömbergson:
> Actually, modern ASIC synthesis tools will be able to automatically
> generate simpler memories. But that is nitpicking.

Yeah, I've done that for some small memories where the details didn't matter 
much or the dedicated RAM compiler produced something with too much overhead 
(e.g. b16 stacks - the synthesis tool will choose a bunch of latches for a 
very small memory).

> Actually it isn't that clear cut. Xilinx actively recommends against
> using asynch reset, see:
> 
> http://www.xilinx.com/support/documentation/white_papers/wp231.pdf
> "Avoid asynchronous reset because it prevents packing of registers into
> dedicated resources and affects performance, utilization, and tool
> optimizations."
> 
> On the other hand Xilinx in a later WP even recommends not implementing
> any dedicated reset at all since they will reset all registers as part
> of the configuration:
> 
> http://www.xilinx.com/support/documentation/white_papers/wp272.pdf.

Yes, you can actually do that: Implement the reset values as "initial" block 
in Verilog for the Xilinx FPGA, and also add an asynchronous reset, but tie 
that to 1 (or whatever inactive level it is), so the synthesis tool can 
optimize that part away.  In the ASIC, actually connect that reset, and make 
sure (by using an `IFDEF FPGA for the initial block) that the initial block 
isn't seen by the synthesis tool, which will flag such initial block as 
errors.

> In Altera devices the same recommendation (not specifying reset state
> for registers) leads to a bigger design. And for Altera the availability
> of asynch support differs between generations. The later devices with
> LABs have dedicated labclr control signals that support asynch reset.

Yes, but that's true for quite some time.

> For older devices Altera has been recommending synchronous reset. Their
> updated recommendations is to use Synchronous Asynchronous Reset:

I also recommend to synchronize clock and reset globally, too, you either gate 
the clock with a delayed reset or you deassert the reset with the second 
clock.  The latter allows you to implement a mix of async and sync reset in 
the circuit.  The per-block style for an ASIC then still is async reset.

> http://www.altera.com/literature/hb/qts/qts_qii51006.pdf
> 
> I agree however that for ASIC design it is way more common to use asynch
> reset (though I have been working on a few ASIC where synch reset is
> used.) And the specific reset strategy is always implemented in a
> dedicated block which feeds its own network.

I've had such a synch reset block in one ASIC, and it wasn't nice to 
integrate.  Actually, I had to add a reset synchronizer (actually it was a 
reset delayer, but it's essentially the same circuit) just for the sake of 
that block.

> True all of them, and Europractice might be the best way forward in
> terms of openness. At least if we want to do a Cryptech ASIC as part of
> an open research project.
> 
> http://www.europractice-ic.com/

Yes, that's the easiest interface for such an open research project.

> > Having worked in the semiconductor industry for quite some time, the
> > best contact I have is to TowerJazz, with one of my former bosses
> > ending up as the European sales director there.
> 
> Good to know. I have worked with Samsung, IBM, LSI, TSMC, UMC, SMIC, NEC
> and ST as fabs for the chips I've been involved in and have a fairly
> good network. But close contacts is always good.

I've worked with other fabs (Xfab and AMS were two not in your list), but the 
contacts weren't that close.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cryptech.is/archives/tech/attachments/20140816/418d3cfc/attachment.sig>