Closed chick closed 5 years ago
This seems good to me. No big rush on getting it done. We have workarounds now.
Any progress on this one.
@stevenmburns this has been languishing, but I will get to it in the next couple of days. Can you provide an example of the the two use cases described?
Partially resolved by PR #161, remaining issue about how to remove flags that are hard coded right now:
In the long run, maybe we need a way to modify this Seq of flags. Not all of these are clearly always desired. In particular “-debug_pp” (record all internal signals in the vpd file) and “+v2k” (if we are using “-sverilog” instead) come to mind. Can we just expose it to the TesterOptions and then allow a user to manipulate it in scala?
val vcsFlags = Seq("-full64",
"-quiet",
"-timescale=1ns/1ps",
"-debug_pp",
s"-Mdir=$topModule.csrc",
"+v2k", "+vpi",
"+vcs+lic+wait",
"+vcs+initreg+random",
"+define+CLOCK_PERIOD=1",
"-P", "vpi.tab",
"-cpp", "g++", "-O2", "-LDFLAGS", "-lstdc++",
"-CFLAGS", "\"%s\"".format(ccFlags mkString " ")) ++
moreVcsFlags ++
blackBoxVerilogList
My idea to override +vcs+initreg+random
with +vcs+initreg+x
didn't work. (The "+x" suffix is not valid in newer versions of VCS.)
So I'll need something more near term. I'll just remove the +vcs+initreg+random
from our build and add it when we need it. You should probably implement either exposing the vcsFlags sequence or your RegEx-based removal idea.
@stevenmburns: I have a new PR #163 that gives ad hoc editing capabilities to the vcs command. Please check it out when you have a chance. It's a bit hacky but I felt I was getting bogged down trying to figure out a more general way of exposing the vcs command construction to the options manager system
I need to use custom command line options for the verilator backend. Is there any way to do this other than forking iotesters?!
Alright, I just found out that moreVcsFlags
works for Verilator too!
But I think there's room for improvement on the documentation side as well as for the naming of the option.
I think we can add support for this with an annotation pretty easily now that Stage/Phase is in. An API would then be an annotation or CLI option string that you add that uses that string when calling Verilator.
There is another option that we use as well (at least for VCS) for deleting existing commands on the command line, for example, if you want to allow X as initial values in your simulation:
vcsCommandEdits = """s/\+vcs\+initreg\+random //"""
Is there a way to use annotations (instead of ExecutionOptionsManager
) with the Driver
API?
It's in Chisel and FIRRTL, but not yet in all other projects (we're working on it). Summarily, execution options are deprecated in 3.2/1.2 in favor of annotations and you should be able to control everything that way.
I am wonder what the status of this issue is though. It looks to me like it has been addressed with the various PR's noted within. If there is something left to do here it might be a good idea to make a new more focused issue. Can this be closed?
Yes, we can close it.
val annotations = Seq(
VcsBackendAnnotation,
WriteFsdbAnnotation,
VcsCFlags(Seq("-I${VCS_HOME}/include")),//<-----
)
use chiseltest and send backend Parameters with test(xx).withAnnotations(annotations ) I tried and it worked well
Asked on stackoverflow.
Is there a way to specify options to VCS when using the PeekPokeTester? In particular, I would like to: 1) Enable System Verilog for black box code 2) Control the macro defines to disable the random number-based initialization. (I want to see initialization issues as Xs.)
I'd propose that there be two new options to chisel-testers, one to specify additional command line arguments, and another to expand the subcommands that are passed to the C compiler.