Daniel,
*<I am wondering if we can use an existing VHDL pseudo-random generator for
this purpose? Maybe "uniform" from math_real?>*
Those math functions do represent constraints in that the sequence of
numbers generated by the calls do have a shape or constraints.
SystemVerilog tooka different approach in that it allows the user to more
closely define the constraints, and the order in which those constraints are
solved.
SystemVerilog supports the generation of constrained-random values with the
use of the
randomize function, the rand and randc type-modifiers, randcase and
randsequence statements, and the rich sets of constraints with the
constraint construct.
For example, we constrained the number of idle cycles and the distributed
value of
the variable kind.
class Fifo_xactn extends vmm_data;
import fifo_pkg::*;
rand fifo_scen_e kind;
rand word_t data; // in : data to push
rand int idle_cycles;
time xactn_time;
constraint cst_idle {
idle_cycles inside {[1:3]}; // ranfom of values 1, 2, or 3
}
constraint cst_xact_kind {
kind dist {
PUSH := 400, //probability of 400/1201
POP := 300, //probability of 300/1201
PUSH_POP :=200,
IDLE := 300,
RESET := 1 // //probability of 1/1201
};
} // cst_xact_kind
Other examples:
class Bus;
rand bit[15:0] addr;
rand bit[31:0] data;
constraint word_align {addr[1:0] == 2’b0;}
endclass
typedef enum {low, mid, high} AddrType;
class MyBus extends Bus;
rand AddrType atype;
constraint addr_range
{
(atype == low ) -> addr inside { [0 : 15] };
(atype == mid ) -> addr inside { [16 : 127]};
(atype == high) -> addr inside {[128 : 255]};
}
endclass
task exercise_bus (MyBus bus);
int res;
// EXAMPLE 1: restrict to low addresses
res = bus.randomize() with {atype == low;};
// EXAMPLE 2: restrict to address between 10 and 20
res = bus.randomize() with {10 <= addr && addr <= 20;};
// EXAMPLE 3: restrict data values to powers-of-two
res = bus.randomize() with {(data & (data - 1)) == 0;};
endtask
class B;
rand bit s;
rand bit [31:0] d;
constraint c { s -> d == 0; }
constraint order { solve s before d; }
endclass
In this case, the order constraint instructs the solver to solve for s
before solving for d. The effect is that s is now chosen true with 50%
probability, and then d is chosen subject to the value of s. Accordingly, d
== 0 shall occur 50% of the time, and d != 0 shall occur for the other 50%.
The LRM is a good place to see what SystemVerilog has done on that topic.
Another excellent source is the book "SYSTEMVERILOG FOR VERIFICATION"
A Guide to Learning the Testbench Language Features. CHRIS SPEAR
*<Also, I was thinking maybe it is good to make it easier for designers to
design checkers/verifiers? Like a simple interface or method to input rules
as to when a set of outputs meet expectations and when they do not? Probably
by having an easy way of specifying tolerances/ranges. Perhaps SV already
has all these features, I'm just not aware of it.>*
That's what the constraints do in SystemVerilog.
Ben Cohen
Ben@systemverilog.us
On Sun, Dec 19, 2010 at 7:17 PM, Daniel Kho <daniel.kho@gmail.com> wrote:
> Hi Ben,
> Oh yes, I agree with your proposals in that email. My lack of knowledge in
> SystemVerilog does not allow me a comparison between the two languages, but
> your proposals sound useful (I especially like the dynamic arrays and
> constrained random generation).
>
> I am wondering if we can use an existing VHDL pseudo-random generator for
> this purpose? Maybe "uniform" from math_real?
> Also, I was thinking maybe it is good to make it easier for designers to
> design checkers/verifiers? Like a simple interface or method to input rules
> as to when a set of outputs meet expectations and when they do not? Probably
> by having an easy way of specifying tolerances/ranges. Perhaps SV already
> has all these features, I'm just not aware of it.
>
> Regards,
> Daniel
>
> On Mon, Dec 20, 2010 at 10:32 AM, ben cohen <hdlcohen@gmail.com> wrote:
>
>> *<The rationale is clear, Verilog/SV needs very comprehensive
>> verification (I even hear of great emphasis on lab bench verification and
>> FPGA emulation - for ASIC designers) to counter for their weak typing, while
>> VHDL being strongly-typed, does not require such comprehensive verification
>> capabilities.>*
>> [Ben] I totally disagree with that rationale as to why SystemVerilog
>> testbench and verification effort needs to be more comprehensive for
>> SystemVerilog designs over vhdl designs.
>> I am very knowledgeable in both languages, and wrote several books on
>> both. The typing is not the real issue. One of the reasons SystemVerilog
>> testbench are more comprehensive today is because of the design complexities
>> as the technology allows for much denser and complex designs. The growth
>> of integrated circuit complexity has driven the verification effort required
>> beyond all reason Thus, there is a need for more comprehensive
>> testbenches with constrained-random testing. Famework technologies, such
>> as VMM/OVM/UVM, allows you to quickly create a fast, reusable,and extendable
>> testbenches using SystemVerilog that is a language that supports constructs
>> needed for the verification of those complex designs.
>> In my email response to [vhdl-200x] Request for Input
>> I enumerated the several constructs that are needed for verification of
>> such complex designs.
>> Please take a look at that email.
>> IMHO, VHDL, SystemVerilog, Verilog, C, are just languages. The complexity
>> of the testbench is not the result of a language. However, some languages
>> are richer than others, and are better suited for certain tasks.
>> Ben Cohen SystemVerilog/us
>>
>> On Sun, Dec 19, 2010 at 5:54 PM, Daniel Kho <daniel.kho@gmail.com>wrote:
>>
>>> Hi Stephen and all,
>>> I have been waiting for this sort of discussion in the SG, and thanks to
>>> Steve, we can finally discuss our direction.
>>>
>>> I have to agree with some of Steve's points, including the declining use
>>> of VHDL. However, I think that we can do something to stop this trend (of
>>> people using non-VHDL design and verification languages). Perhaps instead of
>>> doing the same things that SV has been doing over these years, we could
>>> think of other things that could make VHDL more appealing.
>>>
>>> My belief is that VHDL usage in Europe, Australia (and probably most of
>>> the Commonwealth) remains strong. I don't have statistics though, but I am
>>> one example of a VHDL-only user designing for a European application. One of
>>> the really good thing about VHDL is that we don't really need such a
>>> comprehensive verification package (like that used by Verilog / SV), the
>>> reason being that VHDL is already very strongly typed - this means less
>>> verification.
>>>
>>> I hear VHDL designers say "If it works in simulation, it works on
>>> silicon", but I don't hear the same from Verilog/SV designers. Instead they
>>> would talk a lot about verifying their designs. The rationale is clear,
>>> Verilog/SV needs very comprehensive verification (I even hear of great
>>> emphasis on lab bench verification and FPGA emulation - for ASIC designers)
>>> to counter for their weak typing, while VHDL being strongly-typed, does not
>>> require such comprehensive verification capabilities.
>>>
>>> I currently write everything in plain old VHDL - from the core designs to
>>> even the testbenches. And I feel the language is sufficient for both
>>> purposes (this perhaps is because my designs aren't as complex as some of
>>> yours).
>>>
>>> My humble opinion is that we should not try to do the same things those
>>> SV guys have been doing (I agree with Steve on this), but instead focus our
>>> energy on things that make VHDL easier to use, such as simplifying type
>>> conversions, and friendlier packages.
>>>
>>> I would propose that we make some of VHDL's core packages to easily work
>>> together with one another. One simple example I can think of is in the use
>>> of literals:
>>>
>>> signal i: integer := x"ab";
>>>
>>> where in this case, I can use the hex notation to express an integer
>>> instead of writing out 16#ab#.
>>>
>>> I further propose for certain packages to be synthesisable, such as the
>>> math_real package (this would ease designers from having to write their own
>>> fixed-point or floating-point packages).
>>>
>>> Also, for certain constructs in the core language to be synthesisable,
>>> such as "assert" or "report", which currently is exclusively used only in
>>> simulation. I can think of something like a generic "debug interface" or
>>> "verification interface", which can be synthesised to a real interface
>>> reserved for debugging/verification purposes. And this interface allows for
>>> the use of constructs such as "report" and "assert", while having
>>> capabilities such as queuing of "reports" (or logs), and bus arbitration
>>> (for multiple verification interfaces).
>>>
>>> I am positive that with great minds as all of you, the SG/WG will be able
>>> to brainstorm such great ideas to set the direction for the next revision of
>>> VHDL.
>>>
>>> Regards,
>>> Daniel
>>>
>>>
>>> On Mon, Dec 20, 2010 at 4:35 AM, Bailey, Stephen <
>>> stephen_bailey@mentor.com> wrote:
>>>
>>>> I have submitted my negative vote on the PAR to Jim. I am now
>>>> forwarding the comments that document why I am voting Negative.
>>>>
>>>> -Steve Bailey
>>>>
>>>> The SG has spent all of its time discussing the organization of the WG
>>>> as individual or entity/Corporate. I don't see anything in the minutes
>>>> identifying the requirements for this revision. The recent flurry of
>>>> emails has me concerned that the WG will duplicate significant work that
>>>> has gone into SV by putting similar functionality into VHDL. I cannot
>>>> support the waste of tens to hundreds of man-years to achieve that
>>>> output with the only outcome being that people can do what they can do
>>>> today only in 2 different languages instead of 1 (actually 4 different
>>>> languages instead of 3 when you include e and Vera).
>>>>
>>>> VHDL usage was on the decline prior to SV. SV has accelerated that
>>>> decline. I don't see a way to change the current course of the
>>>> EDA/language trends. They are too strong and the cost to change them
>>>> are prohibitive.
>>>>
>>>> Data which the SG may find useful. The data is from a recent blind
>>>> survey commissioned by Mentor and conducted by Wilson Research Group.
>>>> This data is from North America. The rest of the world portion of the
>>>> survey was recently completed and the combined results not yet
>>>> available.
>>>>
>>>> VHDL design usage declined from 37% in 2007 to 27% in 2010 with
>>>> respondents projected a further decline to 23% in the next 12 months.
>>>> That's a loss of nearly 40% of the design user base for VHDL.
>>>>
>>>> Verilog usage has declined from 81% to 78% and projected to go to 71%.
>>>> SystemC, C/C++ and other design languages have also declined from 2007
>>>> to 2010.
>>>>
>>>> SV has increased from 10% to 34% today and projected to reach 47% in the
>>>> next year. That's a nearly 5x increase in usage.
>>>>
>>>> In verification, VHDL usage is down to 21%, from 27%, and projected to
>>>> fall further. In fact, there are only two languages that have increased
>>>> usage in verification: SystemVerilog usage in verification more than
>>>> doubled to 50% and is projected to increase significantly in the next
>>>> year. C/C++ has seen a respectable increase from 2007 but is projected
>>>> to decline slightly in the next year. Even SystemC usage in
>>>> verification is down slightly from 2007 -- call it steady at about 17%.
>>>>
>>>> The survey included FPGA and ASIC designs and respondents from all
>>>> industries/markets. Although data from the rest of the world might
>>>> soften a bit what is being reported in NA, based on my personal
>>>> experience, I don't expect it to be meaningful in any area except maybe
>>>> SystemC, which has historically higher use in Europe and Japan than in
>>>> the U.S.
>>>>
>>>> In the next year, 80% (4 of every 5) of designers and verification
>>>> engineers will use a language that is not VHDL. Most of them will be
>>>> using SV or Verilog.
>>>>
>>>> The SG needs to ask itself these questions: Can you stop a tsunami?
>>>> What can you offer that would overcome a projected 3x+ advantage that SV
>>>> will have over VHDL in verification usage within the next year; and
>>>> surely greater than that 2 or 3 years from now. If the plan is to
>>>> survive the tsunami, what will you do to survive it when EDA vendors
>>>> clearly know where the market is going? Until these questions are
>>>> addressed in a manner that reflects reality, my vote will remain No on
>>>> another VHDL language revision.
>>>>
>>>>
>>>> --
>>>> This message has been scanned for viruses and
>>>> dangerous content by MailScanner, and is
>>>> believed to be clean.
>>>>
>>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
>>> is
>>> believed to be clean.
>>>
>>
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sun Dec 19 20:53:39 2010
This archive was generated by hypermail 2.1.8 : Sun Dec 19 2010 - 20:53:57 PST