Template:Asic

Template

Edit this section to edit the template.

Overview

Template to be used for ASIC chip details - e.g. developer, hashing specs, process, media.

The reason for using a template rather than a whole bunch of copy/paste scenarios is that it makes it easier to use it across different pages - e.g. entries in a list of ASICs, summary/sidebar entries on a developer's page, full entries on the page for the chip itself (if applicable - currently only Avalon seem to be using this) - and to vary presentation/update to more standards-compliant output as time goes along.

Not included in this template

The following items are not included in this template, for the reasons specified:

• Gen / Generation labels. These mean different things to different people and ultimately have no bearing on a chip's specifications.
• Temperature specifications. Appropriate TDP information is rarely available for mining chips, with some manufacturers instead referring to how hot a chip gets in a given miner at a given temperature. However, as this temperature is highly dependent on the specific configuration of the miner (single fan / double fan / water cooling / immersion cooling), this once again has no bearing on a chip's specifications.
• Cores count The number of cores stated for a mining chip is moot unless each manufacturer uses the exact same design, number of stages per core, etc. Despite plenty of commonality, implementations do differ enough that the concept of a 'core' is difficult at best to use as a distinguishing feature.

Usage

This is a relatively straight forward wiki template and many of the notes about using templates apply here.

This template only uses named parameters. Some of these parameters take multiple values, delimited by a comma, which should be treated as anonymous parameters - i.e. the order in which you specify them determines which sub-parameter you specify a value for.

As an example, the named parameter dev takes three values, name, web and logo, in that order; dev=name,web,logo. These sub-parameters are referenced as 'dev.name and dev.web in this documentation.

Note: Whenever an arbitrary string contains a comma, you must encode it as ,. E.g. dev=Company, Inc.,http://www.example.com/.

Visual guide

The following table serves as a visual guide, showing which parameter is inserted at which location in the output.

[dev.logo][dev.name][dev.web] Facilitators: [codevs]	Mining specifications: Gh/s J/Gh Mh/J V Hz W h/Hz Gh/mm² η-factor mining(n):Gh mining(n):J mining(n):V mining(n):Hz Technical specifications: Foundry: [die.foundry] Die: [die.size]mm @ [die.node]nm ([die.topology]) Package: [package.type] [package.size]mm Markings: [package.markings] Known date codes: [datecodes]	[pics(n):file] [pics(n):caption]
[chip.name][chip.web] [chip.bct] Introduced: [chip.date] Datasheet: [chip.datasheet] [warning]
Additional notes: [notes]
Miners using this chip: [miners]
Sources: [sources] (only shown if showsources=1 is set)

Template template

Although straight forward, this template does have quite a few parameters. If you've already familiarized yourself with the parameters and their meaning, the following template template can help; just copy/paste and adjust values as appropriate.

{{asic | dev=name,web,logo | codevs=list | chip=name,web,date,bct | datasheet=list | pics=list(4) | mining=Gh:J@V:Hz list(4) | die=foundry,node,topology,size | package=type,size,markings | datecodes=list | notes=string | sources=string | showsources=0/1 | warning=canceled|needinfo|vaporware|scam }}

Sandbox

Before using this template in a page, consider using the sandbox. Not only does this allow you to test the output of your parameters, it also provides debug information on each of the provided parameters and several of the derived values, making it easier to fix any problems with the values you provide.

Parameters

Parameter	Description
dev	Details about the primary developer of the ASIC. required multiple value parameter syntax: dev=name,web example: dev=[Company, Inc.],http://www.example.com/,logo-company_inc.png
dev.name	Name of the primary developer. Can be a [wiki link] if the company has a page on the wiki. Note that if the name contains any commas, these should be replaced with the HTML encoded version , required string
dev.web	Website of the primary developer. optional non-wiki link string
dev.logo	Developer's logo. If possible, source this from the company's wiki page. If they don't have one, this would be a good excuse to make one! Otherwise, upload an image and reference simply as filename.extension optional wiki picture filename
codevs	Names of co-developers. An example of a co-developer is an ASIC design/finishing/proofing house or a facilitator between the primary developer and the foundry. optional comma separated list of strings syntax: codevs=Company A,Company B,Company C example: codevs=A6 LLC
chip	Non-technical details of the chip required multiple value parameter syntax: chip=name,web,date,bct example: chip=Blockerator 2000,http://www.example.com/destructor2k/,June 20th 2014,https://bitcointalk.org/index.php?topic=1.msg2#msg2
chip.name	(Code) Name of the chip. Many developers will name their chip or use a part code as a reference. If no such name can be found, the chip may be used exclusively in a particular line of miners, which do have a name, and that name can be used instead. Otherwise, leave blank. optional, string, defaults to unknown
chip.web	Website with information about the chip. This can be a forum thread/post but should not be a BitcoinTalk thread. See chip.bct instead. optional non-wiki link string
chip.date	Introduction date of the chip. This can often be difficult to assess as the chip goes through various stages of development before it goes to market. If possible, find the tape-out date. If this can't be found, try to find when it was first introduced to market, e.g. in an announcement, press coverage, etc. Alternatively, if the chip package has a date code that precedes that introduction, use the date code as a basis instead. If no exact date is known, year/month will suffice . optional date string (no commas)
chip.bct	BitcoinTalk thread/post with information and/or discussion about the chip. optional non-wiki link string to the BitcoinTalk forum.
datasheet	Links to the chip's datasheet(s) and/or significant resource(s) of technical information, if available. optional comma separated list of [wiki link] strings. optional list of comma separated [wiki links] syntax: datasheet=[wiki link1],[wiki link 2],... example: datasheet=http://www.example.com/destructor2k/
pics	Pictures to be included in the template, typically of the top and bottom of the chip and optionally die and/or design photos (up to 6 pictures total) along with simple captions that may include links to further media along the same lines (e.g. Top, [http://www.example.com/media/destructor2k Die shots]) in the following structure: filename.extension:caption optional comma separated list of up to six media structures
mining	Specifications of the chip's Bitcoin hashing performance. Hashing performance of a typical chip is a complex issue with multiple variables. The most common two variables are core voltage and core frequency. Combined, these affect both the hash rate and the power consumption. To enforce per-setting parity for these values, they must be specified as any permutation of the following structure: mining=<Gh:J@V:Hz Where Gh is the hash rate, J is Joules/Ghash, V is the core voltage and Hz is the core frequency. The leading < can be used if a J/Gh rating is derived from at-the-wall power consumption of a miner in case there is no information on the chip. At-the-wall power consumption is always greater than that of the chip due to losses in the power supply, voltage regulators on the board, and losses in auxiliary circuitry. Trailing units may be specified for clarity but will not be used to determine how to interpret the data. For example, you could specify only the hash rate (mining=200) or the power consumption at a given hash rate (mining=200Gh:0.82J) or the hash rate at a given core voltage (mining=200@0.7). The template will automatically insert derived values (W, Gh/J, etc.) where sufficient values are given. If more than one structure is provided, each will be included in the template separately up to a maximum of 4. This allows for minimum and maximum power consumption figures, and minimum and maximum hash rates (if not coinciding with the power consumption figures). Further values, e.g. to demonstrate non-linearity, are outside the scope of this template and should ideally be noted in a chip's datasheet. Important: If you do not have exact figures but have values from which to roughly calculate them, such as from a complete miner's specification, you can enter a mathematical expression. For example, if you know that a miner is advertised as being 800Ghash/s, and a picture tells you that it has 12 chips, you can use mining=800/12 and the template will calculate the hash rate. The main reason for entering these values directly has to do with sourcing, such that others can verify the values entered. In this example, a hash rate of 66.67 is unlikely to be found through a search or through checking sources. Similarly, if only a miner's (800Ghash/s) at-the-wall power consumption (400Watt) and the power supply's efficiency (83%) is known, you can use mining=800/12:400/12*0.83 optional comma separated list of up to four mining structures syntax: mining=Gh:J,V:Hz example (no suffixes): mining=200:0.82,0.78:175 example (suffixes for clarity) mining=200Gh:0.82J,0.78V:175Hz
die	Technical data about the chip die itself. optional multiple value parameter Note: The Gh/mm² and η-factor values are automatically derived from the die size and node process sizes if the hash rate is also known. syntax: die=foundry,node,topology,size example: die=TSMC,28nm,full custom,3.5x3.5
die.foundry	The foundry that produced the chip wafers. Typically this will be one of TSMC, Global Foundries, UMC, or SMIC, but there are other foundries especially for older node sizes. optional string
die.node	Node size. This should be specified in nanometers (nm) and may include the 'nm' suffix for clarity. Sizes should not be specified in µm. optional string
die.topology	The topology of the chip. This can be difficult to ascertain as many manufacturers won't say, or rely on multiple technologies. This value will typically be one of hard copy, full custom or gate array. hard copy generally refers to an FPGA design that was turned into an ASIC by path of least resistance; letting software solve it. full custom may include a custom designed core but with placing and routing automated. optional string
die.size	Physical size of the die, expressed in millimeters length'xwidth and may include the 'mm' suffix for clarity, e.g. 4x4mm optional dimensions string
package	Details of the package used for the chip. optional multiple value parameter syntax: package=type,size,markings example: package=QFN,8x8mm,BTC2000 / [date code] / [lot #]
package.type	The package type and pin count used for the chip. This will typically be one of QFN, BGA or FCBGA, followed by the number of pins. The number of pins on some packages can be difficult to determine. For example, a BGA may consist of 32 rows and 32 columns, but have its corner pins removed, or the shadow area under the die may not have any pins at all. When the pin count varies wildly from what a simple rows * columns calculation would provide, use the rows * columns calculation, append an asterisk (in this example, BGA1024*, and if possible supply media showing the pins on the chip more clearly in the pics parameter if not already specified. optional string
package.size	Physical size of the package's board presence without any leads - i.e. just the dimensions of the (plastic / ceramic) package - expressed in millimeters length'xwidth and may include the 'mm' suffix for clarity, e.g. 9x9mm optional dimensions string
package.markings	Plaintext transcription of the markings on the package, excluding pin 1 indication markers. New lines should be substituted by / (space before and after the slash character). Bare packages should have their markings specified as 'none'. If the markings include a logo, the logo may simply be described as company logo or device logo, though in the case of logos that incorporate text this text should be noted. Special markings may be indicated by place holders, e.g. [lot #] and [date code]. optional string
datecodes	A list of date codes found in the wild. Date codes can help establish manufacturing runs. Typical date codes exist of a week number and a year, both as two digits, together. However, more complex date codes exist and if in use may not be easy to decipher without a datasheet. optional comma separated list of strings syntax: datecodes=code1,code2,... example: 3913,4013,4113
warning	A warning state, where applicable. The only three warning states currently recognized are: needinfo: Inserts a text noting that more information on this chip is desired. vaporware: Inserts a text noting that the chip may not actually exist. scam: Inserts a text noting that the chip is the subject of a scam accusation. These warnings should not be used lightly. Lack of information on a chip does not necessarily imply a scam, and should instead be set to needinfo. When there are strong indications that the chip simply doesn't exist vaporware is an appropriate state. Only when there are strong scam accusations should the scam state be used. If it is known that a chip never reached production because it was canceled, use the canceled state. There are no 'warnings' for chips that are legitimate, currently available or currently under production. Simply leave out this parameter, and no warning will be inserted. Important: If set, further information must be provided in the notes parameter. optional needinfo|vaporware|scam syntax: warning=needinfo|vaporware|scam example: warning=vaporware
notes	Any additional notes that should be added. This may include trivia (back story behind a name, for example), specifications not yet addressed in the template, or anything else you feel may be of interest. optional string syntax: notes=arbitrary string example: notes=The Blockerator 2000 doesn't actually exist.
miners	A (non-exhaustive) list of miners that use this particular chip. These miners may be [wiki linked] or plain linked if there is information on the particular miner available. However, this should absolutely not be used to refer to miners that do not (yet) exist. As with the entirety of the wiki, it is not advertising space. optional list of comma separated strings syntax: miners=miner1,miner2,... example: miners=Blockerator 2K,Blockerator2K1
sources	A list of sources. In order to prevent a link cloud or link clutter, while acknowledging the need to prevent [citation needed], this parameter should be used to list your sources. Anybody interested in checking where information came from can then put in the small effort to find it. Note: If you are uploading media, consider putting the source citation in the media's description instead, and make sure to choose an appropriate license. For company logos this is usually because it will be a wordmark, simple geometric shapes argument, or just 'fair use' based on being illustrative. The latter argument also tends to apply to chip shots. However, if you can provide your own original photos, that would be preferred. optional list of comma separated source citations. syntax: sources=data1<ref>source1</ref>,data2 & data 3<ref>source2&3</ref>,... example: sources=all the things: thin air (original research)
showsources	Adds the citations below the template output. If the page has a <references /> tag, they will then be listed there. optional boolean 0|1 syntax: showsources=0|1 example: showsources=1