Template:Asic

From Bitcoin Wiki
Revision as of 13:34, 11 March 2015 by TheRealSteve (talk | contribs) (Undo revision 55218 (derped))
Jump to navigation Jump to search

Template

Edit this section to edit the template.


Template:Asic/doc

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]
[pics(n):file]
[pics(n):caption]
[chip.name][chip.web] [chip.bct]
Introduced/Planned: [chip.date]
Datasheet: [chip.datasheet]

[warning]
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]
Gh/sJ/GhMh/JVHzWMh/HzGh/mm²η-factor
mining(n):Ghmining(n):Jmining(n):Vmining(n):Hz
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(6) | 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 | debug=0/1 }}

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

ParameterDescription
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.
Important: This should only be specified if dev.name does not resolve to a wiki page (either automatically or because it is specified explicitly as a wiki link).
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 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 lengthxwidth 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 lengthxwidth 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 Warning information.

optional multiple value parameter
syntax: warning=type,details

example: warning=vaporware,This chip does not actually exist
warning.type A warning type, where applicable. The only four warning types currently recognized are:

canceled: Inserts a text noting that the chip was cancelled.
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.
This parameter affects the 'date' label if chip.date is set. If set to one of canceled|vaporware|scam, the label will be Planned, otherwise it will read Introduced

warning.details Details on the warning type, if warranted. In the horizontal template, this is inserted into the [notes] section.
Note: Details may contain commas.
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
debug Adds debug output below the template output, but only if used on the Template:Asic/sandbox page to prevent accidental clutter.
optional boolean 0|1

syntax: debug=0|1

example: debug=1

References