posedge vs negedge clocking in UDB component designs in verilog

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
BuHa_1507271
Level 3
Level 3
10 replies posted 10 questions asked 10 sign-ins

Is it safe to use negedge clocking in PSOC Verilog.  I was concerned because AN82250 PSoC® 3 PSoC 4 and PSoC 5LP Implementing Programmable Logic Designs with Verilog, on page 13...

Note To reduce the likelihood of timing and synchronization failures, it is preferable to use posedge clocking in PSoC designs.

But no further detail on why the AppNote says this.   On the other The  Warp Verilog Reference Guide doesn't seem to mention anything against negedge, and uses it in several examples.

When designing for DDR style clocking from an external source, using both posedge and negedge clocks seem needed (or to resort to a significant oversampling using an internal clock.)     Is it reasonable to ignore AN882250's advice in this case, doing something like:

always @ (posedge clock) 
begin 
. . .  something
end

always @ (negedge clock) 
begin 
. . .  something else
end

?

PSoC® 3 PSoC 4 and PSoC 5LP Implementing Programmable Logic Designs with Verilog.pdf

0 Likes
1 Solution

Burt,

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

View solution in original post

0 Likes
7 Replies
BuHa_1507271
Level 3
Level 3
10 replies posted 10 questions asked 10 sign-ins

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?

0 Likes
RodolfoGL
Employee
Employee
250 solutions authored 250 sign-ins 5 comments on KBA

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:

wire external_clock;

reg  external_clock_reg;

wire falling_edge;

wire rising_edge;

always @ (posedge clock)

begin

  external_clock_reg <= external_clock;

end

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.

0 Likes

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.

0 Likes

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.

0 Likes

Yes @rlos, I understand that.  But the appnote's guidance still seems in conflict with the examples in The Warp Verilog Reference that use negedge.  What about the PSOC architecture leads to this guidance?

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

start_cond.jpg

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.  

0 Likes

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?

0 Likes

Burt,

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

0 Likes