Signal Set-up Before CLK Rise

W

Wojtek

Guest
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
 
Użytkownik "Wojtek" <spawnek@_ale_bez _spamu.wp.pl> napisał w wiadomości
news:1151855873.403249@pdp.ustronie.pw.edu.pl...
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
Click to expand...
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' ?
Click to expand...
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.
Click to expand...
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" <kkjennings@sbcglobal.net> napisał w wiadomości
news:_57qg.61402$fb2.55717@newssvr27.news.prodigy.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)
Click to expand...
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.
Click to expand...

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:1151855873.403249@pdp.ustronie.pw.edu.pl 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:1151857021.597536@pdp.ustronie.pw.edu.pl 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" <Colin_Paul_Gloster@ACM.org> napisał w
wiadomości news:e8b0eh$rl$1@newsserver.cilea.it...
In news:1151855873.403249@pdp.ustronie.pw.edu.pl 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.
Click to expand...


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
Click to expand...
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" <p.peyremorte.remove_that@free.fr> napisał w
wiadomości news:44a924f3$0$896$ba4acef3@news.orange.fr...

If you can synthetize an output latch driven by (not clock), it will work
until the timings are respected (0,8ns late maximum)
Click to expand...
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"
;-)
Click to expand...

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.
Click to expand...
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.
Click to expand...
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?
Click to expand...
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?
Click to expand...
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
 
Użytkownik "KJ" <kkjennings@sbcglobal.net> napisał w wiadomości
news:svfqg.33737$VE1.28009@newssvr14.news.prodigy.com...


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'.
Click to expand...

Hmm... it sounds ok :)

I'll check it...

Thanks

Wojtek
 
Użytkownik "Pascal Peyremorte" <p.peyremorte.remove_that@free.fr> napisał w
wiadomości news:44aa1ce7$0$1027$ba4acef3@news.orange.fr...

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.
Click to expand...


I think 0.8 ns is very short time. I synthesised my component:

Source: S_THIS_9 (FF)
Destination: P_O_DQ<10> (PAD)
Source Clock: P_I_CLK falling

Data Path: S_THIS_9 to P_O_DQ<10>
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
FDC_1:C->Q 34 0.307 1.360 S_THIS_9 (S_THIS_9)
LUT2:I1->O 1 0.195 0.534 _n0003<1>1
(Mtridata_P_O_DQ<1>)
OBUFT:I->O 3.957 P_O_DQ_1_OBUFT (P_O_DQ<1>)
----------------------------------------
Total 6.353ns (4.459ns logic, 1.894ns route)
(70.2% logic, 29.8% route)




and that is report:

Why are there 4 clocks?
If 6 ns is necessary, i would have to use about 100 MHz clock...

I do not know if i can use clocks slower than written in pdf..



=========================================================================
* HDL Synthesis *
=========================================================================

Synthesizing Unit <use_sram>.
Related source file is "C:/Xilinx/nanowo/sram.vhdl".
WARNING:Xst:647 - Input <P_I_RW> is never used.
WARNING:Xst:647 - Input <P_I_Ready> is never used.
WARNING:Xst:736 - Found 11-bit latch for signal <Mtridata_P_O_Data> created
at line 131.
WARNING:Xst:736 - Found 11-bit latch for signal <Mtridata_P_O_DQ> created at
line 132.
Using one-hot encoding for signal <S_THIS>.
INFO:Xst:2117 - HDL ADVISOR - Mux Selector <S_THIS> of Case statement line
70 was re-encoded using one-hot encoding. The case statement will be
optimized (default statement optimization), but this optimization may lead
to design initialization problems. To ensure the design works safely, you
can:
- add an 'INIT' attribute on signal <S_THIS> (optimization is then done
without any risk)
- use the attribute 'signal_encoding user' to avoid onehot optimization
- use the attribute 'safe_implementation yes' to force XST to perform a
safe (but less efficient) optimization
Found 4x2-bit ROM for signal <$n0009>.
WARNING:Xst:736 - Found 1-bit latch for signal <Mtrien_P_O_Data> created at
line 131.
INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data
and gate enable inputs of this latch share common terms. This situation will
potentially lead to setup/hold violations and, as a result, to simulation
problems. This situation may come from an incomplete case statement (all
selector values are not covered). You should carefuly review if it was in
your intentions to describe such a latch.
WARNING:Xst:736 - Found 1-bit latch for signal <Mtrien_P_O_DQ> created at
line 132.
INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data
and gate enable inputs of this latch share common terms. This situation will
potentially lead to setup/hold violations and, as a result, to simulation
problems. This situation may come from an incomplete case statement (all
selector values are not covered). You should carefuly review if it was in
your intentions to describe such a latch.
WARNING:Xst:737 - Found 10-bit latch for signal <S_NEXT>.
INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data
and gate enable inputs of this latch share common terms. This situation will
potentially lead to setup/hold violations and, as a result, to simulation
problems. This situation may come from an incomplete case statement (all
selector values are not covered). You should carefuly review if it was in
your intentions to describe such a latch.
Found 11-bit tristate buffer for signal <P_O_DQ>.
Found 11-bit tristate buffer for signal <P_O_Data>.
Found 10-bit register for signal <S_THIS>.
Summary:
inferred 1 ROM(s).
inferred 22 Tristate(s).
Unit <use_sram> synthesized.


=========================================================================
HDL Synthesis Report

Macro Statistics
# ROMs : 1
4x2-bit ROM : 1
# Registers : 1
10-bit register : 1
# Latches : 5
1-bit latch : 2
10-bit latch : 1
11-bit latch : 2
# Tristates : 2
11-bit tristate buffer : 2

=========================================================================

=========================================================================
* Advanced HDL Synthesis *
=========================================================================


=========================================================================
Advanced HDL Synthesis Report

Macro Statistics
# ROMs : 1
4x2-bit ROM : 1
# Registers : 10
Flip-Flops : 10
# Latches : 5
1-bit latch : 2
10-bit latch : 1
11-bit latch : 2

=========================================================================

=========================================================================
* Low Level Synthesis *
=========================================================================
WARNING:Xst:1426 - The value init of the FF/Latch S_NEXT_0 hinder the
constant cleaning in the block use_sram.
You should achieve better results by setting this init to 0.
WARNING:Xst:1294 - Latch <Mtridata_P_O_DQ_10> is equivalent to a wire in
block <use_sram>.
WARNING:Xst:1294 - Latch <Mtridata_P_O_DQ_9> is equivalent to a wire in
block <use_sram>.
WARNING:Xst:1294 - Latch <Mtridata_P_O_DQ_8> is equivalent to a wire in
block <use_sram>.
WARNING:Xst:1294 - Latch <Mtridata_P_O_DQ_7> is equivalent to a wire in
block <use_sram>.
WARNING:Xst:1294 - Latch <Mtridata_P_O_DQ_6> is equivalent to a wire in
block <use_sram>.
WARNING:Xst:1294 - Latch <Mtridata_P_O_DQ_5> is equivalent to a wire in
block <use_sram>.
WARNING:Xst:1294 - Latch <Mtridata_P_O_DQ_4> is equivalent to a wire in
block <use_sram>.
WARNING:Xst:1294 - Latch <Mtridata_P_O_DQ_3> is equivalent to a wire in
block <use_sram>.
WARNING:Xst:1294 - Latch <Mtridata_P_O_DQ_2> is equivalent to a wire in
block <use_sram>.
WARNING:Xst:1294 - Latch <Mtridata_P_O_DQ_1> is equivalent to a wire in
block <use_sram>.
WARNING:Xst:1294 - Latch <Mtridata_P_O_DQ_0> is equivalent to a wire in
block <use_sram>.
Loading device for application Rf_Device from file '4vlx15.nph' in
environment C:\Xilinx.

Optimizing unit <use_sram> ...

Mapping all equations...
Building and optimizing final netlist ...
Found area constraint ratio of 100 (+ 5) on block use_sram, actual ratio is
0.
FlipFlop S_THIS_2 has been replicated 5 time(s) to handle iob=true
attribute.
Latch Mtrien_P_O_Data has been replicated 10 time(s) to handle iob=true
attribute.
Latch Mtrien_P_O_DQ has been replicated 10 time(s) to handle iob=true
attribute.

=========================================================================
* Final Report *
=========================================================================
Final Results
RTL Top Level Output File Name : use_sram.ngr
Top Level Output File Name : use_sram
Output Format : NGC
Optimization Goal : Speed
Keep Hierarchy : NO

Design Statistics
# IOs : 100

Cell Usage :
# BELS : 35
# GND : 1
# LUT2 : 15
# LUT3 : 19
# FlipFlops/Latches : 58
# FDC_1 : 14
# FDP_1 : 1
# LD : 33
# LD_1 : 10
# Clock Buffers : 1
# BUFGP : 1
# IO Buffers : 97
# IBUF : 42
# OBUF : 33
# OBUFT : 22
=========================================================================

Device utilization summary:
---------------------------

Selected Device : 4vlx15sf363-10

Number of Slices: 34 out of 6144 0%
Number of Slice Flip Flops: 20 out of 12288 0%
Number of 4 input LUTs: 34 out of 12288 0%
Number of bonded IOBs: 98 out of 240 40%
IOB Flip Flops: 38
Number of GCLKs: 1 out of 32 3%


=========================================================================
TIMING REPORT

NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
GENERATED AFTER PLACE-and-ROUTE.

Clock Information:
------------------
-----------------------------------+------------------------+-------+
Clock Signal | Clock buffer(FF name) | Load |
-----------------------------------+------------------------+-------+
_n0021(_n00211:O) | NONE(*)(Mtrien_P_O_DQ) | 22 |
S_THIS_9 | NONE | 10 |
P_I_CLK | BUFGP | 15 |
S_THIS_4 | NONE | 11 |
-----------------------------------+------------------------+-------+
(*) This 1 clock signal(s) are generated by combinatorial logic,
and XST is not able to identify which are the primary clock signals.
Please use the CLOCK_SIGNAL constraint to specify the clock signal(s)
generated by combinatorial logic.
INFO:Xst:2169 - HDL ADVISOR - Some clock signals were not automatically
buffered by XST with BUFG/BUFR resources. Please use the buffer_type
constraint in order to insert these buffers to the clock signals to help
prevent skew problems.

Timing Summary:
---------------
Speed Grade: -10

Minimum period: No path found
Minimum input arrival time before clock: 1.890ns
Maximum output required time after clock: 6.353ns
Maximum combinational path delay: 6.415ns

Timing Detail:
--------------
All values displayed in nanoseconds (ns)

=========================================================================
Timing constraint: Default OFFSET IN BEFORE for Clock 'S_THIS_4'
Total number of paths / destination ports: 11 / 11
-------------------------------------------------------------------------
Offset: 1.890ns (Levels of Logic = 1)
Source: P_I_DQ<10> (PAD)
Destination: Mtridata_P_O_Data_10 (LATCH)
Destination Clock: S_THIS_4 falling

Data Path: P_I_DQ<10> to Mtridata_P_O_Data_10
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
IBUF:I->O 1 0.965 0.534 P_I_DQ_10_IBUF
(P_I_DQ_10_IBUF)
LD:D 0.391 Mtridata_P_O_Data_10
----------------------------------------
Total 1.890ns (1.356ns logic, 0.534ns route)
(71.8% logic, 28.2% route)

=========================================================================
Timing constraint: Default OFFSET OUT AFTER for Clock 'P_I_CLK'
Total number of paths / destination ports: 64 / 40
-------------------------------------------------------------------------
Offset: 6.353ns (Levels of Logic = 2)
Source: S_THIS_9 (FF)
Destination: P_O_DQ<10> (PAD)
Source Clock: P_I_CLK falling

Data Path: S_THIS_9 to P_O_DQ<10>
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
FDC_1:C->Q 34 0.307 1.360 S_THIS_9 (S_THIS_9)
LUT2:I1->O 1 0.195 0.534 _n0003<1>1
(Mtridata_P_O_DQ<1>)
OBUFT:I->O 3.957 P_O_DQ_1_OBUFT (P_O_DQ<1>)
----------------------------------------
Total 6.353ns (4.459ns logic, 1.894ns route)
(70.2% logic, 29.8% route)

=========================================================================
Timing constraint: Default OFFSET OUT AFTER for Clock 'S_THIS_4'
Total number of paths / destination ports: 11 / 11
-------------------------------------------------------------------------
Offset: 4.964ns (Levels of Logic = 1)
Source: Mtridata_P_O_Data_10 (LATCH)
Destination: P_O_Data<10> (PAD)
Source Clock: S_THIS_4 falling

Data Path: Mtridata_P_O_Data_10 to P_O_Data<10>
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
LD:G->Q 1 0.473 0.534 Mtridata_P_O_Data_10
(Mtridata_P_O_Data_10)
OBUFT:I->O 3.957 P_O_Data_10_OBUFT
(P_O_Data<10>)
----------------------------------------
Total 4.964ns (4.430ns logic, 0.534ns route)
(89.2% logic, 10.8% route)

=========================================================================
Timing constraint: Default OFFSET OUT AFTER for Clock '_n0021'
Total number of paths / destination ports: 22 / 22
-------------------------------------------------------------------------
Offset: 4.964ns (Levels of Logic = 1)
Source: Mtrien_P_O_Data_1 (LATCH)
Destination: P_O_Data<10> (PAD)
Source Clock: _n0021 falling

Data Path: Mtrien_P_O_Data_1 to P_O_Data<10>
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
LD:G->Q 1 0.473 0.534 Mtrien_P_O_Data_1
(Mtrien_P_O_Data_1)
OBUFT:T->O 3.957 P_O_Data_10_OBUFT
(P_O_Data<10>)
----------------------------------------
Total 4.964ns (4.430ns logic, 0.534ns route)
(89.2% logic, 10.8% route)

=========================================================================
Timing constraint: Default path analysis
Total number of paths / destination ports: 31 / 31
-------------------------------------------------------------------------
Delay: 6.415ns (Levels of Logic = 3)
Source: P_I_adress<0> (PAD)
Destination: P_O_A0 (PAD)

Data Path: P_I_adress<0> to P_O_A0
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
IBUF:I->O 1 0.965 0.765 P_I_adress_0_IBUF
(P_I_adress_0_IBUF)
LUT3:I0->O 1 0.195 0.534 P_O_A01 (P_O_A0_OBUF)
OBUF:I->O 3.957 P_O_A0_OBUF (P_O_A0)
----------------------------------------
Total 6.415ns (5.117ns logic, 1.298ns route)
(79.8% logic, 20.2% route)

=========================================================================
CPU : 13.14 / 14.00 s | Elapsed : 13.00 / 14.00 s

-->

Total memory usage is 192560 kilobytes

Number of errors : 0 ( 0 filtered)
Number of warnings : 20 ( 0 filtered)
Number of infos : 5 ( 0 filtered)
 
zlotawy a écrit :
Użytkownik "Pascal Peyremorte" <p.peyremorte.remove_that@free.fr> napisał w
wiadomości news:44aa1ce7$0$1027$ba4acef3@news.orange.fr...

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.

I think 0.8 ns is very short time. I synthesised my component:
Click to expand...
I cannot help you more about vhdl synthesis, because I'am a poor
beginner. I was only trying to help about your first question of
datasheet reading.

I wonder whether I really undertood what you wants ! I will not change
anything about I writed before : it is right.

Have you to compute the full ADSP signal each clock within only one
clock cycle delay ? It would be surprising.

I think the ADSP line state should be computed during N clock cycles
before outputing, but when you want to output it, you have to do it
regarding the timings we speak before.
So only the last latch enter in consideration for this timing (clock
input to valid pin output timing), plus delay between this clock from
cypress input clock.

As I do not know frow which events the ADSP line is computed, and its
requirements, I cannot speak about how to pipeline it. This is another
part of the job with no matter of your first question.

Pascal
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top