1 of 1 people found this helpful
Sorry about the delayed response.. I have been traveling with limited free time.
We have made a big push this year to decrease the amount of time to fulfill a FPGA device request from a customer. We have instituted new policies and processes and have shrunk the request to delivery time substantially... we are now averaging just a little over one week.
That was step one... We are now working on a patch to IOD that will allow IOD to monitor a web site and detect when new FPGA devices are available. IOD will then ask the user if they want to download and install the latest devices. I do not have an exact deliver day for this path although I am able to tell you that our team has been working diligently to get this done as quickly as possible (while delivering a high quality solution).
We have effectively separated FPGA device data from the software code allowing independent delivery of devices. This is true 99% of the time... some FPGA devices (very new) require us to modify our software and in those rare cases we will go through the standard SupportNet s/w release process.
The other aspect we have been working on is a "easy" design flow that fits into the normal PCB design process... we call this flow the "IOD Schematic Update" flow. While this flow has been supported for some time we are taking steps to improve the ease of use and performance of the flow. We have a software patch which is days away from release that will allow IOD users creating FPGA parts (symbols + PDBs) to specify the Central Library partition directly from within IOD prior to PDB generation.
That is step one to make the integration between IOD and the Central Library easier to work with. The next step will be direct integration with the Central Library. Right now the Librarian has to perform a couple of additional steps to take the symbols and PDB and import them into the CL. We hope to the direct integration done by 7.9.1 --- but we need to make sure we have all use cases covered so we may decide to make another incremental step forward instead of delivering the complete integration path. More news will be posted as we make progress.
Obviously we are working on more than these couple of items for the next EE release (7.9.1) and one of the capabilities we have planned is user creation and editing of FPGA devices. While complete generation of a new FPGA device will be available through this process the need expressed by some of our customers is less ambitious... they simply want to modify (in most cases "restrict") the usage of the FPGA devices to meet their corporate guidelines. Creation of user rules for IOD has been available for some time this is the next evolution that will allow MGC delivered rules to be modified (and become user rules).
We will also deliver improvements to the performance of the PCB optimization engine (faster run time) for both single and multi-FPGA designs. In fact we have a big push implementing new optimization algorithms for multi-FPGA optimization. At the moment our suggestion is to optimize each FPGA in a multi-FPGA design individually and then run multi-FPGA optimization to achieve the best PCB implementation results. This is a bit time consuming for designs with many FPGAs. The next iteration of the multi-FPGA optimization engine will implement new strategies that should eliminate the need for the individual FPGA device optimization before performing multi-FPGA optimization. In general, we improve the IOD PCB optimization engine in each release of IOD (both performance and functionality).
These items are tactical implementations or our strategic objectives. If we look further out our planning process includes aggressive new functionality to help users better integrate their FPGAs onto their PCBs. One area we have been exploring is something we call "IO Standard Synthesis": This is the coupling of IOD, Signal Integrity and physical layout so that we may sweep the IO Standard sub-parameters (drive strength, termination topologies, etc..) and suggest to users how to best configure their FPGA IO for signal pins to minimize passive PCB component insertion while meeting their electrical constraints (described in CES). We see this as a natural evolution of IOD.
This is a look into what we are working on but this is not a comprehensive list... just highlighting some of the top-line items. As we get closer to the next software release (7.9.1) we will provide a more detailed explanation of the complete set of enhancements for IOD. (now that we have this community up and running there is no reason to wait for the "what's new and cool" document we include with each release.)
Thanks for joining the community and using IOD!!
On the subject of user rules
- I would like to be able to create IOD projects for other devices (like DSPs) that have some variable function pins & swapability
Is this possible?
Although these are much more restricted than FPGAs, IOD would be useful for quicker creation/update of functional symbols & schematic.
The multi-FPGA improvement and IO-Standard synthesis sound good but these are at the high end of the functionality.
We do a lot of designs with one FPGA and fairly straight-forward IO standards where we wouldn't gain a lot from these functions.
I think there is more productivity to be gained by improvements to the basic functionality
- for me integrating more directly to Expedition would be the biggest improvement
I guess you're sick of us mentioning Altium but their demo does show what you normally want from pin swapping in practice (for me at least)
The sequence of
- break out the FPGA
- route towards the FPGA
- use optimise function to unravel the nets to connect the last segment
... is precisely how I would want to do it.
IOD is more powerful in its understanding of the FPGA pin allocation rules but not being so interactive with the layout makes it much slower than it could be.
(having to back-annotate, load layout, unravel, update scm, forward annotate etc).
Does anyone else feel the same?
Yes, Mentor is reducing the number of clicks needed for IODesigner while expanding the power. The reason some competitor tools are easy to start using is their lack of power and complete lack of compatibility with other tools or design flows. For example, the reason you have to choose in IOD if you want to choose to import from the schematic to IOD or export from IOD to the schematic is because IOD can go either way. Let's say you are a visual designer. You can draw a schematic functional block and work back to automatically output the HDL port list. Now lets say you are a code wizard. You can be HDL centric and drive everything from those declarations and constraints through to automatically exporting PCB symbols, functional block symbols and nets to schematic then layout. And you have some layout tools choices. If IOD offers different choices, it must have more clicks to allow for the selection. Still I agree, less clicks is where it is headed.
IOD will work well with the sequence you prefer:
Define the FPGA interface signals
Place & break-out the FPGA
We are adding capability to the post break-out unravel so it will be more aware of things related to your stack-up.
I'd do more of a compare and constrast to competitors, but there isn't much similarity between just pin swapping and unraveling: vendor and user constraints aware pin assigment optimization that automatically changes your pinout and updates your schematic and your compilation constraints.
Thank you for your desired flow. Your step of breaking out the non-FPGA device before looknig for optimization is something I will experiment with.
Also, to clarify/emphasize, a fractured PCB symbol set doesn't slow down pin swapping. Fracturing functional symbols does add limits.
Don't get me wrong, I like IODesigner - it's been a real benefit already in the short time I've been using it.
During schematic creation it saves loads of time.
During layout it lets itself down a little - improving the interaction between layout and IOD would make it a lot more effective (to me at least).
& I agree it's a lot more powerful than competitors
- but a few fairly small improvements could make it as easy to use as well!
Little things like
- cross probe by selecting the nets in layout to swap/unravel in IOD
- colour/highlight nets in layout by swap group / FPGA bank
... would help to see what you're doing
The biggest time-saver during layout would be speeding up the sync/update path so you can make pin allocation changes almost live:
If you had Expedition and IODesigner both running 'in-sync' would it be possible to provide faster import / export functions (just the changes since the last sync)
For small changes (like pin swaps) would it be possible to export directly to the schematic and layout simultaneuosly to avoid the forward annotate step?
Bigger changes (like symbol changes, adding new interfaces etc) are OK being slower because you don't do these as interactively.