Home > Community > Blogs > PCB Design > what s good about property changes in dehdl the secret s in the 16 5 release
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the PCB Design blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

What's Good About Property Changes in DEHDL? The Secret's in the 16.5 Release!

Comments(0)Filed under: Design Entry HDL, ConceptHDL, Constraint Manager, Allegro, Schematic, PCB, Design Entry, Allegro Design Entry, design, SPB16.5, Allegro 16.5, hierarchy, hierarchical schematics, flat schematics, electrical constraints, uprev, property changes

In the 16.5 release, all connectivity changes are stored in the hierarchical block directly in Design Entry HDL (DEHDL). Connectivity changes are basically additions or modifications of components, nets, and pin-net connections. The behavior remains the same as in the pre-16.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. Essentially, we’ve simplified the approach for adding properties within and across hierarchical blocks.

Read on for more details


With the 16.5 release, the Occurrence Edit mode no longer exists and the opf file information is no longer generated. This portion of the DEHDL 16.5 release is the most important change. It is important to understand the concept thoroughly.

When a designer 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-16.5 releases, the designer was able to do this only in Hierarchy mode.

When the designer 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-16.5 releases, this level of change was stored in the opf file in the Occurrence Edit mode. In the 16.5 release, this property is stored on the instance in context of the root (top) level design.

Important: With the 16.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 16.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 16.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-16.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-16.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 designer 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 and DDR is the top (root) level design name. By default, the NEW_PROP will have the source set as GEP, but the designer 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:

Design

Default property selected

Options to save

Flat Design

Block Level property

Block Level

Non-Replicated design

Block Level property

Block Level or Occurrence Level

Replicated design

Occurrence (In-Context) property

Block Level or Occurrence Level

 

Editing Existing Properties

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 16.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, it is saved as an Occurrence property. The designer 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 designer 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 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. 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-16.5 releases, all these properties would be visible only in the Occurrence Edit Mode. In the 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 name 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 have 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 hierarchical block.

Deleting Properties

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.

Please share your feedback using this significant new working model in DEHDL.

Jerry "GenPart" Grzenia

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.