Below is an email from a Glann Ball of Utilitek Systems that I thought will be interesting to others.
I think your use model analysis of CES is spot on. It sounds like your approach of extracting data, allowing users to manipulate it, and then import it will address the need for a way of automating data manipulation, as long as all of the data is there. One case I can conceive of where the lack of an in tool automation layer would be a problem is some kind of external app needing real time interaction with the CES data. Say a user facing app for review of data for instance.
Export / manipulation / import does not really cut it for that. But I'm not sure how many customers are going to go to that level of sophisticated app anyway.
Do you think you would leave API interfaces in CES to allow external apps to trigger an export or import? That would be a good idea from my point of view. I'll post that on the IDEA.
If you want to post this exchange on the PCB community you can.
On 4/14/2011 6:43 PM, Shively, Steve wrote:
> I appreciate your frank questions.
> We do understand the benefits of a general purpose automation layer, but we struggled with the one in CES. There is a significant difference between CES and Expedition (for example). The primary use model for CES is to enter constraint data. Admittedly, there are a few other functions such as doing calculations for impedances around stackups, but by and large one enters rules to constraint the design implementation. In contrast, Expedition is about implementing the design; things like placing components, fanout, and routing. So really, the primary use model of automation in CES is about importing (and sometimes exporting) data. And that's something we need to do a much better job of within CES itself.
> So I want to very clear here: the plans for Expedition and CES are quite different for a number of reasons. Removal of ascii in/out is very specific to the HKP format of Expedition. For example, we have other ascii formats that are supported such as gerber outputs or keyin netlists. Those are not going away. We are not going to remove the ascii outputs of CES. In fact, I plan to enhance it.
> For importing I have a number of options but the one approach I'm focusing on right now will allow users to extract constraint data from CES, manipulate it, and import it. I've started an IDEA to seek input from users on their use cases for import so if you have specific needs, please add them there soon.
> I think the best way to get the functionality you desire is to post your need on the IDEAS site and get others to vote on it. I keep a keen eye on this and use it to help prioritize the enhancements we make to CES. I also keep an eye on it (especially if you tag an item as "CES Automation") so I can provide feedback on our plans, or alternatives for completing a specific task. We are focusing effort specifically on eliminating the need for specific automation and the next release (EE7.9.3) will feature these kinds of enhancements.
> Again, I appreciate your direct questions. In fact, I think others may benefit from this. So I would like to ask: do I have your permission to put this exchange on the PCB Community?
> Steve Shively
> Systems Design Division
> Mentor Graphics Corporation
> +1 720-494-1037
> -----Original Message-----
> From: Glenn Ball [mailto:email@example.com]
> Sent: Thursday, April 14, 2011 3:30 PM
> To: Shively, Steve
> Subject: Re: CES automation
> Thanks for the information Steve.
> I'm a little surprised by the removal of automation from CES permanently. One of the more powerful things about Mentor tools is the
> ability to add functionality that is not present in the tool at the current time. Or that Mentor does not see a need for among their
> broader customer base and thus understandably is not willing to invest in putting into the tool. The automation layer allows the customer to
> determine if the functionality is worth the investment of their own resources. But without it, customers are locked into what exists in
> the tool. Honestly, I doubt that Mentor can, or wants to, anticipate all of the needs and address all of them.
> I think a see a contradiction in this decision. On the one hand, Mentor has generally stated that the ability to export / import ascii
> will eventually be removed. In your letter you indicate that it will be licensed starting in EE7.9.2, which I assume is a precursor to its
> ultimate removal, as with other tools. Mentor's stated remedy for no ascii export / import is to start using the automation layer.
> Unfortunately most PCB designers are not programmers so I don't agree with that decision, but I also realize it is not going to change. The
> curious thing here is that the automation layer is being removed. So with no automation, and eventually no ascii import / export, are we
> left with no way of automating anything? Or are you saying that CES will be unique among the tools, with an ability to export data which
> we can then interact with in an automated way and then import into CES?
> We currently have 1 CES automation project on the horizon. I do appreciate the heads up that the layer will be going away in the future.
> It allows us to re-evaluate going forward with the project. But it is not clear to me how we will get the functionality we desire implemented.
> On 4/14/2011 4:47 PM, Shively, Steve wrote:
>> Clearly we are only starting this process now, and we expect this to take time to ensure we have enabled customers to make a smooth transition before the hard removal. We have not picked a specific version for that yet. We plan to provide notice well in advance of it happening.
>> We don't have plans to re-enable this automation layer in the future. We are focused right now on extending CES capabilities in many ways beyond the robust import mechanism.
>> Steve Shively
>> Systems Design Division
>> Mentor Graphics Corporation
>> +1 720-494-1037
>> -----Original Message-----
>> From: Glenn Ball [mailto:firstname.lastname@example.org]
>> Sent: Thursday, April 14, 2011 2:31 PM
>> To: ces auto answers
>> Subject: CES automation
>> I got the email regarding CES import/export and automation. I
>> understand from the email that the automation layer is going to be
>> removed at some version. You state that the layer will be licensed at
>> version EE7.9.1 update 10. At what version does it disappear entirely?
> I also don't see any indication that of when the automation layer is
>> going to be put back into place. I am hoping that the removal is
>> temporary in order to allow you to focus resources on the
>> import/export and that you will come back at a later version and put
>> the automation layer back into place. Is that the case?
I understand the status but I don't think Mentor take an action to banner CES automation. Year ago, I have requested decrypting .cts file, but Mentor told me there is no method to decrypt .cts file and no roamap for implementing it.
SR : 2240516241 (View SR definitions)
Bigin from 2007.x, .CTS file is encrypted. We used to re-use contranits by a Exporting/Importing contraints ASIIC file in 2005.X, and it works well. In 2007.2, It still works mostly although .cts file is encrypted. After migrating to 2007.6, it fails mostly. We wish to investigate what is wrong by decypting the .cts file.
I have requested this before, but Mentor refuse to provide us with decrypting methode to .cts file.
I can see some of the reasoning of removing automation, but have some thoughts,
we currently don't have any automation in place for CES, but there are cases where
it would help to do something with automation.
1. Add custom menu and items, not to manipulate the data, but f.i. add a link to company guidelines
2. Being able to set a design up with resonable defaults, currently if a design starts there is no
template information until the design has been forwarded to Expedition. With Automation you
can do so something with a trigger, prompting with a template to use
3. Add menu items to export data, process it and re-import it in CES
Most likely there are more cases like this, I just want to start the discussion.
I think the 'switch off' of Automation should not be all or nothing, but more of removing some
capabilities and keeping others.
Correct, we do not provide any method for decrypting the *.CTS files. This data is used by CES and it assumes it has been written by CES, therefore users are not allowed to edit it..
So it seems that the issue you have is re-using constraints from one design to a different design. So I have a few quesitosn for you about that.
What constraints do you want to re-use?
Do you want to copy the schematic and/or layout data as well?
If so, hareuse blocks provide this fucntionality.
If not, what do you expect the system to do when the constraint data does not match the design?
Do you want to copy the layout data too?
Thank you for this input. A few comments:
1) I can see how this could be useful.
2) The user may import a layout template that will provide design setup information into CES for staock, net clasesses, etc. This can be done before going to layout.
3) I'm developing a solution for this. See IDEA# D5884.
2. I am aware of that, but most designers here don't deal with starting designs all that often,
so we provide them with a 'good' setup. The template import for CES is an easy overlook
with a lot of work and possible errors if not done.
I am not saying automation is the solution, but in general it can help to avoid common mistakes.
Understood. So how do you provide a "good" setup today?
For CES, currently by instruction. I did have the idea to implement some automation
based on the trigger ProjectOpened, with some sort of test for a scheme that has to excist.
It is on my todo list, but the CES automation announcement somehow is not really helping me
Most of layout guys dislike to entry constraints from ground, they like to use export/import method to copy it from another similar design . the contents they hope to reuse include below:
4) other general constaints
And, they hope the software can intelligent enougt to eliminate all confilicts, that they hope the tool can be automatically rebuild differational pairs and electrical nets, add delay fomulas etc , assign netclass to nets.
I think that reusing constraints is a really good methodology as many desings are similar to previous designs. The challenge is to be intelligent about it, because simply copying constriants can lead to bad results. Constraints do not map 1:1 to schematic or layout design objects that users typically manipulate. This means that changing a name of an object, disconnecting nets or pins, removing a component, and changing technologies can have a big impact on the constriants associated with these objects. We recognize the need to make our software more intelligent about constraints, and we are working on that.
I am surprised that more customers are not making use of Layout Templates to set up many of the design rules, especially the physical constraints. Instead, I see customers using automation to do this.
We are using the Design Capture - CES - Expedition flow.
Design capture does not have an automation layer.
We use CES automation to cross-probe between applications and DC.
We have a few applications that select parts or nets in the schematics from excel sheets and we have another internal application which also selects parts and nets in DC with the CES automation.
These applications are important for us!
It has been many years since I moved from Design Capture to DxDesigner, is Design Capture PI no longer available?
we don't use the PI.
With CES it is easy to cross probe.
I could send the script but now it is deprecated...
Nevertheless we need this functionality as long as we are with Design Capture.
CES was one of the reasons for moving to 7.9