Signal Set-up Before CLK Rise

Discussion in 'VHDL' started by Wojtek, Jul 2, 2006.

  1. Wojtek

    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
    Wojtek, Jul 2, 2006
    #1
    1. Advertising

  2. Wojtek

    Wojtek Guest

    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
    Wojtek, Jul 2, 2006
    #2
    1. Advertising

  3. Wojtek

    KJ 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' ?


    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
    KJ, Jul 3, 2006
    #3
  4. Wojtek

    Wojtek Guest

    U¿ytkownik "KJ" <> napisa³ w wiadomo¶ci
    news:_57qg.61402$...
    >
    >>> 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
    Wojtek, Jul 3, 2006
    #4
  5. 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.
    Colin Pawe/l/ Gloster, Jul 3, 2006
    #5
  6. Wojtek

    Wojtek Guest

    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, Jul 3, 2006
    #6
  7. 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
    Pascal Peyremorte, Jul 3, 2006
    #7
  8. Wojtek

    Wojtek Guest

    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
    Wojtek, Jul 3, 2006
    #8
  9. Wojtek

    KJ Guest

    >
    > 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
    KJ, Jul 3, 2006
    #9
  10. 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
    Pascal Peyremorte, Jul 4, 2006
    #10
  11. Wojtek

    zlotawy Guest

    U¿ytkownik "KJ" <> napisa³ w wiadomo¶ci
    news:svfqg.33737$...


    >
    > 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'.
    >



    Hmm... it sounds ok :)

    I'll check it...

    Thanks

    Wojtek
    zlotawy, Jul 5, 2006
    #11
  12. Wojtek

    zlotawy Guest

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

    > 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:

    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, Jul 5, 2006
    #12
  13. zlotawy a écrit :
    > U¿ytkownik "Pascal Peyremorte" <> napisa³ w
    > wiadomo¶ci news:44aa1ce7$0$1027$...
    >
    >> 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:


    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
    Pascal Peyremorte, Jul 5, 2006
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rakesh Sharma
    Replies:
    2
    Views:
    2,913
    Thomas Rudloff
    Oct 22, 2004
  2. martin.wahlstedt
    Replies:
    1
    Views:
    1,627
    scottcarl
    May 15, 2007
  3. Replies:
    18
    Views:
    6,582
  4. neilmac
    Replies:
    2
    Views:
    702
    neilmac
    Jan 11, 2008
  5. axr0284
    Replies:
    3
    Views:
    913
Loading...

Share This Page