Hi everyone, just a quick heads-up regarding tomor...
# ieee-sscs-dc-21q3
b
Hi everyone, just a quick heads-up regarding tomorrow's meetup. Unless there are other things to discuss (please suggest on this thread), we will do a final check on design mergers. Below is the snapshot from last week, please let me know in case there are any corrections. Also, please coordinate within each team on who will be the tapeout lead (i.e. who will submit the combined final design). Let's finalize tomorrow...
k
Hi Boris, than You for keeping us up to date. I have mentioned it last week that would be great to have some talk or walk through example on Static Timing Analysis using OpenLane. Thank You
b
@mehdi, do you know some resources (or someone knowledgeable) for STA?
m
@Tom Spyrou Do you think you can provide some help openSTA usage etc.. @Boris Murmann I can help but might be tight to prepare something for tomorrow. I can do a quick walk through tomorrow
๐Ÿ‘ 1
@mkk @mshalan ^
@Krzysztof Herman maybe we could go over your design at some point and see the timing reports etc?
k
of course
@mehdi however I do not know if You have some time today for a short meeting just to take a look on the constrains
m
sure, let's shoot for 7pm EST
k
ok, cool I will send You the zoom link
m
I am happy to help with STA
โœ… 1
๐Ÿ™Œ 1
k
Hi @mshalan will it be possible that You join the meeting at 7 pm EST ?
m
Hi @Krzysztof Herman, it will be too late for me. I am in EET zone. Typically, I am available till 2:00PM EST
k
ok, understood. In fact I am having some problems with STA analysis within the OpenLane. I have some hold violations that worries me and I do not know how to mitigate it. The other thing is that I would like to setup a multicycle paths because I have some Clock Enable signals in my datapaths. Until know I have no success with that issue
t
For opensta there is a good pdf in the repo. In terms of hold fixing, you can add the slack margin command to all repair commands to over fix by an additional margin. You can also modify the sdc with additional clock uncertainty to add guardband. OpenSTA does not do SI analysis so some guardbanding should be applied.
k
@Tom Spyrou thank You for the tips
t
For the multicycle paths there is an sdc command set_multicycle_path. Read the pdf carefully to set the correct relationship. Its complicated in multi clock designs and paths.
k
In fact my design uses some clock enables derived from the main clock what implies multicycle operation
one of he question I have is that I am not sure how to setup the multicycle STA, I try to do this
Copy code
set_multicycle_path 5 -setup  -from [get_ports X_i] -to [get_ports Y_o]
where my module
Copy code
module test  
  (
    input         clk,
    input         rst,
    input         en,
    input  signed [15:0] X_i,
    input  signed [15:0] b0,
    input  signed [15:0] b1,
    output signed [15:0] Y_o
);
I am not sure if I should use X_i and Y_o or dive into the gate level netlist looking for the corresponding FF
t
If you do report_check from to those ports you should see the required time increase after the mcp is applied. If there are no registers in the block be sure to use a virtual clock to constrain the ports. A virtual clock is a clock created not applied to any port in the design. I recommend reading the synopsys sdc spec or getting a book on sdc or design compiler.
k
I am currently reading the documents related to PrimeTIme
t
The best way to determine the points to apply the mcp in is to look at the path report where you want to modify the required time and create an mcp based on the start and endpoint in the report. Mcp will not work if it straddles a register. It must be between registers or between a register and a port. Thise are known as startpoints and endpoints. You can also use the through option of mcp which can be very convenient.
k
ok, great, I will try it out
c
We are planning to merge with USA-1 and USA-4 at this point (@User @User). That way USA-1, USA-3, and USA-4 will be on the same chip. We decreased the required GPIO of our project and we believe that the necessary modifications have been made so that we can share the chip. We have not determined a tapeout lead between us yet, sorry.
๐Ÿ‘ 5
r
I am the team lead of India#3 team. We had a discussion with India#1 and India#2 teams. We feel that if the designs of India#1, India#2 and India#3 teams are merged, it will be helpful since we are all from the same group. India#3 would then take the responsibility of merging all the three designs before final submission of GDSII.
b
Sounds good. We just need a home for the Egypt design then. @Hisham ElReedy
o
@Boris Murmann we are talking to the Egypt design team @Hisham ElReedy and planning to integrate our designs together. USA-2 team will reduce the area and confirm them by 23rd October and we'll work together to figure out who'll be the tape out lead.
b
Excellent, thanks!