Featured post

Top 5 books to refer for a VHDL beginner

VHDL (VHSIC-HDL, Very High-Speed Integrated Circuit Hardware Description Language) is a hardware description language used in electronic des...

Wednesday, 10 October 2012

Digital Logic in Analog Block - How To Test It?

Analog IP blocks these days have increasing amounts of digital control logic. With very small amounts of digital logic, it's possible to just draw gates on the schematic and run targeted tests that will hopefully catch any errors. But when you have several thousand digital gates, a new approach is needed, as I discovered in a recent discussion.

"2,000 gates is probably a good transition point where people switch from manually inserting gates in a schematic to synthesis," said Bob Melchiorre, director of field operations for digital implementation at Cadence. "Beyond 2,000 gates you have to start thinking about how you're going to test it, because you cannot guarantee that simulation or targeted testing will catch all the issues. Around 10,000 gates it starts getting completely unbearable, and you cannot write enough targeted tests to find all the faults in your digital logic."

Click here to read more ...

Get free daily email updates!

Follow us!

Sunday, 7 October 2012

DDR4 SDRAM Standards published by JEDEC

The PC industry hasn't seen an updated memory spec in a while, and it was long past due. That upgrade came last week, as the memory standards group JEDEC revealed that it had published a spec for DDR4 SDRAM, defining "features, functionalities, AC and DC characteristics, packages and ball/signal assignments," that builds on the DDR3 spec, first published in 2007. The DDR4 spec applies to SDRAM devices from 2 GB through 16 GB for x4, x8 and x16 buses. Here's a look at some of the particulars.

“The new standard will enable next generation systems to achieve greater performance, significantly increased packaging density and improved reliability, with lower power consumption,” Macri said.


Double Data Rate

First and foremost, DDR4 memory doubles the maximum transfer rate of DDR3. The new spec supports a per-pin data rate of up to 3.2 giga transfers per second (GT/s), twice that of its predecessor's eventual maximum of 1.6 GT/s (the ceiling was raised over time). And, DDR4's max could likewise go higher, as necessary, to accommodate faster components and bus speeds. So far, the only processor roadmap we've seen in support of DDR4 has been Intel's, with its Haswell server processor slated for 2014; consumer-platform support isn't expected until sometime in 2015.

Meanwhile, JEDEC member company Samsung announced in July that it had begun sampling the "industry's first" 16-GB DDR4 RDIMMs, and that it will also offer a 32-GB module; and Samsung, Micron and other companies already offer smaller-denomination DIMMs that comply with the spec.


Lower Power

The DDR4 spec defines memory that operates on 1.2V, compared with DDR3's 1.5V and 1.35V low-voltage spec. According to Samsung, its DDR4 RDIMMs consume about 40 percent less power than DDR3 memory modules operating at 1.35V. We're not sure what math they used to arrive at that finding, but in a world increasingly mindful of power consumption and rising energy costs, 1.2V is better than 1.35V.


More, Wider Memory

While DDR3 supported DIMM sizes between 512 MB and 8 GB in as many as eight banks, DDR4 quadruples memory top-end by doubling the module maximum to 16 GB (with a 2-GB minimum) in as many as 16 banks. That's math we can handle. What's more, DDR4 can arrange memory banks into as many as four groups, providing faster burst access to memory and separate read, write, activation and refresh operations for each group.

Incidentally, memory speeds of DDR4 will start at 1,600MHz and balloon to 3,200MHz. DDR3 mobiles are available mostly at frequencies between 800MHz and 1,600MHz, although the spec supports 1,866MHz and 2,133MHz memory, according to a comparison chart published by memory maker Micron.

DOWNLOAD

Get free daily email updates!

Follow us!

Tuesday, 25 September 2012

DesignWare DDR4 Memory Interface IP from Synopsys

Highlights:

  • Synopsys expands its industry-leading DesignWare® DDR Memory Interface IP family to include support for DDR4 SDRAMs
  • Backward compatibility with DDR3 and LPDDR2/3 mobile SDRAMs gives SoC designers flexibility as they transition from one SDRAM standard to the next
  • New DDR4 IP offers more features with up to 50 percent lower latency than the previous generation
  • DDR4 memory controller and PHY are connected by a standard DFI 3.1 interface to streamline connections to custom PHYs and controllers

Synopsys, Inc. (SNPS), a world leader in software and IP used in the design, verification and manufacture of electronic components and systems, today announced the expansion of its DesignWare DDR interface IP portfolio to include support for next-generation SDRAMs based on the emerging DDR4 standard. By supporting DDR4 as well as DDR3 and LPDDR2/3 in a single core, the DesignWare DDR solution enables designers to interface with either high-performance or low-power SDRAMs in the same system-on-chip (SoC), which is a key requirement of many SoCs such as applications processors for smartphones and tablets.

"Synopsys' support for DDR4 memory is an important contribution to building a robust DDR4 ecosystem," said Robert Feurle, vice president of DRAM marketing for Micron Technology, Inc. "DDR4 brings substantial power and performance benefits to the industry, and Micron is aggressively driving its introduction. By implementing their DesignWare DDR Interface IP with backward compatibility in mind, Synopsys is enabling chip developers to bridge the transition from today's DDR3-based SoCs to the upcoming DDR4 designs."

Synopsys' DesignWare DDR4 IP solution consists of the DDR4 multiPHY and Enhanced Universal DDR Memory Controller (uMCTL2) that connect through a commonly used DFI 3.1 interface. The new DDR4 IP supports all key DDR4 features planned for the upcoming JEDEC standard and, compared to the previous version, includes a 13 percent increase in raw bandwidth, up to a 50 percent reduction in overall latency and new low-power features that provide intelligent system monitoring and control to power down elements of the IP as determined by the system's traffic patterns. Real-time scheduling features in Synopsys' unique CAM-based DDR controller can optimize the scheduling of data read/write traffic from multiple hosts, maximizing performance and minimizing latency.

"While the initial target markets for DDR4 are networking, server, and compute platforms, engineers designing for digital TVs, set-top-boxes, multi-function printing, smartphone and tablet applications will also adopt DDR4 DRAM as prices drop and performance improves," said Desi Rhoden, executive vice president, Montage Technology, and JEDEC memory chairman. "Synopsys has leveraged their participation at JEDEC to develop DDR4-compatible products before the actual standard has been released, which is a key benefit of JEDEC membership."

"Synopsys' complete DDR interface IP portfolio includes support for LPDDR, LPDDR2, LPDDR3, DDR, DDR2, and DDR3," said John Koeter, vice president of marketing for IP and systems at Synopsys. "With this announcement, we are broadening our portfolio to include support for DDR4 while maintaining backward compatibility with existing JEDEC standard SDRAMs. As new DDR standards evolve, designers look for reliable solutions. Synopsys' track record of over 320 DDR IP design wins demonstrates that we offer a low-risk path to silicon success."

Availability for the DesignWare DDR4 multiPHY and uMCTL2 with support for DDR4 is planned for Q4 2012.

Get free daily email updates!

Follow us!

Sunday, 23 September 2012

Smartphone is next stop for PCI Express

PCI Express, the I/O backbone of PCs and servers, is getting a low-power extension that will take it into Ultrabooks, tablets and smartphones starting next year. The enhanced interconnect will draw two to four times less power while helping mobile devices link to high-performance peripherals such as 60-GHz wireless networking controllers and solid-state drives.

The PCI Special Interest Group expects to approve by the end of the year a new version of its low level software for PCIe 3.0. The code will run on the M-PHY physical layer chips defined by the MIPI Alliance that creates handset interfaces.

Click here to read more ...

Get free daily email updates!

Follow us!

Saturday, 22 September 2012

Callback in System Verilog

    Callback is one of the major confusing point for a System Verilog learner. Many people have asked the same question in many forums, but the answer doesn't seems to satisfy fully the quest of the person who has raised the querry. I too had the same issue, but I learned it slowly in a hard way. I am presenting here a way in which if I had an answer, I would have learned faster.

    We can pass data member to any function. Now consider a case where you are passing a function (say func1) as a data member to another function (say func2) and you get what is called callback. The reason why it is called callback is that the function func2 now can call anywhere in its code function func1.

    In computer programming, a callback is executable code that is passed as an argument to other code. It allows a lower-level software layer to call a subroutine (or function) defined in a higher-level layer.

    Note that SV doesn't give a straight-forward way of passing a function as argument for another function. But we can get the same result (almost we can say!) by using OOP. The idea is to describe all the functions (both func1 type and func2 type) in a base class (don't implement the funct2 kind of function and make them virtual for polymorphism), and then extend the class to a derived class where you implement the func2 type of function.

    Example:-

    class abc_transactor;

    virtual task pre_send(); endtask

    virtual task post_send(); endtask

    task xyz();

    // Some code here

    this.pre_send();

    // Some more code here

    this.post_send();

    // And some more code here

    endtask : xyz

    endclass : abc_transactor

    class my_abc_transactor extend abc_transactor;

    virtual task pre_send();

    ... // This function is implemented here

    endtask

    virtual task post_send();

    ... // This function is implemented here

    endtask

    endclass : my_abc_transactor

    Now let me explain how it is going to work. The base class abc_transactor has 3 tasks, 2 of which are declared virtual and are not implemented. But they are being called from another task xyz() which is fully implemented. The unimplemented virtual task are called callback class.

    The child class, which extends from the base class, implements the previous unimplemented tasks. It inherits the xyz() task from the base class and hence doesn't need to change it. By this we can inject executable code to a function without modifying it.

    Now the next question is why is done. There are many reasons for it.

  1. The biggest advantage is that you can modify the behavior of task xyz() without modifying it in the base or child class. It is a big advantage as no one wants to fiddle with known good functioning code.

  2. Consider a case where you are writing a base class which is going to be used by multiple test environment, and for each test environment a known part of the code, or a known function/task is going to change. The natural choice is to implement those change-in-every-case functions/tasks as callback method and let the user extend your base class with specifying only that part of the code which need to be changed in his case.

    1.  

Get free daily email updates!

Follow us!

Wednesday, 19 September 2012

Programming FPGAs with Python

py For everyone who wants to get started with developing for FPGA’s and dont want to waste time in learning a new programming  language or they just want to use their current knowledge of programming with Python to program an FPGA, this tool is just made for you!

The Python Hardware Processsor is written in Myhdl which makes it possible to run a very small subset of python on an FPGA, it converts a very simple Python code into either VHDL or Verilog and then a hardware description can be uploaded to the FPGA:

“Due to the python nature of Myhdl and the Python Hardware Prozessor written with it, it allows you, to write a Programm for the prozessor, to simulate the Hardware Processor and to convert the Processor to a valid hardware description (VHDL or Verilog) inside a single python environment.”

MyHDL surely won’t replace VHDL or Verilog but it could be a great tool for simulation and to test the behavior of your design and it’s certainly a tool worth looking into if you want to jump into the world of FPGAs.

Feel free to discuss in the comments thread.

Get free daily email updates!

Follow us!

Monday, 17 September 2012

Draw AND gate using XOR gates only

Hi friends….

Do any one know how to design an AND gate using XOR gate.?

This was a good question for discussion among me and my friends during graduation. At last solution was quite impressive. I thought i would be good to discuss it here also as I had found this question is interviews for freshers.

Please let us know your comments and views.

Is it really possible to design AND gate using XOR gate.?
If yes, then HOW?
If no, then WHY?

Get free daily email updates!

Follow us!