Posts

More SystemVerilog Streaming Examples

In my previous post I promised I would write about more interesting cases of streaming using a slice_size and arrays of ints and bytes.  Well, I just posted another set of streaming examples to edaplayground .  I'm going to mostly let you look at that code and learn by example, but I will take some time in this post to explain what I think is the trickiest of the conversions.  When you go to edaplayground, choose the Modelsim simulator to run these.  Riviera-PRO is currently the only other SystemVerilog simulator choice on edaplayground, and it messes up on the tricky ones (more on that in a bit). These examples demonstrate using the streaming operator to do these conversions: unpacked array of bytes to int queue of ints to queue of bytes queue of bytes to queue of ints int to queue of bytes class to queue of bytes Of all those examples, the queue of ints to queue of bytes and the queue of bytes to queue of ints are the tricky ones that I want to spend more ...

SystemVerilog Streaming Operator: Knowing Right from Left

SystemVerilog has this cool feature that is very handy for converting one type of collection of bits into another type of collection of bits.  It's the streaming operator.  Or the streaming concatenation operator.  Or maybe it's the concatenation of streaming expressions (it's also called pack/unpack parenthetically).  Whatever you want to call it, it's nice.  If you have an array of bytes and you want to turn it into an int, or an array of ints that you want to turn into an array of bytes, or if you have a class instance that you want to turn into a stream of bits, then streaming is amazing.  What used to require a mess of nested for-loops can now be done with a concise single line of code. As nice as it is, getting the hang of the streaming operator is tough.  The SystemVerilog 1800-2012 LRM isn't totally clear (at least to me) on the details of how they work.  The statement from the LRM that really got me was this, "The stream_operator <...

A Quick Look at svlib

I just took a quick look at svlib from Verilab.  Very cool.  It's a library for SystemVerilog that gives you file globbing, regular expressions, a better string class, simple ini config file parsing (with yaml support promised for the future!), and more.  It was announced back in March and it took me this long to getting around to reading about it.  Hopefully it doesn't take me that long to actually try it out :-) They welcome feedback so brace yourself, here it comes.  First of all it's open source (Apache license) which is excellent.  It's open source and it has documentation.  Amazing!  :-)  It is not currently developed openly though.  Could we get a github, bitbucket, or sourceforge project going?  Our industry (design verification) desperately needs to admit and recognize that we are software developers.  I mean no, we are verifiers!  Bug finders!  It just so happens that writing software is the primary tech...

Avoiding Verilog's Non-determinism, Part 2

At the end of my last post I promised I would have another non-determinism (AKA, race condition) example from recent real-life experience. Here it comes. Before I show you any code I want to explain how this race condition was introduced. We had a signal in an interface that needed to be widened. We had a function in some simulation-only code that looked at part of that signal and didn't care about the new bits that were added. The engineer who widened the signal decided not to change the function and instead added a new variable and assigned (using the assign keyword) the bits of interest from the newly widened signal to this new variable. He then passed this new variable to the original function in place of the original newly-widened one. Seems reasonable, right? Well, after he made that change some tests started failing and after some digging it began to look like a race condition, but it wasn't obvious where the race was coming from. The problem was that assign s...

Avoiding Verilog's Non-determinism, Part 1

In my last post we looked at some example code that showed off Verilog's non-determinism. Here it is again (you can actually run it on multiple simulators here on EDA Playground ): module top; reg ready; integer result; initial begin #10; ready <= 1; result <= 5; end initial begin @(posedge ready); if(result == 5) begin $display("result was ready"); end else begin $display("result was not ready"); end end endmodule Just to review from last time, the problem is that sometimes the @(posedge ready) will trigger before result has the value 5 and sometimes it will trigger after result has the value 5. We have called this non-determinism but a more common term for it is, race condition. There is a race between the values of ready and result making it to that second process (the second initial block). If result is updated first (wins the race) then everything runs as...

Is Verilog's Non-determinism Really a Problem?

A series of blog posts by Jan Decaluwe criticize Verilog for being "non-deterministic" and therefore fundamentally broken. This one has a code example that illustrates the fact. During a lively Twitter conversation about it I fleshed out the example and put it on EDA Playground so we could all view it and, even better, run it with all the simulators that EDA Playground provides and see what actually happens. Click here to see and run the example code yourself. If you run the example you'll see that it behaves the same for all the simulators available on EDA Playground, except one. Jan explains that they are all compliant with the Verilog specification because the specification allows for either behavior. Jan expertly explains in this post how that can be. Despite these clear examples and explanations I'm left with the feeling of, why should I care? Apparently a lot of other users of the Verilog language have the same feeling as me. I tried to see Jan's ...

SVUnit Upgrade

Being a relatively early adopter of svunit (for unit testing SystemVerilog code), I had a fair amount of code written to work with the early 0.X versions of svunit. The maintainers of svunit have made some good progress and are now on version 2.3 (as of writing this). My old tests don't work with the new version of the framework, but I figured out how to update them. Just in case anyone else is in the same predicament, I will share the steps I took to fix things: In the *_unit_test.sv file: remove typedef class c_<UUT>_unit_test keep the module <UUT>_unit_test declaration, but delete everything in the module except for the string name… and any interface declarations you may have added delete the c_<UUT>_unit_test class declaration add svunit_testcase svunit_ut; under the string name… Now that this is a module and not a class, tasks and functions declared in here might need to have the automatic keyword added to the declaration in order to beh...