This project is "more or less related" to #Shared Silicon and aims to better prepare and prototype designs in FPGA before committing to ASIC tapeout. I'm currently using this library for the #YGREC8 to check design sanity and testability (which is also why you'll find many references and files from Y8 here).

Lately, Christos joined forces and opened new perspectives and applications for this library, for test/validation/fuzzing through the injection of faults. It enables the verification of test benches and other critical tools, for fault-tolerant circuits, wafer-stepper test vectors...

Currently I'm working on the 2nd version of the library, a deeply refactored and enhanced version, and aiming at a v3 with most desired features in the near future. This becomes even more pressing with the MPW shuttles promised by Google on the Skywater 130nm node.


The library implements gates that can work in one of several modes, as explained in the log Modes of operation.

What can you do now with this ?

What's intended ? (not yet implemented)


It all started as a Free collection of 3-input gates and some additional ProASIC3-specific modules, used to design my own systems.

See the license/ directory for the AGPLv3 terms of distribution.

The proasic3v3/ directory contains all the gates and modules, rewritten to simulate the real tiles and hard macros.

You'll find a series of examples in the testxxxxxx directories, that implement various 8-bits units using only 3-inputs gates and with a well-defined latency.


As of 20200715, the v2 supports these tiles and hard macros:

No input:
GND VCC

1 input:
BUFD   BUFF   CLKINT INV    INVD

2 inputs:
and2    and2a   and2b   nand2   nand2a  nand2b  nor2    nor2a   nor2b   or2     or2a    or2b    xnor2   xor2

3 inputs:
and3    and3a   and3b   and3c   ao1     ao12    ao13    ao14    ao15    ao16    ao17    ao18    ao1a    ao1b    ao1c    ao1d    ao1e    aoi1    aoi1a   aoi1b   aoi1c   aoi1d   aoi5    ax1     ax1a    ax1b    ax1c    ax1d    ax1e    axo1    axo2    axo3    axo5    axo6    axo7    axoi1   axoi2   axoi3   axoi4   axoi5   axoi7   maj3    maj3x   maj3xi  min3    min3x   min3xi  mx2     mx2a    mx2b    mx2c    nand3   nand3a  nand3b  nor3    nor3a   nor3b   nor3c   oa1     oa1a    oa1b    oa1c    oai1    or3     or3a    or3b    or3c    xa1     xa1a    xa1b    xa1c    xai1    xai1a   xo1     xo1a    xor3    xnor3
   zor3    zor3i

4 inputs:
OAI22  AOI22  OAI211  AOI211

Flip-flops:
DFN0     DFN1     DFI0     DFI1    
DFN0C0   DFN1C0   DFI0C0   DFI1C0  
DFN0C1   DFN1C1   DFI0C1   DFI1C1
DFN0E0   DFN1E0   DFI0E0   DFI1E0
DFN0E0C0 DFN1E0C0 DFI0E0C0 DFI1E0C0
DFN0E0C1 DFN1E0C1 DFI0E0C1 DFI1E0C1
DFN0E0P0 DFN1E0P0 DFI0E0P0 DFI1E0P0
DFN0E0P1 DFN1E0P1 DFI0E0P1 DFI1E0P1
DFN0E1   DFN1E1   DFI0E1   DFI1E1
DFN0E1C0 DFN1E1C0 DFI0E1C0 DFI1E1C0
DFN0E1C1 DFN1E1C1 DFI0E1C1 DFI1E1C1
DFN0E1P0 DFN1E1P0 DFI0E1P0 DFI1E1P0
DFN0E1P1 DFN1E1P1 DFI0E1P1 DFI1E1P1
DFN0P0   DFN1P0   DFI0P0   DFI1P0
DFN0P1   DFN1P1   DFI0P1   DFI1P1
DFN0P1C1 DFN1P1C1 DFI0P1C1 DFI1P1C1

Latches:
DLI0     DLI1     DLN0     DLN1
DLI0C0   DLI1C0   DLN0C0   DLN1C0
DLI0C1   DLI1C1   DLN0C1   DLN1C1
DLI0P0   DLI1P0   DLN0P0   DLN1P0
DLI0P1   DLI1P1   DLN0P1   DLN1P1
DLI0P1C1 DLI1P1C1 DLN0P1C1 DLN1P1C1

 

RAM4K9

as well as an "inferred" dual-port RAM block that matches the A3P chips.

ALL THESE FILES ARE PROVIDED AS IS AND ARE NOT A COMPLETE SUBSTITUTE TO THE OFFICIAL FILES. I DIDN'T TEST MOST OF THEM! USE AT YOUR OWN RISKS! (some bugs have lurked in the past)

Check the log 1. definition of the gates for the boolean equations of each gate, or better : the source code in proasic3v3/PA3_genlib.vhdl:ComputeLUT8


These files are first written to help simulate designs optimised for the ProASIC3 family using GHDL without forcing the user to install the Actel/Microsemi toolsuite. Some of my designs (such as the YASEP and YGREC) are written as a behavioural/RTL file and some parts require architecture-specific versions (for speed!) that must be checked for equivalence with the higher-level description.

I provide the gates used by my own designs but more are also included, "just in case" they are needed.

This library is for convenience, hence accuracy could be bad in certain aspects. ALWAYS refer to the latest versions of the files provided by Actel/Microsemi/Microchip !

Why bother ?

The A3P family is quite old and slow by today's standards. It's also a mature family with well understood behaviour but more importantly, as the name implies, it's also very close to ASIC design rules. ASIC design is the real goal.

My design workflow is roughly :

  1. design the general architecture and define the units
  2. design and test individual units in RTL, check functionality
  3. break the unit(s) down to individual 3-input gates and map to A3P tiles
  4. test equivalence with RTL and estimate performance
  5. check on FPGA (for fun !)
  6. given the list of used tiles types, design/import/adapt identical ASIC cells and place/route the ASIC

So the "obsolete" Actel/Microsemi gates are just one intermediary step toward designing totally free ASICs.


More background :

Since I focus on ASIC, testing the chips for faults is critical. Once you get chips from the foundry, how do you know they work ? My end goal is ATVG (Automated Test Vector Generation), which is an evolution of the desire to verify coverage of BIST (Built-In Self Test) methods : How do you know your BIST strategy is correct and how long do you have to run it to ensure the whole system is checked ? This implies to check for many things, which have alternate uses :-)

If you want to have 100% coverage for the BIST or the external test vectors in the factory, you necessarily need to make sure the design is fully observable and controllable. This also implies that all the gates have all their input values combinations used (which implies the circuit is optimal), or the circuit has no hidden parts (or bugs) among other things.

My system relies on the user providing a testbench unit with exhaustive coverage, even by brute-force. The end result would be a set of test vectors that reduce the number of cycles to run the physical verification (because the size grows with the number of gates, not the number of states, ideally).

This is not formal verification, which would ensure that a given circuit actually provides the desired function and nothing else, with a high-level analysis and inference engines. This library is a low-level tool which comes much later in the design flow.

This will also not design the BIST for you, because each system has their own specific constraints, though it's a precious tool in the design workflow.


Logs:
1. definition of the gates
2. More gates !
3. An unexpected boost
4. Project created on OHWR !
5. Generalised fault injection
6. Generalised fault injection - part deux
7. What about coverage ?
8. What if we generated the files for each gate ?
9. Let's generate (most) files
10. Lookup tables !
11. v2 in progress
12. early success with v2
13. v2 with sequential gates
14. v2 beta needs tests !
15. v2.1
16. Typo...
17. Version 2.2
18. The way to v2.3
19. Modes of operation
20. An unexpected turn with the histogram
21. New feature : toggle counter
22. v2.4
23. Winner scanner
24. Hierarchy problems and solutions
25. v2.6 : the netlist generation
26. The right depth
27. DepthLists
28. Zombies in v2.6
29. v2.6 release
30. A simple option
31. v2.9 : introducing 4-input gates
32. Flip Flops (should) work...
33. Abnormal initialisation time and workaround
34. Time travel and zombies
35. Internal Representation in v2.9
36. An even faster and easier algorithm to map the netlist
37. A new scope