[The Conversation Africa] South Africa's finance minister, Enoch Godongwana, announced in his October mid-term budget policy statement that cabinet had approved funding for an early retirement programme to reduce the public sector wage bill. R11 billion (about US$627 million) will be allocated over the next two years to pay for the exit costs of 30,000 civil servants while retaining critical skills and promoting the entry of younger talent.

[SAnews.gov.za] With the United Nations Framework Convention on Climate Change (COP29) taking place this week, South Africa expects the COP29 Presidency to enhance efforts to finalise the New Collective Quantified Goal on Finance (NCQG), which is a matter of great importance for developing economies.

[COSATU] The Congress of South African Trade Unions (COSATU) is deeply concerned by the Minister for Communications and Digital Technologies, Mr. S. Malatsi's sudden withdrawal of the South African Broadcasting Corporation (SABC) SOC Ltd Bill from Parliament where it was being engaged upon by the National Assembly's Portfolio Committee: Communications and Digital Technologies.

[DA] It is a national embarrassment that the inability of the City of Johannesburg to supply water to its residents, business and public sector offices, has now led to the shutdown of operations at the Constitutional Court, on Constitution Hill in Braamfontein.

PCI-SIG DevCon 2024 – 32^nd Anniversary

For more than a decade, Cadence has been well-known in the industry for its strong commitment and support for PCIe technology. We recognize the importance of ensuring a robust PCIe ecosystem and appreciate the leadership PCI-SIG provides. To honor the 32^nd anniversary of the PCI-SIG Developer’s Conference, Cadence is announcing a complete PCIe 7.0 IP solution for HPC/AI markets.

Why Are Standards Like PCIe So Important?

From the simplest building blocks like GPIOs to the most advanced high-speed interfaces, IP subsystems are the lifeblood of the chipmaking ecosystem. A key enabler for IP has been the collaboration between industry and academia in the creation of standards and protocols for interfaces. PCI-SIG drives some of the key definitions and compliance specifications and ensures the interoperability of interface IP.

HPC/AI markets continue to demand high throughput, low latency, and power efficiency. This is fueling technology advancements, ensuring the sustainability of PCIe technology for generations to come. As a close PCI-SIG member, we gain valuable early insights into the evolving specs and the latest compliance standards. PCIe 7.0 specifications and beyond will enable the market to scale, and we look forward to helping our customers build best-in-class cutting-edge SoCs using Cadence IP solutions.

Figure 1. Evolution of PCIe Data Rates (source PCI-SIG)

What’s New This Year at DevCon?

At DevCon ’24, the PCIe 7.0 standard will take center stage, and Cadence is showing off a full suite of IP subsystem solutions for PCIe 7.0 this year.

What Sets Cadence Apart?

At Cadence, we believe in building a full subsystem for our testchips with eight lanes of PHY along with a full 8-lane controller. Adding a controller to our testchip significantly increases the efficiency and granularity in characterization and stress testing and enables us to demonstrate interoperability with real-world systems. We are also able to test the entire protocol stack as an 8-lane solution that encompasses many of the applications our customers use in practice. This approach significantly reduces the risks in our customers’ SoC designs.

Figure 2: Piper - Cadence PHY IP for PCIe 7.0

Figure 3: Industry’s first IP subsystem for PCIe 7.0

Which Market Is This For?

At a time when accelerated computing has gone mainstream, PCIe links are going to take on a role of higher importance in systems. Direct GPU-to-GPU communication is crucial for scaling out complex computational tasks across multiple graphics processing units (GPUs) or accelerators within servers or computing pods. There is a growing recognition within the industry of a need for scalable, open architecture in high-performance computing. As AI and data-intensive applications evolve, the demand for such technologies will likely increase, positioning PCIe 7.0 as a critical component in the next generation of interface IP.

Here's a recent article describing a potential use case for PCIe 7.0.

Figure 4: Example use case for PCIe 7.0

Why Are Optical Links Important?

It takes multiple buildings of data centers to train AI/ML models today. These buildings are increasingly being distributed across geographies, requiring optical fiber networks that are great at handling the increased bandwidth over long distances. However, these optical modules soon hit a power wall where all the budgeted power is used to drive the signal from point A to point B, and there is not enough power left to run the actual CPUs and GPUs. Such scenarios create a need for non-retimed, linear topologies. Linear Pluggable Optics (LPO) links can significantly reduce module power consumption and latency when compared to traditional Digital Signal Processing (DSP) based retimed optical solutions, which is critical for accelerating AI performance. Swapping from DSP-based solutions to LPO results in significant cost savings that help drive down expenditure due to lower power and cooling requirements, but this requires a robust high-performance ASIC to drive the optics rather than retimers/DSP.

To showcase the robustness of Cadence IP, we have demonstrated that our subsystem testchip board for PCIe 7.0 can successfully transmit and receive 128GT/s signals through a non-retimed opto-electrical link configured in an external loopback mode with multiple orders of margin to spare.

Figure 5: Example of ASIC driving linear optics

Compliance Is Key

For PCIe 6.0, the official compliance program has not started yet; this is typical for the SIG where the official compliance follows a few years after the spec is ratified to give enough time for the ecosystem to have initial products ready, and for test and equipment vendors to get their hardware/software up and running. At this time, PCIe Gen6 implementations can only be officially certified up to PCIe 5.0 level (the highest official compliance test suite that the SIG supports). We have taken our PCIe 6.0 IP subsystem solution to the SIG for multiple process nodes, and they are all listed as compliant. You can run this query on the pcisig.com website under the Developers->Integrators list by making the following selections:

Due to space limitations, not all combinations could be tested at the May workshop (e.g., N3 root port) – this will be tested in the next workshop.

Also, the SIG just held an “FYI” compliance event this week to bring together the ecosystem for confidential testing (no results were reported, and data cannot be shared outside without violating the PCI-SIG NDA). We participated in the event with multiple systems and can report that our systems have done quite well. The test ecosystem is not mature yet, and a few more FYI workshops will be conducted before the official compliance for 6.0 is launched. We have collaborated with all the key test vendors for electrical and protocol testing throughout the year. As early as the middle of last year, we were able to provide test cards to all these vendors to demo PCIe 6.0 capabilities in their booths at various events. Many of them recorded these videos, and they can be found online.

• Cadence Subsystem IP for PCIe 6.0: Protocol and Electrical Testing
• Cadence Subsystem IP for CXL Protocol Test Demo
• Cadence Subsystem IP for CXL2.0/3.0 Protocol Test Demo
• Cadence Subsystem IP for PCIe 6.0: Protocol Stack Demo

More at the PCI-SIG Developers Conference

Check us out at the PCI-SIG Developer’s conference on June 12 and 13 to see the following demonstrations:

• Robust performance of Cadence IP for PCIe 7.0 transmitting and receiving 128GT/s signals over non-retimed optics
• Capabilities of Cadence IP for PCIe 7.0 measured using oscilloscope instrumentation detailing its stable electrical performance and margin
• The reliability of Cadence IP for PCIe 6.0 interface using Test Equipment to characterize the PHY receiver quality
• A PCI-SIG-compliant Cadence IP subsystem for PCIe 6.0 optimized for both power and performance

As a leader in PCI Express, Anish Mathew of Cadence will share his valuable insights on an important topic: “Impact of UIO ECN on PCIe Controller Design and Performance,” highlighting the strides made by the Cadence design team in achieving this implementation.

Figure 6: Cadence UIO Implementation Summary

Summary

Cadence showcased PCIe 7.0-ready IP at PCI-SIG Developers Conference 2023 and continues to lead in PCIe IP development, offering complete solutions in advanced nodes for PCIe 7.0 that will be generally available early next year. With a full suite of solutions encompassing PHYs, Controllers, Software, and Verification IP, Cadence is proud to be a member of the PCI-SIG community and is heavily invested in PCIe. Cadence was the first IP provider to bring complete subsystem solutions for PCIe 3.0, 4.0, 5.0, and 6.0 with industry-leading PPA and we are proud to continue this trend with our latest IP subsystem solution for PCIe 7.0, which sets new benchmarks for power, performance, area, and time to market.

Cadence tapes out 32G UCIe interface IP for high speed, highly efficient chiplet designs and demonstrate high data rate performance in TSMC's 3nm technology(read more)

I am trying to install IC231 on RHEL 8 using installscape, however configuring keeps failing.

I tried to run the configuration file manually as suggested in one of the previous posts and it gives me following errors:

sh batch_configure.sh
/home/rs/cadence/installs/IC231/install/tmp/slconfig.sh: line 165: xterm: command not found
cat: ncvhdl23.03-d103lnx86_101124125631.stat: No such file or directory
rm: cannot remove 'ncvhdl23.03-d103lnx86_101124125631.stat': No such file or directory
/home/rs/cadence/installs/IC231/install/tmp/slconfig.sh: line 165: xterm: command not found
cat: ncvhdl64b23.03-d103lnx86_101124125631.stat: No such file or directory
rm: cannot remove 'ncvhdl64b23.03-d103lnx86_101124125631.stat': No such file or directory
/home/rs/cadence/installs/IC231/install/tmp/slconfig.sh: line 165: xterm: command not found
cat: oaRedist22.61-p003lnx86_101124125631.stat: No such file or directory
rm: cannot remove 'oaRedist22.61-p003lnx86_101124125631.stat': No such file or directory
/home/rs/cadence/installs/IC231/install/tmp/slconfig.sh: line 165: xterm: command not found
cat: amsEnv64b23.10-p043lnx86_101124125631.stat: No such file or directory
rm: cannot remove 'amsEnv64b23.10-p043lnx86_101124125631.stat': No such file or directory
/home/rs/cadence/installs/IC231/install/tmp/slconfig.sh: line 165: xterm: command not found
cat: ihdl64b23.10-p043lnx86_101124125631.stat: No such file or directory
rm: cannot remove 'ihdl64b23.10-p043lnx86_101124125631.stat': No such file or directory

I am not very well versed with Linux at the moment but trying. Could any one suggest something or point to what is missing?

Hi! 

I am attempting to create a very simple test pcell that contains a single Nmos 4 terminal device (Gate, Source, Drain, Backgate). However, unlike other devices I have used in the past, the backgate terminal of the device I wish to include within the pcell is an inherited connection, and the other 3 are physical terminals. Note that for the pcell master, I do not want any inherited connections, just physical pins. Hence I need to drive this inherited connection with a pin within my pcell. I started implementing the symbol and schematic first, ensuring I could obtain the correct connectivity, extract netlist, etc. I thought I had it hooked up correctly, but alas I am failing to export the CDL. Let me explain my current approach.

Schematic:

Create the 4 physical pins using a combination of dbCreateInst (for the pin isnt), dbMakeNet, dbCreateTerm and dbCreatePin.

Create the device instance using dbCreateInstByMasterName and setting the desired cdf parameters + callbacks.

For the physical terminals of the device, I'm using dbCreateConnByName to make the connection to the appropriate net that was created above.

For the inherited connection, I am creating a netSet property like so: dbCreateProp(newinst deviceTermName "netSet" netName)

Symbol:

Create the 4 physical pins using a combination of dbCreateRect, dbMakeNet, dbCreateTerm, dbCreatePin.

And then create whatever symbol design I wish using the likes of dbCreateRect, dbCreateLine, etc. 

Everything works fine when using a device without an inherited connection, so I'm guessing I'm missing something along this line... Also, if I copy the contents of the pcell schematic to a regular schematic view, do a check and save, the view extracts just fine. So I wonder if the check and save it fixing the connectivity that I may not have. 

Thanks for any possibly engagement or suggestions 🙂

Keelan

Hi All,

I'm using a code (abConvertPolygonToPath.ils) that I found in other posts to convert a rect object to a path object inside a pcell code, but when I try to run a DRC, the layout export fails due to a warning message, here is the log message

*WARNING* (DB-270001): Pcell evaluation for 18A_asaavedr/lay_mesh_BM0_BM4_3p6_3p6/layout has the following error(s):

*WARNING* (DB-270002): ("eval" 0 t nil ("*Error* eval: undefined function" abConvertPolygonToPath))

ERROR (XOASIS-231): Pcell evaluation failed for '18A_asaavedr/lay_mesh_BM0_BM4_3p6_3p6/layout' because the Pcell SKILL code contains either a syntax error or an unsupported XOasis function. Check the standard output or the Virtuoso log file for more information. Cadence recommends correcting the Pcell SKILL code to resolve the issue. However, to ignore these errors and continue the translation, you may use the 'ignorePcellEvalFail' option.

INFO (XOASIS-282): Translation Failed. '1' error(s) and '3' warning(s) found.

And when compile the code I get the following message:

*WARNING* defgeneric function already defined - abConvertPolygonToPath

I will aprreciate any help in how to waive this error, or fix it.

Thank you

Hello,

I was looking to destructively and efficiently modify a list that was passed in as an argument to a procedure, by prepending an item to the list.

I noticed that cons lets you do this efficiently, but the operation is non-destructive. Hence this wouldn't work if you are trying to modify a function's list parameter in place.

Here is an example of trying to add "0" to the front of a list:

Microwave Office is Cadence’s tool-of-choice for RF and microwave designers designing everything from III-V 5G chips, to RF systems in board and package technologies. These types of designs require close interaction between the schematic and its layout. A new Training Byte demonstrates how the schematic-layout connections is built into Microwave Office.(read more)

Hello All:

I am looking for help on the following, as I am new to Cadence tools [I have to use Cadence Innovus for Physical Design after Logic Synthesis using Synopsys Design Compiler, using Nangate 45 nm Open Cell Library]: while using Cadence Innovus, I would need to select a few specific nets to be routed through a specific metal layer. How can I do this on Innovus [are there any command(s)]? Also, would writing and sourcing a .tcl script [containing the command(s)] on the Innovus terminal after the Placement Stage of Physical Design be fine for this?

Secondly, is there a way in Innovus to manipulate layout components, such as changing some pin placements, wire directions (say for example, wire direction changed to facing east from west, etc.) or moving specific closely placed cells around (without violating timing constraints of course) using any command(s)/.tcl script? If so, would pin placement changes and constraining some closely placed cells to be moved apart be done after Floorplanning/Powerplanning (that is, prior to Placement) and the wire direction changes be done after Routing? 

While making the necessary changes, could I use the usual Innovus commands to perform Physical Design of the remaining nets/wires/pins/cells, etc., or would anything need modification for the remaining components as well?

I would finally need to dump the entire design containing all of this in a .def file.

I tried looking up but could only find matter on Virtuoso and SKILL scripting, but I'd be using Innovus GUI/terminal with Nangate 45 nm Open Cell Library. I know this is a lot, but I would greatly appreciate your help. Thanks in advance.

Riya

Hi Cadence & forumers, 

I am running a conformal LEC with a flattened netlist against RTL. 

The run hang for 5 days at the "analyze abort" step which is automatically launched by the compare. 

The netlist is flattened at some levels so hierarchical flow which I tried didn't help much. The flattened/highly optimized netlist is from customer and the ultimate goal. How shall I proceed now? 

On the a side note, a test run with a hierarchical netlist from a simple DC "compile -map_effort medium" command finished after 1 day or so. 

Thank you! 

// Command: vpx compare -verbose -ABORT_Print -NONEQ_Print -TIMEstamp
// Starting multithreaded comparison ...
Comparing 241112 points in parallel.

// Multithreading Overhead: 38% Gates: 8501606/6168138
// Multithreaded processing completed.
================================================================================
Compared points PO DFF DLAT BBOX CUT Total
--------------------------------------------------------------------------------
Equivalent 1025 241638 30 75 21 242789
--------------------------------------------------------------------------------
Abort 0 124 0 0 0 124
================================================================================
Compare results of instance/output/pin equivalences and/or sequential merge
================================================================================
Compared points DFF Total
--------------------------------------------------------------------------------
Equivalent 204 204
================================================================================
// Warning: 512 DFFs/DLATs have 1 disabled clock port: skipped data cone comparison
// Resolving aborts by analyze abort...

Below is showing my Master.v

********************************************************************************************************************************************************************************************************************

///////ALU
module ALU (
    input [31:0] A,B,
    input[3:0] alu_control,
    output reg [31:0] alu_result,
    output reg zero_flag
);
    always @(*)
    begin
        // Operating based on control input
        case(alu_control)

        4'b0001: alu_result = A+B;
        4'b0010: alu_result = A-B;
        4'b0011: alu_result = A*B;
        4'b0100: alu_result = A|B;
        4'b0101: alu_result = A&B;
        4'b0110: alu_result = A^B;
        4'b0111: alu_result = ~B;
        4'b1000: alu_result = A<<B;
        4'b1001: alu_result = A>>B;
        4'b1010: begin
            if(A<B)
            alu_result = 1;
            else
            alu_result = 0;
        end
        default: alu_result = A+B;

        endcase

        // Setting Zero_flag if ALU_result is zero
        if (alu_result)
            zero_flag = 1'b1;
        else
            zero_flag = 1'b0;   
    end
endmodule


/////CONTROL UNIT
/*
Control unit controls takes opcode, funct7, funct3 of the instruction code to determine
and control regwrite in IFU, alu control in ALU to execute proper instruction
*/
/*
Control unit controls takes opcode, funct7, funct3 of the instruction code to determine
and control regwrite in IFU, alu control in ALU to execute proper instruction
*/
module CONTROL(
    input [4:0] opcode,
    output reg [3:0] alu_control,
    output reg regwrite_control,memread_control,memwrite_control
);
    always @(opcode)
    begin
       case(opcode)
        5'b00001: begin alu_control=4'b0001;  //add
        regwrite_control=1; memread_control=0; memwrite_control=0;
        end
        5'b00010: begin alu_control=4'b0010;  ///sub
        regwrite_control=1; memread_control=0; memwrite_control=0;
        end
        5'b00011: begin alu_control=4'b0011;  //mul
        regwrite_control=0; memread_control=0; memwrite_control=1;
        end
        5'b00100: begin alu_control=4'b0100;  ///OR
        regwrite_control=0; memread_control=0; memwrite_control=1;
        end
        5'b00101: begin alu_control=4'b0101;  ///AND
        regwrite_control=1; memread_control=0; memwrite_control=0;
        end
        5'b00110: begin alu_control=4'b0110;  ///XOR
        regwrite_control=0; memread_control=0; memwrite_control=1;
        end
        5'b00111: begin alu_control=4'b0111;  ///NOT
        regwrite_control=0; memread_control=0; memwrite_control=1;
        end
        5'b01000: begin alu_control=4'b1000;  //SL
        regwrite_control=1; memread_control=1; memwrite_control=0;
        end
        5'b11001: begin alu_control=4'b1001;  //SR
        regwrite_control=1; memread_control=1; memwrite_control=0;
        end
        5'b01010: begin alu_control=4'b1010;  //COMPARE
        regwrite_control=1; memread_control=1; memwrite_control=0;
        end
        //5'b11010: begin ALU_control=4'b0000;  //SW
        //regwrite_control=1; memread_control=0; memwrite_control=0;
        //end
        //5'b01010: begin ALU_control=4'bxxxx;  //LW
        //regwrite_control=0; memread_control=0; memwrite_control=1;
        //end
        default : begin alu_control = 4'b0001;
        regwrite_control=1; memread_control=0; memwrite_control=0;
        end
        endcase  
    end
endmodule



//////DATA MEMORY
module Data_Mem(
input clock, rd_mem_enable, wr_mem_enable,
input [11:0] address,
input [31:0] datawrite_to_mem,
output reg [31:0] dataread_from_mem );

reg [31:0] Data_Memory[8:0];

initial begin
    Data_Memory[0] = 32'hFFFFFFFF;
    Data_Memory[1] = 32'h00000001;
    Data_Memory[2] = 32'h00000005;
    Data_Memory[3] = 32'h00000003;
    Data_Memory[4] = 32'h00000004;
    Data_Memory[5] = 32'h00000000;
    Data_Memory[6] = 32'hFFFFFFFF;
    Data_Memory[7] = 32'h00000000;
    //Data_Memory[8] = 32'h00000008;
    //Data_Memory[9] = 32'h00000009;
    //Data_Memory[10] = 32'h0000000A;
    //Data_Memory[11] = 32'h0000000B;
    //Data_Memory[12] = 32'h0000000C;
    //Data_Memory[13] = 32'h0000000D;
    //Data_Memory[14] = 32'h0000000E;
    //Data_Memory[15] = 32'h0000000F;
    //Data_Memory[16] = 32'h00000010;
    //Data_Memory[17] = 32'h00000011;
    //Data_Memory[18] = 32'h00000012;
    //Data_Memory[19] = 32'h00000013;
    //Data_Memory[20] = 32'h00000014;
    //Data_Memory[21] = 32'h00000015;
    //Data_Memory[22] = 32'h00000016;
    //Data_Memory[23] = 32'h00000017;
    //Data_Memory[24] = 32'h00000018;
    //Data_Memory[25] = 32'h00000019;
    //Data_Memory[26] = 32'h0000001A;
    //Data_Memory[27] = 32'h0000001B;
    //Data_Memory[28] = 32'h0000001C;
    //Data_Memory[29] = 32'h0000001D;
    //Data_Memory[30] = 32'h0000001E;
    Data_Memory[31] = 32'h0000001F;
       
    end
    always@(posedge clock) begin
       if(wr_mem_enable) begin
            Data_Memory[address] <= datawrite_to_mem;
       end
       else if(rd_mem_enable) begin
               dataread_from_mem <= Data_Memory[address];
       end
       else begin
               dataread_from_mem <= 32'h00000000;
       end
    end
endmodule   



/////INST MEM
/*

*/
module INST_MEM(
    input [31:0] PC,
    input reset,
    output [31:0] Instruction_Code
);
    reg [7:0] Memory [43:0]; // Byte addressable memory with 32 locations

    
    assign Instruction_Code = {Memory[PC+3],Memory[PC+2],Memory[PC+1],Memory[PC]};

    
    
    initial begin
            // Setting 32-bit instruction: add t1, s0,s1 => 0x00940333
            Memory[3] = 8'b0000_0000;
            Memory[2] = 8'b0000_0001;
            Memory[1] = 8'b0111_1100;
            Memory[0] = 8'b0000_0001;
            // Setting 32-bit instruction: sub t2, s2, s3 => 0x413903b3
            Memory[7] = 8'b0000_0000;
            Memory[6] = 8'b0000_0110;
            Memory[5] = 8'b1000_1111;
            Memory[4] = 8'b1110_0010;
            // Setting 32-bit instruction: mul t0, s4, s5 => 0x035a02b3
            Memory[11] = 8'b0000_0000;
            Memory[10] = 8'b0000_0101;
            Memory[9] = 8'b0111_1100;
            Memory[8] = 8'b0000_0011;
            // Setting 32-bit instruction: or t3, s6, s7 => 0x017b4e33
            Memory[15] = 8'b1111_1111;
            Memory[14] = 8'b1111_0100;
            Memory[13] = 8'b1010_0000;
            Memory[12] = 8'b1010_0100;
            // Setting 32-bit instruction: and
            Memory[19] = 8'b0000_0000;
            Memory[18] = 8'b0010_1001;
            Memory[17] = 8'b0001_1101;
            Memory[16] = 8'b0010_0101;
            // Setting 32-bit instruction: xor
            Memory[23] = 8'b0000_0000;
            Memory[22] = 8'b0001_1000;
            Memory[21] = 8'b0000_1101;
            Memory[20] = 8'b0110_0110;
            // Setting 32-bit instruction: not
            Memory[27] = 8'b0000_0000;
            Memory[26] = 8'b0010_1001;
            Memory[25] = 8'b0011_1101;
            Memory[24] = 8'b1100_0111;
            // Setting 32-bit instruction: shift left
            Memory[31] = 8'b0000_0000;
            Memory[30] = 8'b0101_0111;
            Memory[29] = 8'b1100_0110;
            Memory[28] = 8'b0000_1000;
            // Setting 32-bit instruction: shift right
            Memory[35] = 8'b0000_0000;
            Memory[34] = 8'b0110_1010;
            Memory[33] = 8'b1101_0010;
            Memory[32] = 8'b0111_1001;
            /// Setting 32-bit instruction: Campare
            Memory[39] = 8'b0000_0000;
            Memory[38] = 8'b0111_1010;
            Memory[37] = 8'b1101_0010;
            Memory[36] = 8'b0110_1010;
            /// Setting 32-bit instruction:
            Memory[43] = 8'b0000_0000;
            Memory[42] = 8'b0111_0111;
            Memory[41] = 8'b1101_0010;
            Memory[40] = 8'b0111_0010;
        end
   

endmodule

//IFU
/*
The instruction fetch unit has clock and reset pins as input and 32-bit instruction code as output.
Internally the block has Instruction Memory, Program Counter(P.C) and an adder to increment counter by 4,
on every positive clock edge.
*/
module IFU(
    input clock,reset,
    output [31:0] Instruction_Code
);
reg [31:0] PC = 32'b0;  // 32-bit program counter is initialized to zero

    
    always @(posedge clock, posedge reset)
    begin
        if(reset == 1)  //If reset is one, clear the program counter
        PC <= 0;
        else
        PC <= PC+4;   // Increment program counter on positive clock edge
    end
    // Initializing the instruction memory block
    INST_MEM instr_mem(.PC(PC),.reset(reset),.Instruction_Code(Instruction_Code));

endmodule


///MUX

module Mux_2X1 (
    input mem_rd_select, // rd_mem_enable
    input wire [31:0] dataread_from_mem, regdata2,

    output reg [31:0] mux_out
);

always @(mem_rd_select or dataread_from_mem or regdata2) begin
    if (mem_rd_select == 1)
        mux_out <= dataread_from_mem ;
    else
        mux_out <= regdata2;
    end
endmodule

//DFlipFlop
module DFlipFlop(D,clock,Q);
input D; // Data input
input clock; // clock input
output reg Q; // output Q
always @(posedge clock)
begin
 Q <= D;
end
endmodule

///DATA path


module DATAPATH(
    input [4:0]Read_reg_add1,
    input [4:0]Read_reg_add2,
    input [4:0]Reg_write_add,
    input [3:0]Alu_control,
    input [11:0]Address,
    input Wr_reg_enable,Wr_mem_enable,Rd_mem_enable,
    input clock,
    input reset,
    output OUTPUT
    );

    // Declaring internal wires that carry data
    wire zero_flag;
    wire [31:0]Dataread_from_mem;
    wire [31:0]read_data1;
    wire [31:0]read_data2;
    wire [31:0]Mux_out;
    wire [31:0]Alu_result;
    //wire [31:0]datawrite_to_reg;

    // Instantiating the register file
    REG_FILE reg_file_module(.reg_read_add1(Read_reg_add1),.reg_read_add2(Read_reg_add2),.reg_write_add(Reg_write_add),.datawrite_to_reg(Alu_result),.read_data1(read_data1),.read_data2(read_data2),.wr_reg_enable(Wr_reg_enable),.clock(clock),.reset(reset));

    // Instanting ALU
    ALU alu_module(.A(read_data1), .B(Mux_out), .alu_control(Alu_control), .alu_result(Alu_result), .zero_flag(zero_flag));
    
    //Mux
    Mux_2X1 mux(.mem_rd_select(Rd_mem_enable),.dataread_from_mem(Dataread_from_mem),.regdata2(read_data2),.mux_out(Mux_out));

    //Data Memory
    Data_Mem DM(.clock(clock),.rd_mem_enable(Rd_mem_enable),.wr_mem_enable(Wr_mem_enable),.address(Address),.datawrite_to_mem(Alu_result),.dataread_from_mem(Dataread_from_mem));
    
    // Dflipflop
    DFlipFlop DF (.D(zero_flag), .Q(OUTPUT),.clock(clock));
endmodule


/*
A register file can read two registers and write in to one register.
The RISC V register file contains total of 32 registers each of size 32-bit.
Hence 5-bits are used to specify the register numbers that are to be read or written.
*/

/*
Register Read: Register file always outputs the contents of the register corresponding to read register numbers specified.
Reading a register is not dependent on any other signals.

Register Write: Register writes are controlled by a control signal RegWrite.  
Additionally the register file has a clock signal.
The write should happen if RegWrite signal is made 1 and if there is positive edge of clock.
*/
module REG_FILE(
    input [4:0] reg_read_add1,
    input [4:0] reg_read_add2,
    input [4:0] reg_write_add,
    input [31:0] datawrite_to_reg,
    output [31:0] read_data1,
    output [31:0] read_data2,
    input wr_reg_enable,
    input clock,
    input reset
);

    reg [31:0] reg_memory [31:0]; // 32 memory locations each 32 bits wide
    
    initial begin
        reg_memory[0] = 32'h00000000;
        reg_memory[1] = 32'hFFFFFFFF;
        reg_memory[2] = 32'h00000002;
        reg_memory[3] = 32'hFFFFFFFF;
        reg_memory[4] = 32'h00000004;
        reg_memory[5] = 32'h01010101;
        reg_memory[6] = 32'h00000006;
        reg_memory[7] = 32'h00000000;
        reg_memory[8] = 32'h10101010;
        reg_memory[9] = 32'h00000009;
        reg_memory[10] = 32'h0000000A;
        reg_memory[11] = 32'h0000000B;
        reg_memory[12] = 32'h0000000C;
        reg_memory[13] = 32'h0000000D;
        reg_memory[14] = 32'h0000000E;
        reg_memory[15] = 32'h0000000F;
        reg_memory[16] = 32'h00000010;
        reg_memory[17] = 32'h00000011;
        reg_memory[18] = 32'h00000012;
        reg_memory[19] = 32'h00000013;
        reg_memory[20] = 32'h00000014;
        reg_memory[21] = 32'h00000015;
        //reg_memory[22] = 32'h00000016;
        //reg_memory[23] = 32'h00000017;
        //reg_memory[24] = 32'h00000018;
        //reg_memory[25] = 32'h00000019;
        //reg_memory[26] = 32'h0000001A;
        //reg_memory[27] = 32'h0000001B;
        //reg_memory[28] = 32'h0000001C;
        //reg_memory[29] = 32'h0000001D;
        //reg_memory[30] = 32'h0000001E;
        reg_memory[31] = 32'hFFFFFFFF;
    end

    // The register file will always output the vaules corresponding to read register numbers
    // It is independent of any other signal
    assign read_data1 = reg_memory[reg_read_add1];
    assign read_data2 = reg_memory[reg_read_add2];

    // If clock edge is positive and regwrite is 1, we write data to specified register
    always @(posedge clock)
    begin
        if (wr_reg_enable) begin
            reg_memory[reg_write_add] = datawrite_to_reg;
        end     
    else
        reg_memory[reg_write_add] = 32'h00000000;
    end
endmodule


/////PROCESSOR


module PROCESSOR(
    input clock,
    input reset,
    output Output
);

    wire [31:0] instruction_Code;
    wire [3:0] ALu_control;
    wire WR_reg_enable;
    wire WR_mem_enable;
    wire RD_mem_enable;


    IFU IFU_module(.clock(clock), .reset(reset), .Instruction_Code(instruction_Code));
    
    CONTROL control_module(.opcode(instruction_Code[4:0]),.alu_control(ALu_control),.regwrite_control(WR_reg_enable),.memread_control(RD_mem_enable),.memwrite_control(WR_mem_enable));
    
    DATAPATH datapath_module(.Wr_mem_enable(WR_mem_enable),.Rd_mem_enable(RD_mem_enable),.Read_reg_add1(instruction_Code[9:5]),.Read_reg_add2(instruction_Code[14:10]),.Reg_write_add(instruction_Code[19:15]),.Address(instruction_Code[31:20]),.Alu_control(ALu_control),.Wr_reg_enable(WR_reg_enable), .clock(clock), .reset(reset), .OUTPUT(Output));

endmodule

**********************************************************************************************************************************************************

Below is my Synthesis.tcl file for genus synthesis

********************

set_attribute lib_search_path "/home/sameer23185/Desktop/VDF_PROJECT/lib"
set_attribute hdl_search_path "/home/sameer23185/Desktop/VDF_PROJECT"
set_attribute library "/home/sameer23185/Desktop/VDF_PROJECT/lib/90/fast.lib"
read_hdl Master.v
elaborate
read_sdc Min_area.sdc
set_attribute hdl_preserve_unused_register true
set_attribute delete_unloaded_seqs false
set_attribute optimize_constant_0_flops false
set_attribute optimize_constant_1_flops false
set_attribute optimize_constant_latches false
set_attribute optimize_constant_feedback_seqs false
#set_attribute prune_unsued_logic false
synthesize -to_mapped -effort medium
write_hdl > report/HDL_min_Netlist.v
write_sdc > report/constraints.sdc
write_script > report/synthesis.g
report_timing > report/synthesis_timing_report.rep
report_power > report/synthesis_power_report.rep
report_gates > report/synthesis_cell_report.rep
report_area > report/synthesis_area_report.rep
gui_show

**********************************************

WHEN I COMPARING MY GOLDEN.V WITH HDL_min_Netlist.v  during   conformal , I got  these  non-equivalent   point   for   every reg memory and for every data memory. I don't know what to do with these non-equivalent point. I've been stuck here for the past four days. Please help me in this and how can I remove this non- equivalent point , since I am new to this I really don't know what to do.

hi

How can I tell the LEC tool to ignore a combination of Primary input bus in both Golden and revised.

For example in both Golden and revised there is 

input [3:0] data_in

I want LEC not to check the case that data_in[3:0] == 4'b1000

Optimize Regression Suite, Accelerate Coverage Closure, and Increase hit count of rare bins using Xcelium Machine Learning. It is easy to use and has no learning curve for existing Xcelium customers. Xcelium Machine Learning Technology helps you discover hidden bugs when used early in your design verification cycle.(read more)

Explore Impacts of Finite Interconnect Impedance on PDN Characterization

Over the past few decades, many details have been worked out in the power distribution network (PDN) in the frequency and time domains. We have simulation tools that can analyze the physical structure from DC to very high frequencies, including spatial variations of the behavior. We also have frequency- and time-domain test methods to measure the steady-state and transient behavior of the built-up systems.

All of these pieces in our current toolbox have their own assumptions, limitations, and artifacts, and they constantly raise the challenging question that designers need to answer: How to select the design process, simulation, measurement tools, and processes so that we get reasonable answers within a reasonable time frame with a reasonable budget.

Read this award-winning DesignCon 2024 paper titled “Impact of Finite Interconnect Impedance Including Spatial and Domain Comparison of PDN Characterization.” Led by Samtec’s Istvan Novak and written with a team of nine authors from Cadence, Amazon, and Samtec, the paper discusses a series of continually evolving challenges with PDN requirements for cutting-edge designs.

Read the full paper now: “Impact of Finite Interconnect Impedance Including Spatial and Domain Comparison of PDN Characterization.”

At times, there might arise a condition in the design where you need to push the net of selected pins to all its physically connected objects. For example, a few pins are updated with a new net, and it is required to push the new net to all its connected objects. At times, you might update the die or copy routing to other components, when a portion of routing gets the wrong net.

To propagate the net of the pin to all its physically connected objects, Allegro X APD uses the standalone command, Push Connectivity.

You can call the command through Logic > Push Connectivity.

Alternately, you can use the push connectivity command at the command line. Once the command is active, it lets you select pins or symbols that will be used to push net connectivity to all connected objects.

Presently, dynamic shapes and filled rectangles are not considered as part of connectivity. Static shapes are supported.

By default, a dielectric must separate each pair of conductor layers in the cross-section of a design. In rare cases, this does not represent the real, manufactured substrate.

If your design requires you to have conductor layers that are not separated by a dielectric (such as, for half-etch designs), there is a variable that needs to be set in Allegro X APD. You must set this by enabling the variable icp_allow_adjacent_conductors. This entry, and its location in the User Preferences Editor, are shown in the following image.

The Objects on adjacent conductor layers do not electrically connect together, automatically. A via must be used to establish the inter-layer connections.

When enabling this option, it is recommended to exercise caution because excluding dielectric layers from your cross-section can lead to inaccurate calculations, including the calculations for signal integrity and via heights. It is important that your cross-section accurately reflect the finished product to ensure the most accurate results possible. Any dielectric layers present in the manufactured part need to be in the cross-section for accurate extraction, 3D viewing, and so on.

Let us know your comments on the various designs that would require adjacent conductor layers.

As technology continues to evolve at a rapid pace, the importance of robust and efficient interconnect standards cannot be overstated. Peripheral Component Interconnect Express (PCIe) has been a cornerstone in high-speed data transfer, enabling seamless communication between various hardware components.   

With the advent of PCIe 6.1 ECN, a significant advancement in speed and efficiency, ensuring the accuracy and reliability of its operations is paramount. One critical aspect of this is the verification of shared credit updates. For detailed understanding on Shared Credit, please refer Understanding PCIe 6.0 Shared Flow Control. 

In this blog, we will discuss why this verification is essential and what it entails.  

Introduction 

PCIe 6.1 ECN brings numerous advancements over earlier versions, such as increased bandwidth and faster data transfer speeds.   

A crucial mechanism for efficient data transmission in PCIe 6.0 is the credit-based flow control system. In this system, devices monitor credits, representing the buffer capacity available for incoming data.   

When a device transmits data, it uses credits, which are replenished or adjusted once the data is received and processed. This system ensures that the sender does not overload the receiver.  

Given the critical role of shared credit updates in maintaining the integrity and efficiency of data transfers, verification of these updates is crucial.  Proper management of credit updates is essential to ensure data integrity, as any discrepancies can lead to data loss, corruption, or system crashes.   

Verification also guarantees efficient resource allocation, preventing scenarios where some components are starved of credit while others have an excess, thus avoiding inefficiencies.  Credit inefficiencies pose issues in low power negotiations by preventing devices from entering low power states. Additionally, verification involves checking for proper error handling mechanisms, ensuring that the system can recover gracefully from errors in credit updates and maintain overall stability.   

PCIe 6.1 ECN Flow Control Optimizations Over PCIe 6.0

PCIe 6.1 ECN builds on the FLIT-based architecture introduced in PCIe 6.0, further optimizing flow control mechanisms to handle increased data rates and improved efficiency.  PCIe 6.1 ECN introduced refinements in credit management, making the allocation and advertisement of credits more precise, which helps in reducing bottlenecks and improving data flow efficiency.  Enhancements in flow control protocols ensure better management of buffer spaces and more efficient credit allocation. These enhancements are designed to handle the increased data rates and throughput demands of next-generation applications, ensuring robust and efficient data flow across PCIe devices.  

Below are some major updates: 

1. There have been improvements in error detection and correction mechanisms in PCIe 6.1 ECN to enhance flow control reliability by ensuring that corrupted data packets are detected and handled appropriately without disrupting the flow of valid packets.  
2. The merged credit system, which was a key feature introduced int PCIe 6.0 to simplify and optimize credit management, was further enhanced in PCIe 6.1 ECN to improve performance and efficiency.  
3. PCIe 6.1 ECN introduced better algorithms for allocating and reclaiming merged credits to handle high data rates, introduced more robust error detection and correction mechanism reducing the degradation or system instability. 
4. PCIe 6.1 ECN provided clear guidelines on how to implement the merged credit system correctly, helping developers to implement more reliable systems. For more details, please refer to Specifications section 2.6.1 Flow Control (FC) Rules.

Summary 

In summary, PCIe 6.0 is a complex protocol with many verification challenges. You must understand many new Spec changes and think about the robust verification plan for the new features and backward compatible tests impacted by new features. Cadence’s PCIe 6.0 Verification IP is fully compliant with the latest PCIe Express 6.0 specifications and provides an effective and efficient way to verify the components interfacing with the PCIe 6.0 interface. Cadence VIP for PCIe 6.0 provides exhaustive verification of PCIe-based IP and SoCs, and we are working with early adopter customers to speed up every verification stage.   

More Information

For more info on how Cadence PCIe Verification IP and Triple Check VIP enable users to confidently verify PCIe 6.0, see VIP for PCI Express, VIP for Compute Express Link  and TripleCheck for PCI Express    

See the PCI-SIG website for more details on PCIe in general and the different PCI standards.  

For more information on PCIe 6.0 new features, please visit PCIeLaneMargin, PCIe6.0LaneMargin, and Demonstrating PCIe 6.0 Equalization Procedure.

This post was contributed by Liliko Uchida, application engineer at Cadence. Being a “Woman in STEM” is a phrase that has long been used to describe the holistic experience shared by thousands of women globally, yet it still makes us feel isolated. Partially due to the statistics of gender population in the STEM workforce and the remainder due to our own internal obstacles, being a woman in STEM continues to be a challenge. While many of us know the should-do’s and should-be’s of taking on this unique role objectively, we struggle to implement them. After all, our perseverance as engineers, mathematicians, businesswomen, programmers, and scientists is largely affected by subjectivity. The UMass Lowell Women’s Leadership Conference 2024 aimed to tackle this problem by uniting hundreds of women with shared experiences under one roof. Not only did the conference provide us with the knowledge necessary to persevere, but it also gave us the tools that will allow us to thrive and act upon the facts we already know. It is my hope that through this blog post, I can share some of my main takeaways from this special day. Be Confident This is one of the most palpable pieces of advice we always hear. Yet so many of us struggle to build this confidence because we don’t know how. Featured speaker Nicole Kalil defined confidence as “complete trust in oneself”.”One way to build this self-trust is by getting to know yourself on a deeper level. By creating a true inner connection, we begin to see ourselves as a whole instead of hyper-focusing on our shortcomings frequently illusioned by imposter syndrome. In one of the sessions, we were asked to introduce ourselves to our neighbors, not by what we do for work, but by who we are as a person. Even if this opportunity does not arise every day, this practice can be done simply by listing characteristics of yourself that define who you are. Who do you care for? How do you show them? What are your life goals oriented towards? How do you observe others’ behavior around you, and what does that say about how you make them feel? Getting to know you beneath the surface and allowing yourself to be seen for who you are is critical in building internal confidence. With practice, this self-reassurance will grow independent of external factors. Take Risks “Sometimes, you have to put your foot in the elevator” - Barb Vlacich, Keynote Speaker When opportunities arise, the only thing you can do to have a chance is to try. Without putting your foot in the elevator, the doors will close, becoming a missed opportunity. Similarly, several of the conference’s speakers also emphasized that the answer to every unasked question will always be a no. Even if you are not ready to full-send a negotiation, ask for a raise, or respectfully disagree with a co-worker’s opinion, start by getting comfortable asking uncomfortable questions. Just one discomfort a day will help in building an immunity to the anxiety that comes with taking risks, typically driven by our self-doubt. Another interesting point that stood out from the conference was the statistics of self-assessed qualifications between men and women. During the negotiation panel, it was revealed that men typically feel they only need 60% of the qualifications under a job description to apply, whereas women often feel they need close to 100%. These numbers alone demonstrate how the pure mental habits of men continue to funnel them into STEM and not women. The next time you seek a new opportunity, assess yourself based on the 60% and use it as a checklist threshold. If more women are able to pursue STEM careers using these numbers, the more likely we will begin to populate these roles. Build Your Genuine Network “ The essence of communication lies in the mutual exchange of ideas and emotions. And when the listener isn’t invested, it undermines the entire purpose of the conversation. Why are you having it anyway?” This is a quote from episode 186 of Julie Brown’s podcast This Sh!t Works called “The 5 Steps to Being an Active Listener”. Julie Brown is a Networking Coach, author, and podcast host who guided an energetic and candid conversation about networking and building a personal brand for women. Networking is often misunderstood as putting your name and qualifications out on the table for as many people to pick up your cards. While making these things known is important, they are not what nurtures effective connections. The key to cultivating your genuine network is to activate a sincere interest in the people you meet. Become the proactive receiver of the confidence exercise discussed above. When you meet someone new, what can you take away from them as a person, not an employee? By making people feel heard, even through the little conversations, you can begin to develop more meaningful connections that resonate. And, with practice, the sometimes inherent need to overcompensate by defining yourself with your resume will slowly fade. It was a wonderful opportunity to attend the UML Women’s Leadership Conference with four other inspiring Cadence women. Not only was the conference a motivating learning experience, but it was also a wonderful opportunity for us to bond together as women and feel supported by each other. The most eye-opening part of the day was seeing just how many women alike were sitting under the same roof. The conclusion of the event led me to feel proud to be an engineer, proud to be at Cadence, and most importantly, proud to be a woman. Learn more about life at Cadence .

Peripheral Component Interconnect Express (PCIe) is a high-speed interface standard widely used for connecting processors, memory, and peripherals. With the increasing reliance on PCIe to handle sensitive data and critical high-speed data transfer, ensuring data integrity and encryption during verification is the most essential goal. As we know, in the field of verification, randomization is a key technique that drives robust PCIe verification. It introduces unpredictability to simulate real-world conditions and uncover hidden bugs from the design. This blog examines the significance of randomization in PCIe IDE verification, focusing on how it ensures data integrity and encryption reliability, while also highlighting the unique challenges it presents. For more relevant details and understanding on PCIe IDE you can refer to Introducing PCIe's Integrity and Data Encryption Feature . The Importance of Data Integrity and Data Encryption in PCIe Devices Data Integrity : Ensures that the transmitted data arrives unchanged from source to destination. Even minor corruption in data packets can compromise system reliability, making integrity a critical aspect of PCIe verification. Data Encryption : Protects sensitive data from unauthorized access during transmission. Encryption in PCIe follows a standard to secure information while operating at high speeds. Maintaining both data integrity and data encryption at PCIe’s high-speed data transfer rate of 64GT/s in PCIe 6.0 and 128GT/s in PCIe 7.0 is essential for all end point devices. However, validating these mechanisms requires comprehensive testing and verification methodologies, which is where randomization plays a very crucial role. You can refer to Why IDE Security Technology for PCIe and CXL? for more details on this. Randomization in PCIe Verification Randomization refers to the generation of test scenarios with unpredictable inputs and conditions to expose corner cases. In PCIe verification, this technique helps us to ensure that all possible behaviors are tested, including rare or unexpected situations that could cause data corruption or encryption failures that may cause serious hindrances later. So, for PCIe IDE verification, we are considering the randomization that helps us verify behavior more efficiently. Randomization for Data Integrity Verification Here are some approaches of randomized verifications that mimic real-world traffic conditions, uncovering subtle integrity issues that might not surface in normal verification methods. 1. Randomized Packet Injection: This technique randomized data packets and injected into the communication stream between devices. Here we Inject random, malformed, or out-of-sequence packets into the PCIe link and mix valid and invalid IDE-encrypted packets to check the system’s ability to detect and reject unauthorized or invalid packets. Checking if encryption/decryption occurs correctly across packets. On verifying, we check if the system logs proper errors or alerts when encountering invalid packets. It ensures coverage of different data paths and robust protocol check. This technique helps assess the resilience of the IDE feature in PCIe in below terms: (i) Data corruption: Detecting if the system can maintain data integrity. (ii) Encryption failures: Testing the robustness of the encryption under random data injection. (iii) Packet ordering errors: Ensuring reordering does not affect data delivery. 2. Random Errors and Fault Injection: It involves simulating random bit flips, PCRC errors, or protocol violations to help validate the robustness of error detection and correction mechanisms of PCIe. These techniques help assess how well the PCIe IDE implementation: (i) Detects and responds to unexpected errors. (ii) Maintains secure communication under stress. (iii) Follows the PCIe error recovery and reporting mechanisms (AER – Advanced Error Reporting). (iv) Ensures encryption and decryption states stay synchronized across endpoints. 3. Traffic Pattern Randomization: Randomizing the sequence, size, and timing of data packets helps test how the device maintains data integrity under heavy, unpredictable traffic loads. Randomization for Data Encryption Verification Encryption adds complexity to verification, as encrypted data streams are not readable for traditional checks. Randomization becomes essential to test how encryption behaves under different scenarios. Randomization in data encryption verification ensures that vulnerabilities, such as key reuse or predictable patterns, are identified and mitigated. 1. Random Encryption Keys and Payloads: Randomly varying keys and payloads help validate the correctness of encryption without hardcoding assumptions. This ensures that encryption logic behaves correctly across all possible inputs. 2. Randomized Initialization Vectors (IVs): Many encryption protocols require a unique IV for each transaction. Randomized IVs ensure that encryption does not repeat patterns. To understand the IDE Key management flow, we can follow the below diagram that illustrates a detailed example key programming flow using the IDE_KM protocol. Figure 1: IDE_KM Example As Figure 1 shows, the functionality of the IDE_KM protocol involves Start of IDE_KM Session, Device Capability Discovery, Key Request from the Host, Key Programming to PCIe Device, and Key Acknowledgment. First, the Host starts the IDE_KM session by detecting the presence of the PCIe devices; if the device supports the IDE protocol, the system continues with the key programming process. Then a query occurs to discover the device’s encryption capabilities; it ensures whether the device supports dynamic key updates or static keys. Then the host sends a request to the Key Management Entity to obtain a key suitable for the devices. Once the key is obtained, the host programs the key into the IDE Controller on the PCIe endpoint. Both the host and the device now share the same key to encrypt and authenticate traffic. The device acknowledges that it has received and successfully installed the encryption key and the acknowledgment message is sent back to the host. Once both the host and the PCIe endpoint are configured with the key, a secure communication channel is established. From this point, all data transmitted over the PCIe link is encrypted to maintain confidentiality and integrity. IDE_KM plays a crucial role in distributing keys in a secure manner and maintaining encryption and integrity for PCIe transactions. This key programming flow ensures that a secure communication channel is established between the host and the PCIe device. Hence, the Randomized key approach ensures that the encryption does not repeat patterns. 3. Randomization PHE: Partial Header Encryption (PHE) is an additional mechanism added to Integrity and Data Encryption (IDE) in PCIe 6.0. PHE validation using a variety of traffic; incorporating randomization in APIs provided for validating PHE feature can add more robust Encryption to the data. Partial Header Encryption in Integrity and Data Encryption for PCIe has more detailed information on this. Figure 2: High-Level Flow for Partial Header Encryption 4. Randomization on IDE Address Association Register values: IDE Address Association Register 1/2/3 are supposed to be configured considering the memory address range of IDE partner ports. The fields of IDE address registers are split multiple values such as Memory Base Lower, Memory Limit Lower, Memory Base Upper, and Memory Limit Upper. IDE implementation can have multiple register blocks considering addresses with 32 or 64, different registers sizes, 0-255 selective streams, 0-15 address blocks, etc. This Randomization verification can help verify all the corner cases. Please refer to Figure 2. Figure 3: IDE Address Association Register 5. Random Faults During Encryption: Injecting random faults (e.g., dropped packets or timing mismatches) ensures the system can handle disruptions and prevent data leakage. Challenges of IDE Randomization and its Solution Randomization introduces a vast number of scenarios, making it computationally intensive to simulate every possibility. Constrained randomization limits random inputs to valid ranges while still covering edge cases. Again, using coverage-driven verification to ensure critical scenarios are tested without excessive redundancy. Verifying encrypted data with random inputs increases complexity. Encryption masks data, making it hard to verify outputs without compromising security. Here we can implement various IDE checks on the IDE callback to analyze encrypted traffic without decrypting it. Randomization can trigger unexpected failures, which are often difficult to reproduce. By using seed-based randomization, a specific seed generates a repeatable random sequence. This helps in reproducing and analyzing the behavior more precisely. Conclusion Randomization is a powerful technique in PCIe verification, ensuring robust validation of both data integrity and data encryption. It helps us to uncover subtle bugs and edge cases that a non-randomized testing might miss. In Cadence PCIe VIP, we support full-fledged IDE Verification with rigorous randomized verification that ensures data integrity. Robust and reliable encryption mechanisms ensure secure and efficient data communication. However, randomization also brings various challenges, and to overcome them we adopt a combination of constrained randomization, seed-based testing, and coverage-driven verification. As PCIe continues to evolve with higher speeds and focuses on high security demands, our Cadence PCIe VIP ensures it is in line with industry demand and verify high-performance systems that safeguard data in real-world environments with excellence. For more information, you can refer to Verification of Integrity and Data Encryption(IDE) for PCIe Devices and Industry's First Adopted VIP for PCIe 7.0 . More Information: For more info on how Cadence PCIe Verification IP and TripleCheck VIP enables users to confidently verify IDE, see our VIP for PCI Express , VIP for Compute Express Link for and TripleCheck for PCI Express For more information on PCIe in general, and on the various PCI standards, see the PCI-SIG website .

Please give me some ideas. Thank you very much.

This is the 15th installment of The Rationalist, my column for the Times of India.

It’s election season, and promises are raining down on voters like rose petals on naïve newlyweds. Earlier this week, the Congress party announced a minimum income guarantee for the poor. This Friday, the Modi government released a budget full of sops. As the days go by, the promises will get bolder, and you might feel important that so much attention is being given to you. Well, the joke is on you.

Every election, HL Mencken once said, is “an advance auction sale of stolen goods.” A bunch of competing mafias fight to rule over you for the next five years. You decide who wins, on the basis of who can bribe you better with your own money. This is an absurd situation, which I tried to express in a limerick I wrote for this page a couple of years ago:

POLITICS: A neta who loves currency notes/ Told me what his line of work denotes./ ‘It is kind of funny./ We steal people’s money/And use some of it to buy their votes.’

We’re the dupes here, and we pay far more to keep this circus going than this circus costs. It would be okay if the parties, once they came to power, provided good governance. But voters have given up on that, and now only want patronage and handouts. That leads to one of the biggest problems in Indian politics: We are stuck in an equilibrium where all good politics is bad economics, and vice versa.

For example, the minimum guarantee for the poor is good politics, because the optics are great. It’s basically Garibi Hatao: that slogan made Indira Gandhi a political juggernaut in the 1970s, at the same time that she unleashed a series of economic policies that kept millions of people in garibi for decades longer than they should have been.

This time, the Congress has released no details, and keeping it vague makes sense because I find it hard to see how it can make economic sense. Depending on how they define ‘poor’, how much income they offer and what the cost is, the plan will either be ineffective or unworkable.

The Modi government’s interim budget announced a handout for poor farmers that seemed rather pointless. Given our agricultural distress, offering a poor farmer 500 bucks a month seems almost like mockery.

Such condescending handouts solve nothing. The poor want jobs and opportunities. Those come with growth, which requires structural reforms. Structural reforms don’t sound sexy as election promises. Handouts do.

A classic example is farm loan waivers. We have reached a stage in our politics where every party has to promise them to assuage farmers, who are a strong vote bank everywhere. You can’t blame farmers for wanting them – they are a necessary anaesthetic. But no government has yet made a serious attempt at tackling the root causes of our agricultural crisis.

Why is it that Good Politics in India is always Bad Economics? Let me put forth some possible reasons. One, voters tend to think in zero-sum ways, as if the pie is fixed, and the only way to bring people out of poverty is to redistribute. The truth is that trade is a positive-sum game, and nations can only be lifted out of poverty when the whole pie grows. But this is unintuitive.

Two, Indian politics revolves around identity and patronage. The spoils of power are limited – that is indeed a zero-sum game – so you’re likely to vote for whoever can look after the interests of your in-group rather than care about the economy as a whole.

Three, voters tend to stay uninformed for good reasons, because of what Public Choice economists call Rational Ignorance. A single vote is unlikely to make a difference in an election, so why put in the effort to understand the nuances of economics and governance? Just ask, what is in it for me, and go with whatever seems to be the best answer.

Four, Politicians have a short-term horizon, geared towards winning the next election. A good policy that may take years to play out is unattractive. A policy that will win them votes in the short term is preferable.

Sadly, no Indian party has shown a willingness to aim for the long term. The Congress has produced new Gandhis, but not new ideas. And while the BJP did make some solid promises in 2014, they did not walk that talk, and have proved to be, as Arun Shourie once called them, UPA + Cow. Even the Congress is adopting the cow, in fact, so maybe the BJP will add Temple to that mix?

Benjamin Franklin once said, “Democracy is two wolves and a lamb voting on what to have for lunch.” This election season, my friends, the people of India are on the menu. You have been deveined and deboned, marinated with rhetoric, seasoned with narrative – now enter the oven and vote.

The India Uncut Blog © 2010 Amit Varma. All rights reserved.
Follow me on Twitter.

Read this blog to know how you can easily create and insert connect modules using Spectre AMS Designer with the Verilog-AMS standard language defined by Accellera. (read more)

Read this blog to know more about the innovation behind Universal Connect Modules (UCM).(read more)

Hi 

I am looking into chamfering the edge of PCB for Board edge connectors. I have performed fillet command earlier but new to chamfering.

Below is the description :

As seen above, the PCB edge are chamfered in thickness as well as at the corners.

Using OrCAD PCB hotfix S023.

I have a design which says there are 6 unconnected nets. But 'Display All Nets, shows only 4 unconnected. When I try to look at the non-connection, is appears connected and nothing shows??

What is happening?

I have tried replicating the setup described in a previous post (here), with the proposed solution.

The MDL measurements return a value of 0 for all exported result but the first.

Using Viva I can actually see the correct value for each contribution.

I am using :
- Spectre 23.1.0.538.isr10
- Viva IC23.1-64b.ISR8.40

What should I do differently?

Thanks!

**** test.measure ****

Measurement Name   :  noi_test
Analysis Type      :  noise
noi_total             =  6.9282e-06
r1_flicker            =  0
r1_thermal            =  0
r1_total              =  0
r2_flicker            =  0
r2_thermal            =  0
r2_total              =  0

Hi all,

I have a question regarding how to sweep the config view without using a global variable. I’d like to set a different config view for each test, and I'm trying to avoid using corners or plan.

Any suggestions on how to achieve this?

Thanks in advance for your help!

Best,
MooH

Hello,


I would like to use the simulation software xrun/simvision that comes with XCELIUM. We are currently using classroom licenses and want to disable all ip addresses on the student pcs except the license server ip. We want to make sure that students cannot copy confidential data from the Cadence tools.


Problem:

When I launch the xrun simulation while all ip addresses are blocked, it starts but the performance is very slow. The GUI starts after 5 minutes and the simulation is ready after 10 minutes. The interesting thing is that when I enable all blocked ip addresses, everything works at a reasonable speed.

Terminal Output (execution without internet connection):

xrun -gui design.vhd

waiting for SimVision/Verisium Debug to connect...


Is there a way to run the simulation tools without an Internet connection? Or can you give me the ip addresses that are used by the simulation tools so that I can enable only those specific ips?


Regards,

Max

Hello everyone,

I hope you're all doing well. I’ve set up two testbenches (TB1 and TB2) for my Design Under Test (DUT) using Cadence IC6.1.8-64b.500.21 tools, as shown in the attached figure. The DUT has multiple views available: schematic, Calibre, Maestro, and Symbol, and each testbench uses the same DUT in different scenarios. Currently, I have to manually switch between these views, but I would like to streamline this process.

My goal is to use a single config view that allows me to switch between the schematic and the extracted (Calibre) views. Ideally, I would like to have a configuration file where making changes once would update both testbenches (TB1 and TB2) automatically. In other words, when I modify one config, both testbenches should reflect this update for a single simulation run.

I would really appreciate it if you could guide me on the following:

1. How to create a config view for my DUT that can be used to easily switch between the schematic and extracted views, impacting both TB1 and TB2.
2. Where to specify view priorities or other settings to control which view is used during simulation.
3. Best practices for using a config file in this scenario, so that it ensures consistency across multiple testbenches.

Please refer to the attached figure to get a better understanding of the setup I’m using, where both TB1 and TB2 include the same DUT with multiple available views.

Thank you so much for your time and assistance!

First time user of JasperGold. Chip level verif. I want to prove that an arbiter and a buffer are connected. I want to use the connectivity app to do that.

I see from the user guide, that I should provide a connectivity map, but i have no idea how to construct one.
The training videos said use this command: check_conn -generate_template jasper_template.xlsm -xlsm
But that did nothing, or at least it did not produce a file that i could find

[<embedded>] % check_conn -generate_template jasper_template.xlsm -xlsm
ERROR (ESW104): Invalid command formation.
Problem occurs with "-generate_template -xlsm".

And even if it did, I don't even know what's in the file, and whether it contains the two ips I'm trying to check.

I'm hoping someone can give me a bit of a boost here with some knowledge.

Hi

I have tried using "add net constraints" command to place one-cold constraints on a tristate enable bus. In the command line we need to specify the "net pathname" on which the constraints are to be enforced.

The bus here is 20-bit. How should the net pathname be specified to make this 20-bit bus signals one_hot or one_cold.

The bus was declared as follows:
ten_bus [19:0]

The command I used was

add net constraints one_hot /ren_bus[19]

What would the above command mean?
Should we not specify all the nets' pathnames on the bus?
Is it sufficient to specify the pathname of one net on the bus?
I could not get much info regarding the functionality of this command. I would be obliged if anyone can throw some light.

Thanks
Prasad.

The following macros encapsulates a design pattern that enables constraining data item fields by 'do' actions of a high level sequence. This can be done without presupposing anything about the sequence tree generated under the do-ing sequence.

The tar file consists of 4 files:
- item_constraint_macro.e - the 'item_constraint' and 'sequence_export' macros definition
- item_constraint_example.e and sequence_export_example.e - use examples (one per each new construct)
- packet_seq.e - an auxiliary definition file for the examples

This topic was discussed in a Club-T presentation (Israel, Sophia-Antipolis, Munich). The presentation is also publicly avaiable.

Cadence Clarity 3D Solver supports encrypted component models! Using this functionality, vendors can supply their 3D components, such as connectors, to end customers without revealing the physical IP of these designs. The first connector vendor to take advantage of this functionality is Japan Aviation Electronics (JAE),(read more)

A constraint is a user-defined property, or a rule, applied to a physical object, such as a net, pin, or via in a design. There are a number of constraints that can be applied to an object based on its type and behavior. For example, you can define t...(read more)

Hello,

I am trying to design an RF mixer for a TX.
Assume my input IF signal is at 1 GHz, my LO at 2 GHz and I want my RF at 3 GHz, and assume that the mixer fully works after testing it with HB.
How to simply set the envelope analysis to check the EVM ?
I read through the documentation but I couldn't get it (I couldn't fully understand the settings of the source, probe, analysis.)
Which source and probe to use? I want custom modulation with custom bandwidth and center frequency.
Is there some examples for the ENVLP analysis ?

I am using IC23.1 and spectre 20.1.354.

Concurrent Layout Editing enables more than one designer to work in a hierarchy at the same time. Check out this blog to know more. (read more)

Is there a way to set a thru via hole to thru via hole spacing constraint?

I need the hole to hole spacing, nit pad to pad spacing.

I can calculate the spacing using the via pad diameter, but this won't work for multiple via pad sizes.

I have a small shape for connecting three SMD pads, but it won't connect to one of the pads (0.2x0.6 mm). Thermal relief connects are set to Full contact for SMD pin in Shape parameters, but that doesn't help.

However, if I decrease the Minimum aperture for gap width in Void controls in Shape parameters to something below 0.2 mm the shape connects to the pad. But it is a little contracted at the pad entrance. Just 0.002 mm. What is going on here? 

Tried to attach some pictures, but I get: "An error occurred. Please try again or contact your administrator.". Will try later again.

/F

Hi

I have fixed a SPACING RULE (SP1) for a CLASS_DIFF_PAIR whereas for via associated to the net (DP_VIA), the DISTANCE > 60mils respect to ANY other vias (PTH, BB, TEST vias)

Now my problem is that this rules should NOT be applied for GND VIAS (STICHING VIA) which must be placed at a distance < 40mils respect to DP_VIA

How to create an exemption to the SPACING RULE (SP1)?

Power efficiency is a critical factor in the fast-evolving world of semiconductor design.

The IEEE 1801 standard, also known as UPF (Unified Power Format), was developed by the IEEE to address the intricate challenges associated with power management in contemporary semiconductor designs. This standard offers a uniform framework for defining power domains, power states, and power intent, ensuring consistency across diverse tools and phases of the design process. By utilizing UPF, you can precisely model and regulate power consumption, a critical aspect for battery-operated devices, high-performance computing, and energy-efficient designs.

The key concepts of IEEE 1801 are:

1. Power domains
2. Power states
3. Power gating and isolation
4. Power switches
5. Level shifters, isolation, and retention cells
6. Macro model

Based on these building blocks, you write the power intent of the design.

The power intent for the design includes identifying/implementing low-power strategies that provide a clear description of the power architecture of a design.

The power definitions can effectively manage power consumption and ensure the chip meets its power and performance requirements.

You can start by creating the Power Supply Network, which defines how power is supplied to the design's various power domains and logic cells.

What's the next step to build the file? How do you understand the various concepts related to IEEE 1801? How do you complete the rest of the power intent file?

Relax!

Gear up to attend the training class created just for you to dive deep into the entire format and explore this exciting power specification method/format with hands-on labs in one day!

Training

Fundamentals of IEEE 1801 Low-Power Specification Format Training

This course is a complete tutorial for understanding the fundamentals of IEEE 1801 low-power specification format concepts. You learn about IEEE 1801 power supply networks, ground ports and nets, creating and connecting supply ports/nets, power domain, power switch, power states, defining isolation and level shifter strategies, hierarchical IEEE 1801, and various versions of the IEEE 1801. You also explore how power intent information can be used for a design across various flow stages, such as functional verification, synthesis, logic equivalency checking, place-and-route, test, timing signoff, power integrity, and so forth, using Cadence^® tools.

Labs

We ensure that your learning journey is smooth with hands-on labs covering various design scenarios.

Lab Videos

Now, the exciting part is that to help you further, we have created engaging videos of the training labs. You can refer to the lab module's instructions in demo format at https://support.cadence.com.

Lab Demo: Checking Power Supply Network in IEEE 1801 format and Running IEEE 1801 Quality Checks using Conformal Low Power

Lab Demo: Checking Power Intent for The Macro Connections in IEEE 1801 Format And Running IEEE 1801 Quality Checks using Conformal Low Power 

Online Class

Here is the course link.

Get ready for the most thrilling experience with Accelerated Learning!

The more you know, the faster you go!

Grab the cycle  or hike it, based on your existing knowledge.

Take the quiz and increase your learning pace!!

What's Next?

Grab your Badge after finishing the training and flaunt the expertise you have built up. 😊

Ready to take a tour of this power specification world? Let's help you enroll in this course.

We organize this training for you as a "Blended" or "Live" training. Please reach out to Cadence Training for further information. If you want to ensure you are always the first to know about anything new in training, you can use the SUBSCRIBE button on the landing page to sign up for our regular training newsletters.

Related Short Training Bytes/Videos

Enhance the learning experience with short videos:

Genus Synthesis Solution: Video Library

 Joules RTL Power Solution: Video Library

Related Training

 Low-Power Synthesis Flow with Genus Synthesis Solution

Genus Low-Power Synthesis Flow with IEEE 1801

Related Blogs

It's the Digital Era; Why Not Showcase Your Brand Through a Digital Badge! - Digital Design - Cadence Blogs - Cadence Community

Relax in Summer with Cooler IC chips and Ice-Cream! Do you want to Explore the Recipe? - Digital Design - Cadence Blogs - Cadence Community

Power Is HOT and Touches Everything and Everybody! But the Challenge Is To Deal With Low Power During Design Synthesis; How? - Digital Design - Cadence Blogs - Cadence Community

Binge on Chip Design Concepts this Weekend! - Digital Design - Cadence Blogs - Cadence Community

Conformal ECO Designer enables you to implement RTL engineering change orders (ECOs) for pre- and post-mask layout and offers early ECO prototyping capabilities for driving critical project decisions.

Conformal ECO compares two designs and generates a functional patch that implements the changes between the two designs.

One major criterion for determining patch quality is whether the patch can meet timing closure. To determine this, you typically need to run the time-consuming process of incremental synthesis and place-and-route. Instead, Conformal can analyze path logic depth changes before and after ECO patch generation. This provides a faster way to evaluate timing impact in patch generation stages.

After the patch is created and applied, it is passed to Genus to optimize the patch.

During patch optimization, you can choose to do many things like:

• Keeping constants in the patch
• Allowing tie cell inversion
• Specifying tie cell types
• Preserve DFF cells and cell types in the patch
• Preserve all cells and nets in the patch
• Preserve clock buffer cell in the patch
• Turn on/off sequential constant and sequential merge in patch optimization
• Allowing phase mapping for DFFs
• Map to spare cells
• Force fix DRC before timing

What's Next?

Join the Conformal ECO course to:

• Explore the many options and capabilities of Conformal ECO
• Use Conformal Engineering Change Order (ECO) for flat and hierarchical designs
• Generate a functional ECO patch, apply it to a design, optimize it, and map it to a specified technology
• Run a hierarchical design through ECO and run a comparison to prove the ECO is equivalent
• Run a postmask ECO using Conformal ECO GXL

Make sure you have experience with Conformal Equivalence Checker or completed the Conformal Equivalence Checking course before taking this course.

The online class is free for all Cadence customers with a Cadence Learning and Support Portal account. If you don’t have a Cadence Support account, go to Registration Help or Register Now and complete the requested information. For instructor-led training sessions "Live" or "Blended" please contact Cadence Training.

Please don't forget to obtain your Digital Badge after completing the training. Add your free digital badge to your email signature or any social media and networking platform to show your qualities and build trust, making you and your projects even more successful.

Cyprus is ranked first in fDi’s Island Economies of the Future rankings, followed by the Dominican Republic and Sri Lanka. Cathy Mullan and Naomi Davies detail the results.

Russia remains fDi’s most diversified commodity economy, while second ranked Brazil has displaced Ukraine into third place. Cathy Mullan reports.

Egypt is well on the way to establishing a diversified economy, claims Hala El Saeed, minister of planning and economic development 

Tanzania's economy is booming and its tourism sector is thriving. However, concerns about the president's strong-arm tactics and delays in the completion of key infrastructure projects are threatening this growth.

Combining a strategic location with an investor-friendly environment, Egypt is ensuring its Suez Canal Economic Zone is primed for foreign investment.