Also, in Just Enough Verilog for PSOC, at page 6 it says:
There also exists a negedge keyword. However, because of the architecture of the PSoC, only posedge should be used. Timing and synchronization failures are likely if negedge is used. If it is essential that something occur on the positive and negative edge of a clock, use the rising edge of a clock twice the frequency to trigger the circuitry.
This seems in direct conflict with the examples in The Warp Verilog Reference that use negedge. What about the PSOC architecture leads to this guidance?
If you need to work on both edges, it is recommended to run the clock to the UDB logic much higher than the external clock to the PSoC.
For instance, if the external clock is 4 MHz, you can drive the UDB logic at 32 MHz, then implement something like this:
always @ (posedge clock)
external_clock_reg <= external_clock;
assign falling_edge = !external_clock & external_clock_reg;
assign rising_edge = external_clock & !external_clock_reg;
What the App Note states it is not recommended to clock the UDB logic with an external clock. All the logic should be synchronized to the internal clock that drives the UDB logic.
Thanks @rlos, but that's not the answer I'm looking for. That would force me into running a clock PSOC clock at a much higher rate than I want to just to deal with a relatively rare case.
In my case, I've got multiple clock domains, interfacing to asynchronous systems. I'm expecting the external clock to be in the range of 12-13 MHz. Scaling that to run 8x oversampling of your example on a PSOC 5 exceeds the maximum available clock frequency.
I understand the challenges of multiple clock domains, and want to use the UDB FIFOs to synchronize them, rather than resorting to oversampling on an internal clock. It seems like the FIFOs have been designed with that in mind, e.g. they gray code addresses which are safer across clock boundaries than normal binary.
You might be able to make it work with a 4x the external clock. It depends how much delay you can add in your logic.
Yes @rlos, I understand that. But the appnote's guidance still seems in conflict with the examples in that use
I've got two use-cases where negedge seems helpful:
One is like I2C's START symbol: while the bus is idle both SDA and SDC will be pulled high externally and I'm looking to conserve energy in potentially lengthy idle periods before START. When the master is ready to START, he pulls SDA low (while SDC remains high, which makes it a START).
For power conservation, I really don't want to depend on any high-speed PSOC bus clock while waiting for START (which started me on the negedge topic) because it might be a long time in coming. If this were I2C FM+, I'd have something like 260 ns of hold time after START till SCL changes, but assuming the faster data rates expected, that hold time drops 38.4 ns . That might be a problem if I don't have SCL sampled synchronously with the external START event, but I haven't done a detailed analysis of it.
The other use case I where timing might get challenging is writing to the bus in DDR, I've only got a few 10s of nanoseconds after the clock changes to update the output (at max bus loading). I think that's the tightest external timing requirement, and conservatively I may not be able to hit it, even using the external clock directly: The PSOC 5LP: CY8C58LP Family datasheet has relevant content in section 11.6.8 saying that 20-25 ns propagation delay from clock to data is possible with optimal placement, routing and pin selection, but frankly DDR support isn't a must-have, I'm more concerned with the power used waiting for START.
I've found more detailed explanation in PSoC® Creator™ PSoC 3/PSoC 5LP System Reference Guide section on Clocking; this seems authoritative and answers some of my questions.. Based on that, it seems I may be able to, with "special care" use the Sync component of a UDB to permit me to run some of the logic from the external clock signal, then to the FIFO.
It sounds like the SPI slave component may be what I need to pattern my solution on, which makes a fair amount of sense to me. My clock rates are similar to those typically quoted for SPI, but faster than the 5 MHz quoted in the SPI Slave features list!? Is the Verilog source for the SPI slave available somewhere, or some other example that uses Sync components?
If you are worry about power consumption with I2C, you are better off using the I2C fixed function implementation. PSoC supports waking up from deep-sleep when there is activity on the I2C bus. But that only works if you use the I2C fixed function.
For the Verilog Source, you have access to the implementation of all components available in the Cypress catalog. You can either import the component, refer to PSoC Creator Tutorial - Importing and Copying Components - YouTube , or accessing the code in the PSoC Creator installation folder at C:\Program Files (x86)\Cypress\PSoC Creator\4.2\PSoC Creator\psoc\content\CyComponentLibrary\CyComponentLibrary.cylib