Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 27 2021 06:11
    abignail commented #9
  • Sep 27 2021 06:10
    abignail commented #9
  • Sep 27 2021 02:34
    abignail commented #9
  • Jun 20 2021 03:54
    Tianhang-Cheng opened #13
  • Jun 17 2021 14:08
    Tianhang-Cheng closed #12
  • Jun 17 2021 14:08
    Tianhang-Cheng commented #12
  • Jun 17 2021 08:45
    Tianhang-Cheng opened #12
  • Jun 17 2021 08:31
    Tianhang-Cheng commented #11
  • Oct 30 2020 04:53
    dhxsy1994 closed #11
  • Oct 19 2020 10:06
    dhxsy1994 edited #11
  • Oct 19 2020 10:06
    dhxsy1994 opened #11
  • Oct 21 2019 19:20
    salmansheikh opened #10
  • Jul 27 2019 15:28
    apaj opened #9
  • Feb 18 2019 14:46

    codelec on master

    fix link (compare)

  • Feb 13 2019 02:45
    kai413629305 opened #8
  • Jan 01 2019 05:52

    codelec on master

    newer jars on maven restore nor… (compare)

  • Dec 16 2018 05:34

    codelec on master

    use older chisel3 and chisel-io… (compare)

  • Jul 15 2018 12:04

    codelec on master

    [common][rv32_1stage] use chise… (compare)

  • Jun 15 2018 08:59
    codelec closed #4
  • Jun 14 2018 18:37

    codelec on master

    [common] remove cloneType in fa… [1stage] modify imports to incl… [2stage] modify imports to incl… and 4 more (compare)

Will
@wiltonburke
Hello
Christopher Celio
@ccelio
hi!
kritik bhimani
@codelec
Hi all I changed the branch naming scheme. Branch name with -dev should indicate that the branch is in development for eg. arty-dev should indicate that support for arty fpga is in development. Please suggest if you have any other naming scheme
Tanveer Ahmad
@tahashmi
Hi @ccelio
I'm looking for some ideas from you to work in GSoC 2018 regrading #riscv-sodor / #BOOM
Are you in ?
Christopher Celio
@ccelio
hi @tahashmi
Tanveer Ahmad
@tahashmi
Hello @ccelio I have just started PhD at TU Delft
Working on reconfigurable heterogeneous computing architectures, also interested to extend/work on BOOM/Rocket for my future research
nice to see you here!
Christopher Celio
@ccelio
That's exciting.
Most of my ideas to extend BOOM have to do with verification. E.g., build a test harness and unit-test the Instruction Fetch Unit.
Mostly just engineering work though.
Or adding RVC.
Stefan Wallentowitz
@wallento
@tahashmi we have this chisel learning journey, which is a great idea
but I saw there is already a lot of activity around that
Tanveer Ahmad
@tahashmi
Thank you @ccelio I will check what I can do for verification in a while.
Tanveer Ahmad
@tahashmi
Hi @wallento , Thanks. Yes I was also thinking about chisel learning journey.
Tanveer Ahmad
@tahashmi
@wallento So is there any chance to work on this idea of extending chisel learning support?
Christopher Celio
@ccelio
imo, I think a roadblock for chisel adoption is we need to show people how to verify their designs. for rocket and boom, the answer so far has been to write a verilator test bench that is tethered to a C++ front-end server, and to simulate the entire system running full programs.
i think it would be interesting to get more feedback from industry people on what they would like to see. UVM support? formal testing of Sodor? how to unit-test a Sodor "frontend"?
kritik bhimani
@codelec
is formal testing of sodor different from lockstep simulation between sodor and spike?
i have never used uvm or any verification methodology so formal verification/testing is unknown to me
Stefan Wallentowitz
@wallento
formal verification is actually not covered by UVM I think
the verification frameworks try to verify against a golden model
I favor cocotb a lot for standard verification, because it is damn easy to use
the problem with UVM is IMO that they squeezed everything into System Verilog that doesn't really fit. My experiences were really painful..
so, running cocotb on the verilog output seems a good choice to me
but as @ccelio wrote, what are you actually testing?
unit tests are nice, but a lot of work if its not with standard interfaces
writing your model that generates the expected behavior can be painful
kritik bhimani
@codelec
i am not testing anything but just wanted to know what "formal testing" is -> but from what you just told it means testing against a golden model(spike)
Stefan Wallentowitz
@wallento
formal verification is actually not testing against a golden model
but against a formal description
there is a lot of stuff from clifford wolf on this topic
kritik bhimani
@codelec
RVFI?
Stefan Wallentowitz
@wallento
yes
thats the interface, right?
kritik bhimani
@codelec
the full-form stands for an interface, clifford must be a part of the formal-spec group so he will also have access to the formal description
Stefan Wallentowitz
@wallento
yes, he is, but his work was developed before the workgroup existed
he presented it at ORConf last year too
there is a video
kritik bhimani
@codelec
seeing that video will help me know more about "formal" things
Stefan Wallentowitz
@wallento
wow, thats a massive preview :-D
Christopher Celio
@ccelio
There are a couple of things going on here. For RVFI, that's letting a core send its committed instruction stream to a "formal model of the ISA" to check that the committed instruction stream obeys the ISA. That's super cool, but only one facet of formal.
Formal, as that awesome talk will explain, is about providing asserts, assumes, ignores, etc., in the hardware design and then hooking it up to a formal model that tries to find an adversary input that will break an assert. It tends to work for verifying small pieces of hardware designs where exhaustive testing just can't cover everything.
It would be neat to see how to leverage formal within Chisel. admittedly formal is beyond my understanding (and I think somebody at Berkeley may be working on this).