Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
Get email delivery of the Cadence blog featured here
A while back I visited a customer I see on a fairly regular basis. As soon as I entered the building, my primary contact asked if I'd stop off to talk with a colleague of his who had an Encounter problem. It was a bad one -- he was dead in the water and he couldn't get past the issue.
It's fairly unusual to look at a problem as an application engineer, and make quick suggestions that resolve problems. Especially lately, it seems. Invariably, the problems I see are complicated multi-variable things that take a lot of time and effort to pinpoint. But this one was different. It took me less than a minute to diagnose this problem and resolve it with the user. This scenario got me thinking that sharing these little tidbits would be an interesting addition to the blog. Challenges like this become a "puzzle" of sorts; I share some symptoms and clues, and you can take a crack at it and learn a little bit about how Encounter works along the way.
So here's the first puzzler:
The designer I visited was attempting to perform floorplanning operations in the tool. He inherited a database from another designer and needed to refine the solution to derive better fence locations and sizes. However, there was one big problem -- he couldn't see any fences in the design! Here is what the designer saw when he looked at the floorplan in Encounter:
The following is what he expected to see (5 fences):
The strange thing was that when the original designer was working on the database he could see the fences. We checked to make sure Guides/Regions/Fences/Modules were all visible and selected -- they were. We found one simple setting that, when changed, made the fences visible.
Do you think you know what's going on here? And why could one designer see the fences while the other could not? If you have an idea, leave a comment below.
Check back on Friday for the answer. Or better yet subscribe to the Digital Implementation blogs to get new content delivered to your inbox or favorite feed reader.
@Kari that's a very good point you raise. That can indeed happen as well- thanks for sharing!
I actually had a different answer. My answer assumes that these fences are a couple of layers down in the hierarchy, in which case they would not show up until you press the "hierarchy down" button the appropriate number of times. Of course, the first designer would have had to do the same thing - I wasn't sure if the first designer saw the fences immediately on loading the design, or just was able to see them at some point during his session. I just wanted to mention this, because it has also been a "where did my fences go" moment for folks before.
Man you're good. I'll have to kick up the degree of difficulty a notch for puzzler #2. I'll post a little further discussion around this soon but you nailed it.
Thanks for participating!
Well, assuming no explicit sourcing of local scripts (enc.pref.tcl) and no command-line typing of this setPreference setting, I'm going to guess that the original engineer had the following line in their ~/enc.tcl file:
setPreference MinFPModuleSize 0
Jason- you're spot on with the Min. Floorplan Module Size setting. For extra credit, what was it that one designer could see them yet when the other looked at the same database they could not see them?
Well, there's the obvious questions:
a) Are they in "floorplan view"?
b) Are the fences empty (you have to tell EDI to keep empty modules by setting the "Min. Floorplan Module Size" entry setting in the preferences)?
If not that, I don't know what it could be.