I'm trying to get a simple piece of logic working:

on the positive edge of the clock the output should always be 1, on the negative edge, the output should be the value of a provided input.

I've tried half a dozen ways of doing this, all of which result in an error either at the synthesis or mapping stage (errors regarding outputs with multiple drivers, or clocks being used on non clock pins).

I figure this must be a very easy task to accomplish if you know the trick.

I'm using ISE 13 and developing for a Xilinx Spartan 6. update:

Place:1136 - This design contains a global buffer instance, <XLXI_3>, driving the net, <XLXN_45>, that is driving the following (first 30) non-clock load pins.
< PIN: XLXI_19/XLXI_3/XLXI_205/start_memory1.A5; >
This is not a recommended design practice in Spartan-6 due to limitations in the global routing that may cause excessive delay, skew or unroutable situations.      It is recommended to only use a BUFG resource to drive clock loads. If you wish to override this recommendation, you may use the CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote this message to a WARNING and allow your design to continue.

1 Answer 1


While not strictly recommended, the simplest way of achieving this is the following:

wire out;
reg outReg;
always @ (negedge clock) begin
    outReg <= in;
assign out = outReg | clock;

This would ensure that when the clock goes high, the output will be a 1. Once the clock goes low, the data gets clocked into the register and appears on out (which is no longer being or'ed high). The trouble with this sort of method is that it results in the clock signal having to come off the global clock network to pass through the OR gate which can lead to timing issues due to excessive skew - if we are talking about slow clocks like 10-50MHz that will probably not be an issue though.


I remember now having come across the error this causes in the past. There is a work around to get this to compile (drop the error down to a warning), which is described in Xilinx AR#33025. Basically you need to add the constraint from the error message PIN "XLXI_3.O" CLOCK_DEDICATED_ROUTE = FALSE; to your UCF file and then also assign the global clock to one of the upper group of BUFG (clock buffers) to allow the signal to be able to get onto non-global-clock routing as well. The second part is done with another constraint in the UCF file: INST "name_of_bufg_instance" LOC = BUFGMUX_X*Y* where BUFGMUX_XY is one of the upper group BUFGs - details on how to find valid names can be found at the link above.

Another alternative would be to use a DCM block to generate a 2x clock signal. This clock would then be used to drive the register - in one cycle of the fast clock you would drive to 1, in the other you would drive to your input signal. Granted you would have to synchronise the two clocks to ensure that the 1 appears at the rising edge of the 1x clock, but that can be done.

My suggestion however would be to consider why your logic requires you to do this and see if there is alternate way to design the later logic. Talking from experience with making some pretty complex systems with FPGAs, I find that if you get to a situation where obscure signals have to be created with half clock periods things tend to get messy quickly and the design falls apart.

  • \$\begingroup\$ This causes an error where the clock is driving a non clock pin (clock is inputted into an or block), I tried the ODDR2 component, but as the output was not going off chip it failed. I'll try the DCM now, I was hoping to avoid it as it seems such a trivial use for a DCM, I may end up re-writing the downstream modules to avoid this issue altogether. \$\endgroup\$ Jun 9, 2015 at 2:47
  • \$\begingroup\$ @ZackNewsham its interesting that it causes an error. I have done this in the past. I wonder if there is a setting is ISE that needs to be correctly configured. I'll have a look. \$\endgroup\$ Jun 9, 2015 at 2:53
  • \$\begingroup\$ @ZackNewsham could you update the question with the exact error message that you get? \$\endgroup\$ Jun 9, 2015 at 3:03
  • \$\begingroup\$ question updated \$\endgroup\$ Jun 9, 2015 at 3:08
  • \$\begingroup\$ @ZackNewsham I've updated the answer with a link to the work around for the error. But I agree with you that it is worth looking at why you have a need to generate this signal and to see if there is an alternative way to write the modules that the signal feeds. \$\endgroup\$ Jun 9, 2015 at 3:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.