Hi,
sorry, I think I sent it to the wrong address.
Alex Schreiber wrote:
> Hi,
>
> I'm writing a VITAL model for a synchronous RAM at the moment. Some of
> the input signals can
> have a negative timing in respect to the active edge of the clock. I
> followed the algorithm described
> in chapter 8.2 of the IEEE 1076.4 (Oct. 95) Spec.
>
> There are several questions comming up of which I'm not sure if the
> reason is either a limitation
> of the VHDL simulator (ModelSim), or a limitation in VITAL, or simply
> a misunderstanding of
> mine.
>
> The sync. RAM has the following interface:
>
> - CEB : clock signal (active on falling edge)
> - CSB : chip select (low active)
> - WEB : write enable (low active) << negative setup
> time <<
> - OEB : output enable (low active, asynchronous)
> - BA : bank address (several RAM blocks can be used to build
> a deeper or wider memory)
> - I : data
> input << negative setup time
> <<
> - O : data output (three-state, controlled by OEB and
> BA)
>
> Following the questions in detail:
>
> 1. Internal Signal Delay (tisd) for largest negative timing (absolute
> value):
> ====================================================
>
> When I follow the algorithm in chapter 8.2 and declare
> internal signal delay generics
> for all the signals which are dependent on the clock, the
> values of the VITAL generics
> are updated during the 'negative constraint calculation
> phase' like follows:
>
> # 0 ns ticd_CEB : 0.4 ns
> # 0 ns tisd_WEB_CEB : 0.1 ns
> # 0 ns tisd_CSB_CEB : 0.2 ns
> # 0 ns tisd_BA_CEB : 0.4 ns
> # 0 ns tisd_A_CEB : 0.4 ns
> # 0 ns tisd_I_CEB : 0.4 ns << ???
>
> # 0 ns tsetup_WEB_CEB_noedge_negedge : 0.2 ns
> (default: -0.1 ns) << neg. setup
> # 0 ns thold_WEB_CEB_noedge_negedge : 0 ns
> (default: 0.3 ns)
> # 0 ns tsetup_A_CEB_noedge_negedge(0) : 0 ns
> (default: 0.0 ns)
> # 0 ns thold_A_CEB_noedge_negedge(0) : 0.6 ns
> (default: 0.6 ns)
> # 0 ns tsetup_I_CEB_noedge_negedge(0) : 0 ns
> (default: -0.4 ns) << neg. setup
> # 0 ns thold_I_CEB_noedge_negedge(0) : 2.5 ns
> (default: 2.5 ns)
> # 0 ns tsetup_CSB_CEB_noedge_negedge : 0.6 ns
> (default: 0.4 ns)
> # 0 ns thold_CSB_CEB_noedge_negedge : 0 ns
> (default: 0.2 ns)
> # 0 ns tsetup_BA_CEB_noedge_negedge(0) : 0.6 ns
> (default: 0.6 ns)
> # 0 ns thold_BA_CEB_noedge_negedge(0) : 0 ns
> (default: 0.0 ns)
>
> Question: Why is the input with the maximum negative setup
> time (absolute value)
> delayed as well, i.e. why is tisd_I_CEB
> /= 0 ns? When I use a delayed
> version of this signal (here: I), I do
> not win anything, because I will get a
> false hold error due to the signal event
> of setup.
>
> Workaround: When I do not declare tisd for this signal
> (here: I), the signal will not
> be delayed, but the setup and
> hold timings are updated in respect to
> the delayed clock.
>
> Drawbacks: - assumption about the
> signal with the largest negative
>
> setup time (absolute value) necessary
> - not
> 100% conform to the spec.
>
> # 0 ns ticd_CEB : 0.4 ns
> # 0 ns tisd_WEB_CEB : 0.1 ns
> # 0 ns tisd_CSB_CEB : 0.2 ns
> # 0 ns tisd_BA_CEB : 0.4 ns
> # 0 ns tisd_A_CEB : 0.4 ns
>
> # 0 ns tsetup_WEB_CEB_noedge_negedge : 0.2 ns
> (default: -0.1 ns) << neg. setup
> # 0 ns thold_WEB_CEB_noedge_negedge : 0 ns
> (default: 0.3 ns)
> # 0 ns tsetup_A_CEB_noedge_negedge(0) : 0 ns
> (default: 0.0 ns)
> # 0 ns thold_A_CEB_noedge_negedge(0) : 0.6 ns
> (default: 0.6 ns)
> # 0 ns tsetup_I_CEB_noedge_negedge(0) : 0 ns
> (default: -0.4 ns) << neg. setup
> # 0 ns thold_I_CEB_noedge_negedge(0) : 2.1 ns
> (default: 2.5 ns) << updated
> # 0 ns tsetup_CSB_CEB_noedge_negedge : 0.6 ns
> (default: 0.4 ns)
> # 0 ns thold_CSB_CEB_noedge_negedge : 0 ns
> (default: 0.2 ns)
> # 0 ns tsetup_BA_CEB_noedge_negedge(0) : 0.6 ns
> (default: 0.6 ns)
> # 0 ns thold_BA_CEB_noedge_negedge(0) : 0 ns
> (default: 0.0 ns)
>
> 2. Internal Signal Delay value:
> =====================
>
> In the example given in point 1 the second signal, which has
> a smaller negative setup
> time (here: WEB), is delayed in a way, that the hold time
> becomes 0 ns. But this is not
> always the case. With different timing values, it can
> happen, that the second signal
> is not delayed at all, which results in positive, non-zero
> values for both, setup and hold
> timings (updated in respect to the delayed clock).
>
> # 0 ns ticd_CEB : 0.76 ns
> # 0 ns tisd_WEB_CEB : 0 ns
>
> # 0 ns tsetup_WEB_CEB_noedge_negedge : 0.62 ns
> (default: -0.14 ns)
> # 0 ns thold_WEB_CEB_noedge_negedge : 1.58 ns
> (default: 2.34 ns)
>
> Problem: Each new value which is scheduled in the future
> (e.g. by VitalSignalDelay)
> takes place at +0 delta at that point of
> time. It doesn't matter when and at
> which delta it was scheduled. In the
> second case there is no problem, but
> as soon as the hold time becomes 0 ns
> (after update) like in the first one,
> the signal needs to be delayed by one
> delta ('delayed) to insure, that the
> previous value is taken at the active
> clock edge. Otherwise false errors
> are detected or the model is not working.
>
> 3. Update of Path Delays (tpd):
> ======================
>
> According to chapter 8.2.2.4 of IEEE 1076.4 the propagation
> delay values are adjusted
> as well based on the value of the internal signal delay
> generic. If the original path delay
> value is smaller than the value of the internal signal
> delay, the adjusted path delay value
> will be set to 0 ns. This causes a problem for BA.
>
> In our sync. RAM, BA has two functionalities. The first
> function is like CSB, where it
> needs to meet setup and hold timings in respect to the
> active clock edge. To model this functionality setup and
> hold generics are defined.
>
> The second function is like OEB, where it controls the
> three-state output driver asynchronously. To model this
> effect, the path delay generic is used.
>
> Due to the update of tpd described above, the output will be
> driven only after the maximum
> negative setup time (absolute value), which is not the
> reality and which can cause bus
> contention or wrong values on the bus.
>
> # 0 ns ticd_CEB : 0.76 ns
> # 0 ns tisd_WEB_CEB : 0 ns
> # 0 ns tisd_CSB_CEB : 0.76 ns
> # 0 ns tisd_BA_CEB : 0.76 ns
> # 0 ns tisd_A_CEB : 0.76 ns
>
> # 0 ns tpd_CEB_O : 1.17 ns (default: 1.93 ns)
> # 0 ns tpd_BA_O(0)(tr0z) : 0 ns (default: 0.69 ns)
> # 0 ns tpd_BA_O(0)(trz1) : 0 ns (default: 0.6 ns)
> # 0 ns tpd_BA_O(0)(tr1z) : 0 ns (default: 0.69 ns)
> # 0 ns tpd_BA_O(0)(trz0) : 0 ns (default: 0.6 ns)
>
> Question: Is there any workaround existing?
>
>
> It would be really great if somebody gave me some hints, because I'm
> stucked at the
> moment and I did not find any literature which is covering VITAL
> modeling in depth.
>
> Thanks in advance,
>
> Alex Schreiber
>
>
> **************************************************
> Alexander Schreiber (Alex_Schreiber@avanticorp.com)
> AVANT! Corporation
> Domaine de Green Side
> Les templiers
> 400, avenue Roumanille
> 06410 Sophia Antipolis
> France
> Work : (+33) 4 92 94 46 50
> Fax : (+33) 4 93 65 39 21
> **************************************************
--------------393755E2EC56079D286C554E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
Hi,
sorry, I think I sent it to the wrong address.
Alex Schreiber wrote:
Hi,I'm writing a VITAL model for a synchronous RAM at the moment. Some of the input signals can
have a negative timing in respect to the active edge of the clock. I followed the algorithm described
in chapter 8.2 of the IEEE 1076.4 (Oct. 95) Spec.There are several questions comming up of which I'm not sure if the reason is either a limitation
of the VHDL simulator (ModelSim), or a limitation in VITAL, or simply a misunderstanding of
mine.The sync. RAM has the following interface:
- CEB : clock signal (active on falling edge)
- CSB : chip select (low active)
- WEB : write enable (low active) << negative setup time <<
- OEB : output enable (low active, asynchronous)
- BA : bank address (several RAM blocks can be used to build a deeper or wider memory)
- I : data input << negative setup time <<
- O : data output (three-state, controlled by OEB and BA)Following the questions in detail:
1. Internal Signal Delay (tisd) for largest negative timing (absolute value):
====================================================When I follow the algorithm in chapter 8.2 and declare internal signal delay generics2. Internal Signal Delay value:
for all the signals which are dependent on the clock, the values of the VITAL generics
are updated during the 'negative constraint calculation phase' like follows:# 0 ns ticd_CEB : 0.4 ns
# 0 ns tisd_WEB_CEB : 0.1 ns
# 0 ns tisd_CSB_CEB : 0.2 ns
# 0 ns tisd_BA_CEB : 0.4 ns
# 0 ns tisd_A_CEB : 0.4 ns
# 0 ns tisd_I_CEB : 0.4 ns << ???# 0 ns tsetup_WEB_CEB_noedge_negedge : 0.2 ns (default: -0.1 ns) << neg. setup
# 0 ns thold_WEB_CEB_noedge_negedge : 0 ns (default: 0.3 ns)
# 0 ns tsetup_A_CEB_noedge_negedge(0) : 0 ns (default: 0.0 ns)
# 0 ns thold_A_CEB_noedge_negedge(0) : 0.6 ns (default: 0.6 ns)
# 0 ns tsetup_I_CEB_noedge_negedge(0) : 0 ns (default: -0.4 ns) << neg. setup
# 0 ns thold_I_CEB_noedge_negedge(0) : 2.5 ns (default: 2.5 ns)
# 0 ns tsetup_CSB_CEB_noedge_negedge : 0.6 ns (default: 0.4 ns)
# 0 ns thold_CSB_CEB_noedge_negedge : 0 ns (default: 0.2 ns)
# 0 ns tsetup_BA_CEB_noedge_negedge(0) : 0.6 ns (default: 0.6 ns)
# 0 ns thold_BA_CEB_noedge_negedge(0) : 0 ns (default: 0.0 ns)Question: Why is the input with the maximum negative setup time (absolute value)
delayed as well, i.e. why is tisd_I_CEB /= 0 ns? When I use a delayed
version of this signal (here: I), I do not win anything, because I will get a
false hold error due to the signal event of setup.Workaround: When I do not declare tisd for this signal (here: I), the signal will not
be delayed, but the setup and hold timings are updated in respect to
the delayed clock.Drawbacks: - assumption about the signal with the largest negative
setup time (absolute value) necessary
- not 100% conform to the spec.# 0 ns ticd_CEB : 0.4 ns
# 0 ns tisd_WEB_CEB : 0.1 ns
# 0 ns tisd_CSB_CEB : 0.2 ns
# 0 ns tisd_BA_CEB : 0.4 ns
# 0 ns tisd_A_CEB : 0.4 ns# 0 ns tsetup_WEB_CEB_noedge_negedge : 0.2 ns (default: -0.1 ns) << neg. setup
# 0 ns thold_WEB_CEB_noedge_negedge : 0 ns (default: 0.3 ns)
# 0 ns tsetup_A_CEB_noedge_negedge(0) : 0 ns (default: 0.0 ns)
# 0 ns thold_A_CEB_noedge_negedge(0) : 0.6 ns (default: 0.6 ns)
# 0 ns tsetup_I_CEB_noedge_negedge(0) : 0 ns (default: -0.4 ns) << neg. setup
# 0 ns thold_I_CEB_noedge_negedge(0) : 2.1 ns (default: 2.5 ns) << updated
# 0 ns tsetup_CSB_CEB_noedge_negedge : 0.6 ns (default: 0.4 ns)
# 0 ns thold_CSB_CEB_noedge_negedge : 0 ns (default: 0.2 ns)
# 0 ns tsetup_BA_CEB_noedge_negedge(0) : 0.6 ns (default: 0.6 ns)
# 0 ns thold_BA_CEB_noedge_negedge(0) : 0 ns (default: 0.0 ns)
=====================In the example given in point 1 the second signal, which has a smaller negative setup3. Update of Path Delays (tpd):
time (here: WEB), is delayed in a way, that the hold time becomes 0 ns. But this is not
always the case. With different timing values, it can happen, that the second signal
is not delayed at all, which results in positive, non-zero values for both, setup and hold
timings (updated in respect to the delayed clock).# 0 ns ticd_CEB : 0.76 ns
# 0 ns tisd_WEB_CEB : 0 ns# 0 ns tsetup_WEB_CEB_noedge_negedge : 0.62 ns (default: -0.14 ns)
# 0 ns thold_WEB_CEB_noedge_negedge : 1.58 ns (default: 2.34 ns)Problem: Each new value which is scheduled in the future (e.g. by VitalSignalDelay)
takes place at +0 delta at that point of time. It doesn't matter when and at
which delta it was scheduled. In the second case there is no problem, but
as soon as the hold time becomes 0 ns (after update) like in the first one,
the signal needs to be delayed by one delta ('delayed) to insure, that the
previous value is taken at the active clock edge. Otherwise false errors
are detected or the model is not working.
======================According to chapter 8.2.2.4 of IEEE 1076.4 the propagation delay values are adjustedIt would be really great if somebody gave me some hints, because I'm stucked at the
as well based on the value of the internal signal delay generic. If the original path delay
value is smaller than the value of the internal signal delay, the adjusted path delay value
will be set to 0 ns. This causes a problem for BA.In our sync. RAM, BA has two functionalities. The first function is like CSB, where it
needs to meet setup and hold timings in respect to the active clock edge. To model this functionality setup and hold generics are defined.The second function is like OEB, where it controls the three-state output driver asynchronously. To model this effect, the path delay generic is used.
Due to the update of tpd described above, the output will be driven only after the maximum
negative setup time (absolute value), which is not the reality and which can cause bus
contention or wrong values on the bus.# 0 ns ticd_CEB : 0.76 ns
# 0 ns tisd_WEB_CEB : 0 ns
# 0 ns tisd_CSB_CEB : 0.76 ns
# 0 ns tisd_BA_CEB : 0.76 ns
# 0 ns tisd_A_CEB : 0.76 ns# 0 ns tpd_CEB_O : 1.17 ns (default: 1.93 ns)
# 0 ns tpd_BA_O(0)(tr0z) : 0 ns (default: 0.69 ns)
# 0 ns tpd_BA_O(0)(trz1) : 0 ns (default: 0.6 ns)
# 0 ns tpd_BA_O(0)(tr1z) : 0 ns (default: 0.69 ns)
# 0 ns tpd_BA_O(0)(trz0) : 0 ns (default: 0.6 ns)Question: Is there any workaround existing?
moment and I did not find any literature which is covering VITAL modeling in depth.Thanks in advance,
Alex Schreiber
**************************************************
Alexander Schreiber (Alex_Schreiber@avanticorp.com)
AVANT! Corporation
Domaine de Green Side
Les templiers
400, avenue Roumanille
06410 Sophia Antipolis
France
Work : (+33) 4 92 94 46 50
Fax : (+33) 4 93 65 39 21
**************************************************
--------------393755E2EC56079D286C554E--