Ansys IDEAS Digital Forum Banner 1

WP_Query Object
(
    [query] => Array
        (
            [page_id] => author/paul-mclellan-60.html
        )

    [query_vars] => Array
        (
            [page_id] => 0
            [error] => 
            [m] => 
            [p] => 0
            [post_parent] => 
            [subpost] => 
            [subpost_id] => 
            [attachment] => 
            [attachment_id] => 0
            [name] => 
            [pagename] => 
            [second] => 
            [minute] => 
            [hour] => 
            [day] => 0
            [monthnum] => 0
            [year] => 0
            [w] => 0
            [category_name] => 
            [tag] => 
            [cat] => 
            [tag_id] => 
            [author] => 
            [author_name] => 
            [feed] => 
            [tb] => 
            [paged] => 0
            [meta_key] => 
            [meta_value] => 
            [preview] => 
            [s] => 
            [sentence] => 
            [title] => 
            [fields] => 
            [menu_order] => 
            [embed] => 
            [category__in] => Array
                (
                )

            [category__not_in] => Array
                (
                )

            [category__and] => Array
                (
                )

            [post__in] => Array
                (
                )

            [post__not_in] => Array
                (
                )

            [post_name__in] => Array
                (
                )

            [tag__in] => Array
                (
                )

            [tag__not_in] => Array
                (
                )

            [tag__and] => Array
                (
                )

            [tag_slug__in] => Array
                (
                )

            [tag_slug__and] => Array
                (
                )

            [post_parent__in] => Array
                (
                )

            [post_parent__not_in] => Array
                (
                )

            [author__in] => Array
                (
                )

            [author__not_in] => Array
                (
                )

            [ignore_sticky_posts] => 
            [suppress_filters] => 
            [cache_results] => 
            [update_post_term_cache] => 1
            [lazy_load_term_meta] => 1
            [update_post_meta_cache] => 1
            [post_type] => 
            [posts_per_page] => 10
            [nopaging] => 
            [comments_per_page] => 50
            [no_found_rows] => 
            [order] => DESC
        )

    [tax_query] => WP_Tax_Query Object
        (
            [queries] => Array
                (
                )

            [relation] => AND
            [table_aliases:protected] => Array
                (
                )

            [queried_terms] => Array
                (
                )

            [primary_table] => wp5_posts
            [primary_id_column] => ID
        )

    [meta_query] => WP_Meta_Query Object
        (
            [queries] => Array
                (
                )

            [relation] => 
            [meta_table] => 
            [meta_id_column] => 
            [primary_table] => 
            [primary_id_column] => 
            [table_aliases:protected] => Array
                (
                )

            [clauses:protected] => Array
                (
                )

            [has_or_relation:protected] => 
        )

    [date_query] => 
    [queried_object] => 
    [queried_object_id] => 
    [request] => SELECT SQL_CALC_FOUND_ROWS  wp5_posts.ID FROM wp5_posts  WHERE 1=1  AND wp5_posts.post_type = 'post' AND (wp5_posts.post_status = 'publish' OR wp5_posts.post_status = 'expired' OR wp5_posts.post_status = 'tribe-ea-success' OR wp5_posts.post_status = 'tribe-ea-failed' OR wp5_posts.post_status = 'tribe-ea-schedule' OR wp5_posts.post_status = 'tribe-ea-pending' OR wp5_posts.post_status = 'tribe-ea-draft')  ORDER BY wp5_posts.post_date DESC LIMIT 0, 10
    [posts] => Array
        (
            [0] => WP_Post Object
                (
                    [ID] => 290909
                    [post_author] => 3
                    [post_date] => 2020-09-21 10:00:25
                    [post_date_gmt] => 2020-09-21 17:00:25
                    [post_content] => Oh, our semiconductor industry just loves acronyms, and the title of my blog packs three of the most popular acronyms together at once. I attended a webinar hosted by Aldec last week on this topic, "UVM Simulation-based environment for Ibex RISC-V CPU core with Google RISC-V DV". Verification engineers have been adopting the Universal Verification Methodology in order to make their verification results more robust, in less time.

RISC-V continues to grow in importance as an open source, Instruction Set Architecture (ISA), and at the dac.com site there are some 3,110 search results for RISC-V. I just expect this trend to continue, because engineers often want to customize aspects of their SoC for a specific purpose or domain. A big question then arises on how do you actually verify a RISC-V project.

Google has created a SV/UVM based instruction generator for RISC-V processor verification, then posted it on GitHub. There have been some 765 commits, so this is an actively supported instruction generator.

There are many RISC-V core projects around the world to choose from, and Ibex is a small, 32-bit RISC-V core, also available on Github with 1,860 commits to date.

Using Riviera-PRO Aldec simulates the UVM testbench with the Google DV random instruction generator and Ibex RISC-V core.

[caption id="attachment_290910" align="alignnone" width="1256"]UVM Testbench RISC-V Source: https://ibex-core.readthedocs.io/en/latest/verification.html[/caption]

In the testbench SV classes are blocks with rounded corners, while SV modules are shown as square corners, finally the code to be run is depicted in blue with folded corners.

Random commands come from the Google DV generator, and the testbench also has random interrupts during testing. The co-simulation flow has both an ISS and RTL loaded with test binaries, simulations are run, then the results are compared by a Python script. You can have the same verification experience if you assemble all of the pieces:
  • SystemVerilog simulator that supports UVM (i.e. Riviera-PRO)
  • Instruction Set Simulator (Spike or OVPsim)
  • RISC-V toolchain
Here's the flow of tools and files used for verification: RISC V tool flow The second half of the webinar was showing an actual, live demo of this verification flow in action, running the makefiles, scripts, simulators and comparison on a Linux platform. Batch mode verification was shown first verifying the Ibex core, then GUI mode was run next, and in both cases there were zero mismatches between the ISS and Riviera-PRO simulator results. The GUI for Riviera-PRO had multiple windows: Source code, Classes, Assertions, Messages. In the upper right is the Classes Window, showing instances and hierarchy, methods, properties, derived classes and base classes. Riviera PRO A very useful documentation feature was how a UVM graph could be auto-generated within Riviera-PRO, as it showed memory interface agents, one interrupt agent, connections, and then stepped into instances for more details to understand connectivity. UVM graph An assertions window showed all assertions in one place, without having to look at multiple files, while seeing any failures, passes, and the time when it last happened, quite useful for debugging. Next, the waveform viewer was invoked after restarting simulation, and they added waveforms from the DUT. waveform viewer Finally, they showed the RTL code coverage after simulation had finished, then generated an HTML cumulative summary. code coverage

Summary

RISC-V is one of the biggest topics of 2020 for the electronics industry, and the ecosystem continues to grow each day, but verification can be a burden. Aldec showed in this webinar how their SystemVerilog simulator along with other tools could be used in verifying a RISC-V core called Ibex. I've included links to each open source tool on Github, so go explore on your own and save some verification time, instead of starting from scratch. To watch the archived webinar, visit here.

Related Blogs

[post_title] => WEBINAR: UVM RISC-V and DV [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => uvm-risc-v-and-dv [to_ping] => [pinged] => [post_modified] => 2020-09-21 08:52:24 [post_modified_gmt] => 2020-09-21 15:52:24 [post_content_filtered] => [post_parent] => 0 [guid] => https://semiwiki.com/?p=290909 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 290691 [post_author] => 28 [post_date] => 2020-09-21 06:00:28 [post_date_gmt] => 2020-09-21 13:00:28 [post_content] => MuriloPessatti PhotoMurilo Pilon Pessatti is an Electrical Engineer with a MSEE in Analog IC design. He studied in Brazil at São Paulo University (USP) and earned a masters at Campinas State University (UNICAMP). Murilo then moved to Lisbon in Europe to work for ChipIdea, in the early 2000's when the smartphone era was just taking off. "I had the distinct pleasure to work in one of the first first Analog IP companies, where I had the chance to learn a lot and very fast about Power Management for portable devices. I came back to Brazil and after spending 2 years in a public semiconductor company and decided to start Chipus." Please tell me about Chipus Chipus is a mixed-signal IC design company. We have strong analog expertise, mixed up with significant know-how in digital state-of-the-art technologies. We help our customers to develop the next generation of key IoT, Industrial, Sensors, AI and RF/Optical Communication ASICs. In these almost 12 years since we started the company we had the opportunity to develop almost 400 IPs in mixed-signal areas, tapeout lots of projects, develop very interesting full turn-key ASICs and have a lot of fun working with very challenging and smart customers -- something that really motivates us! What problems does Chipus solve?  Chipus was born with the power-aware mindset. Since the beginning in 2009 when we started building our IP portfolio, we pushed the limits to deliver the lowest power IPs and ASICs. So definitely, when the whole IoT and AI wave hit the market, we were very well positioned to solve all the power related problems based on the IPs and experience we accumulated in the last decade. The key approach and differentiation we have is based on our solid expertise and know-how in operating transistors in weak and moderate inversion. We have both practical ( many tape-outs our team have done dealing with very low power circuits) and solid theoretical experience and background in this field (we are lucky to have a group of researchers in the university very close to us that has developed one of the most accurate charge-based physical models operating in all-region). Adding all of this on top of the portfolio of IPs we have created in the last decade put Chipus in the lead position to solve key power-related problems in IoT and AI to the edge systems and ASICs. We started back in early 2009 building our IP portfolio and as we start gaining credibility from the market by licensing our IPs, our customers start to ask us to help them integrate ours and 3rd Party IPs in their SoCs. We end up not only helping them but also start providing a kind of differentiated design services for customers that really need a high quality team working very close and collaboratively with their SoC architects. At the same time, we start expanding our IP offering, to the point that nowadays we also have high-speed and high-precision building block IPs. Because all these IPs and SoCs had also significant digital blocks, we also built a very experienced digital team that gained a lot of traction in the recent years providing full RTL-to-GDSII flow in state-of-the-art technologies. Last but not least, it was very natural in the last years for Chipus to extend our high quality integration IP services to a complete full ASIC offer, that we start to see a big momentum in different market segments, not only in IoT, industrial but also RF/optical communication. How has the market changed for Chipus in the past 10 years? I see all of the high dynamics in the semiconductor M&A area as a big opportunity to Chipus. But the most important thing for us is to continue doing our high quality work for our customers, even when these customers are merged or acquired by other companies, most of the time we keep working with them, and sometimes our business even grows as they merge with other bigger companies. We are always searching for new challenges and to find out how we can give the best support to our customers, so that all of this market consolidation did not really affect our business and goals as a company. I do believe that IoT, AI to the edge and optical communication are very promising market segments. It is easy to understand: more and more all these "things" are portable and more functionalities need to be done on the edge to be real time. On the other hand, all those things end up putting lots of bits on the internet, which simply cannot afford to use copper anymore. All of this with just some "pico-joules" of energy to make sure batteries last long. That is for me a big opportunity to solve key problems. What type of customers does Chipus look for? We have all types of customers, we never give up to offer the best quality, does not matter the size of the customer, we will be there. We have worked with some small start-ups that end up having very significant exits and become part of big companies. Sometimes we have customers that we license some IPs, sometimes we have customers that need help in a key project in which we come in and increase their capability to solve problems, and sometimes we have customers that want us to develop a full turn-key ASIC. The common point is that in almost all the cases, those customers come back and ask us again for our support. We have some long term customers for who we work constantly and for a long term period. We always see our customers and the business as a relationship and not as a transaction. We expect for a typical customer the same. Time-to-market, first-time-right and price are for sure a big concern from customers. Especially when we have the first interactions with the customers these requirements are more prominent. As far we start the engagement and the trust is developed, things tend to go more smoothly and the most important thing is to be lined up with the long term objectives and goals of the customers. We usually work in very close relationships with our customers long term goals. About Chipus Chipus Microelectronics (ISO 9001:2015 certified) is a semiconductor company focused on the development of mixed-signal ASICs, intellectual property (IP) blocks and IC design services. The company has more than 200 analog IP blocks in process nodes from 22nm to 0.35um of various foundries. Since its foundation in 2008, Chipus has worked with customers worldwide (South and North America, Europe, and Asia) with firm commitment and flexible client support. Besides analog and mixed-signal expertise, Chipus also offers custom digital IC design services having successfully delivered designs in 7nm from RTL to backend. Headquartered in Florianópolis, Brazil, Chipus has a US subsidiary in Silicon Valley and sales teams in both USA and Europe. For additional information on Chipus or its services, please contact us here. [post_title] => CEO Interview: Murilo Pilon Pessatti of Chipus Microelectronics [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => ceo-interview-murilo-pilon-pessatti-of-chipus-microelectronics [to_ping] => [pinged] => [post_modified] => 2020-09-20 18:16:36 [post_modified_gmt] => 2020-09-21 01:16:36 [post_content_filtered] => [post_parent] => 0 [guid] => https://semiwiki.com/?p=290691 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 291115 [post_author] => 29972 [post_date] => 2020-09-20 10:00:46 [post_date_gmt] => 2020-09-20 17:00:46 [post_content] => Moortecs Law No-one likes being put on the spot and yet we all like a forecast…and as we all know, the only guarantee with a forecast is that it is wrong. Sports commentators have carved out a special niche for themselves with the ‘commentators curse’, just as they extol the virtues of an individual or a team, the sporting gods prove them wrong in spectacular fashion! Governments are no better…economic forecasts don’t usually hold for more than a quarter, which is what makes Gordon Moore’s prediction all the more impressive. I’m sure everyone in our industry is familiar with Moore’s Law… while at Fairchild Semiconductor in 1965 he was asked to contribute to the 35th anniversary Electronics Magazine with a prediction for the future of the semiconductor components industry over the next 10 years…his response was ‘the number of transistors in a ‘dense IC’ would double every two years’! What a prediction, it was correct for the next 50 years and is only now starting to ‘fade’, surely the SWAG* to beat all SWAGs?! So what has Moore’s Law got to do with Moortec? Broadly speaking he predicted that over time transistor density would increase, so more could be put on anyone device…and predictably devices would grow. This wasn’t really an issue in the early days, when geometries were measured in micrometres, in fact all the way down to 40nm there weren’t any major issues, it was the transition from planar to FinFET technology where things started to change. The bit Gordon wasn’t too explicit on was the change in leakage current as we ride the geometry wave, leakage current starts to become an issue in FinFET and is just plain ugly sub 7nm, add to which the chip sizes grow significantly as the applications of the day try to maximise the benefits of these plentiful transistors. Ok, big deal…chips get bigger, leakage increases, power density is now also increasing with the ‘end’ of Dennard Scaling, you don’t need to be Nostradamous to predict that things will start to warm up a little. Yet that isn’t the only effect you’ll be seeing, temperature is a first order effect…as the heat rises so data throughput drops, power consumption increases and so the cycle builds on itself.  Second order effects then come into play, the silicon starts to age, reliability takes a hit and can have knock-on effects into your system reliability and overall performance. Great man though he was, Gordon didn’t mention any of that. So here is where Moortec’s Law comes in (just for the record, I’m not claiming it will last 50 years!)…‘the number of sensors used in a ‘dense IC’ will (at least) double per geometry shrink’. There is a second Law (as with Gordon, he too had a second, less well known Law), ‘the number of sensors used in individual designs will rise exponentially as engineers appreciate the information they can divulge in mission mode’! The proliferation of sensors in SoCs will not only be driven by better understanding of the value of the data they provide, but also a deeper appreciation of the type of data they can provide in different areas of a design. Imagine baking a souffle in an oven without a glass door, you are blind to what is happening inside. You’ve followed a recipe and yet you can’t be sure the eggs were a uniform size or the flour was a consistent strength or that the oven holds it’s temperature evenly throughout the cooking process…until you open the oven door, you don’t know what to expect…open it too soon and it will sink, too late and it will have burnt! SoCs are no different, except the cost of failure is many orders of magnitude greater, that ‘mission mode’ visibility the glass door provides is no different from having 10s, 100s or even 1000s of sensors in your device. *Scientific Wild-Ass Guess In case you missed any of Moortec’s previous “Talking Sense” blogs, you can catch up HERE. WEBINAR: Addressing the Challenges of Hyper-scaling within Data Centers with Advanced Node Embedded Sensing Fabrics [post_title] => From Moore’s Law to Moortec’s Law! [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => from-moores-law-to-moortecs-law [to_ping] => [pinged] => [post_modified] => 2020-09-21 07:50:38 [post_modified_gmt] => 2020-09-21 14:50:38 [post_content_filtered] => [post_parent] => 0 [guid] => https://semiwiki.com/?p=291115 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [3] => WP_Post Object ( [ID] => 290251 [post_author] => 30784 [post_date] => 2020-09-20 06:00:51 [post_date_gmt] => 2020-09-20 13:00:51 [post_content] => Protocol in Depth Ethernet Many times i notice people "kind of afraid" of some protocol, trying to avoid the usage because "it's complicated", I decide to go in-depth in one and show that maybe it's not so complicated after all. First challenge is choosing the protocol and decide about the Ethernet, because this protocol has many challenges in my mind, and it's well-known, old, has many standards, have misconceptions that another protocol, like USB or HDMI don't. WARNING I'll try to show the protocol in low-level (bit level) in few words possible, many things will be missing in this text, so don't use this text to do any ethernet work related. The Ethernet was started in 1973, but only in 1990 was released the standards IEEE 802.3i that is known as Ethernet 10BASE-T or "10Mbit Ethernet", and the first point is that there were some standards before, like the DIX Ethernet, StarLAN and LattisNET. I don't think theses protocols are used today, so I'll ignore them and focus only on the IEEE 802.3i, that I'll call "Ethernet". Other point is the IEEE 802.3 standard, is a collection of standard so, we have Ethernet over Coax cable, twisted pair, Fiber-Optic, and many other options. Again the focus is the 10BASE-T (10 is refer of 10Mbit, the BASE refer signaling BASE or BROAD and T refer twisted pair). The ethernet standard 802.3i will cover only the physical and data link of the OSI model, but in the data link layer will be divided into MAC (media access control) and LLC (logical link control), the 802.3i only cover the MAC layer, don't cover the LLC layer, this is cover in 802.2. For a designer that want to include the ethernet in your project (Considering a IC Designer) you will need design theses. Physical layer (Mostly Analog IC Designer) All communication is transmitted by a differential driver and will have the deal with some encoded data in and out as the control in and out. All data will be encoded in Manchester encode and will communicate in full-duplex or half-duplex. Media Access Control Layer (Digital IC Designer) Uses CSMA/CD control access and will receive and send a frame that will be describe below: 1 - Preamble 2 - SFD 3 - Destination Address 4 - Source Address 5 - Length/Type 6 - MAC Client data / PAD (Payload) 7 - Frame Check Sequence 8 - Extension (optional) 1 - Preamble is a 7 bytes(56 bit) that is sent to allow the PHY layer reaches a steady state, these bytes is: 10101010 10101010 10101010 10101010 10101010 10101010 10101010 2 - SFD is the Start Frame Delimiter show the start of the frame, this is one byte (8 bit): 10101011 3 and 4 - Destination and Source Address, both is an 6 bytes (48 bit), that theoretically represent a unique identifier for each equipment. 5 - This can represent two types of data, in 2 bytes (16 bits) the length or type of the following data. 6 - This is the data to be sent, or message, can be 46 to 1500 bytes long (368 to 12000 bits) and at the end is included a PAD. Any other protocol will be in it. 7 - This is a CRC calculation of the Destination and source address, length/type field and data/pad field, and is attached in the end of data/pad field, that has 4 bytes (32 bits) long. 8 - It's not transmitted in half-duplex mode, is transmitted until complete the time frame. There are many controls and processes that the MAC Layer will execute, but i don't think this will very interesting to show in this post. And there is no way that i can show every detail of the standard in some small internet post. But as you can see, isn't complicated to implement, sometimes it's hard to get some information if it's old, or maybe pay for the standard and understand it. It's totally possible to a designer implement any standard, the most complicated is understand the standard that is written not in a very practical way, this need practice to understand it. [post_title] => Protocol in Depth - Ethernet [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => protocol-in-depth-ethernet [to_ping] => [pinged] => [post_modified] => 2020-09-19 17:06:10 [post_modified_gmt] => 2020-09-20 00:06:10 [post_content_filtered] => [post_parent] => 0 [guid] => https://semiwiki.com/?p=290251 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [4] => WP_Post Object ( [ID] => 291071 [post_author] => 28 [post_date] => 2020-09-18 10:00:41 [post_date_gmt] => 2020-09-18 17:00:41 [post_content] => Menta Adaptive Design eFPGA Webinar 1 Since the start of PROMS, PLDs and FPGAs we have learned the importance of programmability in modern semiconductor design. Today we have eFPGAs for “design adaptive” embedded programmability and that is what this webinar is all about. Several key points are discussed starting with the Law of Accelerating Returns as it applies to integrated circuits followed by Semiconductor Trends, the Makimoto Wave, and Design Cycles & Rhythms of Change. This is a great overview for the young and old, absolutely. We then dig into the nuts and bolts of FPGA, ASIC, SoC, Processors and  eFPGAs followed by the Menta Design Adaptive eFPGA IP and the benefits of programmable logic without the pain. The speaker is Yoan Dupret, whom I met at the Design Automation Conference a few years back. Yohan is an innovator with a PhD and more than 15 years experience in the semiconductor industry including various management and technical positions in companies such as DelfMEMS, Samsung, CSR, Infineon and Altis Semiconductor prior to Menta. In addition to his embedded FPGA expertise, Yoan worked on topics such as RF MEMS design, EDA, PDK, MOS and passives RF modeling, statistical simulation and manufacturing yield modeling. As I have mentioned before, it is a privilege to work with so many incredibly intelligent people inside the semiconductor ecosystem and Yoan is one of those people, absolutely. Register HERE and get the replay after the broadcast. Abstract: Despite the current health crisis, we are living through an unprecedent era of innovation - and this is not going to slow down as well captured by the law of accelerating returns. Disruptive and rapid change is now the new constant. The rate of architectural and algorithmic innovation is outpacing traditional chip development cycles. This is not only true for AI, but also for communication protocols, encryption, compression, interconnect fabrics and cybersecurity. The old world order of computing has now fractured beyond recognition. Now is the time to design chips to be at least partially reconfigurable to adapt to emerging needs. Embedded programmable logic, in the form of embedded FPGA (eFPGA) IP, is now making its way in SoCs as an answer to these challenges, with multiple design wins announced by the main eFPGA IP providers. In this webinar, we will explain what makes an eFPGA different to a FPGA but also to embedded CPUs/GPUs - and in which cases an eFPGA IP is the way to go. We will then explain what is a design adaptive eFPGA IP and why this adaptiveness is so important when it comes to integrating an eFPGA IP. Here are the questions I have for the Q&A. Send me your questions and I will make sure they are answered:
  • If I have RTL working on an off the shelf FPGA, how hard is it to port it to a Menta eFPGA IP?
  • You mention foundries, do you work with IDMs as well?
  • What kind of applications are run by your customers?
  • Is there a way to secure the bitstream?
  • Any export limitations?
  • What percentage of the chip is usually taken by the eFPGA?
Register HERE and get the replay after the broadcast. About Menta Menta is a privately held company founded in 2007 in France. The company delivers 100% third party standard-cells embedded FPGA IPs for SoC, ASIC or ASSP designs. Our technology lets you effortlessly update your silicon post-production, whether to fix a bug, implement customer-specific features, adapt to evolving standards, or enhance security.  Menta IPs are delivered with the Origami toolchain to generate the bitstream from RTL, including synthesis. Menta is backed by FJ Development EN, with an investment of more than $7M to date. [post_title] => WEBINAR: Design Adaptive eFPGA IP [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => webinar-design-adaptive-efpga-ip [to_ping] => [pinged] => [post_modified] => 2020-09-17 13:12:19 [post_modified_gmt] => 2020-09-17 20:12:19 [post_content_filtered] => [post_parent] => 0 [guid] => https://semiwiki.com/?p=291071 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [5] => WP_Post Object ( [ID] => 291025 [post_author] => 11321 [post_date] => 2020-09-18 06:00:56 [post_date_gmt] => 2020-09-18 13:00:56 [post_content] => It was a very late evening, perhaps 11 PM, on a warm summer night in 2008. Someone sent an email to info@cliosoft.com with a very odd question - why were we not listed in Wikipedia? The sender was a scientist working for the Lawrence Berkeley National Lab. Of course, this piqued my curiosity and I replied back asking why that concerns him so much? After a few email exchanges, I found out that his team was collaborating with scientists in several other research organizations in Europe to design the Atlas detector for the Large Hadron Collider in Switzerland.  They were using the Cadence Virtuoso platform for analog mixed-signal design and looking for a design management solution to help collaborate and share design data efficiently. Of course, being a research organization, they had limited budgets. This seemed like an absolutely worthy project to be associated with and the Cliosoft Academic program was born! Here is a paper in EDN magazine with more information about this project. We were a small company and we really did not have the resources to promote and nurture an Academic program. However, purely through word of mouth, we got requests for academic licenses from Nikhef in the Netherlands and DESY and the RWTH Aachen University in Germany in 2009. In 2011, two of Europe’s premier research organizations, CERN in Switzerland and CNRS in France adopted the Cliosoft SOS platform. Academic requests started trickling in at a much faster rate, mostly from Europe, even though our Academic program wasn’t even mentioned on our website. Many of them were physics researchers collaborating with one or more of the research organizations using Cliosoft SOS. Dr. John McLean, Head, Microelectronics Support Centre and Manager Europractice Design Tool Service, came to our DAC booth in 2016. We were surprised by this as our previous attempts to get listed with Europractice had, to be honest, fallen on deaf ears. Europractice supports only a select few EDA vendors and they did not have much interest in a design management vendor.  John was blunt and honest with us. I am paraphrasing, but he said something along the lines of “We didn’t think that there was a big enough interest, but it appears that the Physics community in Europe has standardized on your solution”. The power of physics is how Cliosoft made it to the select list of EDA vendors supported by Europractice. It took a little while for word to cross the pond but now we have research organizations and universities in North America using our design management solutions. These include research organizations such as Brookhaven Labs, Stanford SLAC, and Triumf, and universities such as Cornell, SMU, Pennsylvania, and UC Santa Cruz. Since that summer night in 2008, this program has been a special child for me. I feel proud and honored that some of the best minds in the world actually use our software to explore the nature of the universe. While pottering around in COVID-19 isolation, I realized that we now have over 40 academic institutions using our software to help with their deep scientific research. I thought I would write this blog to celebrate that milestone. I reached out to several of the scientists to find out what type of work they are doing and how Cliosoft’s SOS has helped them. Listed below are quotes from some of the smartest people we have had the honor of working with. If you are engaged in academic or research activities and would like to license our software through our academic program then contact us by emailing: edu@cliosoft.com

Wojciech Bialas

  • Engineer/CAD Manager, Experimental Physics Department
  • CERN - European Organization for Nuclear Research
Microelectronics section at CERN is principally involved in the design of a variety of ASICs related to four major LHC experiments of general purpose: ATLAS, CMS and specialized ones: ALICE, LHCb. Starting to use Cliosoft suite of tools by our community was clearly a turning point for us. It came really at the right moment. We were in the middle of electronics design challenge for LHC experiments planned upgrades, where the complexity of ASICs foreseen went up by an order of magnitude from what we were doing before. Microelectronics engineers in the High Energy Physics (HEP) community were geographically and institutionally very much dispersed. Collaboration on these demanding projects in that conditions was really difficult. The Cliosoft SOS solution met perfectly our needs, introducing smooth data exchange between HEP community designers. It also brought us design exploration solutions. Inside our CERN microelectronics section we de facto made Cliosoft data management a standard. Considering all these benefits, nowadays all our projects are receiving SOS data management configuration by default. By using it we simply started to be more efficient in our work.

Maurice Garcia-Sciveres

  • Senior scientist, Physics Division, Lawrence Berkeley National Laboratory
ASICs are an integral part of particle physics experiments and many PhD students are involved in IC design projects. However, particle physics experiments are also carried out by large collaborations of people from many institutions all over the world. The ATLAS.ch experiment, for example, has over 1000 PhD students from 180 institutions. People working on a particular ASIC design will generally not be co-located. Collaboration tools are essential to enable students to work on real ICs that will be used in the experiment. Over the past decade, Cliosoft’s SOS has become the standard tool for integrating particle physics ASICS, greatly enhancing student involvement. Here are just a few of the projects I was involved in: Luca Pacher, University of Torino, PhD 2015: “Development of Integrated Pixel Front-End Electronics in 65 nm CMOS Technology for Extreme Rate and Radiation at HL-LHC”, developed digital control and readout for high rate pixel detectors. Project was organized with Cliosoft leading to final submission in 2017. Ennio Monteil, University of Torino, PhD 2017:  “Front-end electronics in 65nm CMOS technology for the HL-LHC upgrade”, has been working on the design of an analog front-end in 65nm CMOS technology inside the CERN RD53 collaboration. This activity relied on Cliosoft for chip integration. Sara Marconi, Perugia University, PhD 2018: “Design and optimization of low power hybrid pixel array logic for the extreme hit and trigger rates of the Large Hadron Collider upgrade”, designed digital elements and developed UVM verification framework for pixel readout circuit. Full design managed on Cliosoft. Tomasz Hemperek, Bonn U. PhD 2018: "Exploration of advanced CMOS technologies for new pixel detector concepts in High Energy Physics", Development of radiation hard monolithic pixel sensors that can replace hybrid pixel sensors in high energy physics experiments in various technologies (110-180nm). Most using Cliosoft. Veronica Wallangen, U. of Stockholm PhD 2019: “Performance Improvements for Particle Tracking Detectors in Extreme Rate and Radiation Environments”. Designed a 65nm CMOS DFE circuit for 5Mbps NRZ transmission, which was included in a test chip assembled and submitted by collaborators at Southern Methodist University, via Cliosoft. Cesar Gonzalez-Renteria, UC Berkeley PhD in progress: Worked on digital verification of 65nm CMOS pixel readout chip. Mostly RTL code, but relying on Cliosoft for chip integration. Piotr Rymaszewski, Bonn U. PhD in progress:  "Design and characterization of pixel IC electronics and sensors for a new pixel detector generations", Development of radiation hard IP  in 65nm inside the CERN RD53 collaboration and radiation hard monolithic pixel sensor in 150nm technology for ATLAS like environment (LF-Monpix series). Both using Cliosoft. Kostas Moustakas, Bonn U. PhD in progress: "Development of Depleted Monolithic Active Pixel Sensors with Small Collection Electrode for LHC'', Development of radiation hard IP in 65nm inside the CERN RD53 collaboration and radiation hard monolithic pixel sensor in 180nm technology for ATLAS like environment (TJ-Monopix series). Both using Cliosoft.

Nick Van Helleputte

  • R&D Manager, Biomedical circuits and system, imec
Our team focuses on analog-mixed-signal ASIC design for ultra-low-power biomedical applications. As our team has grown, so did the complexity of our ASIC designs. While initially our research focused on analog readout circuits for various biomedical parameters, we gradually moved towards highly integrated true SoCs with analog readouts, analog-to-digital converters, digital signal processing, power management and wireless communication capabilities all in single-chip solutions. This eventually meant larger design teams and multiple collaborators, sometimes spread across different countries. It became clear that to ensure successful and efficient design, we needed a suitable design management tool. We opted for Cliosoft SoS and never regretted this decision. Version control is an integral part of a decent quality assurance design flow and is extremely well implemented in SOS. In addition, it allows efficient collaboration across multiple teams. Roll-back to previous versions and design IP re-use are features we have come to rely upon on a daily basis. However, Cliosoft SOS did not only prove to be valuable for these large ambitious projects. After seeing the benefits SOS offered in our larger research projects, while still being easy to set up and intuitive to use, we decided to make it part of our standard design flow for all design projects. Roughly half of our ASIC designs are PhD researchers who are often working on a research topic by themselves or in a smaller group of 2 to 3 designers. They are now also using Cliosoft SOS. This has proven extremely efficient as our PhD researchers can now more efficiently share common design libraries and it has become much easier to involve extra resources close to tape-outs to help the students out when needed. And last but not least, the hard research effort is so much easier to integrate into our various research programs after the PhD finishes.

Barend Van Liempd

  • Program Manager Radar ICs, imec
At Imec's IoT department, all our circuit design projects (focus on high-capacity wireless network circuits and radar chip designs) in a variety of technology nodes are maintained on Cliosoft SOS. We started using it in year 2016 and it has been a satisfying experience so far. Before the use of Cliosoft, designers had a number of “best practices”, including local libraries and include all the libraries in the cds.lib. With Cliosoft SOS in place, we have optimized and improved on this workflow, and thus have increased productivity. The number of Cadence libraries are reduced considerably and so is the library management. It also resulted in better collaboration among the team, as everyone is working on a limited number of Cadence libraries. The managed libraries helped multiple users to work on the same cell. The Cliosoft SOS integration with Cadence Virtuoso is smooth. The customer support has been excellent. The technical staff was able to resolve our issues/concerns on time.

Coronavirus crisis effect on tapeouts?

Since the design work-flow was version controlled, the coronavirus crisis did not adversely affect our work-flow and we had successful tape-outs according to planned milestones.

Patrick Pangaud

  • Responsable du Service Electronique - Head of the Department of Electronics
  • CENTRE DE PHYSIQUE DES PARTICULES DE MARSEILLE
  • UMR 7346 - Aix-Marseille Université - CNRS/IN2P3
For more than 10 years, the laboratories of IN2P3 (https://in2p3.cnrs.fr/en)  (a CNRS institute) have been using CLIOSOFT tools for their realizations dedicated to physics experiments. IN2P3 develops its research programs in Astroparticles, Particle Physics, Nuclear Physics through 25 laboratories and platforms with a staff of 2500 researchers and engineers. The first project started in 2008, with the contribution of CPPM (one IN2P3 laboratory) to the effort on the FE-I4 project. This readout chip was made for the upgrade of the pixel detector of the CERN ATLAS particle physics experiment, led by the LBNL with implications of CPPM, Bonn University, NiKHEF, Genova University.  The SOS tool was the solution to share and build blocks all together all over the world. After this successful realisation, IN2P3 decided to get tokens for all its laboratories. IN2P3 applications are designed by 14 teams spread all over France in a microelectronics cluster with a unified management:  regular internal meetings, training program and school, sharing knowhow, common CAD tools, sharing technologies and IP exchanges… Using Cliosoft SOS design management allows us to build very large teams with specific expertise coming from laboratories all over the world. Indeed, our engineers participate with other relevant teams from LBNL, Fermilab, CERN, Bonn University, the Italian INFN laboratories, Nikhef, CEA-IRFU and even more for the upgrade of the next physics experiments with an important contribution to the Large Hadron Collider (LHC) detectors' upgrades, based in CERN, Geneva. We can quote in recent years the RD53 project for the ATLAS and CMS inner detectors' upgrade, or the HGCROC for the CMS High Granularity Calorimeter, among others. Engineers also contribute to Societal Applications: Beam profiler for radiation therapy, medical imaging, Compton camera, dosimetry…and they participate to international R&D and academic programs like CERN's initiatives for R&D on Experimental Technologies as RD50 (Radiation hard semiconductor devices for very high luminosity colliders, 2018) and RD53 (Development of pixel readout integrated circuits for extreme rate and radiation, 2013), European Framework program H2020 : ATTRACT (2018) and  AIDA (2011) or  3D-IC (three-dimensional integrated circuit, 2009).

Roberto Beccherle

  • Technology Researcher, INFN - Istituto Nazionale di Fisica Nucleare
We work for an upgraded version of the Pixel Detector readout ASIC, for ATLAS and CMS experiments at the LHC at CERN, within the RD53 collaboration.Being an academia research team, our design team is split across many countries both in US (LBNL) and Europe (Bonn, Marseille, Paris, Pisa, Bari, Torino, Bergamo/Pavia), and assembling such a complex design, in our distributed working environment would have been literally impossible without daily usage of Cliosoft's SOS seamless integration features that allow remote designers to effectively work and collaborate on a distributed chip development.

Ruud Kluit

  • Group leader Electronics Technology, Nikhef
Nikhef is the Dutch National Institute for Sub-atomic particle physics, and in this field of physics, Nikhef does fundamental research on known and yet unknown (predicted) particles. For this, instrumentation, like particle accelerators, and detectors are needed, and these are the technical systems Nikhef engineers, technicians and scientists work on. Since the detectors are often in a radiation environment, the electronics, and also sensors (detectors) with their readout IC's, need to be able to operate under irradiation. This requires specific expertise, and this is spread over the world wide sub-atomic physics community in which we operate. So, in order to develop the ASIN's, we always need a collaboration of engineers, and so a smooth exchangeability of design- parts and files is required to develop the ASIC's efficiently together. In one of such a collaboration, Nikhef (Netherlands) together with Berkeley National Laboratories (US), the university of Bonn (Germany) and Marseille (France), we started exploring the Cliosoft tools in May of 2008. In the years after we experienced the power of such a tool and the ease to interactively exchange design parts, which we experienced to be very efficient for the design process. Later on, SOS (name of the tool), was used in more projects, where several engineers work on one ASIC, collaboration became increasingly important due to the increasing complexity of the ASIC's and tools. But even in the case where a single engineer does the design, the use of version management is very efficient. Another advantage is the easy synchronisation of the latest PDK versions and tool options for the designers in a team.

David Gascón Fora

  • Associate Professor, University of Barcelona
  • Director of the Technology Unit of the Institute of Cosmos Science of the UB (ICCUB)
    • http://icc.ub.edu/technology/unit.
ICCUB is focused on the development of scientific instrumentation for High Energy Physics and Astrophysics, among other fields. We have been developing the front end electronics for the calorimeter and scintillating fiber tracker detectors. This involves the design of radiation-tolerant Application-Specific Integrated Circuits (ASICs) for the LHCb experiment at CERN (https://lhcb-public.web.cern.ch/). The ICCUB-TECH has also designed  ASICs for some of the cameras of the Cherenkov Telescope Array Observatory (https://www.cta-observatory.org/): a preamplifier (PACTA), two amplifiers (ACTA/MUSIC) and a trigger unit (L0). We work in highly cooperative projects. Hence we use Cliosoft’s SOS solution, both internally, as the design management system for ASIC design, and also to collaborate with our colleagues at CERN and other European institutes. A design management tool like SOS is mandatory in collaborative projects. Moreover, the fact that SOS is integrated into the native library manager is extremely helpful.

Paul Hyland

  • Operations Manager, MCCI - Microelectronic Circuits Centre Ireland, Tyndall National Institute
Microelectronic Circuits Centre Ireland is in the “business” of academic research. We want to enable our researchers to do world-class research and publish at top conferences. This helps their careers and excites the industry partners that follow and support our research programs. Our research is focused on analog mixed-signal and RF chip design. We rely on Cliosoft SOS to manage our Cadence design databases and to facilitate easy collaboration between multiple researchers. The version management capabilities within Cliosoft are essential for such an iterative design process as we often need to step back to older versions. We use Cliosoft to tag project databases to clearly identify different design milestones and especially what we taped out. We also have a strong desire to have our researchers use industry-standard tools such that they will be more valuable hires to industry.

Johan Bauwelinck

  • Professor at IDLab, Ghent University, in collaboration with IMEC
Our users are about 50/50 PhD students/postdoctoral researchers, all in Gent. We use the SOS design management software for managing our high-speed transceiver IC designs. The tool allows versioning not only the Cadence libraries but also Keysight ADS design files. Rolling back to a previous version is easy, and we can clearly communicate file status using tags. Moreover, this software facilitates collaborating on large projects.

Richard Leys

  • Research Associate, Karlsruhe Institute of Technology (KIT)
The ASIC and Detector Lab Group at KIT was created in 2014 by Prof. Peric, and counts roughly 10 users between Scientists, PhDs and Students. When setting up at KIT, we had to build our small infrastructure from scratch and moved straight to using SOS for data exchange. It greatly facilitated  setting up the repositories, backups and  collaboration across all user scenarios. The ability  to quickly check file status on large design databases greatly eases collaborative work, even more in a time where remote office has suddenly developed to a new standard. As members of the large High Energy Physics and Astrophysics experiments landscape, we regularly share designs with partner institutions, which is highly facilitated by the widespread adoption of SOS.

Clive Holmes

  • Deputy Head, Europractice Design Tool Service, STFC Rutherford Appleton Laboratory
Europractice provides services to the European academic sector to enable them to more easily use leading microelectronics technologies and adopt advanced design methodologies in their teaching and research.  Cliosoft's SOS integrates well and complements the existing design tools within the Europractice portfolio and better facilitates work on large, often collaborative, projects within the academic sector. academic map As seen on https://www.cliosoft.com/resources/blog/ [post_title] => The History and Physics of Cliosoft’s Academic Program! [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => the-history-and-physics-of-cliosofts-academic-program [to_ping] => [pinged] => [post_modified] => 2020-09-18 07:19:14 [post_modified_gmt] => 2020-09-18 14:19:14 [post_content_filtered] => [post_parent] => 0 [guid] => https://semiwiki.com/?p=291025 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [6] => WP_Post Object ( [ID] => 290460 [post_author] => 11830 [post_date] => 2020-09-17 10:00:40 [post_date_gmt] => 2020-09-17 17:00:40 [post_content] =>

 

Two converging trends for die to die connectivity in MCMs 1

Synopsys has released a Technical Bulletin entitled “Parallel-Based PHY IP for Die-to-Die Connectivity”. The piece is authored by Manuel Mota, senior product marketing manager, staff at Synopsys. Manuel has worked at Synopsys for 11 years in the IP area. Prior to that, he worked at MIPS Technologies, Chipidea (acquired by Synopsys) and CERN. Clearly Manuel has a lot of background in high-performance data communications, so I paid attention to this Technical Bulletin.

The piece begins with motivation for multi-chip package integration. There are two threads here. One is to integrate homogeneous die to facilitate splitting a larger chip into smaller pieces to manage fabrication yield. This approach also allows multiple SKUs of the design to be created easily by integrating different numbers of sub-chips. This is a very effective approach. While I was at eSilicon we did this kind of chip decomposition for a networking customer. The approach works quite well.

Another use of the multi-chip approach is to facilitate tight heterogeneous die integration to take advantage of process technologies that are cost-optimized for the implemented function. These two approaches are summarized in the graphic, above and this general integration approach is referred to as 2.5D.

Further decomposing the problem, there are two ways to implement communication between the die in a 2.5D design – high-speed serial (e.g., SerDes) or lower speed parallel interfaces. Synopsys offers IP to support both approaches and this Technical Bulletin focuses on the parallel approach. No matter which approach is used, several key characteristics must be met. These include:

  • Very high-energy efficiency per bit transmitted
  • Very low latency to mitigate the performance impact of splitting the functionality between the dies
  • Link reliability (bit error rate)
  • Bandwidth efficiency or the amount of die beachfront allocated to transmitting a given data rate

What type of design will be more appropriate for a parallel interface? The bulletin points out that the data rate that can be sustained across a link depends on the materials involved and the pitch. Silicon interposers can only maintain low data rates per lane of up to 6-8 gigabits per second per lane, making the use of high-speed SerDes die-to-die links unsuitable. It is here that a parallel die-to-die PHY architecture addresses the challenges of die-to-die links routed over silicon interposers.

Again, based on my experience at eSilicon, we were quite successful using our HBM PHY to integrate memory stacks on a silicon interposer. Continuing with the HBM example, the bulletin explains that, similar to high-bandwidth memory (HBM) interfaces, parallel die-to-die links aggregate up to 1,000s of pins, each transmitting data at a few Gbps. For example, if each pin can reach a data rate of 4Gbps unidirectionally, then the PHY needs 500 transmit pins and 500 receive pins to achieve a total aggregate bandwidth of two terabits per second (2Tbps bidirectional).

Given the large number of signal pins required for a parallel link, each driver and receiver need a simplistic architecture to be very energy- and area-efficient. The bulletin goes into how this is done. It also goes into area (beachfront) efficiency, robustness and testability. You will learn a lot about the comprehensive IP support Synopsys provides for parallel communication approaches. You can access Parallel-Based PHY IP for Die-to-Die Connectivity here.  You can also get the complete picture of all Synopsys DesignWare Die-to-Die PHY IP Solutions here.

[post_title] => Parallel-Based PHY IP for Die-to-Die Connectivity [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => parallel-based-phy-ip-for-die-to-die-connectivity [to_ping] => [pinged] => [post_modified] => 2020-09-16 12:51:03 [post_modified_gmt] => 2020-09-16 19:51:03 [post_content_filtered] => [post_parent] => 0 [guid] => https://semiwiki.com/?p=290460 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [7] => WP_Post Object ( [ID] => 289782 [post_author] => 16 [post_date] => 2020-09-17 06:00:32 [post_date_gmt] => 2020-09-17 13:00:32 [post_content] => Cadence has clearly found its groove with Intelligent System Design, something that Lip-Bu reinforced in the CadenceLIVE kickoff keynote on Tuesday, August 11th. Anirudh Devgan, president of Cadence, continued to discuss the theme in his keynote on Wednesday, August 12th with his equally consistent subtitle—"Strength in Computational Software”. His point being that what separates EDA from mass market software is a strong base in numerical mathematical software, in EM and thermal modeling, for example. He offers a bold prediction in asserting that while software has largely been driven by social media over the last 10 years, computational methods will be the big driver over the next 10 years. Anirudh at CadenceLIVE showed how he keeps pushing to prove that point anirudh cadencelive

Computational Verification and Logistics

Anirudh has an interesting perspective on verification, where there’s always an obsessive focus on optimizing core engines, for formal, simulation, emulation and prototyping. As there should be. These engines must be pushed to deliver the best possible core performance. But verification efficiency isn’t determined solely by that core performance. We spend more time figuring out how to get better coverage, setting engines up, analyzing results, debugging, moving between engines. Also simply running masses of regressions, over and over again. Those are also important steps to optimize. Anirudh views this need as a kind of logistics layer on top of the engines, using the engines as effectively as possible to deliver the total result you really want as quickly as possible. A good example is the Cadence Palladium/Protium dynamic duo, a close coupling between Palladium emulation for SoC debug and verification and Protium FPFA prototyping for software debug and verification. I know Cadence has done a lot of work to get the linkage between these two as seamless as possible. This is essential given the iterative progress of real verification tasks. Running in prototyping, you find a hardware issue and have to jump back into emulation to debug and then back again when patched. Making those jumps more like jumps and less like week-long interrupts is critical for efficient verification and demands smart computational logistics between engines. Another example, just announced, is machine learning (ML)-based regression optimization for Xcelium. Mike Gianfagna, a fellow SemiWiki blogger has written on this topic, so I won’t steal his thunder. The main idea is to use ML to compress regression cycles. Again, smart computational logistics optimizing between runs.

Computational Implementation and Logistics

In implementation, Anirudh is clearly proud of the company’s performance in delivering a fully integrated solution. This has become critical‚ especially for 7nm and below. Much tighter integration between engines has become essential. He sees this area equally benefiting from intelligence between the tools. As implementation teams iterate back and forth between steps, the (again smart computational) logistics layer can learn from prior steps to deliver a better optimized result each time, converging on better power and timing solutions faster than might have been possible through conventional flows. For 3DIC, Anirudh played up Cadence special strengths. One thing I didn’t know is that Cadence Allegro, the PCB solution,  is also the solution of choice for advanced packaging. Now they’re working on connections between Allegro and Innovus and Virtuoso to extend this solution. This puts them in a unique position in the industry to integrate advanced packaging with IC design.

Computational Analysis and Acquisitions

He put a lot of emphasis on analytics and simulations for these solutions. The solutions can span from board to package to die: Cadence Clarity and Celsius, Sigrity and Quartus. Application builders are demanding more optimization across the total solution, in a car for example., requiring this level of integration. Extending their design and analysis reach further, Cadence recently made two acquisitions in RF.  AWR, which provides a comprehensive RF mm wave and microwave implementation platform is now a part of Cadence. Cadence also pulled in Integrand for RFIC electromagnetic extraction for on-chip components. Both of these highly computational portfolio additions are widely popular. Cadence plans to integrate both into the portfolio. Which should be pretty interesting for 5G product builders. On a quite different note, Cadence also acquired InspectAR, a tool for augmented reality (AR) visualization on top of a PCB. Allegro is now a key area of focus, because of 3DIC. Cadence sees this technology becoming particularly important in that area. Lots of progress. I really like the continued theme of new big tech announcements each year. Can’t wait for the next one! To learn more about Cadence views on Computational Software, click HERE. [post_title] => Anirudh CadenceLIVE Plays Up Computational Software [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => anirudh-cadencelive-plays-up-computational-software [to_ping] => [pinged] => [post_modified] => 2020-09-02 15:04:47 [post_modified_gmt] => 2020-09-02 22:04:47 [post_content_filtered] => [post_parent] => 0 [guid] => https://semiwiki.com/?p=289782 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [8] => WP_Post Object ( [ID] => 291030 [post_author] => 12 [post_date] => 2020-09-16 16:00:53 [post_date_gmt] => 2020-09-16 23:00:53 [post_content] => Global electronics production is healthy, despite the COVID-19 pandemic. The chart below shows the three-month-average change versus a year ago (3/12 change) in electronics production (measured in local currency) for the major Asian producers. China is the largest electronics manufacturing country and the original source of the COVID-19 outbreak. In 2018, China electronics production growth averaged 13% versus the prior year. In 2019, the average growth dropped to 9% as some manufacturing shifted to other countries due to the trade dispute between the U.S. and China. In early 2020, China shut down many manufacturing plants in an effort to control the spread of COVID-19. As a result, 3/12 change went negative in February and March, bottoming out at -5.9% in March. China production has since recovered to 3/12 growth rates in the 11% to 12% range in May through July. Electronics Production 2020 Taiwan was a major beneficiary of production shifts out of China in 2019. Taiwan's electronics production 3/12 change averaged just about flat in 2018 before averaging 21% in 2019. Average 3/12 growth has slowed to 8% in 2020, but no significant slowdown due to COVID-19 has been shown. South Korea and Vietnam 3/12 change has been volatile over the last two and a half years. However, neither country shows any significant impact from COVID-19. Vietnam's 3/12 change did dip to -2% in January, but that was due to a slowdown which began in December 2019. Electronic production in the mature economies of the United State and European Union has shown weak to moderate growth in the last few years. U.S. 3/12 growth in 2018 averaged 4%, slowing to 0.7% in 2019. EU-27 (European Union countries excluding the UK) 3/12 growth averaged 5% in 2018 and -1.7% in 2019. 3/12 growth in the U.S. and EU has been weak in 2020, but it is difficult to say how much of this is due to the COVID-19 pandemic and how much is a continuation of previous trends. Both the U.S. and EU bounced back to 3/12 growth of 2% in July. The impact of the COVID-19 pandemic on electronics production is also demonstrated by the combined revenue trends of the two largest contract electronics manufacturers, HonHai (also know as Foxconn) and Pegatron. Both companies are based in Taiwan but have manufacturing facilities around the world. Most of their production is in China. The combined revenues dropped by more than half from NT$668 million in December 2019 to NT$299 million in February 2020. Year-to-year growth was 2% in 2019 over 2018 but declined 14% in January and February. Year-to-year growth recovered to 6% in August and revenues were NT$526 million, 94% of the average monthly revenues in 2019. According to Digitimes.com, HonHai and Pegatron are expected to see revenues peak in 4Q 2020 with the launch of new Apple iPhone models. Interestingly, the major electronics manufacturing countries in Asia had relatively low COVID-19 death rates compared to Europe and the U.S. According to Johns Hopkins University of Medicine, China's COVID-19 deaths per 100,000 population was 0.34. Vietnam and Taiwan had the lowest death rates of all countries listed. South Korea's rate of 0.71 was below the worldwide rate of 1.20. Four of the five largest European countries had rates above 46. The U.S. rate was 59.5.
The pandemic-related shutdowns have devastated many sectors of the global economy - particularly travel, tourism, entertainment, bars, restaurants, and brick-and-mortar retail stores. However, the shutdowns have contributed to the growth of some electronic devices. With numerous workplaces and schools closed or limited, more people are working and learning from home. This has driven many people to upgrade their PCs and tablets. Some households which previously did not have PCs or tablets are now acquiring them, often paid for, or subsidized by, employers or school systems. This month, IDC forecast 3.3% growth in 2020 for personal computing devices (PCs, tablets, and workstations). The smartphone market was slow in the first half of 2020 due to manufacturing disruptions and the temporary closing of many retail outlets. Smartphone demand is expected to rebound in the second half of 2020 as manufacturing returns to normal. In August, IDC revised their 2020 smartphone unit shipment forecast to a 9.5% decline compared to an expected 11.9% decline in June. Apple's expected release of its 5G iPhone 12 models in October should drive strong fourth quarter 2020 growth.
[post_title] => Electronics Production Healthy [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => electronics-production-healthy [to_ping] => [pinged] => [post_modified] => 2020-09-17 11:28:09 [post_modified_gmt] => 2020-09-17 18:28:09 [post_content_filtered] => [post_parent] => 0 [guid] => https://semiwiki.com/?p=291030 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [9] => WP_Post Object ( [ID] => 290990 [post_author] => 30510 [post_date] => 2020-09-16 06:00:07 [post_date_gmt] => 2020-09-16 13:00:07 [post_content] => A Field-Programmable Gate Array (FPGA) can implement arbitrary digital logic, anything from a microprocessor to a video generator or crypto miner. An FPGA consists of many logic blocks, each typically consisting of a flip flop and a logic function, along with a routing network that connects the logic blocks. What makes an FPGA special is that it is programmable hardware: you can redefine each logic block and the connections between them. The result is you can build a complex digital circuit without physically wiring up individual gates and flip flops or going to the expense of designing a custom integrated circuit. Die photo closeup showing the circuitry for one of the 64 tiles in the XC2064 FPGA. The metal layers have been removed, exposing the silicon and polysilicon transistors underneath. Click for a larger image. From siliconpr0n.
Die photo closeup showing the circuitry for one of the 64 tiles in the XC2064 FPGA. The metal layers have been removed, exposing the silicon and polysilicon transistors underneath. Click for a larger image. From siliconpr0n.
  The FPGA was invented by Ross Freeman1 who co-founded Xilinx2 in 1984 and introduced the first FPGA, the XC2064. 3 This FPGA is much simpler than modern FPGAs—it contains just 64 logic blocks, compared to thousands or millions in modern FPGAs—but it led to the current multi-billion-dollar FPGA industry. Because of its importance, the XC2064 is in the Chip Hall of Fame. I reverse-engineered Xilinx's XC2064, and in this blog post I explain its internal circuitry (above) and how a "bitstream" programs it. Xilinx XC2064
The Xilinx XC2064 was the first FPGA chip. Photo from siliconpr0n.
  Nowadays, an FPGA is programed in a hardware description language such as Verilog or VHDL, but back then Xilinx provided their own development software, an MS-DOS application named XACT with a hefty $12,000 price tag. XACT operated at a lower level than modern tools: the user defined the function of each logic block, as shown in the screenshot below, and the connections between logic blocks. XACT routed the connections and generated a bitstream file that could be loaded into the FPGA. Screenshot of XACT. The two lookup tables F and G implement the equations at the bottom of the screen, with Karnaugh map shown above.
Screenshot of XACT. The two lookup tables F and G implement the equations at the bottom of the screen, with Karnaugh map shown above.
  An FPGA is configured via the bitstream, a sequence of bits with a proprietary format. If you look at the bitstream for the XC2064 (below), it's a puzzling mixture of patterns that repeat irregularly with sequences scattered through the bitstream. There's no clear connection between the function definitions in XACT and the data in the bitstream. However, studying the physical circuitry of the FPGA reveals the structure of the bitstream data and it can be understood. Part of the bitstream generated by XACT.
Part of the bitstream generated by XACT.
 

How does an FPGA work?

The diagram below, from the original FPGA patent, shows the basic structure of an FPGA. In this simplified FPGA, there are 9 logic blocks (blue) and 12 I/O pins. An interconnection network connects the components together. By setting switches (diagonal lines) on the interconnect, the logic blocks are connected to each other and to the I/O pins. Each logic element can be programmed with the desired logic function. The result is a highly programmable chip that can implement anything that fits in the available circuitry. The FPGA patent shows logic blocks (LE) linked by an interconnect.
The FPGA patent shows logic blocks (LE) linked by an interconnect.
 

CLB: Configurable Logic Block

While the diagram above shows nine configurable logic blocks (CLBs), the XC2064 has 64 CLBs. The diagram below shows the structure of each CLB. Each CLB has four inputs (A, B, C, D) and two outputs (X and Y). In between is combinatorial logic, which can be programmed with any desired logic function. The CLB also contains a flip flop, allowing the FPGA to implement counters, shift registers, state machines and other stateful circuits. The trapezoids are multiplexers, which can be programmed to pass through any of their inputs. The multiplexers allow the CLB to be configured for a particular task, selecting the desired signals for the flip flop controls and the outputs. A Configurable Logic Block in the XC2064, from the datasheet.
A Configurable Logic Block in the XC2064, from the datasheet.
You might wonder how the combinatorial logic implements arbitrary logic functions. Does it select between a collection of AND gates, OR gates, XOR gates, and so forth? No, it uses a clever trick called a lookup table (LUT), in effect holding the truth table for the function. For instance, a function of three variables is defined by the 8 rows in its truth table. The LUT consists of 8 bits of memory, along with a multiplexer circuit to select the right value. By storing values in these 8 bits of memory, any 3-input logic function can be implemented.4

The interconnect

The second key piece of the FPGA is the interconnect, which can be programmed to connect the CLBs in different ways. The interconnect is fairly complicated, but a rough description is that there are several horizontal and vertical line segments between each CLB. CLB. Interconnect points allow connections to be made between a horizontal line and a vertical line, allowing arbitrary paths to be created. More complex connections are done via "switch matrices". Each switch matrix has 8 pins, which can be wired together in (almost) arbitrary ways. The diagram below shows the interconnect structure of the XC2064, providing connections to the logic blocks (cyan) and the I/O pins (yellow). The inset shows a closeup of the routing features. The green boxes are the 8-pin switch matrices, while the small squares are the programmable interconnection points. The XC2064 FPGA has an 8 by 8 grid of CLBs. Each CLB has an alphabetic name from AA to HH.
The XC2064 FPGA has an 8 by 8 grid of CLBs. Each CLB has an alphabetic name from AA to HH.
  The interconnect can wire, for example, an output of block DC to an input of block DE, as shown below. The red line indicates the routing path and the small red squares indicate activated routing points. After leaving block DC, the signal is directed by the first routing point to an 8-pin switch (green) which directs it to two more routing points and another 8-pin switch. (The unused vertical and horizontal paths are not shown.) Note that routing is fairly complex; even this short path used four routing points and two switches. Example of a signal routed from an output of block DC to block DE.
Example of a signal routed from an output of block DC to block DE.
  The screenshot below shows what routing looks like in the XACT program. The yellow lines indicate routing between the logic blocks. As more signals are added, the challenge is to route efficiently without the paths colliding. The XACT software package performs automatic routing, but routes can also be edited manually. Screenshot of the XACT program. This MS-DOS program was controlled via the keyboard and mouse.
Screenshot of the XACT program. This MS-DOS program was controlled via the keyboard and mouse.
 

The implementation

The remainder of this post discusses the internal circuitry of the XC2064, reverse-engineered from die photos.5 Be warned that this assumes some familiarity with the XC2064. The die photo below shows the layout of the XC2064 chip. The main part of the FPGA is the 8×8 grid of tiles; each tile holds one logic block and the neighboring routing circuitry. Although FPGA diagrams show the logic blocks (CLBs) as separate entities from the routing that surrounds them, that is not how the FPGA is implemented. Instead, each logic block and the neighboring routing are implemented as a single entity, a tile. (Specifically, the tile includes the routing above and to the left of each CLB.) Layout of the XC2064 chip. Image from siliconpr0n.
Layout of the XC2064 chip. Image from siliconpr0n.
  Around the edges of the integrated circuit, I/O blocks provide communication with the outside world. They are connected to the small green square pads, which are wired to the chip's external pins. The die is divided by buffers (green): two vertical and two horizontal. These buffers amplify signals that travel long distances across the circuit, reducing delay. The vertical shift register (pink) and horizontal column select circuit (blue) are used to load the bitstream into the chip, as will be explained below.

Inside a tile

The diagram below shows the layout of a single tile in the XC2064; the chip contains 64 of these tiles packed together as shown above. About 40% of each tile is taken up by the memory cells (green) that hold the configuration bits. The top third (roughly) of the tile handles the interconnect routing through two switch matrices and numerous individual routing switches. Below that is the logic block. Key parts of the logic block are multiplexers for the input, the flip flop, and the lookup tables (LUTs). The tile is connected to neighboring tiles through vertical and horizontal wiring for interconnect, power and ground. The configuration data bits are fed into the memory cells horizontally, while vertical signals select a particular column of memory cells to load. One tile of the FPGA, showing important functional units.
One tile of the FPGA, showing important functional units.
 

Transistors

The FPGA is implemented with CMOS logic, built from NMOS and PMOS transistors. Transistors have two main roles in the FPGA. First, they can be combined to form logic gates. Second, transistors are used as switches that signals pass through, for instance to control routing. In this role, the transistor is called a pass transistor. The diagram below shows the basic structure of an MOS transistor. Two regions of silicon are doped with impurities to form the source and drain regions. In between, the gate turns the transistor on or off, controlling current flow between the source and drain. The gate is made of a special type of silicon called polysilicon, and is separated from the underlying silicon by a thin insulating oxide layer. Above this, two layers of metal provide wiring to connect the circuitry. Structure of a MOSFET.
Structure of a MOSFET.
  The die photo closeup below shows what a transistor looks like under a microscope. The polysilicon gate is the snaking line between the two doped silicon regions. The circles are vias, connections between the silicon and the metal layer (which has been removed for this photo). A MOSFET as it appears in the FPGA.
A MOSFET as it appears in the FPGA.
 

The bitstream and configuration memory

The configuration information in the XC2064 is stored in configuration memory cells. Instead of using a block of RAM for storage, the FPGA's memory is distributed across the chip in a 160×71 grid, ensuring that each bit is next to the circuitry that it controls. The diagram below shows how the configuration bitstream is loaded into the FPGA. The bitstream is fed into the shift register that runs down the center of the chip (pink). Once 71 bits have been loaded into the shift register, the column select circuit (blue) selects a particular column of memory and the bits are loaded into this column in parallel. Then, the next 71 bits are loaded into the shift register and the next column to the left becomes the selected column. This process repeats for all 160 columns of the FPGA, loading the entire bitstream into the chip. Using a shift register avoids bulky memory addressing circuitry. How the bitstream is loaded into the FPGA. The bits shown are conceptual; actual bit storage is much denser. The three columns on the left have been loaded and the fourth column is currently being loaded. Die photo from siliconpr0n.
How the bitstream is loaded into the FPGA. The bits shown are conceptual; actual bit storage is much denser. The three columns on the left have been loaded and the fourth column is currently being loaded. Die photo from siliconpr0n.
  The important point is that the bitstream is distributed across the chip exactly as it appears in the file: the layout of bits in the bitstream file matches the physical layout on the chip. As will be shown below, each bit is stored in the FPGA next to the circuit it controls. Thus, the bitstream file format is directly determined by the layout of the hardware circuits. For instance, when there is a gap between FPGA tiles because of the buffer circuitry, the same gap appears in the bitstream. The content of the bitstream is not designed around software concepts such as fields or data tables or configuration blocks. Understanding the bitstream depends on thinking of it in hardware terms, not in software terms.7 Each bit of configuration memory is implemented as shown below.8 Each memory cell consists of two inverters connected in a loop. This circuit has two stable states so it can store a bit: either the top inverter is 1 and the bottom is 0 or vice versa. To write to the cell, the pass transistor on the left is activated, passing the data signal through. The signal on the data line simply overpowers the inverters, writing the desired bit. (You can also read the configuration data out of the FPGA using the same path.) The Q and inverted Q outputs control the desired function in the FPGA, such as closing a routing connection, providing a bit for a lookup table, or controlling the flip flops. (In most cases, just the Q output is used.) Schematic diagram of one bit of configuration memory, from the datasheet. Q is the output and Q is the inverted output.
Schematic diagram of one bit of configuration memory, from the datasheet. Q is the output and Q is the inverted output.
  The diagram below shows the physical layout of memory cells. The photo on the left shows eight memory cells, with one cell highlighted. Each horizontal data line feeds all the memory cells in that row. Each column select line selects all the memory cells in that column for writing. The middle photo zooms in on the silicon and polysilicon transistors for one memory cell. The metal layers were removed to expose the underlying transistors. The metal layers wire together the transistors; the circles are connections (vias) between the silicon or polysilicon and the metal. The schematic shows how the five transistors are connected; the schematic's physical layout matches the photo. Two pairs of transistors form two CMOS inverters, while the pass transistor in the lower left provides access to the cell. Eight bits of configuration memory, four above and four below. The red box shows one bit. When a column select line is activated, the row data line is loaded into the corresponding cells. The closeup and schematic show one bit of configuration memory. Die photo from siliconpr0n.
Eight bits of configuration memory, four above and four below. The red box shows one bit. When a column select line is activated, the row data line is loaded into the corresponding cells. The closeup and schematic show one bit of configuration memory. Die photo from siliconpr0n.
 

Lookup table multiplexers

As explained earlier, the FPGA implements arbitrary logic functions by using a lookup table. The diagram below shows how a lookup table is implemented in the XC2064. The eight values on the left are stored in eight memory cells. Four multiplexers select one of each pair of values, depending on the value of the A input; if A is 0, the top value is selected and if A is 1 the bottom value is selected. Next, a larger multiplexer selects one of the four values based on B and C. The result is the desired value, in this case A XOR B XOR C. By putting different values in the lookup table, the logic function can be changed as desired. Implementing XOR with a lookup table.
Implementing XOR with a lookup table.
  Each multiplexer is implemented with pass transistors. Depending on the control signals, one of the pass transistors is activated, passing that input to the output. The diagram below shows part of the LUT circuitry, multiplexing two of the bits. At the right are two of the memory cells. Each bit goes through an inverter to amplify it, and then passes through the multiplexer's pass transistors in the middle, selecting one of the bits. A closeup of circuitry in the LUT implementation. Die photo from siliconpr0n.
A closeup of circuitry in the LUT implementation. Die photo from siliconpr0n.
 

Flip flop

Each CLB contains a flip flop, allowing the FPGA to implement latches, state machines, and other stateful circuits. The diagram below shows the (slightly unusual) implementation of the flip flop. It uses a primary/secondary design. When the clock is low, the first multiplexer lets the data into the primary latch. When the clock goes high, the multiplexer closes the loop for the first latch, holding the value. (The bit is inverted twice going through the OR gate, NAND gate, and inverter, so it is held constant.) Meanwhile, the secondary latch's multiplexer receives the bit from the first latch when the clock goes high (note that the clock is inverted). This value becomes the flip flop's output. When the clock goes low, the secondary's multiplexer closes the loop, latching the bit. Thus, the flip flop is edge-sensitive, latching the value on the rising edge of the clock. The set and reset lines force the flip flop high or low. Flip flop implementation. The arrows point out the first multiplexer and the two OR-NAND gates. Die photo from siliconpr0n.
Flip flop implementation. The arrows point out the first multiplexer and the two OR-NAND gates. Die photo from siliconpr0n.
 

8-pin switch matrix

The switch matrix is an important routing element. Each switch has eight "pins" (two on each side) and can connect almost any combination of pins together. This allows signals to turn, split, or cross over with more flexibility than the individual routing nodes. The diagram below shows part of the routing network between four CLBs (cyan). The switch matrices (green) can be connected with any combination of the connections on the right. Note that each pin can connect to 5 of the 7 other pins. For instance, pin 1 can connect to pin 3 but not pin 2 or 4. This makes the matrix almost a crossbar, with 20 potential connections rather than 28. Based on Xilinx Programmable Gate Array Data Book, fig 7b.   The switch matrix is implemented by a row of pass transistors controlled by memory cells above and below. The two sides of the transistor are the two switch matrix pins that can be connected by that transistor. Thus, each switch matrix has 20 associated control bits;9 two matrices per tile yields matrix 40 control bits per tile. The photo below indicates one of the memory cells, connected to the long squiggly gate of the pass transistor below. This transistor controls the connection between pin 5 and pin 1. Thus, the bit in the bitstream corresponding to that memory cell controls the switch connection between pin 5 and pin 1. Likewise, the other memory cells and their associated transistors control other switch connections. Note that the ordering of these connections follows no particular pattern; consequently, the mapping between bitstream bits and the switch pins appears random. Implementation of an 8-pin switch matrix. The silicon regions are labeled with the corresponding pin numbers. The metal layers (which connect the pins to the transistors) were removed for this photo. Based on die photo from siliconpr0n.
Implementation of an 8-pin switch matrix. The silicon regions are labeled with the corresponding pin numbers. The metal layers (which connect the pins to the transistors) were removed for this photo. Based on die photo from siliconpr0n.
 

Input routing

The inputs to a CLB use a different encoding scheme in the bitstream, which is explained by the hardware implementation. In the diagram below, the eight circled nodes are potential inputs to CLB box DD. Only one node (at most) can be configured as an input, since connecting two signals to the same input would short them together. Input selection. The eight nodes circled in green are potential inputs to DD; one of them can be selected.
Input selection. The eight nodes circled in green are potential inputs to DD; one of them can be selected.
  The desired input is selected using a multiplexer. A straightforward solution would use an 8-way multiplexer, with 3 control bits selecting one of the 8 signals. Another straightforward solution would be to use 8 pass transistors, each with its own control signal, with one of them selecting the desired signal. However, the FPGA uses a hybrid approach that avoids the decoding hardware of the first approach but uses 5 control signals instead of the eight required by the second approach. The FPGA uses multiplexers to select one of eight inputs.
The FPGA uses multiplexers to select one of eight inputs.
  The schematic above shows the two-stage multiplexer approach used in the FPGA. In the first stage, one of the control signals is activated. The second stage picks either the top or bottom signal for the output.10 For instance, suppose control signal B/F is sent to the first stage and 'ABCD' to the second stage; input B is the only one that will pass through to the output. Thus, selecting one of the eight inputs requires 5 bits in the bitstream and uses 5 memory cells.

Conclusion

The XC2064 uses a variety of highly-optimized circuits to implement its logic blocks and routing. This circuitry required a tight layout in order to fit onto the die. Even so, the XC2064 was a very large chip, larger than microprocessors of the time, so it was difficult to manufacture at first and cost hundreds of dollars. Compared to modern FPGAs, the XC2064 had an absurdly small number of cells, but even so it sparked a revolutionary new product line. Two concepts are the key to understanding the XC2064's bitstream. First, the FPGA is implemented from 64 tiles, repeated blocks that combine the logic block and routing. Although FPGAs are described as having logic blocks surrounded by routing, that is not how they are implemented. The second concept is that there are no abstractions in the bitstream; it is mapped directly onto the two-dimensional layout of the FPGA. Thus, the bitstream only makes sense if you consider the physical layout of the FPGA. I've determined how most of the XC2064 bitstream is configured (see footnote 11) and I've made a program to generate the CLB information from a bitstream file. Unfortunately, this is one of those projects where the last 20% takes most of the time, so there's still work to be done. One problem is handling I/O pins, which are full of irregularities and their own routing configuration. Another problem is the tiles around the edges have slightly different configurations. Combining the individual routing points into an overall netlist also requires some tedious graph calculations. I announce my latest blog posts on Twitter, so follow me at kenshirriff for updates. I also have an RSS feed. Thanks to John McMaster, Tim Ansell and Philip Freidin for discussions.12

Notes and references

  1. Ross Freeman tragically died of pneumonia at age 45, five years after inventing the FPGA. In 2009, Freeman was recognized as the inventor of the FPGA by the Inventor's Hall of Fame
  2. Xilinx was one of the first fabless semiconductor companies. Unlike most semiconductor companies that designed and manufactured semiconductors, Xilinx only created the design while a fab company did the manufacturing. Xilinx used Seiko Epson Semiconductor Division (as in Seiko watches and Epson printers) for their initial fab. 
  3. Custom integrated circuits have the problems of high cost and the long time (months or years) to design and manufacture the chip. One solution was Programmable Logic Devices (PLD), chips with gate arrays that can be programmed with various functions, which were developed around 1967. Originally they were mask-programmable; the metal layer of the chip was designed for the desired functionality, a new mask was made, and chips were manufactured to the specifications. Later chips contained a PROM that could be "field programmed" by blowing tiny fuses inside the chip to program it, or an EPROM that could be reprogrammed. Programmable logic devices had a variety of marketing names including Programmable Logic ArrayProgrammable Array Logic (1978), Generic Array Logic and Uncommitted Logic Array. For the most part, these devices consisted of logic gates arranged as a sum-of-products, although some included flip flops. The main innovation of the FPGA was to provide a programmable interconnect between logic blocks, rather than a fixed gate architecture, as well as logic blocks with flip flops. For an in-depth look at FPGA history and the effects of scalability, see Three Ages of FPGAs: A Retrospective on the First Thirty Years of FPGA Technology. Also see A Brief History of FPGAs
  4. The lookup tables in the XC2064 are more complex than just a table. Each CLB contains two 3-input lookup tables. The inputs to the lookup tables in the XC2064 have programmable multiplexers, allowing selection of four different potential inputs. In addition, the two lookup tables can be tied together to create a function on four variables or other combinations.Logic functions in the XC2064 FPGA are implemented with lookup tables. From the datasheet.
    Logic functions in the XC2064 FPGA are implemented with lookup tables. From the datasheet.
     
  5. To analyze the XC2064, I used my own die photos of the XC20186 as well as the siliconpr0n photos of the XC2064 and XC2018. Under a light microscope, the FPGA is hard to analyze because it has two metal layers. John McMaster used his electron microscope to help disambiguate the two layers. The photo below shows how the top metal layer is emphasized by the electron microscope.Electron microscope photo of the XC2064, courtesy of John McMaster.
    Electron microscope photo of the XC2064, courtesy of John McMaster.
     
  6. The Xilinx XC2018 FPGA (below) is a 100-cell version of the XC2064 FPGA. Internally, it uses the same tiles as the 64-cell XC2064, except it has a 10×10 grid of tiles instead of an 8×8 grid. The bitstream format of the XC2018 is very similar, except with more entries.The Xilinx XC2018 FPGA. On the right, the lid has been removed, showing the silicon die. The tile pattern is faintly visible on the die.
    The Xilinx XC2018 FPGA. On the right, the lid has been removed, showing the silicon die. The tile pattern is faintly visible on the die.
      The image below compares the XC2064 die with the XC2018 die. The dies are very similar, except the larger chip has two more rows and columns of tiles. Comparison of the XC2064 and XC2018 dies. The images are scaled so the tile sizes match; I don't know how the physical sizes of the dies compare. Die photos from siliconpr0n.
    Comparison of the XC2064 and XC2018 dies. The images are scaled so the tile sizes match; I don't know how the physical sizes of the dies compare. Die photos from siliconpr0n.
     
  7. While the bitstream directly maps onto the hardware layout, the bitstream file (.RBT) does have a small amount of formatting, shown below.The format of the bitstream data, from the datasheet.
    The format of the bitstream data, from the datasheet.
     
  8. The configuration memory is implemented as static RAM (SRAM) cells. (Technically, the memory is not RAM since it must be accessed sequentially through the shift register, but people still call it SRAM.) These memory cells have five transistors, so they are known as 5T SRAM.One question that comes up is if there are any unused bits in the bitstream. It turns out that many bits are unused. For instance, each tile has an 18×8 block of bits assigned to it, of which 27 bits are unused. Looking at the die shows that the memory cell for an unused bit is omitted entirely, allowing that die area to be used for other circuitry. The die photo below shows 9 implemented bits and one missing bit. Memory cells, showing a gap where one cell is missing. Die photo from siliconpr0n.
    Memory cells, showing a gap where one cell is missing. Die photo from siliconpr0n.
     
  9. The switch matrix has 20 pass transistors. Since each tile is 18 memory cells wide, two of the transistors are connected to slightly more distant memory cells. 
  10. A few notes on the CLB input multiplexer. The control signal EFGH is the complement of ABCD, so only one control signal is needed in the bitstream and only one memory cell for this signal. Second, other inputs to the CLB have 6 or 10 choices; the same two-level multiplexer approach is used, changing the number of inputs and control signals. Finally, a few of the control signals are inverted (probably because the inverted memory output was closer). This can cause confusion when trying to understand the bitstream, since some bits appear to select 6 inputs instead of 2. Looking at the complemented bit, instead, restores the pattern. 
  11. The following table summarizes the meaning of each bit in a tile's 8×18 part of the bitstream. Each entry in the table corresponds to one bit in the bitstream and indicates what part of the FPGA is controlled by that bit. Empty entries indicate unused bits.       
    #2: 1-3 #2: 3-4 PIP D2,D5 (bit inverted) Gin_3 = D G = 1 2' 3'
    #2: 1-2 #2: 2-6 #2: 2-4 PIP A2,A5 (bit inverted) Gin_3 = C G = 1' 2' 3'
    #2: 3-7 #2: 3-6 PIP D3, D4, D5 PIP A3, A4, A5 G = 1' 2 3'
    #2: 2-7 #2: 2-8 ND 11 PIP A1, A4 G = 1 2 3'
    #2: 1-5 #2: 3-5 PIP A3, AX PIP D1, D4 Y=F G = 1 2' 3
    #2: 4-8 #2: 5-8 ND 10 PIP D3, DX Y=G Gin_2 = B G = 1' 2' 3
    #2: 7-8 #2: 6-8 ND 9 PIP B2, B5, B6, BX, BY PIP Y2 X=G Gin_1 = A G = 1' 2 3
    #2: 5-6 #2: 5-7 ND 8 PIP B3,BX (bit inverted) PIP Y4 X=F G = 1 2 3
    #2: 4-6 #2: 1-4 #2: 1-7 PIP C1, C3, C4, C7 PIP X3 Q = LATCH Base FG (separate LUTs)
    #1: 3-5 #1: 5-8 #1: 2-8 PIP X2
    #1: 3-4 #1: 2-4 ND 7 PIP C3,CX (bit inverted) PIP X1 Fin_1 = A F = ! 1 2 3
    #1: 1-2 #1: 1-3 ND 6 PIP B6, B7 CLK = enabled Fin_2 = B F = 1' 2 3
    #1: 1-5 #1: 1-4 ND 5 PIP C6, C7 CLK = inverted (FF), noninverted (LATCH) F = 1' 2' 3
    #1: 4-8 #1: 4-6 ND 4 PIP C4, C5 CLK = C F = 1 2' 3
    #1: 2-7 #1: 1-7 ND 3 PIP B4, B5 PIP K1 SET = F F = 1 2 3'
    #1: 2-6 #1: 3-6 ND 2 PIP B2, BC PIP K2 SET = none F = 1' 2 3'
    #1: 7-8 #1: 3-7 ND 1 PIP C1, C2 PIP Y3 RES = D or G Fin_3 = C F = 1' 2' 3'
    #1: 6-8 #1: 5-6 #1: 5-7 PIP B1, BY PIP Y1 RES = G Fin_3 = D F = 1 2' 3'
    The first two columns of the table indicate the switch matrices. There are two switch matrices, labeled #1 (red) and #2 (green) in my diagram below. The 8 pins on matrix #1 are labeled 1-8 clockwise. (Switch #2 is the same, but there wasn't room for the labels.) For example, "#2: 1-3" indicates that bit connects pins 1 and 3 on switch #2. The next column defines the "ND" non-directional connections, the boxes below with purple numbers near the switch matrices. Each ND bit in the table controls the corresponding ND connection. Diagram of the interconnect showing the numbering scheme I made up for the bitstream table.
    Diagram of the interconnect showing the numbering scheme I made up for the bitstream table.
      The next two columns describe what I'm calling the PIP connections, the solid boxes on lines above. The connections from output X (brown) are controlled by individual bits (X1, X2, C3). Likewise, the connections from output Y (yellow). The connections to input B (light purple) are different. Only one of these input connections can be active at a time, so they are encoded with multiple bits using the multiplexer scheme. Inputs C (cyan), D (blue) and A (green) are similar. The remaining table columns describe the CLB; refer to the datasheet for details. Bits control the clock, set and reset lines. The X and Y outputs can be selected from the F or G LUTs. The last two columns define the LUTs. There are three inputs for LUT F and three inputs for LUT G, with multiplexers controlling the inputs. Finally, the 8 bits for each LUT are defined, specifying the output for a particular combination of three inputs. 
  12. Various FPGA patents provide some details on the chips: 4870302464248747062164758985, and RE34363. XACT documentation was formerly at Xilinx, but they seem to have removed it. It can now be found here. John McMaster has some xc2064 tools available. 
[post_title] => Reverse-engineering the First FPGA Chip Xilinx XC2064 [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => reverse-engineering-the-first-fpga-chip-xilinx-xc2064 [to_ping] => [pinged] => [post_modified] => 2020-09-17 11:29:08 [post_modified_gmt] => 2020-09-17 18:29:08 [post_content_filtered] => [post_parent] => 0 [guid] => https://semiwiki.com/?p=290990 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 1 [filter] => raw ) ) [post_count] => 10 [current_post] => -1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 290909 [post_author] => 3 [post_date] => 2020-09-21 10:00:25 [post_date_gmt] => 2020-09-21 17:00:25 [post_content] => Oh, our semiconductor industry just loves acronyms, and the title of my blog packs three of the most popular acronyms together at once. I attended a webinar hosted by Aldec last week on this topic, "UVM Simulation-based environment for Ibex RISC-V CPU core with Google RISC-V DV". Verification engineers have been adopting the Universal Verification Methodology in order to make their verification results more robust, in less time. RISC-V continues to grow in importance as an open source, Instruction Set Architecture (ISA), and at the dac.com site there are some 3,110 search results for RISC-V. I just expect this trend to continue, because engineers often want to customize aspects of their SoC for a specific purpose or domain. A big question then arises on how do you actually verify a RISC-V project. Google has created a SV/UVM based instruction generator for RISC-V processor verification, then posted it on GitHub. There have been some 765 commits, so this is an actively supported instruction generator. There are many RISC-V core projects around the world to choose from, and Ibex is a small, 32-bit RISC-V core, also available on Github with 1,860 commits to date. Using Riviera-PRO Aldec simulates the UVM testbench with the Google DV random instruction generator and Ibex RISC-V core. [caption id="attachment_290910" align="alignnone" width="1256"]UVM Testbench RISC-V Source: https://ibex-core.readthedocs.io/en/latest/verification.html[/caption] In the testbench SV classes are blocks with rounded corners, while SV modules are shown as square corners, finally the code to be run is depicted in blue with folded corners. Random commands come from the Google DV generator, and the testbench also has random interrupts during testing. The co-simulation flow has both an ISS and RTL loaded with test binaries, simulations are run, then the results are compared by a Python script. You can have the same verification experience if you assemble all of the pieces:
  • SystemVerilog simulator that supports UVM (i.e. Riviera-PRO)
  • Instruction Set Simulator (Spike or OVPsim)
  • RISC-V toolchain
Here's the flow of tools and files used for verification: RISC V tool flow The second half of the webinar was showing an actual, live demo of this verification flow in action, running the makefiles, scripts, simulators and comparison on a Linux platform. Batch mode verification was shown first verifying the Ibex core, then GUI mode was run next, and in both cases there were zero mismatches between the ISS and Riviera-PRO simulator results. The GUI for Riviera-PRO had multiple windows: Source code, Classes, Assertions, Messages. In the upper right is the Classes Window, showing instances and hierarchy, methods, properties, derived classes and base classes. Riviera PRO A very useful documentation feature was how a UVM graph could be auto-generated within Riviera-PRO, as it showed memory interface agents, one interrupt agent, connections, and then stepped into instances for more details to understand connectivity. UVM graph An assertions window showed all assertions in one place, without having to look at multiple files, while seeing any failures, passes, and the time when it last happened, quite useful for debugging. Next, the waveform viewer was invoked after restarting simulation, and they added waveforms from the DUT. waveform viewer Finally, they showed the RTL code coverage after simulation had finished, then generated an HTML cumulative summary. code coverage

Summary

RISC-V is one of the biggest topics of 2020 for the electronics industry, and the ecosystem continues to grow each day, but verification can be a burden. Aldec showed in this webinar how their SystemVerilog simulator along with other tools could be used in verifying a RISC-V core called Ibex. I've included links to each open source tool on Github, so go explore on your own and save some verification time, instead of starting from scratch. To watch the archived webinar, visit here.

Related Blogs

[post_title] => WEBINAR: UVM RISC-V and DV [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => uvm-risc-v-and-dv [to_ping] => [pinged] => [post_modified] => 2020-09-21 08:52:24 [post_modified_gmt] => 2020-09-21 15:52:24 [post_content_filtered] => [post_parent] => 0 [guid] => https://semiwiki.com/?p=290909 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 7234 [max_num_pages] => 724 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => 1 [is_privacy_policy] => [is_404] => [is_embed] => [is_paged] => [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_favicon] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => 34d19884449719a501669c739d1edc2b [query_vars_changed:WP_Query:private] => [thumbnails_cached] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) [tribe_is_event] => [tribe_is_multi_posttype] => [tribe_is_event_category] => [tribe_is_event_venue] => [tribe_is_event_organizer] => [tribe_is_event_query] => [tribe_is_past] => [tribe_controller] => Tribe\Events\Views\V2\Query\Event_Query_Controller Object ( [filtering_query:protected] => WP_Query Object *RECURSION* ) )

WEBINAR: UVM RISC-V and DV

WEBINAR: UVM RISC-V and DV
by Daniel Payne on 09-21-2020 at 10:00 am

UVM Testbench RISC-V

Oh, our semiconductor industry just loves acronyms, and the title of my blog packs three of the most popular acronyms together at once. I attended a webinar hosted by Aldec last week on this topic, “UVM Simulation-based environment for Ibex RISC-V CPU core with Google RISC-V DV“. Verification engineers have been … Read More


CEO Interview: Murilo Pilon Pessatti of Chipus Microelectronics

CEO Interview: Murilo Pilon Pessatti of Chipus Microelectronics
by Daniel Nenni on 09-21-2020 at 6:00 am

MuriloPessatti Photo

Murilo Pilon Pessatti is an Electrical Engineer with a MSEE in Analog IC design. He studied in Brazil at São Paulo University (USP) and earned a masters at Campinas State University (UNICAMP). Murilo then moved to Lisbon in Europe to work for ChipIdea, in the early 2000’s when the smartphone era was just taking off.

“I… Read More


From Moore’s Law to Moortec’s Law!

From Moore’s Law to Moortec’s Law!
by Tim Penhale-Jones on 09-20-2020 at 10:00 am

Moortecs Law

No-one likes being put on the spot and yet we all like a forecast…and as we all know, the only guarantee with a forecast is that it is wrong. Sports commentators have carved out a special niche for themselves with the ‘commentators curse’, just as they extol the virtues of an individual or a team, the sporting gods prove them wrong in … Read More


Protocol in Depth – Ethernet

Protocol in Depth – Ethernet
by Luigi Filho on 09-20-2020 at 6:00 am

Protocol in Depth Ethernet

Many times i notice people “kind of afraid” of some protocol, trying to avoid the usage because “it’s complicated”, I decide to go in-depth in one and show that maybe it’s not so complicated after all.

First challenge is choosing the protocol and decide about the Ethernet, because this protocol… Read More


WEBINAR: Design Adaptive eFPGA IP

WEBINAR: Design Adaptive eFPGA IP
by Daniel Nenni on 09-18-2020 at 10:00 am

Menta Adaptive Design eFPGA Webinar 1

Since the start of PROMS, PLDs and FPGAs we have learned the importance of programmability in modern semiconductor design. Today we have eFPGAs for “design adaptive” embedded programmability and that is what this webinar is all about.

Several key points are discussed starting with the Law of Accelerating Returns as it applies… Read More


The History and Physics of Cliosoft’s Academic Program!

The History and Physics of Cliosoft’s Academic Program!
by Srinath Anantharaman on 09-18-2020 at 6:00 am

academic map

It was a very late evening, perhaps 11 PM, on a warm summer night in 2008. Someone sent an email to info@cliosoft.com with a very odd question – why were we not listed in Wikipedia? The sender was a scientist working for the Lawrence Berkeley National Lab. Of course, this piqued my curiosity and I replied back asking why that concerns… Read More


Parallel-Based PHY IP for Die-to-Die Connectivity

Parallel-Based PHY IP for Die-to-Die Connectivity
by Mike Gianfagna on 09-17-2020 at 10:00 am

Two converging trends for die to die connectivity in MCMs 1

 

Synopsys has released a Technical Bulletin entitled “Parallel-Based PHY IP for Die-to-Die Connectivity”. The piece is authored by Manuel Mota, senior product marketing manager, staff at Synopsys. Manuel has worked at Synopsys for 11 years in the IP area. Prior to that, he worked at MIPS Technologies, Chipidea (acquired… Read More


Anirudh CadenceLIVE Plays Up Computational Software

Anirudh CadenceLIVE Plays Up Computational Software
by Bernard Murphy on 09-17-2020 at 6:00 am

Anirudh min

Cadence has clearly found its groove with Intelligent System Design, something that Lip-Bu reinforced in the CadenceLIVE kickoff keynote on Tuesday, August 11th. Anirudh Devgan, president of Cadence, continued to discuss the theme in his keynote on Wednesday, August 12th with his equally consistent subtitle—”Strength… Read More


Electronics Production Healthy

Electronics Production Healthy
by Bill Jewell on 09-16-2020 at 4:00 pm

Electronics Production 2020

Global electronics production is healthy, despite the COVID-19 pandemic. The chart below shows the three-month-average change versus a year ago (3/12 change) in electronics production (measured in local currency) for the major Asian producers. China is the largest electronics manufacturing country and the original source… Read More


Reverse-engineering the First FPGA Chip Xilinx XC2064

Reverse-engineering the First FPGA Chip Xilinx XC2064
by Ken Shirriff on 09-16-2020 at 6:00 am

Xilinx XC2064

A Field-Programmable Gate Array (FPGA) can implement arbitrary digital logic, anything from a microprocessor to a video generator or crypto miner. An FPGA consists of many logic blocks, each typically consisting of a flip flop and a logic function, along with a routing network that connects the logic blocks. What makes an FPGA… Read More