Due to architectural changes in SPB16.5 Design Entry HDL (DEHDL), we no longer require various modes of operation -- such as Hierarchy mode, Expanded mode and Occurrence Edit mode. There will be no need to change modes while working on the schematic since the explicit need for design net listing and design expansion is removed. This is a HUGE simplification from prior releases!Read on for more details …
Designs which are upreved to the SPB16.5 DEHDL release lead to a single mode of operation in which the winning values of properties are always displayed on the schematic canvas. There is no longer a need to change the modes from hierarchy mode to expanded mode to occurrence edit mode. In short, what you see on the schematic canvas is what you get on the board. The following are the different modes of operation used to capture/modify schematic connectivity and properties in pre-SPB16.5 releases:
These modes no longer exist, but the connectivity and property changes can still be made in a similar manner with flexibility provided to the user. The new dynamic connectivity model has the complete design information loaded in memory; any change to the design content needs to be updated in the memory image. The changes are committed and updated to the memory image and the disk image while saving the design. Once the memory image has been updated, the changes can be viewed anywhere in the design. Therefore, saving the schematic sheet after making changes is very important. With the incremental netlisting available in SPB16.5 release, the changes in the schematic sheet are quickly computed and updated to the design image. As there is no need to generate the design netlist, saving schematic sheets will no longer be a problem. Also, the HDL_DIRECT OFF option is no longer needed.In the SPB16.5 release, all the connectivity changes are stored in the hierarchical block directly. Connectivity changes are basically additions or modifications of components, nets, and pin-net connections. The behavior remains the same as in pre-SPB16.5 release.
Property changes can be stored directly in the hierarchical block on which the object exists, or at the root (top) level design in context of which the block has been instantiated.Note: With the opf file information no longer generated, this portion of SPB16.5 is the most important change. You must ensure that you understand the concept thoroughly.
When a user stores a property in a hierarchical block, it is visible in all the instances of the block and any change to the property in the block is propagated to all the instances of the block. In pre-SPB16.5 releases, the user was able to do this only in Hierarchy mode.
When the user wants to store a property change only on a particular instance or occurrence of a block, the property needs to be stored in the root (top) level design. In pre-SPB16.5 releases, this level of change was stored in the opf file in the Occurrence Edit mode. In the SPB16.5 release, this property is stored on the instance in context of the root (top) level design. Important: With the SPB16.5 release, Design Entry HDL does a property check of all Cadence properties, to check if any values are incorrectly set in the schematic. Therefore, it is possible that you may get some warning or error messages.
In the SPB16.5 release, as there is only a single mode of operation, property changes are supported and you have the flexibility of selecting the location for storing property changes. The location where the property is stored is known as the Source of the property and it is visible in the attribute form. A new column, Source, has been added to the Attribute form. Source displays the name of the block where the property is stored:
When a property is added, the default source for that block/root property is selected. This default is selected based on the type of the block being added (flat, non-replicated, or replicated). At the same time, you can change the source by clicking on the drop down list and selecting another source block/root. Depending on the source, properties are called Occurrence properties or Block level properties.
Now that we are getting the feel of the property changes, let us look at the type of property changes that can be done in the SPB16.5.
Master Property Change
The Master Property Changes are the changes in the property value that is stored in the block directly. These changes are visible at all instances of the block. This is same as adding the properties in Hierarchy mode operation in pre-SPB16.5 releases.
In-Context Property Change
The In-context property changes are changes in the property value that is stored in the root (top) level design. The property is added on a specific instance (occurrence) of the block and is visible only on this instance of the block. This is same as adding properties in the Occurrence Edit mode in pre-SPB16.5 releases.The next section covers the different types of designs and the default options that are provided for the source while adding a property.Adding Properties to a Flat Design or Root (Top) Level Design
Any property that you add in a flat design or root (top) level design is saved as a Block (Master) property by default. As there is only one design level, the property is stored in that design only. Here, you do not have an option to save the property as an Occurrence property.In the following figure, a new property FOO is added with BLOCK as the value. It is saved with Source as PROCESSOR (i.e. as a Block property). The Source column drop down has only one value, PROCESSOR:
Adding Properties in Non-Replicated Designs
A non-replicated design is a design which contains only one instance of each of the hierarchical blocks used at the top level.
When you add a property to an instance in the non-replicated block, the property is saved as a Master property by default. Since there is only one instance of the block, storing the property as Master or In-context is the same. Hence, the property value is stored directly in the block by default.
It is possible that you would like to add this property only on this instance (occurrence) of the block, while working further in the design you might have to add more instances of this block and you would like to keep the property specific only to this instance of the block. To facilitate this, the user is provided the flexibility to change the source of the property from the default value of Master to In-context. This can easily be done by changing the default Source from the block name to the root (top) level design name. The drop down list for the Source column provides all the possible design names where the property can be stored:
In the above picture, the GEP is the hierarchical block & DDR is the top (root) level design name. By default, the NEW_PROP will have the source set as GEP, but the user can change the source to DDR to make this as an In-Context property.Adding Properties in Replicated Designs
A replicated design contains hierarchical blocks which are instantiated more than once at the top level. When you add a property to an instance in a replicated block, it is added as an In-Context (Occurrence) property by default. This means that the newly added property will have its source set to the root (top) level design. Since there are multiple instances of the block, the property being added is considered to be specific for the instance (occurrence) of the block. Hence, the property value is stored in the root (top) design by default. This property would be available only on this instance of the block and not on the other instances.Note: When you add an occurrence property on a vectored pin or aliased bus, the property will not be visible in the attribute form. It will only be visible on individual bits of the pin or bus by selecting the show index checkbox.
It is possible that you would like to add this property to all the instances of the block. To facilitate this, you have the flexibility to change the source of the property from the default value of In-context (Occurrence) to Master (block level). This can easily be done by changing the default Source from the root (top) level design name to the block name. The drop down for the Source column provides all the possible design names where the property can be stored:
The following table provides a quick summary of how you can save properties now:
When you edit an existing property value, the source with which the property was added is retained. When a Block level property is edited, it is saved as a Block level property. An Occurrence property is edited and saved as an Occurrence property. While editing properties, if you want to change the source of a Block level property to Context property , you can only change it if you have edited or changed the value. If the value is same, the property is considered a block level property. This is applicable for all components, pins, and net properties.All packaging properties are edited as Occurrence properties as per property changes in the SPB16.5 release, When a bus property is added to a whole bus in the Constraint Manager (CM) database, it gets added to the bus object. Editing the property on individual bits or partial bus would apply the change to the complete bus.If a property is applied to a partial bus, it is applied to individual bits in the Constraint Manager database. If you need to change a property value on certain bits of a bus, then it would need to be done as overrides on bus bits. A voltage property can only be edited in the block that it is added for global nets. In case you want to edit the voltage property in some other block, you can set the visibility to value and then edit the property.
Editing Existing Component Properties
On editing an existing property value, the source with which the property was added is retained. When a Block level property is edited, it is saved as a Block level property. When an Occurrence property is edited and saved as an Occurrence property. The user can also change the source of the property by making the change in the block name displayed in the Source column.
Editing Existing Signal Properties
The user can capture properties on different signals in the design. The signals in a design can be confined to one single level of hierarchy, i.e. the signals are local to the design. Some of the signals go across the deign hierarchy. These signals are interfaces at one level of hierarchy and become block ports at a higher level of hierarchy. Broadly, we’ll refer to such signals as interface signals. There’s another category of signals, which are available across the design and they are not passed around using the block interfaces. These signals are the global signals which exist at all levels of the design. In the following section, we would see how the addition of properties to these different types of signals works in the SPB 16.5 release.
Editing Existing Signal Properties Locally to a block
In a design block, a same signal can exist at multiple places on a single page, or on multiple pages. The signal can also be aliased to some other signal in the design. All in all in each of these cases, there could be one single physical net, which can exist on one or more pages of the schematic block. This single physical net would be containing all the properties for the signal and in pre-SPB 16.5 release, all these properties would be visible only in the Occurrence Edit Mode.
In SPB 16.5 release, there properties would be visible at all times on all the instances of the signal. If you add a property on a signal on one page and save that page and now go to the next page and check the properties on the same signal there, the newly added property would be visible there. You would also be able to edit this property and modify it to some new value. And on saving this schematic page, the modified value would be available in the attribute form of the signal on any other page of the design.
Adding properties to signals in a hierarchical non-replicated design
In case of hierarchical designs, a signal could be flowing across multiple hierarchical blocks. This signal would have a single physical net name and can be identified by the same all across the hierarchy. The properties on signals in hierarchical designs would work similar to how they used to operate in the single level of hierarchy. The only difference would come up in cases when there are multiple instances / occurrences of the hierarchal block.
In such a case, for each of the hierarchal blocks, the signal would be having a unique physical net name and hence properties which are specific to that instance or occurrence of the signal can be different. There could also be some properties captured on the signal as the block level properties and these properties would be available on the signal in all instances or occurrences of the hierarchal block.
All Block level or Occurrence properties are deleted from the source. But, in a scenario where you have both an Occurrence and Block level property on a component, pin or net, and you delete the Occurrence property, the row from the attribute form does not get deleted. The Block level property is rippled to that row. At the same time if you want to delete the block level property, you cannot delete it immediately because the delete button is deactivated. You need to press OK and save the design. After saving the design, if you reopen the Attribute form, the delete button is enabled and you can delete the Block Level property.
Important: Since this stuff is important and prone to confusion, please go through the Lab and implement the step-by-step methodology to get a feel of how this functionality works in the tool.
Please share your experiences with this new 16.5 capability.
Jerry "GenPart" Grzenia