Weights update process

The process of updating weights is one training iteration involving backpropagation. The latter can be broken down into 4 distinct steps:

  • Forward pass

In this first training step, the intention is to extract weight from the first pass of the training data into the neural network.

  • Loss function

The training loss (precision) is calculated from a loss function, e.g mean square error. On the first iteration, the loss will be high. Then, iteration after iteration, the neural network learns and the training loss (difference) between the prediction label and training label decreases.

  • Backward pass

To achieve a minimum loss, the weights need to be adjusted by taking a derivative of the loss with respect to the weights.

  • Weight update

The weights of each layer are then updated accordingly with the calculated weights from the training iterations.

Clock concurrent optimization

Since Cadence added Azuro’s ccopt by default in SOC Encounter, I think it is time to look deeper in this clock concurrent optimization. The latter was initiated by a company called Azuro which was then acquired by Cadence in July 2012.

Clock concurrent optimization merges clock tree synthesis (CTS) with physical optimization, simultaneously building clocks and optimizing logic delays based directly on a propagated clocks model of timing. Thus, the clock tree synthesis (CTS) becomes timing-driven and tightly coupled with placement and  logic sizing. This is different from traditional techniques of sequential optimization and useful skew.

CTS is done by combining the benefits of pre-route layer-aware optimization and useful skewing.

Buffer insertion is not only done to just reduce the skew but also to do time borrowing and to improve the overall speed of the design.

What is the benefits of using CCopt ?

  • Increased chip speed or reduced chip area and power
  • Reduced IR drop

Why use path_adjust ?

path_adjust is used to either relax or tighten the timing constraints (even though defined by path_delay).

e.g to relax the constraints by 100ps

rc:>/ path_adjust -from [all_inputs] -to [all_outputs] -delay 100 -name pa_i2o

e.g to tighten the constraints by 100ps

rc:>/ path_adjust -from [all_inputs] -to $all_registers -delay 100 -name pa_i2r

path_adjust is thus use to guide RTL Compiler to concentrate and focus on register to register timing instead of optimizing inputs to output paths.

When such path_adjust exceptions are created there are located at /designs/my_design/timing/exceptions/path_adjust.

AlexOrr’s first 100 days in formal-land

This weekend, I caught up with a presentation from @AlexOrr of Broadcom in which he talks about his “first 100 days in formal-land”.

I wanted to read it for a very long time. After reading the slides offline, I felt that this presentation was worth attending in person.

Within those slides, one can feel his experience and his desire to share it with the Design And Verification Engineer (DAVE) community.

@AlexOrr’s presentation is from #JUG2015. Blog posts related to Jasper User Group 2015 can be found here.

There are two items from his presentation I was repeating for a long time to my peers: Assertions and Jenkins. It is good to hear someone else is emphasizing on them as well.


Below are some key takeaways from Alex’s presentation. They are not new. However, they should be reminded over and over again.

Assumptions become assertions in simulation.

Do I have to retest all the reset values over and over again ?

I assume he was hinting at UVM built-in sequence uvm_reg_hw_reset_seq.

Assertions more portable than dynamic tests.

Use assertions, path spoilers, monitors, and/or illegal_bins statements. As well as $past.

Leverage “SuperLint” apps such as X-Prop.