Thanks Steve. It is working fine if I have a static solid shape in my board, but, for a dynamic copper pour the outline is still visible. Is there any other settings for this? Regards, Chadga
↧
Forum Post: RE: How to Disable visiblity of only Dynamic Copper shape
↧
Forum Post: RE: How to Disable visiblity of only Dynamic Copper shape
Hmm this just works for both static and dynamic shapes. Are you sure it's the shape outline that is showing and not another layer? Try turning all layers off then just an etch layer on, then toggle the Shp checkbox.
↧
↧
Forum Post: RE: How to Disable visiblity of only Dynamic Copper shape
Yes Steve. I tried the same steps, it's still the same. I have attached screenshots for your refrence, just to make sure if I am doing the steps right. near Capacitor C4 there is a small static shape. that will turn-off, but for dynamic copper the outline remains. What might be the issue? Regards, Chadga
↧
Forum Post: RE: How to Disable visiblity of only Dynamic Copper shape
What hotfix are you using? I'm running 17.2-2016 S049 and it just works. The shapes at the top are dynamic and the on below the cline to the right is static.
↧
Forum Post: RE: How to Disable visiblity of only Dynamic Copper shape
I am using the same hotfix version S049. I think I got it, i tried turining off the boundary in color dialog box and it worked. Thanks for the quick response. Regards, Chadga
↧
↧
Forum Post: RE: Error about Environment Variable settings
Thank you very much indeed Andrew.
↧
Forum Post: RE: Updating Net Names in Layout XL
I suspect that some of the nets have ended up with a "sticky" net attribute on them and are being preserved after the copy. As you say, VLS XL will be OK, but it would be good to fix. The best way to do this is to use Connectivity->Update Binding. Set preserve existing bindings to be on (so that you don't change any existing bindings), and also turn on clear connectivity . This will remove any existing logical connectivity, including any "sticky" nets. That should fix the net names. Regards, Andrew.
↧
Forum Post: Systemverilog interfaces over hierarchical boundaries
I have experienced some back-end issues using systemverilog interfaces when and interface is traversing over hierarchical boundaries. I've tried to sketch the situation in the attached drawing. The top picture shows the "regular" method of using interfaces. the interface and connected module are all instantiated at the same level of hierarchy. This works for simulation and back-end. The middle picture shows my situation. At the toplevel I have a module and interface instantiation. The interface is connected to the purple module and then connected to 2 sub-modules. In simulation this works. Then the synthesis tool complains that the interface at the purple level should be an modport. So I added that. However the synthesis tool is interpreting the wires in the as bidirectional and adds logic to facilitate this. In my design all wires are unidirectional. The only workaround I could find to fix this issue is depicted in the lower picture. I connect via a modport the original interface (labeled A). Then I instantiate a new interface (labeled B) which has the same parent as interface A. Both interfaces A and B are connected to a connect module which contains a lot of statements like: assign interfaceB.rx1 = interfaceA.rx1; assign interfaceB.rx2 = interfaceA.rx2; assign interfaceA.statusX = interfaceB.statusX; etc so it is just a "dumb" connection of interface A and B. This way of work feels very wrong as this connect module is creating a lot of overhead. Is there a good / easier way of using the interface over hierarchical boundaries that is not only working in simulations but also works for synthesis? Thanks community.cadence.com/.../3817.drawing.pdf
↧
Forum Post: Problem about font
Hi all, I'm drawing a new schematic and I have a simple problem about font of the value of component , reference and nets name. I want to have for each component the same font size. In each ibrary of components the font is the same. When I put a new componet in the page, I see always different font. Is there someone that can help me? Thaks.
↧
↧
Forum Post: How to use ocnDspfFile with case_sensitive port/net names
ADE allows to use dspf with the option to honor case sensitivity, the corresponding ocean command does not offer any options. How do I set said option there ?
↧
Forum Post: RE: How to use ocnDspfFile with case_sensitive port/net names
Easiest way is to try it on the form and then save an OCEAN script to see what it does. It's not a separate argument: ocnDspfFile( "\"doodah.dspf\" case_sensitive=true " ) It's embedded in the string. Andrew.
↧
Forum Post: RE: How to use ocnDspfFile with case_sensitive port/net names
Thanks, Jan
↧
Forum Post: RE: Differential pair constraint region problem
Very helpful tool, thank you! However, this does not solve my problem. Like I said, I am able to route the net and there are no DRCs. Normally, as I am routing a net over a constraint region boundary, the geometry of the traces will automatically change at the boundary, based on the constraint, before I ever "click down" any trace. For some reason it is now not doing that, I have to click down trace beyond the boundary first, and then the geometry changes. This is more of an inconvenience than anything else, but weird behavior nonetheless. The pictures that Krzysztof provided show this behavior perfectly.
↧
↧
Forum Post: RE: dbCopyCellView does not return cell_ID even when the cell is correctly copied.
What sub-version are you using? In other words, what does getVersion(t) in the CIW return?
↧
Forum Post: RE: dbCopyCellView does not return cell_ID even when the cell is correctly copied.
I'm hitting a problem with replying, hence several attempts to post. Can you please show your SKILL that you're using to perform the copy?
↧
Forum Post: RE: dbCopyCellView does not return cell_ID even when the cell is correctly copied.
Were there any messages in the CIW when you tried to do this? I'd also like to see what the directories for the cellView look like in UNIX too
↧
Forum Post: ihdl vs netExpr
I have a question about inherited connections and ihdl. Short version is ihdl adds a "!" to the terminal db object name in the generated schematic and I didn't expect the "!" there. According to the manual, I should be able to add some stuff to a verilog netlist which will cause the imported schematic to have a net expression on one of the terminals. For example: module mymodule(......, MYVDD) (* netExpr = "MYVDD(MYVDD)" *) input MYVDD; ..... endmodule After I run ihdl, what I end up with in the schematic is terminal name = "MYVDD!" (note the ! which I did not expect) pin name = "P__69" (not unusual for a schematic pin db object) default net = "MYVDD!" (here the ! is expected and required) property name for the terminal net expression = "MYVDD" (also expected) If I check the result of dbGetTermNetExpr(term) it is "[@MYVDD:%:MYVDD!]" as expected. What I'm wondering about is the presence of "!" in the terminal name. When I create a schematic by hand in virtuoso with an attached net expression, I don't get the "!" in the terminal name. Is there a way to tell ihnl to not add the "!" to the terminal name? Should I worry about this? There can be so many tools that may be used at some point in a design cycle (Virtuoso Schematic, Layout-XL, Assura, PVS, auCdl, spectre, UNL, AMS, UNL, Innovus, ultrasim, VPS, Voltus-Fi, dspf, av_extracted, .....) that a name I wasn't expecting or that is different from before always makes me wonder which tool will get unhappy with me in a confusing and hard to find way.
↧
↧
Forum Post: RE: How to do Components placement movement in a particular angle from existing position when we don't know the exact XY locations to where we need to move
Perhaps I am oversimplifying the problem here, but it looks like you want to 'slide' the component down the 75-degree angle. With a little trigonometry, you can find the x,y displacement. From the image you posted it looks like those x,y moves have been calculated. I would simply move the component and type in the command bar ix .423 iy -.034. Now if they need to stay normal to the 75-degree angle, you will need to go to your SOH, CAH, TOA bag of tricks.
↧
Forum Post: RE: How to update the netlist (input.scs) from extracted view after QRC extraction
Hi Andrew, Thanks for your help. I tried to type the command in CIW and also ocean, but there is another error " *Error* eval: not a function - "asimenv.misc" " for both of them. Please let me know if you have a solution for this problem. Regards Mohammad
↧
Forum Post: RE: How to update the netlist (input.scs) from extracted view after QRC extraction
My guess is that you put a space between envSetVal and the open parenthesis. That’s not allowed (and wasn’t there in what I posted above). SKILL (for various good reasons) doesn’t allow that. So please try it without the space. Regards, Andrew
↧