Static Timing Analysis - Setup Time violation and BUFOE modules

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

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hello!

I need some help or reassurance in the following:

I have implemented a design whose purpose would be to act as a 'man-in-the-middle' in a non-standard paralel bus communication.
I've created a component with Verilog implementation in which the byte-wide databus is bidirectional, therefore I also instantiated 8 BUFOE modules which are connected to the PSOC 5LP bidirectional digital pins. The Data bus is driven by the MASTER on the DATA pins, except when a read cycle is initiated in which case the SLAVE gains control over the DATA bus. The slave drives the DATAO pins.

pastedImage_1.png

After building the design with a newly created component, the following warning appeared:
"Warning-1366: Setup time violation found in a path from clock ( Clock_ibus ) to clock ( Clock_ibus )."
(note: my Master Clock is 48MHz)

After opening the STA report, the following was highlighted as the timing violation:

pastedImage_5.png

pastedImage_6.png

pastedImage_7.png

Upon closer inspection I found that the accumulated delay is made up of these steps:

pastedImage_8.png

I have attached the Verilog implementation of my component below, but here's a block diagram of the relevant hardware elements:

pastedImage_11.png

My assesment of the situation is that the Static Timing Analyser, built in the PSOC Creator, is ignorant about the OE and its inverted pair -OE signals and their effect on the BUFOE components.

In the analysis I can see how the signal originates from my MUX-ed registers, go through the BUFOE, take a U-turn in the iocell (the physical pin, so to speak), go around the BUFOE's fb (feedback) signal, straight into the other BUFOE, another U-turn at the other bi-directional pin, and straight back to my bufreg's input via the din (fb) wire. This whole route is supposed to be completed within a clock cycle + setup/hold times, no wonder the signal propagation delay is a blasted 79+ nanoseconds. In reality, when the OE signal is LOW (-OE is HIGH), the data on dout never reaches the DATA pin. When the OE signal is HIGH and -OE is LOW the data never reaches the DATAO pin.

Knowing how the BUS protocol and my hardware control these signals, I plan to ignore this warning, but use the STA report to calculate reasonable clock frequency (24MHz).

My question would be: Am I right? Can I ignore the STA warnings? If yes, is there any way to make the STA to calculate with the right parameters/constraints(or whatever)? I skimmed through the PSOC Creator User Guide's but found nothing helpful (Directives included...)

Thanks,

David

0 Likes
6 Replies
odissey1
Level 9
Level 9
First comment on KBA 1000 replies posted 750 replies posted

David,

There are several steps to remedy timing violation problem. Read this CY App Note describing various issues arising from clock skew, particular the section "Using the PSoC Creator STA Report":

PSoC® 3, PSoC 4, and PSoC 5LP Digital Design Best Practices

The component is rather large with many io buses, which resulted in poor timing. To improve timing try following:

1. In Verilog code change reset from synchronous to asynchronous. (First disable reset to see if this helps).

2. See if it is possible to add Sync clock component e.g on io buses.

3. In Design Wide Resources -> System -> Operatin temperature range change from (-20C to 85C) to (0C to 85C). This will easy constrains on the design.

4. Check io pins setting from sinc/double-sinc to transparent.

5. Component has a lot of Control registers. Use them in sync mode, sync-ed to a lower freq clock .

Finally, if you want somebody to review and test your code, attach a demo project (1): File->Create Archive Bundle->Minimal; (2) Delete folder 'Generated source' in the created archive to reduce archive size.

odissey1

0 Likes
Anonymous
Not applicable

Hello odssey1,

Thanks for your answer.

I'm already past the thorough studying of said Application Notes (I've probably read all of the related material, Component Author Guide included), and I believe my problem is not really related to any of the offered solution in the appnote. Could you elaborate what made you think so?

In connection to your suggestions:

1. I modified and tested my code to have asynchronous reset, for it seems like reasonable thing to do (thank you for the insight), however I did not expect this to solve my problem (and it did not), because as stated above, my question really was more about the STA behaviour and how it includes all the signal paths disregarding whether they may or may not be available in reality. I used the reset signal to initialise two registers.

2. If I'm not mistaken, the Sync component synchonises two possibly out-of-synchron clocks to the Master Clock. My component uses only one clock, which is actually the Master clock / 2, and there is no other component to sync with, so I guess this is out of the question. Also, as far as I know, the I/Os are just simply asynchonous if set to transparent mode (which they are), and no sync component could do any improvement on their timing (I ahve no idea how the STA calculates with this, I only guess it adds a worst-case signal propagation time and that's it?). Not to mention, the BUS_CLK which is fed to the I/O cell is always derived from the Master Clock, so even, with sync mode, they should still be in sync with my component. I'm open to any correction.

3. I have already done that. You can see it for yourself on the top of my STA report.

4. It is set to transparent as stated above

5. Please explain this to me, how exactly will this help with timing? I use them in sync mode, but I also MUX them into one register (based on an address decoding), and that particular register will be part of the signal path in question. I presume, the signal paths and SETUP and HOLD times are taken into consideration from register to register...?

Once again, I thank you for your time and effort, you've given me some seeds for thought, however the core of my question seem to be still untouched. (Namely, about how the STA report deals with connected BUFOE modules and whether there are some directives to solve the warning and most importantly are there any flaws in my originaly statements)

All the Best,

David

0 Likes

David,

    Did you try by increasing the Clock Period ? ( Reducing the component frequency)

Since , from the STA report the critical path delay is ~79.17 ns which needs a Clock Period >79.17ns ( Maximum Clock Frequency=~12 MHz). Just once try by running the component at a frequency lesser then 12 MHz and see if the setup violation still persists.

To run the component at higher frequency we will need to reduce the path delay to avoid the setup violation. Could you please attach your PSoC Creator Component so that we all can see if any redundant nodes can be removed from the design?

-Gyan

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Dear Gyan,

Increasing the Master/Bus Clock does not help much, tried already.
If I change the component clock to ~12MHz, the warning disappears, obviously, the setup time violation will be solved.

I need at least 24MHz in my design.

But let me highlight this:

This is not a standard STA issue I'm having. If read carefully, the main problem is in fact, that a register's output violates the SAME register's Setup time due to the bi-directional nature of the BUFOE instantiations via the path connecting all of them. The question at hand is if there is any way to negate the warning or is there something I missed in my train-of-thoughts in the original post.

Thanks,

David

0 Likes

Hi David,

Due to the bidirectional nature of this component both the forward and backward data path will affect the STA and the warning (a register's output violates the SAME register's Setup time) is expected.

What is the pin configuration you have used at terminal 'DataI' ? I could not place a pin with bidirectional/Input configuration.

Could you try by changing the operating conditions ( Voltage ) in .CYDWR -> System tab? ( Decrease the voltage -> Will increase the component path delay)

-Gyan

0 Likes
Anonymous
Not applicable

Just to put an end to this thread:

Yes, the static timing analysis was wrong, as in it did not take into consideration how the hardware actually worked.
I could not find any directives to shush the STA about this, maybe there is one, maybe there isn't. Who knows.

The design works perfectly and timing is not an issue.

0 Likes