Template:Asic
Extremely preliminary ASIC chip details template.
NOTE: There is nothing actually here yet. Do not use this template.
Preliminary 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.
This template will likely make a bit of use of the #explode stringfunction in order to easily pass multiple anonymous parameters as a single named parameter. I.e. dev=Bitmain,https://bitmaintech.com/ creating an internal wiki link for Bitmain, but also adding an external link to https://bitmaintech.com/, whereas dev=Bitmain does not include the external link. This helps cut down on having to do things like dev=Name|devlink=somesite|devlogo=somemedia, when these can - for the purposes of a template - easily be grouped together without much confusion in use. Unfortunately the comma separator does mean that things like "Company, Inc." will need to have their comma encoded or wrapped such that the template won't see that as a separator. That or think of a different delimiter to use. Anything but resorting to the pipe template/magic word {{!}} which makes my eyes hurt.
To do
Basically all the things, including what details to include:
- Developer details
- Main developer (may include external link, name may be wikilink (will not create red links))
- dev=name,website
- Secondary developers (i.e. chip facilitators, design bureaus, etc. - may include external link, no internal wiki links)
- codevs=name1,name2,...
- Main developer (may include external link, name may be wikilink (will not create red links))
- Chip details
- (code) name, default to "unknown" (may include external link, may include BCT link)
- chip=name,website,bct
- picture(s) - top/bottom maybe die (design) shot if available, with captions. Currently inserting as a gallery, though apparently widths is broken. Images should (preferably) be square (chips be square, yo).
- chipmedia=media1,media1caption,media2,media2caption,...
- Introduction date (tape-out / market introduction / first known date code, preferably using #time)
- chipdate=August 2014,1339 (Date template missing?)
- Mining Specifications. Typical or min-max, as these can vary wildly depending on implementation and voltage/frequency modifications. Additionally, at the moment the test table below contains a #expr to calculate Gh/J. This only works if the input J/Gh is a single number, rather than a range. If ranges are to be allowed, those ranges would have to be split first. Additionally, because of the two variables, one could have 'Gh/s @ V @ Hz' and additional matching 'J/Gh @ V @ Hz' where the J/Gh does not necessarily carry through in all the variations. Will have to think on this one a bit. If allowing that format, then mods.volt, mods.freq and possible btcspecs.energy and btcspecs.hashrate can go, leaving essentially btcspecs=J@Gh@V@Hz,J2@Gh2@V2@Hz2,..., with #expr used to do any further calculations. However, I feel that this overcomplicates matters, and allowing min-max for both figures is sufficient for an overall overview - leaving the details of how to achieve those figures to the source citation or the reader's own research.
- Ghash/s
- J/Ghash
- btcspecs=hashrate,energy
- Tech that modifies mining specs
- Core voltage (typical or min-max)
- Core frequency (typical or min-max)
- mods=volt,freq
- Technical specifications ( in smaller type? )
- foundry (TSMC, UMC, Global Foundries, SMIC, etc.)
- node size (nm)
- node process (hardcopy / full custom / gate array / standard cell / ?, rolled (sometimes called 'folded') cores / unrolled cores)
- die size (mm x mm)
- package specs (QFN, BGA, etc. mm x mm)
- package markings in plaintext ( logo/name / part code / date code indication )
- techspecs=foundry,nodesize,process,diesize,package,markings
- list of date codes found in the wild.
- datecodes=code1,code2,...
- (code) name, default to "unknown" (may include external link, may include BCT link)
- Additional notes - trivia, additional details, pretty much anything, including whether or not the chip being referred was every actually real.
- notes=Additional notes here
- Use details, i.e. a non-exhaustive list of miners this chip is used in. I'm pretty sure mediawiki can do a two-way relationship, but I think that would require every single miner to also have a wiki page...somehow. Stick to this, manually update as miners are listed.
- miners=minerA,minerB,minerC,etc.
- Sources. Where possible, give source for any parameter. Rather than making a link cloud of sources in the template (output), accept arbitrary data here, e.g. foundry & node size & die size,codevs. Anybody with a citation needed itch can then check the source or (temporarily) set showsource=1
- sources=string1,string2,...
- Optional feedback
- For missing parameters - i.e. those inserting the template should have an easy way to figure out which parameters are missing without having to refer back to the documentation.
- showmissing=0|1
- For sources - additionally outputs sources
- showsources=0|1
- For missing parameters - i.e. those inserting the template should have an easy way to figure out which parameters are missing without having to refer back to the documentation.
Formatting:
- (wiki)table that structures the information
| [dev.name][[dev.website]|www] [codevs] | [chip.name][[chip.website]|www] [[chip.bct]|BCT] |
|
| Bitcoin mining specs | Technical specs | |
| Hash rate: [btcspecs.hashrate]Gh/s Power consumption: [btcspecs.energy]J/Gh (Expression error: Unrecognized punctuation character "[".Gh/J) |
Foundry: [techspecs.foundry] Die: [techspecs.diesize] @ [techspecs.nodesize]nm Package: [techspecs.package] Markings: [techspecs.markings] Known date codes: [datecodes] |
|
| Core voltage: [mods.volt] Core frequency: [mods.freq] | ||
| Additional notes: [notes]/td> | ||
| Miners using this chip: [miners] | ||
| Sources: [sources] | ||
All the logic that actually outputs the above based on provided parameters
- Should have a boolean toggle that outputs all parameters and shows which ones are missing.
Proper documentation:
- The style of the preliminary table above can show where provided info goes as a visual reminder
- Make a table of parameters, listing:
- required yes/no
- format (string (arbitrary, link, etc.), integer, boolean, whatever)
- default value (only applicable to chip name so far: unknown)
- description of parameter and parameter use. E.g. if a derived value is to be used, use #expr so that original source values can be looked up. Things like the hash rate should be explained in terms of typical vs min-max values. With adequate cooling a chip can be overclocked quite a bit, and with extreme undervolting a chip can easily be very power-efficient. The ASICs page will end up making note of this as well. As a result, these values can be gamed to fit an agenda, which leads to:
- explain source citation. Although most of the values should be readily found via google/bing/whatever, and I'm far from a [citation needed] kinda person as a consequence, adding sources doesn't hurt.
Not to do
Things that shouldn't be included in this template (and should be noted on the ASICs page instead):
- Gen / Generation labels. These mean different things to different people and is ultimately fluff.
- temperature specs. Drop the chips in liquid nitrogen and hey presto - i.e. temperature is fluff for asic specs and should be reserved for miners.
- Cores count. The number of cores 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.