Hi,
In the previous inquiry thread about why we encountered timing violation issues (as the error shown below), your team mentioned it was due to "The timing conflicts are related with using a 10ns clock on a 20ns device. But I think this SRAM doesn't require an input clock signal. Why would setting my clk to 10ns affect the SRAM?
Or do you mean it as shown in the figure below (the first line is the control signal, the second line is address, and the third line is SRAM data output)? When I set the control signal to low (open), the initial segment of unknown and incorrect values will display as the timing violation. Therefore, as long as I ensure that I am using the correct values later on (ffb8) in my continuing circuit, my circuit can operate normally (my circuit can indeed pass simulation under this condition currently).Additionally, you mentioned last time that I could slow down the clock speed. So I tried to slow down the clock to 100ns or even slower, but still encountered timing violations. Therefore, I'm not sure what range of slower clock you are referring to. Could this also be related to my time scale setting being "timescale 1ns/1ps"?
--- The following part is what I want to confirm about the other answers you replied to me last time ---
LINKS: Timing violation of 7025L20PFGI SRAM - Memory Products - Memory Products - Renesas Engineering Community
I think "taa" means "Access Time from Address" (as shown in the right picture), so I need to change this value to 20 ns (if I use a 20ns device). Is that correct?
And if I want to change the device speed, I just need to adjust taa to 15/17/20/25/35/55.
Thank you very much for your response!
Best,Jason Shih
Hello Jason,
I have an internal request ( ASI-1131 ) with Engineering to review / comment on this issue.
I will get back to you once I hear back.
From our Engineering team:
To your question.
"In the previous inquiry thread about why we encountered timing violation issues (as the error shown below), your team mentioned it was due to "The timing conflicts are related with using a 10ns clock on a 20ns device.But I think this SRAM doesn't require an input clock signal. Why would setting my clk to 10ns affect the SRAM?"
Since this device is asynchronous you do not need a clock. however, since you showed a clock and your timing was similar to the clock cycle it looked like you were trying to time your controls to a clock edge for system reasons. If this is not the case, then just treat the timing parameters as you would any asynch system and satisfy the input timing per datasheet.
Just curious, why did you show a clock signal if you are not using it for timing?
Additionally, your comment;
Yes.
Yes, this is correct. If you have a 20ns access time part, you need to set the taa to a minimum of 20ns. Of course, you can run as slowly as needed.
Hi Michael Quirk,
Thanks for the response first, but I want to confirm with you one last time if my understanding is correct (the text at the end).
I apologize for not fully demonstrating the reason for using the clock in my previous diagram. I used the positive edge of the clock to pass SRAM output data to subsequent circuits (as shown below). I am not trying to time your controls to a clock edge.
I just inadvertently found that all instances of timing violations occurred when two ports were simultaneously opened and closed (one opening, one closing). But I wonder if the problem arises from the High-Z state during opening, right?However, I believe it is normal for there to be a High-Z initially upon opening followed by some time delay before data output occurs. So this timing violation can be ignored, correct?
Thanks!
1. I just inadvertently found that all instances of timing violations occurred when two ports were simultaneously opened and closed (one opening, one closing). But I wonder if the problem arises from the High-Z state during opening, right?
1. Answer-When you mention "two ports were simultaneously opened and closed (one opening, one closing)"Are you talking about address collision or different addresses read write etc from each port?
2. However, I believe it is normal for there to be a High-Z initially upon opening followed by some time delay before data output occurs. So this timing violation can be ignored, correct?
Answer 2. Please define the relevant control signals involved in "opening" and their relative timing (Address change, R/W#, CE# etc). I'm having trouble interpreting your comments vis-à-vis your test snippets.It is usually a bad idea to ignore timing violations unless you understand the internal timing paths of the device in question. The timing parameters include theoretical relative signal timing, time for signal propagation, process and temperature variation, and a safety buffer.
To assure proper operation under all conditions you must satisfy all relevant timing parameters.
If you do not mean you are violating spec'd timing parameters please explain your question in relation to the timing diagrams or parameters in the datasheet (attached).
REN_7025_DST_20191008.pdf
Thanks for the answers, I found the problem arises when I close a_port and simultaneously change its address same as the address (7be) of b_port that is about to be opened (as shown in Figure 1). Previously, I overlooked the possibility that signal timing offsets could lead to both reading and writing from the same address at the same time.
Figure 1
My solution is to delay changing the address of a_port by one clock cycle to avoid potential conflicts (as shown in Figure 2). Do you have any other recommended solutions for addressing this issue through control signals?
Figure 2
The related control signals are marked in the figure, the ms signal is low (0), and busya/busyb signals are high (1). Additionally, I did not input inta and intb signals (I also want to check if it's possible not to input the int signal?).
Q1. My solution is to delay changing the address of a_port by one clock cycle to avoid potential conflicts (as shown in Figure 2). Do you have any other recommended solutions for addressing this issue through control signals?A1. The delay should work as long as the next address does not cause a collision (same address on both ports). This is one way to avoid problems with address collision.You could also monitor /BUSY just to be sure if there is any question.
Q2. The related control signals are marked in the figure, and the ms, busya and busyb signals are high (1). Additionally, I did not input inta and intb signals (I also want to check if it's possible not to send the int signal?).A2. You do not need to use INT or SEM if you avoid address collision or monitor /BUSY. The INT and SEM do not affect internal function. The signal /BUSY low will block write internally in master mode so it’s best to avoid address collision or to monitor /BUSY.
Really thanks for your help.
Best Regards,Jason Shih