When there is an error within a component you should create a MyCase or post it as a new thread under PSoC Software together with a bit of example etc.
Modifying a component will always result in creating your own one. Using a different name is IMHO a must-do: Take the case that something goes wrong and ´nobody is able to see that you used a different (modified) component.
Oh I don't know if I'd consider this a mistake in a component, I was just asking if there was a "proper" way to take an existing component and modify it for my own library use. Totally agreed on your other points and reasons.
Well first, since it appears you're mixing the two, let's talk about what a macro is and what a component is.
A component is an implementation of a function that you place in a schematic. This can be a software function or a hardware function and it can be implemented in many different ways. This is always a single item with no wires or such. The symbol for a component can change based on the configuration.
A macro is a collection of one or more components including the component configuration. It cannot be configured nor does the macro generate APIs. In fact the macro only exists in the catalog and is never placed on a schematic. Once dropped the macro changes to the set of components pictured. Macros cannot have a symbol. In other words, a macro is effectively what you'd get if you copied those items from one instance of PSoC Creator to another.
Components have a blue diamond icon in the component catalog, where as macros have a a flow chart with a green arrow.
To make a macro, you simply need to highlight a portion of your schematic, right click and select "Generate Macro". It will show up under the default tab in the component catalog and you can place it right away. If you want to change the macro's name and placement, click on the Components tab in the solution explorer. You can read more in the component author guide about placement and such.
On the other hand a component can be implemented in a number of ways. The first way most people learn is to write Verilog. This obviously isn't what you want. The second way you can implement a component is through a schematic. It turns out most components you use in the catalog are implemented this way.
That's right we have hierarchy. Simple building blocks can be used to make very powerful components. This too is outlined in the component author guide (which I know is a long and somewhat dry read). There are some very cool and important things in the component author guide, and it is a great place to start. Also, we have a way to import a component which we let you do for almost every component in the catalog. In some cases you may not get everything, mainly due to protecting our IP. One more thing to note, with 3.0 we also have implement using the UDB editor. This is a simple way to make state machines that synthesize down to PLD blocks on the chip for example. It also gives you access to the datapath (which is like an extra 8 bit processor for hardware).
I think you are looking for a way to modify the SAR component. Here is a video explaining how to import a component into your project. You can then modify the implementation as needed.
!!! DANGER !!!
I have no idea whether the SAR can be safely clocked with anything other than SYSCLK. You might resolve your static timing issue but create a new problem. if you are still having an STA problem I suspect it is NOT actually the SAR at all. I recommend working with our tech support people to resolve this issue. Our components are carefully designed and implemented - this clock is probably "buried", with no option to change the frequency, for good reason.
Wow, two excellent and informative answers! Thank you very much for taking the time to respond, it's truly appreciated.
Scott, your description of what a component is and what a macro is helps considerably. It seems, like you said, that most of the components in the library are actually macros. In my particular case, though, the Sequencing SAR component is an actual component (blue diamond icon). I can, however, "break in" to it and see that it's made up of the ADC_SAR block (yellow header) and a yellow block which is the Verilog component. There are also other bits (virtual MUXes and an interrupt line) in there, but the component is actually made up of several smaller blocks. My question was what is the "official" or "sanctioned" or "recommended" way to take a component such as the Sequencing SAR component and modify it. In my case it means adding two synchronizers between the eos and eoc outputs of the SAR_ADC block and their respective inputs in the Verilog block.
I intend on reading the component author documentation now, as I suspect that it will answer some of the more "newbie" questions I have. Thanks for the pointer.
Unfortunately that link was not very helpful; the Sequencing SAR component is in the existing library, not another project or an archive. The only way I can see to "get in" to a component in the library is to open up the schematic by navigating through the directory tree on the filesystem, select everything on the page and copying those "internal" compnents into my design where I can then break the connections and wire them as needed.
I see your warning about the potenital issues with driving the SAR with an alternate clock and appreciate it; it's a valid concern and I will follow up with my own testing and with Cypress. As mentioned above and also over at www.cypress.com/, I was able to meet timing by inserting a synchronizer between the ADC component digital outputs and the Verilog component digital inputs. This allowed me to get to 64MHz on a simpler design and 48MHz with a more complex one. I need to test the system yet in the 48MHz version to make sure operation is correct but after reviewing the Verilog code I don't see why it would not work.