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


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)
  • 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 (since 20191124, so the library is not restricted to ProASIC3 designs anymore)

What's intended ? (not yet implemented)

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

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

Read more »

A3Ptiles_v2.5_20191205.tgz

small but not insignificant tweak, the last/definitive release of v2.5

x-compressed-tar - 185.14 kB - 12/06/2019 at 00:15

Download

A3Ptiles_v2.5_20191203.tgz

v2.5 ! 10x faster for failure test, packages are reorganised, external files can contain the excluded states... it's a great release !

x-compressed-tar - 184.96 kB - 12/03/2019 at 06:45

Download

read_xcl.tgz

The prototype of the code that reads the exclude files

x-compressed-tar - 1.67 kB - 12/01/2019 at 19:05

Download

A3Ptiles_v2.4_20191201.tgz

Added long integers for histograms/counters, and also counts the total number of cycles to check all the failures (figure of merit for the future BIST)

x-compressed-tar - 177.05 kB - 12/01/2019 at 15:16

Download

A3Ptiles_v2.3_20191127.tgz

added : Toggle counter, "exclude" generic parameter

x-compressed-tar - 176.71 kB - 11/27/2019 at 04:44

Download

View all 20 files

  • Winner scanner

    Yann Guidon / YGDES4 days ago 6 comments

    The above picture shows the scanning pattern of the enhanced testbench for INC8. Not that it makes a big difference, since the scan is quite fast (1s on my i7) but for the ALU8, which lasts a few minutes at this moment, the 54% time saved will mean quite a lot...

    It works well for the INC8 and the ALU because they rely on carry propagation (of some sort). The algorithm uses a dual loop (outer forward, inner backwards) that "hits" the powers of 2 sooner than a simple linear scan : the index 128 will be reached after 64 iterations, for example. Many "failure modes" appear on powers of two, or the index before (like : 127 and 128) so reaching them faster is good. This results in the "inverse sawtooth" pattern of the above picture.

    This is boosted by another trick called "folding" that tests an index and its opposite. This creates the "horizontal mirror" of the picture. The resulting algorithm is a bit subtle but efficient and small: 

    -- 1743 cycles vs 3995 in linear mode !
    procedure reverse_folding is
      variable j : integer := 1;  -- the current power of 2
      variable k : integer := 0;  -- the inferior limit for the reverse scan
      variable l : integer := 0;  -- the sub-loop counter for reverse scan
    begin
      loop
        l := j;
        loop
          if (l < 128) then -- 128 appears 2x
            test_cycle(    l);
            test_cycle(255-l);
          end if;
          l := l-1;
          exit when l < k;
        end loop;
        k := j+1;
        j := j+j;
        exit when j > 128;
      end loop;
    end reverse_folding;

    We'll see soon enough if this cuts the run time of the ALU8 tests !


    Well, guess what ?

    For the thorough testing of the ALU8,

    • 13.248.331 simulation cycles in 383s to check all the faults with linear scanning
    • 1.121.723 cycles in 36s with reverse-folding !

    so it's roughly a 10x increase in processing efficiency !

    Upload: soon


    20191205 :

    down to 34s and only 931.316 cycles with this dumb simple tweak : I swapped the SRI and SND ports !

    I don't know how but I'll have to try some bit shufflings. However the search space is out of range : 16! = 20.922.789.888.000...

  • v2.4

    Yann Guidon / YGDES5 days ago 0 comments

    I just uploaded A3Ptiles_v2.4_20191201.tgz and though it's a pretty modest update compared to the last archive (I added larger integers for the histograms and activity counters, plus a few features) the cumulative changes deserve a minor number increment ! So it's v2.4 already, and more features are brewing already : I am coding some files to import exclusion vectors from external files.

    Stay tuned.


    ... and in read_xcl.tgz I prototyped the code that reads the "exclusion files".

    I could read the whole file into memory but I don't want to use more memory than required, particularly during initialisation. So I scan the file along with the list of gates. It's not the most direct/simple method but it is light on real resources and scalable if the DUT grows.

    I'm about to include the mechanism inside the general system.

  • New feature : toggle counter

    Yann Guidon / YGDES11/27/2019 at 03:52 0 comments

    Here's a fun and easy one :

    The newest feature simply counts how many times each gate's output changes value.

    It might sound a bit silly for now but it was quick to implement and it will be very useful later when selecting the most appropriate implementation for the decoding logic. Some versions are "as fast as possible" and don't care about anything but giving the right result with the least logic depth as possible. Of course it generates a lot of logic activity and many spurious changes for nothing.

    Other versions use a slower but more careful logic with latches to minimise the number of control lines to change. This reduces noises and power consumption with CMOS and FPGAs.

    For now, there is no application but this will greatly help the design of the #YGREC8

    Of course I'll have to find a way to use 64 bits numbers with GHDL because I suppose that the current limit of 2³¹ cycles and toggles will be easy to exceed.

    Whatever...

    Stay tuned and watch for the latest upload in the files sections :-)

  • An unexpected turn with the histogram

    Yann Guidon / YGDES11/24/2019 at 23:27 0 comments

    I just uploaded A3Ptiles_v2.3_20191124.tgz but this is only an interim version.

    The good part : I added a more complex circuit to test, the ALU8 has 83 gates, it is more rich and interesting than the INC8 unit (only 13 gates).

    The bad part : I encounter cases that I didn't expect. By design, some gate configurations do not exist in the ALU8 and this creates a new situation. I need a way to explicitly tell the simulator that these cases don't occur, or modify the design to take these cases into account.

    With this new situation, the system I created for INC8 (with a simple bash script) will not work at all because some cases will not be testable...

    Anyway, the tool already proves its worth, because I focus on logic flaws I didn't see coming. The histogram is not just a gadget :-)


    20191126 :

    I tried one method to reduce the problem : I substitute the offending gates with a composite gate.

    Most of the problems appear with AO1 : so I replaced them all (in the ALU8) with :

    -- AO1 => Y := (A and B) or C;
    architecture combi of ao1_combi is
      signal t : std_logic;
    begin
     e_a: entity AND2 port map(A=>A, B=>B, Y=>t);
     e_o: entity OR2  port map(A=>C, B=>t, Y=>Y);
    end combi;

    It seems to solve most of the problems and the exhaustive fault injector can deal with fewer problems.

    However some problems will always remains, "by design", the best example is with testbenches that only test a subset of the signals and decode into mutually-exclusive signals.

    So I must add a mechanism to instruct the gate that some states are illegal...


    What is the best way to transmit the information about the gates ?

    • The easiest method is with a port. A std_logic_vector or string is an "optional" port, which can be left "open".
    • A generic is another easy way to inject additional information with "default" value when not used.

    Both of these methods create one problem : backwards compatibility is not preserved and they require the use of "if generate"s constructs to let the netlist source code run with the original simulator... But is it a real problem ?

    Another method would be to use an external file with a list of gates-inputs to ignore. It's much more complicated though but opens the way to automatically generate the list from the histogram.

    It seems that both methods are complementary so I'll have to implement them both...


    I have chosen the generics mechanism to provide an inline "exclusion list", with an unbounded std_logic_vector as parameter. Every 'X' becomes an entry to exclude. The list can be empty, of course. In the first simple test, here is one example:

    x5: entity xor3  generic map(exclude=> "X-X-X-X-")
                  port map(A => D, B=>G, C=>H, Y=>Y );

    Backwards compatibility is broken but it could be solved with a "if-generate" if ever needed.

    Now I work on making sure everything works well like before.

  • Modes of operation

    Yann Guidon / YGDES11/22/2019 at 15:45 0 comments

    Suppose, for the sake of argument, that you want to create a digital silicon chip, for example. The exciting ASIC world is calling your name so your RTL code is tested, formally verified, simulated, cosimulated, and finally synthesised.

    At that point, you would want to ensure the synthesiser did not poo-poo your neat system so you can re-simulate the mapped netlist, using the fast mode of this library. Or you can simply write and pre-map some modules in this low-level dialect, as I do.

    Fast mode

    In this mode, each logic gate is replaced by a lookup table of the appropriate size.

    Fast mode doesn't care much about meta-values, "if it's not 1, it's 0" to speed things up. Be ready to break your code, and in the process, uncover potential troubles with badly initialised registers (for example, and if your synthesiser didn't warn you enough before).

    Now your code works in after-synthesis. But it's only the beginning of the end of the road because going from the virtual world to the real world implies a crazy shift in methods and focus, and I'm not even talking about place/route/retiming and other niceties... Because here, we're out of the comfortable walled garden of FPGAworld, where they sell you "Known Good Dice" that will behave exactly according to the specifications of the datasheet. No, the factory will deliver dice, some of them might even work !

    How would you know which are good ? Run a program, for example, and see if it returns the expected good value : that's a valid idea but it can work only if the die is totally connected to the outside world... and this is costly, particularly if the die is DOA ! The usual solution is to connect only a few pins to a test rig, power up, inject signals and check the results. If the circuit looks like it's not dead and passes enough tests, it can then be packaged for further thorough tests.

    Trace mode

    One of the approaches for testing the chip with only a few pins is to make it run some sort of internally-generated sequence or even program that will exercise all (or most) units in the chip. It's called "BIST" for Built-In Self-Test and it must be designed along with the chip itself (remember the "Design For Test" DFT methodology they bore you with ?) so you're not caught with untestable units at the last moment.

    So the chip must be designed in advance to allow self-testing, which means you must synthesise often and run/simulate the BIST to ensure that ALL the gates are covered. This scenario is covered by the second mode of the library: trace mode that works with both normal and meta values. When one meta-value 'L' or 'H' is found at the input, the output will be a valid meta-value, so it propagates a meta-state in the logic cone. You can either set an input pin to meta, or select one input combination to output the corresponding metavalue. All the computations should be performed correctly, right ? At least you should observe a number of meta-values at the output to see which input or gate affects which output bit.

    Hopefully, this should help you design, adapt, refine and select your BIST methodology.

    For now you can only select one bit to "meta-ise" but it shouldn't be too hard to brute-force a small design, you can even run multiple GHDL instances in parallel, though that's only the beginning.

    Flip/Alteration mode

    Once you have selected your BIST method and built your test vectors, you need to test them exhaustively. You synthesise again and now you simulate over and over, with each iteration altering a different bit in the LUT of all the gates. Each time, one bit is flipped, which might subtly change the function of the gate and the whole circuit... Meta-informations are propagated like with the trace mode but no new meta-value is injected. However the change of any gate should result in at least one invalid result at the output.

    This is the most useful mode so far because it simulates the imperfect world. Furthermore, an exhaustive test might not...

    Read more »

  • The way to v2.3

    Yann Guidon / YGDES11/21/2019 at 00:56 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 / YGDES11/19/2019 at 06:11 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.

View all 24 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