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

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

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 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

--- 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.

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.

--- 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?

--- 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

--- 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?

--- 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

I set one base clock like this:

create_clock -name clk_14Mhz -period 67.817 [get_ports clk]