Clock signal source should not drive registers triggered by different clock edges

[Altera_Forum]

I'm getting the following warning: 

 Warning (308022): (Medium) Rule C106: Clock signal source should not drive registers triggered by different clock edges. Found 1 node(s) related to this rule.  Its caused by a state machine clocked by the pos edge of clk and then another piece of code that needs to use the state and change a signal at the falling edge of the clock.  Should I be very concerned about this warning? From what I read, it means that it may be harder for it to meet timing, but it can work. Is there another way to accomplish changing a signal on the opposite edge of the clock (compared to when the state changes)?

[Altera_Forum]

I'd prefer to pass on good advice, so rather than encouraging you to use both edges of the clock in your design, can you please first explain why you need to use both edges. 

 There is rarely any need to use both clock edges internal to the FPGA for a single-clock synchronous design.  If your design is interfacing to an external device using dual-data rate (DDR), then you would generally code the internal logic relative to a single clock and use the I/O element DDR logic explicitly, i.e., have two internal single-rate data paths that you then route through a DDR component.  Cheers, Dave

[Altera_Forum]

I'm actually trying to use the ALTASMI_PARALLEL megafunction to write to my EPCS4 serial mem chip. The signals that the function wants (bulk_erase, write, wren, read, rden) all need to be asserted for just one rising edge of the clock that I'm sending to the function. In the documents they show some waveforms that are changing on the falling edge of the clock. 

 Of course, I could divide the clock and get more clever about when to change it. Is that perhaps a more correct solution?

[Altera_Forum]

--- Quote Start ---  I'm actually trying to use the ALTASMI_PARALLEL megafunction to write to my EPCS4 serial mem chip. The signals that the function wants (bulk_erase, write, wren, read, rden) all need to be asserted for just one rising edge of the clock that I'm sending to the function. In the documents they show some waveforms that are changing on the falling edge of the clock.  Of course, I could divide the clock and get more clever about when to change it. Is that perhaps a more correct solution?  --- Quote End ---  I haven't used this IP block, so I can't say for sure, however, using an FPGA clock that is at-least 2x the serial clock is generally a good solution. If you look at the waveforms for the EPCS devices, they are pretty much the same as SPI Flash devices. If you were going to create an SPI controller, you'd code it so that it was internally clocked by the FPGA clock (of say 100MHz), and then use baud-rate logic (control registers plus clock dividers) to program the clock used for the SPI interface.  Read a data sheet for an SPI device, and you'll likely see comments about data being clocked out relative to the falling edge of the spi clock. This is not the same as using the falling-edge of the fpga clk. If the FPGA clock is 2x the SPI clock, then the data is clocked out every second FPGA clock, while the SPI clock is toggled every FPGA clock. There is only ever one FPGA logic clock and the rising-edge of that clock is always used.  I would have thought the ALTASMI_PARALLEL megafunction would have taken care of that for you. However, as I commented, I have not used this IP block. If the IP does not have an Avalon-MM slave interface to it, then its probably old. Someone reading this thread might be able to recommend another IP core for interfacing to the EPCS as an external Flash device.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  The signals that the function wants (bulk_erase, write, wren, read, rden) all need to be asserted for just one rising edge of the clock that I'm sending to the function. In the documents they show some waveforms that are changing on the falling edge of the clock.  --- Quote End ---   In a synchronous design, the signals are usually originated from registers operated by the same clock. Then the signals will be set shortly behind the rising edge and processed at the next clock edge. There's no use of falling edge clocked registers to generate this signals.   If you generate this signals in a test bench, you'll assert and deassert them with sufficient distance from the clock edge to avoid timing violations or just for clarity. I guess, the IP manual does the same. The timing shouldn't be misunderstood as design template.

[Altera_Forum]

There's nothing technically wrong with using the falling edge, assuming the duty cycle you have in the constraint is correct. (Every double-data rate interface uses the falling edge). It's much better than dividing down the clock(if you were doing that in logic). Creating a 2x clock is a good solution, but a lot of overhead for such a small chunk.  

As other's have stated, falling edge logic is usually not necessary, but it also shouldn't hurt anything either.

[Altera_Forum]

--- Quote Start ---  In a synchronous design, the signals are usually originated from registers operated by the same clock. Then the signals will be set shortly behind the rising edge and processed at the next clock edge. There's no use of falling edge clocked registers to generate this signals.   If you generate this signals in a test bench, you'll assert and deassert them with sufficient distance from the clock edge to avoid timing violations or just for clarity. I guess, the IP manual does the same. The timing shouldn't be misunderstood as design template.  --- Quote End ---    I have done a SPI interface in a design I did 2 weeks ago and I do understand how all that works. Unfortunately, in the Cyclone III user logic does not have access to the pins that interface to the serial mem. They are all controlled by dedicated hardware in the chip. Only the ALTASMI_PARALLEL megafunction can get access to them and give you an interface to talk to the mem. That function does take care of all the details of the command set as well as the signal timing to the serial mem. But the user interface to it shows that writing or reading data to the function is done on the rising edge of the clock that you are driving it with (a user clock less than 25 MHz). You cannot simulate it but they show examples of write and read cycles in which the write or read pulse starts on the falling edge of a clock, and is sampled on the rising edge. So that's what I was going on.  If I understand you correctly, it should not matter if I assert the signal at the rising edge. It will actually arrive in the logic after that edge and then it gets sampled on the next rising edge, and it goes away right after that edge. Do I understand that correctly?

[Altera_Forum]

--- Quote Start ---   If I understand you correctly, it should not matter if I assert the signal at the rising edge. It will actually arrive in the logic after that edge and then it gets sampled on the next rising edge, and it goes away right after that edge. Do I understand that correctly?  --- Quote End ---    Yes.  This is a case where you need to use synthesis and timequest timing analysis. If the user logic and the ALTASMI_PARALLEL megafunction are being clocked by a single clock, then the timequest clock constraint for that clock will check that the data driven from your user logic arrives in time to meet the setup time of the ALTASMI_PARALLEL input registers, and similarly for the ALTASMI_PARALLEL outputs to your logic.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Yes.  This is a case where you need to use synthesis and timequest timing analysis. If the user logic and the ALTASMI_PARALLEL megafunction are being clocked by a single clock, then the timequest clock constraint for that clock will check that the data driven from your user logic arrives in time to meet the setup time of the ALTASMI_PARALLEL input registers, and similarly for the ALTASMI_PARALLEL outputs to your logic.  Cheers, Dave  --- Quote End ---    OK, that makes sense. Do I understand correctly that for all the internal logic of the FPGA, it understands the setup and hold times of the various registers and I don't have to enter some numbers somewhere?

[Altera_Forum]

--- Quote Start ---  Do I understand correctly that for all the internal logic of the FPGA, it understands the setup and hold times of the various registers and I don't have to enter some numbers somewhere?  --- Quote End ---  You have to enter one number; the TimeQuest clock constraint.  The time between clock edges is the clock period. The clock-to-output delay from the source register plus the setup requirement of the destination register must be less than the clock period. Look in the TimeQuest documentation, and in Rysc's TimeQuest guide on the Altera Wiki.  http://www.alterawiki.com/wiki/timequest_user_guide  Cheers, Dave

[Altera_Forum]

I set one base clock like this: 

 create_clock -name clk_14Mhz -period 67.817 [get_ports clk]

[Altera_Forum]

--- Quote Start ---  I set one base clock like this:  create_clock -name clk_14Mhz -period 67.817 [get_ports clk]  --- Quote End ---     That should work nicely.  Note that you don't really have to be that accurate with the clock, i.e., 67ns or 68ns would also be fine.   The key is that you're providing TimeQuest with a target to meet.  Cheers, Dave

[Altera_Forum]

This may be off topic, but it is related to the clock stuff. I'm getting this: 

 Warning (308040): (Medium) Rule C104: Clock signal source should drive only clock input ports. Found 3 nodes related to this rule.   Warning (308010): Node "port0_wr"  Warning (308010): Node "port0_rd"  Warning (308010): Node "port2_wr"  Is this saying that my clk signal should not be driving these nodes? Or is it saying that these nodes are considered clocks and that they are driving some non-clock input downstream?

[Altera_Forum]

--- Quote Start ---   Is this saying that my clk signal should not be driving these nodes? Or is it saying that these nodes are considered clocks and that they are driving some non-clock input downstream?  --- Quote End ---    Its your code, don't you know? :)  I think its probably found that those signals are being used both as a clock to a register and as an input to a register. Search through your code and see if you are trying to use these as clocks.  Cheers, Dave

[Altera_Forum]

Yes, it turns out that I am using them for both in my uarts. I will have to figure out how to do it differently.

[Altera_Forum]

--- Quote Start ---  You have to enter one number; the TimeQuest clock constraint.  The time between clock edges is the clock period. The clock-to-output delay from the source register plus the setup requirement of the destination register must be less than the clock period. Look in the TimeQuest documentation, and in Rysc's TimeQuest guide on the Altera Wiki.  http://www.alterawiki.com/wiki/timequest_user_guide  Cheers, Dave  --- Quote End ---    I seem to be running into issues with the setup time (or it could be hold time). TimeQuest says it meets all timing, but things are not working right (in the hardware) and seem to be related to timing issues. If I am setting an enable signal high for just one clock cycle (pos edge) and then later testing that enable in a state machine that uses the same base clock, is it possible that its not seeing the enable signal because its not meeting setup and hold timing? Do I need to do something like extend the enable for 2 clock cycles?

[Altera_Forum]

--- Quote Start ---  Unfortunately, in the Cyclone III user logic does not have access to the pins that interface to the serial mem. They are all controlled by dedicated hardware in the chip.  --- Quote End ---   I don't think so. Dedicated hardware is working at configuration time. All IP accessing the configuration memory in user mode is pure software as far as I'm aware of.

[Altera_Forum]

--- Quote Start ---  I seem to be running into issues with the setup time (or it could be hold time). TimeQuest says it meets all timing, but things are not working right (in the hardware) and seem to be related to timing issues. If I am setting an enable signal high for just one clock cycle (pos edge) and then later testing that enable in a state machine that uses the same base clock, is it possible that its not seeing the enable signal because its not meeting setup and hold timing? Do I need to do something like extend the enable for 2 clock cycles?  --- Quote End ---    Why do you say it looks timing related?  If TQ says timing is being met and you have problems, then there are possibilities a) it's not timing related  b) you've constrained your design incorrectly.  I suggest you attach your .sdc file  c) Bug in TQ. Very very very unlikely, but not 100% impossible.  You can always run a gate level simulation and see what's happening.

[Altera_Forum]

--- Quote Start ---  Why do you say it looks timing related?  If TQ says timing is being met and you have problems, then there are possibilities a) it's not timing related  b) you've constrained your design incorrectly.  I suggest you attach your .sdc file  c) Bug in TQ. Very very very unlikely, but not 100% impossible.  You can always run a gate level simulation and see what's happening.  --- Quote End ---    Well, I do agree. I have been simulating and things look correct there. I'm really new to timing constraints so I may not know what I'm doing there yet. I have attached the sdc file.

[Altera_Forum]

That .sdc looks unusual (lots of generated clocks) but correct. 

Are there no warnings about unconstrained paths?  One other possibility is that your simulation isn't mimicking the system external to the FPGA properly. Ie, in real life the signals are shorter or longer, etc and your logic isn't handling that properly.  You can always add SignalTap probes to your design and see what's going on inside the FPGA.

[Altera_Forum]

--- Quote Start ---  I seem to be running into issues with the setup time (or it could be hold time). TimeQuest says it meets all timing, but things are not working right (in the hardware) and seem to be related to timing issues. If I am setting an enable signal high for just one clock cycle (pos edge) and then later testing that enable in a state machine that uses the same base clock, is it possible that its not seeing the enable signal because its not meeting setup and hold timing? Do I need to do something like extend the enable for 2 clock cycles?  --- Quote End ---    This type of problem sounds symptomatic of not using a synchronizer on a signal. You indicate that your UART is having trouble. Look at the UART rx signal path it should be; top-level input pin, synchronizer (to UART controller clock), to UART control logic.  If you have cut the timing path on rx because its an asynchronous signal, then you are telling TimeQuest 'Its ok, I know what I am doing', and so it will no longer check that path. However, the expectation is that you have a synchronizer on that input.  Cheers, Dave