leonardt / fault

A Python package for testing hardware (part of the magma ecosystem)
BSD 3-Clause "New" or "Revised" License
41 stars 13 forks source link

fix input values due to the change for signed values #105

Closed Kuree closed 5 years ago

Kuree commented 5 years ago

image

Whenever the high bit for the input is high, i.e. when the value is larger than 0x80, the current fault will pad 1's to make an negative number. This patch use masks to mask them off.

That's the cause that why verilator failed in GarnetFlow but ncsim works: https://github.com/StanfordAHA/GarnetFlow/commits/master

EDIT: Travis version is working with this fix: https://travis-ci.com/StanfordAHA/GarnetFlow/builds/112535673

coveralls commented 5 years ago

Pull Request Test Coverage Report for Build 930


Totals Coverage Status
Change from base Build 928: 0.01%
Covered Lines: 1368
Relevant Lines: 1791

💛 - Coveralls
leonardt commented 5 years ago

Interesting, is this because without the mask, C is promoting the byte (char) to a 32 bit type (used by verilator?) which results in sign extension? Then adding the mask results in the promotion to 32 bits without extension because the mask numeric literal is treated as a 32 bit value?

Kuree commented 5 years ago

I believe so. char in C/C++ is signed by default. So there might be a sign extension during the implicit conversation. Bitwise & should correct this error regardless whether the input is signed or not.

leonardt commented 5 years ago

Confirmed via testing!

// promotion.c
#include "printf.h"

int main() {
    char byte = 0xEE;
    printf("%%hhx byte = %hhx\n", byte);
    printf("%%x   byte = %x\n", byte);
    printf("%%x   (int) byte = %x\n", (int) byte);
    printf("%%x   byte & 0xFF = %x\n", byte & 0xFF);
}

and

/tmp
❯ gcc promotion.c && ./a.out
%hhx byte = ee
%x   byte = ffffffee
%x   (int) byte = ffffffee
%x   byte & 0xFF = ee
leonardt commented 5 years ago

Another thing we could try is using unsigned char instead of char for the input type of files. This design enforces that files are read as unsigned bytes. Are there cases where it makes sense to read file data as a signed byte ever?

Kuree commented 5 years ago

I need to confirm this with @jeffsetter and other people who do the application development. For DNN the inputs may be signed depends on how they process it.

jeffsetter commented 5 years ago

I was templating my testbench to support different types, including the signed and unsigned variants. Images support unsigned and signed types.