-
Version 2.2
11/19/2019 at 06:11 • 0 commentsI 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
09/05/2019 at 14:51 • 0 commentsA 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...
08/19/2019 at 20:12 • 0 commentsWhile 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
08/17/2019 at 18:39 • 0 commentsThe 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 !
08/13/2019 at 22:25 • 0 commentsThere'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
08/10/2019 at 21:50 • 0 commentsI added the code to generate all the 15 DFN1* gates.
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
08/10/2019 at 14:51 • 0 commentsThe 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
08/09/2019 at 20:39 • 0 commentsIt 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 !
08/08/2019 at 08:55 • 0 commentsI 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...
-
Let's generate (most) files
06/17/2019 at 09:20 • 0 commentsIf you remember the log What if we generated the files for each gate ? you know I discarded the idea of generating the gates with a script.
Well, after a few days of sitting on this setback, I decided that there were enough "low hanging fruits", and the advantages are good enough, to justify writing some code to generate those gates. The trick is to keep the system simple and small enough that it doesn't create more problems than it solves.
The first change is to create 4 types of combinatorial gates, depending on the number of inputs. The sequential gates (latches, flip-flops) will be ignored for now.
4 types means there are dealing with 4 sizes of lookup tables : 1, 2, 4 and 8 entries. Ideally we would use only one size (8 entries) and an extra size parameter (stored somewhere) gives the range, or something... but since VHDL arrays already has 'range-related attributes, we can infer the actual type. The perturbation logic would be something like :
index = Random() mod Table'Length; table(index) <= table(index) xor '1';
The lookup table array is std_logic_vector because it helps with something else : coverage. If one element of the table is set to 'X' then the value will (ideally) propagate to the output, showing that this entry is sensitive to a given test vector. The universal gate must be modified:
if (a='X') or (b='X') or (c='X') then return 'X'; end if;
We can go even further because each input gets compared sequentially to create the index :
variable i : integer := 0; ... if a = '1' then index := 1; else if a /= '0' then return a; end if; end if;
Then the same code is copy-pasted-modified for b and c, depending on the number of inputs (and names) of the gates.
Sounds like a plan...
Now that we can deal with a flexible size of lookup table, we can define the corresponding type :
subtype LookupType1 is std_logic_vector( 0 downto 0); subtype LookupType2 is std_logic_vector( 1 downto 0); subtype LookupType4 is std_logic_vector( 3 downto 0); subtype LookupType8 is std_logic_vector( 7 downto 0);
Then we can sort the gates according to their inputs :
- no input : GND VCC (CLKBUFF is an exception with the implicit input from a pin)
- 1 input : INV CLKINT (CLKINT wouldn't be used in a portable design anyway)
- 2 inputs : AND2 AND2A NAND2 NOR2 NOR2A NOR2B OR2 OR2A OR2B NOR2 XNOR2 XOR2 (some functions would be redundant)
- 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 XO6 AXO7 AXOI1 AXOI2 AXOI3 AXOI4 AXOI5 AXOI7 MAJ3 NAND3 NAND3A NAND3B NOR3 NOR3A NOR3B NOR3C OA1 OA1A OA1B OA1C OAI1 OR3 OR3A OR3B OR3C XA1 XA1A XA1B XA1C XO1 XO1A XOR3 XNOR3 ZOR3 ZOR3I
- 3 inputs with modified input signal names : MX2 MX2A MX2B MX2C
...