Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 117900

Article: 117900
Subject: Re: Which are the best books about CORDIC algorithms and applications
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 12 Apr 2007 23:32:09 +0100
Links: << >>  << T >>  << A >>
On 12 Apr 2007 12:40:55 -0700, "Weng Tianxiang" 
<wtxwtx@gmail.com> wrote:

>I have read Ray paper and went to his website and read "How to
>calculate sine()". After reading I still have difficulties
>understanding its process.
>
>Can you give an example on how to calculate sine(x), where x = 35
>degrees?
>
>I don't understand why he could calculate the factor K before starting
>calculation. Because during calculating, one doesn't know how many
>iterations should be taken to reach required accuracy.

Ah, but that's not so.  The whole point about CORDIC is that
you *do* know in advance how many iterations it takes.
You *never* stop the iterations early.

Having said that... the fudge-factor K reaches an asymptote
so quickly that the error (for any number of iterations greater
than about 10) is negligibly small.

I'll try an explanation... be sure to read it in a
monospaced (Courier etc) font.

I can rotate a vector (x,y) through any angle A, giving a 
rotated vector (x', y'),  by using the matrix multiplication

 / x' \     / cos(A)  -sin(A) \     / x \
 |    |  =  |                 |  *  |   |
 \ y' /     \ sin(A)   cos(A) /     \ y /

We can divide both sides of the equation by cos(A)...

 / x'/cos(A) \     / 1  -tan(A) \     / x \
 |           |  =  |            |  *  |   |
 \ y'/cos(A) /     \ tan(A)  1  /     \ y /

since tan(A) = sin(A)/cos(A).  That works out
fairly easily as

 x'/cos(A) = x - y.tan(A)  or  x' = cos(A) * (x - y.tan(A))
 y'/cos(A) = x.tan(A) + y  or  y' = cos(A) * (x.tan(A) + y)

Now here comes the cunning part:  Suppose we choose A 
so that tan(A) is exactly 2^(-N) for some integer N.
The calculation of x.tan(A) and y.tan(A) is now a 
simple right shift (division by an exact power of 2).
Note, too, that you can make the rotation negative
simply by swapping the + and - operations.

Of course, to get this we require 
  A = arctan(2^(-N))
for some integer N.  For example:

N=0: A = arctan(1) = 45 degrees
N=1: A = arctan(0.5) = 26.565... degrees
N=2: A = arctan(0.25) = 14.036... degrees

All this would be harmless fun, until Volder (in his 1959
paper) was able to prove that ANY angle within a certain
range (roughly +/- 100 degrees) can be expressed as the 
sum of all these different A, for N=0,1,2....infinity,
if each of those terms is either added or subtracted
(i.e. multiplied by +1 or -1).  Of course we don't need
to go to infinity, but only "far enough" for any given
accuracy.  To take your 35-degree example:

start                                     0     ... too small
add      arctan(1)      0     + 45     = 45     ... too big
subtract arctan(1/2)   45     - 26.565 = 18.435 ... too small
add      arctan(1/4)   18.435 + 14.036 = 32.471 ... too small
add      arctan(1/8)   32.471 +  7.125 = 39.696 ... too big
subtract arctan(1/16)  39.696 -  3.576 = 36.120 ... too big
...

and after, let's say, 16 such steps you will have converged 
on your desired 35 degree angle to within about 0.002%.
Of course, you pre-calculate all these arctan angles and
store them in a little lookup table.

Meanwhile, as you have been adding and subtracting these
angles you have also been doing the matrix multiplication
(in the right direction at each step, of course).
If you started with x = 1.00000 and y = 0, then
by the time you have finished, the final x and y values
will be the cosine and sine of your desired angle
BUT they will also have been multiplied by all the
1/cos(A) factors at each step.  So you get a
scaling (the CORDIC gain) of

  1/cos(arctan(1)) * 1/cos(arctan(0.5)) * ...

Try it on a spreadsheet; you'll find this value very
quickly converging on the limit value 1.646760258.
To fix this problem, all you need to do is start with
x=0.607252935...  instead of 1.00000.

SUCH a pretty algorithm... but, as others have said,
in these days of fast, cheap multipliers it's not
so useful as it once was.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 117901
Subject: Re: spartan 3e availability
From: "emu" <emu@ecubics.com>
Date: 12 Apr 2007 16:02:31 -0700
Links: << >>  << T >>  << A >>
On Apr 12, 3:05 pm, Austin Lesea <aus...@xilinx.com> wrote:
> emu,
>
> I went to the Xilinx.com website, did a search on the part number,
> clicked on the store for NuHorizons, and there is 1 in stock, and ships
> in 24 hrs.

Hello Austin,
went there again, and it says "factory stock". Which is not the same
as they would really have it in stock.
Sorry ;-)


Article: 117902
Subject: Re: System Generator pcore I/O performance results
From: "Newman" <newman5382@yahoo.com>
Date: 12 Apr 2007 17:12:12 -0700
Links: << >>  << T >>  << A >>
On Apr 11, 11:54 am, "eejw" <wilder_j...@hotmail.com> wrote:
> Newman,
>
> Thanks for writing back.
>
> I tried:  1. starting the timer  2. writing 8 samples  3. reading
> timer  4. dividing timer result by 8 -->
> This gave me an average write time of 20 cc's.  So it did lower it
> some.
>
> It's interesting...I'm finding that it takes 21 cc's to read/write
> data from/to external SRAM.  I would think that the FSL link should be
> *much* faster since it's accessing memory on-chip.  In fact, the
> mb_ref_guide states a latency of 2 cc's for using non-blocking "put"
> and "get" operations for transferring data over FSL.  Blocking
> accesses stall until there is space available on the FSL.  What I am
> doing is a very simple design, and there shouldn't be any blocking, at
> least not from the program I am implementing.  There must be some way
> to get better performance than what I'm seeing.
>
> I'm not implementing cache with this design.
>
> I looked at main.s and couldn't really make much sense of the assembly
> code.  I did searches for put, get, fsl and found nothing.  I would be
> interested to know how the compiler is translating to machine code as
> well...is there some option for seeing c-code interspersed with
> related assembly?  I set compiler options to no optimization and
> create symbols for assembly.
>
> Joel
>
> On Apr 10, 10:42 pm, "Newman" <newman5...@yahoo.com> wrote:
>
>
>
> > On Apr 10, 11:34 pm, "Newman" <newman5...@yahoo.com> wrote:
>
> > > On Apr 10, 12:12 pm, "eejw" <wilder_j...@hotmail.com> wrote:
>
> > > > Sorry...typo
>
> > > > 16-bit word (not "16-byte word") in passing data from MB -> pcore.
>
> > > > On Apr 10, 11:07 am, "eejw" <wilder_j...@hotmail.com> wrote:
>
> > > > > Hello all:
>
> > > > > I have a question regarding using SysGen to create a co-processor
> > > > > that's used in a microblaze design.  I'm using EDK v9.1 through the
> > > > > base system builder wizard to create a design used on a Xilinx ML401
> > > > > dev. board.
>
> > > > > I've already generated a simple pcore and connected that to the
> > > > > microblaze proc. in EDK.  Data are being passed from MB -> pcore and
> > > > > pcore -> MB through shared memory (using the "from register" and "to
> > > > > register" in SysGen).
>
> > > > > Using the provided function calls for communicating from MB -> pcore,
> > > > > I do the following:
>
> > > > > findavg_sm_0_Write(FINDAVG_SM_0_D0,FINDAVG_SM_0_D0_DIN, datasamp[0]);
> > > > > findavg_sm_0_Write(FINDAVG_SM_0_D1,FINDAVG_SM_0_D1_DIN, datasamp[1]);
> > > > > findavg_sm_0_Write(FINDAVG_SM_0_D2,FINDAVG_SM_0_D2_DIN, datasamp[2]);
> > > > > etc.
>
> > > > > To check performance, I start timer, do function call to write shared
> > > > > memory, then read value from timer.
>
> > > > > So it's just:
>
> > > > > //start timer
> > > > > findavg_sm_0_Write(FINDAVG_SM_0_D0,FINDAVG_SM_0_D0_DIN, datasamp[0]);
> > > > > //read count register
>
> > > > > I'm seeing that it takes 28 clock cycles to pass a 16-byte word from
> > > > > MB -> pcore in this way.  This seems *way* too long.
>
> > > > > To improve performance, the API documents that were generated when I
> > > > > created the pcore suggest to remove this line in the xparameters.h
> > > > > file:
>
> > > > > #define FINDAVG_SM_0_SG_ENABLE_FSL_ERROR_CHECK
>
> > > > > I did that, but it doesn't help.
>
> > > > > I didn't do anything special regarding connecting my pcore to the MB.
> > > > > Just added it through the Hardware -> Configure coprocessor... tool in
> > > > > EDK which connects the pcore to MB through an FSL.
>
> > > > > Has anyone investigated this and can share any words of wisdom?
>
> > > > > thanks,
> > > > > Joel- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > could start timer
> > > do 4 writes to different locations
> > > then read the elapsed value
> > > divide value by 4 manually
>
> > > it would be interesting to see if the value is still 28 clocks
> > > does MB have a cache?
> > > chipscope or simulation would highlight what's going on
>
> > > Newman- Hide quoted text -
>
> > > - Show quoted text -
> > > findavg_sm_0_Write(FINDAVG_SM_0_D0,FINDAVG_SM_0_D0_DIN, datasamp[0]);
>
> > also, disassemble the write function to see how efficiently it
> > compiled the instruction
> > I would think that it should be around 1 assembly op- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

A while back, I stepped through code on the target using the gnu debug
tool.  There is an option to compile the code and libraries for single
step debug that shows the mixed assembly with the C code and one can
single step at either level.

As mentioned, one can disassemble the elf, but the jtag gnu debugger
is more intuitive if you can suffer the pain to get it working.


Newman


Article: 117903
Subject: Re: SETUP & HOLD time confusion
From: "Newman" <newman5382@yahoo.com>
Date: 12 Apr 2007 18:02:47 -0700
Links: << >>  << T >>  << A >>
On Apr 12, 2:31 pm, "M. Hamed" <mhs...@gmail.com> wrote:
> In the Xilinx Synthesis and Simulation Design Guide there is this
> phrase:
>
> "While Xilinx data sheets report that there are zero hold times on the
> internal registers and I/O registers with the default delay and using
> a global clock buffer, it is still possible to receive a $hold
> violation from the simulator. This $hold violation is really a $setup
> violation on the register. However, in order to get an accurate
> representation of the CLB delays, part of the setup time must be
> modeled as a hold time."
>
> Can somebody put some more explanation to this phrase? I understand
> how the setup/hold window can be shifted back and forth by adding
> delay to the data path but I dont understand why the need for modeling
> part of the setup time as hold time, and how to properly fix hold time
> violations.
>
> Thank you.
> /MHS

Here is a stab at it.
The min propagation delay from a flip flop to another flip flop plus
the global clock uncertainty is more than the hold time of the
destination FF. If the propagation delay is continuously increased,
first you'll get a setup violation, if increased further... a hold
violation, increased further... no violation.  Once one hits the setup
violation point and further, the functionality of the device comes
into question.

I believe the answer is to limit the propagation delay with timing
constraints.

Newman


Article: 117904
Subject: Re: SETUP & HOLD time confusion
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 12 Apr 2007 19:34:11 -0700
Links: << >>  << T >>  << A >>
No, no, no. Let's not make a bad thing even worse.

I am ashamed that a Xilinx document publishes the above quoted
nonsense.
But let's at least look at the basics:
Set-up time and hold-time are both input timing requirements.
"3 ns set-up time" means, the new data must be there at least 3 ns
before the clock edge, in order to be guaranted to be captured in the
flip-flop. (like the airline says: you must be there one hour before
departure)
If data arrives later, it might actually make it, but there is no
guarantee.
A positive hold-time requirement (very rare and always bad!) means
that the data being clocked in must actually linger on the D pin (for
the specified positive hold time) beyond the clock edge. Bad
requirement, since it is often very hard to live with. That's why most
good parts specify "zero hold time", which means, you can take away
the data right at the clock edge. In reality even a bit earlier, but
that would have to be specified as a negative hold-time value, and few
data sheets do.
In other words, D must be stable from as early as a set-up time before
the clock, to as late as a (positive) hold time after the clock, but
most hold times are specified as 0.
If you change D within this required timing window, the flip-flop will
make the decision for you, whether it catches the early or the later
data, but it usually catches a clean 0 or 1. If you change data at a
very narrow "bulls-eye" point in time, then the flip-flop can indicate
its displeasure by having an unpredictable output delay, the infamous
metastable delay.
I do not have the foggiest idea what the stupid sentence in your quote
means, but it deserves to be eradicated and translated into English.
Let me inquire.
You obviously hit a sensitive nerve with me...
Peter Alfke


On Apr 12, 6:02 pm, "Newman" <newman5...@yahoo.com> wrote:
> On Apr 12, 2:31 pm, "M. Hamed" <mhs...@gmail.com> wrote:
>
>
>
> > In the Xilinx Synthesis and Simulation Design Guide there is this
> > phrase:
>
> > "While Xilinx data sheets report that there are zero hold times on the
> > internal registers and I/O registers with the default delay and using
> > a global clock buffer, it is still possible to receive a $hold
> > violation from the simulator. This $hold violation is really a $setup
> > violation on the register. However, in order to get an accurate
> > representation of the CLB delays, part of the setup time must be
> > modeled as a hold time."
>
> > Can somebody put some more explanation to this phrase? I understand
> > how the setup/hold window can be shifted back and forth by adding
> > delay to the data path but I dont understand why the need for modeling
> > part of the setup time as hold time, and how to properly fix hold time
> > violations.
>
> > Thank you.
> > /MHS
>
> Here is a stab at it.
> The min propagation delay from a flip flop to another flip flop plus
> the global clock uncertainty is more than the hold time of the
> destination FF. If the propagation delay is continuously increased,
> first you'll get a setup violation, if increased further... a hold
> violation, increased further... no violation.  Once one hits the setup
> violation point and further, the functionality of the device comes
> into question.
>
> I believe the answer is to limit the propagation delay with timing
> constraints.
>
> Newman



Article: 117905
Subject: Re: Please HELP: timing problems on Virtex-4FX
From: "Dima" <Dmitriy.Bekker@gmail.com>
Date: 12 Apr 2007 21:35:01 -0700
Links: << >>  << T >>  << A >>
Hi Ben,

> Well, those are the failing timespecs, certainly! More useful would be the
> paths themselves, from the TRACE report (.twr file), telling you the source
> and destination nets of the worst N paths in each timing group (where N is
> by default 3, I think). The clock uncertainty and skew are also reported
> there.

Ahh yes, of course. I have pasted the failing paths right below this
message. Unfortunatly, I couldn't attach the log file directly, so
please excuse the poor formatting. I reran the build this time without
the MGT protector core. Also, I implemented the workaround in AR 24326
which suppresses the DDR2 failing constraint. This note explains why
it is safe to suppress the DDR2 timing failure. I am a lot more
comfortable with this explanation than simply to ignore it.
Nevertheless, the design still fails wiht proc_clk_s and apu_fpu_clk_s
not meeting timing.

I also implemented a very basic design with only a few components:
CPU, PLB BRAM, and OPB RS232. I changed the CPU frequency to 266.67
MHz by only modifying CLKFX on dcm_0 (this one only has a single DCM
since no DDR2). I changed CLKFX to be M=8 and D=3 (instead of the
original M=3, D=1 for 300 MHz). Even this basic design still fails
timing! I have pasted the failing path for this design as well (see
below).

> Looking again at your clocking architecture, I'm not sure that the DCM
> configuration you're using will guarantee a rising-edge alignment between
> the 266MHz and 133MHz clocks - which is a requirement for the apu_fpu core.

Do you have a suggestion on how I should configure the DCMs for a
266-133 CPU-FPU ratio? Even a working basic design, without any memory
(like DDR2) would help. These frequencies are within the limits and I
am sure Xilinx must have tested this exact configuration to find the
maximum allowable frequency (which is 275 MHz for the CPU -11 grade
and 137.5 MHz for the FPU). If you have any suggestions here, I will
try them. I am running out of ideas. I opened up a webcase today as
well to see if I can get help from that avenue.

The failing paths are pasted in below. Thanks for your help.

- Dmitriy

================================================================================
DESIGN 1 with DDR2 (apu_fpu_clk_s)
================================================================================
Timing constraint: TS_system_i_dcm_0_dcm_0_CLKFX_BUF = PERIOD
TIMEGRP
"system_i_dcm_0_dcm_0_CLKFX_BUF" TS_sys_clk_pin / 1.33333333 HIGH 50%;

 423953 items analyzed, 50 timing errors detected. (48 setup errors, 2
hold errors)
 Minimum period is   9.606ns.
--------------------------------------------------------------------------------
Slack:                  -1.053ns (requirement - (data path - clock
path skew + uncertainty))
  Source:               system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/rs_fir_l1[31].r (FF)
  Destination:          system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/fpu_fetch_state_2 (FF)
  Requirement:          3.750ns
  Data Path Delay:      4.227ns (Levels of Logic = 7)
  Clock Path Skew:      -0.053ns
  Source Clock:         system_i/proc_clk_s rising at 3.750ns
  Destination Clock:    system_i/apu_fpu_clk_s rising at 7.500ns
  Clock Uncertainty:    0.523ns

  Clock Uncertainty:          0.523ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.311ns
    Phase Error (PE):           0.367ns

  Maximum Data Path: system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/rs_fir_l1[31].r to system_i/apu_fpu_0/
apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_state_2
    Location             Delay type         Delay(ns)  Physical
Resource
                                                       Logical
Resource(s)
    -------------------------------------------------
-------------------
    SLICE_X28Y200.YQ     Tcko                  0.307   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/instruction(1)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/rs_fir_l1[31].r
    SLICE_X34Y189.F2     net (fanout=12)       1.127   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/instruction(0)
    SLICE_X34Y189.COUT   Topcyf                0.491   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc0_subchain(1)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_dec_prod_0_and00001
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc0_cch[2].cmux
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc0_cch[1].cmux
    SLICE_X34Y190.CIN    net (fanout=1)        0.000   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc0_subchain(1)
    SLICE_X34Y190.COUT   Tbyp                  0.076   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc1_subchain(1)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc0_cch[0].cmux
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc1_cch[1].cmux
    SLICE_X34Y191.CIN    net (fanout=1)        0.000   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc1_subchain(1)
    SLICE_X34Y191.COUT   Tbyp                  0.076   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc2_subchain(1)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc1_cch[0].cmux
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc2_cch[1].cmux
    SLICE_X34Y192.CIN    net (fanout=1)        0.000   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc2_subchain(1)
    SLICE_X34Y192.XB     Tcinxb                0.339   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_dec_chain(3)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc2_cch[0].cmux
    SLICE_X37Y193.G4     net (fanout=6)        0.724   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_dec_chain(2)
    SLICE_X37Y193.Y      Tilo                  0.165   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_0_mux0001_map12
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_2_mux000125_sw0
    SLICE_X36Y196.G4     net (fanout=1)        0.438   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/n4862
    SLICE_X36Y196.Y      Tilo                  0.166   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_state(2)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_2_mux000125
    SLICE_X36Y196.F4     net (fanout=1)        0.135   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_2_mux0001_map11
    SLICE_X36Y196.CLK    Tfck                  0.183   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_state(2)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_2_mux000176
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_state_2
    -------------------------------------------------
---------------------------
    Total                                      4.227ns (1.803ns logic,
2.424ns route)
                                                       (42.7% logic,
57.3% route)

--------------------------------------------------------------------------------
Slack:                  -1.037ns (requirement - (data path - clock
path skew + uncertainty))
  Source:               system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/rs_fir_l1[31].r (FF)
  Destination:          system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/fpu_fetch_state_3 (FF)
  Requirement:          3.750ns
  Data Path Delay:      4.211ns (Levels of Logic = 6)
  Clock Path Skew:      -0.053ns
  Source Clock:         system_i/proc_clk_s rising at 3.750ns
  Destination Clock:    system_i/apu_fpu_clk_s rising at 7.500ns
  Clock Uncertainty:    0.523ns

  Clock Uncertainty:          0.523ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.311ns
    Phase Error (PE):           0.367ns

  Maximum Data Path: system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/rs_fir_l1[31].r to system_i/apu_fpu_0/
apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_state_3
    Location             Delay type         Delay(ns)  Physical
Resource
                                                       Logical
Resource(s)
    -------------------------------------------------
-------------------
    SLICE_X28Y200.YQ     Tcko                  0.307   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/instruction(1)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/rs_fir_l1[31].r
    SLICE_X34Y189.F2     net (fanout=12)       1.127   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/instruction(0)
    SLICE_X34Y189.COUT   Topcyf                0.491   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc0_subchain(1)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_dec_prod_0_and00001
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc0_cch[2].cmux
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc0_cch[1].cmux
    SLICE_X34Y190.CIN    net (fanout=1)        0.000   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc0_subchain(1)
    SLICE_X34Y190.COUT   Tbyp                  0.076   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc1_subchain(1)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc0_cch[0].cmux
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc1_cch[1].cmux
    SLICE_X34Y191.CIN    net (fanout=1)        0.000   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc1_subchain(1)
    SLICE_X34Y191.COUT   Tbyp                  0.076   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc2_subchain(1)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc1_cch[0].cmux
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc2_cch[1].cmux
    SLICE_X34Y192.CIN    net (fanout=1)        0.000   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc2_subchain(1)
    SLICE_X34Y192.XB     Tcinxb                0.339   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_dec_chain(3)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc2_cch[0].cmux
    SLICE_X36Y197.G3     net (fanout=6)        0.819   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_dec_chain(2)
    SLICE_X36Y197.XMUX   Tif5x                 0.477   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_3_mux0001_map1
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_3_mux0001171
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_3_mux000117_f5
    SLICE_X37Y197.G4     net (fanout=1)        0.303   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_3_mux0001_map7
    SLICE_X37Y197.CLK    Tgck                  0.196   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_state(3)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_3_mux000126
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_state_3
    -------------------------------------------------
---------------------------
    Total                                      4.211ns (1.962ns logic,
2.249ns route)
                                                       (46.6% logic,
53.4% route)

--------------------------------------------------------------------------------
Slack:                  -1.015ns (requirement - (data path - clock
path skew + uncertainty))
  Source:               system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/rs_fir_l1[1].r (FF)
  Destination:          system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/fpu_fetch_state_2 (FF)
  Requirement:          3.750ns
  Data Path Delay:      4.189ns (Levels of Logic = 6)
  Clock Path Skew:      -0.053ns
  Source Clock:         system_i/proc_clk_s rising at 3.750ns
  Destination Clock:    system_i/apu_fpu_clk_s rising at 7.500ns
  Clock Uncertainty:    0.523ns

  Clock Uncertainty:          0.523ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.311ns
    Phase Error (PE):           0.367ns

  Maximum Data Path: system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/rs_fir_l1[1].r to system_i/apu_fpu_0/
apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_state_2
    Location             Delay type         Delay(ns)  Physical
Resource
                                                       Logical
Resource(s)
    -------------------------------------------------
-------------------
    SLICE_X28Y201.YQ     Tcko                  0.307   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/instruction(31)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/rs_fir_l1[1].r
    SLICE_X34Y190.F1     net (fanout=5)        1.165   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/instruction(30)
    SLICE_X34Y190.COUT   Topcyf                0.491   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc1_subchain(1)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_dec_prod_2_and00001
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc0_cch[0].cmux
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc1_cch[1].cmux
    SLICE_X34Y191.CIN    net (fanout=1)        0.000   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc1_subchain(1)
    SLICE_X34Y191.COUT   Tbyp                  0.076   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc2_subchain(1)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc1_cch[0].cmux
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc2_cch[1].cmux
    SLICE_X34Y192.CIN    net (fanout=1)        0.000   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc2_subchain(1)
    SLICE_X34Y192.XB     Tcinxb                0.339   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_dec_chain(3)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_idc2_cch[0].cmux
    SLICE_X37Y193.G4     net (fanout=6)        0.724   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_dec_chain(2)
    SLICE_X37Y193.Y      Tilo                  0.165   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_0_mux0001_map12
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_2_mux000125_sw0
    SLICE_X36Y196.G4     net (fanout=1)        0.438   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/n4862
    SLICE_X36Y196.Y      Tilo                  0.166   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_state(2)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_2_mux000125
    SLICE_X36Y196.F4     net (fanout=1)        0.135   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_2_mux0001_map11
    SLICE_X36Y196.CLK    Tfck                  0.183   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_state(2)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_state_2_mux000176
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_state_2
    -------------------------------------------------
---------------------------
    Total                                      4.189ns (1.727ns logic,
2.462ns route)
                                                       (41.2% logic,
58.8% route)

--------------------------------------------------------------------------------
Hold Violations: TS_system_i_dcm_0_dcm_0_CLKFX_BUF = PERIOD
TIMEGRP         "system_i_dcm_0_dcm_0_CLKFX_BUF" TS_sys_clk_pin /
1.33333333 HIGH 50%;
--------------------------------------------------------------------------------
Hold Violation:         -0.083ns (requirement - (clock path skew +
uncertainty - data path))
  Source:               system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/rs_fir_l1[30].r (FF)
  Destination:          system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/fpu_fetch_id_class.fpu_maj (FF)
  Requirement:          0.000ns
  Data Path Delay:      0.454ns (Levels of Logic = 1)
  Positive Clock Path Skew: 0.014ns
  Source Clock:         system_i/proc_clk_s rising at 3.750ns
  Destination Clock:    system_i/apu_fpu_clk_s rising at 7.500ns
  Clock Uncertainty:    0.523ns

  Clock Uncertainty:          0.523ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.311ns
    Phase Error (PE):           0.367ns

  Maximum Data Path: system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/rs_fir_l1[30].r to system_i/apu_fpu_0/
apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_id_class.fpu_maj
    Location             Delay type         Delay(ns)  Physical
Resource
                                                       Logical
Resource(s)
    -------------------------------------------------
-------------------
    SLICE_X28Y200.XQ     Tcko                  0.283   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/instruction(1)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/rs_fir_l1[30].r
    SLICE_X29Y200.F4     net (fanout=3)        0.275   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/instruction(1)
    SLICE_X29Y200.CLK    Tckf        (-Th)     0.104   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_id_class.fpu_maj
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_if_fpu_maj1
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_id_class.fpu_maj
    -------------------------------------------------
---------------------------
    Total                                      0.454ns (0.179ns logic,
0.275ns route)
                                                       (39.4% logic,
60.6% route)
--------------------------------------------------------------------------------
Hold Violation:         -0.039ns (requirement - (clock path skew +
uncertainty - data path))
  Source:               system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/rs_fir_l1[26].r (FF)
  Destination:          system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/fpu_fetch_id_class.fpu_maj (FF)
  Requirement:          0.000ns
  Data Path Delay:      0.515ns (Levels of Logic = 1)
  Positive Clock Path Skew: 0.031ns
  Source Clock:         system_i/proc_clk_s rising at 3.750ns
  Destination Clock:    system_i/apu_fpu_clk_s rising at 7.500ns
  Clock Uncertainty:    0.523ns

  Clock Uncertainty:          0.523ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.311ns
    Phase Error (PE):           0.367ns

  Maximum Data Path: system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/rs_fir_l1[26].r to system_i/apu_fpu_0/
apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_id_class.fpu_maj
    Location             Delay type         Delay(ns)  Physical
Resource
                                                       Logical
Resource(s)
    -------------------------------------------------
-------------------
    SLICE_X30Y200.XQ     Tcko                  0.283   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/instruction(5)
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/rs_fir_l1[26].r
    SLICE_X29Y200.F3     net (fanout=9)        0.336   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/instruction(5)
    SLICE_X29Y200.CLK    Tckf        (-Th)     0.104   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_id_class.fpu_maj
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_fetch_if_fpu_maj1
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_fetch_id_class.fpu_maj
    -------------------------------------------------
---------------------------
    Total                                      0.515ns (0.179ns logic,
0.336ns route)
                                                       (34.8% logic,
65.2% route)
--------------------------------------------------------------------------------


================================================================================
DESIGN 1 with DDR2 (proc_clk_s)
================================================================================
Timing constraint: TS_system_i_dcm_1_dcm_1_CLKFX_BUF = PERIOD
TIMEGRP
"system_i_dcm_1_dcm_1_CLKFX_BUF"
TS_system_i_dcm_0_dcm_0_CLK2X_BUF /
1.33333333 HIGH 50%;

 1029 items analyzed, 34 timing errors detected. (34 setup errors, 0
hold errors)
 Minimum period is   5.958ns.
--------------------------------------------------------------------------------
Slack:                  -0.736ns (requirement - (data path - clock
path skew + uncertainty))
  Source:               system_i/reset_block/reset_block/
Rstc405resetcore (FF)
  Destination:          system_i/ppc405_0/ppc405_0/PPC405_ADV_i (CPU)
  Requirement:          1.250ns
  Data Path Delay:      1.528ns (Levels of Logic = 0)
  Clock Path Skew:      -0.108ns
  Source Clock:         system_i/sys_clk_s rising at 10.000ns
  Destination Clock:    system_i/proc_clk_s rising at 11.250ns
  Clock Uncertainty:    0.350ns

  Clock Uncertainty:          0.350ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.236ns
    Phase Error (PE):           0.231ns

  Maximum Data Path: system_i/reset_block/reset_block/Rstc405resetcore
to system_i/ppc405_0/ppc405_0/PPC405_ADV_i
    Location                         Delay type         Delay(ns)
Physical Resource
 
Logical Resource(s)
    -------------------------------------------------------------
-------------------
    SLICE_X19Y169.XQ                 Tcko                  0.291
system_i/RSTC405RESETCORE
 
system_i/reset_block/reset_block/Rstc405resetcore
    PPC405_ADV_X0Y1.RSTC405RESETCORE net (fanout=1)        0.437
system_i/RSTC405RESETCORE
    PPC405_ADV_X0Y1.CPMC405CLOCK     Tppcdck_RSTCORE       0.800
system_i/ppc405_0/ppc405_0/PPC405_ADV_i
 
system_i/ppc405_0/ppc405_0/PPC405_ADV_i
    -------------------------------------------------------------
---------------------------
    Total                                                  1.528ns
(1.091ns logic, 0.437ns route)
 
(71.4% logic, 28.6% route)

--------------------------------------------------------------------------------
Slack:                  -0.701ns (requirement - (data path - clock
path skew + uncertainty))
  Source:               system_i/reset_block/reset_block/
Rstc405resetchip (FF)
  Destination:          system_i/ppc405_0/ppc405_0/PPC405_ADV_i (CPU)
  Requirement:          1.250ns
  Data Path Delay:      1.499ns (Levels of Logic = 0)
  Clock Path Skew:      -0.102ns
  Source Clock:         system_i/sys_clk_s rising at 10.000ns
  Destination Clock:    system_i/proc_clk_s rising at 11.250ns
  Clock Uncertainty:    0.350ns

  Clock Uncertainty:          0.350ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.236ns
    Phase Error (PE):           0.231ns

  Maximum Data Path: system_i/reset_block/reset_block/Rstc405resetchip
to system_i/ppc405_0/ppc405_0/PPC405_ADV_i
    Location                         Delay type         Delay(ns)
Physical Resource
 
Logical Resource(s)
    -------------------------------------------------------------
-------------------
    SLICE_X19Y172.YQ                 Tcko                  0.291
system_i/RSTC405RESETCHIP
 
system_i/reset_block/reset_block/Rstc405resetchip
    PPC405_ADV_X0Y1.RSTC405RESETCHIP net (fanout=1)        0.558
system_i/RSTC405RESETCHIP
    PPC405_ADV_X0Y1.CPMC405CLOCK     Tppcdck_RSTCHIP       0.650
system_i/ppc405_0/ppc405_0/PPC405_ADV_i
 
system_i/ppc405_0/ppc405_0/PPC405_ADV_i
    -------------------------------------------------------------
---------------------------
    Total                                                  1.499ns
(0.941ns logic, 0.558ns route)
 
(62.8% logic, 37.2% route)

--------------------------------------------------------------------------------
Slack:                  -0.664ns (requirement - (data path - clock
path skew + uncertainty))
  Source:               system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/fpu_ldst_store_phase2 (FF)
  Destination:          system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/rs_ardr_l1[29].r (FF)
  Requirement:          3.750ns
  Data Path Delay:      3.818ns (Levels of Logic = 2)
  Clock Path Skew:      -0.256ns
  Source Clock:         system_i/apu_fpu_clk_s rising at 0.000ns
  Destination Clock:    system_i/proc_clk_s rising at 3.750ns
  Clock Uncertainty:    0.340ns

  Clock Uncertainty:          0.340ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.311ns
    Phase Error (PE):           0.184ns

  Maximum Data Path: system_i/apu_fpu_0/apu_fpu_0/
gen_apu_fpu_sp_full.netlist/fpu_ldst_store_phase2 to system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/rs_ardr_l1[29].r
    Location             Delay type         Delay(ns)  Physical
Resource
                                                       Logical
Resource(s)
    -------------------------------------------------
-------------------
    SLICE_X29Y204.YQ     Tcko                  0.291   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_ldst_store_phase2
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_ldst_store_phase2
    SLICE_X29Y204.F1     net (fanout=36)       0.678   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_ldst_store_phase2
    SLICE_X29Y204.X      Tilo                  0.165   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_ldst_store_phase2
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_ldst_use_direct1
    SLICE_X51Y202.BX     net (fanout=32)       2.259   system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/fpu_ldst_use_direct
    SLICE_X51Y202.CLK    Tdick                 0.425   system_i/
fcb_v10_0_FCMAPURESULT<2>
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/
fpu_ldst_st_sngl.sdm_m5.mm[29].cmux
                                                       system_i/
apu_fpu_0/apu_fpu_0/gen_apu_fpu_sp_full.netlist/rs_ardr_l1[29].r
    -------------------------------------------------
---------------------------
    Total                                      3.818ns (0.881ns logic,
2.937ns route)
                                                       (23.1% logic,
76.9% route)

--------------------------------------------------------------------------------


================================================================================
DESIGN 2 with no DDR2 (proc_clk_s)
================================================================================
Timing constraint: TS_system_i_dcm_0_dcm_0_CLKFX_BUF = PERIOD
TIMEGRP
"system_i_dcm_0_dcm_0_CLKFX_BUF" TS_sys_clk_pin / 2.66666667 HIGH 50%;

 3 items analyzed, 3 timing errors detected. (3 setup errors, 0 hold
errors)
 Minimum period is   5.438ns.
--------------------------------------------------------------------------------
Slack:                  -0.562ns (requirement - (data path - clock
path skew + uncertainty))
  Source:               system_i/reset_block/reset_block/
Rstc405resetcore (FF)
  Destination:          system_i/ppc405_0/ppc405_0/PPC405_ADV_i (CPU)
  Requirement:          1.250ns
  Data Path Delay:      1.514ns (Levels of Logic = 0)
  Clock Path Skew:      -0.040ns
  Source Clock:         system_i/plb_bram_if_cntlr_1_port_BRAM_Clk
rising at 10.000ns
  Destination Clock:    system_i/proc_clk_s rising at 11.250ns
  Clock Uncertainty:    0.258ns

  Clock Uncertainty:          0.258ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.235ns
    Phase Error (PE):           0.140ns

  Maximum Data Path: system_i/reset_block/reset_block/Rstc405resetcore
to system_i/ppc405_0/ppc405_0/PPC405_ADV_i
    Location                         Delay type         Delay(ns)
Physical Resource
 
Logical Resource(s)
    -------------------------------------------------------------
-------------------
    SLICE_X18Y74.XQ                  Tcko                  0.307
system_i/RSTC405RESETCORE
 
system_i/reset_block/reset_block/Rstc405resetcore
    PPC405_ADV_X0Y0.RSTC405RESETCORE net (fanout=1)        0.407
system_i/RSTC405RESETCORE
    PPC405_ADV_X0Y0.CPMC405CLOCK     Tppcdck_RSTCORE       0.800
system_i/ppc405_0/ppc405_0/PPC405_ADV_i
 
system_i/ppc405_0/ppc405_0/PPC405_ADV_i
    -------------------------------------------------------------
---------------------------
    Total                                                  1.514ns
(1.107ns logic, 0.407ns route)
 
(73.1% logic, 26.9% route)

--------------------------------------------------------------------------------
Slack:                  -0.426ns (requirement - (data path - clock
path skew + uncertainty))
  Source:               system_i/reset_block/reset_block/
Rstc405resetsys (FF)
  Destination:          system_i/ppc405_0/ppc405_0/PPC405_ADV_i (CPU)
  Requirement:          1.250ns
  Data Path Delay:      1.378ns (Levels of Logic = 0)
  Clock Path Skew:      -0.040ns
  Source Clock:         system_i/plb_bram_if_cntlr_1_port_BRAM_Clk
rising at 10.000ns
  Destination Clock:    system_i/proc_clk_s rising at 11.250ns
  Clock Uncertainty:    0.258ns

  Clock Uncertainty:          0.258ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.235ns
    Phase Error (PE):           0.140ns

  Maximum Data Path: system_i/reset_block/reset_block/Rstc405resetsys
to system_i/ppc405_0/ppc405_0/PPC405_ADV_i
    Location                        Delay type         Delay(ns)
Physical Resource
 
Logical Resource(s)
    ------------------------------------------------------------
-------------------
    SLICE_X19Y74.YQ                 Tcko                  0.291
system_i/RSTC405RESETSYS
 
system_i/reset_block/reset_block/Rstc405resetsys
    PPC405_ADV_X0Y0.RSTC405RESETSYS net (fanout=1)        0.437
system_i/RSTC405RESETSYS
    PPC405_ADV_X0Y0.CPMC405CLOCK    Tppcdck_RSTSYS        0.650
system_i/ppc405_0/ppc405_0/PPC405_ADV_i
 
system_i/ppc405_0/ppc405_0/PPC405_ADV_i
    ------------------------------------------------------------
---------------------------
    Total                                                 1.378ns
(0.941ns logic, 0.437ns route)
 
(68.3% logic, 31.7% route)

--------------------------------------------------------------------------------
Slack:                  -0.426ns (requirement - (data path - clock
path skew + uncertainty))
  Source:               system_i/reset_block/reset_block/
Rstc405resetchip (FF)
  Destination:          system_i/ppc405_0/ppc405_0/PPC405_ADV_i (CPU)
  Requirement:          1.250ns
  Data Path Delay:      1.378ns (Levels of Logic = 0)
  Clock Path Skew:      -0.040ns
  Source Clock:         system_i/plb_bram_if_cntlr_1_port_BRAM_Clk
rising at 10.000ns
  Destination Clock:    system_i/proc_clk_s rising at 11.250ns
  Clock Uncertainty:    0.258ns

  Clock Uncertainty:          0.258ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.235ns
    Phase Error (PE):           0.140ns

  Maximum Data Path: system_i/reset_block/reset_block/Rstc405resetchip
to system_i/ppc405_0/ppc405_0/PPC405_ADV_i
    Location                         Delay type         Delay(ns)
Physical Resource
 
Logical Resource(s)
    -------------------------------------------------------------
-------------------
    SLICE_X19Y75.XQ                  Tcko                  0.291
system_i/RSTC405RESETCHIP
 
system_i/reset_block/reset_block/Rstc405resetchip
    PPC405_ADV_X0Y0.RSTC405RESETCHIP net (fanout=1)        0.437
system_i/RSTC405RESETCHIP
    PPC405_ADV_X0Y0.CPMC405CLOCK     Tppcdck_RSTCHIP       0.650
system_i/ppc405_0/ppc405_0/PPC405_ADV_i
 
system_i/ppc405_0/ppc405_0/PPC405_ADV_i
    -------------------------------------------------------------
---------------------------
    Total                                                  1.378ns
(0.941ns logic, 0.437ns route)
 
(68.3% logic, 31.7% route)

--------------------------------------------------------------------------------


Article: 117906
Subject: Re: How do I use the Xilinx USB download cable for testing?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 13 Apr 2007 09:04:52 +0200
Links: << >>  << T >>  << A >>
"IEEE member" <bkfross@ieee.org> writes:


> shouldn't be too much trouble to come up with a simple example to
> read and write registers in your design via JTAG.  For details on
> attaching logic to the BSCAN interface, refer to

I've done this with some Altera parts. Added my own JTAG accessible
register which I've used to program an external microcontroller via
the FPGA. I created a SVF file to do the programming so I could use
mostly any JTAG programming software (e.g. Impact)

Petter

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 117907
Subject: Are there Quartus II Web Edition limitations?
From: "Maik Ritter" <maik@rittersoft.de>
Date: 13 Apr 2007 00:20:40 -0700
Links: << >>  << T >>  << A >>
Hello!

I have a simple question: Are there any limitations to the Quartus II
software when I use a web edition liscence? (v 7.0)

I ask because I am not able to find the correct configuration
controller (EPM7128AE) in the pulldown menu when I try to convert
my .sof file into a .jic file.

I have a Stratix EP1S10F780C6ES FPGA with the mentioned configuration
controller on a NIOS development kit and try to save my configuration
permanently in the configuration controller. From the Quartus II help
system I understand, that I have to build a .jic file. When I try to
do so, I go to the "Convert Programming Files" tab, and fill in the
required informations. But I can't chose my configuration controller
in any menu. So neither I am to stupid to convert my file or the
software I use is limited and does not offer all configuration
devices.

Can someone help me to solve this issue?

Thanks
Maik


Article: 117908
Subject: Re: Spartan 3E Not enough block ram.
From: "Ken Soon" <csoon@xilinx.com>
Date: Fri, 13 Apr 2007 15:58:16 +0800
Links: << >>  << T >>  << A >>
> Adding output registers is simple...
>
> if rising_edge(clk) then
>    memout_d1 <= memout;
>    memout_d2 <= memout_d1;
>    memout_d3 <= memout_d2;
>    ...
> end if;
>
> You could add a generic port to your memory template to automatically
> generate these delays to keep your upper-level HDL clean.
>
Hmm...
I dun suppose you mean by this way? :
architecture rtl of dp2_bram is
type     mem_array_type    is array (0 to (mem_size - 1)) of
std_logic_vector((data_width - 1) downto 0);
signal   mem_array         :  mem_array_type;
attribute   ram_style      :  string;
attribute   ram_style      of mem_array : signal is "pipe_distributed";
signal       dout2 :  std_logic_vector((data_width - 1) downto 0);
signal  dout3 :  std_logic_vector((data_width - 1) downto 0);
signal   din2 :  std_logic_vector((data_width - 1) downto 0);
signal  din3 : std_logic_vector((data_width - 1) downto 0);

begin
   process (wr_clk)
   begin
      if (wr_clk'event and wr_clk = '1') then
         if (ce = '1') then
            if (wr_en = '1') then
     din2 <= din;
     din3 <= din2;
               mem_array(conv_integer('0' & wr_addr)) <= din3;
            end if;
         end if;
      end if;
   end process;

   process (rd_clk)
   begin
      if (rd_clk'event and rd_clk = '1') then
         if (ce = '1') then
            if (rd_en = '1') then
               dout3 <= mem_array(conv_integer('0' & rd_addr));
     dout2 <= dout3;
     dout <= dout2;
            end if;
         end if;
      end if;
   end process;

end rtl;

Well anyway after doing this... my implement design repeated itself for four
times, taking 2 hours of my time.
And then still having about the same timing constraint.

Oh yah, I went to use the FPGA editor. I found that this time, luckily, the
3 timing constraints all came from one CLB, so I can easily just focus on
this CLb.  I thought of shifting up the CLB closer to its sources/
destinations and thereby shortening the route. But then... the timing delays
increased and subsequent shifting did not even change the timing constraint
by a bit not matter where i shift above the original position.
Another engineer told me that it could have help as the route could have
buffers which would have delay the signals so I had hope that it would work
but alas it didn't.

Now I wondering if my adding of the register levels is wrong. Well, I should
hope that it is wrong huh, would mean still got chance...



Article: 117909
Subject: Re: Please HELP: timing problems on Virtex-4FX
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Fri, 13 Apr 2007 09:58:26 +0100
Links: << >>  << T >>  << A >>
Hi Dmitriy,

> I also implemented a very basic design with only a few components:
> CPU, PLB BRAM, and OPB RS232. I changed the CPU frequency to 266.67
> MHz by only modifying CLKFX on dcm_0 (this one only has a single DCM
> since no DDR2). I changed CLKFX to be M=8 and D=3 (instead of the
> original M=3, D=1 for 300 MHz). Even this basic design still fails
> timing! I have pasted the failing path for this design as well (see
> below).

Thanks, that's very useful. It's clear that the failing paths are inside the 
apu_fpu core.

> Do you have a suggestion on how I should configure the DCMs for a
> 266-133 CPU-FPU ratio? Even a working basic design, without any memory
> (like DDR2) would help.

Well according to the report you attached, the timing analyser believes that 
the clocks are properly aligned, and that's good enough for me. However, you 
can see that the "clock uncertainty" is pretty high at >0.5ns - that's more 
than 10% of the cycle budget. However, this alone doesn't explain why the 
design is failing timing.

> These frequencies are within the limits and I
> am sure Xilinx must have tested this exact configuration to find the
> maximum allowable frequency (which is 275 MHz for the CPU -11 grade
> and 137.5 MHz for the FPU).

Not this exact configuration, but it certainly runs at 275 CPU : 137.5 FPU 
in V4FX-11. I know this, because I'm the guy who design, implemented and 
tested this core. :)

> If you have any suggestions here, I will try them.

Looking at the details of the report, there are a couple of things I 
wouldn't expect. Firstly there's a massive net delay up front which suggests 
that the fetch-stage instruction register is getting placed sub-optimally. 
Secondly, there's at least one extra level of logic more than there should 
be on this critical path. The fact that the offending net names are suffixed 
with "_mapNN" suggests that the mapper has rearranged some of this logic and 
managed to make it worse. I've seen similar happenings before.

Therefore... what options are you passing to MAP? In case you didn't know, 
there is a .opt file in your EDK project's /etc directory that specifies 
this. By default, it does *not* use timing-driven mapping, which is highly 
recommended. There are a few other options which may help or hinder you 
here: -global_opt and -logic_opt are the ones that spring to mind. Just add 
(or remove) the options in the .opt file under the "Program map" heading, 
one option per line.

I know there is a script called "Xplorer" which will try out these different 
options for you automatically.  Seems to me like an admission that the tools 
don't work properly, but it's not just FPGA tools that exhibit this sort of 
unpredicable speed-optimization-may-slow-things-down problem - C compilers 
are just as bad! But if you get desparate, you could try that.

Once again, I hope you can get this sorted soon...

Cheers,

         -Ben- 



Article: 117910
Subject: Re: Are there Quartus II Web Edition limitations?
From: "PeterK" <meltyb@hotmail.com>
Date: Fri, 13 Apr 2007 12:15:41 +0100
Links: << >>  << T >>  << A >>

"Maik Ritter" <maik@rittersoft.de> wrote in message 
news:1176448840.200861.296710@y5g2000hsa.googlegroups.com...
> Hello!
>
> I have a simple question: Are there any limitations to the Quartus II
> software when I use a web edition liscence? (v 7.0)
>
> I ask because I am not able to find the correct configuration
> controller (EPM7128AE) in the pulldown menu when I try to convert
> my .sof file into a .jic file.
>
> I have a Stratix EP1S10F780C6ES FPGA with the mentioned configuration
> controller on a NIOS development kit and try to save my configuration
> permanently in the configuration controller. From the Quartus II help
> system I understand, that I have to build a .jic file. When I try to
> do so, I go to the "Convert Programming Files" tab, and fill in the
> required informations. But I can't chose my configuration controller
> in any menu. So neither I am to stupid to convert my file or the
> software I use is limited and does not offer all configuration
> devices.
>
> Can someone help me to solve this issue?
>
> Thanks
> Maik
>

I'm a complete beginner but I don't think that EPM7128AE is a configuration 
controller. Its a MAX7000A series PLD. The configuration controllers have 
numbers like EPCS64N. Your code needs to be loaded from somewhere else.

Peter 



Article: 117911
Subject: Re: SETUP & HOLD time confusion
From: "Newman" <newman5382@yahoo.com>
Date: 13 Apr 2007 04:48:05 -0700
Links: << >>  << T >>  << A >>
On Apr 12, 10:34 pm, "Peter Alfke" <a...@sbcglobal.net> wrote:
> No, no, no. Let's not make a bad thing even worse.
>
> I am ashamed that a Xilinx document publishes the above quoted
> nonsense.
> But let's at least look at the basics:
> Set-up time and hold-time are both input timing requirements.
> "3 ns set-up time" means, the new data must be there at least 3 ns
> before the clock edge, in order to be guaranted to be captured in the
> flip-flop. (like the airline says: you must be there one hour before
> departure)
> If data arrives later, it might actually make it, but there is no
> guarantee.
> A positive hold-time requirement (very rare and always bad!) means
> that the data being clocked in must actually linger on the D pin (for
> the specified positive hold time) beyond the clock edge. Bad
> requirement, since it is often very hard to live with. That's why most
> good parts specify "zero hold time", which means, you can take away
> the data right at the clock edge. In reality even a bit earlier, but
> that would have to be specified as a negative hold-time value, and few
> data sheets do.
> In other words, D must be stable from as early as a set-up time before
> the clock, to as late as a (positive) hold time after the clock, but
> most hold times are specified as 0.
> If you change D within this required timing window, the flip-flop will
> make the decision for you, whether it catches the early or the later
> data, but it usually catches a clean 0 or 1. If you change data at a
> very narrow "bulls-eye" point in time, then the flip-flop can indicate
> its displeasure by having an unpredictable output delay, the infamous
> metastable delay.
> I do not have the foggiest idea what the stupid sentence in your quote
> means, but it deserves to be eradicated and translated into English.
> Let me inquire.
> You obviously hit a sensitive nerve with me...
> Peter Alfke
>
> On Apr 12, 6:02 pm, "Newman" <newman5...@yahoo.com> wrote:
>
>
>
> > On Apr 12, 2:31 pm, "M. Hamed" <mhs...@gmail.com> wrote:
>
> > > In the Xilinx Synthesis and Simulation Design Guide there is this
> > > phrase:
>
> > > "While Xilinx data sheets report that there are zero hold times on the
> > > internal registers and I/O registers with the default delay and using
> > > a global clock buffer, it is still possible to receive a $hold
> > > violation from the simulator. This $hold violation is really a $setup
> > > violation on the register. However, in order to get an accurate
> > > representation of the CLB delays, part of the setup time must be
> > > modeled as a hold time."
>
> > > Can somebody put some more explanation to this phrase? I understand
> > > how the setup/hold window can be shifted back and forth by adding
> > > delay to the data path but I dont understand why the need for modeling
> > > part of the setup time as hold time, and how to properly fix hold time
> > > violations.
>
> > > Thank you.
> > > /MHS
>
> > Here is a stab at it.
> > The min propagation delay from a flip flop to another flip flop plus
> > the global clock uncertainty is more than the hold time of the
> > destination FF. If the propagation delay is continuously increased,
> > first you'll get a setup violation, if increased further... a hold
> > violation, increased further... no violation.  Once one hits the setup
> > violation point and further, the functionality of the device comes
> > into question.
>
> > I believe the answer is to limit the propagation delay with timing
> > constraints.
>
> > Newman- Hide quoted text -
>
> - Show quoted text -

I believe that the Op wanted to know how to alleviate the hold time
violation.
Many times in the post P&R simulation, the cause of a hold violation
is
the same as for a setup violation...  excessive data path propagation
delay from
one flip flop to another.  To get rid of it, one must reduce the
combinational and
routing propagation delay.  If this was not clear, I failed in my
explanation.

Newman


Article: 117912
Subject: No login in uClinux (Petalinux)
From: "Pablo" <pbantunez@gmail.com>
Date: 13 Apr 2007 05:12:34 -0700
Links: << >>  << T >>  << A >>
Is there some method to avoid "login prompt"?. The reason is that I
have designed an application over uClinux and I want that this app run
without introducing any information. Could I edit some inittab file?

Thanks


Article: 117913
Subject: Re: Are there Quartus II Web Edition limitations?
From: "Maik Ritter" <maik@rittersoft.de>
Date: 13 Apr 2007 05:41:18 -0700
Links: << >>  << T >>  << A >>
Thanks for the answer!

I already figured that out. It is just a custom programmed
configuration controller for this dev kit. Now, I know how to programm
the configuration for the FPGA into flash memory. It works through the
web interface this dev kit provides. . . .

Still, I am interested in the question if there are any limitations in
the Quartus II Web Edition software.

Maik


Article: 117914
Subject: PLB Master to communicate with the BRAM
From: "LilacSkin" <lpaulo07@iseb.fr>
Date: 13 Apr 2007 06:03:24 -0700
Links: << >>  << T >>  << A >>
Hi,

I need to make an IPIF PLB MASTER and I have some question about this
purpose,

-what is the IP2IP_Addr bus ?
-why the burst mode (even if is not selected) is automaticaly created
with the IPIF software ?
-what is the "local address bus" which made so many problems ?

Thk very much!


Article: 117915
Subject: Re: Are there Quartus II Web Edition limitations?
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 13 Apr 2007 15:22:26 +0200
Links: << >>  << T >>  << A >>
Maik Ritter wrote:
> Thanks for the answer!
> 
> I already figured that out. It is just a custom programmed
> configuration controller for this dev kit. Now, I know how to programm
> the configuration for the FPGA into flash memory. It works through the
> web interface this dev kit provides. . . .
> 
> Still, I am interested in the question if there are any limitations in
> the Quartus II Web Edition software.
> 
> Maik
> 

(It's easier to follow threads if you quote appropriately - if you want 
to use Google's broken Usenet interface, you have to learn the tricks.)

It's a while since I did any FPGA stuff, but as far as I know, the web 
edition fully supports the whole Max7000 series.  The source code for 
the configuration controller in the EPM7128 is available along with the 
NIOS development kit (although it's easy enough to write your own).  If 
you are thinking about making your own boards, the EPM7128 is a silly 
choice - it's expensive and limited, and completely unnecessary with 
more modern FPGAs.

Article: 117916
Subject: Re: SETUP & HOLD time confusion
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 13 Apr 2007 15:18:15 +0100
Links: << >>  << T >>  << A >>
"Newman" <newman5382@yahoo.com> wrote in message 
news:1176464884.975134.282650@n59g2000hsh.googlegroups.com...
>
> I believe that the Op wanted to know how to alleviate the hold time
> violation.
> Many times in the post P&R simulation, the cause of a hold violation
> is
> the same as for a setup violation...  excessive data path propagation
> delay from
> one flip flop to another.  To get rid of it, one must reduce the
> combinational and
> routing propagation delay.  If this was not clear, I failed in my
> explanation.
>
> Newman
>
To be blunt, no. The OP wanted to understand the barmy paragraph he read. It 
sounds like Peter is on a mission to get that fixed.
In general a FF hold time violation is caused by excessive _clock_ path 
propagation to the FF in question. Fortunately, only a complete numpty would 
clock an FPGA FF with anything but a global clock signal. ;-)
HTH, Syms. 



Article: 117917
Subject: How do I constrain Xilinx to implement multi-cycle paths?
From: "news reader" <newsreader@google.com>
Date: Fri, 13 Apr 2007 22:30:57 +0800
Links: << >>  << T >>  << A >>

Due to RAM access, I calculate data on rising edge while feed into the RAM
on negedge edge of clk_100m_i, which is 100MHz. To me, the delay between
my_data and latching into ram_data is 15ns, while ISE may treat it as 5ns..




reg [3:0] my_stages;
reg [31:0] my_data;

always @(posedge clk_100m_i or negedge rst)
if (!rst)
...
else begin  // one-hot shift register
 my_stages <= {my_stages[2:0], start_pulse};
end
end

always @(posedge clk_100m_i or negedge rst)
if (!rst)
...
else begin
 if (my_stages == 4'b0001)
  my_data <= a * b; // 32-bit multiplier
end
end


always @(negedge clk_100m_i or negedge rst)
if (!rst)
...
else begin
 if (my_stages == 4'b0100)
  ram_data <= my_data; // 16-bit multiplier
end
end






Article: 117918
Subject: Re: SETUP & HOLD time confusion
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 13 Apr 2007 15:35:43 +0100
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message 
news:461f9185_3@x-privat.org...
> "Newman" <newman5382@yahoo.com> wrote in message 
> news:1176464884.975134.282650@n59g2000hsh.googlegroups.com...
>>
>> I believe that the Op wanted to know how to alleviate the hold time
>> violation.
>> Many times in the post P&R simulation, the cause of a hold violation
>> is
>> the same as for a setup violation...  excessive data path propagation
>> delay from
>> one flip flop to another.  To get rid of it, one must reduce the
>> combinational and
>> routing propagation delay.  If this was not clear, I failed in my
>> explanation.
>>
>> Newman
>>
> To be blunt, no. The OP wanted to understand the barmy paragraph he read. 
> It sounds like Peter is on a mission to get that fixed.
> In general a FF hold time violation is caused by excessive _clock_ path 
> propagation to the FF in question. Fortunately, only a complete numpty 
> would clock an FPGA FF with anything but a global clock signal. ;-)
> HTH, Syms.
>
Just to follow up, it's important to realise that IC manufacturers do not 
usually give minimum propogation times for their circuits, just max times. 
This is because, over time, the manufacturing process might improve or 
whatever. The zero hold-time together with a max delay spec. and a clock 
distribution spec. are all you need.
Anyway, I wonder why you are doing post P&R timing checks? The generally 
accepted method is to set timing constraints and let the P&R software take 
care of everything.
HTH, Syms. 



Article: 117919
Subject: JTAG ID code 0xFFFFFFFF
From: "BERT" <callmevc@gmail.com>
Date: 13 Apr 2007 07:40:17 -0700
Links: << >>  << T >>  << A >>
Hi,

I need some help with my Altera Dev Kit (STRATIX DSP S80 Development
Board Rev 1.2).  I no longer seem to be able to program my device. It
was working properly until I started getting the following error:

"Error: Can't configure device. Expected JTAG ID code 0x20070DD for
device 1, but found JTAG ID code 0xFFFFFFFF."

Also, when I use the "Auto Detect" feature of Quartus II Programmer,
I get
"EPS180/_HARDCOPY_FPGA_PROTOTYPE" instead of the actual device name
EP1S80B9C656.

Does this mean that my development kit is toast, or am I missing
something here ? Has anyone seen such an error before ?I would greatly
appreciate any help !!

I am using Altera ByteBlaster II programming cable. Replacing the
cable with a new one doesn't help either.

Thanks,
Vijay.


Article: 117920
Subject: Re: How do I constrain Xilinx to implement multi-cycle paths?
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 13 Apr 2007 15:40:23 +0100
Links: << >>  << T >>  << A >>
"news reader" <newsreader@google.com> wrote in message 
news:evo156$o8t$1@mawar.singnet.com.sg...
>
> Due to RAM access, I calculate data on rising edge while feed into the RAM
> on negedge edge of clk_100m_i, which is 100MHz. To me, the delay between
> my_data and latching into ram_data is 15ns, while ISE may treat it as 
> 5ns..
>
>
>
Dear Mr. Reader
Read the manual? :-)
I suggest you start with the Constraints Guide. Search for 'multi cycle'.
HTH, Syms. 



Article: 117921
Subject: Re: spartan 3e availability
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 13 Apr 2007 07:44:21 -0700
Links: << >>  << T >>  << A >>
emu,

What about 'ships in 24 hours' that you don't like?

Distributors have been squeezed pretty hard by price conscious
customers:  there is no such thing as shelf stock any longer.  It is all
"virtual stock."

Austin

emu wrote:
> On Apr 12, 3:05 pm, Austin Lesea <aus...@xilinx.com> wrote:
>> emu,
>>
>> I went to the Xilinx.com website, did a search on the part number,
>> clicked on the store for NuHorizons, and there is 1 in stock, and ships
>> in 24 hrs.
> 
> Hello Austin,
> went there again, and it says "factory stock". Which is not the same
> as they would really have it in stock.
> Sorry ;-)
> 

Article: 117922
Subject: Re: JTAG ID code 0xFFFFFFFF
From: "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch>
Date: Fri, 13 Apr 2007 16:46:37 +0200
Links: << >>  << T >>  << A >>
you can get that if there's something stuck at one.
Check the cables!
Ben
"BERT" <callmevc@gmail.com> wrote in message 
news:1176475217.521694.315060@n76g2000hsh.googlegroups.com...
> Hi,
>
> I need some help with my Altera Dev Kit (STRATIX DSP S80 Development
> Board Rev 1.2).  I no longer seem to be able to program my device. It
> was working properly until I started getting the following error:
>
> "Error: Can't configure device. Expected JTAG ID code 0x20070DD for
> device 1, but found JTAG ID code 0xFFFFFFFF."
>
> Also, when I use the "Auto Detect" feature of Quartus II Programmer,
> I get
> "EPS180/_HARDCOPY_FPGA_PROTOTYPE" instead of the actual device name
> EP1S80B9C656.
>
> Does this mean that my development kit is toast, or am I missing
> something here ? Has anyone seen such an error before ?I would greatly
> appreciate any help !!
>
> I am using Altera ByteBlaster II programming cable. Replacing the
> cable with a new one doesn't help either.
>
> Thanks,
> Vijay.
> 



Article: 117923
Subject: Re: JTAG ID code 0xFFFFFFFF
From: "BERT" <callmevc@gmail.com>
Date: 13 Apr 2007 08:07:55 -0700
Links: << >>  << T >>  << A >>
On Apr 13, 10:46 am, "Benjamin Todd"
<benjamin.toddREMOVEALLCAPIT...@cernREMOVEALLCAPITALS.ch> wrote:
> you can get that if there's something stuck at one.
> Check the cables!
> Ben"BERT" <callm...@gmail.com> wrote in message
>
> news:1176475217.521694.315060@n76g2000hsh.googlegroups.com...
>
> > Hi,
>
> > I need some help with my Altera Dev Kit (STRATIX DSP S80 Development
> > Board Rev 1.2).  I no longer seem to be able to program my device. It
> > was working properly until I started getting the following error:
>
> > "Error: Can't configure device. Expected JTAG ID code 0x20070DD for
> > device 1, but found JTAG ID code 0xFFFFFFFF."
>
> > Also, when I use the "Auto Detect" feature of Quartus II Programmer,
> > I get
> > "EPS180/_HARDCOPY_FPGA_PROTOTYPE" instead of the actual device name
> > EP1S80B9C656.
>
> > Does this mean that my development kit is toast, or am I missing
> > something here ? Has anyone seen such an error before ?I would greatly
> > appreciate any help !!
>
> > I am using Altera ByteBlaster II programming cable. Replacing the
> > cable with a new one doesn't help either.
>
> > Thanks,
> > Vijay.


Thanks for your help ! I moved to a different computer and now I am
able to program the device, and everything works properly. Very
strange ... My previous computer was a 10-15 year old laptop, and the
parallel-port is probably not working properly.


Article: 117924
Subject: Re: SETUP & HOLD time confusion
From: "Newman" <newman5382@yahoo.com>
Date: 13 Apr 2007 08:08:42 -0700
Links: << >>  << T >>  << A >>
On Apr 13, 10:35 am, "Symon" <symon_bre...@hotmail.com> wrote:
> "Symon" <symon_bre...@hotmail.com> wrote in message
>
> news:461f9185_3@x-privat.org...
>
>
>
> > "Newman" <newman5...@yahoo.com> wrote in message
> >news:1176464884.975134.282650@n59g2000hsh.googlegroups.com...
>
> >> I believe that the Op wanted to know how to alleviate the hold time
> >> violation.
> >> Many times in the post P&R simulation, the cause of a hold violation
> >> is
> >> the same as for a setup violation...  excessive data path propagation
> >> delay from
> >> one flip flop to another.  To get rid of it, one must reduce the
> >> combinational and
> >> routing propagation delay.  If this was not clear, I failed in my
> >> explanation.
>
> >> Newman
>
> > To be blunt, no. The OP wanted to understand the barmy paragraph he read.
> > It sounds like Peter is on a mission to get that fixed.
> > In general a FF hold time violation is caused by excessive _clock_ path
> > propagation to the FF in question. Fortunately, only a complete numpty
> > would clock an FPGA FF with anything but a global clock signal. ;-)
> > HTH, Syms.
>
> Just to follow up, it's important to realise that IC manufacturers do not
> usually give minimum propogation times for their circuits, just max times.
> This is because, over time, the manufacturing process might improve or
> whatever. The zero hold-time together with a max delay spec. and a clock
> distribution spec. are all you need.
> Anyway, I wonder why you are doing post P&R timing checks? The generally
> accepted method is to set timing constraints and let the P&R software take
> care of everything.
> HTH, Syms.- Hide quoted text -
>
> - Show quoted text -

I agree with what you said about timing constraints and global clocks
along with synchronous design practices.  I generally set up the top
level testbench to simulate primary inputs to the FPGA when I do the
top level behavioral simulation.  Static timing is deemed sufficient
for internal timing.
Simulation is a necessary but insufficient for timing.  After
everything is ready to go, I'll do a sanity check with a full timing
simulation mainly for primary input stimulus.  I rarely get a timing
violation, but I cannot say never.  The information I gave is from an
experience I had over ten years ago.  I found that a hold time
violation masqueraded as a too long prop delay.  I just wanted to
share that.  Sorry if it upset you.
I applaud Peter's passion for this board.  He really cares about his
customers.

Newman

Newman




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search