Technology Mapping

[Mahdi89]

When generating a Verilog netlist using e/Teak you should expect a popup window (if you're using the GUI, if not try --help in command line) which asks you to select a technology library. e/Teak's technology mapper automatically generates the gates within modules based on the provided library (see the generated verilog files). In your case "example.v" file which contains the timing information for every gate is the default library and is useful when you simulate the design and aim to estimate the execution time of your circuit or approximate the critical path (in synchronous designs).
If you install other technology libraries, such as UMC Faradey 130nm, e/Teak recognises the path to the library and maps the circuit based on the available gates in the package. If you don't have access to UMC Faradey 130nm then you can use NanGate 45nm library: http://www.nangate.com/?page_id=22

But why do you need Tech. mapping? By Tech mapping a design Synopsys can provide you with more accurate timing estimations. Bear in mind that e/Teak doesn't generate RTL, instead it generates gate level netlist. When you have gate-level netlist in hand you don't really need to rely on the elaboration phase of Design Compiler (DC) and you can easily skip it. The only renaming phase is Tech. mapping the design if you want to use area estimator from Synopsys. For power estimations a vcd file can be generated from the simulator and fed it into Synopsys PowerTime for power and timing estimations.
For the asynchronous designs Tech. mapper replaces C elements with Dlatches from the library. When estimating the area DC will throw some warnings saying that it has detected timing loops which could be ignored as you don't really want DC to touch/optimise your design at all!
If you need DC to optimise your design we recommend taking look at the re-synthesis paper in the Documentation folder: https://github.com/balangs/Documentation/tree/master/Peer-reviewed_Publications

[imanazari70]

Do we able to select a handshake protocol in eTeak(For implementation in technology mapping)? For example, make our design base on the 4-phase dual-rail protocol or 2-phase dual-rail protocol or... ?
If yes, how should I do it?

[Mahdi89]

@imanazari70 unlike the Balsa synthesis system, the only handshake protocol supported in eTeak is 4-phase dual-rail only. The synchronous elastic backend is identical to the 4-phase bundled data (SELF) protocol in which delay matching particularly for the operators is done by the global clock signal. However it's feasible to remove the global clock signal from the design and insert delays for every operator individually. @analava

[Po0ria]

I recently tried to map a simple component of your examples to make a gate-level netlist using other technology file mapping like nanGate 45 nm as you mentioned before, but the problem that I've faced is that the eTeak can not recognize some symbols in *.v of the library like (NangateOpenCellLibrary.v):
Error: "expecting an identifier (at `(ZN, A1'...)"
I think maybe the eTeak just recognizes some specific gates like "AND2 I0" (I have not seen before in tech files) instead of regular gates like "and, or, not". I think this eTeak just use its own library

[Mahdi89]

@roopia The *-mapping.v files are provided in the following folder: https://github.com/balangs/eTeak/tree/master/tech

If you wish to use a different technology node such as nanGate 45nm library you'd need to make sure to include a mapping file in this directory with a proper naming for the primitive set (e.g. and, or, etc.). For instance, for and2 the associated name in the UMC130F library is AN2EHD whilst it is HS65_LS_AND2X4 in ST 65nm Library. I just checked the nanGate 45nm library, depending on the cell strength the name could be AND2_X1, AND2_X2, or AND2_X4.

The alternative approach is to use the example library to generate a generic netlist, then you could pass it to DC to technology map the generic gates for you. If you have asynchronous gates, such as C elements (which I believe you have), you better make sure that they're replaced with latches before passing the netlist to DC as I think it wouldn't recognise the custom elements of the asynchronous design.