VHDL library for gate-level verification

Collection of ASIC cells and ProASIC3 "tiles" in VHDL 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. It works for 4-input LUTs even though it started with Actel/Microsemi/Microchip's official definitions (LUT-3 gates). I don't address exact delays for very accurate simulation because they are proprietary and I don't need such a precision at the early stages of prototyping.

This library replaces the proprietary files during simulation of synthesised results, so I can make truly Free and Open Source designs, which can later be ported to ASIC technology. This is still a work in progress but the latest feature provide useful alternatives to the proprietary tools: I added custom extensions to provide incredibly useful verification features such as logical cone checks, BIST coverage checks, and I currently work on BIST vector generation.

Apart from shell scrips, all the code is portable VHDL'93 and uses GHDL (not mcode

This project is shelved and superseded by #Libre Gates 

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 ?

  • Simulate your mapped design (the initial purpose). The "simple" implementation ( >= v2.8 ) works anywhere, it's fast but without any fancy feature.
  • 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)
  • Inject unusual signals at inputs to observe the logical cone
  • Alter the function of a given gate (simulate a hardware fault)
  • Compare which alternative architecture toggles the least nets, investigate toggle-reduction strategies to reduce switching-induced power consumption.
  • Implement arbitrary logic with the generic gates (arbitrary LUT16 is supported since 20191213, so the library is not restricted to ProASIC3 designs)

What's intended ? (not yet implemented)

  • BIST verification (brute-force through all the gates is possible thanks to parallelism)
  • Automatic Test Vector Generation
  • Import/Export EDIF ? CircuitJS ?

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:

1 input:

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

Read more »


The last known good v2.9, fixes, updates, and the first RS latches.

x-compressed-tar - 196.28 kB - 08/28/2020 at 23:52



Fixed the latches, minor fix, major effect !

x-compressed-tar - 315.66 kB - 07/27/2020 at 05:53



defined some standard 4-inputs gates, updated INC8, added Gray6, fixed a big bug with DFF

x-compressed-tar - 194.01 kB - 07/18/2020 at 04:51



Version 2.8 can generate the "simple" definitions.

x-compressed-tar - 163.07 kB - 03/24/2020 at 17:22



v2.8 Library "simple" implementation with direct definition and NO external dependency or analysis capability, for compatibility. No delay

x-vhdl - 76.33 kB - 03/24/2020 at 17:18


View all 36 files

  • A new scope

    Yann Guidon / YGDES09/01/2020 at 03:15 0 comments

    This project will soon go in "shelved mode".

    Its scope has grown, extended and now goes beyond the PA3 family : I'd like to add the sxlib or the wsclib, among others, and even those included in the Google-funded Skywater PDK (who knows if I can one day get it).

    The PA3-specific code is in fact quite localised and I have found a name for the project : LibreGates ! Look, I even got the domain name that redirects the proper page.

    Having a distinct and evocative name helps a lot on many aspects. I struggled to identify or even talk about this project, as you can guess from this project's evasive name. I can now separate the PA3-related code from the gates architecture and the analysis framework, which is now available for any other gates family.

    The transition will take a while and the last v2.9 is quite a nice package, but the directories and scripts will be quite different for the new system, far beyond what I considered for v2.10 !

    Of course, #Libre Gates will keep the compatibility with the standard proasic3 library. Directory paths are different though but it's not a crazy deal.

  • An even faster and easier algorithm to map the netlist

    Yann Guidon / YGDES08/31/2020 at 03:22 0 comments

    It only occurs to me now that the algorithm I use in v2.9 can be way faster and efficient. The trick is to serialise the number of the output port on the respective net and each sink de-serialises it in parallel. The number of runs is then proportional on the log2 of the number of gates, and this can be even further reduced because std_logic has 9 states, and can encode 3 bits per cycle. The 9th state ('U') is then used to force the update of the signals.

    A circuit with 4 inputs and 4 gates is mapped in 1 cycle, 2 cycles can test 64 signals, 3 cycles 512 signals... It's a crazy speedup !

    The funniest side is that i came up with this algorithm almost 20 years ago now. I wonder why I didn't consider it until now...

    A new twist can be added with the inclusion of some "signal integrity check". A linear function extends the range of the numbers to transmit, and adds a majority of numbers that are not valid. This should catch cases with driver conflicts because the library uses std_logic_vector and not std_ulogic_vector. If we consider that one more probe cycle is not a significant cost, then we can extend the coding space by a factor of 8. The linear function 5x+3 should work well enough. The function has another offset because the input number ("gate number") can be negative (for a port).

  • Internal Representation in v2.9

    Yann Guidon / YGDES08/31/2020 at 00:45 0 comments

    The development cycle for v2.10 starts and it's a good time to discuss how v2.9 works, in particular for the internal data structures. They are well suited for what they do in v2.9 but, knowing what I know now, it is obvious I should have left more margin in the code. Going back to v2.9 is also a way to evaluate what I could change without breaking what (fragile) code exists and works until now.

    Note : I will explicitly cover the mechanics behind the "probe" mode only. The "fast" mode and the "simple" version are not at stake here. What I want is a better framework to analyse a netlist with not just ports and boolean logic, but also latches and RS FF.


    The very first mechanism is the census of the gates. Each instance gets its own unique number during elaboration, thanks toa little trick with the generics system. Here is the example of the generic 2-inputs gate :

    Library ieee;
        use ieee.std_logic_1164.all;
    Library work;
        use work.all;
        use work.PA3_genlib.all;

    entity generic_gate2 is
      generic( Gate_Number : integer := Gate_Census;
               exclude: std_logic_vector := "");
      port( A, B : in std_logic;
            LUT : in std_logic_vector;
            Y : out std_logic);
    end generic_gate2;

    architecture trace of generic_gate2 is
      signal LUT4 : LookupType4;
      LUT4 <= Inferlut(LUT, LUT4'instance_name, Gate_Number, 3, exclude);
      Y <= Lookitup2(A, B, LUT4, Gate_Number) after ns;
    end trace;

    The Generic's value is given by the Gate_Census procedure, which is pretty basic :

    -- just count the number of registered gates
    impure function Gate_Census return integer is
        gate_instance_counter := gate_instance_counter + 1;
        return gate_instance_counter;
    end Gate_Census;

    So yes it's just a counter, so far. But it is called for each and every analysed gate, and updates the shared variable gate_instance_counter every time. After elaboration, not only does each gate has a unique number (very useful for later) but the analyser knows how many gates to check. This is used at the end of the elaboration to allocate room for all of them, in an array called GateList.

    List of gates

    After elaboration, the VHDL simulator initialises the signals. In the example gate above, the first line is executed first (for each instance of the component):
    LUT4 <= InferLUT(LUT, LUT4'instance_name, Gate_Number, 3, exclude);
    That's quite tricky and it tries to do a lot at once because there is so much to initialise...

    • First, it has to write to a signal because otherwise, the execution of the InferLUT function would not happen at the right time (before the others). But since all the parameters shouldn't change (yes, right) this initialisation function is called just once.
    • The first argument is the desired contents of the LUT, which can be given directly as a literal value (as in PA3_definitions.vhdl), as a generic or a port (as in the example, though this is not very "clean" because it creates the risk of re-running the initialisation routine)
    • The next argument is the text string that identifies the gate, for human consumption and pretty-reporting.
    • The Gate_Number is given so the function knows where to put the gate's definition.
    • 3 is the last valid index in the LUT (it's the size)
    • exclude is a generic that eventually flags which input combinations not to care about.

    So after the delta cycles of t=0 are over, GateList contains the list of all the gates. There is no real order, it's mostly defined by the inclusion order and this is in theory something that you shoudn't rely on (though GHDL does a great job of preserving the writing order).

    Note that all the gates are included and counted but not all should be analysed : gates with 0 or 1 input are "degenerate" because a fault on them is equivalent to a fault on the input of the larger tested gates. The list of gate number...

    Read more »

  • Time travel and zombies

    Yann Guidon / YGDES08/24/2020 at 18:43 1 comment

    No it's not another Doctor Who fanfic ;-)

    The logic depth analysis detects logic loops in digital netlists and this is a good safety net because otherwise, it couldn't tell the depth anyway. This is explained in the log Zombies in v2.6 with the classic examples of a dual-NOR2 flip-flop and a MUX-based latch (among others) :

    The analyser can detect the incoherent logical depth but can't tell if a logical loop is either a latch or an oscillator (or both ?) so it's safest to just exit with an error.

    But this is not enough : not all digital circuits are pure boolean networks and loops happen in a way or another. As described in the log 127. A tale of Flip-Flops, I also need to handle DFF, RS FF and transparent latches. I also describe a model for dealing with them all.

    DFFs are quite easy to model : just consider its inputs and outputs as ports, because the effect is not on the current clock cycle.

    But I also need Set/Reset flip-flops and I have defined a table of "macros" (which will then be substituted with the real gates) as well as a strategy to allow the analysis.

    Mapped to
    Set10S1R0AO1, AON21
    Set11S1R1AO1B, DLI1P1C1, AON21B
    Reset10R0S1OA1, OAN21
    Reset11R1S1OA1B, DLN1P1C1, OAN21B

    Let's add to this a new "virtual component" : backwards is a "time machine" that sends the value of one net to another identical net but with a different logic depth. The "simple" definition is just a wire that will be simulated as such, but the analysis version breaks the temporal causality that defines the loop (while also preserving the fanout so this is not a buffer).

    I had to invent a symbol so I chose a B with a leftwards arrow... Here is the "weird circuit" with the appropriate new symbol :

    This new component is a first little step toward a more extensive redesign that will allow the other types of sequential gates to be analysed, such as this circuit (from an old IBM european patent EP0092663A2 from 1983).

    (there would be 2 "backwards" meta-components)

    I have added the two files SRFF_simple.vhdl and SRFF_PA3.vhdl to the A3P library. It shouldn't belong there, strictly, but I have no other place for it (yet).


  • Abnormal initialisation time and workaround

    Yann Guidon / YGDES08/16/2020 at 17:47 0 comments

    In the log 124. TAP timing & simulation I encountered a strange situation : the simulation would appear to take much longer than expected. This occurs after elaboration and during the first wait of the driving process.

    This did not appear before because I think 2 factors played together for the first time :

    • The design has grown and reaches about 100 gates, the largest I've tried so far. But this shouldn't be an issue by itself because the MUX64 is quite fast to sim.
    • This if the first time I use a discrete flip-flop (a pair of NOR2) which could create undefined behaviours at start-up. But this shouldn't be a problem because the situation is already handled, right ?

    Unfortunately I'm not able to trace what happens exactly but here are some tips :

    • Make sure this is not an elaboration issue. A simple report lets you trace when and where the delay occurs. And normally, the total runtime should be directly proportional to the workload so change the iteration count for example.
    • Check all the parameters of the initial values of the signals, either during declaration and in the testbench.
    • Avoid undefined states and logical loops, and shield/split the units from them (gating/enabling data helps)
    • Use different versions of the source code : change the architecture, try with a behavioural implementation, or the "simple" gates library.

    In practice, the last tip can be a good compromise : it's not as fast as a behavioural model but less heavy than the "full trace" that is the default option.

    However the "full trace" and "simple" libraries don't cohabit well but the design flow could require them both, depending on the level of analysis to perform. I have chosen to add a "simple" sub-directory in the latest version, where the homonymous version is built separately from the "full trace" version. Scripts using GHDL can then select which version is used on a case-by-case basis, depending on the requirements, by selecting the right path.

    For the #YGREC8 this saves some seconds and uses more room but this is necessary because the tracing version can't analyse properly the sequential gates for now.

  • Flip Flops (should) work...

    Yann Guidon / YGDES07/18/2020 at 05:01 0 comments

    I just added a test of a few DFF ( DFN1E1C0 , DFN1C0 ) in the form of a Gray code counter. This uncovered a biiig bug in my code and libraries, that are now easily solved. Burn all previous versions !

    I also rearranged the order of the sanity tests / examples so the shortest come first.

    This new release is already 198668 bytes when compressed...

    I am now considering how I could integrate the FF in the verification system, they use a LUT2 so far so they are excluded from the algorithm...

  • v2.9 : introducing 4-input gates

    Yann Guidon / YGDES07/14/2020 at 20:11 0 comments

    These newcomers are not part of the ProASIC3 family but are welcome extensions to the gates library, as discussed in 107. Choosing the gates. Say hello to OAI22, AOI22, OAI211 and AOI211 !

    Oh and after I added them, I find this interesting study about them :

    so I must not be completely wrong here.

  • A simple option

    Yann Guidon / YGDES03/24/2020 at 17:29 0 comments

    I think I skipped v2.7 that was on the drawing board (I still need to make more examples), but v2.8 is here !


    It adds (or restores) a feature/behaviour that was considered in the beginning, then abandoned, then lately I thought it would be cool

    1. to be able to simulate the designs at a slightly faster speed (though it's subjective)
    2. to be able to synthesise the designs on different platforms that don't understand/know Actel's legacy conventions.

    The last point convinced me so here it is : PA3_definitions_simple_nodelay.vhdl

    I copy-pasted the code that generates the LUTs. I had to modify the code of the MX2x gates and this also introduces a timing inconsistency but it's minor and not used (since it's apparent only when timing is used AND I'm NANDifying my code).

    This version doesn't use external definitions that are necessary for analysis and introspection. It's purely so the Actelified source code can work on Lattice/Xilinx/Intel/etc.

    The default version remains the "trace" one, and it can be regenerated at will, with the timing you want, since I have provided 2 scripts and the generator can be rerun as you like.

    Update 2020028 : both versions are built now by a single script so they can be used in parallel, selected by the -P (include path) parameter of GHDL.

  • v2.6 release

    Yann Guidon / YGDES12/29/2019 at 20:24 0 comments

    It's the last update of this project for 2019 !


    I have reorganised the files and directories a bit... More needs to be done but it's satisfying so far and I need to go back to work on the ALU8 unit. It was a good opportunity to test that the library integrates well with other projects so now I'm back to the #YGREC8project for a bit.

    See you in the next decade !

  • Zombies in v2.6

    Yann Guidon / YGDES12/28/2019 at 02:42 0 comments

    Update: some "zombies" have an explicit solution, explained in

    I'm still trying to figure out a good method to solve the final problem of vector generation.

    Meanwhile I'm also making v2.6 more solid with a better detection of netlist warts, such as unconnected sinks and sources. I label those faulty gates or ports : "zombies". I don't make much efforts to "clean up" the netlist, instead I'll bail out if the netlist contains zombies. There is no point in trying because the vectors make sense only on a final design, however I try to make the output less cryptic and more useful when the tool is used as a simple netlist checker during design and for regression tests.

    Also : the netlist will not "see" GND and VCC gates because they have no input. They don't make sense anyway, though A3P netlist often contain these... I consider these as "NOFIX".

    A3Ptiles_v2.6_20191228.tgz has all the good stuff.

    More info can be found in the test4_cornercases directory. The weird_unit.vhdl file implements the following circuits:

    ff1 and ff2 implement a well-known set/reset flip-flop circuit and the outputs are "sequential" because they depend on the previous state, so they are "zombies". Both NAND2 are correctly flagged.

    The mx0 implements a transparent latch. mx0 is correctly flagged, as well as the next gate that depends on the output.

    Out(4) is left unconnected.

    open1 and open2 are two chained gates with the final output dangling open. This is where things get a bit complex because open2 is correctly flagged as a zombie but not open1. Removing both would affect other parts of the system, such as reducing the depth of the design, which would create an avalanche of other effects...

    open3 is correctly flagged as a zombie because both inputs are unconnected.

    The end of the report says this:

       Latency of the 5 outputs :
          Output#0 : N/A
          Output#1 : N/A
          Output#2 : N/A
          Output#3 : N/A
          Output#4 : N/A
      Found 6 zombie gates or inputs (unconnected or loops) :
     - Gate #6 : fanout= N/A - :vectgen(plip):wrap@vg_wrapper(weird):open2@and2(trace):lut4
     - Gate #1 : fanout=2 - :vectgen(plip):wrap@vg_wrapper(weird):ff1@nand2(trace):lut4
     - Gate #2 : fanout=2 - :vectgen(plip):wrap@vg_wrapper(weird):ff2@nand2(trace):lut4
     - Gate #3 : fanout=2 - :vectgen(plip):wrap@vg_wrapper(weird):mx0@mx2(trace):lut8
     - Gate #4 : fanout=1 - :vectgen(plip):wrap@vg_wrapper(weird):dummy@and2(trace):lut4
     - Gate #7 : fanout= N/A - :vectgen(plip):wrap@vg_wrapper(weird):open3@and2(trace):lut4

    I chose to flag the errors rather than correct them (by pruning), for these reasons :

    • The correction/remedy could make the situation worse if there is a misunderstanding or a bug
    • It is not the purpose of the system : I just want to make sure the vectors are generated with a sane dataset.
    • It was not planned in advance and this "late feature" is harder to add (it was not straight-forward to implement anyway)
    • Feature creep is bad and I want to KISS.

    So I hope people can use this tool as a filter, I try to present useful information, so the user can correct their design.

View all 38 project logs

  • 1
    Get and install GHDL

    get it there :

    also read

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

  • 2

    under Linux :

    tar xzvf A3Ptiles_v2.6_20191229.tgz
    cd A3Pv2.6

    This will run scripts for a minute or so, compiling everything and testing the results for consistency.

  • 3
    Use in your project

    Copy (or symlink) the directory proasic3v2 in your project.

    Use the tests/examples to setup your scripts and include the proper paths to the files.

View all 3 instructions

Enjoy this project?



Yann Guidon / YGDES wrote 07/27/2020 at 06:05 point

Another important fix (makes the latches work as intended) : update to YGREC8_VHDL.20200727.tgz !

  Are you sure? yes | no

Yann Guidon / YGDES wrote 07/17/2020 at 03:16 point

TODO for v2.10 : consider DFFs as inputs and outputs...

  Are you sure? yes | no

Tim wrote 07/12/2020 at 19:58 point

Looks exciting! Still very incomplete as of now, not even spice models of their nmos/pmos.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 07/12/2020 at 21:54 point

yes but it's due soon !

  Are you sure? yes | no

Tim wrote 07/12/2020 at 22:37 point

I hope this will also help improve all the OSS VLSI-Design toolchains. Magic is old.

The discussion about "130 nm is an ancient technology why not something more recent" are quite funny. Almost all of this "maker stuff" revolves around designs in 130 nm (afaik STM32F103) or much larger (AVR), not to speak of all the sensors, PMICs and LED-drivers in 350 nm or 180 nm.

I would be perfectly happy with reliable and low cost access to 350nm. Still not too sure about the conditions surrounding the skywater offer.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 07/12/2020 at 23:59 point

I agree about 130nm : it's a great node for "us". decent Vcore, good I/O voltages, fast, dense, and this fab supports Flash cells.
I'm discussing with the  @Tim Ansell about the conditions, it's very welcoming !

  Are you sure? yes | no

Tim Ansell wrote 07/13/2020 at 00:18 point

The exact conditions are still being decided but the generally idea is "free as in beer" for "free as in freedom".

You can have a look over Google's documentation about licenses for open source projects at for some idea of what is going to be suitable.

If you don't have a strong preference, just use Google's default license choice of Apache 2.0 -- From

> The Apache license is our preferred license not only for source code  but also for hardware."

Stay well away from the licenses listed under

  Are you sure? yes | no

Tim wrote 07/13/2020 at 06:42 point

Cool! Having no restriction on the PDK and derived products would already be a huge anomaly/change.

I was also wondering about the criteria to be able to use their manufacturing service. They mentioned it would be free for eligible designs (?). I guess there ha ve to be some limits.

Looking at current MPW costs at 130 nm, this is still off by one or two orders of magnitude for a noncommercial project without external funding. So they must do something to really bring cost down or put up a high barrier.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 07/13/2020 at 09:01 point

Hi @Tim Ansell  :-)
Thanks for the explanations and details !

I looked at the links about the licences and find that AGPL is considered "toxic" to your employer, though it makes perfect sense in the current situation, because we're not building a webservice for example. We all agree that the purpose is to totally open as many levels of the design pipeline as possible and AGPL unambiguously goes in that direction. We all want to have the full "source code" of the chips we have/own to ensure safety and security.

This gates library as well as most of my "FOSS" projects are under AGPL.

  Are you sure? yes | no

Tim wrote 07/13/2020 at 10:41 point

Oh, I did not realise Tim Ansell was directly involved.

  Are you sure? yes | no

Tim Ansell wrote 07/13/2020 at 16:39 point

@Yann Guidon / YGDES - I'm not a lawyer and so won't argue about reasons around the licenses.

The lawyers have said we can *not* accept AGPL files. Projects under AGPL won't be eligible for inclusion in the shuttle run.

  Are you sure? yes | no

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


so far, I need the following gates for INC8 :


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