Close
0%
0%

VHDL library for gate-level verification

Hard macros and tiles of Actel/Microsemi's ProASIC3 so I can design and verify optimised code without the proprietary libraries

Similar projects worth following
This is a collection of VHDL files that re-implement the gates of a FPGA family, which is close to ASIC structures and that I use to evaluate ASICs. Actel/Microsemi/Microchip provides official definitions and delays for very accurate simulation but these are proprietary files and I don't need such a precision at the early stages of prototyping.I replace these files with mine so I can make truly Free and Open Source designs, which can later be ported to ASIC technology.

This is a work in progress that gets updates when needed by my designs, please forgive the many holes.

I added custom extensions to provide incredibly useful verification features such as logical cone checks, BIST coverage checks, hopefully even BIST vector generation...

The VHDL code is portable '93 but only GHDL scripts (not mcode) are provided.

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

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.


What can you do now with this ?

  • Simulate your mapped design (the initial purpose)
  • Check that the gates behave correctly, with histograms of their activity, and detect unused cases (this helps optimise/simplify a design, or ensure it is optimal)
  • The activity histogram can also be used for investigating toggle-reduction strategies to reduce switching-induced power consumption.
  • Inject unusual signals at inputs to observe the logical cone
  • Alter the function of a given gate (simulate a hardware fault)

What's intended ?

  • BIST verification (brute-force through all the gates is possible thanks to parallelism)
  • Automatic Test Vector Generation
  • Implement LUT4 one day to support classic FPGA (already implemented are LU1-LUT2-LUT3)

From the README.txt :

------------------------------------------------------------------------------------------------------------

This is a "Free" collection of 3-input gates and some additional ProASIC3-specific modules, used to design my processors.

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

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

It depends on the delay/ directory that defines a propagation time for all the tiles.

You'll find an example in the INC8/ directory, that implements an 8-bits increment unit using only 3-inputs gates and with a well-defined latency.

------------------------------------------------------------------------------------------------------------

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

GND VCC

BUFD   BUFF   CLKINT INV    INVD

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

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   ...

Read more »

A3Ptiles_v2.3_20191121.tgz

single-architecture version

x-compressed-tar - 90.16 kB - 11/21/2019 at 06:19

Download

A3Ptiles_v2.2_20191119.tgz

integration of 2 tests, exhaustive failure detection of INC8, pretty good !

x-compressed-tar - 91.15 kB - 11/19/2019 at 07:02

Download

A3Ptiles_v2pre20190825.tgz

Added latches and INC8, packaging/integration not done yet

x-compressed-tar - 88.83 kB - 08/25/2019 at 08:32

Download

A3Ptiles_v2pre20190813.tgz

Many enhancements ! meta-levels and other goodies...

x-compressed-tar - 32.71 kB - 08/13/2019 at 21:59

Download

A3Ptiles_v2pre20190811.tgz

GND/VCC + "non-binary" logic cone detection

x-compressed-tar - 7.66 kB - 08/11/2019 at 15:42

Download

View all 13 files

  • The way to v2.3

    Yann Guidon / YGDES12 hours ago 0 comments

    Hopefully, v3 would implement some sort of ATVG but this is a complex algorithm with several steps, the first of them is to extract the netlist from the "blackbox" of the DUT (Design Under Test). The current version 2.2 is not yet able to do that and the chosen approach is to not analyse the DUT's file themselves, but only use "functional/behaviour" data obtained from 1) running the DUT 2) extracting and injecting information at the inputs/outputs and the gates themselves.

    To extract the netlist, I don't intend to use simulator-provided internal feature. I have chosen the following "greybox" method :

    • list all the gates, add inputs and outputs
    • exclude all the LUT2 and LUT1 gates (inverters, buffers, GND, VCC) because they contribute no useful information
    • Clear all the larger LUTs (with 2 and 3 inputs), set LUT2s as pass-through
    • For each of the inputs and gates, select 7 of them and assign to their output the value '0', '1', 'W', 'Z', 'L', 'H' or '-' (so we can test 7 gates simultaneously)
    • Send "all 'U' " then "all 'X'  " values at the inputs to force the refresh of all the gates => these values will propagate (pass) through the whole design. However, the gates that have a different value will see their value propagated to the inputs of other "sink" gates.
    • Scan all the gates and check their histogram to see which value they receive at their output. If one of the values "01WZLH-" is received, add the n° of the current gate to the list of "sinks" of the sending gate (there would be an array to store this info, which is refreshed for every iteration of the algorithm)
    • After all the inputs and gates are scanned, each of them should have a list of their sources and sinks gates.

    The current code requires many modifications to permit this : for example, the lookup functions in the gates will be deeply altered and the global list of gates will have to hold much more information, in a better structured way. I also want to get rid of the the various architectures of gates and merge some code, which will make the library easier to use and probably even smaller. Hopefully I can find an easy yet efficient way to avoid having the "trace" architecture.

    And of course, I must add the ALU8 as a 3rd example :-)

    Let's do it...


    Here it is ! A3Ptiles_v2.3_20191121.tgz

    It's only a preliminary version where there is only a single architecture, more upgrades will follow.

  • Version 2.2

    Yann Guidon / YGDES2 days ago 0 comments

    I try to clean up my code and integrate the INC8 unit for a much-needed update and the results are looking good :-)

    PA3_genlib.vhdl:151:5:@0ms:(report note): 13x A3P gates found.
    PA3_genlib.vhdl:153:7:@0ms:(report note):  gate number: 0  bit number: -1
    PA3_genlib.vhdl:155:7:@0ms:(report note):  -- no gate function is altered --
    PA3_genlib.vhdl:156:7:@0ms:(report note): List of the registered gates:
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#1 : :inc8_tb(plip):tb@inc8(tiles):e_r0b@inv(trace):lut2
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#2 : :inc8_tb(plip):tb@inc8(tiles):e_r1b@xor2(trace):lut4
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#3 : :inc8_tb(plip):tb@inc8(tiles):e_r2b@ax1c(trace):lut8
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#4 : :inc8_tb(plip):tb@inc8(tiles):e_r3a@and3(trace):lut8
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#5 : :inc8_tb(plip):tb@inc8(tiles):e_r3b@xor2(trace):lut4
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#6 : :inc8_tb(plip):tb@inc8(tiles):e_r4a@and2(trace):lut4
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#7 : :inc8_tb(plip):tb@inc8(tiles):e_r4b@ax1c(trace):lut8
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#8 : :inc8_tb(plip):tb@inc8(tiles):e_r5a@and3(trace):lut8
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#9 : :inc8_tb(plip):tb@inc8(tiles):e_r5b@ax1c(trace):lut8
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#10 : :inc8_tb(plip):tb@inc8(tiles):e_r6a@and3(trace):lut8
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#11 : :inc8_tb(plip):tb@inc8(tiles):e_r6b@ax1c(trace):lut8
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#12 : :inc8_tb(plip):tb@inc8(tiles):e_r7a@and3(trace):lut8
    PA3_genlib.vhdl:171:7:@0ms:(report note):  gate#13 : :inc8_tb(plip):tb@inc8(tiles):e_r7b@ax1c(trace):lut8
    PA3_genlib.vhdl:228:5:@5120ns:(report note): End of simulation ! 256 cycles.
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(1) = 128 128  |  0 0  (0)
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(2) = 64 64 64 64  |  0 0 0 0  (0)
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(3) = 32 32 32 32 32 32 32 32  |  0 0 0 0 0 0 0 0  (0)
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(4) = 32 32 32 32 32 32 32 32  |  0 0 0 0 0 0 0 0  (0)
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(5) = 112 16 112 16  |  0 0 0 0  (0)
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(6) = 64 64 64 64  |  0 0 0 0  (0)
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(7) = 56 56 56 56 8 8 8 8  |  0 0 0 0 0 0 0 0  (0)
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(8) = 32 32 32 32 32 32 32 32  |  0 0 0 0 0 0 0 0  (0)
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(9) = 84 84 28 28 12 12 4 4  |  0 0 0 0 0 0 0 0  (0)
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(10) = 48 48 48 48 16 16 16 16  |  0 0 0 0 0 0 0 0  (0)
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(11) = 98 98 14 14 14 14 2 2  |  0 0 0 0 0 0 0 0  (0)
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(12) = 105 105 7 7 15 15 1 1  |  0 0 0 0 0 0 0 0  (0)
    PA3_genlib.vhdl:242:7:@5120ns:(report note):  h(13) = 105 105 7 7 15 15 1 1  |  0 0 0 0 0 0 0 0  (0)
    

    Basically : if all the mapped gates use the trace architecture, the sub-design under test can be treated as a "black box" and the whole logic network can be re-extracted at will, modified/altered, etc.

    v2.2 is now uploaded in the files section as A3Ptiles_v2.2_20191119.tgz

    Also notice the histogram result : it gives a very interesting insight into the switching activity of certain nodes and could help with predicting (relative) power consumption in CMOS for example (or noise with relays hehehe)


    Once it's done, the rest is just some easy scripting !

    The test.sh for the INC8 unit lists all the LUTs and then scans them exhaustively, inserting one fault successively. The 13 LUTs have 86 cases to test and it's completed in a few seconds, without even trying to use multiple parallel instances.

    I have therefore proved that my INC8 is not only working, but also leaves no logic hole and will be easy to test with tailored vectors.

    Next in line will be the ALU...

  • A taste of a real design

    Yann Guidon / YGDES09/05/2019 at 14:51 0 comments

    A recent hackachat with the Parallax team provided me with some interesting "data points" :-)

    @Chip Gracey  sent me a large file containing the synthesis report of his latest creation, the Propeller 2, and I did some reverse engineering :-)

    For example I extracted the different types of gates and it's very interesting :

    adhalfx2_s  and2x1_s  and2x4_s  and4x4_s  ao21x2_s  ao22x1_s  ao22x2_s  aoi21abx1_s  aoi21abx2_s  aoi21ax1_s  aoi21ax2_s  aoi21cx05_s  aoi21cx1_s  aoi21cx2_s  aoi21x1_s  aoi21x2_s  aoi221x1_s  aoi221x2_s  aoi222x05_s  aoi222x2_s  aoi22x05_s  aoi22x1_s  aoi22x2_s  aoi31x1_s  aoi31x2_s  aoi32x05_s  bufx10_s  bufx3_s  bufx4_s  bufx6_s  bufx8_s  clkbufx10_s  clkbufx3_s  clkbufx4_s  clkbufx6_s  clkbufx8_s  clkinvx10_s  clksgpx6_s  dffprx2_s  exnor2x1_s  exnor2x2_s  exor2x2_s  invx1_s  invx2_s  invx3_s  invx4_s  majix1_s  muxi2x05_s  muxi2x1_s  muxi2x2_s  nand2ax1_s  nand2ax2_s  nand2ax3_s  nand2ax4_s  nand2x1_s  nand2x2_s  nand2x3_s  nand2x4_s  nand3drx2_s  nand3x1_s  nand3x2_s  nand4x2_s  nor2ax05_s  nor2ax2_s  nor2ax3_s  nor2ax4_s  nor2x05_s  nor2x1_s  nor2x2_s  nor2x3_s  nor2x4_s  nor3x2_s  oa211x2_s  oa21x1_s  oa21x2_s  oa222x2_s  oa31x2_s  oai211x05_s  oai211x1_s  oai211x2_s  oai21ax1_s  oai21ax2_s  oai21x1_s  oai21x2_s  oai221x1_s  oai221x2_s  oai22x05_s  oai22x1_s  oai22x2_s  oai311x2_s  oai31x2_s  oai321x2_s  or2x4_s  or3x2_s  sdffpmrqx1_s  sdffprqx05_s  sdffprqx1_s  sdffprqx2_s  sdffprx1_s  sdffprx2_s

    • The x suffix followed by a number indicates the strength of the gate, depending on the load to drive (wires and gates).
    • some gates have up to 4 inputs, which helps a lot with high fanout/fanin depth
    • the first prototype exceeded 300MHz at 180nm with 24 gates in the critical datapath :-O

  • Typo...

    Yann Guidon / YGDES08/19/2019 at 20:12 0 comments

    While reviewing and re-checking the gates versus the handbook, I finally spotted that I made a mistake with xo6 which is in fact axo6. This is fixed in the next release, along with a couple of missing gates. The latches are not included yet though.

    I try to focus on packaging, integration and testing, though the perspective of v3 is alluring and I try to clear the path towards this even better system.

  • v2.1

    Yann Guidon / YGDES08/17/2019 at 18:39 0 comments

    The v2 is already a significant breakthrough but instead of packaging/testing/integrating, I consider adding even more powerful features, in particular to provide an even better function ! I don't want to merely check if/how test vectors cover a design, now I want to generate these test vectors !

    I have the stem of the algorithm but the system requires some more "updates" and I have to solve some thorny VHDLities : so many things are possible AND impossible, it's sometimes like a maze...

    Anyway, I now add a "hidden port" to ALL the gates, to allow automatic discovery of the DUT's netlist, which is one of the required features to build the TVG algorithm.


    Update : in fact, no need of a hidden port, I might have found a more elegant solution. We'll see when v2 is operational.

  • v2 beta needs tests !

    Yann Guidon / YGDES08/13/2019 at 22:25 0 comments

    There's a new archive and it's amazing !

    A3Ptiles_v2pre20190813.tgz

    .

    Where do I start ...

    So now it has all the DFx gates (64 of them !), all the logic gates (1, 2 and 3-inputs macros) and and... oh well, POWERFUL features to probe and analyse a circuit...

    You get BOTH the "fast" (simple) gates and the "trace" versions, and you can select which gate will be logged. Either use a "VHDL configuration" or change the source code to affect an architecture to selected gates !

    The "fast" cells are just like the previous version. Fast and simple.

    The "trace" cells have the same function BUT also support multi-values signals ! The '0'/'1' levels are the basic "binary" system, but if at least one output is 'L' or 'H', then the output will adopt the 'L'/'H' levels ! And any other input value will be copied to the output and propagated to the rest of the circuit.

    All the cells (except for now the DFF) work with a lookup table and the testbench can alter one bit of one the lookup table.

    • In "alter" mode, the selected bit is flipped and the selected gate's function is changed. This is useful to verify that your BIST or test vector can catch ALL possible faults (not just stuck or broken wires).
    • In "trace" mode, the selected LUT bit is not flipped but changed from '0'/'1' binary level to 'L'/'H' meta level, to observe the effect of this given LUT entry over the output(s).

    A few features are still missing, for example we can't change the LUT when the simulation is started... DFFs are not alterable yet, either, but it's not critical.

    Many tools, tests and examples shoud be written but this release is really a game-changer !!! Download it and try it !

  • v2 with sequential gates

    Yann Guidon / YGDES08/10/2019 at 21:50 0 comments

    I added the code to generate all the 15 DFN1* gates.

    A3Ptiles_v2pre20190810.tgz

    lt needs some more polishing and some gates are still missing but it's just a few days of work...

    I'm already wondering how I will implement the alteration of the DFFs.

  • early success with v2

    Yann Guidon / YGDES08/10/2019 at 14:51 0 comments

    The system starts to work !

    With the most fundamental problems "mostly solved", I can see my new code working in a promising manner.

    Here is the new README.txt :

    file README.txt
    created sam. août 10 16:03:22 CEST 2019
    
    WHAT :
    
    The new version of the PA3 gates library is more compact
    and provides much more insight into the logic's dynamic behaviour.
    Configuration relies a lot on the runtime generics option of the
    recent GHDL simulator, with the -g command line parameter.
    
    WHY :
    
    This tool enhances the classic ProASIC3 gates library
    for design verification and "Design For Test".
    It helps build test vectors and prove they can catch all the possible faults.
    It also helps ensure that a complex boolean function has
    no "blind spot" with unused intermediary combinations.
    
    A non-boolean value can be injected and propagated through
    the logic gates, to highlight the "logic cone" of the circuit,
    which can greatly help during debug/development.
    
    HOW :
    
    The provided script runme.sh generates the big files with all
    the definitions, then runs a couple of tests (three XOR2 chained)
    as a self-test as well as demonstration of the use of the
    new extra features of this library.
    
    * VHDL source code only needs to include :
    
    Library proasic3;
        use proasic3.all;
    
    (just like before)
    
    * The top level simulation file must include these 2 generics :
    
      generic (
        gate_select_number: integer := 0;
        bit_select_number: integer := -1
      );
    
    The default values do nothing, but when they are changed,
    the selected gate is affected/altered.
    These values can be changed post-elaboration by GHDL's command line.
    
    * A clock signal is required for sampling the gates' states
    (avoiding false results due to transients)
    
      signal clock : std_logic := '0';
    
    * The clock and the generics are fed into an entity
    that does some of the dirty work behind the scene:
    
      rg: entity register_generics port map(
           gate_select_number => gate_select_number,
           bit_select_number => bit_select_number,
           clock => clock);
    
    When "clock" changes to value '1' then the values of all the detected gates
    are sampled and the histogram is updated.
    The histogram is shown when  "clock" changes to value 'X'.
    
    
    TODO :
      - "fast" option without instrumentation
      - sequential gates
      - tiny gates (1 and 0 input)
      - restrict the gates that will be sampled or altered.
      - sed scripts to filter the outputs
    NOFIX :
      - coarse timing (everybody has 1ns latency)
      - 2^31 simulation cycles maximum
    

    The archive is going live soon...

  • v2 in progress

    Yann Guidon / YGDES08/09/2019 at 20:39 0 comments

    It was not easy but i have a first proof of concept for the code !

    https://cdn.hackaday.io/files/1625946956421696/A3Ptiles_v2pre20190809.tgz

    It is far from being the most elegant or efficient but it works. A 2-stages compilation system creates the whole collection of gates and their definitions, the result is provided in the archive in case you can't run the generation script.

    It covers the alteration of a given bit of the lookup table of a given gate. The access works with a number system: the program lists all the alterable gates and provides their path along with an index, that is reused to address the gate. It should be pretty easy to use in a script.

    The delay system should also be redesigned. Probably with real data from the datasheets, though this is pointless without information about the routing delays...

    The sequential gates are missing too, and the smaller gates are still absent...

  • Lookup tables !

    Yann Guidon / YGDES08/08/2019 at 08:55 0 comments

    I finally took the time to write the first code ! And I get the following LUT8s :

     and3 :    10000000
     and3a :   00001000
     and3b :   00000010
     and3c :   00000001
     ao1 :     11101010
     ao12 :    01101101
     ao13 :    11010100
     ao14 :    11010110
     ao15 :    00101001
     ao16 :    01000010
     ao17 :    10000110
     ao18 :    01001101
     ao1a :    10101110
     ao1b :    11010101
     ao1c :    01011101
     ao1d :    10101011
     ao1e :    01010111
     aoi1 :    00010101
     aoi1a :   01010001
     aoi1b :   00101010
     aoi1c :   01010100
     aoi1d :   10101000
     aoi5 :    11100111
     ax1 :     10100110
     ax1a :    01011001
     ax1b :    10101001
     ax1c :    01101010
     ax1d :    01010110
     ax1e :    10010101
     axo1 :    11100110
     axo2 :    01101110
     axo3 :    01110110
     axo5 :    10011101
     xo6 :     10111001
     axo7 :    01100111
     axoi1 :   00011001
     axoi2 :   10010001
     axoi3 :   10001001
     axoi4 :   00100110
     axoi5 :   01100010
     axoi7 :   10011000
     maj3 :    11101000
     nand3 :   01111111
     nand3a :  11110111
     nand3b :  11111101
     nor3 :    00000001
     nor3a :   00010000
     nor3b :   01000000
     nor3c :   10000000
     oa1 :     10101000
     oa1a :    10001010
     oa1b :    01010100
     oa1c :    01000101
     oai1 :    01010111
     or3 :     11111110
     or3a :    11101111
     or3b :    10111111
     or3c :    01111111
     xa1 :     00101000
     xa1a :    10000010
     xa1b :    00010100
     xa1c :    01000001
     xo1 :     10111110
     xo1a :    11101011
     xor3 :    10010110
     xnor3 :   01101001
     zor3 :    10000001
     zor3i :   01111110
    

    The necessary source code is not as difficult as I imagined, though it requires some method. There are some obvious duplicates but it's a different problem.

    All the code must be re-tested after this rewrite because I have caught a few inconsistencies...

View all 19 project logs

  • 1
    Get and install GHDL

    get it there : https://github.com/ghdl/ghdl/releases

    also read http://ghdl.free.fr/

    Be sure to not use the MCODE version... The GCC and LLVM backends seem to work well.

  • 2
    Test

    under Linux :

    wget https://cdn.hackaday.io/files/1625946956421696/A3Ptiles.20190412.tgz
    tar xzvf A3Ptiles.20190412.tgz
    cd A3P/
    ./runme.sh
  • 3
    Use in your project

    Use the INC8 example to setup your scripts and include the proper paths to the files.

View all 3 instructions

Enjoy this project?

Share

Discussions

Yann Guidon / YGDES wrote 08/08/2019 at 10:36 point

Damnit I found a wrong declaration for NAND2, with 3 inputs in PA3_components.vhdl :-/

  Are you sure? yes | no

Yann Guidon / YGDES wrote 12/02/2018 at 19:24 point

@SHAOS 

so far, I need the following gates for INC8 :

 INV  XOR2  AX1 AND3  AND2

I haven't looked yet at your library of CMOS cells at #Shared Silicon ...

  Are you sure? yes | no

SHAOS wrote 12/02/2018 at 23:54 point

What is "AX1"? My INV, AND2 and AND3 were "silicon proven"

I have XOR2 and NXOR2 too, but I didn't test them in silicon yet

  Are you sure? yes | no

Yann Guidon / YGDES wrote 12/03/2018 at 04:31 point

From the files :

architecture rtl of AX1 is
begin
  Y <= (A and B) xor C after gate_delay;
end rtl;

so it's a XOR2 with one input being the result of AND2. The absence of output buffer of AND2 makes the combined gate faster.

  Are you sure? yes | no

SHAOS wrote 12/03/2018 at 04:34 point

so I guess it could be built out of AND2 and XOR2 then :)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 12/03/2018 at 05:11 point

It could but it would use more surface and be slower.

That's why it's interesting to design and analyse the logic with A3P : if you limit yourself to basic gates, you miss some useful optimisations.

This library of cells helps me design tighter circuits and when they are stable and optimised, I can then focus on the CMOS library to implement the required functions (if they are not available yet).

And your role becomes clear at this point ;-)

  Are you sure? yes | no

SHAOS wrote 12/03/2018 at 06:32 point

I don't think custom implementation of AND-XOR will be much smaller or faster of a simple combination of AND and XOR, may be just a little bit... 

  Are you sure? yes | no

Yann Guidon / YGDES wrote 12/03/2018 at 12:03 point

This little bit could make a significant difference :-)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 12/03/2018 at 12:31 point

the merging saves the space of the intermediate buffer, as well as the interconnect between AND2 and XOR2.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates