QUIP: add_new_cell supports only subset of architecture?

[Altera_Forum]

I was hoping that ::quartus::chip_editor::add_new_cell would allow me to add any valid cell in the device, but it seems to primarily (or only?) support LCCOMB and LCFF cells. 

 In particular, I would like to be able to add any BLOCK_INSTANCE defined in the appropriate architecture file, in my case quip_v60/data/architectures/stratixii.arch. (I'll temporarily ignore the fact that the block names don't map very consistently between the architecture definition and Quartus. Furthermore, I confess to still being fairly new to Altera architectures.)  Consider any of the following attempts for valid blocks in the EP2S60F1020C3. This works as expected:  add_new_cell -cell_name new_cell -location LCCOMB_X1_Y1_N0 -comb  This throws no exceptions, but nevertheless reports "Error: Encountered an unknown error while attempting to execute the ECO command":  add_new_cell -cell_name new_cell -location IOC_X0_Y2_N0  This reports "Internal Error: Sub-system: CUT, File: /quartus/db/cut/cut_atom_io.cpp, Line: 3118\n IBUF atom can be created only on Stratix II or later families", complete with stack trace (and by the way, this is a Stratix II):  add_new_cell -cell_name new_cell -location IOC_X0_Y2_N0 -ibuf  Since IOs tend to have COMBOUT outputs, I wondered if perhaps the -comb could appease the software. This throws no exceptions, but nevertheless reports "Error: Can't move atom |cellins|new_cell" (who said anything about moving?):  add_new_cell -cell_name new_cell -location IOC_X0_Y2_N0 -comb  And likewise with IOC_X0_Y2_N4, PIN_D30, MRAM_X51_Y20, DLL_X48_Y52_N0, ...  I do see that there's an add_new_io function, but it claims to be reserved for earlier architectures. Which brings me back to my primary question: Is there no way for me to instantiate arbitrary blocks that exist in the device?

[Altera_Forum]

What is it you're trying to do? I'm guessing very few people who watch this board do much Chip Planner Tcl scripting. I've done it a few times, and it's only been a minor tweak on scripts I've created from the Change Manager. But that's really what the ECO's of the Chip Planner are designed for. It seems almost like you're trying to create a design with the Chip Planner, and a large one at that(i.e. I'm sure people have created small designs that are a handful of LEs, like a special clock mux or something...) 

If you describe your goals, there might be a better way to do it.

[Altera_Forum]

--- Quote Start ---  I'm guessing very few people who watch this board do much Chip Planner Tcl scripting.   --- Quote End ---    I understand. Is there a better forum for this?    --- Quote Start ---  I've done it a few times, and it's only been a minor tweak on scripts I've created from the Change Manager. But that's really what the ECO's of the Chip Planner are designed for.   --- Quote End ---    I suppose I was under the impression that TCL didn't merely provide a public API for Quartus, but actually tied in to its core functionality. So although I knew that Chip Planner looked at changes as ECOs, I assumed that the TCL interface would open things up and give the kind of flexibility and control that I'm used to with XDL in the Xilinx world.  The academic side of me would like to see that kind of control for the benefit of all the router and placer papers out there, almost invariably built on simplistic assumptions about the architectures, and ultimately unusable in the real world. In general when I've wanted a router or placer that could work with real architectures, I've had to write my own, and that's a shame because my expertise is more with the underlying data than with the placing and routing algorithms. If there had been usable tools out there, I would have loved to simply use them.    --- Quote Start ---  It seems almost like you're trying to create a design with the Chip Planner, and a large one at that.  --- Quote End ---    Now that you mention it, I can see where you might get that impression. I'm not actually trying to create large designs from scratch, but I am interested in full control of every configurable part of the device. I want to be able to exercise ever instance of every cell type, ultimately including all of the detailed routing (though I know that TCL does not allow that).    --- Quote Start ---  If you describe your goals, there might be a better way to do it.  --- Quote End ---    Yeah, I suppose I should explain where I'm coming from. I'm working on a DARPA project that needs to determine that configured FPGAs have not been accidentally or maliciously compromised and can be trusted. To that end, if something could conceivably be used in a compromising fashion, then I want to understand and exercise it.  The architecture definitions, and the kinds of output than I can get from TCL are great, but although they give me a lot of information and reporting capability, they give me much less in the way of control. I'll take just as much rope as I can get, with no fear of accidentally hanging myself.

[Altera_Forum]

--- Quote Start ---  Is there a better forum for this?  --- Quote End ---   Very unlikely   --- Quote Start ---  I'm working on a DARPA project that needs to determine that configured FPGAs have not been accidentally or maliciously compromised and can be trusted. To that end, if something could conceivably be used in a compromising fashion, then I want to understand and exercise it.  --- Quote End ---   That's an understandable motivation. In this case, it may be insufficient to deal with the supported vendor tools. I fear, you have to understand the binary configuration bitsrtreams and the underlying hardware details, both completely undocumented.

[Altera_Forum]

If this has $ or strategic value, I would try to work with Altera directly on your goals. I know that may sound harsh, but you're probably asking for a lot of information, work, etc. and Altera is a business at the end of the day. (I kind of get what you're doing, but the term "maliciously compromised" can mean a lot of different things, and probably does.) If anything, Altera may like helping projects that may one day help Altera(especially when coming from somewhere so well respected...).  

 One thing I was going to say when I thought you were just trying to build a design, was to work with the tools, rather than try to understand everything they do. For example, rather than entering LUTs into the Chip Planner, learn to build them in source and then place them with assignments. The nice thing about this is the tools work much better with you. Even something like the ALM is much more complex than the old days of just a 4-input LUT and a carry-chain. I'm still finding out rules or how things are done that aren't quite what I expected. Now, if you're trying to be exhaustive in coverage and understand every scheme, that's not going to work, but it may help a little. (For example, if you're building test logic, don't build it completely as an ECO, build it as controlled source.) Just a thought. Good luck.

[Altera_Forum]

--- Quote Start ---  If this has $ or strategic value, I would try to work with Altera directly on your goals. I know that may sound harsh, but you're probably asking for a lot of information, work, etc. and Altera is a business at the end of the day.   --- Quote End ---    There is no monetary value at present. As you say there would certainly be a lot of work involved, though the intent was for me to do it, rather than push it off on someone else. That's partly why my preferred approach would have been to make use of existing tools.    --- Quote Start ---  (I kind of get what you're doing, but the term "maliciously compromised" can mean a lot of different things, and probably does.)  --- Quote End ---    It can indeed mean many things. In general we're just interested in added, removed, or modified functionality. But as you're surmising, that can result in something failing to work at a critical time, or generating erroneous results, or leaking keys, or sucking power too quickly.    --- Quote Start ---  One thing I was going to say when I thought you were just trying to build a design, was to work with the tools, rather than try to understand everything they do. For example, rather than entering LUTs into the Chip Planner, learn to build them in source and then place them with assignments.   --- Quote End ---    That is indeed part of what I'm doing. But for everything that cannot be added or described at the WYSIWYG level, I'll have to look elsewhere. I was kind of hoping for one-stop-shopping. ;)    --- Quote Start ---  (For example, if you're building test logic, don't build it completely as an ECO, build it as controlled source.)  --- Quote End ---    I think my misunderstanding comes in part from what I'm accustomed to in the Xilinx world, and in part from my failure to take "ECO" literally. I figured Altera was simply acknowledging that users would generally only use Chip Editor for small-scale changes, but I didn't realize that Chip Editor was effectively limited to those kinds of changes. I now know better.  I appreciate the comments and suggestions.

[Altera_Forum]

The ::quartus::chip_editor package also supports adding I/Os but will not allow you to add any arbitrary BLOCK_INSTANCE into the design. On Stratix® II FPGA devices only LCELL_FF, LCELL_COMBS and I/Os are supported for addition and deletion. ECOs can modify properties on several other blocks but due to the complicated rules governing other block types adding or removing them is not supported. 

  For I/Os specifically you need to use the “add_new_io” command rather than “add_new_cell”. For example:  add_new_io -cell_name new_cell -location IOC_X0_Y2_N0 -direction bidir