-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
about ScanChainTransform error #29
Comments
The current problem is that I have not updated Chiffre to work on the newest Rocket Chip. (Technically, I haven't tested it in some time, so I expect a few things are broken/out of sync.) That specific error you mentioned is because Cool! I'm glad you find it useful. @azidar actually just filed a PR (chipsalliance/chisel#1077) which is intended to make the specification of things you want the compiler to modify (like fault injection points) NOT require source code modifications. Instead it's an argument you pass to the compiler. So... things are intending to get better in the future.
That's probably about it. Obviously, getting started with Chiffre on smaller designs or looking at the tests will be more straightforward to understand. However, the intent is that you just specify what you want to make run-time injectable, and everything is taken care of for you. When/if things go wrong, file an issue.
Yes, I just haven't found the time, nor a specific user clamoring for this. If it's something you're interested in, I can see about looping back to this. |
Thanks for your prompt reply. Your answer helps me a lot.
…------------------ Original ------------------
From: Schuyler Eldridge <[email protected]>
Date: Wed,Apr 24,2019 10:19 PM
To: IBM/chiffre <[email protected]>
Cc: yangrj <[email protected]>, Author <[email protected]>
Subject: Re: [IBM/chiffre] about ScanChainTransform error (#29)
The current problem is that I have not updated Chiffre to work on the newest Rocket Chip. (Technically, I haven't tested it in some time, so I expect a few things are broken/out of sync.)
That specific error you mentioned is because TargetDirAnnotation changed (a change I introduced). TargetDirAnnotation is a case class with one public member "dir". In a further PR I updated it to be called "directory". I think, for the time being, the fix is to change a.value to a.dir.
Cool! I'm glad you find it useful. @azidar actually just filed a PR (chipsalliance/chisel#1077) which is intended to make the specification of things you want the compiler to modify (like fault injection points) NOT require source code modifications. Instead it's an argument you pass to the compiler. So... things are intending to get better in the future.
I also would like to ask if I want to evaluate my own processor implemented in Chisel language, in addition to the fault injector controller, faulty component and firrtl transforms, what else do I need to do or pay attention to?
That's probably about it. Obviously, getting started with Chiffre on smaller designs or looking at the tests will be more straightforward to understand. However, the intent is that you just specify what you want to make run-time injectable, and everything is taken care of for you. When/if things go wrong, file an issue.
Do you still have plans for memory fault injection?
Yes, I just haven't found the time, nor a specific user clamoring for this. If it's something you're interested in, I can see about looping back to this.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Hello, I am very sorry to bother you. I have seen your paper "Chiffre: A Configurable Hardware Fault Injection Framework for RISC-V Systems " and I’m very interested in your Chiffre Fault Injection Framework.
I tried the Chiffer experiment but end up encountering a problem during the configuration of LeChiffre. According to the error log "value is not a member of firrtl.TargetDirAnnotation", I went to check the definition of TargetDirAnnotation in the firrtl source files, but found that the member ‘value’ does not exist.
I see that the FIRRTL project is still being updated. I don't know if it is the reason for the firrtl version to cause this error. I don't know much about the compilation process of firrtl, so I don't have an idea for this problem. I sincerely hope that I can get your help.
The error logs is as follows:
[error] /chiffre/rocket-chip/chiffre/src/main/scala/chiffre/passes/ScanChainTransform.scala:131:95: value value is not a member of firrtl.TargetDirAnnotation
[error] val targetDir = new File(state.annotations.collectFirst{ case a: TargetDirAnnotation => a.value}.getOrElse("."))
[error] ^
[warn] /chiffre/rocket-chip/src/main/scala/util/DescribedSRAM.scala:7:34: imported `Annotated' is permanently hidden by definition of object Annotated in package util
[warn] import freechips.rocketchip.util.Annotated
[warn] ^
[warn] one warning found
[error] one error found
One of the great advantages of Chiffre framework is that it only needs to make few modifications to the original circuit description. Refer to the method of writing chisel and firtrl transforms, I also would like to ask if I want to evaluate my own processor implemented in Chisel language, in addition to the fault injector controller, faulty component and firrtl transforms, what else do I need to do or pay attention to? Do you still have plans for memory fault injection?
Thanks for your time and look forward to your reply.
The text was updated successfully, but these errors were encountered: