Template:Asic
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 codes: [codes] |
|
||||||||||||||||||
| Notes: [notes] | |||||||||||||||||||
| Used on: [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 | codes=list | notes=string | sources=string | showsources=0/1 | warning=future|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
| Parameter | Description |
|---|---|
| style | Output style. Defaults to the above visual guide. The three other options at this time are:
optional string style=infobox |
| dev | Details about the primary developer of the ASIC. required multiple value parameter syntax: 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=A6 LLC |
| chip | Non-technical details of the chip required multiple value parameter syntax: 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=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 Important: If the display style is infobox, only the first picture specified is used. Thus, the first picture should generally be a 'top' picture for identification. |
| 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 (in MHz). 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 ( 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 |
| 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. 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=QFN,8x8mm,BTC2000 / [date] / [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'. optional string |
| codes | A list of 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: 3913,4013,4113 |
| warning | Warning information. optional multiple value parameter warning=vaporware,This chip does not actually exist |
| warning.type | A warning type, where applicable. The only four warning types currently recognized are:
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. |
| warning.details | Details on the warning type, if warranted. 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=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=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=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=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=1 |
References