Hi. Hello, and welcome to episode 3 of the Mi-V Unleashed Training Series. My name's Alicia. I'd like to start off today by playing a quick housekeeping video. Let's move this one here, this one over here. Oh, hey there. Before we jump into today's presentation, I want to share some cool features and functionalities of the webinar console. Guess what? It's completely customizable. Now, you may only see a few windows on your screen. However, if you take a look at the taskbar below, there are various widgets you can launch to add to your screen. Take notice of the Ask Question widget. We encourage you to ask questions throughout the presentation. While our presenters are busy delivering exciting content to our audience, they are always supported by subject matter experts who sit behind the scenes and help answer questions they cannot address live. Now, grab a coffee, a pen, and a writing pad, and enjoy today's webinar. Awesome. Now that we've got our housekeeping items covered, I'd like to introduce our presenter for today's session, Alexander Newsom. Alexander will be discussing the Linting and Clock Domain Crossing analysis for Microchip FPGA designs. Before we get started, please take a moment to access the menu bar at the bottom of your screen to see all the engagement tools we have available for you to use throughout today's session. As a reminder, our session will be available on demand to view. Now, without further ado, I'm going to pass it over to our presenter. Alexander, please take it away. Hello, and welcome to our webinar. Today's webinar is about linting, which is static analysis, and CDC verification for Microchip FPGAs. First of all, let's start with webinar agenda. The first thing we will cover is what static linting means, as well as what's CDC analysis. We'll just run overview of static linting and CDC analysis. We will introduce Aldec's tool, static verification tool, ALINT-PRO. We will run tool overview and present you a few examples, simple examples. We will switch to static verification of Microchip Icicle design. We will show how to apply static verification on Microchip Icicle design on Libero projects. We will show you automated project conversion, as well as we will run automated linting of Microchip Icicle design, as well as CDC analysis. At the end, we will run, we'll do conclusion and a Q&A session. Let's start from the first topic, linting. What linting means. Linting actually, what how it helps to designers to in design process. Linting allows designers to uncover bugs very early in design flow, even before the simulation. Once you only write your RTL code, you can run linting on this code and find very different issues, starting from naming conventions and up to synthesis issues, and maybe even long combinational paths if you have them in your logic. This process is very fast, and it can be run very early in design stages. By doing that, you will actually save a lot of time because if you find bugs or inefficiencies as soon as possible in design process, then you will save your money and your time and don't propagate these bugs to the later design stages, especially to implementation stage. Definitely, it will save time on the implementation iterations once. For example, running synthesis with Libero, you can run it fewer amount of times once you solve lots of implementation issues before with lint tools. It helps to implement automated code reviews and reduce cost of review, basically manual labor. Most of tools are based on comprehensive knowledge based on industry best practices, and it will show you, root plugins later on, which we use in ALINT-PRO, and this can be applied to automate code reviews. What is the technology of linting? Basically, if you think about lint tool, is a lightweight and very simple, implementation tool which runs parse, elaboration, and then high-level synthesis. High-level means you don't run synthesis map based. You don't maps your, design on specific cell library. Basically, you just map on technology independent library, like basic flip-flop, MUX, and so on. This process takes small amount of time. It generates netlist. Then linting with static analysis analyzes design and different presentation levels, starting from text structural, from RTL code. When you run parse, you basically run parse specific rules. You check, for example, naming conventions, formatting, commands, and so on. You go to elaboration, you extract the hierarchy, build your design hierarchy, you check other rules related to the hierarchy. You synthesize, once you synthesize, you actually check different synthesis-related issues and may check design sensitivity as well as that, your design is suitable to synthesize with different synthesis tool, which is usable between different synthesis tool. When you generate netlist. When about to generate netlist, you can also check netlist. Here we have... You can apply pattern matching technology on netlist, and we do that. With this pattern matching technology, we can extract different issues. For example, we extract clock trees, we extract reset trees, we extract clock tree and reset tree issues. For example, when clock feed path is as data to flip-flop and so on. We check, basically, we extract clock trees, and you can also see them in a graphical form in our viewers. We have clock and reset viewers. Then we also extract clock domains. To extract clock domains, there is also a need to supply a general constraint file. Then we understand clocks. We understand clock boundaries, and then we understand paths going from one clock domain to another clock domain. Then we will look on specific design patterns, correct synchronizers between those clock domains. Once we extract them, we check them, and if they're not exist there, we generate an error in sync for CDC analysis. That's basically... That's our technology underneath the tool. ALINT-PRO contains complete FPGA vendor primitive support for most FPGA vendors, such as Microchip. If you talk about clock domain crossing analysis, this problem is twofold. First of all, we have to statically analyze design, extract clock domains, find combination patterns, and so on. Secondly, second part of CDC analysis is ensure proper behavior of signals crossing clock domains. For the first part, we use ALINT-PRO, ALINT-PRO runs static verification, extraction clock domain, identifies clock generation, identifies all signal cross clock domains, ensure clock domains crossing properly guarded with value synchronizers. Once we do that, we pass through all the stages, we can also generate SystemVerilog assertions towards functional simulation. Then can be added to verification, to regressions or test environments to make sure that signals crossing clock domain don't violate specific rules. For example, poor pulse is too short for signal going from slower clock domain to higher clock domain. Sorry, opposite, and so on. Let's talk about ALINT-PRO and its features. Static, as I already mentioned, ALINT-PRO is static design verification tool, which means it performs analysis, and the input of this analysis is either RTL alone or RTL and SDC sources. SDC means standard constraints. Okay. Our tool doesn't actually require complicated setup. Setup is very easy, then you can just run with push-button approach to start linting. ALINT-PRO has the DO-254 support, includes a dedicated toolset for companies actually running the DO-254 compliance. ALINT-PRO contains number of different and very useful visualization windows. In addition to generating violations, we also provide different means to visualize design. One of them is, as I mentioned already, clock schematic viewing and clock tree extraction and the reset tree extraction. You can see them in different windows. Also, our tool is able to extract FSMs from design, and once extracted, they are also analyzed for different issues, as well as you can see them graphically in FSM viewer. You can see these yellow stages here, yellow states and conditions and so on. It runs CDC and RDC verification. RDC means for reset domain crossing. In this case, just for designs containing asynchronous reset from different clock domain. We're not going to talk about this issue, but it's still there. We just, in this presentation, we cover only CDC part of it. As already I mentioned that it contains complete FPGA library support. All libraries are precompiled in ALINT-PRO. All library components are already constrained for CDC analysis. Whenever you use them in design, you can run CDC verification. As well as we support automated project conversion. You can just click and convert, click Libero project and convert it to ALINT-PRO environment. Finally, ALINT-PRO is able to automatically generate, assist to generate design constraints. In the case you don't have that constraint with your design, you can run CDC analysis. At the same time, you actually generate design constraint templates that can be used further, not only in linting and CDC analysis, but also in the implementation, natural implementation with Libero or other implementation tools. Let's talk about ALINT-PRO checks. ALINT-PRO provides powerful static design verification at RTL and FDS level. During parse stage, once we parse the code, we run checks for code formatting, for layout, comments, and so on. Naming conventions. Once, same as for coding style and language constructs. Once we run elaboration stage, we can check for design and portability, IP checks, and so on. Then we run a very simple, fast synthesis. I'm talking about technology-independent synthesis, which runs actually half a minute or maybe less, depending on the design size. The ones we synthesize, we automatically checks for safe synthesis, optimized for area and timing. For example, we check for long combinational paths. Those are not exact paths you can see in a mapped synthesis, but still you have good idea in the very early stages of your design and development where you want to optimize your logic for timing. One of important checks, area checks is simulation to synthesis functional match. Here is that, dependent on coding style, there are some dangerous coding styles which are actually allowed by, let's say, RTL standards and so, but synthesis tools, when you may get design, actual implementation function differently from your simulation. For example, if you use non-blocking constructs, one like... Maybe non-blocking constructs one after another in sequential process and so on. These issues may actually cause this functional mismatch, and it's very important to actually avoid all these issues and making sure that your implementation actually works exactly the same as your simulated design. We already mentioned that we run graphical FSM extraction and do checks, and I will show you simple example. One of examples of introduction to ALINT-PRO. We generate design constraints and also checks for missing design constraints or uncompleted design constraints in the case customer supplies those constraints to ALINT-PRO. We run clock and reset tree verification, and also we run CDC, clock domain crossing verification. ALINT-PRO contains number of plugins. The first plugin is basic. It comes with the tool. There's no cost. Basic prevents simple coding mismatch, bring style and so on. Aldec premium plugin actually complements Aldec basic plugin, providing much more rules and actually making sure that you cover most of important topics. Aldec CDC plugin is developed for CDC verification and contains about 60 rules, different rules also related to the clock trees, to the set trees, to IOs, to design constraints, and also to CDC analysis to make sure that you're basically cover all aspects of CDC and don't have any issues. STARC rules are based on a tutorial, basically the book that are written by Semiconductor Technology Academic Research Center. This is in Japan. This center actually is based, was set up by main companies like Fujitsu, Panasonic, Renesas, and so on, and covers best industry practice and contains significant amount of checks. It's very, it covers lots of topics of RTL design, and it's highly recommended also to use for the companies. DO-254 plugin basically is targeted for companies running DO-254 standard and compliance. RMM or Reuse Methodology Manual probe plugin is based on RMM manual developed by main EDA companies such as Synopsys and Mentor Graphics. Let's start with ALINT-PRO. Now I will show you simple examples, I will probably switch from slides to my screen. Here is ALINT-PRO GUI. Contains number of features. That's how you see ALINT-PRO the first time you open it after installation. On the right side of GUI, you will see Flow Manager. Under Flow Manager, you see Demo Projects. You see these Demo Projects only when no workspaces or projects are loaded. With... Here you can pick either one of them and basically train, run CDC run linting and see how tool is running. Let's click one-- let's take one of them, which is a simple project, FSM written with SystemVerilog, and there's only one file, and FSM looks quite complicated if you look at SystemVerilog code. Let's run verification. In fact, it's already run here. You can see different... Basically we can actually clean the project, run it again just to see the process. You can click on this green arrow on the top, or you can double-click on Run Project. As you can see, once you click on Flow Manager, you can see different phases: parse, elaborate, synthesize, constrain, and then linking, and then report generation. Those are phases related how tool processes the code. It starts with parse, and at the same time, it runs parse linking. It goes to elaboration and then runs elaboration linking. It goes to synthesis and runs synthesis linking, and so on. You can basically run all together by double-clicking on Run Project. At the same time, you can run projects, and you develop different scripts with a Tcl, based language, supported by ALINT-PRO. You can run commands like project.run, for example, to run it, and you can develop scripts to run linting in a batch mode, which is highly recommended. Only in the case of debugging, you can open GUI, right? Because once you run linting, you don't necessarily need to open the GUI. Here we have violation viewer. In violation viewer, we see a couple of violations. As I mentioned, this design is about FSM extraction. Even before going to see the rules, we can open FSM viewer. Here you can see different viewers like netlist windows. Here, for example, you can see violation viewer and so on. Netlist windows, you have RTL schematic viewer, clock and reset viewer, control schematic viewer. FSM windows, you can see FSM viewer. Let's open this one and see FSM extractions in your design. We can see 1 FSM found and extracted in your design. The tool understands it's of type Moore. You have different rules of FSM. For example, you can require all FSMs to be owned with type Moore or owned with type Mealy. You can also define and restrict FSMs to have specific states encoding. In this case, it's binary, and so on. This is how you extract FSMs. Also you can actually visualize FSMs by clicking on show in graph. Basically you'll see FSM graph, and you can see different colors, and these different colors relates different FSM violations. We can see those violations in the violation viewer. Start from the first violation, avoid deadlock states in FSM descriptions. It shows S13 state, which is marked in the red, is a deadlock state. Definitely you won't see arc going out from this state. It's only going in. Basically it's deadlock state. If you want to debug it, you don't have this window at all, what you do is just click on it, you can see show source. You can see it on in the actual source code, or you can see it in show in FSM graph. It'll show you this actual place in FSM graph. Then you can debug it and fix it. Second is S10 state is unreachable. Actually, all this group of state looks like it's unreachable. Also it has also incoming arc and also outgoing arc, for some reason, this incoming arc is marked with red cross. Maybe this cross actually leads to the situation where you cannot reach those states. We can also debug this arc. We just click, double-click on this arc, and you will see it as this specific transition and specific expression. Condition for the transition, which is the if count more than 7, then you go to S 10. Count is a variable defined here, and it's variables consists only 3 bit. With 3 bit, count never can reach values more than 7, therefore, this arc never could be taken. That's why we have this red cross set by the tool. Tool automatically analyze the semi-formal analysis. It runs BDD-based analysis to make sure that all conditions are executable. In a case it sees that some conditions are not executable, it actually checks it and automatically defines this portion of sets, states as unreachable. Same you can, you can check ex-reachability, executable conditions, not only in FSMs, but anywhere in the code. This particular example of FSM. Let's go to another example. Here I will go with lights. Shift here with lights. Let's go to simple CDC analysis demo and open other project. In this project, we see very simple design where, let's just quickly run synthesis to see what design means. Basically, it's a very simple one. Now, we also talked about flow manager. Before I showed you default flow. Default flow means default linking, when you're going through different phases, parse, elaborate, synthesize, constraint, and so on, and run linking along with going through those phases. Now let's choose another flow, which is CDC, efficient CDC debugging flow. This is another flow developed for actual CDC analysis. In this flow, you go through different steps. First of all, you go through design entry. We can run it quickly here. With design entry, actually, you just parse, elaborate, and synthesize your design. Now we've already done here. We can see it in RTL schematic. This is simple RTL schematic. We have two clocks, clock A, clock B, which are synchronous clocks, and one clock from there, other from there. Definitely there is a CDC violation here because you don't have 2 flip flops actually synchronizing data going from Q to D. You have only 1 of them. Also we have design constraint files. Format is Aldec Design Constraint, which is similar to SDC and, or it actually enhances SDC with a few other commands, such as, for example, block level constraining. We can constrain, for example, IP blocks and blocks without actual internals, protected blocks, and so on, as well as reset related commands. We can define similar, we define create clock. We can define create reset. With create reset command, we can define, for example, that we want to see, to have a synchronous reset with active low, active low, and with this specific edge synchronizer to fit the clock and so on. Then once we define reset, we actually can, we are able to check that actual build reset within design complies to this, to this constraint. Let's now. Here we see that we, in this specific project, we already have all design constraints. We have two clocks defined as asynchronous. They are asynchronous clock groups. We define input delay for clock A phase. We port the in and the clock B port for the out. Timing here, in fact, we don't care about timing in the CDC analysis. We just care about phases by definition. At the same time, if you develop those files and we may already set the proper timing for the implementation, and that can be then reused later in implementation. You can bring the implementation SDC file to ALINT-PRO. ALINT-PRO understands definitely.SDC files. You can add them to the project. We can run clock setup. During clock setup, it extracts clock tree. It checks so that all clock-related constraints are available. In a case, for example, you don't have at least one of those Gray-coded clock constraints, clock A, it will provide you violation, saying that one of clocks is unconstrained. At the same time, once you run through these phases, it automatically generates design constraint templates. In the case you don't have those constraints, let's take a look at the project directory, there is automatically generated ALINT-PRO output directory with a constraint folder. Here you can see chip-level ADC file. Currently, it's all. This file is automatically generated by ALINT-PRO right now when we run this clock setup phase. It contains commands. Basically, all of them currently commented, like of clock definitions and so on. This information is actually extracted actually from design. ALINT-PRO analyzes design without design constraints, extracts clock tree, understands which ports are clock ports, actually writes this file according to our design structure. In our specific case, we already have those constraints in design file. Therefore, all these constraints now are commented. In the case some constraints are missing, it missing, you won't see... Basically, they won't be commented. There is a task of designer to just copy-paste commands from this template file to actual design constraint file of your design and move forward. For Icicle setup phase, now we are running IO setup, which is set input delay, set output delay commands, and making sure that those commands are complete. As I said, as we see here, we also have only two input, one input and one output. All of them are covered here, so we don't have any issues. Reset setup extracts clock trees, but in our case, we don't have them. Now let's go to structural CDC and RDC analysis, which is last stage, last step. You can see that there is a violation here. Also once you go through states, through those states, it's very useful to use graphical viewers. Like for example, netlist between those clock and reset here to visualize extracted clock trees. Here we have two extracted clock trees. Those are very simple because we have a direct connection from clock to input port to a flop. Still we can analyze, and we can see them. In other case, you will see complete design. There is clock going to specific flops and clock hierarchy, clock structure and so on. Let's take a look at this violation. Violation says that always use synchronization circuits to transfer data between synchronous clock domains. Actually, I forgot to tell before that, first of all, once you see these violations here, you can... You can actually read documentation about this violation. You can understand better why what does it mean and how to prevent it. That's why just double-click on violation in the LCD and see documentation. You can read documentation, you can see different. We also have 2 examples. One example is failing example, and other is corrected example. Those are real code examples. You can easily take them, copy to your project, and actually train on those examples. As I think it's a very good means to train, to understand if in a case you don't understand some specific rule or you have some doubts and so on, it's very useful to copy-paste those examples to your project files and actually run them. Here we have violation instances, here is no synchronizer. It's what we expected because we have only one clock. There's not two clocks on other side. Let's. We can see them in the source port. We can see them in RTL schematic. In RTL schematic, it shows the CDC path, which actually is going from one clock domain because this clock is clock A, this one is clock B, and this is a crossing. There is no here proper synchronizer found. There is no two flip flops found, only one here, right? What we can do now, we can also open CDC viewer, which is another viewer, graphical viewer here, and we can see two clock domains. We can see crossings from and crossings to those clock domains. We can see that from both clocks, from basically, this is crossing to, from clock A to clock B. Same as basically here, to clock B from clock A, but other order. We can see that there is no synchronization here, so it's not synchronized. That's why we have this violation. What we can do now, we can go quickly and correct the code. Just add another clock to the clock B, and then rerun it. Run CDC. Now we don't see any violations. Let's take a look at CDC viewer now. Here we can take a look at those synchronizers. This is actually clock and reset viewer. Look at CDC viewer, clock A, crossings from clock A to clock B. You can see now that now it's proper synchronizer structure is found. It's called NDFF. Basically it's two or three flip flops, depending on the design requirement, you can make it three stages, and so on. There is no issues, and it's synchronized, and you can also visualize those synchronizers in either RTL schematic. That's this pass. Now we have two flip flops on other side. You can filter in CDC schematic. CDC schematic is another way to represent design based on clock domains. We have clock A domain, we have clock B domain, and here actually we have all passes. This bus actually combines all CDC passes, going from clock A to clock B. We can see starting point of these passes, and we can see end point on these passes. Usually those end points should go in this case to valid synchronizers, so that we can look inside this box, which is a input box, and we can see in this box actual valid synchronizer, two flip flops. Let's move to other topic, and then we can go to. First of all, let's take, let's review where we can use linting and CDC in the FPGA design flow. Talking specifically about Microchip design flow with Libero. First of all, the first place to use linting, and talking mostly about linting, not CDC, but linting, it's the very first, very early stages of design development. Even before you bring them to Libero, you start running stuff. You can parse, elaborate, you can check syntax, you can check synthesis issues, so you can check other issues, naming conventions, so on, with linking. It's really advisable to run linking as soon as possible, as soon as possible once you have even maybe some portion of RTL block development, maybe block development or maybe some set of blocks development. You can run linking as soon as possible and find different design issues and correct them as soon as possible. The second place to run linking is once you already run Libero flow and you run already synthesis. Because after synthesis, you already have a netlist. You have full design. This is the place where you can run CDC analysis, not only linting. Linting is also important here, but most important also is to run CDC, clock domain crossing analysis after synthesis. As I already mentioned, linting, CDC analysis, runs checks in RTL with time constraints, checks for clocks, resets, and so on. Basically two place to run linting. Let's talk about automated conversion of Libero project. [Orpheus] supports porting of Microchip libraries. We can go to our viewer and see design management window library viewer. In library viewer, we can go to global, and Microchip, and here we can see all families and Microchip libraries loaded, and then automatically attached to the project during conversion, or you can manually attach them once you run any project. We also support automated Libero conversion. Here I can show you, under tools, we have convert section. Here you can see we can convert from Quartus, maybe Pado, as well as Microchip. After, click on Microchip and select Icicle design, select Icicle project file, prjx format. Click Next. Now we see that all project hierarchy is extracted in the viewer. In the case some files are missing, which means that are mentioned in the.prjx file, but actually don't exist in the file tree system, you will see them in red. It's a problem. In this case, we don't see any issues here. Just review the structure and click on Finish. It will take some time because project is a bit big, and conversion takes maybe half a minute. Just wait for this project to be loaded into ALINT-PRO. Let's just talk, other topic is to talk about how to run linting on Microchip Icicle project. Just for now, once it's loaded, I will just move to next slide. Once we start run linking, first of all, we run parse and elaborate phases, same as you parse and elaborate your code. ALINT-PRO has a compiler, content compiler, which is industry used compiler. Compiler by itself throws warnings and errors. Whenever compiler has error, definitely you stop compilations, you have to correct the code right away. In the case, the compiler throws warnings, those warnings still allows you to go to next steps like elaboration and synthesis, and so on. I think it's still is very important to check for those warnings even before you go to check ALINT-PRO violations, because those warnings really actually point to design issues. For example, like, we have not synthesizable constructs, net results, drivers, out of range indexes here, notion, right? In the spot connections which ports are unconnected. In some cases, it's okay because we just reuse some other IPs, but still there, it's really important before, even before we go to actual to linking, to look at compiler warnings and making sure we can eliminate or at least understand those warnings. You can see in our design that our project is converted, and it contains different libraries like syncomps, work, same star structure as in component, same structure as you can see in in in Libero projects. There is a... so on. Let's just open as the same already. I will close this window and open and open other instance of ALINT-PRO with already linted design. The reason of that, the reason of that is because it takes some time. We just want to save some time. It maybe takes a couple of minutes to run linting. Here we already have it. This is the main project. Just a second. It's loading. Until... Okay, it's loaded here. Here we actually, linting here is already have been run, and we have our violations here. Let's talk about those violations in our slides. Those violations also are described in slides. We can review rules by different types. You can review them by rule level, by severity level. Here, for example, is rule level. We have rules, we have recommendations, and we can see them in different, in different ways. Let's review them by rule level. Just click back slide. Which issues here we have? We have some connection issues, so avoid unconnected ports. You can see it here, right? Here you can see unconnected ports. Unreachable states of FSM descriptions. Design extracts not couple of FSMs, and in fact, we can also see those FSMs extracted in FSM viewer. We can click on them and also click on show them in graph, for example. This is FSM. There are different issues like some unreachability issues, for example, for FSMs. We can click on this in violation item and debug it with FSM graphs. Here, for example, we have those 4 gray states. They have only arcs from the states, but not arcs to those states. Those states are unreachable basically, right? From the main reset state. Maybe it's because of a design reuse, but still it's really important to analyze those FSMs and those places in design. Code redundancy issues. Here we have that signal detected in the code should be used within the code. Object declared in the code can be used in the code. This is other issues. Those are in recommendation sections. Still, I think it's important to understand which signals and then objects are not used. For example, click on object, you will see different objects like parameters, ports, and so on, which are not used in design. Still it's important sometimes to understand, especially during early design development, it's really important to clean up your code to check all these issues. RTL related issues. Node duplicated, non-blocking signal assignments, and so on. Let's I will probably just go quickly now to other topic, which is CDC analysis. I think I already showed you the value of the tool and value of those messages. Right? For example, index should not exceed an object range. This one, here we can see that index not exceed. Once we click on source, we can see some unreadable source. I don't know how to debug it, but still we can just, it's important to understand and analyze those issues. Reset related issues. In one case, we do not have both asynchronous reset and synchronous reset connected to the same reset line. ALINT-PRO automatically extracts reset trees, both synchronous and asynchronous, and make sure that if you have asynchronous reset tree defined, it should not be fitted both to synchronous and asynchronous resets of design. Let's go back, talk about CDC. Run CDC, I will switch to one of IC-level IP blocks, which is CoreAXI interconnect, and make it inactive. Let's go to this slide. Here we switch to CDC. Here we already run CDC, so we have couple of violations here. Once we analyze, basically this block contains AXI interconnect switch with 8 primary and 8 secondary interfaces. Those primary and secondary interfaces could be parameterized as to be completely independent, so can be run with different clocks. In this case, we have 16 different clocks. First of all, what we can do here, we can take a look at CDC viewer. You can see that in CDC viewer, we have all these clocks defined, and then we have crossings to the clocks, and we can see how they are synchronized. ALINT-PRO is able to extract about 10 of different correct synchronization patterns. Not only flip-flops, but also wide flip-flops when you have actually memory. In this case, you can see a wide flip-flop and 1 memory and synchronizers. This way, you can actually see how each, which, synchronization structures between different clock domains. We have violations. Those violations actually relates to the fact that here there is FIFOs. FIFOs contain pointers, which is read pointer and write pointer. Those pointers are multi-bit, and we actually pass pointer values from 1 clock domain to another. Right? Here, basically, we have 4-bit pointers. Maybe, 3-bit actually pointers to go through clock domains. It's possible only when the value of these pointers is basically Gray-coded, so only 1 bit changes at a time, at 1 clock cycle. We still extract them as warnings, but we also generate assertions. These assertions can be used in simulation. Those assertions actually require the functional behavior of this pointer has to be Gray-coded. Not necessarily Gray-coded, but every time should only one bit has to change at time. That's why once we run CDC, we click on Generate CDC Assertions, this file is already generated. I can show you in file browser. ALINT-PRO output, functional, CDC assertions, CDC assertion file. Here we can see, we can see this file, this is actually a separate module. It's in SystemVerilog. You can just add it to verification environment on the top of your design under test. It looks inside design signals, it checks for different violations, such for example, as CDC one bit change. It's exactly the violation actually is related to those read and write pointers. Only one bit can change over time. Other one change, checks for glitch. This actually relates to only those synchronization patterns we found in this design. This is actually. Finally, we can generate synthesis CDC report. I can show you the CDC report in slides. Basically, we run consistent generate constraints, and I already showed these stages in simple design. We can do the same generation of constraints, missing constraints and so on here. If you don't have, for example, constraints. We run CDC analysis here, and we analyze results, and we can see clock trees and reset trees. Same way as I showed you before with CDC viewer, we can see different clock domains as separate boxes, and those passes are all CDC passes going through those boxes between clock domains. Finally, we can generate a CDC report. This is CDC report for this module. CDC report contains all information about CDC analysis, including clock domain info, synchronization info, extracted synchronizers info, we're able to set up other for, like, quasi-static signal that actually crossing clock domains, but is not changing. We are guaranteed to be stable during let's say functional operation of our design. In this case, we can, you know, mark some CDC passes as valid, and don't check design structures on those passes. Basically, I already mentioned about CDC violations. Here is actually this, it's automatically generated once you run the generate CDC assertion stage of CDC flow. Here we are going to finish our presentation and going to recap session. Recap of points discussed include, ALINT-PRO provides automated conversion mechanism for Microchip Libero projects. It performs an advanced linking right after the conversion. We can use different advanced viewers, schematic, FSM, clock tree recept viewers, CDC viewer to check design structures. We check for CDC violations, can generate CDC assertions for functional verification. As a overall statement is linking and CDC analysis helps finding these critical design bugs, improving code quality, and reducing implementation cycles number with Libero environment. Thank you very much. Now we can go to Q&A session. All right. Thank you so much, Alexander, for the great presentation, and thank you to our audience for attending today's session. It does look like we have a few questions from the audience. The first question is: How do you constrain hard IP blocks for CDC analysis? As we already mentioned, the Libero and other FPGA vendors contain hard IPs. These hard IPs basically, they don't provide internals in RTL format. What should we do, for example, in CDC analysis, how we know that because in CDC analysis, we want to actually to see all CDC passes propagated through those IP as well, right? Understand which IP input and which IP, especially which IP output is phased with which clock. For this purpose, we develop other addition to CDC, to SDC format, which is we call block-level constraint. For example, instead of create clock command, which creates clock for design port, we have create cell clock command, which creates a pin which create... Which sets that specific this specific pin of design IP is a clock input. Once we define clock inputs for this specific design IP, we can define phase relation between inputs and outputs to specific clocks and so on. This way, we can actually constrain block-level designs towards CDC verification. Great. Thank you. We do have time for one more question, and the question is. How does ALINT-PRO generate design constraints, and are they suitable for actual implementation? I already mentioned that ALINT-PRO, once it goes through different CDC phases, it actually generates different portions of missing constraints. In the case you don't have constraints at all, it generates full constraints. We have to preview it. Yes, those constraints are fully suitable for actual implementation. The only thing, as I already mentioned, is that just you have to change timing. For example, clock frequencies and in IO delays and so on, and maybe add some other constraints, for example, like, and the input. Still, ALINT-PRO, Provides Very suitable and convenient way to start with to generate design constraints. Can be used not only for CDC analysis in ALINT-PRO but also in later stage outside of ALINT-PRO with actual design implementation. All righty. Awesome. Thank you again, Alexander, for your presentation. Thank you again to our audience for joining today's session. We ask that you please take action on your screen to stay up to date with all of our exciting Mi-V e cosystem Unleashed content. Thank you, and have a great day.