Get email delivery of the Cadence blog featured here
Right form the start Specman has been very good at generating constrained random stimulus. Value generation guided by constraints is achieved with an algorithm within Specman that is at the very core of the tool. And solving constraints is one of the most outstanding features of Specman itself.
In the early days of Specman, the constraint solver (called PGen) had been continuously augmented and improved over time. However, at some point, this constraint solver reached its limitations due to the ever-increasing complexity of constraints, and a new constraint solver was created. This new constraint solver, called IntelliGen, became the default constraint solver in Specman and it has seen a lot of development to further improve generation performance and capacity. IntelliGen has not only gotten faster and smarter, it has also stayed as backwards compatible as possible. This means that you can still run old e constraints in IntelliGen without noticing that the engine under the hood for resolving constraints has changed.
Several years ago, I transitioned from PGen to IntelliGen, and even while migrating problematic constraints from PGen to IntelliGen, I had very minimal hiccups. The issues I did encounter did not relate to getting the code to compile, but rather related to how the constraint interpretation (also known as semantics) changed with IntelliGen.
It helps to understand how IntelliGen does all of its magic, because to predict how a constraint model is solved, you have to know how IntelliGen ticks:
Each group of constraints has a bunch of elements. These elements are fields that are tied together by the constraints.
In this simple example, we see two constraints. Each of the constraints creates a group that connects a number of fields together.
The technical term for such a group of elements is “Connected Field Set” (CFS), and understanding this will help you understand IntelliGen’s warnings and errors as well as how performance is impacted by certain constraints.
Any field which is used in constraint expressions is linked to other fields in those expressions. There are some expressions which cause fields to be inputs. An input is a field that needs to be generated first, and whose value is then used as is. A method call, for example, makes a field an input, since the generator cannot understand what a method does. So the field is just passed as is to the method, and the result is used. The read_only() method also does this, although there is no method to call. So all this does is make the field which is passed an input.
For the example we get 2 CFSs:CFS 1: a_uint, b_uintCFS 2: c_byte, d_nibble
The field c_byte is also involved in CFS 1, but only as an input. What this means is that CFS 2 is first resolved, and then the value of c_byte is passed into CFS 1. When CFS 1 is resolved, c_byte is not changed, only its value is used.
The simplified characteristics for fields and CFSs can be summarized as follows:
Keep in mind that there are exceptions to these rules, but these will be discussed in future articles.
Great, now we’ve established a common terminology and explained what CFSs are! These have been at the heart of constraint generation for a while now, and if you haven’t heard of them then good for you because Specman never complained about them and your constraints are well written. Or are they? Perhaps you should take a good look in your Specman console and log-files and search for some warnings:
You can retrieve all generated warnings and errors by using the following command in the Specman command line:Specman> show notify *GEN*
These warnings may give you some very useful information on the reported constraint’s performance or on some possible unintended results.
In summary, knowing about CFSs will help you write constraints that are a lot more efficient, and will also help you understand unintended behavior as well as generation-related performance issues.
This article is the first one in a new series to highlight constraint-modelling in Specman, to give you food for thought and help you get more efficient modeling constraints. There will be more articles coming in the following weeks/months to address specific topics which I found helpful when dealing with constraint-modeling and debugging.
Stay tuned and thanks for reading.