You should just be able to start the worker and (after the time for training); use it. For the moment, it would not be a bad idea to check that bit 0 of status is set. In the future, the training will take place on the initialize->start transition; and then the wait for training will be signaled by the delayed return of the START OK Control Op response. -Shep
On Tue, Apr 3, 2012 at 10:03 AM, Albert Kwon <[email protected]> wrote: > What is the equivalent of this when I'm using the c++ code (a code like > testRpl)? Do I have to use swctl? > > Thanks, > Albert > > > > On 04/03/2012 07:11 AM, Shepard Siegel wrote: > > See lines 133-135 > https://github.com/ShepardSiegel/ocpi/blob/master/bsv/wrk/DramServer_v6.bsv > > The only bit that matters is bit 0. > The rest are for debug and may or may not be present based upon > hasDebugLogic > > Be sure to wait a second or two after the > reset->unreset->initialize->start sequence before looking, as read-capture > training takes a while and we have not yet made that long wait built into > initialize (as it should be). > > Look at testSeq9* if you are unsure of the sequence, e.g. > https://github.com/ShepardSiegel/ocpi/blob/master/bin/testSeq9b2 > > Please let me know if that was your issue. > > -Shep > > > > On Tue, Apr 3, 2012 at 1:05 AM, Albert Kwon <[email protected]>wrote: > >> Hi Shep, >> >> I have a quick question about dramStatus variable in >> DramServer_v6.bsv: is initComplete.read supposed to be 1 when DRAM is ready? >> When I get the value for dramStatus, it is always 16, which seems like >> it means appFull = 1, and everything else is 0. >> If so, how can I make sure that it is 1? >> >> Thanks, >> Albert >> > > >
_______________________________________________ opencpi_dev mailing list [email protected] http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
