Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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
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. NewmanArticle: 117903
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. NewmanArticle: 117904
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. > > NewmanArticle: 117905
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"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
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 MaikArticle: 117908
> 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
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"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. PeterArticle: 117911
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. NewmanArticle: 117912
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? ThanksArticle: 117913
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. MaikArticle: 117914
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
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
"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
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"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
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
"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
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
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
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
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:
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