five computers

Git - version control done right

As I've started working on this small CPU project, one of the first decisions I've been considering has been which version control system to use. I've been a user of subversion for most of my personal projects for several years now and am currently using it at a client. As a result I'm quite familiar with the ins and outs of using it on a variety of sizes of projects. I've become more aware of distributed systems, such as Git and Mercurial over the last year, but haven't really been able to get my head around the advantages of them. In particular, the quote below from Linus Torvalds has been in the back of my mind.

"The slogan of Subversion for a while was 'CVS done right', or something like that, and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right."

- Linus Torvalds

One of the main source control issues I've seen on several of the projects I've worked on has been the aversion to branches that most users have. Typically there is a big central source repository that everyone will check out from. You then develop in your own little world. When the particular piece of work is complete, you check it back in. Usually, there is a fairly high barrier or cost to those commits, with sets of test suites that you must pass before you can commit your code back to the central repository. The checks take hours to run and you can not check back in until your code passes all the tests. Otherwise everyone else is at risk. But I always found that if I was working on something non-trivial, I'd really like to make some progress and check point that half way, committing it in to just a local branch, then working on further. That would give me the confidence to make larger changes, safe in the knowledge I can revert back to a midway working point. That's what a branch would be for, after all, but not if they are hard to make and not if the commit cost is so high. So we never did that, working for days or weeks before committing any changes.

The second common frustration I've seen with a centralized repository occurs when two people are working closely together on a piece of the system. This happens to characterise almost every verification endeavor, for example. By common definition, the verification and design work should be done by two different people, just to get extra eyes on the spec. This avoids duplicating erroneous assumptions about the design and is fundamental to the whole process. As a consequence, we are almost always faced with the situation where changes need to be made by two or more people, in distinct parts of the code (e.g., testbench and rtl) but cannot be checked in because of mutual dependencies. The changes depend on each other and all the commit checks will fail for either change on its own. Various ways around this exist, disabling affected checks in the commit scripts, copying files into each others workspaces and other hacks. All because fundamentally the centralised server approach, with costly branches and high commit costs, doesn't really let this sort of work proceed in an effective way.

The third frustration is the general speed of the repository. Time to check things out, time to do merges, how long it takes to do a diff or an update. These operations can usually mean a break for coffee or a walk around while the tool fetches the changes, compares them and attempts to merge it all together. Compound that by working in remote sites or across multiple geographic locations.

Git claims to solve these problems and be a whole lot faster at the same time.

The key is in breaking away from a centralised server. The database is distributed to every developer. As a result, everyone works on their own branch by default. Making further branches is trivial, because they don't get sent to every other developer. Fewer issues with namespace collisions when naming a branch, no real concern about checking code in and someone else getting your partially finished work. Earlier today I'd listened to Joel Spolsky and Jeff Atwood talking about the fact that Git makes branching trivial, but I didn't really understand why until I watched a really interesting presentation from Linus Torvalds on the subject. It is supposed to be a talk about Git, but really he focuses almost exclusively on the advantages of a distributed repository. I'd initially thought the real advantage was the 'always available' nature of a distributed repository, so that you could work on a plane or generally away from a network and still be able to check in, look at histories and all the things you normally need the central server access for. That's certainly part of the reason why it is interesting, but the branching and merging cost reduction that Git claims to offer is a much bigger deal.

For my second source of frustration above, Git also provides a solution. As there is no central repository, everyone can pull and push data to each other. The verification engineer and designer can exchange files more easily, through a tracked, version controlled system, rather than the usual sideband exchanges or hacks to the check-in scripts. Git also addresses that third issue, because all of the files are local and it has been designed for performance. Network overhead isn't an issue for a diff or history request as you have all the data locally. Merges are similarly less painful. The claimed performance is impressive and part of the reason why I want to try Git out.

Now, the most glaring problem with all this is that it sounds like anarchy. There is no central organisation, check-ins can happen any time, so where did all the quality assurance go? Linus talks about the network of trust relationships in his presentation. But, you can still have acceptance tests on when you actually pull data from a particular user or set of users. You can require them to run a battery of tests before they are allowed to share their work with the rest of the project. The usual checks and balances can be put back in place for when the whole database gets reassembled, but the individual developers or groups of designers can work more efficiently in a sub-repository. Git also supports hierarchical projects that combine various blocks of code, in fact that seems to be the preferred use model. Each sub-system on a design would be a unique Git repository. It could be even broken down further and have each IP block in their own repository. The general approach that has been used in the past, with quality checks, can still be used with some changes, as a gate to when larger mergers take place. This probably requires some trusted people in the organisation to act as gatekeepers or guardians for each level, but the basic methodology shouldn't be too difficult to layer on top.

You can read a lot more about Git on the homepage, including conversion documents from other common source control systems and details on the actual commands to use. Looking through the SVN conversion document, the git command syntax appears a bit cleaner and generally more intuitive to me. I also played around with the merge and diff tools and they seem powerful. It was very easy to create and populate a repository, for example. I plan on using it for the next few projects I work on to get a feel for how really useful it is and where the issues are hidden.

Edit to add: I found this draft version of the differences between Git and Subversion quite useful.

a somewhat crazy notion

Many ideas have been whirling around in my head since being at DAC. I've been inspired to learn some new things, starting with the Open Verification Methodology but also revisiting some of the Electronic System Level tools and flows that I've worked with in the past. I'm interested in exploring visualization techniques and tools and how they might be applied to verification and design. I'd also like to learn more about a few of the more interesting formal verification tools, like OneSpin 360 MV and maybe explore what is possible with ESL tools like Bluespec's SystemVerilog flow or the various other similar tools that are out there.

I have a difficult time learning things just for the sake of it, tending to be more driven by necessity rather than idle curiosity. I've been doing some work based around a small CPU core and started getting frustrated with the way the CPU was architected. This led me to start considering designing my own CPU, just for fun. Partly as a motivation to crack open a Hennessy & Patterson book that I've been meaning to read for a few years, partly to see if I can do it, partly as a vehicle to hang all those other ideas upon.

I've been looking around the web, browsing on OpenCores and finding humbling projects, such as HomebrewCPU, which is a Minix-compatible CPU entirely constructed from discrete gates. You can even browse the web pages that it is serving or telnet in to it! To my way of thinking, that is slightly nuts - impressive, but nuts all the same - five wire-wrapped boards to debug. My background is in FPGAs and that seems the perfect technology for this sort of exploration - I'm also thinking along the way that I might be able to play with synthesisable verification or FPGA enhanced verification/ emulation as well as possibly using this as a platform for a reconfigurable architecture. Lots of ideas, potential and possibilities. It will also give me a chance to re-engage with FPGA technologies and learn about more about the state of those tools. The various tools are getting to a fairly mature point and a simple pipelined CPU shouldn't require too much work but still be complex enough to do interesting things with.

I've been looking at Xilinx and Altera to get an understanding of their current tool flows and trying to work out language support and maturity - which would be the best option for systemVerilog, where the best simulation options are and that kind of thing. No real conclusions yet, but both have trial versions of what appears to be a complete tool chain, so I will probably drive a small example through both flows as a pipe cleaner.

Then of course there are the more fundamental religious issues - CISC or RISC, what ISA to use. Roll my own, pick up an already defined but open architecture, or something in between? I'm looking for suggestions in this respect - I know ARM are quite litigious when it comes to cloning their ISA, so I'll be avoiding that, but OpenSPARC might well be a good option. Any other suggestions? I'm not sure if the early MIPS ISAs are cloneable without problems? Maybe I could go really back to my roots and implement a Z80 architecture. The advantage of picking on an existing ISA is that the tools come mostly for free. While porting gas and gcc to my own ISA could also be an interesting experiment and learning experience, it would probably be more of a distraction than I want.

I am a fan of the Python language and tend to write most of my personal projects in it. As a result, I'm intrigued by the potential for writing the core in Python, using some of the available extensions and libraries. Two packages seem to already exist, MyHDL and PyHVL. MyHDL is Python extension to let you express parallel behaviour that can then be automatically translated to verilog or VHDL. PyHVL provides the other piece of the Python puzzle, enabling high-level verification in Python. So potentially I could do the design and verification in Python then drive through into an FPGA flow for implementation. JL jokingly mentioned the potential for an OVM port to Python but maybe it isn't such a crazy notion. The thing that Python is fantastic for is expressing complex ideas quickly and without a lot of fuss or housekeeping. From the verification perspective it seems to be a perfect match as I can focus more on the testing, and less on the language. I'm a bit more skeptical about using it on the design side but I think it might be worth a look.

To kick things off, I found the description for a minimal CPU on opencores. This is a really basic 8-bit processor, 4 op codes, couple of registers and a very simple, small architecture, yet it can still do some useful function. This evening I wrote a Python ISS for it, just to prove out some ideas. Took about an hour to get a working cycle-based ISS together for the architecture. Of course, immediately the next thing you need is an assembler and that was fairly easy to put together in Python too. Nothing particularly complex, but a two pass assembler that supports labels and constants and generates code that runs on the core. I'm able to assemble and run the example greatest common divisor (Dijkstra's algorithm) described in the paper and it has given me a good indication of the direction to go. So far, my couple of hour project can assemble and execute the following code:

start:
    NOR allone      ; akku == 0
    NOR b
    ADD one         ; akku = -b

    ADD a           ; akku = a - b
                    ; Carry set when akku >= 0
    JCC neg

    STA a

    ADD allone      
    JCC end         ; A=0 ? -> end, result in b

    JCC start

neg:
    NOR zero
    ADD one         ; Akku = -Akku

    STA b
    JCC start       ; carry not altered

end:
    JCC end

a: 10  ; a & b are the two values to consider
b: 30

allone: 0xff  ; various constants
zero:   0
one:    1

Next step is to describe this trivial core in a synthesisable form and see how I get on running it through one or two FPGA flows. A few tests and some verification could be useful too! For FPGAs I'm much more used to the general suck it and see style of testing that is the norm. Synthesize, place and route and see if it works. In the last several years I've been working on much larger ASICs so have certainly seen the value of more robust verification and I think FPGA technology has probably spent too much time as the wild frontier of design robustness and testing. As this project progresses I want to explore what the best balance is for testing and how the test environments can use the FPGA to accelerate testing along the way.

So plenty of things up in the air but I think this could be fun.

visual commitment

I've had an on again/ off again interest in visualization tools to enhance design and verification for many years. I've written log file parsers to show data in a more friendly way to enhance debug, or TCL/Tk widgets that demonstrate activity on bus ports of a SystemC AMBA switch model. Tools that at first glance might seem somewhat pointless visual trinkets can really enhance debug, by letting the brain search for patterns more easily within data. For example, with the bus switch, it was visually easy to see which bus wasn't getting any traffic, which could have been extracted from a log, but would have required more thought. Patterns of burstiness or busyness can also be seen quite easily. Similar results can usually be achieved with grep or clever regular expressions, but I find I end up having to keep a lot more data in my head, which pushes out the brainpower I might apply to actually working on the real problem.

Well written visualisations present the data in a more accessible way, letting you get to the problems more quickly. A good example of these from the recent DAC are a couple of OCP tools by Duolog. The tools present typical OCP information in a more easily interpretable way, colouring related transactions in a log file, or showing bus bandwidth. It is much simpler to trace a series of transactions this way, or find buses that are being starved or overloaded. The information could have been directly extracted from the log file by the user, but the visualisations make things easier and quicker.

I've been playing around with  Flash and also just started reading about the Processing language over the weekend. Co-incidentally, I happened across these visualisations of version control commits for several large projects, written in Processing. These give a good indication of how visualisations can show a lot of very complex data in a more accessible way. The Python visualisation was particularly interesting to show how few contributers there were until an explosion of contributions around the year 2000 wander on to the stage.

As our SoC designs keep getting larger, I believe that more accessible means to interpret the verification and design data and results will be needed, beyond just waveforms and log traces. I would be interested to see what the ebb and flow of check-ins look like for a complex, modern SoC. We tend to think that hardware design is just the same as software design by another name, but you might start to see structural differences in how the code and modifications organise themselves.

The Python case shows one leader, banging away on their own, suddenly joined en mass when the code base becomes popular. SoCs will also probably demonstrate Conway's Law visually, mirroring the organisational structure that put the design together. Pairs of verification and design engineers working together, sub-assemblies, clustering around organisational and functional boundaries. The vast majority of changes would be much more localised than you see in a large software project such as Python. Quite possibly other software projects fall along similar modular designs but it would be instructive to see the visualisations side by side - perhaps with the organisational (or lack of) human structure overlaid.

metrics

Listened to Brian Bailey talking on the missing metrics for verification coverage at the Certess booth on Wednesday. This was a really interesting talk discussing the standard code coverage and functional coverage metrics and pointing out that we don't really currently have a good metric to track when we are doing useful verification or not. Functional coverage is used for this, but care needs to be taken to ensure we are covering the right things.

There's a danger that functional coverage, which was originally designed to track the quality of random stimulus, is used to only track that stimulus. In this way, we might not consider if the behaviour is actually checked or not. The same ideas are represented in David Robinson's verification planning presentation at DAC. Requirements and functional coverage without checkers is a waste of time and effort. It is possible to get 100% coverage, with lots of cover points and no enabled or implemented checkers in a design. Careful testbench design, or tools like Certess, can be used to address these issues but only once you realise that functional coverage isn't a magic bullet.

I also saw a demo of the Certess product, Certitude. It randomly inserts errors into the device under test (DUT) to give a way to evaluate the quality of the testbench surrounding the DUT. The basic idea is that if the design is mutated in a particular way, the testbench is good if it can detect the error, or has a hole if this failure mode cannot be seen in the checkers. This artificial bug insertion is something I do on an ad-hoc way when developing a testbench and Certitude automates and expands on this commonly used approach.

You can read a paper from Brian on this topic.

flock together

Attended the blogging Birds of Feather session at DAC, last evening. I was quite amazed at the number of people who showed up. I had expected there to be half a dozen people and not much interest. Instead, more chairs had to be brought in and in the end about 40 people showed up, with many traditional journalists and bloggers in attendance. The discussion was lively and spirited.

One of the main themes was confusion over just what blogging is and how it should fit in to the more traditional roles of the press and marketing with the EDA world. Some of the discussion revolved around trying to classify just what a blog is or isn't and how it differs from columns, marketing or opinion pieces. To me this seems a mostly futile debate or perhaps one that stems from a lack of real understanding on what the medium is about. Really all a blog is is a way of having a somewhat one-sided or asymmetric conversation. The classification or editorial style then comes from the person who runs the blog. Columns, blessays, technical paper sources, marketing fluff pieces, lunchable debates, it is all blogging and reflects the writer of the blog. At the lowest level, a blog is really just an easy mechanism to publish on-line. Everything else becomes an issue of personal approach, rather than definition over the technical nature of the communications medium.

There was also quite a bit of concern over editorial control and company influence. Certainly it is clear that one of the main differences that a blog has over what has gone before is the democratization of content creation. The barriers to entry have been stripped away and anyone with something to say can start saying it. It is analogous to the changes with the automated printing press and how that lowered the cost of entry to distribute ideas. But anyone being able to publish isn't always a good thing. Professional writers and editors perform a useful function, giving an expectation for a certain level of quality. 

Now, editorial control over the content is removed. But editors are valuable - they are a filter on the content. That filter finds interesting articles and also maintains quality. A blog removes that or shifts the onus onto the writer to be their own editor. EDA blogging isn't going to be immune to the wide range of quality and value that exists in the mainstream blogosphere. Some blogs will be terrible. Some will be great. The advantage is that my definition of what is great and interesting might be radically different to yours, so I'll be able to find the content that is valuable to me, rather than what an editor thinks I need to hear.

Control and classification again was brought up when the issue of the 60+ EDA blogs was mentioned. The concern was that so many disparate sources of information need to be corralled and filtered, otherwise nobody could read them or keep up. Here again, I think this is a bit of a red herring. There will be a large number of EDA blogs that will appear, but I'll personally probably only care about the content of a small percentage of them. It is exactly the same as when I come to DAC. There might be 500 companies here, but I'm not interested in the products that many or even most of them have. I personally filter out all the low level layout, silicon process technology companies and concentrate on the ones relevant to me. EDA blogs will be the same - I'll find the 5 or 10 that cover my areas of interest and read those. The beauty is that you can also find the (no doubt very different) 5 or 10 that cover your area of interest and watch those. You have the control over the content you are exposed to, rather than having EE Times select across the whole EDA sphere, which then provides maybe one article per issue that actually covers part of the industry that I care about.

Along the same lines, there is no real reason that someone couldn't step up and start aggregating the content in useful ways, collecting and collating interesting content from other sources. Reputation tends to be the driver for this. If I find someone who writes interesting content I'll tend to follow their interests too. If they point to another article or blog, I'll read that. They then are providing the role of a more traditional editor to the content I read. The only real change is that there will be a lot more editors and authors, so we can all find the more personalised channel that suits our interest.

My experiences aggregating content for SoFoBoMo (Solo Photographic Book in a Month) is illustrative for this. In a couple of months, we established a group of 200 people working an indivdual book project, all working on their own project, concurrently, in the same month. Many of the participants also blogged about their experiences creating their first (for those new to the process) or latest book. Everyone was working on a similar process, but on their own personal work. I set up simple tools that pulled from all of the participants blogs and provide one, very focused, feed specifically about this shared project. Those people may well have been blogging about what they had for lunch or where they went at the weekend, but only the relevant entries about SoFoBoMo appeared in the feed. It would certainly be quite trivial to do something similar for hot EDA topics too. I could do that and publish it and become a hub for those conversations. There is a world of free tools out there just to do this task. A feed that combed all the EDA blogs for ESL topics or OVM or whatever buzzwords you are interested in is trivial to set up and would deliver customised content on a daily basis. Certainly not all readers will set this up, but it only takes one person to do it and share it for everyone to benefit.

Janick Bergeron raised some interesting concerns common to most bloggers, on how to maintain the flow of content. There have been a lot of articles written on how to feed the beast, with blogs devoted to these sorts of topics. This isn't really an EDA blogging or even a blogging specific topic, but one common to anyone who writes. Passion has to be the driver, particularly for a personal outlet that isn't corporately funded or part of a job. I think it is hard to fake a blog - you have to want to do it, enjoy writing and have something to say. There are certainly mechanisms to help discover content or processes you can put in place to make it more of a habit, but you have to want to do it at a fundamental level. My blog on photography exists because I'm interested in discussing the topic. I want to share the ideas and learn from others following a similar path. I write it now because I can't stop writing it and I enjoy the process of ordering my thoughts.

James Colgan and I had an interesting conversation on what topics make sense for blogging. I think there can be an initial fear that you have to be an expert in a particular topic to be able to talk about it. That can certainly be one approach. But there can be a lot of value to others in describing a learning process. You can become a guide for those who are following the same path if you point out the pitfalls that you fell into along the way. I used my experiences photographing strangers as an example - 18 months ago I started blogging about my attempts to get better at taking pictures of people I didn't know. My early efforts were painful but I kept talking about how it improved over time. Some of those articles are amongst the more popular and valuable ones that I've written - because others who are earlier on that learning curve can see what I did over time. Similarly, in the EDA industry I could see that an expert on OVM blogging about use of the methodology would be fascinating. I could also see that a blog written about the frustrations of trying to learn to use the OVM for the first time would be of value. The expert has already probably forgotten the details that the new user might get hung up on and maybe wouldn't even know about the common mistakes that would be made. There is value to both and sharing that sort of experience.

Overall this was a really interesting and fun session. Kudos to JL for pushing to make it happen and to everyone who attended and made it such a lively discussion.

Where are they now?

DAC started early with a Mentor sponsored breakfast at 7:30. Got to see a bit about some of their testbench automation tools that help steer coverage to more interesting parts of the design. There are a few other companies here that have similar products. The aim is to move beyond user driven constrained random testing and let the tools help in solving the problem.

After that, I listened to Gary Smith on the state of the EDA industry. Highlights:

• It's all about the software
• Threads are dead
• C is finished to be replaced by some useful concurrent language - brush up on Occam I say
• Verification is a solved problem and will be automated - don't bother being a verification engineer
• Almost 38% of companies roll their own EDA tools

His talk made for an interesting start to the day, at least.

I spent the rest of the day attending various sessions and tool demos, which I'll write more about later. I've been surprised how low attendance is. There are a lot of people from the tool companies in their booths, but not many customers for them to talk to - and that was on Monday, the free attendance day when there aren't that many technical sessions or other distractions.

The Open Verification Methodology(OVM) is a hot item this year, with many sessions discussing issues around use and interoperability. Many vendors are showing products or claiming compatibility with this new standard. SystemVerilog is the other dominant theme though SystemC still has some traction. The last time I was at DAC SystemC was the new kid on the block that everyone was expecting to take over the world, not so much any more and it has settled into a system level modeling niche.

The disturbing thing I am seeing is how little progress has been made in the last decade in the ESL tool industry. Many years ago I was working on ARM926 designs that were not on the bleeding edge, even then. Today, many ESL companies are still just showing support for ARM9 or being excited about performance of their ARM7 models. That's at least 2 or 3 cycles behind the latest processor technologies and a huge leap in tool complexity to keep up. Synthesis capacities are rising much slower than the process technologies, tools companies are stalling out, reimplementing the same technologies to support systemC, systemVerilog or what ever the new hot language or methodology is, without apparently making any significant progress.

The other problem that the ESL companies face is the lack of models for their particular product line. Many seem to be falling into the same trap - expecting customer demand to dictate which models to develop. But that isn't going to work - the systems designers need the models right around when they decide they need the models. There is no lead time. There certainly isn't the 6 months to 1 year lead time it takes to find the right ESL company, negotiate and convince them to start creating a model, get the team together and write and verify the model, then deliver it back to the system architect. When the architect wants the model, there might be a 1 week lead time. Maybe a month, before serious work needs to start. The whole investigation better be mostly finished in 6 months. ESL companies need to seed their model libraries in anticipation of customer need. If they wait for the customer, they'll always be too late to be any use at all and keep going round that loop. In spite of that glaring hole, ESL is another hot ticket at DAC this year. Software design and implementation continues to increase in cost and complexity and HW/SW co-design companies are proliferating as a result.

With the apparent dearth of progress and lack of useful model or up-to-date models, I'm not too surprised that almost 40% of companies are looking inwards for their EDA tools. Might also explain where everyone is this year, too.

The one bright light in the ESL space is that although many of the tools and methodologies haven't changed much in the last 5 years, they do seem to have moved on from being all smoke and mirrors and snake oil to perhaps actually working. So maybe things haven't changed, they've just become real.

DAC for verification: highlights from deepchip

Each year, John Cooley does a great job previewing the companies at DAC. From that list, here's the ones that sound interesting to me.

OneSpin's 360MV tool does something called "gap-detection" plus timing diagrams on your design's System Verilog Assertions. (booth 625)

Real Intent Meridian CDC for clock domain crossing verification. Formal analysis and interfaces to simulation.
(booth 2540)

NuSym DeNibulator's intelligent testbench" It hunts down your hard to find coverage points and automatically tweaks your TB to reach them. It's next gen constrained random. (booth 379)

Certess Certitude testbench error injection.(booth 324)

Another "intelligent testbench" is Mentor inFact - graphical tool that generates, grades, and then upgrades TBs. It
now drives existing e, Vera, SV, or C/C++ TBs. Does OVM & VMM.(booth 2301)

CebaTech is showing their C2R Compiler,which takes untimed ANSI C and outputs Verilog RTL. (booth 760)

Forte Cynthesizer v3.4 (SystemC design) adds support for Power Compiler for "best-in-class area, performance, and now power results" and "management of ECOs by graphically mapping RTL back to the original SystemC design" and inter-block interfaces.(booth 1645)

Mentor 's Catapult C synth & Vista ESL tools. (booth 2301)

Carbon's Model Studio does Verilog-RTL-to-C conversion for simulation, to get early models for architectural work(booth 2467)

Synfora Pico Extreme C synthesis tool (booth 329)

Bluespec : "general purpose high-level synthesis & simulationfor modeling, verification and implementation". (booth 2367)

Imperas : yet-another-ISS tool, OVPsim, for embedded SW. (booth 467)

Mirabilis VisualSim does "graphical SystemC TLM 2.0 import without any code development; and power estimation of the full system." (booth 778)

Steve Golson's "Four Principles of Flow Engineering" DAC Tuesday at 10:30 AM, Room 206AB

Dassault Synchronicity DesignSync Cadence data management tools. (booth 620)

EVE ZeBu is showcasing PCIe and AXI synthesizable transactors and its System Verilog support for custom transactors.(booth 301)

Mentor Veloce "using mixed System Verilog and SystemC based upon System Verilog DPI standard 2.0" with Nucleus embedded RTOS (booth 2301)

Synfora Pico Extreme FPGA (booth 329)

VeriEZ EZVerify covers you design, assertions and testbench, with added full System Verilog support this year plus VMM/OVM checking (booth 1936)

Veritools usually has linters, code coverage and waveform viewers. Supports SV dynamic objects. (booth 1334)

Denali PureSpec System Verilog methodology support (OVM,VMM, AVM) in all IP blocks. (booth 1611)

visualising complex datasets

A great example of the sort of insight that you can glean from a lot of data, with the right sort of visualisation.

new companies at DAC

Based on the list of exhibitors and the scant information provided, these are some of new companies that appear to have a verification aspect to their products. I'll be finding out more next week on site. Brian Bailey has his take on DAC for Verification, over at Chip Design mag, that is worth a look if you are struggling to fill your schedule! There is quite an overwhelming amount of things packed in to next week.

• Amiq Consulting S.R.L.1
  • RTL level verification & verification IP
    

• Axilica Ltd.
  • Tools for UML modeling/simulation of HW/SW designs
    

• Duolog Technologies Ltd.
  • Intelligent testbench, ESL verification - Socrates design environment
    

• Imera Systems, Inc.
  • Network virtualisation, remote debugging and source code access
    

• Paradigm Works, Inc.
  • Verification services company. Selling SystemVerilog FrameWorks tools
    

• SAS Satin IP Technologies
  • Design reuse management flows & technology. VIP lane product for IP deployment
    

• Synapse Design Automation
  
  • Design & Verification services company
    

• WinterLogic Inc.
  
  • Verilog fault simulator company: Fault Manager