Signal Set-up Before CLK Rise

Hello,
signal ADSP has to be set up before CLK Rise. And i do not know what it
means

How can I do this?

Maybe clk'event and clk='0' ?

You can see this => http://www.warszawa.koliber.org/sejm/signals.pdf


Thank You for Your attention

zlotawy

Wojtek

U¿ytkownik "Wojtek" <spawnek@_ale_bez _spamu.wp.pl> napisa³ w wiadomo¶ci
news:...
> Hello,
> signal ADSP has to be set up before CLK Rise. And i do not know what it
> means
>
> How can I do this?
>
> Maybe clk'event and clk='0' ?
>
> You can see this => http://www.warszawa.koliber.org/sejm/signals.pdf
>

and second question,

can I use in one component processes where one is clocked by rising and
other by falling?

zlotawy

>> Hello,
>> signal ADSP has to be set up before CLK Rise. And i do not know what it
>> means
>>
>> How can I do this?
>>
>> Maybe clk'event and clk='0' ?

No, clk'event and clk= '1' (or better...use rising_edge(clk) from the ieee
std_logic_1164 library)

>>
> and second question,
>
> can I use in one component processes where one is clocked by rising and
> other by falling?
>
Not in one process, if you're trying to create synthesizable code (i.e.
something that can be made into an actual part). Using two separate
processes there is no issue although generally using both edges of the clock
is a symptom of poor design practice.

KJ

U¿ytkownik "KJ" <> napisa³ w wiadomo¶ci
news:_57qg.61402$. net...
>
>>> Hello,
>>> signal ADSP has to be set up before CLK Rise. And i do not know what it
>>> means
>>>
>>> How can I do this?
>>>
>>> Maybe clk'event and clk='0' ?
>
> No, clk'event and clk= '1' (or better...use rising_edge(clk) from the ieee
> std_logic_1164 library)
>

signal ADSP has to be set up before CLK Rise. so i can not use
rising_edge(clk).

as you can see http://www.warszawa.koliber.org/sejm/signals.pdf on page 2.




>> and second question,
>>
>> can I use in one component processes where one is clocked by rising and
>> other by falling?
>>
> Not in one process, if you're trying to create synthesizable code (i.e.
> something that can be made into an actual part). Using two separate
> processes there is no issue although generally using both edges of the
> clock is a symptom of poor design practice.


i want to create driver for SRAM. SRAM works with rising edge, driver should
works with falling edge (if i have to set up signal before rising clock of
SRAM). Clock is the same.

Do You have any idea how i can make it in other way?

Wojtek

In news: timestamped Sun, 2 Jul
2006 17:57:49 +0200, Zlotawy Wojtek posted:

"Hello,
signal ADSP has to be set up before CLK Rise. And i do not know what it
means

How can I do this?

Maybe clk'event and clk='0' ?

You can see this => http://www.warszawa.koliber.org/sejm/signals.pdf"

That PDF file is an excerpt of Cypress document number 38-05239 Rev. *B
for the CY7C1386C and the CY7C1387C. It is actually written in that PDF
file that the complement of ADSP (NOT ADSP in VHDL but in a real
implementation you would not bother to have a signal named ADSP but you
would have a signal named maybe NOT_ADSP) (the line drawn above ADSP
indicates the complement) must be "Set-up Before CLK Rise". It means
that NOT ADSP must be stable at some time (setup) before the rising
edge of the clock.

It is not really a matter of clk'event and clk='0', what is important is
that you have NOT ADSP at the necessary value early enough.

In news: timestamped Sun, 2 Jul
2006 18:16:32 +0200, Zlotawy Wojtek posted:

"and second question,

can I use in one component processes where one is clocked by rising and
other by falling?"

I do not believe that code clocked on the rising edge of a clock and
clocked on the falling edge of the same clock is synthesizable.

U¿ytkownik "Colin Pawe/l/ Gloster" <> napisa³ w
wiadomo¶ci news:e8b0eh$rl$...
> In news: timestamped Sun, 2 Jul
> 2006 17:57:49 +0200, Zlotawy Wojtek posted:
>
> "Hello,
> signal ADSP has to be set up before CLK Rise. And i do not know what it
> means
>
> How can I do this?
>
> Maybe clk'event and clk='0' ?
>
> You can see this => http://www.warszawa.koliber.org/sejm/signals.pdf"
>
> That PDF file is an excerpt of Cypress document number 38-05239 Rev. *B
> for the CY7C1386C and the CY7C1387C. It is actually written in that PDF
> file that the complement of ADSP (NOT ADSP in VHDL but in a real
> implementation you would not bother to have a signal named ADSP but you
> would have a signal named maybe NOT_ADSP) (the line drawn above ADSP
> indicates the complement) must be "Set-up Before CLK Rise". It means
> that NOT ADSP must be stable at some time (setup) before the rising
> edge of the clock.
>
> It is not really a matter of clk'event and clk='0', what is important is
> that you have NOT ADSP at the necessary value early enough.
>



OK, I see.

NOT_ADSP has to be set up before CLK Rise.

Before. Not at the moment of rising.

And I do not know how i can do this if I work with the same clock. How i can
set up it before clock rise? Hmm.. maybe with previous clock rise? Or set
up not before but with rising clock. Maybe it will be fast enough.

Wojtek

Wojtek a écrit :
>How i can set up it before clock rise? Hmm.. maybe with previous clock rise?
> Or set up not before but with rising clock. Maybe it will be fast enough.
>
> Wojtek

Hello Wojtek,

You need to drive ADSP at least 1,2 ns before clock'rise with clock @
250 MHz.

250 MHz have a cycle time of 4 ns. Clock'fall is half, so 2 ns before
Clock'rise. It enable you to have 0,8 ns max of jitter in ADSP line.

If you can synthetize an output latch driven by (not clock), it will
work until the timings are respected (0,8ns late maximum)


Be careful about "Maybe it will ...".
In the most of cases, "May be it will work" is equivalent to "It will
not always work".
In the others case it is equivalent to "It will crash at the worst
moment"

Pascal

U¿ytkownik "Pascal Peyremorte" <> napisa³ w
wiadomo¶ci news:44a924f3$0$896$...

> If you can synthetize an output latch driven by (not clock), it will work
> until the timings are respected (0,8ns late maximum)

i do not know yet if i can

is it possible to synthetize component with clock rising in one process and
falling in other? If not, it will be harder but not impossible

time you wrote (0.8 ns) is max time from my setting to being right value on
output. I understand correctly?


>
> Be careful about "Maybe it will ...".
> In the most of cases, "May be it will work" is equivalent to "It will not
> always work".
> In the others case it is equivalent to "It will crash at the worst moment"
>
>


Yeah


Thank You
Wojtek

>
> signal ADSP has to be set up before CLK Rise. so i can not use
> rising_edge(clk).
>
> as you can see http://www.warszawa.koliber.org/sejm/signals.pdf on page 2.
>

As is true also with every storage element in every synchronous design. I'm
assuming that the clock to both the controller and the memory are free
running and arrive at both the controller and the memory device at the same
time. The setup time prior to the clock at the memory will be the clock
period less the clock to output delay of the controller less any clock skew
between the devices less any PCB propogation delay. At least those are the
major contributors. If you try to use the falling edge you'll immediately
have one other major contributor (and will generally be larger than any of
the above) which is that you'll need to know precisely when the falling edge
occurs relative to the rising edge (hint: it won't be exactly half way).
Even if that falling edge occurs exactly in the middle of the clock cycle
you immediately start at a disadvantage in that half of the clock cycle is
now gone, you've traded it for a large hold time (i.e. the time that the
signal is stable AFTER the clock...which in many cases is unimportant and if
you make that trade you're crippling your design).

One of the times when a falling edge driven controller 'might' be justified
is when there is an unusually large hold time requirement (in this case from
the SRAM), not a setup time requirement.

>
>
> i want to create driver for SRAM. SRAM works with rising edge, driver
> should works with falling edge (if i have to set up signal before rising
> clock of SRAM). Clock is the same.

What you seem to be missing is that you don't have a requirement to
accomplish all of this on one single clock cycle. The controller can
receive the command to write to memory on one clock cycle and the write can
be sent to the memory on the next clock cycle....the SRAM doesn't care.
This does not imply that the SRAM can not be written to on every clock cycle
either if that's what you may be thinking, this is just an example of what
is called 'pipelining'.

> Do You have any idea how i can make it in other way?

Yes, use the rising edge of the clock exclusively and a simulator. It will
all work out.

KJ

Wojtek a écrit :
> [...]
> time you wrote (0.8 ns) is max time from my setting to being right value
> on output. I understand correctly?

Yes, assuming that you use the cypress device at 250MHz (first column)
and that you do not forget to include in it the propagation time from
the output of your VHDL device to the input of the cypress device. Be
carefull of the routing, load capacitors, impedance matching, etc.

In detail, 0.8 ns is the time that you dispose from the falling edge of
"clock" to the ADSP stable signal, mesured BOTH at the input of the
cypress device.
If "clock" is delivered by your VHDL device, it is relatively easy to
assure that all propagation times may be close together between clock
and and other lines.
But if clock is issued by another device and only used by both you VHDL
device and the Cypress one, you have to look very close to all that.

Pascal