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...

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!

Monday, 10 September 2012

Verilog language reference manual LRM

Verilog was started initially as a proprietary hardware modeling language by Gateway Design Automation Inc. around 1984. It is rumored that the original language was designed by taking features from the most popular HDL language of the time, called HiLo, as well as from traditional computer languages such as C. At that time, Verilog was not standardized and the language modified itself in almost all the revisions that came out within 1984 to 1990.

Verilog simulator was first used beginning in 1985 and was extended substantially through 1987. The implementation was the Verilog simulator sold by Gateway. The first major extension was Verilog-XL, which added a few features and implemented the infamous "XL algorithm" which was a very efficient method for doing gate-level simulation.

The time was late 1990. Cadence Design System, whose primary product at that time included Thin film process simulator, decided to acquire Gateway Automation System. Along with other Gateway products, Cadence now became the owner of the Verilog language, and continued to market Verilog as both a language and a simulator. At the same time, Synopsys was marketing the top-down design methodology, using Verilog. This was a powerful combination.

In 1990, Cadence recognized that if Verilog remained a closed language, the pressures of standardization would eventually cause the industry to shift to VHDL. Consequently, Cadence organized the Open Verilog International (OVI), and in 1991 gave it the documentation for the Verilog Hardware Description Language. This was the event which "opened" the language.

OVI did a considerable amount of work to improve the Language Reference Manual (LRM), clarifying things and making the language specification as vendor-independent as possible.

Soon it was realized that if there were too many companies in the market for Verilog, potentially everybody would like to do what Gateway had done so far - changing the language for their own benefit. This would defeat the main purpose of releasing the language to public domain. As a result in 1994, the IEEE 1364 working group was formed to turn the OVI LRM into an IEEE standard. This effort was concluded with a successful ballot in 1995, and Verilog became an IEEE standard in December 1995.

When Cadence gave OVI the LRM, several companies began working on Verilog simulators. In 1992, the first of these were announced, and by 1993 there were several Verilog simulators available from companies other than Cadence. The most successful of these was VCS, the Verilog Compiled Simulator, from Chronologic Simulation. This was a true compiler as opposed to an interpreter, which is what Verilog-XL was. As a result, compile time was substantial, but simulation execution speed was much faster.

In the meantime, the popularity of Verilog and PLI was rising exponentially. Verilog as a HDL found more admirers than well-formed and federally funded VHDL. It was only a matter of time before people in OVI realized the need of a more universally accepted standard. Accordingly, the board of directors of OVI requested IEEE to form a working committee for establishing Verilog as an IEEE standard. The working committee 1364 was formed in mid 1993 and on October 14, 1993, it had its first meeting.

The standard, which combined both the Verilog language syntax and the PLI in a single volume, was passed in May 1995 and now known as IEEE Std. 1364-1995.

After many years, new features have been added to Verilog, and the new version is called Verilog 2001. This version seems to have fixed a lot of problems that Verilog 1995 had. This version is called 1364-2001.

Timeline:

1984 Verilog-XL simulator and language developed by Gateway Design Automation
1987 Synopsys introduced a Verilog based synthesis tool.
1989 Cadence Design Systems acquired Gateway, and Verilog.
1990 Cadence placed the Verilog language in the public domain.
1995 Verilog HDL became (IEEE Std 1364-1995).
1997 Verilog VCS bought by Viewlogic
1997 Viewlogic bought by Synopsys
1998 Synopsys issues Verilog VCS
2001 A significantly revised version was published in 2001.

DOWNLOAD VERIOG LRM

Intel Is Cooling Entire Servers By Submerging Them in Oil

originalAir cooled computers are for wimps. But while the idea of keeping temperatures in check using water might be a step in the right direction, Intel is doing something even more radical: it's dunking entire servers—the whole lot—into oil to keep them chill.

Don't panic, though: they're using mineral oil, which doesn't conduct electricity. It's a pretty wacky idea, but it seems to be working. After a year of testing with Green Revolution Cooling, Intel has observed some of the best efficiency ratings it's ever seen. Probably most impressive is that immersion in the oil doesn't seem to affect hardware reliability.

All up, it's extremely promising: completely immersing components in liquid means you can pack components in more tightly as the cooling is so much more efficient. For now, though, it's probably best to avoid filling your computer case with liquid of any kind.



Get free daily email updates!

Follow us!