HOME    COMMUNITY    BLOGS & FORUMS    VIP Central
VIP Central

Decoding SAS 24G: New Encoding and Features

Posted by VIP Experts on July 25th, 2016

SAS follows its own version of Moore’s law, doubling the speed every few years. Keeping up with the tradition, SAS 24G (Gen-5) was recently introduced. Let’s decode, how the effective speed has been doubled to 24G, though signaling rate remains at 22.5G. This has been achieved through a more efficient 128b/150b encoding scheme to realize a usable data rate of 24G while retaining compatibility with 6G and 12G. Additional features were also introduced to improve the overall protocol efficiency. Some of the newly added features include binary primitives, primitive parameters, SMP open priority, inter-expander fairness arbitration enhancements, … etc. In this blog we will look into some of the new features, and will continue to delve into more details in the upcoming blogs on SAS.

128b/150b Encoding

The support for Gen-5 is not merely a speed bump from earlier Gen-4; but also utilizes a whole new encoding scheme. SAS-4 utilizes 128b/150b encoding scheme that is aimed at providing better link efficiency at speeds 22.5G and higher. To preserve backward compatibility with earlier generations, the 128b/150b encoding is utilized when the physical link operates at Gen-5 or higher (SAS Packet mode). Traditional 8b/10b encoding scheme is used when the physical link operates at Gen-4 or lower speeds (SAS Dword mode).

The 128b/150b encoding process encodes four dwords into 150 bits, whereas the 8b/10b encoding method would have resulted in 160-bits for the same four dwords (lesser number of bits to transmit!). Unlike 8b/10b encoding, the 128b/150b encoding allows for correction of transmission errors at the receiver. In this new encoding scheme, the information is transferred in the form of ‘SPL packets’ which are 150-bit blocks transmitted serially on the wire.  Each block contains:

  1. 2-bit SPL Packet Header
  2. 128-bit SPL Packet Payload Descriptor
  3. 20-bit Forward Error Correction(FEC) Information
SPL Packet

SPL Packet

SPL Packet Header

The SPL Packet Header field defines the format of the packet payload descriptor i.e. the type of segment contained in the packet payload.

SPL Packet Payload Descriptor

The Packet Payload descriptor contains a scrambled idle segment, idle dword segment, SPL frame segment or a primitive segment. A simple way to think of packet payload descriptor would be that it is a collection of four dwords of identical type (primitive or data dwords).

  • A scrambled idle segment contains four data dwords set to zero. A scrambled idle segment is a deletable SPL packet.
  • An idle dword segment contains four scrambled idle dwords and is transmitted outside a frame.
  • A frame segment contains four data dwords that are part of a frame. This can be a SSP frame segment, SMP frame segment, STP frame segment or an address frame segment. The CRC is placed in the final SPL packet of the frame. As all packets are 4-dword aligned, pad words are used to fill any unfilled slots between the CRC and end of the SPL frame segment.
  • A primitive segment contains an extended binary primitive or four dwords that are primitives/binary primitives (and, associated primitive parameter, if any). We’ll see more on binary primitives and primitive parameters in subsequent blogs.

Forward Error Correction

The 128b150b encoding scheme also equips the receivers with the ability to correct transmission errors. This is made possible with the Forward Error Correction information embedded in each SPL packet. A Reed Solomon code is used for this purpose. For the computation of FEC, a 26-symbol message M(x) is constructed using the 2-bit Packet header and 128-bit packet payload. Each symbol is 5-bits wide (26 symbols x 5 bits = 130 bits). The parity check symbols P(x) is then calculated over this message M(x). The computed parity P(x) is embedded in the original message and transmitted. The selected Reed Solomon code allows correction of up to 2 symbol errors.

We will look into Binary primitives and Primitive parameters in the upcoming blogs. Stay tuned!

Synopsys recently announced the availability of industry’s first VIP to support SAS 24G.
To know more about Synopsys storage VIP, please visit http://synopsys.com/vip
Also read our recent blogs on storage.
Evolution of Storage Protocols: SCSI to SAS
Industry’s First SAS 24G Verification IP for Enterprise Storage Systems

Authored by Srinivas Vijayaragavan and Pooja Gupta.

Posted in SAS, SATA, Storage | No Comments »

Evolution of Storage Protocols: SCSI to SAS

Posted by VIP Experts on July 12th, 2016

Synopsys recently announced the availability of industry’s first VIP to support the Serial-attached SCSI (SAS) 24G standard. Let’s look back how far we have come along, let’s time travel and re-live the interesting journey of storage and SCSI evolution.

There is no limit to generate, process, store, and restore data in today’s smart and connected world. One thing is for sure: we want our information, all of our information, to be stored securely and accessible whenever we want to and from wherever we are. Storage drives are becoming smaller in size with evolving storage technologies, yet data centers are becoming bigger by every passing day to support the ever increasing rate of data generation. What does the future of data storage hold? Will our data continue to leap from our myriad of devices to the cloud?

Storage media has evolved from magnetic tape to floppy disks and CD/DVD, to hard disk drives, and flash based scsi 1storage. It is projected that in one single day we exchange as much information as our grandparents did in early 1950s in a year. In 1950s, magnetic tapes were first used by IBM to store data, that was quite popular until the mid-1980s. In 1969, the first floppy disk (read only, stored 80kB of data) was introduced. Four years later in 1973, same size floppy disk could store 256kB of data and could be re-written. Now the kids of connected-to-cloud generation, who haven’t seen floppy, will recognize the image just as an icon to save your work in some popular software.

In 1981, Shugart Associates teamed up with NCR Corporation, and convinced ANSI to set up a committee to standardize a computer system interface for storage (SASI). In 1982, a technical committee was formed to work on standardizing SASI (very early predecessor of SCSI). A number of changes were made to the interface to widen the command set and improve performance. The name was also changed to SCSI; to make it as an industry standard. The first “true” SCSI interface standard was published in 1986, and evolutionary changes to the interface have been occurring since that time. Since then the trend has set to store more and more data into smaller size disks.

SCSI, the Small Computer System Interface, is a set of American National Standards Institute (ANSI) standard electronic interfaces that allow personal computers to communicate with peripheral hardware such as printers, scanners, disk drives, and CD-ROM drives etc. SCSI is often thought of as a hard disk interface, however, SCSI is not an interface tied specifically to hard disks. Many other type of devices can be present on the bus, what my point is that SCSI was designed from the ground up to be a high-performance, high-level, expandable interface. SCSI has made a name for itself as a storage technology that as a highly reliable solution and high performance and includes many commands and special features, to our forever increasing demands for speed and flexibility in storage devices. Now, SCSI is the storage technology of choice for storage applications in high-end computer users, server systems, network attached storage (NAS) and storage area network (SAN) applications.

scsi parallel to serial comparision table

SCSI began as a parallel interface, allowing the connection of devices to a personal computer or other systems with data being transmitted across multiple data lines. SCSI itself, however, has broadened greatly in terms of its scope, and today includes a wide variety of related technologies and standards, as defined in the SCSI-3 standard. SCSI-3 is extended into its own full portfolio, reflecting its new status as an “umbrella” standard containing several others.

All SCSI communication takes place between an initiator (host adapter) that sends commands, and a target drive that responds. Immediately after receiving a command sequence, the target returns a response code, so the initiator knows whether or not it will get the response it wants.

Common SCSI components

Initiator: An initiator issues service requests and receives responses. Initiators come in a variety of forms and may be integrated into a server’s system board or exist within a host bus adapter

Target: A SCSI target is typically a physical storage device. The target can be a hard disk or an entire storage device. It is also possible for non-storage hardware to function as a SCSI target

Service delivery subsystem: The mechanism that allows communication to occur between the initiator and the target; it usually takes the form of cabling

Expander: Only used with serial-attached SCSI (SAS); allows multiple SAS devices to share a single initiator port

Stay tuned for upcoming blogs on SAS – Serial Attached SCSI details and other interesting aspects.

To know more about Synopsys storage VIP, please visit http://synopsys.com/vip

Authored by Mansi Chadha

Posted in FC, NVMe, SAS, SATA, Storage | No Comments »

PCI SIG Update: Latest on PCIe Gen4 0.7 VIP and Test Suite

Posted by VIP Experts on July 6th, 2016

Synopsys at PCI SIG

The PCI-SIG Developers Conference 2016 was held at Santa Clara in last week and it was a great success. Our PCIe experts were there and we bring you the highlights of conference.

There was a lot of interest and queries from attendees regarding our latest version of the PCI VIP for Gen 4.  The VIP supports the latest version of the Gen 4 Specification, 0.7.    We have many early adopter customers utilizing the latest specifications and leveraging our up-to-date VIP for accelerated verification closure. Some of our customers are close to tape out and signing off verification with our VIP.  There were questions about how we identify and keep tests up to date with every changing Gen 4 spec. We illustrated this for a few of our tests showing the entire flow starting with linking the pdf spec to our tests using Verdi Spec Linking.   The tool not only allows for the creation of a verification plan based using the spec as an input but it also supports spec updates by ‘diffing’ the previous and new version of the spec to make sure features still apply.

There were variety of queries and we observed that the major challenges in PCI verification being faced by fellow verification engineers are ranging from protocol compliance and checks, high level interface for packet generation and error injection, to specification linking to test plan and coverage, and performance concerns like memory footprint etc. There were system level verification challenges like verification of a switch with large number of instances etc. We went over key features of the VIP and test suites to overcome the above mentioned verification challenges including extensive protocol checks, tests for compliance, flexible error injection, Verdi spec linking, ease of debug etc.

If you had a chance to drop by the booth we appreciate it; it was good to meet so many existing customers and have you share your success with the VIP and Test Suites.

To know more about PCIe VIP, please visit http://synopsys.com/vip

Authored by Paul Graykowski and Ankur Jain

Posted in PCIe | No Comments »

Energy Efficient Designs with MIPI

Posted by VIP Experts on June 28th, 2016

Getting the best out of available battery technologies continues to be a challenge for mobile design companies. When phones were used for voice only, the battery lasted a few days compared to less than a day in case of smartphones with high resolution screens, cameras, powerful processors, gigabytes of memories and running power hungry software. Consumers continuously demand more features and functions from their mobile electronics and with more functions converged into a single device, it’s becoming extremely challenging for SoC designs to keep up with the exploding bandwidth, advanced integration functionality and low power constraints.

MIPI Alliance has been leading the effort in designing energy efficient interfaces with low and ultra-low power features as cornerstones of its specifications. One of the primary focus in all of the MIPI specifications is to lower power consumption and making the interfaces energy efficient. This blog reviews M-PHY and D-PHY specifications for their energy efficient features.

MIPI M-PHY

MIPI M-PHY [1] is a serial interface technology with high bandwidth capabilities used for mobile applications requiring low pin count and demanding power efficiency. The MIPI  M-PHY Specification features the following aspects for energy efficiency:

  • BURST mode operation for improved power efficiency.
  • Multiple transmission modes with different bit-signaling and clocking schemes intended for different bandwidth ranges to enable better power efficiency over a huge range of data rates.
  • Multiple power saving modes, where power consumption can be traded-off against recovery time. Central to the MIPI M-PHY specification is its Finite State Machine which defines the following five power saving STATEs                                                                                                                                                                                                               
    • STALL: The power saving state in HS-MODE.  This state allows the lowest power consumption of all ACTIVATED states.                                                                                                                                       
    • SLEEP: The power saving state of LS-MODE.  This state allows the lowest power consumption of all ACTIVATED states.                                                                                                                                                  
    • HIBERN8: This state enables ultra-low power consumption, while maintaining the configuration settings.  During this state, the M-RX is considered to be in squelch.                                                        
    • DISABLEDThis is a POWERED state, while MODULE operation is disabled by a RESET signal. When DISABLED, an M-TX shall be high impedance, and an M-RX shall keep the LINE at DIF-Z.                                                                                                                        

MIPI D-PHY

MIPI D-PHY is a flexible, low-cost, High-Speed serial interface solution for communication interconnection between components inside a mobile device. Traditionally, these interfaces are CMOS parallel busses at low bit rates with slow edges for EMI reasons. The MIPI D-PHY solution enables significant extension of the interface bandwidth for more advanced applications. The MIPI D-PHY solution can be realized with very low power consumption.

Operating Modes: Control, High-Speed, and Escape
During normal operation a Data Lane will be either in Control or High-Speed mode. High-Speed Data transmission happens in bursts.

  • Escape Mode: Escape mode is a special mode of operation for Data Lanes using Low-Power states. It shall be supported in the Forward direction and is optional in the reverse direction. 
  • Low-Power Data Transmission: Data transmission happens at low speed (up to 10Mbps) using a low frequency TLPX clock (50ns). In Camera and Display applications, LPDT is utilized during the blanking period to reduce power. Control and status information is send (between camera/display device and the application processor) with the help of low power modules (utilizing low frequency signals).
  • Ultra-Low Power State: When the lane enters the Ultra-Low Power State (ULPS) system goes into sleep state and there is no transmission of data. Almost no power is consumed in this state.
  • Clock Lane Ultra-Low Power State: When the Clock Lane goes into Ultra-Low Power State, the clock transition stops (‘00’ is driven on the lane) and almost no power is consumed.

Low Power Data Transmission

Low Power Data Transmission[2]

Protocols such as Camera Serial Interface, Display Serial Interface, UniPro and Low Latency Interface utilize these and their own features to help create energy efficient designs. We will cover some of these protocols in the upcoming blogs.

Synopsys provides a complete set of MIPI VIP; more details can be found at http://synopsys.com/vip

Authored by Apoorva Mathur.

References:

[1] MIPI Alliance Specification for M-PHY, Version 4.0, 27 April 2015

[2] MIPI Alliance Specification for D-PHY, Version 2.0, 23 November 2015

Posted in Camera, CSI, D-PHY, DSI, MIPI, Mobile SoC, MPHY, Uncategorized, Unipro, UniPro | No Comments »

Debug of AMBA AXI Outstanding Transactions

Posted by VIP Experts on June 21st, 2016

Verifying today’s complex designs is time consuming, as simulations run for long time and millions of transaction are executed. Traditional approach of debug is to dump all the information of millions of packets in a log file, however it would always be challenging to filter out specific transactions from the huge log file. For example, in case of AXI Protocol, a fixed number of outstanding transactions are allowed during simulation, it would always be difficult to find out such outstanding transaction in the huge log file of a single run of simulation or during interactive simulation. It is one of the biggest pain point of debugging.

Synopsys Verdi protocol analyzer supports unique search/filter capability to overcome such debug pain points. Let’s put some light on, what are the outstanding transactions, with the help of following diagram.

AMBA Outstanding Transactions

AXI Outstanding Transactions

 

AXI master can issue multiple address (A1,A2,A3) for read/write without waiting for respective completions. A typical debug requirement is to count and track outstanding transactions in a certain time window of the simulation. Traditional way of debugging through signal dump or log file is very tedious and time consuming.

Verdi protocol analyzer is natively integrated with AXI VIP to make debug easy and fast. A snapshot of the protocol analyzer GUI is shown below. Master/Slave transactions and its properties can be highlighted in the GUI. Search engine can be invoked from a menu button in the tool bar. Using the search engine with appropriate query will filter such transaction in less than 10 seconds making it easy and fast to debug AXI outstanding transactions.

Verdi Protocol Analyzer

Verdi Protocol Analyzer

The complete solution is described in a white paper – Finding Outstanding Transactions.

Authored by Abhishek Upadhyay

Posted in AMBA, Debug, Interconects | No Comments »

Verification Highlights from DAC 2016

Posted by VIP Experts on June 14th, 2016

Synopsys at DAC 2016

Synopsys at DAC 2016

The Design Automation Conference (DAC) 2016 was a great success and here we provide you the highlights of Synopsys’ activities at the event.

Verification Luncheon

Verification Luncheon

Synopsys hosted the annual “SoC Leaders Verify with Synopsys” Verification luncheon.  The luncheon featured industry experts and executives from Cavium, NXP, Qualcomm and Samsung, and drove our main messages of collaboration, with strong technology innovation in the Verification Continuum platform.

Synopsys' Chairman and Co-CEO at DAC panel

Synopsys’ Chairman and Co-CEO at DAC panel

Synopsys’ Chairman and Co-CEO was at DAC panel and talked about advanced process nodes, hardware – software co-design, automotive industry, security, software signoff, and his vision on future ranging from digital intelligence, mobility age, big data and local utilization of data from IoT, to the next killer app.

Synopsys Highlighted Automotive Verification Solutions

Synopsys Highlighted Automotive Verification Solutions

Synopsys highlighted its Automotive verification solutions daily during DAC on the show floor.  It covered VCS (leading RTL/Gate Level simulator, recently certified for ISO26262), Automotive VIP (Native SystemVerilog/UVM architecture with available source code test suites, Verdi (recently certified for ISO26262), and Certitude (fault injection).

Recent Synopsys announcements at DAC:

Synopsys Selected as Primary Emulation Provider for NXP Semiconductors
4X emulation performance enables fast software schedules for next-generation SoCs

NXP Selects Synopsys As Primary SoC Verification Solution
Comprehensive Synopsys Solution Enables Accelerated Verification of Next-Generation SoCs including Automotive, Secure Connectivity and Smart Connected Products

Authored by Ankur Jain

Posted in AMBA, Audio, Automotive, Camera, CAN, Data Center, DDR, Debug, DesignWare, Display, eMMC, Ethernet, Ethernet AVB, Flash, FlexRay, HBM, HMC, Interconects, Interface Subsystems, LIN, LPDDR, Memory, Memory, Methodology, MIPI, Mobile SoC, ONFi, PCIe, Processor Subsystems, Soundwire, Storage, SystemVerilog, Test Suites, UFS, Uncategorized, USB, UVM | No Comments »

Synopsys Verification Continuum at DAC 2016

Posted by VIP Experts on June 2nd, 2016

DAC 2016

Synopsys at DAC 2016

The Design Automation Conference (DAC) 2016, in Austin, Texas kicks off next week starting June 5th to June 9th. As the leading and longest-running annual design and verification event, DAC is the premier place to network with fellow design and verification engineers.

Synopsys will feature its annual Verification Luncheon and Customer Panel that discusses the entire Verification Continuum offering, including our customer collaborations on VCS, VIP, SpyGlass, Verdi, VC Formal, ZeBu, and Hybrid emulation.  In addition, the luncheon panel of industry experts will share their viewpoints on what is driving SoC complexity, how their teams have achieved success and how you can apply their insights on your next project. 

Additionally, please join us at Synopsys Booth #149 to hear industry experts discuss exciting new developments and the latest trends in IoT, FinFET, and Automotive design and use. 

Further information (and registration) for verification luncheon and panel can be found at: https://www.synopsys.com/Tools/Verification/Pages/dac2016-verification-luncheon-panel.aspx

To know more visit our DAC page:                                                       https://www.synopsys.com/apps/dac2016/home.html?cmp=DAC16-HL

Authored by Ankur Jain

Posted in Audio, Automotive, Camera, Data Center, Debug, DesignWare, Display, Ethernet, Interface Subsystems, Memory, Methodology, Mobile SoC, PCIe, Processor Subsystems, Soundwire, Storage, Success Stories, SystemVerilog, Test Suites, Uncategorized, UVM | Comments Off

MIPI SoundWire: Higher Bandwidth Through Bulk Register Access

Posted by VIP Experts on May 31st, 2016

MIPI SoundWire provides an optional mechanism for transporting register operations at higher bandwidth than mandatory command mechanism.  Bulk Register Access (BRA) protocol is a particular format of data transport to achieve the higher bandwidth.  While normal commands can only be driven at the rate of one command per frame, Bulk Register Access provides the option to read/write as many as 511 registers in one frame.  So a clock frequency of 5MHz and frame size of 256*16(4096 BitSlots or 2048 clock periods) will increase the effective rate of data transfer to approximately 1.2 MBps. MIPI SoundWire supports a frequency of up to 12 MHz, so the bandwidth can be even higher. In this blog I’ll focus on what a Bulk Register Access payload stream looks like and how it can be used to achieve higher bandwidth.

BRA Payload Stream

Since BRA is in no way related to actual audio transport we have the freedom to choose any values of word length and sample interval as per our needs. However, there are some restrictions as our aim is to transport a minimum of 11 bytes even in the worst case scenario (with 11 bytes we are only accessing 1 byte which is defeating the whole purpose of BRA, a normal command in this case would be more efficient). To use as many bits available in a frame for transporting data, sample word length can be set equal to hwidth and sample interval equal to number of columns. HStop can be set to max column and HStart to column 0 or 1 when lane 0 is being used.  Hence the specification recommends that Port 0 should support all values of word length from 1 to 16 as it provides the most efficient packing of data.

Data on port 0 can be easily multiplexed with other ports when desired. Keeping a separate sub-frame for BRA when multiplexing it with other Ports looks like a better option as it removes any restrictions on sample interval which are present when multiplexing both Port 0 and “normal” data ports in the same sub-frame. However when it comes to test modes for BRA, any kind of multiplexing can be used without trouble as now we are not interested in ensuring that our BRA block should be complete within a frame.

Another important differentiating feature of BRA is that it is packed in bytes without taking channel boundaries into consideration. All payload channel samples falling within a frame are collectively used for transporting one BRA block. Since a BRA block is always packed in bytes all bits beyond a multiple of 8 are ignored even if they fall within the frame. With a new frame a new BRA block starts, so if 64 contiguous addresses are to be read and only 60 addresses can be read in one frame due to limitations on available bits for payload, the remaining 4 addresses will be read in the next frame/next BRA block. The next BRA block will have the 61st address as the starting address and number of bytes will be set to 4 so that the remaining 4 bytes are read.

Few examples

Example 1: 

Let’s take Frame size = 10 columns * 60 rows and number of bytes to be read = 64

Total number of bits that’ll be used for such a BRA block -> (64 + 10) bytes * 8 = 592 bits

Payload Parameters->  Hstart  1, Hstop 9 Word length = 9, Sample Interval = 10

Available payload bits in frame -> 60*9 = 540

Number of bits that can be used = 540 – 540%8 = 536

Number of bytes that can fit one frame = 536/8 = 67

So only 64-7 = 57bytes can be read in this frame, total bits in block 67 *8 = 536

The frame would look like as shown below in table -1.

 

1

2

3

4

5

6

7

8

9

10

1

C

 

 

 

 

 

 

 

 

 

2

O

 

 

 

 

 

 

 

 

 

3

N

 

 

 

 

 

 

 

 

 

.

T

 

 

 

 

 

 

 

 

 

.

R

 

 

 

 

 

 

 

 

 

.

O

 

 

 

 

 

 

 

 

 

.

L

 

 

 

 

 

 

 

 

 

 

W

 

 

 

 

 

 

 

 

 

 

O

 

 

 

 

 

 

 

 

 

 

R

 

 

 

 

 

 

 

 

 

48

D

 

 

 

 

 

 

 

 

 

.

 

 

 

 

 

 

 

 

 

 

.

 

 

 

 

 

 

 

 

 

 

.

 

 

 

 

 

 

 

 

 

 

60

 

 

 

 

 

 

 

 

 

 

 

Remaining 7 bytes can be accessed in another frame, total bits in this BRA block: 17*8 = 136

The resulting frame is shown below in table-2.

 

1

2

3

4

5

6

7

8

9

10

1

C

 

 

 

 

 

 

 

 

 

2

O

 

 

 

 

 

 

 

 

 

3

N

 

 

 

 

 

 

 

 

 

.

T

 

 

 

 

 

 

 

 

 

.

R

 

 

 

 

 

 

 

 

 

15

O

 

 

 

 

 

 

 

 

 

16

L

 

 

 

 

 

 

 

 

 

.

W

 

 

 

 

 

 

 

 

 

.

O

 

 

 

 

 

 

 

 

 

.

R

 

 

 

 

 

 

 

 

 

48

D

 

 

 

 

 

 

 

 

 

.

 

 

 

 

 

 

 

 

 

 

.

 

 

 

 

 

 

 

 

 

 

.

 

 

 

 

 

 

 

 

 

 

60

 

 

 

 

 

 

 

 

 

 

Example 2:

Let’s take the same frame with same sub –frame and word length = 12 and sample interval = 24

I’m not going into detailed calculations here but the packed BRA block would look something like this (Table 3 BRA Block 3). All channel samples falling within the frame would collectively be used to send one BRA block.

 

1

2

3

4

5

6

7

8

9

10

1

C

 

 

 

 

 

 

 

 

 

2

O

 

 

 

 

 

 

 

 

 

3

N

 

 

 

 

 

 

 

 

 

.

T

 

 

 

 

 

 

 

 

 

.

R

 

 

 

 

 

 

 

 

 

.

O

 

 

 

 

 

 

 

 

 

.

L

 

 

 

 

 

 

 

 

 

 

W

 

 

 

 

 

 

 

 

 

 

O

 

 

 

 

 

 

 

 

 

 

R

 

 

 

 

 

 

 

 

 

48

D

 

 

 

 

 

 

 

 

 

We will talk more about other aspects of Bulk Register Access such as deferred command response and interrupts in case of failed commands, in our upcoming blogs.

For more information on MIPI Soundwire, you can download our whitepaper, and visit http://synopsys.com/vip

By the way we have published an informative series of blogs on MIPI Soundwire. In MIPI Soundwire: Digital Audio Simplified, we mentioned that digital audio formats, including Pulse Code Modulation (PCM) and Pulse Density Modulation (PDM), are target applications for MIPI Soundwire. Later, we discussed Digital Audio Streams and Channels, Benefits of MIPI Soundwire and MIPI Soundwire Source Code Test Suites.

Authored by Parul Raj

 

Posted in MIPI, Soundwire, Uncategorized | Comments Off

Full Utilization of 16 GT/s PCIe Gen 4 Bandwidth – 2

Posted by VIP Experts on May 25th, 2016

PCI express Gen 4 implementation is marching towards the Gen 4 0.7 release. It’s important that not only physical layer delivers the 16 GT/s rate, but also the entire protocol stack should be capable of saturating the full allocated bandwidth. To saturate the full bandwidth, following two key features are gaining traction:

In our earlier blog,  we discussed about 10-bit extended tag. In this blog, we will discuss about the second feature scaled flow control credits. We will give a brief introduction of the feature to give a jump start to any one ramping up on the latest specifications, and also discuss corresponding verification challenges and solutions.

Scaled flow control credits

Current flow control mechanism allows maximum of up to 127 outstanding header credits and 2047 outstanding data credits. The Gen3 x16 link can’t saturate with these limits in certain scenarios. The flow control mechanism is enhanced with scaled flow control. In scaled flow control mechanism, the maximum outstanding header and data credits can be scaled by a factor of 1, 4 or 16 based on the programmable setting. Note that the credits remain unchanged, one header credit will still be 1 TLP header and one data credit remains to be 16 bytes. Following updates have been done to support scaling flow control: -

  • New capability structure called “Data Link Feature Extended Capability” has been added. It contains programmable control/status information about the local and peer support of the “Data Link Feature Support”
  • New DLLP called “Data Link Feature Exchange” has been added
  • New state called “DL Feature” has been added in the Data Link Control and Management State Machine as a part of the initialization
  • During the new state DL Feature a new extension is added to initialization. The new DLLP “Data Link Feature Exchange” is exchanged at every 34 us to figure out if the Flow control scaling is enabled
  • Init FC1, Init FC2 exchanged subsequently decide the scaling factor through the re-definition of the reserved bits as shown below
  • Subsequent UpdateFC protocol remains unchanged. The scaling factor in the UpdateFC must continue to match to the factor indicated during initial credit exchange protocol
Proposed updates to DLLP to support credit scaling (Courtesy: PCI-SIG)

Proposed updates to DLLP to support credit scaling (Courtesy: PCI-SIG)

Verification Challenges and Solution

Verification of the feature can be divided in 3 categories as described below: -

  • Normal operation
    • Directed test to verify if credit scaling with different programmed settings is reaching to its maximum values
    • Random credits usage with different scaling enabled
    • With multiple VCs, when one VCx is blocked the other VCy can continue to make forward progress if there is pending traffic
  • DL Feature state
    • Possible state transitions from and to DL Feature state
  • Error injection cases
    • New HdrScale and DataScale field corruptions
    • Issuing more credits than advertised
    • All the error injections leading to reporting of “Flow Control Protocol Error”, as defined in specification.

Synopsys VC VIP for PCIe supports latest specifications and makes it very easy to verify all the new features.

Authors:  Anand Shirahatti, Mohd Adil Khan, Jamshed Alum 

Posted in PCIe | Comments Off

AUTOMOTIVE… Vroom Vroom….

Posted by VIP Experts on May 17th, 2016

automtoive smoke cloud

One of the most important inventions of mankind is the “wheel”. What started as a small means of transportation has turned into a revolution that changed the dynamics of how the world runs today. Imagine a world without wheel – scary and impossible to accept. With the wheel around, the first step to automotive industry was laid with a simple carriage, and exponentially grew into one of the biggest economic sectors running over billions of automobiles.

From being simple users of these automobiles in earlier times, users have become smarter now and looking for differentiators in new automobiles. They demand more sophisticated infotainment systems and high-end features as a standard at a lower price. Being connected at all the times is the order of the day – an ecosystem on the move. There is tighter screw from governments on emission norms, fuel economy and safety features.

The move to autonomous vehicle is approaching to mass production rapidly. From manually controlled cars in yester years to more driver alerts to emergency intervention for driver assist package to monitored control for super cruise concept to autonomous driving – the growth in automotive technology is on fast track. Auto-on lamps, rain sensing wipers, brake assist, night vision, intelligent parking assist, traffic jam assist, blind spot detection – the list of automation is huge and ever growing to make driving a happy and safe experience.

Safety implies protection against any risk, danger, damage or cause of injury. Safety in automobiles cannot be compromised and it is the primary requirement to prevent any malfunctions or defects that may cause serious accidents. There have been many product recalls in recent times due to undetected safety issues leading to not only heavy financial losses but also a big dent on the popular automobile brands. Any defect, however small, if left in the design may lead to serious consequences. Hence, safety in the automotive industry is highly regulated. Automobiles have to comply with a certain number of norms and regulations. ISO 26262 standard is considered as one of the best practice framework for achieving automotive functional safety.

To conclude, with all the above automation, and safety measures, electronics in automobiles is already on a rise. Electronics and software now contribute a handsome 35% of the overall car cost and 90% of innovations and new features. Automotive protocols like Ethernet AVB, CAN, LIN, FlexRay are being deployed rapidly, especially in the Infotainment systems in automobiles. The day is not far when we would have driver-less cars roaming around us – fully safe and sound.

We will talk more about the above mentioned automotive protocols in our upcoming blogs.

Automotive Systems

Automotive Systems

Synopsys: Your verification partner for next-gen Automotive SoCs

Synopsys VC VIP for Ethernet AVB, CAN, LIN, FlexRay are based on native SystemVerilog, Universal Verification Methodology (UVM) architecture, and provides built-in protocol checks, coverage and verification plan for accelerated verification closure. VIP provides an extensive and customizable set of frame generation and error injection capabilities. In addition, source code test suites are also available to jumpstart verification of complex protocols. Wherever applicable, compliance test suites are also provided.

Authored by Jaspreet Singh Gambhir

Posted in Automotive, CAN, Ethernet AVB, FlexRay, LIN | Comments Off