Comments (6)
Currently we have:
impure function RandCovPoint return integer ;
impure function RandCovPoint return integer_vector ;
impure function GetPoint ( BinIndex : integer ) return integer ;
impure function GetPoint ( BinIndex : integer ) return integer_vector ;
impure function GetMinPoint return integer ;
impure function GetMinPoint return integer_vector ;
As a first step we could add GetIncPoint which updates LastIndex to (LastIndex mod NumBins) + 1 and then does a GetPoint(LastIndex). Note the funny increment of LastIndex is because bins are numbered from 1 to NumBins.
impure function GetIncPoint return integer ;
impure function GetIncPoint return integer_vector ;
Then we could add a GetNextPoint(Mode) which does:
impure function GetNextPoint(Mode : ) return integer/integer_vector is
begin
case Mode is
when Random => return RandCovPoint ;
when Increment => return GetIncPoint ;
when Minimum => return GetMinPoint ;
end case ;
end function GetNextPoint;
GetIncPoint has the same flaws you pointed out with your current methodology, it ignores the current coverage of the bins in a trade for simplicity. GetMinPoint returns the bin with the minimum coverage which returns the first bin with the minimum percent coverage - which is one way to get an incrementing pattern when the coverage goals are different.
What this also points out is that the naming for RandCovPoint is inconsistent. Likelyhood in the future there will be a GetRandPoint that duplicates it and with the intent of slowly deprecating RandCovPoint. I use the word deprecate lightly as unless there is a compelling reason, there is no reason to break old code.
If we do this does it solve the problem?
from osvvm.
I am not against this, however, can you provide an example of where it is good to hide the intent of what you are doing like this.
Let me give an example of my concern from RandomPkg. RandomPkg has the capability to select which of uniform, normal, favorbig, favorsmall, and poisson (just for fun) distributions are used by RandInt and friends. However, as I read the tests, it results in something like:
RV.SetRandomParm(NORMAL, <mean>,<stddeviation>);
....
IntVal := RV.RandInt(0,15) ;
The problem I see is as the distance between the SetRandParm and the RandInt increases the less readable the code is. I think we need to take care with our abstractions and be sure to clarify the intent of the code and not obfusicate it, hence, later the following was added:
RV.Normal(<mean>, <stddeviation>, 0, 15) ;
I find myself challenged to find a use model for it, and hence, have actually thought of removing it.
Maybe if you could provide a good use model for this, I could both justify adding it and decide the current capability in RandomPkg is actually a good thing.
from osvvm.
I dont really have a specific test case - it was more for ease of debug. For example, when generating packet data, where the payload is inconsequential other than the length, I can currently generate it either as fully random payload, or as a count sequence. The count sequence makes waveform debug much easier as I can always tell from the payload where in the packet I am. I thought it might be useful to have a similar switch when using coverage. I currently use coverage to generate specific headers in a packet.
If I could use the coverage in a similar way, I could add the bins in the order that would make debugging easier, and have a simple switch to enable it, rather than have a more complicated setup that has several if..then statements to individually add bins based on config.
from osvvm.
Ok. You feedback helps.
from osvvm.
I have an example from a real testbench
I have a design sending IP packets over AXI. These packets are formed in a packet gerator that has multiple flows (in my case ~30). I use the covPType to create a index to fetch a packet from a specific flow (as the IP address, UDP port etc have to be consistent when sending multiple packets on the same flow).
idx := cov.randCovPoint;
pkt_ptr := new byte_array_t'( stream_gen.get_next_packet(idx) );
send_axis_packet( pkt_ptr.all, pkt_drive_q );
....
cov.ICover(idx);
The UUT has a filter that is supposed to only send specific packets to a specific end point, but some packets are being incorrectly dropped. With the randomised indexing, it is harder to track down which packets are being incorrectly dropped so a pattern can be detected. The flows are configured so that the first half should go through and the 2nd half should be blocked.
I can currently work around this problem in this tesbench with:
idx := cov.randCovPoint when G_RANDOM_COV else (pkt_cnt rem stream_gen.count_flows);
But this wont then obey any coverage limits set for each index.
from osvvm.
Released in 2020.05
from osvvm.
Related Issues (20)
- Alerts - Option to print entire path to alert name. HOT 6
- AlertLogPkg: ReportAlerts ignores ReportAll HOT 3
- Intelligent Coverage - Protected type restricted to use in different files HOT 8
- AlertLogPkg: Enabling and Disabling Passed/Affirmations Checked HOT 1
- Inconsistent line termination. HOT 4
- ScoreboardPkg is missing in OsvvmContext HOT 3
- Race conditions / buffer issues in console output HOT 4
- Missing wait for 0 ns in else-branch in WaitForLevel procedure HOT 2
- NewID Procedure with signal parameter and wait for 0 ns HOT 1
- NewID Procedure with signal parameter and wait for 0 ns
- Make the AlertLogName column width of log-output configurable HOT 2
- Traceability between expected errors/skipped tests and issue tracking software HOT 2
- CoveragePkg: AddCross with IgnoreBin Error HOT 5
- Common Log Interface HOT 6
- AlertLogPkg: AffirmIf with std_match (as implemented in the ScoreBoardPkg) HOT 3
- Add possibility to use falling clock edge as the active one. HOT 2
- RandInt : Provide simple overload or set defaults of min/max version to integer'low integer'high
- IDs - add _UNINITIALISED constant and add is_initialised functions for IDs
- ScoreboardGenericPkg: Make generic "match" function impure
- Provide a WARNING (user settable via options to ERROR) if any randomisation is attempted without first providing a seed HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from osvvm.