Chips4Makers.iohttps://chips4makers.io/blog/2022-10-03T00:00:00+02:00Chips want to be freePDKMaster circuits and layouts for bandgap and ADC2022-10-03T00:00:00+02:002022-10-03T00:00:00+02:00Fatsietag:chips4makers.io,2022-10-03:/blog/pdkmaster-circuits-and-layouts-for-bandgap-and-adc.html<p>After a first pure report on analog blocks scalability, I am happy to be able to report on
the first PDKMaster based circuits and layouts for the <a class="reference external" href="https://nlnet.nl/PET">NGI Zero PET</a>
funded
<a class="reference external" href="https://nlnet.nl/project/AMSL/index.html">Analog/Mixed-Signal Library</a> project in
this blog post. Reports on the scalability
<a class="reference external" href="static/20220621_BandgapReport.pdf">of a bandgap</a> and an
<a class="reference external" href="static/20220621_SARADCReport.pdf">ADC</a> circuits …</p><p>After a first pure report on analog blocks scalability, I am happy to be able to report on
the first PDKMaster based circuits and layouts for the <a class="reference external" href="https://nlnet.nl/PET">NGI Zero PET</a>
funded
<a class="reference external" href="https://nlnet.nl/project/AMSL/index.html">Analog/Mixed-Signal Library</a> project in
this blog post. Reports on the scalability
<a class="reference external" href="static/20220621_BandgapReport.pdf">of a bandgap</a> and an
<a class="reference external" href="static/20220621_SARADCReport.pdf">ADC</a> circuits were already
discussed in a <a class="reference external" href="first-analogmixed-signal-project-results.html">previous blog post</a>.
Now for these circuits a PDKMaster based circuit and layout generator have been implemented.</p>
<p>The bandgap implementation contains first version of code that does the sizing of the
transistors targeting minimum power consumption of the bandgap. The ADC implenentation
allows to quickly configure and generate a circuit and layout for an SAR ADC from 1 to 8
number of bits.</p>
<div class="section" id="voltage-reference-e-g-bandgap">
<h2>Voltage reference (e.g. bandgap)</h2>
<p>Based on the <a class="reference external" href="static/20220621_BandgapReport.pdf">bandgap report</a> a first implementation
has been made using the PDKMaster framework for a circuit and corresponding layout generation.
A notebook is used to generate these blocks; the output of the full run can be found
in the <a class="reference external" href="static/20221003_Bandgap.html">bandgap notebook</a>.</p>
<p>The ciruit and layout generation code can be found in
<a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-sky130/-/blob/blog20221003/c4m/pdk/sky130/bandgap.py">c4m.pdk.sky130.bandgap</a>
The classes in this module are <tt class="docutils literal">Bandgap</tt> and <tt class="docutils literal">BandgapCell</tt>.</p>
<p><tt class="docutils literal">Bandgap</tt> objects are only capable of circuit generation and simulation but no layout.
It is using continuous values for dimensions able to violate grid DRC rules etc. A first
version for the computation of an optimized version of a bandgap is implemented in the
<a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-sky130/-/blob/blog20221003/c4m/pdk/sky130/bandgap.py#L577-L589">compute_minpower()</a> method of the class. The target is to minimize the power consumed by
the bandgap. This method thus shows how the simulation support in PDKMaster can be used
in optimization.</p>
<p><tt class="docutils literal">BandgapCell</tt> objects on the other hand represent a circuit with corresponding layout
with dimensions of the structures that need to conform to the DRC rules. With the
<a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-sky130/-/blob/blog20221003/c4m/pdk/sky130/bandgap.py#L822-L836">convert2cell()</a> method a <tt class="docutils literal">Bandgap</tt> object can be converted to a <tt class="docutils literal">BandgapCell</tt> one.
As this is the first version of the class this separation in two classes may in the future
be removed before a general bandgap structure is upstreamed in a more generalized library.</p>
<p>In the <a class="reference external" href="static/20221003_Bandgap.html">bandgap notebook</a> one can see how this all is applied to three different
bandgap versions, one with 5V devices; one with low-Vt 1.8V devices and one with
regular Vt 1.8V devices. First <a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-sky130/-/blob/blog20221003/c4m/pdk/sky130/bandgap.py#L577-L589">compute_minpower()</a> is called and then converted to a
cell with layout using <a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-sky130/-/blob/blog20221003/c4m/pdk/sky130/bandgap.py#L822-L836">convert2cell()</a>.
Normally the resulting reference voltage should be around 1.2V but one can see that for
the versions with 1.8V devices - even the low-Vt ones - this value is not reached.
This means that the Vt of these devices is too high relative to the supply voltage
to give enough operation margin for the current mirror to work in saturation.</p>
<p>Although the <a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-sky130/-/blob/blog20221003/c4m/pdk/sky130/bandgap.py#L577-L589">compute_minpower()</a> seems to be able to compute a bandgap for the three
different varations of transistors it's also the first version that has room for
improvement. In good open source fashion this means that the code is open for
improvements or even for other stategies other than minimum power for computing the
bandgap transistor dimensions.</p>
</div>
<div class="section" id="adc">
<h2>ADC</h2>
<p>For the ADC it's <a class="reference external" href="static/20220621_SARADCReport.pdf">corresponding report</a> was used as
guidance. The choice was made to implement a single-ended ADC using the pre-amplifier
and the Lewis and Gray comparator as discussed in the document. The digital logic in
the sequencer has been changed slightly to better map to the cells available in the
<a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-flexcell">c4m-flexcell library</a>; more detail is available as <a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-sky130/-/blob/blog20221003/notebooks/ADC_support.py#L109-124">comment in the code</a>.
The simulation results in the <a class="reference external" href="static/20221003_ADC.html">notebook run</a> shows that the adapted sequencer works
as expected.</p>
<p>In this case using nominal value transistors for most of the transistors gave
results that was fast enough for a first version.
So the focus in this excercise was more on easy configuration of the number of bits for
the ADC rather than on deriving an optimized version. From the <a class="reference external" href="static/20221003_ADC.html">notebook run</a> one can
see the results of running the ADC generation for both an 8 bit and a 6 bit version and
it also results in a
<a class="reference external" href="static/20221003_adclib_Sky130.gds">gds file with 2 ADCs</a> in it.</p>
<img alt="" src="images/20221003_ADC8bit.png" />
<img alt="" src="images/20221003_ADC6bit.png" />
<p>Above are the 8bit ADC on the left and the 6bit version on the right. At the top of the
cell are capacitors and one can see the need for more capacitors for the 8bit ADC.</p>
<p>This shows the flexibility in configuration of the number of bits for the ADC based on the
flexibility of the PDKMaster framework. In more classical approaches for analog design a 6
bit version and a 8 bit version of an ADC would involve quite some more work in schematic
capture and layout generation.</p>
<p>As also said in the <a class="reference external" href="static/20221003_ADC.html">notebook</a> the use of PMOS switch to
capture the input voltage limits the input range of the ADC. This value will be further
investigated when an ADC will be put on a real tape-out.</p>
<p>For ADC the code has been done in <a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-sky130/-/blob/blog20221003/notebooks/ADC_support.py#L17">one class named ADC</a> in a file <a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-sky130/-/blob/blog20221003/notebooks/ADC_support.py">ADC_support.py</a> local
to the notebook. <a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-sky130/-/issues/4">c4m-pdk-sky130 issue 4</a> has been filed to move the ADC code into c4m.pdk.sky130.</p>
</div>
<div class="section" id="simulation-and-layout-support-code">
<h2>Simulation and layout support code</h2>
<p>For the simulations done for the bandgap some simulation support code has been provided in
<a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-sky130/-/blob/blog20221003/c4m/pdk/sky130/_simulation.py">c4m.pdk.sky130._simulation</a>.
This contains things like Ids vs Vgs simulation, result plotting support code etc.
This is thus more general code where at least part of it could be ripe for upstreaming;
<a class="reference external" href="https://gitlab.com/Chips4Makers/PDKMaster/-/issues/26">PDKMaster issue 26</a>
has been created to track this.</p>
<p>For the layout generation of both the bandgap and the ADC some common layout support code
has been used. It is available in
<a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-sky130/-/blob/blog20221003/c4m/pdk/sky130/_layout.py">c4m.pdk.sky130._layout</a>.
Currently a <tt class="docutils literal">class Sky130Layout</tt> is defined which is higher level layout generation
code using <tt class="docutils literal">class CircuitLayouter</tt> from PDKMaster internally.
<a class="reference external" href="https://gitlab.com/Chips4Makers/PDKMaster/-/issues/25">PDKMaster issue 25</a> has been filed
for upstreaming the code.</p>
</div>
<div class="section" id="under-construction">
<h2>Under construction</h2>
<p>The code for these two blocks still lives in the dev branch with complicated
inter-project dependencies when writing this code. A branch named <tt class="docutils literal">blog20221003</tt>
has been made on the related repos that should be consistent. So if one wants to reproduce
the generation of the block one needs to checkout this branch for the <tt class="docutils literal">PDKMaster</tt>,
<tt class="docutils literal"><span class="pre">c4m-flexcell</span></tt>, <tt class="docutils literal"><span class="pre">c4m-flexio</span></tt>, <tt class="docutils literal"><span class="pre">c4m-flexmem</span></tt> and the <tt class="docutils literal"><span class="pre">c4m-pdk-sly130</span></tt> repos. Don't
hesitate to contact me through one of the links on the left side if you want to try
this yourself.</p>
<p>Alternative is to wait until the layout generation code is upstreamed and the
circuit and layout generation live in the main branch(es) of the repo. After
completion of the
<a class="reference external" href="https://gitlab.com/Chips4Makers/PDKMaster/-/milestones/3">PDKMaster v0.9.0 milestone</a>
- which is still planned for this month - things should become more fit for external use and external contributions.</p>
</div>
Two More Reports on Scalable Analog blocks2022-09-30T00:00:00+02:002022-09-30T00:00:00+02:00Fatsietag:chips4makers.io,2022-09-30:/blog/two-more-reports-on-scalable-analog-blocks.html<p>The first results for the <a class="reference external" href="https://nlnet.nl/PET">NGI Zero PET</a> funded
<a class="reference external" href="https://nlnet.nl/project/AMSL/index.html">Analog/Mixed-Signal Library</a> project were
already presented in a <a class="reference external" href="first-analogmixed-signal-project-results.html">previous blog post</a>.
Now the scalability reports on the rest of the analog blocks have been made available by
<a class="reference external" href="https://www.lip6.fr">LIP6</a>; one for a DAC and one for a PLL.</p>
<div class="section" id="dac">
<h2>DAC</h2>
<p>A comparison …</p></div><p>The first results for the <a class="reference external" href="https://nlnet.nl/PET">NGI Zero PET</a> funded
<a class="reference external" href="https://nlnet.nl/project/AMSL/index.html">Analog/Mixed-Signal Library</a> project were
already presented in a <a class="reference external" href="first-analogmixed-signal-project-results.html">previous blog post</a>.
Now the scalability reports on the rest of the analog blocks have been made available by
<a class="reference external" href="https://www.lip6.fr">LIP6</a>; one for a DAC and one for a PLL.</p>
<div class="section" id="dac">
<h2>DAC</h2>
<p>A comparison was made between the so-called R-2R and a capacitive DAC architecture.
Scaling implication have been investigated and a comparison of the two architectures were
made. You can find the details <a class="reference external" href="static/20220930_DACReport.pdf">in the report</a> authored by
<a class="reference external" href="https://www-soc.lip6.fr/users/marie-minerve-louerat/">Marie-Minerve Louërat</a>.</p>
</div>
<div class="section" id="pll">
<h2>PLL</h2>
<p>Here the scalability implications of a classic PLL architecture with a phase-frequency
detector, a charge pump with loop filter and a voltage controlled oscillator (VCO) was
investigated. The details for this one can be found in <a class="reference external" href="static/20220930_PLLReport.pdf">the corresponding report</a> authored by <a class="reference external" href="https://www-soc.lip6.fr/en/users/dimitri-galayko/">Dimitri Galayko</a></p>
</div>
PDKMaster v0.2.0 and Demo Packages on Pypi2022-08-24T00:00:00+02:002022-08-24T00:00:00+02:00Fatsietag:chips4makers.io,2022-08-24:/blog/pdkmaster-v020-and-demo-packages-on-pypi.html<div class="section" id="pdkmaster-v0-2-0">
<h2>PDKMaster v0.2.0</h2>
<p>In <a class="reference external" href="first-analogmixed-signal-project-results.html">previous post on first results for analog/mixed-signal</a> I already mentioned I would update on the
status of PDKMaster development. This has taken me a few weeks more than planned but here
it is.</p>
<p>One of the targets in the <a class="reference external" href="https://nlnet.nl/PET">NGI Zero PET</a> funded
<a class="reference external" href="https://nlnet.nl/project/AMSL/index.html">Analog …</a></p></div><div class="section" id="pdkmaster-v0-2-0">
<h2>PDKMaster v0.2.0</h2>
<p>In <a class="reference external" href="first-analogmixed-signal-project-results.html">previous post on first results for analog/mixed-signal</a> I already mentioned I would update on the
status of PDKMaster development. This has taken me a few weeks more than planned but here
it is.</p>
<p>One of the targets in the <a class="reference external" href="https://nlnet.nl/PET">NGI Zero PET</a> funded
<a class="reference external" href="https://nlnet.nl/project/AMSL/index.html">Analog/Mixed-Signal Library</a> project is to
develop PDKMaster up to a state it can be used externally and is ready for external
contributions. The <a class="reference external" href="https://pypi.org/project/PDKMaster/0.2.0/">v0.2.0 release</a> of
<a class="reference external" href="https://gitlab.com/Chips4Makers/PDKMaster/">PDKMaster</a> is a step in this
direction. (<a class="reference external" href="https://pypi.org/project/PDKMaster/0.2.1/">v0.2.1 release</a>
is a small bug fix release fixing a dependency issue)</p>
<p>First part was focused on documentation. Sphinx has been set up to extract autodoc strings
from the code and a first set of documentation is provided by adding some autodoc strings
to the PDKMaster code base. Currently the documentation is not hosted on a public web site
yet. This will be done once the code is deemed ready for external usage. For now you can
checkout the code, setting up the environment as said in the README.md file and the running
'<tt class="docutils literal">doit docs</tt>' and then you will find the docs in the '<tt class="docutils literal">docs/html</tt>' directory.</p>
<p>Second part was to work on QA. For this a first set of unit tests have been written and
<a class="reference external" href="https://gitlab.com/Chips4Makers/PDKMaster/-/pipelines">CI</a> has
been set up to run these unit tests. This is common development practice to avoid regressions
with new commits.</p>
</div>
<div class="section" id="demo-packages-on-pypi">
<h2>Demo Packages on Pypi</h2>
<p>For demo purposes also packages of the different Chips4Makers repos including the
PDKMaster based version of sky130 PDK have been released on <a class="reference external" href="https://pypi.org/">pypi</a>.
As said the code base is currently not considered to fit for external usage. All this is
released as-is and no support whatsoever can currently be provided. This is planned onwards
from release v0.9.0 of PDKMaster.</p>
<p>The list of related packages is:</p>
<ul class="simple">
<li><a class="reference external" href="https://pypi.org/project/c4m-flexcell/0.1.0/">c4m-flexcell v0.1.0</a></li>
<li><a class="reference external" href="https://pypi.org/project/c4m-flexio/0.1.0/">c4m-flexio v0.1.0</a></li>
<li><a class="reference external" href="https://pypi.org/project/c4m-flexmem/0.0.4/">c4m-flexmem v0.0.4</a></li>
<li><a class="reference external" href="https://pypi.org/project/c4m-pdk-sky130/0.0.2">c4m-pdk-sky130 v0.0.2</a></li>
</ul>
<p>One should be able to install everything with the command '<tt class="docutils literal">pip install <span class="pre">c4m-pdk-sky130</span></tt>'</p>
</div>
<div class="section" id="pdkmaster-v0-3-0">
<h2>PDKMaster v0.3.0</h2>
<p>Although this release and announcement has taken some in the mean time work has already been
done on PDKMaster v0.3.0.</p>
<p>The target for that release:</p>
<ul class="simple">
<li>100% code coverage for the unit tests</li>
<li>autodoc strings for all classes and non-trivial functions and methods</li>
<li>features needed for other tasks in the
<a class="reference external" href="https://nlnet.nl/project/AMSL/index.html">Analog/Mixed-Signal Library</a></li>
</ul>
</div>
First Analog/Mixed Signal Project Results2022-06-15T00:00:00+02:002022-06-15T00:00:00+02:00Fatsietag:chips4makers.io,2022-06-15:/blog/first-analogmixed-signal-project-results.html<p>In a previous professional life I have been working on radiation hardened SRAM compiler design
amongst other things. There I used Cadence Virtuoso for analog circuit development. It is one
of the proprietary reference analog design platforms. As a hobby I was also doing open source
software development enjoying the …</p><p>In a previous professional life I have been working on radiation hardened SRAM compiler design
amongst other things. There I used Cadence Virtuoso for analog circuit development. It is one
of the proprietary reference analog design platforms. As a hobby I was also doing open source
software development enjoying the big potential development acceleration that can be seen
through open source community based development. As an open source proponent I also longed
for a world where analog blocks would be developed with an open source mindset.</p>
<p>The main driver of the open source community is IMO not the availabillity of the source itself
but the process of having a whole community working on a gradual improvement of the open
source code base through smaller and bigger patches. Classically analog design is a lot of
times done as design to spec; e.g. the specification for a block is written down and then a
circuit is designed according to this specification. When specifications are changed
typically big part of the design and layout have to be redone. This methodology is not very
compatible with the gradual improvement flow hinted to above.</p>
<p>Recently the idea of (open source) scripted analog generators has seen renewed interest
(BAG: <a class="reference external" href="https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-23.pdf">paper</a> & <a class="reference external" href="https://github.com/ucb-art/BAG_framework">github</a>,
<a class="reference external" href="https://fasoc.engin.umich.edu/">OpenFASOC</a>, <a class="reference external" href="https://www-soc.lip6.fr/equipe-cian/logiciels/oceane/">Oceane</a>, ...)
due to the Sky130 open source PDK and the Google sponsored MPW runs. These developments are in
their early development phase and it is good that different approaches are investigated so a
good open source analog development methodology can grow out of these developments; including
cross-pollination between the projects.</p>
<p>Since last year I am working on a project funded by <a class="reference external" href="https://nlnet.nl/PET">NGI Zero PET</a> named
<a class="reference external" href="https://nlnet.nl/project/AMSL/index.html">Analog/Mixed-Signal Library</a>.
As described on the project page, it consists on completing/extending <a class="reference external" href="https://gitlab.com/Chips4Makers/PDKMaster">PDKMaster</a> to allow
scalable analog generators, use the framework on selected analog circuits and get them used
in a digital HDL-to-GDS ASIC flow. The focus of the project is on building the needed base
framework that will allow to use the open source gradual improvement workflow
also for analog circuits.</p>
<p>This blog post will focus on the progress on the analog circuits design. <a class="reference external" href="https://gitlab.com/Chips4Makers/PDKMaster">PDKMaster</a> has
been discussed in a
<a class="reference external" href="pdkmaster-v01-release-and-freepdk45-example.html">previous post</a>
but a lot of development has been done in the mean time. This will be discussed in a
follow-up post.</p>
<p>For the development of the <a class="reference external" href="https://gitlab.com/Chips4Makers/PDKMaster">PDKMaster</a> based analog block generators four test structures were
selected:</p>
<ul class="simple">
<li>A voltage reference</li>
<li>A PLL (phase-locked-loop)</li>
<li>A lower precision, lower speed ADC (analog-to-digital converter)</li>
<li>A lower precision, lower speed DAC (digital-to-analog converter)</li>
</ul>
<p>One of the selection criteria for the circuits is to not have too complex circuits and where
applicable trade off performance for less analog circuit complexity. This is to
ensure development can be focused on the analog block generator rather than on
the needed analog design effort for the blocks itself. Once this project is finished the
source code of the blocks should then be the base code on which improvements can be made.</p>
<div class="section" id="analog-circuits-scaling-reports">
<h2>Analog circuits scaling reports</h2>
<p>The design of the analog block itself is done in cooperation with
<a class="reference external" href="https://www.lip6.fr">LIP6</a> at the
<a class="reference external" href="https://www.sorbonne-universite.fr">Sorbonne Université</a>. They are
doing a more classical design of the analog blocks but with a focus on having circuit
architectures that can be scaled to different technolgy nodes. They then make reports
on the blocks to be used by me (e.g. Staf Verhaegen) as base for the <a class="reference external" href="https://gitlab.com/Chips4Makers/PDKMaster">PDKMaster</a>
based analog block generators.</p>
<p>Three reports are now made available:</p>
<ul class="simple">
<li>Voltage reference report</li>
<li>ADC report</li>
<li>VCO report</li>
</ul>
<p>Work is ongoing on completing the design reports on the full PLL circuit and a
DAC.</p>
<div class="section" id="voltage-reference">
<h3>Voltage Reference</h3>
<p>The report on the voltage reference that is commonly known as a bandgap was made by
<a class="reference external" href="https://www-soc.lip6.fr/en/users/dimitri-galayko/">Dimitri Galayko</a> and discusses the generic design of a relatively simple bandgap circuit.
The design has been tested in simulation for AMS 0.35µm and TSMC 0.18µm technology.
The report is provided as a <a class="reference external" href="static/20220621_BandgapReport.pdf">PDF file</a>.</p>
</div>
<div class="section" id="adc">
<h3>ADC</h3>
<p>This report has been delivered by
<a class="reference external" href="https://www-soc.lip6.fr/users/marie-minerve-louerat/">Marie-Minerve Louërat</a> and
<a class="reference external" href="https://www.lip6.fr/actualite/personnes-fiche.php?ident=P491">Jacky Porte</a>. It
discusses a SAR (successive approximation register) ADC (analog-to-digital converter). In
<a class="reference external" href="static/20220621_SARADCReport.pdf">the PDF</a>, the design of an 8 bit SAR ADC is done using
the <a class="reference external" href="https://www-soc.lip6.fr/equipe-cian/logiciels/oceane/">Oceane</a> software is discussed together with scaling considerations.</p>
</div>
<div class="section" id="vco">
<h3>VCO</h3>
<p>VCO stands for voltage-controlled and is one the main subblocks in the PLL.
<a class="reference external" href="https://www-soc.lip6.fr/en/users/dimitri-galayko/">Dimitri Galayko</a> has now made the report
on the VCO and node scalability; it is delivered again as a
<a class="reference external" href="static/20220621_VCOReport.pdf">PDF file</a>.</p>
</div>
</div>
<div class="section" id="first-pdkmaster-based-bandgap-design">
<h2>First PDKMaster based Bandgap design</h2>
<p>Based on Dimitri's bandgap report a first version of a bandgap design using the PDKMaster
framework has been done in a <a class="reference external" href="static/20220606_Bandgap3V3.html">Sky130 python notebook</a>.
In the notebook you can find the design of the circuit and some performance analysis.
This is currently a non-optimized bandgap design. Layout has been generated though and
has been submitted for <a class="reference external" href="https://platform.efabless.com/projects/1042">Sky130 MPW6</a>
(confirmation still pending).</p>
<img alt="" src="images/20220613_Bandgap3V3.png" />
<p>Currently this is a preliminary version and will be further developed to allow the user to
for example trade-off between area, power consumption and accuracy. The design notebook
used for the bandgap design is also very preliminary as <a class="reference external" href="https://gitlab.com/Chips4Makers/PDKMaster">PDKMaster</a> is still under heavy
development. As said above in a follow-up post the state of the <a class="reference external" href="https://gitlab.com/Chips4Makers/PDKMaster">PDKMaster</a> development will
be discussed further.</p>
</div>
Retro-µC 2021 Test Tape-out2021-11-28T00:00:00+01:002021-11-28T00:00:00+01:00Fatsietag:chips4makers.io,2021-11-28:/blog/retro-mc-2021-test-tape-out.html<img alt="" src="images/20211124_top_2dice_screenshot.png" style="width: 60%;" />
<p>I found some time to work on the Retro micro-controller again and
perform a test tape-out in TSMC 0.35um technology. I was also
contacted by Matt Venn for an interview. We agreed to also discuss
this tape-out during the interview. This relieved me from the (in
my eyes) boring …</p><img alt="" src="images/20211124_top_2dice_screenshot.png" style="width: 60%;" />
<p>I found some time to work on the Retro micro-controller again and
perform a test tape-out in TSMC 0.35um technology. I was also
contacted by Matt Venn for an interview. We agreed to also discuss
this tape-out during the interview. This relieved me from the (in
my eyes) boring task of writing an extensive blog post on it.
<a class="reference external" href="https://www.youtube.com/watch?v=agXJeIpdU6I">The interview</a> is
published on Matt Venn's <a class="reference external" href="https://www.youtube.com/c/ZeroToASIC">Zero To ASIC Course YouTube channel</a>.</p>
<p>Just wanted to do a little additional expectation management. Due to
the current chip squeeze TSMC is less tolerant for canceled MPW
(multi-project wafer) reservations. In order to meet the deadline for
this run I did take several shortcuts, amongst others in verifying the
design and the P&R outcome. So I would not be surprised if this chip
isn't working. I did achieve the goal though of setting up the use of
Coriolis for place-and-route together with the standard cell library I am
developing.</p>
NLnet018TV Measurement Report2021-05-19T00:00:00+02:002021-05-19T00:00:00+02:00Fatsietag:chips4makers.io,2021-05-19:/blog/nlnet018tv-measurement-report.html<p>Almost a year ago I reported on the <a class="reference external" href="nlnet018tv-a-fully-automated-test-chip-design.html">NLnet018TV test chip design</a> for <a class="reference external" href="https://nlnet.nl/project/Chips4Makers/index.html">my NLnet project</a>.
I did have verification measurements of the chip available now for several weeks but because of the <a class="reference external" href="https://libre-soc.org/180nm_Oct2020/">Libre-SOC prototype tape-out</a> taking all of my time I did not find time and motivation to summarize …</p><p>Almost a year ago I reported on the <a class="reference external" href="nlnet018tv-a-fully-automated-test-chip-design.html">NLnet018TV test chip design</a> for <a class="reference external" href="https://nlnet.nl/project/Chips4Makers/index.html">my NLnet project</a>.
I did have verification measurements of the chip available now for several weeks but because of the <a class="reference external" href="https://libre-soc.org/180nm_Oct2020/">Libre-SOC prototype tape-out</a> taking all of my time I did not find time and motivation to summarize the measurements for this blog up to now.</p>
<p>The test chip was manually wirebonded in 85-pin PGA package using <a class="reference external" href="https://europractice-ic.com/packaging-integration/standard-packaging/">Europractice's standard packaging services</a> through <a class="reference external" href="https://www.imec-int.com/">imec</a> as can be seen in the following picture:</p>
<img alt="" src="images/20210519_PackagedChip.jpg" style="width: 50%;" />
<p>For this PGA package a PCB adapter board was designed to make it easier to connect to the different pins. The KiCad design files of the PCB can be found <a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite/-/tree/master/designs/NLNet018TV/testing/PGA85_Adapter">here</a>. For production of the PCBs I used <a class="reference external" href="https://jlcpcb.com/">JLCPCB</a>. Below you find the picture of the PCB on the left and on the right the PCB with the chip and headers soldered on and pins connected for measurement:</p>
<img alt="" src="images/20210519_PGA85AdapterPCB.jpg" style="width: 38%;" />
<img alt="" src="images/20210519_PGA85AdapterSetup.jpg" style="width: 40%;" />
<p>I already reported on my adventures with the <a class="reference external" href="https://www.analog.com/en/products/ad5522.html">AD5522 SMU</a> in the <a class="reference external" href="tag/pm-smu.html">Poor Men's SMU</a> thread. I also used this SMU to meaure the NLnet018TV test chip.</p>
<p>The full report of the actual measurement can be found <a class="reference external" href="static/20210519_NLNet018TV_MeasReport.html">here</a>; original notebook and saved data can be retrieved from the <a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite/-/tree/master/designs/NLNet018TV/testing/AD5522/RaspberryPi">snowwhite repository</a>. The notebook is called <cite>NLNet018TV_meas.ipynb</cite> and the measured data <cite>NLNet018TV.npz</cite>. In the rest of the blog a summary of the measurements will be given. The main message is that no showstoppers were discovered for the Libre-SOC prototype tape-out; IO and SRAM cell are working fine.</p>
<div class="section" id="sr-latches">
<h2>SR Latches</h2>
<p>Functionality of SR latches has been succesfully verified and drive strength measured. More details are in the <a class="reference external" href="static/20210519_NLNet018TV_MeasReport.html">measurement report</a>.</p>
</div>
<div class="section" id="io-cells">
<h2>IO cells</h2>
<ul class="simple">
<li>The logic cell and IO themselves were succesfully powered by the designed IO cells</li>
<li>For same designed drive strength the source current was relatively higher than the sink current (plot is below). For the prototpye the design is slightly adapted to bring them closer together.</li>
<li>For the input the switching threshold is around 0.92V; this is still acceptable as it is higher than the 0.8V Vil of TTL and LVCMOS but ideally this would be closer to the 1.5V Vt of TTL and LVCMOS.</li>
</ul>
<p>IO drive strength plot (pu=pull-up, pd=pull-down); left all curves, right zoom in on pull-up/pull-down functionality drive strength:</p>
<img alt="" src="images/20210519_IODriveStrength.png" style="width: 60%;" />
<p>The plots are clipped around 22µA due to measurement limits imposed by the <a class="reference external" href="https://www.analog.com/en/products/ad5522.html">AD5522 SMU</a>.</p>
</div>
<div class="section" id="sram-cell">
<h2>SRAM cell</h2>
<ul class="simple">
<li>The measured hold static noise margin (SNM) is around 600mV (plot below). This metric is a measuremnt for the SRAM robustness but detailed explanation goes too far for this blog. The measured value is very satisfactory as a value of 200-300mV would still be acceptable.</li>
<li>Due to a design mistake read SNM could not be measured but write-trip point measurement still show robustness of the cell when word line is open and both bitlines are forced high.</li>
<li>A write-trip point of around 0.80 V was measuremed (plot below); this is also a good value as there is enough margin to both ground and supply voltage.</li>
</ul>
<p>SRAM plots, left hold SNM, right WTP.</p>
<img alt="" src="images/20210519_SRAM_SNMWTP.png" style="width: 60%;" />
</div>
PDKMaster v0.1 release and FreePDK45 example2021-03-15T00:00:00+01:002021-03-15T00:00:00+01:00Fatsietag:chips4makers.io,2021-03-15:/blog/pdkmaster-v01-release-and-freepdk45-example.html<p>After a lot of blood, sweat and tears I have now reached a new milestone for my NGI0 NLnet project. I released v0.1 of the PDKMaster python framework together with a standard cell library generator and an example PDK implementation for the FreePDK45 technology.
It consist of the following …</p><p>After a lot of blood, sweat and tears I have now reached a new milestone for my NGI0 NLnet project. I released v0.1 of the PDKMaster python framework together with a standard cell library generator and an example PDK implementation for the FreePDK45 technology.
It consist of the following three releases:</p>
<ul>
<li><p class="first"><a class="reference external" href="https://pypi.org/project/PDKMaster/0.1">PDKMaster v0.1 (PyPI)</a></p>
<p>PDK Master is a tool to manage PDKs for ASIC design and a framework for designing circuits and layouts in those technologies. It consists of different parts:</p>
<ul class="simple">
<li>Python classes to descibe the primitives of a technology like the process layers use in a design and the devices that can be made in the technology. The definition of the technology also contains the design rules that need to be obeyed so this all can be derived</li>
<li>Python classes to represent circuit and layouts using these primitives and conforming to their design rules. Focus is on easy parameterized circuit design and layout with effortless scalability between technologies.</li>
<li>Export functions to generate the setup files for other tools, currently Coriolis P&R and klayout design viewer/editor.</li>
<li>Simulation interface so circuits defined in PDKMaster can be simulated.</li>
</ul>
</li>
<li><p class="first"><a class="reference external" href="https://pypi.org/project/c4m-flexcell/0.0.4/">c4m-flexcell v0.0.4 (PyPI)</a></p>
<p>This is a scalable standard cell library used to generate the standard cells that are part of the FreePDK45 PDKMaster release but also used for the tape-out of the <a class="reference external" href="https://nlnet.nl/project/Libre-RISCV/">libre-SOC 0.18um prototype</a> using a NDAed PDK.</p>
</li>
<li><p class="first"><a class="reference external" href="https://pypi.org/project/c4m-pdk-freepdk45/0.0.1/">c4m-pdk-freepdk45 v0.0.1 (PyPI)</a>, <a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-freepdk45/-/releases/v0.0.1">tarball</a></p>
<p>This has two different release forms, one on PyPI with only the PDKMaster based FreePDK45 PDK and a more complete tarball that contains also the exported files:</p>
<ul class="simple">
<li>The python module source code, the FreePDK45 technology description is mainly <a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-pdk-freepdk45/-/blob/v0.0.1/c4m/pdk/freepdk45/pdkmaster.py">one python file</a> from which everything else is generated.</li>
<li>Generated support files for Coriolis P&R and KLayout FreePDK45 viewing editing</li>
<li>The c4m-flexcell generated FlexLib standard cell library with gds, spice, verilog, VHDL and liberty file views.</li>
<li>Example flow to synthesize and place-and-route Arlet's 6502 core using Coriolis.</li>
<li>Example python notebook showing PDKMaster's ability to combine parametric design and layout in one file. The example is the design of a minimum area balanced inverter.</li>
</ul>
</li>
</ul>
<p>More details can be found in each of the links of the release. This work is under heavy development and unfortunately not much more documentation is available other than the linked to README files. Also the API is currently highly unstable with every new commit likely breaking current code. If that doesn't stop you don't hesitate to contact me on one of the links on the left or on the <a class="reference external" href="https://gitter.im/Chips4Makers/community">gitter Chips4Makers community page</a>.</p>
Poor Men's SMU, part 4: Calibration2021-02-11T00:00:00+01:002021-02-11T00:00:00+01:00Fatsietag:chips4makers.io,2021-02-11:/blog/poor-mens-smu-part-4-calibration.html<p>As reported in my <a class="reference external" href="poor-mens-smu-part-3-diodes-are-forever.html">previous blog</a> on using the <a class="reference external" href="https://www.analog.com/en/products/ad5522.html">AD5522</a> SMU <a class="reference external" href="https://wiki.analog.com/resources/eval/ad5522_user_guide">development board</a> it was mentioned calibration would be needed to get more accurate low-voltage and low-current measurements.</p>
<div class="section" id="procedure">
<h2>Procedure</h2>
<p>An important aspect of doing calibration is the order in which the parameters are calibrated and what references are used during …</p></div><p>As reported in my <a class="reference external" href="poor-mens-smu-part-3-diodes-are-forever.html">previous blog</a> on using the <a class="reference external" href="https://www.analog.com/en/products/ad5522.html">AD5522</a> SMU <a class="reference external" href="https://wiki.analog.com/resources/eval/ad5522_user_guide">development board</a> it was mentioned calibration would be needed to get more accurate low-voltage and low-current measurements.</p>
<div class="section" id="procedure">
<h2>Procedure</h2>
<p>An important aspect of doing calibration is the order in which the parameters are calibrated and what references are used during the calibration. The order is important as metrics are correlated; for example calibrating input offsets should be calibrated before output offsets are calibrated as otherwise the input offset will wrongly seen as a measurement offset.</p>
<p>To improve the measurements I wanted to calibrate the following parameters:</p>
<ol class="arabic simple">
<li>gain error</li>
<li>force offset</li>
<li>measurement offset</li>
</ol>
<p>These errors are also the ones advised in the AD5522 data sheet to be calibrated. It does assume the 5V reference and linearity of the <a class="reference external" href="https://www.analog.com/en/products/ad5522.html">AD5522</a> SMU and the <a class="reference external" href="https://www.analog.com/en/products/ad7685.html">AD7685</a> ADC are accurate enough.</p>
<p>The gain error is calibrated by forcing the extreme value for voltage or current and measuring the resulting voltage or current. The gain error can then be computed out of the dialed in and measured range.</p>
<p>For the force offset calibration I did by trying to push the SMU to a value it can't achieve so it will clamp on the maximum force compliance. For example if you have a channel open and try force the SMU to have a certain current it will not reach the current as not current can flow. The SMU will clamp instead on the maximum voltage for a positive current and on the maximum negative voltage for a negative current. Sweeping the current from negative to positive one can find the point at which the SMU goes from clamping to negative voltage to clamping to positive voltage. This value then gives the force offset.</p>
<p>After calibration of the force offset then the measurement offset is determined by forcing a 0 value for current or voltage on the input and measuring the resulting output.</p>
<p>This procedure has been carried out in a python notebook that drives the SMU and investigate the details in <a class="reference external" href="static/20210211_Calibration.html">the notebook</a>. The resulting values of the calibration are also in that document.</p>
</div>
<div class="section" id="integration">
<h2>Integration</h2>
<p>Currently the calibration parameters have been included in the AD5522 python support code. I hard coded the calibration parameters in the init of the python class. When the board is initialized now the calibration parameters are set on the SMU.</p>
<p>The current calibration procedure is not ideal to squeeze out the last possible accuracy out of the board but is considered good enough for the measurements I want to do with it.</p>
</div>
<div class="section" id="diodes-revisited">
<h2>Diodes revisited</h2>
<p>After this calibration procedure was done I then went back to the <a class="reference external" href="poor-mens-smu-part-3-diodes-are-forever.html">diodes measurement</a>. But it did not seem to have improved the situation as can be seen from the results of redoing the forced voltage measurement:</p>
<img alt="" src="images/20210211_Diodes_uncovered.png" />
<p>I did not understand this measurement until I covered the diodes with a towel and then I got the following measurement:</p>
<img alt="" src="images/20210211_Diodes_covered.png" />
<p>This is more what I expected. LEDs are also photosensitive and when they are not covered they will generate a small current due to the light that is falling on them. This also shows that the SMU is capable of measuring current with an accury of at least a few nA which is better than I expected.</p>
</div>
Poor Men's SMU, part 3: Diodes are Forever2021-01-17T00:00:00+01:002021-01-17T00:00:00+01:00Fatsietag:chips4makers.io,2021-01-17:/blog/poor-mens-smu-part-3-diodes-are-forever.html<p>This is third part on my adventures with the <a class="reference external" href="https://www.analog.com/en/products/ad5522.html">AD5522</a> SMU <a class="reference external" href="https://wiki.analog.com/resources/eval/ad5522_user_guide">development board</a>. For history you can look at <a class="reference external" href="poor-mens-source-measurement-unit-smu.html">part 1</a> and <a class="reference external" href="poor-mens-smu-part-2.html">part 2</a>.</p>
<p>After getting the SMU working and being able to operate it from Jupyter notebooks on a raspberry Pi I now decided to use the device to …</p><p>This is third part on my adventures with the <a class="reference external" href="https://www.analog.com/en/products/ad5522.html">AD5522</a> SMU <a class="reference external" href="https://wiki.analog.com/resources/eval/ad5522_user_guide">development board</a>. For history you can look at <a class="reference external" href="poor-mens-source-measurement-unit-smu.html">part 1</a> and <a class="reference external" href="poor-mens-smu-part-2.html">part 2</a>.</p>
<p>After getting the SMU working and being able to operate it from Jupyter notebooks on a raspberry Pi I now decided to use the device to measure some diodes/LEDs. I did the measurement and the plotting again in a Python notebook. I also used the notebook to comment on the results. Head over to the <a class="reference external" href="static/20210117_Diodes.html">html version of the notebook</a> to learn all about the diode and LED results.</p>
<p>As indicated in the notebook, the SMU needs to be calibrated to be able to measure smaller values accurately. So that is what I am currently working on and (hopefully) you will here more about this in the near future.</p>
Poor Men's SMU, part 22021-01-09T00:00:00+01:002021-01-09T00:00:00+01:00Fatsietag:chips4makers.io,2021-01-09:/blog/poor-mens-smu-part-2.html<p>This is a continuation of my adventure with the AD5522 <a class="reference external" href="https://wiki.analog.com/resources/eval/ad5522_user_guide">development board</a> (see <a class="reference external" href="poor-mens-source-measurement-unit-smu.html">part 1</a> ). I did make progress on setting it up but as always it has taken much more time than wanted to debug the setup.</p>
<div class="section" id="schrodinger-s-cat">
<h2>Schrödinger's cat</h2>
<p>One problem I had to solve was that the setup …</p></div><p>This is a continuation of my adventure with the AD5522 <a class="reference external" href="https://wiki.analog.com/resources/eval/ad5522_user_guide">development board</a> (see <a class="reference external" href="poor-mens-source-measurement-unit-smu.html">part 1</a> ). I did make progress on setting it up but as always it has taken much more time than wanted to debug the setup.</p>
<div class="section" id="schrodinger-s-cat">
<h2>Schrödinger's cat</h2>
<p>One problem I had to solve was that the setup sometimes seemed to work flawlessly but other times not. Especially when I tried to debug the setup by looking at it though an oscilloscope all seemed to work but it did not seem to work when not looking at it.</p>
<p>After some more debugging I found out that the circuit did not work either when I used the oscilloscope probe in the 10X setting. This seems to indicate a problem with signal integrity that can be solved by adding load on the lines. I now added a 120Ω resistor on the SPI clock and chip select signals and my problems seem to be solved.</p>
</div>
<div class="section" id="raspberry-pi">
<h2>Raspberry Pi</h2>
<p>I decided to use a Raspberry Pi to access the SPI interface for the <a class="reference external" href="https://www.analog.com/en/products/ad5522.html">AD5522</a> SMU and the <a class="reference external" href="https://www.analog.com/en/products/ad7685.html">AD7685</a> ADC; giving the following setup:</p>
<img alt="" src="images/20210109_Setup.jpg" style="width: 80%;" />
<p>It's not pretty but ItWorks™. The <a class="reference external" href="https://www.meanwell.com/webapp/product/search.aspx?prod=PT-65">PT-65C</a> already shown in <a class="reference external" href="poor-mens-source-measurement-unit-smu.html">part 1</a> is connected to the supply pins of the development board, the ground of the Raspberry Pi and the dev board are also connected together. Both chip select signals of SPI device 0 are used, the first for the <a class="reference external" href="https://www.analog.com/en/products/ad5522.html">AD5522</a>, the second for the <a class="reference external" href="https://www.analog.com/en/products/ad7685.html">AD7685</a>. Both the MISO from the <a class="reference external" href="https://www.analog.com/en/products/ad5522.html">AD5522</a> and the <a class="reference external" href="https://www.analog.com/en/products/ad7685.html">AD7685</a> are connected to the MISO pin of SPI device 0. This signal can be shared as it will only be driven by the chips when their chip select is activated.</p>
<p>I was still using Raspbian 9 based on the debian stretch release when doing the setup and I got it all working. As I am using python I did wanted to have a newer python as the python 3 version on stretch is 3.5 which like features like the f-strings etc. I decided to upgrade the version based on debian buster and now called Raspberry Pi OS. Unfortunately this also caused problems. The problem found is that the SPI driver on the latter version gives extra chip select signals.</p>
<p>In the following pictures the SPI clock is given in yellow and the chips select (active low) as purple. First the good one on older version of the OS:</p>
<img alt="" src="images/20210109_SPIStretch.png" style="width: 45%;" />
<p>Now the one on the latest version of the OS where one can see the second enabling of the chips select signal:</p>
<img alt="" src="images/20210109_SPIBuster.png" style="width: 45%;" />
<p>Unfortunately this extra chip select let the SMU perform a write to a register which makes it unusable. This has taken quite some time to debug as this problem was seen at the same time as the first problem and it took a long time to realize there are actually two problems. But in the end I seem to have ended with a working setup in the old Raspbian version.</p>
</div>
<div class="section" id="python-notebook">
<h2>Python notebook</h2>
<p>As said earlier I am using python to drive the dev board through a SPI interface. Especially I am running a Jupyter notebook server on Raspberry Pi and accessing it from Firefox on my Linux amd64 desktop computer. I replicated now the IV curve done in <a class="reference external" href="poor-mens-source-measurement-unit-smu.html">part 1</a> with the Analog Devices software in a Jupyter notebook (<a class="reference external" href="static/IVTest.html">IV Test notebook static version</a>).</p>
<p>To be (hopefully) continued...</p>
</div>
Poor Men's Source Measurement Unit (SMU)2021-01-03T00:00:00+01:002021-01-03T00:00:00+01:00Fatsietag:chips4makers.io,2021-01-03:/blog/poor-mens-source-measurement-unit-smu.html<div class="section" id="smu">
<h2>SMU ?</h2>
<p>In my previous professional life doing semiconductor process development I used so called <a class="reference external" href="https://en.wikipedia.org/wiki/Source_measure_unit">source measure units</a> (SMUs) for measuring out transistors. Although I don't remember the exact type number, I guess I had access to a <a class="reference external" href="https://www.keysight.com/en/pd-542807-pn-4145B/semiconductor-parameter-analyzers?nid=-536900419.536905445.00&cc=BE&lc=fre">HP 4145A</a> semiconductor parametric analyzer.</p>
<p>Nice thing about these units is that these …</p></div><div class="section" id="smu">
<h2>SMU ?</h2>
<p>In my previous professional life doing semiconductor process development I used so called <a class="reference external" href="https://en.wikipedia.org/wiki/Source_measure_unit">source measure units</a> (SMUs) for measuring out transistors. Although I don't remember the exact type number, I guess I had access to a <a class="reference external" href="https://www.keysight.com/en/pd-542807-pn-4145B/semiconductor-parameter-analyzers?nid=-536900419.536905445.00&cc=BE&lc=fre">HP 4145A</a> semiconductor parametric analyzer.</p>
<p>Nice thing about these units is that these allow 4-quadrant operation, e.g. allow all the 4 combinations of positive or negative voltage with positive or negative current. It allows to force a voltage and measure current or the other way around.</p>
<p>In my new professional life working on open source semiconductors I don't have that luxury anymore. I did look on-line but even second hand version of an old <a class="reference external" href="https://www.keysight.com/en/pd-542807-pn-4145B/semiconductor-parameter-analyzers?nid=-536900419.536905445.00&cc=BE&lc=fre">HP 4145A</a> costs too much for the numbers of times I will need such equipment. From the other side switching to single-quadrant power supplies and loads was not really the way I wanted to go. So I was on the look-out for a better solution.</p>
</div>
<div class="section" id="ad5522">
<h2>AD5522</h2>
<p>After much searching around I found the Analog Devices <a class="reference external" href="https://www.analog.com/en/products/ad5522.html">AD5522</a> chip and it's companion <a class="reference external" href="https://wiki.analog.com/resources/eval/ad5522_user_guide">development board</a>. Although this chip is not in the same range as the <a class="reference external" href="https://www.keysight.com/en/pd-542807-pn-4145B/semiconductor-parameter-analyzers?nid=-536900419.536905445.00&cc=BE&lc=fre">HP 4145A</a> regarding the specifications it should still allow to fulfill my measurement needs at a much lower cost than that high precision equipment.</p>
</div>
<div class="section" id="first-test">
<h2>First test</h2>
<p>So I went ahead and bought the <a class="reference external" href="https://wiki.analog.com/resources/eval/ad5522_user_guide">development board</a> together with a Mean Well <a class="reference external" href="https://www.meanwell.com/webapp/product/search.aspx?prod=PT-65">PT-65C</a> power supply board. To house the Mean Well power supply I repurposed the case and the switch of a failed Amiga 1200 power supply as can be seen from the next photo:</p>
<img alt="" src="images/20210103_Meanwell.jpg" style="width: 45%;" />
<p>The Analog Devices support software runs only under Windows and I don't have a Windows computer set up anymore. So I needed to set up a virtual machine with the software installed. Luckily USB port forwarding to the virtual machine did work to access the <a class="reference external" href="https://wiki.analog.com/resources/eval/ad5522_user_guide">development board</a> with the support software through a USB connection from my Mint 20 Linux machine.</p>
<p>I connected a 6.2KΩ resistor to the output of channel 3. In the next plot one can see that a voltage sweep from -6V to 6V correctly results in a measured current going from -1mA to 1mA:</p>
<img alt="" src="images/20210103_AD5522_sweep.png" style="width: 45%;" />
<p>Currently I am playing with a Raspberry Pi to use one of it's SPI interfaces on it's 40 pin header to setup and drive the <a class="reference external" href="https://www.analog.com/en/products/ad5522.html">AD5522</a>. First results seem to be encouraging and the plan is to use this setup then to perform the measurement tests on the <a class="reference external" href="nlnet018tv-a-fully-automated-test-chip-design.html">NLNet018TV</a>.</p>
<p>Story (hopefully) to be continued...</p>
</div>
Fixing the ESD generator2020-11-01T00:00:00+01:002020-11-01T00:00:00+01:00Fatsietag:chips4makers.io,2020-11-01:/blog/fixing-the-esd-generator.html<p>This is a continuation on <a class="reference external" href="first-testing-of-and-changes-to-esd-generator.html">my previous blog on first tests on the ESD generator</a>.</p>
<div class="section" id="problems">
<h2>Problems</h2>
<p>After some more debugging the voltage multiplier of the ESD Generator has been made to work. Detailed simulation results of the problems can be found in this <a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite/-/blob/blog20201101/designs/NLNet018TV/testing/ESDGenerator/sim/ESDGenSim.ipynb">Jupyter notebook</a> in the created <a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite/-/blob/blog20201101/designs/NLNet018TV/testing/ESDGenerator/sim">sim folder …</a></p></div><p>This is a continuation on <a class="reference external" href="first-testing-of-and-changes-to-esd-generator.html">my previous blog on first tests on the ESD generator</a>.</p>
<div class="section" id="problems">
<h2>Problems</h2>
<p>After some more debugging the voltage multiplier of the ESD Generator has been made to work. Detailed simulation results of the problems can be found in this <a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite/-/blob/blog20201101/designs/NLNet018TV/testing/ESDGenerator/sim/ESDGenSim.ipynb">Jupyter notebook</a> in the created <a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite/-/blob/blog20201101/designs/NLNet018TV/testing/ESDGenerator/sim">sim folder</a> in the ESD Generator source folder.
Summary of the problems:</p>
<ul class="simple">
<li>Leakage problem reported on in the previous blog post is mainly caused by the 10MΩ input impedance on the oscilloscope input not the diode leakage current</li>
<li>The bridge rectifier in the design is not needed and actually blocks the proper working of the voltage multiplier.</li>
<li>A DC offset is only seen in between the odd or the even nodes in the voltage multiplier.</li>
</ul>
</div>
<div class="section" id="measurement-results">
<h2>Measurement results</h2>
<p>In order to increase the input impedance and to allow to measure the higher generated voltages I used a voltage divieder to mimic 100:1 probe. A 1GΩ resistor was put in series with the probe. Combined with the 10MΩ input impedance of the oscilloscope this gives 100:1 ratio plus it increases the resistance on the measurement points from 10MΩ to 1GΩ.</p>
<img alt="" src="images/20201101_100_1_probe.jpg" style="width: 45%;" />
<p>To solve the problems as identified in the previous paragraph the diodes on the design have been desoldered and the output of the transformer directly connected to the input of the voltage multiplier. Now I can see the voltage multiplier working as it should. In the next oscilloscope measurements I have given the voltage on node 2 to 6 on the voltage multiplier:</p>
<img alt="" src="images/20201101_n2.png" style="width: 45%;" />
<img alt="" src="images/20201101_n3.png" style="width: 45%;" />
<img alt="" src="images/20201101_n4.png" style="width: 45%;" />
<img alt="" src="images/20201101_n5.png" style="width: 45%;" />
<img alt="" src="images/20201101_n6.png" style="width: 45%;" />
<p>The voltages for channel two (purple) are using the 100:1 probing so they have to be multiplied by 100 to get the actual value.
We can clearly see the difference in behaviour between odd and even nodes. The measured mean voltage on the even nodes is summarized in the next table:</p>
<table border="1" class="docutils">
<colgroup>
<col width="30%" />
<col width="70%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Node</th>
<th class="head">Avg. voltage</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>n2</td>
<td>830 V</td>
</tr>
<tr><td>n4</td>
<td>1610 V</td>
</tr>
<tr><td>n6</td>
<td>1970 V</td>
</tr>
</tbody>
</table>
<p>For the first nodes a capacitance of 4.7nF was used and for the last two nodes the 150pF of the original design was used. One can clearly see that for the latter ones the load of the diode leakage and the 1GΩ reduced the voltage step achieved significantly together with bigger ripple on the output.</p>
</div>
<div class="section" id="esdgenerator-v0-2-plans">
<h2>ESDGenerator v0.2 plans</h2>
<p>So these are the plans for a revision of the ESD Generator:</p>
<ul class="simple">
<li>Remove bridge rectifier</li>
<li>Increase the charge pump capacitors capacitance to reduce ripple</li>
<li>I have also ideas to provide the necessary connections on the board so different voltage multipliers could be chained together to generate even higher voltages.</li>
</ul>
</div>
First testing of and changes to ESD generator2020-10-04T00:00:00+02:002020-10-04T00:00:00+02:00Fatsietag:chips4makers.io,2020-10-04:/blog/first-testing-of-and-changes-to-esd-generator.html<p>As reported in a previous <a class="reference external" href="esd-generator-high-voltage-generator-for-esd-testing.html">blog post</a> I am working on a small circuit to generate high voltages for some ESD testing. I now received the PCBs and the components for on the PCB and even did find some time to do the first testing of the design. As a …</p><p>As reported in a previous <a class="reference external" href="esd-generator-high-voltage-generator-for-esd-testing.html">blog post</a> I am working on a small circuit to generate high voltages for some ESD testing. I now received the PCBs and the components for on the PCB and even did find some time to do the first testing of the design. As a reminder this is the schematic of the ESD generator:</p>
<img alt="" src="images/20200712_ESDGeneratorv0.1.png" style="width: 75%;" />
<p>To do the first testing I just populated the transformator, the diode bridge and components C1, C13, D5 and D17. This can be seen in the next picture:</p>
<img alt="" src="images/20201004_ESDGenPCB.jpg" style="width: 40%;" />
<p>It should allow to test if a voltage of 400V can be seen on C13 but unfortunaltely this is not the case. Testing reveals that it does not keep it's value.</p>
<p>In order to see if no design errors were made or maybe polarity of the diodes was switched, first the functionality of the diode bridge was checked. In the next image two oscilloscope snapshots are shown:</p>
<img alt="" src="images/20201004_ESDGen_DioBridgeHalf1.png" style="width: 45%;" />
<img alt="" src="images/20201004_ESDGen_DioBridgeHalf2.png" style="width: 45%;" />
<p>Here N_ISO was taken as 0V reference and L_ISO is shown in yellow on channel 1. Here a peak-to-peak voltage over 870V is seen which is higher than expected. For 240V AC a peak-to-peak voltage just under 680V is expected. I checked the <a class="reference external" href="http://catalog.triadmagnetics.com/Asset/F-367P.pdf">transformer datasheet</a> and verified I connected both primary and secondary in series. Multi-meter measurement confirms the increased voltage on the unloaded transformer: 244V AC on primary and 307V AC on secondary.</p>
<p>On the oscilloscope snapshots also on channel 2 in purple the board GND is shown on the left image and 220VRECT net on the right. This confirms that the board ground correctly follows L_ISO when the latter is below zero and 220VRECT follows it when above 0V. Switching reference voltage to the board ground gives then the following picture:</p>
<img alt="" src="images/20201004_ESDGen_DioBridgeBoardGND.png" style="width: 60%;" />
<p>Here 220VRECT is shown as channel 1 in yellow and L_ISO on channel2 in purple. It confirms the correct working of the diode bridge. Next step is to measure the voltage on C13 which should keep the peak voltage stored due the diodes blocking reverse currents. This is given in the next oscilloscope measurements:</p>
<img alt="" src="images/20201004_ESDGen_StorageCap150pF.png" style="width: 45%;" />
<img alt="" src="images/20201004_ESDGen_StorageCap300pF.png" style="width: 45%;" />
<p>On channel 1 still 220VRECT is shown and on channel 2 now the voltage over C13 is given. On the left the original designed 150pF capacintance value for C1 and C13 was used and on the right both capacitances were doubled to 300pF. For the original capacitance value one can see that the value reaches only a maximum of 94V and decreases again, with doubling of the capacitances the voltages improve slightly. For safety, I used very small capacitors to limit the maximum current that this circuit can provide at high voltages. It seems I made it too small compared to the leakage current of the diodes. The rectified voltage was supposed to be 270V peak-to-peak oscillating at 100Hz, with a capacitance of 150pF this gives a maximum current of around 4µA with a capacitance of 150pF. Checking the <a class="reference external" href="https://www.comchiptech.com/admin/files/product/1N4001-G%20Thru.%201N4007-G%20RevB.pdf">diode datasheet</a> gives a maximum leakage current of 5µA which is higher than the maximum current capability.</p>
<p>So the conclusion of this first experiment is that C1 has to be increased to have a maximum current significantly higher than the diode leakage current and also the storage capacitors like C13 need to increased to minimize the ripple on it's output caused by the diode leakage currents. I have now ordered a capacitor kit in order to experiment with different capacitance values.</p>
ESD Generator: high voltage generator for ESD testing2020-07-12T00:00:00+02:002020-07-12T00:00:00+02:00Fatsietag:chips4makers.io,2020-07-12:/blog/esd-generator-high-voltage-generator-for-esd-testing.html<p>After tape-out of <a class="reference external" href="nlnet018tv-a-fully-automated-test-chip-design.html">NLNet018TV</a>
I am now working on implementing the test procedures and gathering the equipment needed
for executing the tests.</p>
<p>For ESD testing high voltages with limited charges need to be generated. This high
voltage charge is then applied over two pins on the test chip to see …</p><p>After tape-out of <a class="reference external" href="nlnet018tv-a-fully-automated-test-chip-design.html">NLNet018TV</a>
I am now working on implementing the test procedures and gathering the equipment needed
for executing the tests.</p>
<p>For ESD testing high voltages with limited charges need to be generated. This high
voltage charge is then applied over two pins on the test chip to see if the chip
survives the event. This event mimics what happens when a charged person touches
a chip.</p>
<p>Standards exist for performing ESD tests together with expensive equipment that allows
to perform the test according to the standard. For our project we do want to perform tests
that also tests ESD performance but on a lower budget without claiming ESD standard
performance compliance.</p>
<p>A first version the schema of a circuit to generate high voltages up to 4kV has been designed
and is given in the next picture.</p>
<img alt="" src="images/20200712_ESDGeneratorv0.1.png" style="width: 90%;" />
<p>The circuit is a <a class="reference external" href="https://en.wikipedia.org/wiki/Cockcroft%E2%80%93Walton_generator">Cockcroft-Walton generator</a>.
The schema is drawn in KiCad and available from <a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite/-/tree/master/designs/NLNet018TV/testing/ESDGenerator">the gitlab repo</a>.</p>
<p>As I am not a very experienced PCB designer with even less experience with high voltages
I am sure there is much room for improvement. So don't hesitate to mail me your comments
or head over to the gitter page for a chat (links on the left).</p>
NLNet018TV: a fully automated test chip design2020-06-13T00:00:00+02:002020-06-13T00:00:00+02:00Fatsietag:chips4makers.io,2020-06-13:/blog/nlnet018tv-a-fully-automated-test-chip-design.html<p>I am working on a <a class="reference external" href="https://nlnet.nl/project/Chips4Makers">NGI0 NLnet funded project</a> and
I now did reach a first milestone in the project. I did tape-out a test chip which kept me busy
for the last two months and is also the reason I neglected this blog the last months. The
milestone is …</p><p>I am working on a <a class="reference external" href="https://nlnet.nl/project/Chips4Makers">NGI0 NLnet funded project</a> and
I now did reach a first milestone in the project. I did tape-out a test chip which kept me busy
for the last two months and is also the reason I neglected this blog the last months. The
milestone is a step to the tape-out of a <a class="reference external" href="https://libre-soc.org/180nm_Oct2020/">prototype of the libre-SOC project</a>
in the fourth quarter of this year.</p>
<div class="section" id="description-and-source-code">
<h2>Description and source code</h2>
<p>In good open source fashion I did put all the source code in the
<a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite/-/tree/NLNet018TV">NLNet018 TV tag</a>
on my <a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite">SnowWhite git repository</a>
in the <a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite/-/tree/NLNet018TV/designs/NLNet018TV">designs/NLNet018TV</a> directory.
This test chip contains some test structures to test <a class="reference external" href="http://www2.eng.cam.ac.uk/~dmh/4b7/resource/section14.htm">IO pads</a>,
<a class="reference external" href="https://en.wikipedia.org/wiki/Flip-flop_(electronics)#Simple_set-reset_latches">SR latches</a> and
an <a class="reference external" href="https://en.wikipedia.org/wiki/Static_random-access_memory">SRAM</a> cell.
In the <a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite/-/tree/NLNet018TV/designs/NLNet018TV/README.md">readme file</a> in
the repostory you find a more description on the contents of the test chip.</p>
<p>There is one caveat though. As the design rules are given under NDA they can't be distributed. So
these are located in a private directory that unfortunately can't be shared publicly.
As a consequence one needs to replicate all these files before being able to regenerate
the design. This makes my open source hart bleed and is also one of the reasons I am also
working on my <a class="reference external" href="https://gitlab.com/Chips4Makers/PDKMaster">PDKMaster project</a> (also <a class="reference external" href="https://nlnet.nl/">NLNet</a> funded) with which
I am trying to make handling of the foundry NDA PDK data as open as possible.</p>
</div>
<div class="section" id="the-a-in-eda">
<h2>The A in EDA</h2>
<p>EDA stand for <a class="reference external" href="https://en.wikipedia.org/wiki/Electronic_design_automation">electronic design automation</a>
and the term is normally used for the group of software tools for desiging PCBs and ASICs. Although
for digital circuits there is a high degree of automation this is not the case for tasks where layout
is involved. Both for desiging PCBs as for designing analog circuits on ASICs the flow is that
of doing schematic capture of the design followed by a mostly manual layout task.</p>
<p>For this test chip I focused on getting the automation part also in the layout part
of the design. The final <a class="reference external" href="https://en.wikipedia.org/wiki/GDSII">GDSII</a> file, except for the logo,
is fully generated by python scripts, including the dummy fill of the open area and the
bonding diagram for packaging.
It uses <a class="reference external" href="https://gitlab.lip6.fr/vlsi-eda/coriolis">Coriolis</a> and
<a class="reference external" href="https://klayout.de">klayout</a> through their respective python interfaces to achieve this.
<a class="reference external" href="https://klayout.de">klayout</a> is also used for <a class="reference external" href="https://en.wikipedia.org/wiki/Design_rule_checking">DRC</a>.</p>
</div>
<div class="section" id="jupyter-notebooks">
<h2>Jupyter Notebooks</h2>
<p>During this process I also started to experiment with Jupyter Notebooks in a
<a class="reference external" href="https://jupyter.org/">Jupyter Lab</a> environment. And I like so far what I have seen, I will
certainly continue looking at it further. Admittedly, due to time pressure, the
<a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite/-/blob/NLNet018TV/designs/NLNet018TV/flexio/IOPad.ipynb">IOPad notebook</a>
for generating the IO and SR latches test structures chip has grown too bulky without proper documentation.
I do see it as personal shortcoming though and not one of the Python Notebook format. And before
working further on higher level generation code I am planning to work on lower level building blocks
to make it possible to generate design rule compliant layouts with less code and less trial-and-error.</p>
<p>I also used Python Notebooks using <a class="reference external" href="https://ipywidgets.readthedocs.io/en/stable/">ipywidgets</a>
to design the SRAM cells and IO drivers. I first need to look further into making these public
without giving away NDA data. Certainly for such design tasks I see big potential for Python
Notebooks due to the access to all the scientific python tools like <a class="reference external" href="https://scipy.org/">SciPy</a>
and others without needing to convince a proprierary EDA tool vendor to implement a custom (proprietary)
flow for you needs.</p>
</div>
<div class="section" id="portability">
<h2>Portability</h2>
<p>This test chip is done for the TSMC 0.18µm technology which is different than the TSMC 0.35µm
process that will be used for the <a class="reference external" href="https://chips4makers.io/beta.html">Chips4Makers beta run</a>.
Everything developed here is done with easy portability in mind. This means that most of the
work in this project on standard cells, IO and SRAM is also meant to advance the fully open source
0.35µm process further and will be reused for the <a class="reference external" href="https://chips4makers.io/beta.html">Chips4Makers beta run</a>.</p>
<p>As said earlier this project did show though that first more work is needed on providing lower
level support for generating design rule compliant layouts before focusing further on the higher
level stuff.</p>
</div>
<div class="section" id="next-step">
<h2>Next step</h2>
<p>As is in the name, the purpose of a test chip is to test it after it is delivered. In the
repository already the <a class="reference external" href="https://gitlab.com/Chips4Makers/snowwhite/-/blob/NLNet018TV/designs/NLNet018TV/testing/TestPlan.md">test plan</a>
is avalaible. So the next step is to define how these measurements will be carried out and
then execute the tests once the dies arrive. The latter is expected in 3 months from now.</p>
<p>Especially generating the few kV voltages and applying it to the chip for ESD testing will
be a challenge to me. So if you have a comment or ideas on this or anything else related
to this project don't hesitate to contact me with any of the contact links on the left.</p>
</div>
Open source mixed RTL synthesis2020-01-06T00:00:00+01:002020-01-06T00:00:00+01:00Fatsietag:chips4makers.io,2020-01-06:/blog/open-source-mixed-rtl-synthesis.html<div class="section" id="test-designs">
<h2>Test designs</h2>
<p>It has been some time that I posted here and it's one of my New Year Resolutions to be more active here. As reported in a <a class="reference external" href="https://www.youtube.com/watch?v=xiBrZFaZ7hQ">presentation @ ORConf 2019</a> development of the Chips4Makers low volume ASIC manufacturing process is going on. Plan for this year is to do …</p></div><div class="section" id="test-designs">
<h2>Test designs</h2>
<p>It has been some time that I posted here and it's one of my New Year Resolutions to be more active here. As reported in a <a class="reference external" href="https://www.youtube.com/watch?v=xiBrZFaZ7hQ">presentation @ ORConf 2019</a> development of the Chips4Makers low volume ASIC manufacturing process is going on. Plan for this year is to do <a class="reference external" href="https://chips4makers.io/">a beta run</a> where other people can join.</p>
<p>In the ORConf presentation test chip tape-outs were presented. One of the test tape-outs contained a MOS6502 core and another a Z80 core. These cores are coming from FPGA implementations of old computers like a <a class="reference external" href="https://en.wikipedia.org/wiki/ZX_Spectrum">ZX Spectrum</a> or a <a class="reference external" href="https://en.wikipedia.org/wiki/Commodore_64">Commodore 64</a>. VHDL was used to write these cores. For the top cell and the JTAG interface nMigen is used which generates Yosys RTLIL or verilog as output. So for simulation and synthesis one need to mix different RTL languages.</p>
</div>
<div class="section" id="open-source-mixed-rtl-synthesis-1">
<h2>Open source mixed RTL synthesis</h2>
<p>The Yosys open source synthesis tool chain has traditionally been focused on Verilog. So for make the Chips4Makers test chips a proprietary Verific plugin for the <a class="reference external" href="https://www.symbioticeda.com/seda-suite">Symbiotic EDA tool suite</a> was used to do the synthesis on the VHDL code. Luckily Tristan Gingold is working very hard on changing this story. If you look at the recent commits on the <a class="reference external" href="https://github.com/ghdl/ghdl/commits/master">ghdl repository</a> and the <a class="reference external" href="https://github.com/tgingold/ghdlsynth-beta/commits/master">ghdlsynth-beta repository</a> you can see a lot of VHDL synthesis related commits for GHDL and accompanying Yosys plugin.</p>
<p>The Yosys ghdlsynth plugin is now able to synthesize both the Z80 and MOS6502 VHDL core used for the test chips. This way I could redo the synthesis and the place-and-route for the test chip using only open source tools. In commit <a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC/commit/77f33ae0b2c8753df43b94203dcbb141d59dff51">77f33ae</a> on the <a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC">Retro_uC repo</a> the synthesis for the two test chips was switched to ghdlsynth-beta.</p>
</div>
<div class="section" id="repeating-the-work">
<h2>Repeating the work</h2>
<p>If you want to repeat this you will need the latest version of quite some software and RTL code with some non-trivial compiling and python code installation. Best to <a class="reference external" href="mailto:blog@chips4makers.io">contact me</a> or head over to the <a class="reference external" href="https://gitter.im/Chips4Makers/community">Chips4Makers Lobby</a> on <a class="reference external" href="https://gitter.im">gitter</a>.</p>
<p>After checking out the <a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC">Retro-uC repository</a> you have to go into <tt class="docutils literal">asic/C4M035/SnowWhiteIII_MOS6502</tt> or <tt class="docutils literal">asic/C4M035/SnowWhiteIII_Z80</tt> directory and execute <tt class="docutils literal">make gdsii</tt> there to do the generation of the RTL code with nMigen, synthesis with Yosys and place-and-route with QFlow.</p>
<p>You will need recent versions of several dependencies installed for this to work out:</p>
<ul class="simple">
<li><a class="reference external" href="https://github.com/YosysHQ/yosys">yosys</a>: synthesis software.</li>
<li><a class="reference external" href="https://github.com/ghdl/ghdl">ghdl</a>: VHDL simulation and synthesis.</li>
<li><a class="reference external" href="https://github.com/tgingold/ghdlsynth-beta">ghdlsynth-beta</a>: GHDL synthesis plugin for Yosys.</li>
<li><a class="reference external" href="https://github.com/m-labs/nmigen/">nMigen</a>: python hardware generation framework.</li>
<li><a class="reference external" href="https://gitlab.com/Chips4Makers/t65">t65</a>: the MOS6502 VHDL core with a nMigen wrapper.</li>
<li><a class="reference external" href="https://gitlab.com/Chips4Makers/t80">t80</a>: the Z80 VHDL core with a nMigen wrapper.</li>
<li><a class="reference external" href="https://gitlab.com/Chips4Makers/c4m-jtag">c4m-jtag</a>: reusable JTAG interface.</li>
<li><a class="reference external" href="http://opencircuitdesign.com/qflow/index.html">QFlow</a>: RTL-2-GDSII flow; use version 1.4, with 1.3 you will need to use lower initial density settings.</li>
</ul>
</div>
<div class="section" id="next-step">
<h2>Next step</h2>
<p>Currently I am still using the free but proprietary ModelSim for Altera FPGAs to do simulation. So the next step to take is to have a mixed RTL simulation flow using only open source tools.</p>
</div>
The Retro-uC is death - long live the Retro-uC !2018-11-25T00:00:00+01:002018-11-25T00:00:00+01:00Fatsietag:chips4makers.io,2018-11-25:/blog/the-retro-uc-is-death-long-live-the-retro-uc.html<div class="section" id="retro-uc-s-death">
<h2>Retro-uC's death ?</h2>
<p>Last month the <a class="reference external" href="https://crowdsupply.com/chips4makers/retro-uc">Retro-uC crowdfunding campaign</a> ended without reaching it's funding goal. I do regret that it did not reach it's goal but I did learn some things:</p>
<ul class="simple">
<li>The typical retro-computing guy is not very interested in Arduino type maker stuff. He wants to assemble and program a …</li></ul></div><div class="section" id="retro-uc-s-death">
<h2>Retro-uC's death ?</h2>
<p>Last month the <a class="reference external" href="https://crowdsupply.com/chips4makers/retro-uc">Retro-uC crowdfunding campaign</a> ended without reaching it's funding goal. I do regret that it did not reach it's goal but I did learn some things:</p>
<ul class="simple">
<li>The typical retro-computing guy is not very interested in Arduino type maker stuff. He wants to assemble and program a system with CPU, memory and peripherals. One chip with just GPIO outputs is not really getting him exciting.</li>
<li>The prospect of an open silicon movement is not attractive enough for Arduino loving maker to pay some premium on an Arduino type device.</li>
</ul>
<p>IMHO these factors meant the campaign stayed far away from the funding goal. The nice thing about crowdfunding is that you can find these things out without spending a lot of money.</p>
<p>One may wonder if this means the end of the Retro-uC and/or the Chips4Makers project. The answer is no, certainly not yet. Being a little wiser now I am even more motivated to work on help in getting the open silicon movement from the ground. I bought some new toys to play with and started looking at a good hardware 'programming' language.</p>
</div>
<div class="section" id="new-toys">
<h2>New toys</h2>
<div class="section" id="sram-and-i2c-test-chips">
<h3>SRAM and I2C test chips</h3>
<img alt="SRAM and I2C EEPROM test chips" src="images/Chips4Test.jpg" style="width: 45%;" />
<p>This was already mentioned in an update to the Retro-uC campaign but I ordered some SRAM and I2C EEPROM chips:</p>
<ul class="simple">
<li><a class="reference external" href="https://fremontmicrousa.com/products-memories">Fremont Micro FT24C32A 32 kB I2C EEPROM</a></li>
<li><a class="reference external" href="https://www.microchip.com/wwwproducts/en/24LC32A">Microchip 24LC32A 32kB I2C EEPROM</a></li>
<li><a class="reference external" href="https://www.idt.com/products/memory-logic/srams/asynchronous-srams/71256sa-50v-32k-x-8-asynchronous-static-ram">IDT 71256SA 32 kB parallel SRAM</a></li>
<li><a class="reference external" href="https://www.alliancememory.com/datasheets/as6c62256/">Alliance Memory AS6C62256 32 kB parallel SRAM</a></li>
</ul>
<p>This should be able to test an external SRAM interface and test the booting from external ROM for the Retro-uC. The external SRAM interface was an often asked for feature.</p>
</div>
<div class="section" id="arty-s7-pmods">
<h3>Arty S7 + Pmods</h3>
<img alt="Arty S7 FPGA board and PmodVGA plus PmodI2S2" src="images/ArtyS7_Pmods.jpg" style="width: 45%;" />
<p>I also ordered an Arty S7; this was the development board in one of the stretch goals. Also one of the reasons to go for this board is that is seems to have Migen support, see more below. The additional VGA and I2S Pmods allows to experiment with video and sound for Retro computing pleasure. They should also be usable on my <a class="reference external" href="https://hackaday.io/project/12930-blackice-low-cost-open-hardware-fpga-dev-board">BlackIce</a> board.</p>
</div>
<div class="section" id="zynqberry">
<h3>ZynqBerry</h3>
<img alt="ZynqBerry" src="images/ZynqBerry_TE0726-03M.jpg" style="width: 65%;" />
<p>Finally I ordered a <a class="reference external" href="https://shop.trenz-electronic.de/de/TE0726-03M-ZynqBerry-Zynq-7010-in-Raspberry-Pi-Formfaktor">ZynqBerry</a>. This is a FPGA board with a <a class="reference external" href="https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html">Xilinx Zynq SoC</a> in a <a class="reference external" href="https://www.raspberrypi.org/products/raspberry-pi-3-model-b/">Raspberry Pi 3 Model B</a> form factor. One of the things I will investigate is how far this boards allows to combine some old-school Retro fun with modern features.</p>
</div>
</div>
<div class="section" id="the-quest-for-the-ideal-hardware-programming-language">
<h2>The quest for the ideal hardware 'programming' language</h2>
<p>As explained in a previous <a class="reference external" href="retro-uc-first-time-right-yes-we-can.html">blog post</a>, I minimized the features for the Retro-uC. This was to not have feature creep generating long delays in the project and to minimize the risk of having a non-working part. But from comments it seems some more features are needed to make the Retro-uC more attractive.</p>
<p>I am not very fond of the current VHDL and (System)Verilog RTL languages. I am not going to go in-depth now but I do think that these languages are hampering productivity in developing working, debugged circuits. I do think they should be delegated to the same functionality as assembly language has for CPUs: basically only used by the higher level language compilers and in exceptional cases for low-level stuff. But even then maybe <a class="reference external" href="http://freechipsproject.github.io/firrtl/">FIRRTL</a> is more fit for this job.</p>
<p>Currently I am making myself familiar with <a class="reference external" href="https://m-labs.hk/migen/">Migen</a>. For me this seems a perfect fit: it is python based and succesfully abstracts away the event based nature of the low level RTL languages. Other possible candidates were <a class="reference external" href="https://chisel.eecs.berkeley.edu/">Chisel</a> or <a class="reference external" href="https://github.com/SpinalHDL/SpinalHDL">SpinalHDL</a>, but there I was put off by the reliance on the <a class="reference external" href="https://www.scala-lang.org/">Scala</a> language, <a class="reference external" href="https://dictionary.cambridge.org/us/dictionary/english/ymmv">YMMV</a>. Most other HDL languages I looked at seemed not a good fit for me as they build on the same event driven basics which I do find are hampering the low-level RTL languages.</p>
</div>
Retro-uC first time right - yes, we can2018-09-15T00:00:00+02:002018-09-15T00:00:00+02:00Fatsietag:chips4makers.io,2018-09-15:/blog/retro-uc-first-time-right-yes-we-can.html<p>This post is again about comments posted after launch of the Retro-uC campaign claiming it defies 'common wisdom' and thus is unrealistic. This time about the fact the project assumes the chip will work the first time; in the industry also as first-time-right. In order to explain what are possible …</p><p>This post is again about comments posted after launch of the Retro-uC campaign claiming it defies 'common wisdom' and thus is unrealistic. This time about the fact the project assumes the chip will work the first time; in the industry also as first-time-right. In order to explain what are possible problems and the strategy to avoid them, this post will need to be more technical than the previous posts.</p>
<p>As expained in the previous post, the startup costs are a big contributor to the final cost of the products for a low volume costum chip. Doing an iteration on the production would double the startup costs of the repeated production steps. The Retro-uC project was from the start defined in such a way with the purpose of having a working chip on the first iteration and avoid having to raise the pledge levels. The main principle applied is <a class="reference external" href="https://en.wikipedia.org/wiki/KISS_principle">KISS</a>: keep it simple, stupid.</p>
<p>Before going into the gory details of what can go wrong let's first give some background on how a microelectronics chip works. On the chip, the zeros and ones are represented by electric signals. Computations are done by transistors on a chip; for digital applications they act as switches with the voltage on one of the input nodes determining if the switch is open or closed. Switches can be used to make <a class="reference external" href="https://en.wikipedia.org/wiki/Digital_electronics">digital circuits</a>. Take for example a light in a room that can be controlled from multiple switches in a classic way; e.g. not centralized in the electrical cabinet. The state of the individual switches determines if the light is on or not, thus if you have a zero or one on the output. Electrically controllable switches can also be used to make memory elements. When going back to our light example you can also have configurations where pushing a button switches the light on or off. In technical terms a memory element on a chip is often called a register. Another use case for transistors is to use them with the input not fully open or fully closed. This is called an <a class="reference external" href="https://en.wikipedia.org/wiki/Analogue_electronics">analog application</a> of the transistor. Example here is the use as in a transistor radio or an audio amplifier.</p>
<p>The fact that zeros and ones are presented by electrical signals also means that they are bound by the physical laws for electrical signals. The wires will have a certain resistance, wires close to each other will form a capacitor and other similar effects. This means that these signals will take time to propagate through the chip and may also interact with each other. There can be different causes why a chip does not work first time:</p>
<ul class="simple">
<li>a bug is present in the source code of the chip</li>
<li>an analog circuit on the chip does not work or does not meet the specification</li>
<li>timing problems</li>
<li>power distribution problems</li>
<li>signal integrity problems; these are unwanted interactions between different signals that make the chip malfunction</li>
</ul>
<p>With the scaling of the technology more things are put on a chip; and features like dynamic frequency and voltage scaling, multiple clocks, multiple voltage domains, etc. The complexity of designing a chips increases with each and this almost exponentially with the technology node. In the next paragraphs it is detailed what decisions have been made to mitigate the problems for the Retro-uC chip.</p>
<p>To minimize the risk of having a killer bug in the RTL source code of the Retro-uC well tested code was used for the three cores. The MOS 6502 and the Z80 were used in emulators for the Commodore 64 and the ZX Spectrum. The Motorola 68000 core has been used to boot Linux. The JTAG interface has been newly written but has first been unit tested using the <a class="reference external" href="https://github.com/potentialventures/cocotb">cocotb</a> tool and afterwards tested on FPGA. The rest of the glue logic has been kept relatively simple and is also tested by simulation and on FPGA. Implementing new features has only minimal impact on final cost as these are mainly determined by startup costs. So it is tempting to let feature creep come in. But every new feature needs development time and increases the risk of introducing a killer bug. Therefor it was to decided to develop the Retro-uC in a <a class="reference external" href="https://en.wikipedia.org/wiki/Minimum_viable_product">MVP (minimum viable product)</a> fashion but this may disappoint people who really want their own favorite feature implemented.</p>
<p>For analog blocks it is common to at least have one iteration on the design. Each type of circuit can have different architectures implementing the function. Each architecture has it's own peculiarities and there are no (fully) automated tools like for digital applications to check if a design fulfills it's specification. The designer needs to do the design of the circuit and also the test benches with which to check it's functionality. So to have a circuit performing according to specification when it is delivered from the fab, both the simulation models provided by the silicon fab as the test benches developed by the designer have to cover the whole functionality and for the peculiar requirements of the chosen architecture. As a consequence often one or more iterations are needed to get the circuit right. For the Retro-uC it was decided to not include analog functionality like for example an ADC (analog to digital converter). The design itself would take considerable time and delay the project with several months and also the startup costs would need to be increased in order to allow for test chips of the analog blocks. Also the needed information to be able to design open source analog blocks without needing a NDA is not in place at the moment; which is another reason to not include analog blocks in the pilot Retro-uC project. In the mid-term it is planned to also include open source analog design possibility inside the Chips4Makers project but this will be developed in parallel with the digital part and will take some time to get there.</p>
<p>Most digital chips are clocked, the registers on the chip typically renew their stored value at the start of each clock cycle. Timing problems in the digital part of a chip are caused because signals take a certain time to propagate through a chip. Transistors can only provide a certain current and this limits the speed with which signals can travel between the transistors. In order for a clocked register to work well it has requirements on the timing of the signals on it's input. The signals have to arrive a certain time before the next cycle starts and at the start of the cycle the value has to be kept it's state a certain time before it may change to the next state. The former is called a setup constraint and the latter a hold constraint. A violation of the setup is not a killer problem if you allow to reduce the clock frequency to give enough time for the signal to propagate. For the Retro-uC the max. frequency will be determined when the chip comes back from the foundry and is a refinement of the max. frequency range determined during the design phase. A hold violation is a killer problem though; if it is present you have to fix your design and order a new chip. But for the 0.35 micron technology chosen this will not pose a problem when not doing crazy things on the chip. The delay of the register is big enough; even if you connect the output of one register directly to the input of another register you won't violate the hold requirements.</p>
<p>On a chip there can be more complicated timing constraints. For certain protocols there may be requirements on different signals arriving with only limited difference in delay; sometimes circuit may also depend on signals arriving with a certain order in time and thus depend on the propagation delay of each of the elements in the signal paths. These kind of timing problems can also be the cause that designs that work on a FPGA don't work when implemented in an ASIC. Even when the special timing requirements were not specified, it can be that by luck and due to the architecture of the FPGA the timing requirements are never violated during FPGA testing. When now implemented in ASIC with a more fine grained architecture this unspecified timing problem may be triggered and cause a malfunction of the chip. These problems are avoided on the Retro-uC by not using RTL code that depends on such requirements; all timing is done on signal arriving at registers relative to the clock and the tools I selected to design and verify the chips handle these requirements well. Another possible source of timing problems is if you have more than one clock on a chip and signals need to go from one clock domain to another clock domain. The problem is caused because the timing of the clocks is independent from each other; the start of one of the clock cycles can happen any time relative to the other clock cycles; the frequencies of the clock may be even different. This can lead to the so-called meta-stability problem. When a signal is changing value it has a voltage in between the two digital values for a certain time. During that time, this signal can be seen as different logic values at different places and leading to wrong logic computation. Alternatively you may want to have a bus of signals to go between the clock domains and some of them may be seen in the old state and some of them in the new state by the other clock domain. In the Retro-uC this problem is avoided as much as possible by having only one main clock. The only place where a second clock could not be avoided is for the JTAG interface which is defined to carry it's own clock signal. The risk has been minimized here by using a handshake protocol to transfer data between the JTAG interface and the rest of the design. A single signal is used to indicate data is ready and only in the next clock cycle the actual data is read so it is in a stable state. Then an acknowledge signal is given form the receiving side to the sender so the latter knows the data is no longer needed and the cycle can be ended. Next to the normal digital verification; this mechanism will also be verified before tape-out with transistor-level simulations - known as SPICE simulations by the people in the field.</p>
<p>Both for the remaining power distribution and the signal integrity problems the complexity of them increases almost exponentially with scaling. The main problem for power distribution is the voltage drop one gets over a wire with a certain resistance and a current going through it. Typically voltage is scaled with technology scaling and more functionality is put on a chip. When lowering the voltage the current has to increase in order to deliver the same power. Having the same resistance of the power distribution network thus results in a higher voltage drop. As the voltage was already lower this is thus a double effect in relative terms to supply voltage. With technology scaling the devices become smaller and by this the power density on the chip increases. This is an additional factor making the design of power distribution network more difficult. With the increasing frequency with which chips are run even the inductance of the power distribution network can become important. This is the phenomenon that high current peaks take a certain amount of time to build up and the distribution network may need to be designed to avoid having problems with it. Next to the power distribution the integrity of the signals has to be guaranteed. The integrity may be broken because signals next to each other may influence each other. With scaling the signals are put closer together, much more things are happening at the same time and the signals will change faster; this all makes the problem (much) more complex. For the 0.35um technology chosen for the Retro-uC the power density on the chip is relatively low and the chip is running at a moderate frequency so both power distribution and signal integrity can be checked with simple extraction of power consumption, resistance of distribution network and capacitance on some critical (asynchronous) signals. If one would go for 0.18um where the same functionality is put on a quarter of the area and running at higher frequency more automated tools would be needed to minimize risk mainly for power distribution; when even going smaller also signal integrity has to be verified carefully.</p>
<p>With this blog post I explained how the first time right aspect of chip development has been looked at from the beginning of this project and how all has been done to minimize the risk of having a non-functional product. Although this risk has been minimized it is not 0% and thus this was also mentioned in the 'Risks & Challenges' chapter on the campaign. I consider the risk certainly not higher than the average crowdfunding project.</p>
Startup costs and low-volume manufacturing2018-09-02T00:00:00+02:002018-09-02T00:00:00+02:00Fatsietag:chips4makers.io,2018-09-02:/blog/startup-costs-and-low-volume-manufacturing.html<p>After my <a class="reference external" href="https://www.crowdsupply.com/chips4makers/retro-uc">Retro-uC</a> crowdfunding campaign was announced comments were made on social media that this project defied 'common wisdom' and therefor is not realistic. One of the comments was on the funding goal that was too low to make a custom ASIC. In this blog I want to go deeper …</p><p>After my <a class="reference external" href="https://www.crowdsupply.com/chips4makers/retro-uc">Retro-uC</a> crowdfunding campaign was announced comments were made on social media that this project defied 'common wisdom' and therefor is not realistic. One of the comments was on the funding goal that was too low to make a custom ASIC. In this blog I want to go deeper into the choices made for the Retro-uC that made the current goal possible. Unfortunately almost everything in the current semiconductor manufacturing world is done under NDA; this includes the quotes for manufacturing I got so I can't give the full details in this article. Hopefully I can share enough to give insight in the cost choices made for this project.</p>
<p>As you can derive from the title of this blog the start-up costs are playing an important role for low-volume chip production. The Chips4Makers wants to target real low volume with a small budget - not more than several thousand of dollars. This means start-up costs are very important. Before one can have a packaged chip it first has to be designed and then manufactured afterwards. Both steps normally involve startup costs.</p>
<p>All the design costs are startup costs; e.g. they need to be paid before the chip can go for manufacturing. It involves engineering costs and software license costs. The engineering work for Retro-uC is, in good maker tradition, not accounted for; it's seen as a labor of love to help the open silicon movement going. Also open source RTL code is used for the sub-blocks so most of the code did not have to be designed from scratch. For the software open source tools are used. For the software commonly used for chip design, hefty license fees need to be paid; for low-volume manufacturing in a mature technology the cost would be higher than the chips themselves. Therefor for the Retro-uC open source tools are being used. Of course this may raise the question if these tools are up to the task of designing a chip. In order make this possible, the complexity of the Retro-uC has been kept relatively low. The retro cores are from a time when chip design was done by doing the layout of the whole chip manually using Rubylith. I did look at the available open source tools and <a class="reference external" href="https://fosdem.org/2018/schedule/event/cad_os_asic">presented intermediate conclusion @ FOSDEM</a>. In the time between that presentation and the launch I have grown more confidence and I have close contact with the some of the main developers of the tools. All these things combined make the engineering cost for the Retro-uC project virtually zero.</p>
<p>The startup costs for manufacturing the chips and the PCBs for the Retro-uC are present in the chip manufacturing, chip packaging, PCB manufacturing and PCB assembly stage.</p>
<p>For chips manufacturing the main startup cost are the mask costs. The masks are used to project patterns on the wafer during the <a class="reference external" href="https://en.wikipedia.org/wiki/Photolithography">lithography</a> production process. With scaling of the technologies these masks need to contain smaller features and become more complex. This means that the costs of these masks increase with every node. Also more masks are typically needed for smaller technologies. As a rule of thumb for mature nodes - when normal <a class="reference external" href="https://en.wikipedia.org/wiki/Moore%27s_law">Moore's law scaling</a> was still valid - one can take that the startup costs double with each node; for recent nodes this is not so straight forward. Of course scaling has also advantages, for each node the area taken by the same device is halved and the cost of a wafer only increases slightly. This means that the cost of chips with the same functionality decreases with each node but only when more than a certain volume is reached; otherwise the startup costs can not be divided over enough chips. With scaling also the performance improves, both in speed and in power consumption making scaling a must for higher volume. An additional way to reduce the mask costs is to use a <a class="reference external" href="https://en.wikipedia.org/wiki/Multi-project_wafer_service">multi-project wafer service</a>. Here different chips for different customers are put on the same mask set so the costs are shared. This reduces the costs but also introduces other requirements on area, less flexibility on process options and meeting fixed deadlines. For the Retro-uC the choice was made for a MPW on TSMC 0.35um. This allows the low funding goal but as a consequence compromises are made on speed and area, like only 4kB on-chip RAM, etc.</p>
<p>With a choice for a mature node and MPW the setup cost of packaging the chips becomes also a big contributor to the total startup costs. For packaging there are two main options: ceramic and plastic packages. But the processing of these is most of the time also different. Ceramic packages are most of the time bought fully fabricated and the silicon die is then put inside and then bonded. This bonding is often done manually. For plastic packaging one starts with a <a class="reference external" href="https://en.wikipedia.org/wiki/Lead_frame">lead frame</a>; a die is placed on this lead frame and bonded. In the next stage the frame with die is molded in a plastic case and the outside pins are finished off. Ceramic packages are most of the time used for small volume and plastic for high volume. Ceramic packaging has relatively low startup costs but have a high per unit costs; the ceramic packages are not cheap and the manual labor also increases costs so the per unit cost can reach up to several tens of dollar. For plastic packaging the tooling of a custom lead frame will cost more than ten thousand dollar. There are so called open tool lead frames for a fixed number of existing packages. This allows to avoid the tooling of the lead frame. Even when using such an open tool lead frame the startup costs involved are still a few thousand dollar. As these packagers are focused on high volume their setup process is not optimized and as a customer you also want a rigid setup process. If you send a bunch of expensive dies for packaging you don't want to loose any of them during the setup process. Alternatively for the Retro-uC and Chips4Makers <a class="reference external" href="https://eesemi.com/cob.htm">Chip-On-Board or Direct-Chip-Attachement</a> has been investigated but no good candidates were found that could meet the needed requirement on bonding pitch and did not have the same high per unit cost due to manual labor needed as for ceramic packaging. Although the chip manufacturing costs are quite mature and not much can be gained, I do think the startup costs for the packaging can still be reduced if some company wants to focus on this or if there would be more competition. Currently the Retro-uC is planned to use plastic packaging. Likely I did not find the best existing option yet. So <a class="reference external" href="mailto:blog@chips4makers.io">I am all ears</a> for offers or links to investigate further.</p>
<p>For both the PCB manufacturing and assembly the startup cost is relatively low. There is a lot of competition in this space with services like <a class="reference external" href="https://oshpark.com/">Oshpark</a> and even several Chinese companies. Even for low volume the setup process are highly automated and low cost.</p>
<p>Finally in the comments I saw links to the <a class="reference external" href="https://www.crowdsupply.com/sifive/hifive1">HiFive1 board</a> from <a class="reference external" href="https://www.sifive.com/">SiFive</a> as reference for the Retro-uC. They have chosen a 0.18um technology and likely did not go for MPW but for a full mask set. The crowdfunding goal was also $1 indicating that the run was sponsored to get traction on their chips; there's nothing wrong with that but is just another strategy chosen than for Retro-uC. The Retro-uC project wants to show what production cost can be reached for low volume manufacturing. Of course the 0.18um technology allows better specs for features (16kB on-chip RAM) and speed (>300MHz). Of course I can't look behind the curtain of <a class="reference external" href="https://www.sifive.com/">SiFive</a> but their latest <a class="reference external" href="https://www.crowdsupply.com/sifive/hifive-unleashed">Hifive Unleashed</a> is an indication that they have shifted to higher cost and/or higher volume products. From a pure money point of view it's not unlogical, there is quite some money to be made by competing with ARM and the like. It's just not what I want to target with Chips4Makers. Although I would love to be able to quit my day job and make a living of providing low-volume manufacturing services, it will be because the Chips4Makers concept makes it possible and not because of a strategic shift of the project. Also I won't focus on one instruction set but want to see what the imagination of the makers can bring to the world.</p>
<p>The Retro-uC is a pilot project but for future projects it should be possible to have four projects with almost the same total startup cost e.g. one fourth for each of them and with the same per unit cost as for the Retro-uC. The reason is that now the MPW seat consist of four dies which are the same. In future projects these could be four different dies.</p>
Retro-uC crowdfunding campaign launched on crowdsupply2018-08-26T00:00:00+02:002018-08-26T00:00:00+02:00Fatsietag:chips4makers.io,2018-08-26:/blog/retro-uc-crowdfunding-campaign-launched-on-crowdsupply.html<p>I am delighted to announce that the Retro-uC crowdsupply campaign has now been launched. It has taken a little longer to straighten out the last hurdles in production and delivery but now the campaign is waiting for you. Together with the crowdsupply staff, the delay has also been used to …</p><p>I am delighted to announce that the Retro-uC crowdsupply campaign has now been launched. It has taken a little longer to straighten out the last hurdles in production and delivery but now the campaign is waiting for you. Together with the crowdsupply staff, the delay has also been used to streamline the pledge targets. Next to the hardware targets now also open silicon development support is included in some of the targets. This is to help to bootstrap the low-volume open silicon movement. For the details please head over to the <a class="reference external" href="https://www.crowdsupply.com/chips4makers/retro-uc">campaign page</a>; use the <a class="reference external" href="mailto:blog@chips4makers.io">Contact</a> link for all your questions.</p>
<p>Whether a retro geek or an open silicon enthusiast; now is the ideal time to show your support !</p>
Motorola 68000 support complete in Retro-uC2018-06-17T00:00:00+02:002018-06-17T00:00:00+02:00Fatsietag:chips4makers.io,2018-06-17:/blog/motorola-68000-support-complete-in-retro-uc.html<p>I'm happy to announce that now support for the Motorola 68000 in the Retro-uC is complete. It uses the ao68000 core to implement the Motorola 68000 instruction set.</p>
<p>As usual, it has taken more effort than originally planned. As the ao68000 already had a Wishbone interface used as the internal …</p><p>I'm happy to announce that now support for the Motorola 68000 in the Retro-uC is complete. It uses the ao68000 core to implement the Motorola 68000 instruction set.</p>
<p>As usual, it has taken more effort than originally planned. As the ao68000 already had a Wishbone interface used as the internal bus for the Retro-uC the first steps went fluently. I needed to fix a bug in my block read support but that was quickly done.</p>
<p>The most time consuming was to get the endianness right. In the Retro-uC I currently have a memory map to access to I/O pins. This can be either accessed in 8 bit mode or in 32 bit mode. The Z80 and MOS6502 will access the memory map in 8 bit mode; the Motorola 68000 and the JTAG interface in 32 bit. As I want to have the I/O mapped to the same address in all three cores the endianness support has to be done right and all should agree on it. It seems my assumption on endianness when implementing Z80 and MOS6502 support did not agree with how the Motorola 68000 saw things. Several iterations had to be done to get all the cores agree on the same address for the I/O pins.</p>
<p>Another problem that has taken some time to get right was the fact that the ao68000 uses a ROM for storing microcode. A ROM is implemented on the MAX10 FPGA by using block RAM that is initialized and never written to. The memory initialization is not compatible with the dual image feature of the MAX10 used on the XLR8. This means programming a bitstream with the ao68000 included will overwrite the backup image on the MAX10; this also means this bitstream can't be programmed through the OpenXLR8 support in the Arduino IDE. After some fiddling I could program the FPGA also with my Bus Pirate.</p>
<p>To download the files please look at the release announcement and the <a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC/tags/XLR8_v20180617">gitlab release tag</a> which include the download file and the release notes.</p>
<p>The code is quite generic and should be easily portable to other FPGA boards. If anybody feels like taken up such a challenge don't hesitate to contact me.</p>
Retro-uC for XLR8 Release 201806172018-06-17T00:00:00+02:002018-06-17T00:00:00+02:00Fatsietag:chips4makers.io,2018-06-17:/blog/retro-uc-for-xlr8-release-20180617.html<p>A release has been done of the Retro-uC on the XLR8 implementing Motorola 68000 support for Retro-uC.
Please find the release notes and the file to download on the <a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC/tags/XLR8_v20180617">gitlab page</a>.</p>
Blink Demo2018-04-29T00:00:00+02:002018-04-29T00:00:00+02:00Fatsietag:chips4makers.io,2018-04-29:/blog/blink-demo.html<div class="section" id="intro">
<h2>Intro</h2>
<p>In order to show the progress I made on the Retro-uC a short video is presented with a demo with the Retro-uC running on an FPGA.</p>
<p>For the demo an <a class="reference external" href="http://www.aloriumtech.com/xlr8/">Alorium XLR8</a>, a <a class="reference external" href="https://www.velleman.eu/products/view/?id=435506">Velleman VMA201 proto shield</a> and a <a class="reference external" href="`DangerousPrototypesBusPirateV3.6`">Dangerous Prototypes BusPirate V3.6</a> were used. On the proto …</p></div><div class="section" id="intro">
<h2>Intro</h2>
<p>In order to show the progress I made on the Retro-uC a short video is presented with a demo with the Retro-uC running on an FPGA.</p>
<p>For the demo an <a class="reference external" href="http://www.aloriumtech.com/xlr8/">Alorium XLR8</a>, a <a class="reference external" href="https://www.velleman.eu/products/view/?id=435506">Velleman VMA201 proto shield</a> and a <a class="reference external" href="`DangerousPrototypesBusPirateV3.6`">Dangerous Prototypes BusPirate V3.6</a> were used. On the proto shield LEDs and accompanying resistors have been soldered on the D2-D9 Arduino IOs.</p>
<p>The Retro-uC core used has the Z80 and the MOS6502 and a JTAG interface. In the video below a demo is giving by blinking the LEDs on the proto shield in four different ways:</p>
<ol class="arabic simple">
<li>The LEDs are blinked using the JTAG boundary scan method. This is a standardized way of accessing the IOs on a chip through the JTAG interface. This feature will also allow to easily test PCBs in a standard way that contains the final Retro-uC chip.</li>
<li>The LEDs are blinked by writing to the memory locations where the IOs are memory mapped. The JTAG interface in the Retro-uC has custom memory access commands and these can be used to write in the memory locations. On the Retro-uC the IOs are memory mapped and their state can be changed this way through the JTAG interface.</li>
<li>The LEDs are blinked by a Z80 program. The Retro-uC will have on-chip SRAM and on the XLR8 MAX10 block RAM is used. The JTAG memory access commands are now used to load the program in the on-chip RAM and enable the Z80 core. The Z80 is compiled from a C program using the <a class="reference external" href="http://sdcc.sourceforge.net/">SDCC compiler</a>.</li>
<li>The LEDs are blinked by a MOS6502 program. The same C program as before has now been compiled using the <a class="reference external" href="https://www.cc65.org/">cc65 compiler</a>.</li>
</ol>
<p>Finally the Retro-uC is reset by pressing the Reset button.</p>
</div>
<div class="section" id="the-video">
<h2>The Video</h2>
<br /><video width="960" height="540" controls>
<source src="videos/20180428_demo.mp4" type="video/mp4"/>
<a href="videos/20180428_demo.mp4">Old browser video download</a>
</video></div>
<div class="section" id="the-binaries-and-the-source">
<h2>The Binaries and the Source</h2>
<p>The source code for the demo is available on the <a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC">Retro-uC gitlab repo</a> and the <a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC/tags/XLR8BlinkDemo_20180429">XLR8BlinkDemo_20180429 tag</a> corresponds with the state of the code as used for the demo. The file <a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC/uploads/b7d727b88632e6828e696e474a4fc6c8/XLR8BlinkDemo_20180429.tgz">XLR8BlinkDemo_20180429.tgz</a> attached to the tag contains the release files that allows to redo the demo on your own.</p>
<p>Some more detail on how the different files are generated (all files are referred to the top of the <a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC">Retro-uC gitlab repo</a> and commit of the tag):</p>
<ul>
<li><p class="first">The bitstream for the MAX10 Altera FPGA on the XLR8 is generated with Quartus Prime Lite version 17.1.0. The project files are located in <a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC/tree/08a6f51c3b1925018ceebd9ee99265d8e73c6110/boards/XLR8/quartus">boards/XLR8/quartus</a> with Retro-uC.pqf the top project file to be loaded in Quartus. The code uses a few git submodules (links also refer to commit as used for the demo):</p>
<ul class="simple">
<li><a class="reference external" href="https://gitlab.com/Chips4Makers/t80/tree/6c2b16cbd1c6398297cde6b0292471d41c9c7163">T80</a>: Z80 RTL code</li>
<li><a class="reference external" href="https://gitlab.com/Chips4Makers/t65/tree/b268bdafaa51ed33b7b7909df752e3bcd66f94d5">T65</a>: MOS6502 RTL code</li>
<li><a class="reference external" href="https://gitlab.com/Chips4Makers/c4m_jtag/tree/c412840d70267efc14843383e16933992ec1be7c">C4M::JTAG</a>: my own developed JTAG RTL code. Plan is to give more details on this code in one of the next blog posts.</li>
</ul>
<p>This is combined with Retro-uC specific code:</p>
<ul class="simple">
<li><a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC/tree/08a6f51c3b1925018ceebd9ee99265d8e73c6110/rtl/vhdl">rtl/vhdl</a>: Generic Retro-uC RTL code, containing wrappers around the mentioned submodules and the top control module.</li>
<li><a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC/tree/08a6f51c3b1925018ceebd9ee99265d8e73c6110/boards/XLR8/rtl/vhdl">boards/XLR8/rtl/vhdl</a>: The XLR8 specific code, containing the top module that mainly maps the XLR8 specific IO pins to the generic one from Retro-uC.</li>
</ul>
</li>
<li><p class="first"><a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC/tree/08a6f51c3b1925018ceebd9ee99265d8e73c6110/boards/XLR8/demo">boards/XLR8/demo</a>: The demo files.</p>
<ul class="simple">
<li>buspirate.cfg & playsvf.sh: Support files for using OpenOCD to access the JTAG interface</li>
<li>blink_boundaryscan.svf & blink_memmap.svf: hand written SVF files</li>
<li>In leds_c the C code is available together with the compile.sh scripts the generates the two other svf files using the two C comilers mentioned earlier.</li>
</ul>
</li>
</ul>
<p>If you want to redo the demo from the release tarball the included README details how to program the XLR8 and run the tests. One warning though: when the Retro-uC core is programmed on the XLR8 it can't be accessed anymore through the Arduino IDE and needs to be accessed through the JTAG pins. So only do the demo if you feel comfortable with this.</p>
</div>
<div class="section" id="feedback">
<h2>Feedback</h2>
<p>I am interested in all feedback; be it questions & comments or ideas, tips, tricks etc. Feedback can be given on the <a class="reference external" href="https://hackaday.io/project/27091-chips4makers-pilot-retro-uc/log/145585-retro-uc-blink-demo-on-xlr8">log</a> on the <a class="reference external" href="https://hackaday.io/project/27091-chips4makers-pilot-retro-uc">Retro-uC Hackaday project page</a> or through an <a class="reference external" href="mailto:staf@fibraservi.eu?subject=BlinkDemo">email</a>.</p>
</div>
Chips4Makers @ FOSDEM 20182018-02-02T00:00:00+01:002018-02-02T00:00:00+01:00Fatsietag:chips4makers.io,2018-02-02:/blog/chips4makers-fosdem-2018.html<p>When writing this I am putting the last efforts in my presentations for <a class="reference external" href="https://fosdem.org/2018">FOSDEM 2018</a>. I will have two presentations there:</p>
<ul class="simple">
<li><a class="reference external" href="https://fosdem.org/2018/schedule/event/cad_os_asic">The open source EDA tool chain for the Chips4Makers project</a> in the <a class="reference external" href="https://fosdem.org/2018/schedule/track/cad_and_open_hardware/">CAD and Open Hardware devroom</a></li>
<li><a class="reference external" href="https://fosdem.org/2018/schedule/event/retro_uc/">Retro-uC - An open source microcontroller with retro instruction sets</a> in the <a class="reference external" href="https://fosdem.org/2018/schedule/track/retrocomputing/">Retrocomputing …</a></li></ul><p>When writing this I am putting the last efforts in my presentations for <a class="reference external" href="https://fosdem.org/2018">FOSDEM 2018</a>. I will have two presentations there:</p>
<ul class="simple">
<li><a class="reference external" href="https://fosdem.org/2018/schedule/event/cad_os_asic">The open source EDA tool chain for the Chips4Makers project</a> in the <a class="reference external" href="https://fosdem.org/2018/schedule/track/cad_and_open_hardware/">CAD and Open Hardware devroom</a></li>
<li><a class="reference external" href="https://fosdem.org/2018/schedule/event/retro_uc/">Retro-uC - An open source microcontroller with retro instruction sets</a> in the <a class="reference external" href="https://fosdem.org/2018/schedule/track/retrocomputing/">Retrocomputing devroom</a></li>
</ul>
<p>Hope to see you all there.</p>
Retro-uC Campaign Product Options2018-01-31T00:00:00+01:002018-01-31T00:00:00+01:00Fatsietag:chips4makers.io,2018-01-31:/blog/retro-uc-campaign-product-options.html<p>Finally I see a light at the end of the tunnel and is the launch of the Retro-uC campaign getting closer. In this post the different options for the campaign will be presented in their current state. Changes are still possible until the launch of the campaign. All feedback is …</p><p>Finally I see a light at the end of the tunnel and is the launch of the Retro-uC campaign getting closer. In this post the different options for the campaign will be presented in their current state. Changes are still possible until the launch of the campaign. All feedback is highly appreciated, so head over to the <a class="reference external" href="https://hackaday.io/project/27091-chips4makers-pilot-retro-uc/log/86360-retro-uc-crowdfunding-campaing-product-options">Hackaday.io project site for the Retro-uC</a> if you want to comment.</p>
<dl class="docutils">
<dt>Four options are currently foreseen:</dt>
<dd><ul class="first last simple">
<li>The chip itself</li>
<li>The chip mounted on a board that is breadboardable</li>
<li>The chip mounted on a prototyping board</li>
<li>The chip integrated in a stand-alone board with Arduino compatible IO layout</li>
</ul>
</dd>
</dl>
<p>All three PCB design are done in KiCad and available in the KiCad directory in the <a class="reference external" href="https://gitlab.com/Chips4Makers/Retro-uC">Retro-uC git repository</a>.</p>
<div class="section" id="the-chip">
<h2>The Chip</h2>
<p>The chip itself will contain the three retro cores: Z80, MOS6502 and Motorola 68000 compatible CPUs with some on-chip memory and lot's of IO. The size of the on-chip RAM is not fixed yet but is going to be a few KB.
For the package currently a 100-pin QFN package is assumed but this may also still change.</p>
<p>Originally two versions of the chip were investigated one with low number and one with a high number of IOs. But after further investigation it was seen that due to cost of sawing the smaller chips the cost difference would be small. With only one chip, the setup cost for packaging has to be paid only once and the logistics are also easier. Also the on-chip RAM available for the low IO chip would have been quite limited. Thus it was decided to go for only the big IO chip.</p>
<dl class="docutils">
<dt>An overview of the pins:</dt>
<dd><ul class="first last simple">
<li>VIO, VCORE, GND, GNDIO: The power pins, 4 of each are provided. The IO voltage will be 5V and the voltage for the logic on the chip will be 3.3V.</li>
<li>TCK, TMS, TDI, TDO, TRST_N: JTAG interface that is used for testing the chip but also used for loading programs in the on-chip RAM.</li>
<li>ENZ80, EN6502, ENM68K: Pins that can select which core is running. Currently only one core is planned to be active at the same time so there will be priorioty in between the chips. During further development it may be decided to allow more than one active. But only if there is minimal risk of having a non-functioning chip and if the boot sequences of the cores can be made compatible.</li>
<li>I2CBOOT: When this pins is high the on-chip RAM will be loaded from an external I2C Flash chip. It it is low the program will need to be loaded through the JTAG interface.</li>
<li>CLK, RESET_N: The clock and reset of the chip.</li>
<li>PA1-PA10, PB1-PB21, PC1-PC21, PD1-PD21: 73 General purpose 5V IOs</li>
</ul>
</dd>
</dl>
</div>
<div class="section" id="breadboardable-pcb">
<h2>Breadboardable PCB</h2>
<p>This is a PCB with the chip mounted that can be used on a breadboard. The chip can be used using only the two outer rows but if more IO capability is wanted this can be done through the inner via arrays.
There are four DIP switches on this board with which one can determine the state of the ENZ80, EN6502, ENM68K and the I2CBOOT pins. The board should then be functional when just providing the two supply voltages, a clock and an external I2C Flash chip that stores the program.</p>
<img alt="Breadboardable PCB Front" src="images/20180131_Retro_uC-Breadboard-Front.png" style="width: 2.54cm;" />
<img alt="Breadboardable PCB Back" src="images/20180131_Retro_uC-Breadboard-Back.png" style="width: 2.54cm;" />
</div>
<div class="section" id="prototyping-pcb">
<h2>Prototyping PCB</h2>
<p>This is a PCB with the chip mounted with prototyping areas inspired by the <a class="reference external" href="https://www.crowdsupply.com/ben-wang/perf-2">Perf+ 2 prototyping PCB boards</a>. The prototyping areas have horizontal copper lines on the front and vertical ones on the back. This allows to do routing by soldering and without the need of jumper wires. In between the prototyping area solder bridges are foreseen that allows to continue the horizontal and vertical traces. If the solder bridges are left open, DIL components can be mounted on the board without the need for cutting PCB traces.</p>
<img alt="Prototyping PCB Front" src="images/20180131_Retro_uC-ProtoPlus-Front.png" style="width: 18.8cm;" />
<img alt="Prototyping PCB Back" src="images/20180131_Retro_uC-ProtoPlus-Back.png" style="width: 18.8cm;" />
</div>
<div class="section" id="retrino">
<h2>Retrino</h2>
<p>This is a board with IO layout compatible with the Arduino MEGA. Currently only digital 5V IO is planned to be supported, no analog features are present. The use case for the board is to be able to use Arduino (MEGA) shields from assembly programs using the supported retro instruction sets. There are currently no plans to port the Arduino IDE as then one could better use a standard Arduino board.</p>
<p>Next to the Retro-uC on the board is an stm32f0 ARM Cortex-M0 microcontroller from ST. It will allow to program the board through a USB connection with a computer and store the program in the on chip non-volatile memory. Once programmed the board can be used stand-alone by providing it 5V on the micro-USB. The ARM microcontroller with then boot the Retro-uC from it's on-chip non-volatile memory. Additionally a voltage-regulator is on board that will generate the 3.3V out of the 5V provided on the USB port.</p>
<img alt="Retrino Front" src="images/20180131_Retro_uC-Retrino-Front.png" style="height: 5.5cm;" />
<img alt="Retrino Back" src="images/20180131_Retro_uC-Retrino-Back.png" style="height: 5.55cm;" />
</div>
The Buzzword Article Part 3: Makers2017-12-31T00:00:00+01:002017-12-31T00:00:00+01:00Fatsietag:chips4makers.io,2017-12-31:/blog/the-buzzword-article-part-3-makers.html<p>In the third blog post in the discussion on buzzwords related to the Chips4Makers projects I will be talking about one that part of the name of the project.</p>
<div class="section" id="the-hype">
<h2>The Hype</h2>
<p>The two biggest movements that can be seen as the forefront of the maker movement are the <a class="reference external" href="https://en.wikipedia.org/wiki/Arduino">Arduino</a> and …</p></div><p>In the third blog post in the discussion on buzzwords related to the Chips4Makers projects I will be talking about one that part of the name of the project.</p>
<div class="section" id="the-hype">
<h2>The Hype</h2>
<p>The two biggest movements that can be seen as the forefront of the maker movement are the <a class="reference external" href="https://en.wikipedia.org/wiki/Arduino">Arduino</a> and the <a class="reference external" href="https://en.wikipedia.org/wiki/Raspberry_Pi">Raspberry Pi</a>. These two pieces have sold by the millions and have grown much bigger than expected. With both tools users can do things themselves and not buy an of the shelf part.</p>
<p>When looking at the history of both projects it's interesting to see that both of them started with education in mind and not with profit as a first motif. Both of projects became commercial due to popularity and I would even use the word necessity. Arduino started as cheap teaching aid for non-technical students and the Raspberry as introductory tool to computing for kids. The history of Arduino is also filled with personal, academic and corporate infighting including some law suits. This shows that open source doesn't make a project immune for some human social imperfections.</p>
<p>Given the success of these two projects also interest was coming from the corporate world with projects like the <a class="reference external" href="https://en.wikipedia.org/wiki/Intel_Edison">Intel Edison</a>. None of these initiatives have up to now been able to overtake the original projects given earlier. In general it's always quite difficult to overtake a successful first mover but it at least shows that open source projects can resist classic money driven corporate marketing push. Although difficult to derive from the facts, it's also my opinion that one of the reasons is that makers are more aware of what they actually want and thus less susceptible to classic marketing tricks. That's also a factor for me why I went with crowd-funding as explained in the <a class="reference external" href="the-buzzword-article-part-2-crowdfunding.html">previous blog post</a>.</p>
</div>
<div class="section" id="a-revival">
<h2>A Revival</h2>
<p>Actually the maker movement is not new but can be seen as a revival of the hacker movement from 80's/90's under a new name.</p>
<p>The original hacker movement was also driven by people who wanted to understand things and how things could be changed (hacked) but also by beliefs like that information wants to be free. Of course it was not always liked by the companies if hackers made public ways on how to phone for free or background information on the sleazy business and marketing tactics used. These companies then did lobbying and marketing to put the hacker movement in a bad light. True, this was also helped by the fact that the distinction was often unclear between the hacker movement and the cracker one; the latter who focused on (illegal) personal gain. Time has changed; the cracker movement has gone underground and producing things like malware and is highly driven by illegal derived gain. The thinkerers have now the maker movement and the information freedom, human rights, privacy and similar movements are now all a publicly represented by pressure groups.</p>
<p>I'm writing this on my way home from the <a class="reference external" href="https://events.ccc.de/congress/2017/wiki/index.php/Main_Page">34C3 Conference</a>; the 34th conference organized by Chaos Computer Club from Germany. This club and conference is thus already going from the 80's and have been was a big driving forces in the hacker movement.
It was my first time there although I was already familiar with the club from my young C64 and Amiga years. I was impressed by the organization of the conference where more than 15000 people met. No small feat I would say for a bunch of hackers and volunteers. Also the quality of the presentations was higher than I am used to from my 'professional' live. I suppose it's because all presenter are passionate about what they are doing and not their day to day job.</p>
</div>
<div class="section" id="the-difficult-road">
<h2>The Difficult Road ?</h2>
<p>Given the nature of the makers/hackers trying to produce something they like is likely not the easiest road to take. But myself being a hacker/maker myself I would like to try it as it is something I am passionate about. I am also of the opinion open silicon would be liked by some of the makers. If I fail at least I have spent my time on something I am passionate about.</p>
<p>After having felt the maker/hacker vibe live at 34C3 I'm full of new energy to work further on continue the Retro-uC project and get through the slow progress in the discussions on the production.</p>
</div>
The Buzzword Article Part 2: Crowdfunding2017-11-26T00:00:00+01:002017-11-26T00:00:00+01:00Fatsietag:chips4makers.io,2017-11-26:/blog/the-buzzword-article-part-2-crowdfunding.html<p>In this second part of the article covering buzzwords I will be discussing crowdfunding which is also hot at the moment. The phenomenon is likely already over the 'Peak of Inflated Expectation' in the <a class="reference external" href="https://en.wikipedia.org/wiki/Hype_cycle">Hype Cycle</a> and on the way to maturity. For the Chips4Makers project and open source silicon …</p><p>In this second part of the article covering buzzwords I will be discussing crowdfunding which is also hot at the moment. The phenomenon is likely already over the 'Peak of Inflated Expectation' in the <a class="reference external" href="https://en.wikipedia.org/wiki/Hype_cycle">Hype Cycle</a> and on the way to maturity. For the Chips4Makers project and open source silicon in general I think it is a major enabler.</p>
<p>With classic investing one has to invest the money for development and first production run before going to market. Often external investor or investors are attracted to fund part of the money. But these investor(s) also expect to get return on their investment (<a class="reference external" href="https://en.wikipedia.org/wiki/Return_on_investment">ROI</a>) and will have thus their say on the direction of development. The owner of the idea and/or company is thus not for the fully 100% boss anymore and the investors will have influence; especially if original targets are not met. Additionally it often means a certain expectation on growth so just serving a niche market without pushing into other directions is most of the time not an option.</p>
<p>With crowdfunding the money will be coming from much more people (e.g. the crowd). You have forms in a more classical setting where bonds or shares are sold to several people. Other type is the signle product financing crowdfunding of which <a class="reference external" href="https://www.kickstarter.com/">Kickstarter</a> is a known example. In this model for a specific product a target amount of money is put as a goal for needed investment and the product is produced when that target is reached with enough people donating. After production has completed the investors will then receive the product. This allows to test the market need for a product without the need to do a lot of pre-investing. Of course it is not without risks of the investors. Some unforeseen development costs or technical problems may deplete the invested money before the product is ready and have the investors still loose their money.</p>
<p>One of the reasons I choose <a class="reference external" href="https://www.crowdsupply.com/">Crowd Supply</a> for crowdfunding Retro-uC is that they actively help project owners resulting in a good track record in projects that succeeded in reaching their goal. Another reason is that they are focused on open source electronic products. I certainly want to avoid the <a class="reference external" href="http://www.orsoc.se/">ORSoC</a> fiasco where they organized a crowdfunding campaign for an open source OpenRisc chip by themselves. They never reached their goal and the investors lost their money. By using <a class="reference external" href="https://www.crowdsupply.com/">Crowd Supply</a> for the Retro-uC, investors know they will get the money back if the investment goal is not reached and allows me to test the market. I am currently spending quite some time on getting the financial picture clear before starting the campaign. This takes longer than expected and also is reason why the launch is delayed from the original November target. I do plan to go into more detail in one of the next blog posts on the adventure I am going trough.</p>
<p>After the Retro-uC project I also see an important role for crowdfunding for Chips4Makers to grow. Making custom chips has a high start-up cost, and to reduce that the chip manufacturers and semiconductor service companies provide <a class="reference external" href="https://en.wikipedia.org/wiki/Multi-project_wafer_service">MPW services</a> where different projects are combined on one mask set and thus the start up costs are shared. These services can be used for open silicon projects but the restrictions on design size, timing, volume, NDAs, etc. may not be ideal for small volume production as they are optimized for prototype production. For Chips4Makers I do want to build on that by having several people launching crowdfunding campaigns for open silicon products. The final campaign is only successful if a number of projects reach the goal and these projects are then combined on one production run. This would optimize the cost and effort further, resulting in lower start-up cost and less volume needed per project than when projects would be run separately. All this is currently a dream and details can only be worked out after first successfully completing the Retro-uC pilot project.</p>
The Buzzword Article Part 1: Open Source2017-11-12T00:00:00+01:002017-11-12T00:00:00+01:00Fatsietag:chips4makers.io,2017-11-12:/blog/the-buzzword-article-part-1-open-source.html<p>We live in a world with mass production and consumption of goods. In order to stand out from the pack and to sell a lot of things the marketing of the goods is an important part of doing business in this setting. For this marketing often buzzwords are used to …</p><p>We live in a world with mass production and consumption of goods. In order to stand out from the pack and to sell a lot of things the marketing of the goods is an important part of doing business in this setting. For this marketing often buzzwords are used to attract people.</p>
<p>We all like to think we are special and different than the rest. In reality we are mostly gregarious animals being part of herds in our work environment, sports club, church community, etc. Some of the really special people may earn their money as artists but most of them will be ignored or even become the avoided weirdo.</p>
<p>Being special we also think that the empty marketing buzzwords are not applicable to us but in reality the buzzwords do indicate trends and can be used as guidance to analyze use cases for a project. In the next few blog posts I will investigate some buzzwords and their applicability to the Chips4Makers project and it's Retro-uC pilot project. I will also dive into a few buzzwords not directly applicable to give more background on my reasoning behind the Chips4Makers project and my (twisted) thinking in general. The nice thing about humans being able to think is that we can also differ in opinion. I am happy to hear any feedback on my posts here by using the contact link in the left banner of this blog.</p>
<div class="section" id="open-source">
<h2>Open Source</h2>
<p>Recently you can see open source mentioned in a lot of places. Sometimes it's not much more than a marketing term used to attract people but without much substance and used companies with a classic proprietary mind set. Some of my thoughts on the subject I used for a <a class="reference external" href="https://www.youtube.com/watch?v=lQjC2NaaUAg&list=PLUg3wIOWD8ypZnjCc_M08APZ7NSuET4G1&index=24">presentation I did @ the last OrConf conference</a>.</p>
<p>For the Chips4Makers project I find open source an essential ingredient to make it possible. The purpose of the Chips4Makers project is to make real low volume custom chips possible. For mature technology nodes the production costs are not the main contributor anymore to the cost of a chip. The <a class="reference external" href="https://en.wikipedia.org/wiki/Electronic_design_automation">EDA</a> software to design the chips and the licensing costs for <a class="reference external" href="https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core">IP</a> sub-blocks are a major contributor. Open source is needed to reduce these costs.</p>
<p>I don't envy the <a class="reference external" href="https://en.wikipedia.org/wiki/Electronic_design_automation">EDA</a> software companies. For the state-of-the-art chip technology the process of designing the chips is becoming very complex. You not only have the exponential increase in number of devices on the chips themselves but also additional process complexities: increasing power density on the chips, double or multi-patterning, decreasing supply voltage or even dynamic voltage/frequency scaling, higher variation in performance between transistors on a chip and from chip to chip, etc. This means developing the tools to make chips for these nodes needs a lot of investment and this investment has to be earned back by licensing the software. Additionally if you ask a big stash of bucks to use your software they also expect reasonable support which needs trained people who can provide this. There is more than one <a class="reference external" href="https://en.wikipedia.org/wiki/Electronic_design_automation">EDA</a> company so you also need sales people that try to convince their tool is better than their competitor's. This all increases the overhead and the total amount of money to be made by licensing of your software. For these state-to-the-art nodes the start-up costs for producing chips is several million of dollars so high (some would say professional) software license costs for the software are acceptable. For mature nodes with start-up cost going even down to only several thousands of dollars this is not the case. It is very difficult for the <a class="reference external" href="https://en.wikipedia.org/wiki/Electronic_design_automation">EDA</a> companies to support the latter requirements; there is not enough money in that market to contribute to their bottom line. That's why I think that initiatives like the <a class="reference external" href="https://fossi-foundation.org">FOSSi Foundation</a> or the <a class="reference external" href="https://www.ohwr.org/projects/ohr-meta/wiki/FOSDEM2018">CAD and Open Hardware Devroom @ FOSDEM</a> are essential to get the open silicon movement from the ground.</p>
<p>For the Chips4Makers and the Retro-uC project I will be using open source as much as possible and identify gaps in the tool chains and contribute improvements where time permits. I will be pragmatic in the use of proprietary tools. Contrary some other people I don't have ethical problems with the existence or the use of proprietary tools. I do think though a fully open source <a class="reference external" href="https://en.wikipedia.org/wiki/Electronic_design_automation">EDA</a> tool chain is a long term requirement for a successful open silicon movement. Even if we would get support from some proprietary tool suite a change in strategy can cause problems in the future. An open source tool chain will always make it possible for people to take over and solve hiccups in the support or functionality.</p>
<p>Next to the software you also have the <a class="reference external" href="https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core">IP</a> sub-blocks. For open silicon to succeed everyone reinventing the wheel all the time is not ideal. They should be able to stand on the shoulders of giants by reusing the <a class="reference external" href="https://en.wikipedia.org/wiki/Hardware_description_language">HDL</a> code of other projects. Here efforts like <a class="reference external" href="https://www.librecores.org/">LibreCores</a> and tools like <a class="reference external" href="https://github.com/olofk/fusesoc">FuseSoC</a> are important parts of the puzzle. Problem is that the used <a class="reference external" href="https://en.wikipedia.org/wiki/Hardware_description_language">HDL</a> languages themselves seem to make it difficult to design generic re-usable code. Going into detail is going too far for this article but I do hope to find the time to go into more detail in a future post. For the Retro-uC pilot project I am using existing open source blocks and also the extra blocks that are developed will be made available for reuse in next projects. In that respect this pilot project is also a prove of the functionality of these blocks on a custom chip.</p>
<p>So for the Chips4Makers project to succeed I thus think open source is an essential part. In open source cooperation is import and I realize an open silicon movement can't be made successful by a single person. People with suggestions, propoals or just a (weird) idea to discuss should not hesitate to use the contact link provided on this blog site.</p>
</div>
Start of a new blog2017-10-22T00:00:00+02:002017-10-22T00:00:00+02:00Fatsietag:chips4makers.io,2017-10-22:/blog/start-of-a-new-blog.html<p>Inspired by the <a class="reference external" href="https://www.youtube.com/watch?v=L4nO9Bmn-Ow&index=9&list=PLUg3wIOWD8ypZnjCc_M08APZ7NSuET4G1">LibreCores talk of Philipp Wagner</a> at <a class="reference external" href="https://www.youtube.com/watch?v=0Hp5EMZSKrg&list=PLUg3wIOWD8ypZnjCc_M08APZ7NSuET4G1">ORConf 2017</a> I now decided to start a blog
for the Chips4Makers project. Overall the <a class="reference external" href="https://www.youtube.com/watch?v=0Hp5EMZSKrg&list=PLUg3wIOWD8ypZnjCc_M08APZ7NSuET4G1">ORConf 2017</a> conference was inspiring and it was nice to
meet real hackers, makers and open source EDA enthousiasts.</p>
<p>When I was heading to the conference …</p><p>Inspired by the <a class="reference external" href="https://www.youtube.com/watch?v=L4nO9Bmn-Ow&index=9&list=PLUg3wIOWD8ypZnjCc_M08APZ7NSuET4G1">LibreCores talk of Philipp Wagner</a> at <a class="reference external" href="https://www.youtube.com/watch?v=0Hp5EMZSKrg&list=PLUg3wIOWD8ypZnjCc_M08APZ7NSuET4G1">ORConf 2017</a> I now decided to start a blog
for the Chips4Makers project. Overall the <a class="reference external" href="https://www.youtube.com/watch?v=0Hp5EMZSKrg&list=PLUg3wIOWD8ypZnjCc_M08APZ7NSuET4G1">ORConf 2017</a> conference was inspiring and it was nice to
meet real hackers, makers and open source EDA enthousiasts.</p>
<p>When I was heading to the conference on a morning I saw this sign in a window:</p>
<img alt="Don't Dream It Be It!" src="images/20170909_DreamBe.jpg" style="width: 400px;" />
<p>I found it fit for the ORConf conference in general as there a lot of people who are contaminated
with the open source virus and wanting to bring what has started in the software world end of last century
and want to bring that also to the EDA and the silicon world. I did find it also fit for me. Since I
graduated mid nineties I have been full of ideas but typically never went to implementation. With
the Chips4Makers project I plan now to change that.</p>
<p>On this blog you can expect to find first-all more technical background on the Retro-uC pilot project
and other future projects. But you will also find some rumblings from me on open source, open silicon, EDA,
licensing and similar here. I do plan to also go further in some of the questions and comments I got on
my two ORConf presentations (<a class="reference external" href="https://www.youtube.com/watch?v=4zNRTudEl_4&list=PLUg3wIOWD8ypZnjCc_M08APZ7NSuET4G1&index=13">1</a>, <a class="reference external" href="https://www.youtube.com/watch?v=lQjC2NaaUAg&list=PLUg3wIOWD8ypZnjCc_M08APZ7NSuET4G1&index=24">2</a>).</p>
<p>And for the people who have seen my ORConf presentation, it was a chock for me to discover I could not buy
an Amiga magazine anymore with the left over change when I was at the airport on my way home...</p>