[FEL]: archimedes 2.0.0 stable release

Archimedes, the 2D Quantum Monte Carlo simulator for semiconductor devices, has been updated on both Fedora and EPEL testing repositories.

Since last FEL release, archimedes entails the following changes:

• The material parameters have been checked and modified
• Benchmark tests were carried out to check the validity of the framework
• Scattering phonons can be set to ON or OFF
• Support for Full band approach was implemented
• Parabolic, Kane and Full bank verified
• Full band parameters supports for all materials
• Initial implementation of FEM for Poisson
• Quantum Effective Potential modified
• Bohm Potential Model was implemented
• Calibrated Bohm Potential Model was implemented
• Density Gradient corrected and tested
• Full effective potential model was implemented

 

Filed under: asic

A freeware GLADE as an IC layout editor

It’s the first time, I’m writing about a freeware. But even though it is not opensource, this freeware does have interesting features which Toped developers are working on for Toped.

Glade is capable of reading GDS2, OASIS, LEF and DEF. Some of its features are;

• Fast, hardware accelerated OpenGL graphics;
• Import/Export GDS2, OASIS, DXF, LEF, DEF and Verilog;
• Import Cadence display.drf and techfiles directly;
• Edit and display hierarchy from 0 to an unlimited number of levels;
• Create instance, label, rectangle, path, polygon, via, pin commands with interactive display during enter;
• Layer select window for setting layer visibility/selectability, current layer, choosing layer colour and transparency, fill pattern, line style/width and setting layer names;
• …and many others!

Since Glade being just a freeware and not opensource, it will not be available under the Free Electronic Lab(FEL) umbrella, the user is ought to download it from the developer’s website and execute the following commands manually.

$ export GLADE_HOME=`pwd`
$ export PATH="$PATH:$GLADE_HOME/bin"
$ export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$GLADE_HOME/lib"

Since Glade was not compiled under a FEL compatible repository, it crashes frequently. In either case, I would also recommend FEL users to use toped 

# yum install toped

or magic

# yum install magic

as they are tested and deeply rooted into FEL’s proposed design flows.

Filed under: asic

Floorplanning with Magic, how hard can that be ?

Alliance VLSI development cycle has stalled and there are many software compatibility issues that need to be solved before getting a proper (one that can meet the industry’s needs) digital backend flow with opensource software. Herb which was meant as a clone for Alliance VLSI will not be stable enough at the end of this year, nor I would expect some Mixed-Signal designs from it.

Since it won’t be TCL based, I doubt I would even use Herb myself. Hence, I’m investigating further on what should be done before one can design a mixed signal chip with the industry’s requirements.

Magic VLSI is fairly analog oriented, it is TCL based and it is lambda based. Since it is TCL based, it deserves credits. But being lambda based it makes it hard to go beyond 90nm process node with it since it won’t be accurate enough. Surely a timing correlation would prove this.

Magic’s 2 grid cells normally represent the length of the transistor. However, macro models of SRAM/ROM available in the LEF format include decimal points to reflect the position of different metal layers and vias. This is a major drawback with Magic VLSI.

Achieving digital implementation with Magic would certainly require new techniques about  how to use magic itself and how metrics (resistances, capacitances, switching activities,..) are extracted.

I started today with a case scenario: try to get a simple floorplan setup with some macro models. Nigel Nordsworth has kindly forwarded some Macro models. He is FEL’s test contributor for more than a year now. As mentioned above, LEF files might include X and Y positions with 3 decimal points in microns. Hence, to load the macro models, these X and Y positions should be multiplied by 1000 and thereby converting them into the nanometer scale.

Our current possible solution would be to use a Magic’s grid cell to represent 1 nm². This is not how one would normally use Magic. The complexity slope rises as all the tech files should be revisited and possibly be project dependent. Being project dependent, the solution would not be useful for the normal user. But once we can get a proper TCL package with can help us rotate the macro models and one of the 3 internal routers of magic can actually do some power routings (VDD and GND), we will present our solution for standardization.

instance_name ""
foreach instance [ cellname list instances ] {
    if { $instance == $element_name } {
         set instance_name $element_name
    }
}

select cell $instance_name
instance celldef $instance_name

regsub {\.} $xl {} xl
regsub {\.} $yl {} yl
move to $xl $yl

puts "Info: Moved the following selected Macro to ($xl,$yl)"

Using the above TCL commands just to move around the macro model I believe that a digital implementation should be feasible with Magic VLSI. But some intelligent mechanisms should be investigated about the timing and power correlations. As I wrote in the past, coupled with IRSIM we can even estimate leakage power out of the design during standby mode.

It should be exciting to design low power and low voltage designs.

Filed under: alliance, asic, magic

[FEL]: Standard Cell characterisation – part two

Xcircuit 3.6 series brings on technology library support, which enables anyone to maintain customed analog or digital IPs, independent of the schematic design. This powerful feature, coupled with ngspice, helps the designer to maintain their spice commands within the testbench schematic. It will automatically extracts the spice netlists with the subcircuits included, then from the tcl console simulate the design.

However this was not working out of the box and the user needed to patch ngspice. Since ngspice rework 17, Fedora’s ngspice was patched accordingly. But with ngspice rework 19, it broke. This week Holger Volgt improved the patch and merge it to ngspice cvs branch.

This blog post will briefly show a testcase about how to invoke ngspice within Xcircuit directly.

Launch Xcircuit and load your design. Here, I’ll take a simple invertor as example. Then launch the Tcl console from the file menu and type

::xcircuit::spice start

If you encounter this error, you are certainly using an older version of ngspice.

There is already an update in the fedora repositories which fixes this issue.

On the screenshot below, you can see the invertor in a test situation alongside spice commands for the simulation. Hence there is no need to maintain extra file or makefile to launch SPICE simulation. Everything is launched and saved by Xcircuit in a postscript format.

::xcircuit::spice start

(extracts the spice netlist and sets the initial condiction.)

::xcircuit::spice run

(executes the simulation)

::xcircuit::spice send “plot v(Vin) v(Vout)”

(sends the plot command to ngspice and displays the plot)

Arun SAG has recently filed a package review request for emacs-spice-mode. Once approved and pushed to Fedora repositories, you can execute spice simulations within emacs as well.

Filed under: asic, emacs, feature, fedora, Free Electronic Lab, IP, xcircuit

[FEL]: Standard Cell characterisation – part one

Both xcircuit and ngspice has been updated for Fedora/EPEL-5 last week with some key features to boost productivity for standard cell characterisation. I’ll explain briefly in two blog posts, thus this one is the first post.

Last week, Fedora users have updated their ngspice rework 19 to rework 20 (20-1.fc12), with the following key highlights :

• Updated BSIM4 code to BSIM 4.6.5 in accordance to this document.
• Piecewise linear(PWL) functionality for B sources.
• Support of 5-terminal bjt’s in subckt’s by prepending subckt name (similar things should be made for 5-7 terminal mos transistors, like soi models).
• New measurement code, which is the most awaited feature for standard cell characterisation.

Currently the measurement code is still undocumented, so I hope this blog post will help ngspice users understand with their baby steps with ngspice’s .meas command. Though it follows the same syntax as HSpice, it still not yet complete. Hopefully the next ngspice releases will smooth the edges.

.meas command

Anyone who is characterising standard cells can now use .meas command and it surely helps to maintain an automatic flow.

For the sake of simplicity, I’ll cover a transient simulation as example, however one can also use it for voltage transfer characteristic of the cell.

.tran 0.1 18n uic

Define a parameter :

.param vp = 3.0v

Calculate maximum voltage of signal Vout from 4 ns to 10 ns

.meas tran vmax max v(Vout) from 4n to 10n

Calculate minimum voltage of signal Vout from 6 ns to 15 ns

.meas tran vmin min v(Vout) from 6n to 15n

Calculate the fall delay between the falling edge of the signal Vin and the falling edge of signal Vout. (note the use of parameter ‘vp’ here)

.meas tran delay_f trig v(Vin) val=’vp/2′ fall=1 targ v(Vout) val=’vp/2′ fall=1

Calculate the rise delay between the rising edge of the signal Vin and the rising edge of signal Vout. (note the use of parameter ‘vp’ here)

.meas tran delay_r trig v(Vin) val=’vp/2′ rise=1 targ v(Vout) val=’vp/2′ rise=1

These are the basic .meas commands which can be extended for ripple calculation and many of the user’s needs. The above image, created with ‘dia’, describes visually those commands.

Upon simulation, ngspice will output :

…

Transient Analysis

vmax                =  3.300000e+00 at=  1.000000e-08

vmin                =  2.589696e-04 at=  1.480631e-08

delay_f           =  4.780022e-10 targ=  1.052800e-08 trig=  1.005000e-08

pdelay_r           =  2.980831e-10 targ=  5.448083e-09 trig=  5.150000e-09

…

More examples can be found about the .meas command with

$  rpm -qld ngspice-doc | grep meas

Filed under: asic, eda, feature, fedora, Free Electronic Lab, ngspice

[FEL]: Power Estimation at transistor Level

One of the least advertised features of IRSIM is its ability to quickly estimate power of large VLSI circuits from gate level netlists (.sim).

To install IRSIM on Fedora (default on Fedora Electronic Lab):

# yum install irsim

This estimation is based on the

• ‘three-level quantization scheme’, where the voltage can assume 3 values (GND, VDD/2 and VDD). It is fairly more accurate than the ‘two-level rail-to-rail model’.
• measurement of glitching power.
• estimates reasonably close to those that can be derived by measuring currents with a SPICE simulator with an error of less than 20% and a speed up of about 500 times.
• incremental power measurement.

Filed under: asic, opencircuitdesign

[FEL]: Status of Electric VLSI on Fedora

Fedora 11 stable repositories provides Electric VLSI 8.08. Upstream released a new release version 8.09 which won’t be pushed to Fedora stable repositories.

Please note that because most of the Fedora electric userbase (I’m referring to mostly universities in France and Japan) use third party plugins that due to the licensing incompatibilities wih Fedora, FEL can not entail those plugins. That said, Fedora Electronic Lab team understands that releasing a new upstream version would break interoperability with the user’s plugins.

Hence new versions of electric will only make their way to the fedora updates-testing repository.

# yum install electric –enablerepo=updates-testing

Electric is one of the FEL packages which by Fedora user’ requests we are giving most of our attention.

Filed under: asic, fedora, electric

A junior ASIC Guy Visits An FPGA World

The title of this blog post was copied from Harry Gries’s blog post An ASIC Guy Visits An FPGA World and reflects my thoughts as a junior.

Harry’s observations are oriented towards the “raw” design methodology proposed by the FPGA design tools vendors. Coming from the ASIC environment, we are heavily design methodology oriented and work hard to satisfy design tools. But in the FPGA environment, the design tools provide an even more automated work flow from frontend to backend. Physical design sometimes (depending on the size of the design) seems to take a few minutes. I have seen people even skip the entire the physical design, unless there is a violation somewhere.

I had a few FPGA projects to handoff and though they were for some different medium-sized companies, sometimes I felt that project managers and reviewers were not serious enough like in ASIC environment. I got a few remarks for my VHDL designs which sometimes coming from a senior FPGA designer shocked me. It is true as well that FPGA design was not their prime development base.

One of those remarks which till now I have not really understood the reason between it and why my reasoning was not valid. It concerned my FSMs. They had “next-state” decoding and “output” decoding into two separate VHDL processes. My reasoning which Altera’s appplication notes implies will restrict the synthesis tool from sharing resources with other blocks. The remark I got, during a code review, was “I never seen that in my 12 years career, clean this”. I am still eager to know what advantage will my design have while combining these two processes.

I also got the most chaotic code review experience with other FPGA designers. VHDL code review was left incomplete from my point of view and discarded parts of code review with respect to switching rates, power, … due to lack of time. I was expecting a thorough code review for an optimal the sign-off and hand-off like I used to see with ASIC design teams.

I’m sure this is not true in every FPGA design team. What I was to say here is that during the excursion to the FPGA world, the strict discipline routine one has in ASIC environment just fades away. How quickly? I think it depends on the FPGA design team. I could even feel how disconnected the small companies are from the EDA vendors. However, I wish to get myself involved with a “real” high-performance FPGA based design team to see how discipline they are

While these are issues I personally encountered, I am trying to get Fedora Electronic Lab enough collaborative solutions so that small companies can at least have a decent code review, project hand-off and make FPGA designers happy.

Filed under: asic, fpga

FEL: linsmith and electric 8.08

The Smith Charting program, linsmith, will soon land on fedora repositories as new package.

Electric 8.08 will hit fedora-updates repositories as well in the upcoming hours.

Filed under: asic, electric

EDA: standard cells for chip design

A standard cell is group of transistor and interconnect structures, which provides a boolean logic function (e.g., AND, OR, XOR, XNOR, inverters) or a storage function (flipflop or latch). All CAD tools for chip design (whether proprietary or open source) require standard cell libraries. These standard cell libraries contain primitive cells required for digital design.

A fedora user will have some standard cell libraries from

the alliance package

the pharosc package

# yum install pharosc\*

Pharosc provides five new open source standard cell libraries, the vsclib, wsclib, vxlib, vgalib and rgalib. They have been drawn with the Graal software from Alliance, part of an extensive open source software suite for designing integrated circuits with a standard cell design methodology.

The libraries have been characterized in a generic 0.13µm technology, compatible with most foundry rules. Pharosc is the result of a book that Graham Petley is writing, The Art of Standard Cell Library Design.

Among the standard cells from pharosc there are many scripts to provide interoperability between magic, alliance and xcircuit as well as scripts to allow one to update actual cells or create his/her own cells (pharosc-devel). There are more than 500 spice decks which can be simulated with either gnucap or ngspice.

Each single component in any standard cell library comes with a well documentation html manual.
The latter entails schematics, layouts and several parameters for spice simulation. The transistor schematics for the libraries have been drawn with Xcircuit, which uses Postscript as its native file format.

Pharosc entails Alliance’s sxlib which has been characterised in 0.13µm using the same methodology and converted to the same 0.13µm layout rules. There is also an ssxlib which is the Alliance sxlib converted with a script from 1µm to 2µm layout and adjusted to obey DSM layout rules. The adjustments change the timing slightly.

Filed under: asic, fedora, semiconductor, VLSI