Preserve_Hierarchical_Boundary Assignment

Could you expand on a few questions:

1) What type of components are being merged? Registers, or combinatorial logic?

2) How do you know they're being merged? (Just because it exists in the RTL view but not in th etechnology view doesn't mean it was merged. It may have been synthesized away or something.

3) Most importantly, why don't you want them to be merged? In general, the only time something gets merged is because it is redundant and there's no reason to have it around.

That being said, I'm currently adding redundant registers to a Hardcopy II design so that it can meet timing, and I then add that register to the Assignment Editor and apply the Remove Duplicate Registers = Off and that works(they get merged if I don't do that.). There is also one for Remove Duplicate Logic. If you really want to prevent this, you can put one or both of the hierarchies into a Design Partition, and they won't get merged.

(I just noticed a Preserve Register assignment, which I've never used before but looks like it would do the same thing, and not require a double-negative to get the assignment to do what you want.)

Rysc, The "Preserve Register" assignment is the GUI version of the preserve or syn_preserve synthesis attribute.

There is another thread on this topic, also from jefflieu http://www.alteraforum.com/forum/showthread.php?t=1673

Ok, This is my circuit:

2 to 1 Multiplexer connected to a ALU unit. I've looked at the signals in the technology map: the mux is merged into the ALU and it disappears. Yes timing is improved by merging that but i don't want that at this stage (for my "scientific" research on estimation of Max Clock Rate).

I'll try the "Design Partition" suggestion and Thank you a lot. I can't get it right from Altera User Guide :(

One last assignment might be Implement as Output of a Logic Cell, which is more fundamentally what you want. (The registers weren't getting merged or anything like that, it's just the combinatorial logic gets merged as it should). Incremental Compilation isn't really designed for this purpose, so it wouldn't be documented that way. In fact, part of the reason the documentation isn't good for this type of thing is that this is something user's very, very seldom want(the end result is a slower, larger design). But if you're doing "scientific" research then there are reasons you would want this that just aren't commonly documented.

One last thing is that if the mux gets merged into a LUT, it might not hurt what you're evaluating. For example, if you want to evaluate the ALU and not the mux, but the first part of the ALU is a LUT, then having more logic in the LUT doesn't make it slower(i.e. a 2 input LUT isn't necessarily faster than a 4-input LUT, it's more dependent on what input to the LUT is used, which you're not controlling).