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
Kevin, Are you at a relatively high utilization on the part (presumably with logic from something other than the PCI interface)? If you are, one great strategy is to remove all your logic but a stub, and then get the PCI interface to route to perfection. Then you use that result as a guide file (or copy the PCI placement into the UCF file). If this works, then you've just got the tool to do the routing for you. I don't know if it will help here, but the technique works great on Altera designs especially. The idea is to route the critical logic first, but do it while unloading the place and route from having to deal with the uncritical logic. Best of luck. Carl -- Posted from firewall.terabeam.com [216.137.15.2] via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 37701
deerlux wrote: > > I use the following code to initialize the block RAM of SpartanII FPGA as > the handbook of Xilinx: > module MYMEM(clk,we,addr,din,dout); > input clk,we; > input [7:0]din; > output [7:0]dout; > input [8:0]addr; > wire logic0,logic1; > assign logic0=1'b0; > assign logic1=1'b1; > > RAMB4_S8 > ram0(.WE(we),.EN(logic1),.RST(logic0),.CLK(clk),.ADDR(addr),.DI(din),.DO(dou > t)); > // synopsys translate_off > defparam ram0.INIT_00= > 256h'0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF; > defparam ram0.INIT_01= > 256'hFEDCBA9876543210FEDCBA9876543210FEDCBA9876543210FEDCBA9876543210; > // synopsys translate_on > endmodule > But when I implement it using Xilinx Foundation3.1i.It shows INIT_xx > including INIT_00 and INIT_01 not initialized.I use Synopsys FPGA Express to > synthesis. > Who can tell me how to initialize the block RAM? > Thank you! Because you don't synthesize defparams of RAMB_S8 by using translate_on/off, synthesizer seems to have no initialization constructs to get synthesized. Please look at the Synopsys manuals, how to do it. UtkuArticle: 37702
I guess the first step is to check the proper definitions of MIPS and MOPS. As far as I know MIPS stands for Millions of instructions per second and MOPS is millions of operations per second. Now if you have mapped the algorithm on a VLIW/parallel machine, then each 'instruction' has more than one 'operation'. However if the platform is a risc machine then each instruction has just one operation. So in case of parallel machines it would be fair to evaluate through MOPS., while in risc machines MOPS and MIPS both signify the same result.. -MJ AAP3 wrote: > Hi..to all > I wrote some functions for a CDMA receiver and I want to find the number of > MIPS required by each function. How do I calculate it? > and which is more accurate measure, MIPS or MOPS? > More info: > data rate 2Mbps. > system clock 50MHz. > 4 time over sampling. > 16 Spreading factor. > > Thanks.Article: 37703
Hello, Is it possible to check the program in my PLD (Xilinx 3064XL) with an mikrocontroller ? Can I read the program out and generate a checksum ? Or is it only possible with an PC and the program in the PLD to verify ? Thanks Martin.Fischer@fzi.deArticle: 37704
We have been doing a DDR interface and have encountered similar problems. There are some limitations on DCMs in ES silicon specifically. Obtain the errata sheet from your FAE. You will find some reset limitations, jitter specs and multiplication ration issues that may be causing your issues. John Adair Enterpoint Ltd. Unit 4 Malvern Hills Science Park Geraldine Road Malvern Worcestershire United Kingdom www.enterpoint.co.uk The views expressed in this message are those of the writer and not necessarily those of Enterpoint Ltd.. The use of information in this message is without warranty and persons using the information are advised to make their own checks as to it's validity. No responsibility will be accepted for any incorrect, inaccurate or missleading information supplied. David Miller <spam@quartz.net.nz> wrote in message news:3C201C58.2040903@quartz.net.nz... > Hi, > > Here's a problem that does not qualify as kindergarten stuff. > > A DCM in a xc2v1000 engineering sample is behaving oddly. I am using > this DCM to generate and deskew a clock and antiphased clock (0 & 180 > degrees) for a DDR RAM. It is being fed by a 100MHz crystal buffered > with a CY2308 zero-delay clock buffer (ie, a pll.) > > The period of the clock seen at the board is 10 ns - usually. > Occasionally, the clock periods is lengthened by between 2.5 and 3 ns. > The stretch is always in the low half of the cycle. > > What could be causing this? > > Relevant facts: > - Chip is a xc2v1000bg456-4 -ES > - Software is Xilinx Alliance 3.3.08i with the VirtexII device update > files and the bitgen patch applied. > - SelectIO type HSTL class II with DCI is being used > > I used a 1 gigahertz (5 gigasample) oscilloscope to look at this clock > pin, so sampling error isn't it. The oscilloscope showed that sometimes > (perhaps 1 of 4 stretched periods), the clock starts to go high at the > right time, then changes its mind literally half way through the rise > time -- it gets to half way between Vol and Voh (or Vref; this is HSTL) > and then returns to Vol again. between 2.5 and 3 ns later, it does a > proper rising edge. > > I've even tried locking the DCM to different parts of the chip and it > made no difference. > > I've searched the xilinx answers and found no clues. Any suggestions > gratefully received! > > -- > David Miller, BCMS (Hons) | When something disturbs you, it isn't the > Endace Measurement Systems | thing that disturbs you; rather, it is > Mobile: +64-21-704-djm | your judgement of it, and you have the > Fax: +64-21-304-djm | power to change that. -- Marcus Aurelius >Article: 37705
In comp.arch Murali Jayapala <mjayapal@esat.kuleuven.ac.be> wrote: > I guess the first step is to check the proper definitions of MIPS and MOPS. > As far as I know MIPS stands for Millions of instructions per second and MOPS > is millions of operations per second. > Now if you have mapped the algorithm on a VLIW/parallel machine, then each > 'instruction' has more than one 'operation'. However if the platform is a > risc machine then each instruction has just one operation. So in case of Wrong - consider any SIMD instructions (practicly all risc processors have them these days) or for that matter, muladd. > parallel machines it would be fair to evaluate through MOPS., while in risc > machines MOPS and MIPS both signify the same result.. Well... most dsp processors advertise both, esp as they do have muladds and similar... > -MJ > AAP3 wrote: >> Hi..to all >> I wrote some functions for a CDMA receiver and I want to find the number of >> MIPS required by each function. How do I calculate it? >> and which is more accurate measure, MIPS or MOPS? >> More info: >> data rate 2Mbps. >> system clock 50MHz. >> 4 time over sampling. >> 16 Spreading factor. >> >> Thanks. -- Sander +++ Out of cheese error +++Article: 37706
I originally posted this yesterday on google groups, but I'm not seeing it on my home news server. In case it is not visible to all, I'm reposting. Hello All, My company is currently comparing 66MHz PCI core solutions from Xilinx and Altera, as well as debating using a home-spun core. One issue I've come upon is the PCI requirement for a MAX clock-to-out time of 6 ns and MIN clock-to-out time of 2 ns. Both the Xilinx ISE and Altera Quartus II tools seem very helpful in supplying MAX (worst-case) Tco times, but I don't see any info on best-case times. Apparently the SDF files for back-annotated timing sim have the same worst-case numbers repeated 3 times, resulting in the same simulation regardless of case selection. My question is: how is anyone (FPGA vendors included) guaranteeing a MIN Tco of 2 ns across all conditions and parts if the design tools don't even yield that information? Thank You, Stephen ByrneArticle: 37707
> Wrong - consider any SIMD instructions (practicly all risc processors have > them these days) or for that matter, muladd. > But isnt the granularity of each of the operation in a SIMD instruction smaller than one 'regular' opertation ?. It would be fair to compare operations of similar granularity. In vliw archs, each operation in an instruction have graularity similar to one of regular risc style instruction. While the graularity of one SIMD instruction still has same granularity as the granularity of one regular risc instruction (even though each SIMD might have more than one operation). Isnt this true?? I am still under the impression that this is true.... but I could be wrong. -MJArticle: 37708
My favorite "divide by 3" circuit is to multiply by 85 and then divide by 256. 85 is 0x55. To multiply by 0x55, only 2 adders are required. Input A, Output B = A / 3 t1 = A + (A<<2); -- multiply by 0x05 t2 = t1 + (t1<<4); -- multiply by 0x11 B = t2 >> 8; -- divide by 256 Not quite as elegant as below, but very fast and small. It is useful when the remainder is not required as in the orginal post. Eric Pearson "Carl Brannen" <carl.brannen@terabeam.com> wrote in message news:48a39dc55b77e0cdb6c1f9895bfe4eb6.51709@mygate.mailgate.org... > Let's see how long a VHDL chunk will fit in this forum... > > library IEEE; > use IEEE.std_logic_1164.all; > > -- Divide by 3 circuit example. Uses only 85 LUTs > -- (up to 4-input) to compute the quotient and > -- remainder when a 32-bit input is divided by 3. > -- > -- Designer: Carl Brannen > -- > -- Feel free to modify this circuit and use it in > -- your own designs. I am aware of no patents that > -- it infringes on, but you will have to make your > -- own determination of this. My only request is > -- that you leave a comment to the effect that your > -- knowledge of the algorithm is through me. > -- > -- Synthesize with optimize set for "low", and > -- "area". This circuit is already optimized, > -- the computer will only be waste its time (and likely > -- increase the size and delay of the result) if it > -- tries to optimize further. > -- > -- This code was written in response to this post > -- on the comp.arch.FPGA thread: > -- > -- <<< > -- "I need to implement in an fpga an algorithm that will divide an integer > -- by 3. The dividend length is still to be determined but will be > -- somewhere between 20 and 30 bits, and the divisor is always the number > -- 3. > -- > -- Does anyone know an efficient combinatoric algorithm that can accomplish > -- this? > -- >>> > -- > -- http://www.fpga-faq.com/archives/11400.html#11409 > > entity DIV32_3 is > port ( > CLK: in STD_LOGIC; > AIN: in STD_LOGIC_VECTOR(31 downto 0); > REMOUT: out STD_LOGIC_VECTOR( 1 downto 0); > QOUT: out STD_LOGIC_VECTOR(30 downto 0); > TEST: out STD_LOGIC_VECTOR(53 downto 0) > ); > end DIV32_3; > > architecture DIV32_3_arch of DIV32_3 is > > -- Partial remainders: > signal R1V: STD_LOGIC_VECTOR(15 downto 0); -- 16 LUTs > signal R2V: STD_LOGIC_VECTOR( 7 downto 0); -- 8 LUTs > signal R4V: STD_LOGIC_VECTOR( 3 downto 0); -- 4 LUTs > signal R8V: STD_LOGIC_VECTOR( 1 downto 0); -- 2 LUTs > signal P4V: STD_LOGIC_VECTOR( 1 downto 0); -- 2 LUTs > signal P3V: STD_LOGIC_VECTOR( 1 downto 0); -- 2 LUTs > signal P2V: STD_LOGIC_VECTOR( 1 downto 0); -- 2 LUTs > signal P1V: STD_LOGIC_VECTOR( 1 downto 0); -- 2 LUTs > signal P0V: STD_LOGIC_VECTOR( 1 downto 0); -- 2 LUTs > > -- Rearrangement of partial remainders only: > signal PRV: STD_LOGIC_VECTOR(15 downto 0); -- 16 LUTs > > -- carries internal to blocks: > signal X0V: STD_LOGIC_VECTOR(13 downto 0); -- 14 LUTs > > -- Flip-flop for QOUT: > signal QOUTQ,QOUTD: STD_LOGIC_VECTOR(30 downto 0); -- 31 LUTs > > -- Flip-flop for Remainder: > signal REMQ,REMD: STD_LOGIC_VECTOR( 1 downto 0); > > > -- -- ------- > > -- Total LUT count: -- 85 LUTs (45 slices or 23 CLBs) > > -- Force tool to not "optimize" (i.e. bloat) the design > -- by creating a set of flip-flop outputs. > signal FKD,FKQ: STD_LOGIC_VECTOR(53 downto 0); > > > begin > > -- Scheme for quickest determination of remainder when dividing by 3. > -- Example, 32-bit input, R80 provides the 2-bit remainder result in > -- just 4 stages of 4-input LUTs: > -- > -- AIN > -- 3322 2222 2222 1111 1111 1100 0000 0000 > -- 1098 7654 3210 9876 5432 1098 7654 3210 > -- ---- ---- ---- ---- ---- ---- ---- ---- > -- R17 R16 R15 R14 R13 R12 R11 R10 > -- \ / \ / \ / \ / > -- R23 R22 R21 R20 > -- \ / \ / > -- R41 R40 > -- -----\ /----- > -- R80 > -- > -- Scheme for computing quotients from the above > -- remainder scheme. More partial remainders have > -- to be computed, as compared to the above remainders, > -- these ones are called PRs. > -- > -- The quotient for the highest four bits is computed > -- directly from (no greater than 4-input) LUTs. The > -- lower quotients all require a remainder input. That > -- remainder allows direct computation of the quotient > -- for the high two bits, and a partial remainder needs > -- to be computed to get the lower 2 bits as well. The > -- following diagram suppresses Rxx that aren't used, and > -- only shows how the PRs are calculated. The lowest > -- value in each column gives the Rxx or PRx that computes > -- the partial remainder at that column: > -- > -- AIN > -- 3322 2222 2222 1111 1111 1100 0000 0000 > -- 1098 7654 3210 9876 5432 1098 7654 3210 > -- ---- ---- ---- ---- ---- ---- ---- ---- > -- R17 R15 R13 R11 > -- | | | > -- P4 | R21 | > -- / | | \ | > -- R23 P3 P2 P1 > -- / / | > -- / / P0 > -- /-----/-----/ > -- R41 > -- > -- ---- ---- ---- ---- ---- ---- ---- ---- > -- R17 R23 P4 R41 P3 P2 P0 R8 > -- PR7 PR6 PR5 PR4 PR3 PR2 PR1 PR0 > -- > -- > -- From the above tables, it's clear that the > -- longest computation is that of the quotient > -- at position 0, as would be expected. The > -- number of stages of logic is only 6, and the > -- longest paths are as follows: > -- > -- R17 R16 R15 R14 R13 R12 > -- \ / \ / \ / > -- R23 R22 R21 > -- \ / \ > -- R41 P1 > -- \ / > -- P0 > -- | > -- Remainder[3:2] > -- | > -- Quotient[1:0] > -- > -- > -- In order to make the VHDL shorter, I've packed > -- the remainders into longer STD_LOGIC_VECTORs > -- as follows: > -- R1V <= R17 & R16 & ... R10 > -- R2V <= R23 & R22 & R21 & R20 > -- R4V <= R41 & R40 > -- R8V <= R80 > -- > -- > -- I normally don't like to complicate things any more > -- than they have to, but I hate to have to create all > -- those unnecessary "SEL" assignments. > > -- If Xilinx would support a select statement like this: > -- > -- with AIN(4*I+3 downto 4*I) > -- > -- I wouldn't have to do this this way, but this is the first > -- way to implement this that comes to mind. I guess I could > -- define LUT4s, since none of these are trivial, but that wouldn't > -- port to Altera. > > -- Generate the R1x logic (16 LUTs) > G1: for I in 0 to 7 generate > R1V(I*2 + 0) > <= ((not AIN(4*I+3)) and (not AIN(4*I+2)) and (not AIN(4*I+1)) and ( > AIN(4*I+0))) > or ((not AIN(4*I+3)) and ( AIN(4*I+2)) and (not AIN(4*I+1)) and (not > AIN(4*I+0))) > or ((not AIN(4*I+3)) and ( AIN(4*I+2)) and ( AIN(4*I+1)) and ( > AIN(4*I+0))) > or (( AIN(4*I+3)) and (not AIN(4*I+2)) and ( AIN(4*I+1)) and (not > AIN(4*I+0))) > or (( AIN(4*I+3)) and ( AIN(4*I+2)) and (not AIN(4*I+1)) and ( > AIN(4*I+0))); > R1V(I*2 + 1) > <= ((not AIN(4*I+3)) and (not AIN(4*I+2)) and ( AIN(4*I+1)) and (not > AIN(4*I+0))) > or ((not AIN(4*I+3)) and ( AIN(4*I+2)) and (not AIN(4*I+1)) and ( > AIN(4*I+0))) > or (( AIN(4*I+3)) and (not AIN(4*I+2)) and (not AIN(4*I+1)) and (not > AIN(4*I+0))) > or (( AIN(4*I+3)) and (not AIN(4*I+2)) and ( AIN(4*I+1)) and ( > AIN(4*I+0))) > or (( AIN(4*I+3)) and ( AIN(4*I+2)) and ( AIN(4*I+1)) and (not > AIN(4*I+0))); > end generate; > > -- Generate the R2x logic (8 LUTs) > G2: for I in 0 to 3 generate > R2V(I*2 + 0) > <= ((not R1V(4*I+3)) and (not R1V(4*I+2)) and (not R1V(4*I+1)) and ( > R1V(4*I+0))) > or ((not R1V(4*I+3)) and ( R1V(4*I+2)) and (not R1V(4*I+1)) and (not > R1V(4*I+0))) > or ((not R1V(4*I+3)) and ( R1V(4*I+2)) and ( R1V(4*I+1)) and ( > R1V(4*I+0))) > or (( R1V(4*I+3)) and (not R1V(4*I+2)) and ( R1V(4*I+1)) and (not > R1V(4*I+0))) > or (( R1V(4*I+3)) and ( R1V(4*I+2)) and (not R1V(4*I+1)) and ( > R1V(4*I+0))); > R2V(I*2 + 1) > <= ((not R1V(4*I+3)) and (not R1V(4*I+2)) and ( R1V(4*I+1)) and (not > R1V(4*I+0))) > or ((not R1V(4*I+3)) and ( R1V(4*I+2)) and (not R1V(4*I+1)) and ( > R1V(4*I+0))) > or (( R1V(4*I+3)) and (not R1V(4*I+2)) and (not R1V(4*I+1)) and (not > R1V(4*I+0))) > or (( R1V(4*I+3)) and (not R1V(4*I+2)) and ( R1V(4*I+1)) and ( > R1V(4*I+0))) > or (( R1V(4*I+3)) and ( R1V(4*I+2)) and ( R1V(4*I+1)) and (not > R1V(4*I+0))); > end generate; > > -- Generate the R4x logic (4 LUTs) > G4: for I in 0 to 1 generate > R4V(I*2 + 0) > <= ((not R2V(4*I+3)) and (not R2V(4*I+2)) and (not R2V(4*I+1)) and ( > R2V(4*I+0))) > or ((not R2V(4*I+3)) and ( R2V(4*I+2)) and (not R2V(4*I+1)) and (not > R2V(4*I+0))) > or ((not R2V(4*I+3)) and ( R2V(4*I+2)) and ( R2V(4*I+1)) and ( > R2V(4*I+0))) > or (( R2V(4*I+3)) and (not R2V(4*I+2)) and ( R2V(4*I+1)) and (not > R2V(4*I+0))) > or (( R2V(4*I+3)) and ( R2V(4*I+2)) and (not R2V(4*I+1)) and ( > R2V(4*I+0))); > R4V(I*2 + 1) > <= ((not R2V(4*I+3)) and (not R2V(4*I+2)) and ( R2V(4*I+1)) and (not > R2V(4*I+0))) > or ((not R2V(4*I+3)) and ( R2V(4*I+2)) and (not R2V(4*I+1)) and ( > R2V(4*I+0))) > or (( R2V(4*I+3)) and (not R2V(4*I+2)) and (not R2V(4*I+1)) and (not > R2V(4*I+0))) > or (( R2V(4*I+3)) and (not R2V(4*I+2)) and ( R2V(4*I+1)) and ( > R2V(4*I+0))) > or (( R2V(4*I+3)) and ( R2V(4*I+2)) and ( R2V(4*I+1)) and (not > R2V(4*I+0))); > end generate; > > -- The R80 logic: (2 LUTs) > R8V(0) > <= ((not R4V(3)) and (not R4V(2)) and (not R4V(1)) and ( R4V(0))) > or ((not R4V(3)) and ( R4V(2)) and (not R4V(1)) and (not R4V(0))) > or ((not R4V(3)) and ( R4V(2)) and ( R4V(1)) and ( R4V(0))) > or (( R4V(3)) and (not R4V(2)) and ( R4V(1)) and (not R4V(0))) > or (( R4V(3)) and ( R4V(2)) and (not R4V(1)) and ( R4V(0))); > R8V(1) > <= ((not R4V(3)) and (not R4V(2)) and ( R4V(1)) and (not R4V(0))) > or ((not R4V(3)) and ( R4V(2)) and (not R4V(1)) and ( R4V(0))) > or (( R4V(3)) and (not R4V(2)) and (not R4V(1)) and (not R4V(0))) > or (( R4V(3)) and (not R4V(2)) and ( R4V(1)) and ( R4V(0))) > or (( R4V(3)) and ( R4V(2)) and ( R4V(1)) and (not R4V(0))); > > -- P4 = R23 # R15 (2 LUTs) > P4V(0) > <= ((not R2V(7)) and (not R2V(6)) and (not R1V(11)) and ( R1V(10))) > or ((not R2V(7)) and ( R2V(6)) and (not R1V(11)) and (not R1V(10))) > or ((not R2V(7)) and ( R2V(6)) and ( R1V(11)) and ( R1V(10))) > or (( R2V(7)) and (not R2V(6)) and ( R1V(11)) and (not R1V(10))) > or (( R2V(7)) and ( R2V(6)) and (not R1V(11)) and ( R1V(10))); > P4V(1) > <= ((not R2V(7)) and (not R2V(6)) and ( R1V(11)) and (not R1V(10))) > or ((not R2V(7)) and ( R2V(6)) and (not R1V(11)) and ( R1V(10))) > or (( R2V(7)) and (not R2V(6)) and (not R1V(11)) and (not R1V(10))) > or (( R2V(7)) and (not R2V(6)) and ( R1V(11)) and ( R1V(10))) > or (( R2V(7)) and ( R2V(6)) and ( R1V(11)) and (not R1V(10))); > > -- P3 = R41 # R13 (2 LUTs) > P3V(0) > <= ((not R4V(3)) and (not R4V(2)) and (not R1V(7)) and ( R1V(6))) > or ((not R4V(3)) and ( R4V(2)) and (not R1V(7)) and (not R1V(6))) > or ((not R4V(3)) and ( R4V(2)) and ( R1V(7)) and ( R1V(6))) > or (( R4V(3)) and (not R4V(2)) and ( R1V(7)) and (not R1V(6))) > or (( R4V(3)) and ( R4V(2)) and (not R1V(7)) and ( R1V(6))); > P3V(1) > <= ((not R4V(3)) and (not R4V(2)) and ( R1V(7)) and (not R1V(6))) > or ((not R4V(3)) and ( R4V(2)) and (not R1V(7)) and ( R1V(6))) > or (( R4V(3)) and (not R4V(2)) and (not R1V(7)) and (not R1V(6))) > or (( R4V(3)) and (not R4V(2)) and ( R1V(7)) and ( R1V(6))) > or (( R4V(3)) and ( R4V(2)) and ( R1V(7)) and (not R1V(6))); > > -- P2 = R41 # R21 (2 LUTs) > P2V(0) > <= ((not R4V(3)) and (not R4V(2)) and (not R2V(3)) and ( R2V(2))) > or ((not R4V(3)) and ( R4V(2)) and (not R2V(3)) and (not R2V(2))) > or ((not R4V(3)) and ( R4V(2)) and ( R2V(3)) and ( R2V(2))) > or (( R4V(3)) and (not R4V(2)) and ( R2V(3)) and (not R2V(2))) > or (( R4V(3)) and ( R4V(2)) and (not R2V(3)) and ( R2V(2))); > P2V(1) > <= ((not R4V(3)) and (not R4V(2)) and ( R2V(3)) and (not R2V(2))) > or ((not R4V(3)) and ( R4V(2)) and (not R2V(3)) and ( R2V(2))) > or (( R4V(3)) and (not R4V(2)) and (not R2V(3)) and (not R2V(2))) > or (( R4V(3)) and (not R4V(2)) and ( R2V(3)) and ( R2V(2))) > or (( R4V(3)) and ( R4V(2)) and ( R2V(3)) and (not R2V(2))); > > -- P1 = R11 # R21 (2 LUTs) > P1V(0) > <= ((not R1V(3)) and (not R1V(2)) and (not R2V(3)) and ( R2V(2))) > or ((not R1V(3)) and ( R1V(2)) and (not R2V(3)) and (not R2V(2))) > or ((not R1V(3)) and ( R1V(2)) and ( R2V(3)) and ( R2V(2))) > or (( R1V(3)) and (not R1V(2)) and ( R2V(3)) and (not R2V(2))) > or (( R1V(3)) and ( R1V(2)) and (not R2V(3)) and ( R2V(2))); > P1V(1) > <= ((not R1V(3)) and (not R1V(2)) and ( R2V(3)) and (not R2V(2))) > or ((not R1V(3)) and ( R1V(2)) and (not R2V(3)) and ( R2V(2))) > or (( R1V(3)) and (not R1V(2)) and (not R2V(3)) and (not R2V(2))) > or (( R1V(3)) and (not R1V(2)) and ( R2V(3)) and ( R2V(2))) > or (( R1V(3)) and ( R1V(2)) and ( R2V(3)) and (not R2V(2))); > > -- P0 = R41 # PR1 (2 LUTs) > P0V(0) > <= ((not R4V(3)) and (not R4V(2)) and (not P1V(1)) and ( P1V(0))) > or ((not R4V(3)) and ( R4V(2)) and (not P1V(1)) and (not P1V(0))) > or ((not R4V(3)) and ( R4V(2)) and ( P1V(1)) and ( P1V(0))) > or (( R4V(3)) and (not R4V(2)) and ( P1V(1)) and (not P1V(0))) > or (( R4V(3)) and ( R4V(2)) and (not P1V(1)) and ( P1V(0))); > P0V(1) > <= ((not R4V(3)) and (not R4V(2)) and ( P1V(1)) and (not P1V(0))) > or ((not R4V(3)) and ( R4V(2)) and (not P1V(1)) and ( P1V(0))) > or (( R4V(3)) and (not R4V(2)) and (not P1V(1)) and (not P1V(0))) > or (( R4V(3)) and (not R4V(2)) and ( P1V(1)) and ( P1V(0))) > or (( R4V(3)) and ( R4V(2)) and ( P1V(1)) and (not P1V(0))); > > -- Assemble the partial remainders into the inputs for the quotient > -- calculations: > PRV(15 downto 0) -- Remainder of > <= R1V(15 downto 14) -- R17 AIN[31:28] > & R2V( 7 downto 6) -- R23 AIN[31:24] > & P4V( 1 downto 0) -- P4 AIN[31:20] > & R4V( 3 downto 2) -- R41 AIN[31:16] > & P3V( 1 downto 0) -- P3 AIN[31:12] > & P2V( 1 downto 0) -- P2 AIN[31:8] > & P0V( 1 downto 0) -- P0 AIN[31:4] > & R8V( 1 downto 0); -- R8 AIN[31:0] > > -- The highest quotient block has no remainder coming in, > -- so compute it directly: (3 LUTs) > with AIN(31 downto 28) select > QOUTD(30 downto 28) <= > "000" when "0000" | "0001" | "0010", > "001" when "0011" | "0100" | "0101", > "010" when "0110" | "0111" | "1000", > "011" when "1001" | "1010" | "1011", > "100" when "1100" | "1101" | "1110", > "101" when others; > > -- 0000 00 > -- 0001 00 > -- 0010 00 > > -- 0011 01 > -- 0100 01 > -- 0101 01 > > -- 0110 10 > -- 0111 10 > -- 1000 10 > > -- 1001 11 > -- 1010 11 > -- 1011 11 > > > -- Compute the quotient in blocks of 4 bits > Q: for I in 0 to 6 generate > -- Top two bits are computed directly from the carry-in and AIN > QOUTD(4*I + 2) > <= ((not PRV(2*I+3)) and (not PRV(2*I+2)) and ( AIN(4*I+3)) and ( > AIN(4*I+2))) > or ((not PRV(2*I+3)) and ( PRV(2*I+2)) and (not AIN(4*I+3)) and (not > AIN(4*I+2))) > or ((not PRV(2*I+3)) and ( PRV(2*I+2)) and (not AIN(4*I+3)) and ( > AIN(4*I+2))) > or (( PRV(2*I+3)) and (not PRV(2*I+2)) and (not AIN(4*I+3)) and ( > AIN(4*I+2))) > or (( PRV(2*I+3)) and (not PRV(2*I+2)) and ( AIN(4*I+3)) and (not > AIN(4*I+2))) > or (( PRV(2*I+3)) and (not PRV(2*I+2)) and ( AIN(4*I+3)) and ( > AIN(4*I+2))); > QOUTD(4*I + 3) > <= ((not PRV(2*I+3)) and ( PRV(2*I+2)) and ( AIN(4*I+3)) and (not > AIN(4*I+2))) > or ((not PRV(2*I+3)) and ( PRV(2*I+2)) and ( AIN(4*I+3)) and ( > AIN(4*I+2))) > or (( PRV(2*I+3)) and (not PRV(2*I+2)) and (not AIN(4*I+3)) and (not > AIN(4*I+2))) > or (( PRV(2*I+3)) and (not PRV(2*I+2)) and (not AIN(4*I+3)) and ( > AIN(4*I+2))) > or (( PRV(2*I+3)) and (not PRV(2*I+2)) and ( AIN(4*I+3)) and (not > AIN(4*I+2))) > or (( PRV(2*I+3)) and (not PRV(2*I+2)) and ( AIN(4*I+3)) and ( > AIN(4*I+2))); > -- I need to compute the remainder out of the top two bits for the lower two > bits > X0V(2*I + 0) > <= ((not PRV(2*I+3)) and (not PRV(2*I+2)) and (not AIN(4*I+3)) and ( > AIN(4*I+2))) > or ((not PRV(2*I+3)) and ( PRV(2*I+2)) and (not AIN(4*I+3)) and (not > AIN(4*I+2))) > or ((not PRV(2*I+3)) and ( PRV(2*I+2)) and ( AIN(4*I+3)) and ( > AIN(4*I+2))) > or (( PRV(2*I+3)) and (not PRV(2*I+2)) and ( AIN(4*I+3)) and (not > AIN(4*I+2))) > or (( PRV(2*I+3)) and ( PRV(2*I+2)) and (not AIN(4*I+3)) and ( > AIN(4*I+2))); > X0V(2*I + 1) > <= ((not PRV(2*I+3)) and (not PRV(2*I+2)) and ( AIN(4*I+3)) and (not > AIN(4*I+2))) > or ((not PRV(2*I+3)) and ( PRV(2*I+2)) and (not AIN(4*I+3)) and ( > AIN(4*I+2))) > or (( PRV(2*I+3)) and (not PRV(2*I+2)) and (not AIN(4*I+3)) and (not > AIN(4*I+2))) > or (( PRV(2*I+3)) and (not PRV(2*I+2)) and ( AIN(4*I+3)) and ( > AIN(4*I+2))) > or (( PRV(2*I+3)) and ( PRV(2*I+2)) and ( AIN(4*I+3)) and (not > AIN(4*I+2))); > -- Now I can compute the lowest two bits: > QOUTD(4*I + 0) > <= ((not X0V(2*I+1)) and (not X0V(2*I+0)) and ( AIN(4*I+1)) and ( > AIN(4*I+0))) > or ((not X0V(2*I+1)) and ( X0V(2*I+0)) and (not AIN(4*I+1)) and (not > AIN(4*I+0))) > or ((not X0V(2*I+1)) and ( X0V(2*I+0)) and (not AIN(4*I+1)) and ( > AIN(4*I+0))) > or (( X0V(2*I+1)) and (not X0V(2*I+0)) and (not AIN(4*I+1)) and ( > AIN(4*I+0))) > or (( X0V(2*I+1)) and (not X0V(2*I+0)) and ( AIN(4*I+1)) and (not > AIN(4*I+0))) > or (( X0V(2*I+1)) and (not X0V(2*I+0)) and ( AIN(4*I+1)) and ( > AIN(4*I+0))); > QOUTD(4*I + 1) > <= ((not X0V(2*I+1)) and ( X0V(2*I+0)) and ( AIN(4*I+1)) and (not > AIN(4*I+0))) > or ((not X0V(2*I+1)) and ( X0V(2*I+0)) and ( AIN(4*I+1)) and ( > AIN(4*I+0))) > or (( X0V(2*I+1)) and (not X0V(2*I+0)) and (not AIN(4*I+1)) and (not > AIN(4*I+0))) > or (( X0V(2*I+1)) and (not X0V(2*I+0)) and (not AIN(4*I+1)) and ( > AIN(4*I+0))) > or (( X0V(2*I+1)) and (not X0V(2*I+0)) and ( AIN(4*I+1)) and (not > AIN(4*I+0))) > or (( X0V(2*I+1)) and (not X0V(2*I+0)) and ( AIN(4*I+1)) and ( > AIN(4*I+0))); > end generate; > > > -- The following flip-flop implication of all the partial logic is included > only > -- to prevent the synthesis tool from optimizing out the beautiful logic I've > -- created. > FKD(53 downto 0) <= R1V & R2V & R4V & R8V & P4V & P3V & P2V & P1V & P0V & X0V; > > -- Register the remainder > REMD(1 downto 0) <= PRV(1 downto 0); > > process (CLK) > begin > if CLK'event and CLK='1' then > FKQ <= FKD; > QOUTQ <= QOUTD; > REMQ <= REMD; > end if; > end process; > > > -- Output assignment: > > REMOUT <= REMQ(1 downto 0); > QOUT <= QOUTQ(30 downto 0); > > -- Test output (unused, but included for synthesis restriction). > TEST <= FKQ; > > end DIV32_3_arch; > > > -- > Posted from firewall.terabeam.com [216.137.15.2] > via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 37709
Yes, there seems to be some problem with Google Groups. Even my postings were just visible on Google Groups and didn't appear on other news servers. Dunno whats wrong!!!! Regards, Harish http://hdlplanet.tripod.com Kevin Brace wrote: > I know this topic is not directly related to this newsgroup, but I > noticed some postings I made to comp.arch.fpga through Google Groups got > posted on Google Groups' comp.arch.fpga archive, but wasn't there when I > checked my postings through mailgate.org's service > (http://www.mailgate.org). > Anyone else noticed this problem? > > Kevin Brace (don't respond to me directly, respond within the newsgroup)Article: 37710
> The problem with doing it is that it's hard to get the output of the "F" LUT > out of the slice. But it can be done by brining it out the CARRY-OUT. Perhaps I'm missing something, but why can't you send the output of the F-LUT to output X, and the output of the F5-MUX to output F5? Stephen Melnikoff. -- Stephen Melnikoff - s.j.melnikoff@iee.org Electronic, Electrical and Computer Engineering University of Birmingham, Birmingham, UKArticle: 37711
Murali Jayapala wrote: > > Wrong - consider any SIMD instructions (practicly all risc processors have > > them these days) or for that matter, muladd. > > > > But isnt the granularity of each of the operation in a SIMD instruction smaller > than one 'regular' opertation ?. It would be fair to compare operations of similar > granularity. In vliw archs, each operation in an instruction have graularity > similar to one of regular risc style instruction. While the graularity of one SIMD > instruction still has same granularity as the granularity of one regular risc > instruction (even though each SIMD might have more than one operation). Isnt this > true?? I am still under the impression that this is true.... but I could be wrong. Oops sorry about that.. I think I am wrong here. I was thinking of sub-word parallel instructions in SIMD style... -MJArticle: 37712
Hello, What is the difference between Boundary Scan and BIST ? And what can I do with them ? With Boundary Scan I can read out the checksum from an PLD, how can I read the cheksum out with an Mikrocontroller ? Thanks Martin.Fischer@fzi.deArticle: 37713
I would want to use clk_dll to divide a clock by 3, where can I found an example of this ?? Can I also apply some constrain to the clk_dll ?? ThanksArticle: 37714
In my project I've a master clock and a clock derived by it via combinatorial logic, in Synplify I could apply constrain to the first, I also could apply constrain to the second if I select it, my question is what's the System clock that synplify show me together with the other clocks. It'a a problem if it doesn't respect the constrain on the master clock ?? ThanksArticle: 37715
Austin, You say potato, and I say potato. Sounds like we are in agreement? Anything can be well documented, but unfortunately most designs are not. If I see hdl code, at least I can see where it is going, even if it is written badly. In fact, if it is written badly, then I can: not hire the consultant ever again, lay off that engineer, reject the code and get it done right. Nice thing about software is that people have figured out how to manage it, and document it. Not that we have many good examples (Microsoft is the usual bad example, but even here Apple Computer has an equally poor reputation for bad code -- they actually printed t-shirts that said something like "OS7: 7000 bugs and counting"). If I examine a design, from top to bottom, I can make a determination of the quality of the design by examining the hdl code. It is possible, but more difficult to see what is going on in schematic. It is impossible to know what is going on if I need to go look in FPGA Editor (unless I did it). As a technical manager, code review is one tool that should be used to make sure the project is on track, following the rules, and has a higher likelihood of success. Austin Austin Franklin wrote: > > A design that is well architected, self documented, commented, and > reliable is > > more important to many customers. I prefer to throw all of my energies > into > > supporting those designs (in hdl's) which now account for 99% of what is > being > > done out there. > > Well, Austin, that's all well and good...but one can do, in my opinion, an > equally as well documented, if not better documented and certainly a more > reliable design in schematics. When the synthesis tools change, the design > changes. That's hardly reliability. That is, unless you instantiate > everything...but that's hardly synthesis...that's just a netlister. > > I also believe it's erroneous to claim that HDL code is "self documenting", > that's not reality. It takes care and time to correctly document a design. > > If you make the FPGAs big enough and fast enough, synthesis works. If you > make the CPUs fast enough, and have enough memory and disk space, Microsoft > code works. Same thing. I'm not saying it's right or wrong, but it is a > fact. > > Regards, > > AustinArticle: 37716
This is a multi-part message in MIME format. --------------BD37B04DA684C5022DB6EDD2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bryan, FPGA Editor does support routing, but TRACE has a few problems dealing with it.... Also for everyone here, you might also want to try the Directed Routing constraint (which appends it to the ucf or ncf file) Tools > Directed Routing cst.... Dave Bryan wrote: > So lets talk controversial.... > > If Lucent can support hard macros in Epic with hard routing, then why can't > Xilinx. My application requires it and Xilinx doesn't support it in FPGA > editor(which was programmed by the same softies as Epic). Oh, I remember > why they don't support it. Because nobody cares about designs that push the > limitations of FPGAs. Because everybody else that is making designs for > Xilinx parts is still in kindergarten finger painting with verilog and hdl. > Ha, I didn't get my EE degree to be a soft weirdo. Anybody can throw code > together and get poor performance. > > flame away kindergarten kids > > Bryan > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message > news:3C1F8AEC.BFD2E067@xilinx.com... > > This is a friendly and helpful newsgroup, but let's make sure that it does > not > > get abused. > > Lots of textbooks explain how to divide by a power of 2, where the > remainder is, > > and how you sign-extend the MSB. Explaining that is not the purpose of > this > > newsgroup. > > > > Let's use our "bandwidth" for more complex and perhaps controversial > questions > > that are not explained in textbooks and data books. > > > > Peter Alfke, Xilinx Applications > > > > --------------BD37B04DA684C5022DB6EDD2 Content-Type: text/x-vcard; charset=us-ascii; name="dhawke.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Hawke Content-Disposition: attachment; filename="dhawke.vcf" begin:vcard n:;David Hawke tel;cell:(44) 778 875 5002 tel;fax:(44) 1291 621 541 tel;home:(44) 1291 621 655 tel;work:(44) 870 7350 517 x-mozilla-html:FALSE org:Xilinx UK;Northern European Sales version:2.1 email;internet:dhawke@xilinx.com title:Xilinx Field Applications Engineer adr;quoted-printable:;;Benchmark House=0D=0A203 Brooklands Road=0D=0A;Weybridge;Surrey;KT14 ORH;United Kingdom fn:David Hawke end:vcard --------------BD37B04DA684C5022DB6EDD2--Article: 37717
--------------54E62841DE335C4C12624456 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David, The most important errata from the errata sheet for the DCM is to reset it after the part is configured and the clocks are running after a delay. The delay is required because the power supply that runs the delay lines did not power on for a long time until after the part is done configuring. The delay can be seconds if cold, and about 200 ms at room temperature. The recommendation is to wait 500 ms at room temp (longer if cold), to assert RST for a short period (say 100 us or less -- as it stops all of the clocks, and you may be switching a lot of stuff, and power supplies don't like going from 0 load to 100% load!), and then see if LOCKED is true, and CLIN_IN_LOST is false, and (if the CLKFX outputs are used) CLK_FX_STOPPED is false. If the status bits are good, then the device is running OK. If the status bits are not OK, reset it again. Austin David Miller wrote: > Hi, > > Here's a problem that does not qualify as kindergarten stuff. > > A DCM in a xc2v1000 engineering sample is behaving oddly. I am using > this DCM to generate and deskew a clock and antiphased clock (0 & 180 > degrees) for a DDR RAM. It is being fed by a 100MHz crystal buffered > with a CY2308 zero-delay clock buffer (ie, a pll.) > > The period of the clock seen at the board is 10 ns - usually. > Occasionally, the clock periods is lengthened by between 2.5 and 3 ns. > The stretch is always in the low half of the cycle. > > What could be causing this? > > Relevant facts: > - Chip is a xc2v1000bg456-4 -ES > - Software is Xilinx Alliance 3.3.08i with the VirtexII device update > files and the bitgen patch applied. > - SelectIO type HSTL class II with DCI is being used > > I used a 1 gigahertz (5 gigasample) oscilloscope to look at this clock > pin, so sampling error isn't it. The oscilloscope showed that sometimes > (perhaps 1 of 4 stretched periods), the clock starts to go high at the > right time, then changes its mind literally half way through the rise > time -- it gets to half way between Vol and Voh (or Vref; this is HSTL) > and then returns to Vol again. between 2.5 and 3 ns later, it does a > proper rising edge. > > I've even tried locking the DCM to different parts of the chip and it > made no difference. > > I've searched the xilinx answers and found no clues. Any suggestions > gratefully received! > > -- > David Miller, BCMS (Hons) | When something disturbs you, it isn't the > Endace Measurement Systems | thing that disturbs you; rather, it is > Mobile: +64-21-704-djm | your judgement of it, and you have the > Fax: +64-21-304-djm | power to change that. -- Marcus Aurelius --------------54E62841DE335C4C12624456 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> David, <p>The most important errata from the errata sheet for the DCM is to reset it after the part is configured and the clocks are running after a delay. <p>The delay is required because the power supply that runs the delay lines did not power on for a <b>long</b> time until after the part is done configuring. The delay can be seconds if cold, and about 200 ms at room temperature. <p>The recommendation is to wait 500 ms at room temp (longer if cold), to assert RST for a short period (say 100 us or less -- as it stops all of the clocks, and you may be switching a lot of stuff, and power supplies don't like going from 0 load to 100% load!), and then see if LOCKED is true, and CLIN_IN_LOST is false, and (if the CLKFX outputs are used) CLK_FX_STOPPED is false. If the status bits are good, then the device is running OK. If the status bits are not OK, reset it again. <p>Austin <p>David Miller wrote: <blockquote TYPE=CITE>Hi, <p>Here's a problem that does not qualify as kindergarten stuff. <p>A DCM in a xc2v1000 engineering sample is behaving oddly. I am using <br>this DCM to generate and deskew a clock and antiphased clock (0 & 180 <br>degrees) for a DDR RAM. It is being fed by a 100MHz crystal buffered <br>with a CY2308 zero-delay clock buffer (ie, a pll.) <p>The period of the clock seen at the board is 10 ns - usually. <br>Occasionally, the clock periods is lengthened by between 2.5 and 3 ns. <br> The stretch is always in the low half of the cycle. <p>What could be causing this? <p>Relevant facts: <br> - Chip is a xc2v1000bg456-4 -ES <br> - Software is Xilinx Alliance 3.3.08i with the VirtexII device update <br>files and the bitgen patch applied. <br> - SelectIO type HSTL class II with DCI is being used <p>I used a 1 gigahertz (5 gigasample) oscilloscope to look at this clock <br>pin, so sampling error isn't it. The oscilloscope showed that sometimes <br>(perhaps 1 of 4 stretched periods), the clock starts to go high at the <br>right time, then changes its mind literally half way through the rise <br>time -- it gets to half way between Vol and Voh (or Vref; this is HSTL) <br>and then returns to Vol again. between 2.5 and 3 ns later, it does a <br>proper rising edge. <p>I've even tried locking the DCM to different parts of the chip and it <br>made no difference. <p>I've searched the xilinx answers and found no clues. Any suggestions <br>gratefully received! <p>-- <br>David Miller, BCMS (Hons) | When something disturbs you, it isn't the <br>Endace Measurement Systems | thing that disturbs you; rather, it is <br>Mobile: +64-21-704-djm | your judgement of it, and you have the <br>Fax: +64-21-304-djm | power to change that. -- Marcus Aurelius</blockquote> </html> --------------54E62841DE335C4C12624456--Article: 37718
Ok, this is great. Two other times I posted to this group about making hard macros and got no response. The low road paid off it seems. I really want to get these hard macros with locked routing to work. What I see when I try to make a hard macro is that I cannot manually route the nets in editor. I want to hand route the clock signal on local routing and hand route an enable. The first thing that happens is I start routing the clock through a switchbox from a normal IBUF, works fine. Then I try to re-select the input sight to the switchbox to make a split in the routing. I cannot select the input bubble again and if I just select the net and a new destination out of the switchbox it complains. I have a routed design open in editor right next to the one I am hand routing. Since I couldn't get this to work, I decided to first see if I could route the line by hand like the router did. I know I am selecting usable sights because I am cheating of a routed design. So how do I re-select that bubble to continue hand routing? From what I have seen on the group most people are letting the tool route the "macro" then going into editor and turning the ncd to a macro. Then lock routing. What I have been doing is placement only and then open the ncd to hand route my couple nets. What I am building into a macro is a 16 bit FIFO, I have 16 of these FIFOs in the design and each one contains IOB latches. Since they contain IOB latches none of them have the identical IOB placement because of prohibit sites. If I hand route I can keep al of the clock tree in the logic portion the same and only change which IOBs it goes to for each macro. Any help greatly appreciated, but if you can answer this why can't my Xilinx FAE? Bryan "Bret Wade" <bret.wade@xilinx.com> wrote in message news:3C1FDBC2.A88FF9B8@xilinx.com... > Hello Bryan, > > FPGA Editor and the other implementation tools do support routed hard macros. > Hard macros aren't widely used because of the limitations in the timing analysis > tools in dealing with the macros, but the support is there. > > Regards, > Bret Wade > Xilinx Product Applications > > Bryan wrote: > > > So lets talk controversial.... > > > > If Lucent can support hard macros in Epic with hard routing, then why can't > > Xilinx. My application requires it and Xilinx doesn't support it in FPGA > > editor(which was programmed by the same softies as Epic). Oh, I remember > > why they don't support it. Because nobody cares about designs that push the > > limitations of FPGAs. Because everybody else that is making designs for > > Xilinx parts is still in kindergarten finger painting with verilog and hdl. > > Ha, I didn't get my EE degree to be a soft weirdo. Anybody can throw code > > together and get poor performance. > > > > flame away kindergarten kids > > > > Bryan > > > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message > > news:3C1F8AEC.BFD2E067@xilinx.com... > > > This is a friendly and helpful newsgroup, but let's make sure that it does > > not > > > get abused. > > > Lots of textbooks explain how to divide by a power of 2, where the > > remainder is, > > > and how you sign-extend the MSB. Explaining that is not the purpose of > > this > > > newsgroup. > > > > > > Let's use our "bandwidth" for more complex and perhaps controversial > > questions > > > that are not explained in textbooks and data books. > > > > > > Peter Alfke, Xilinx Applications > > > > > > >Article: 37719
"Carl Brannen" <carl.brannen@terabeam.com> wrote in message news:58d3bc222c92128795a51aed1bc2d4d1.51709@mygate.mailgate.org... > "Bryan" <bryan@srccomp.com> wrote in message > news:3c1fc73b$0$22747$724ebb72@reader2.ash.ops.us.uu.net... > > > So lets talk controversial.... > > > > If Lucent can support hard macros in Epic with hard routing, then why can't > > Xilinx. My application requires it and Xilinx doesn't support it in FPGA > > editor(which was programmed by the same softies as Epic). > > Just curious, which constraint is it that is driving you to hard macros? I've > long wished for better support for the little things. I haven't got it, so > I've drifted towards optimizing VHDL to get what I want. > My design is in a XC2V3000 part. I have 16 asynchronous FIFOs that interface to my core logic design. Each of these FIFOs has its own write clock, so there is not enough resources in the chip to put these on low skew global clocks. I also have 4 other clocks in the design. So I have just run out of clock resources. That is not a big deal if I could hand route the FIFO write clocks for repeatability. See my other response to Bret Wade BryanArticle: 37720
This is a multi-part message in MIME format. --------------02E14D37B3671B885B255E54 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bryan, I tend to use the add command when selecting one net with the pin of the COMP that I want to connect to. I generally then let the router pick the route throught the switch matrix. The router may or may not use the same net and split it. Personally when routing the clocks, I use tight constraints in PAR, then lock the clock net down (if met) using the directed routing constraint...Much easier and less hassle! btw : I am an FAE and have just one customer doing this kind of stuff.....I wouldn't recommend it to any of my customers, but it is fantastic to guarantee local clocks working! Dave Bryan wrote: > Ok, this is great. Two other times I posted to this group about making hard > macros and got no response. The low road paid off it seems. I really want > to get these hard macros with locked routing to work. What I see when I try > to make a hard macro is that I cannot manually route the nets in editor. I > want to hand route the clock signal on local routing and hand route an > enable. The first thing that happens is I start routing the clock through a > switchbox from a normal IBUF, works fine. Then I try to re-select the input > sight to the switchbox to make a split in the routing. I cannot select the > input bubble again and if I just select the net and a new destination out of > the switchbox it complains. I have a routed design open in editor right > next to the one I am hand routing. Since I couldn't get this to work, I > decided to first see if I could route the line by hand like the router did. > I know I am selecting usable sights because I am cheating of a routed > design. So how do I re-select that bubble to continue hand routing? > > From what I have seen on the group most people are letting the tool route > the "macro" then going into editor and turning the ncd to a macro. Then > lock routing. What I have been doing is placement only and then open the > ncd to hand route my couple nets. What I am building into a macro is a 16 > bit FIFO, I have 16 of these FIFOs in the design and each one contains IOB > latches. Since they contain IOB latches none of them have the identical IOB > placement because of prohibit sites. If I hand route I can keep al of the > clock tree in the logic portion the same and only change which IOBs it goes > to for each macro. > > Any help greatly appreciated, but if you can answer this why can't my Xilinx > FAE? > > Bryan > > "Bret Wade" <bret.wade@xilinx.com> wrote in message > news:3C1FDBC2.A88FF9B8@xilinx.com... > > Hello Bryan, > > > > FPGA Editor and the other implementation tools do support routed hard > macros. > > Hard macros aren't widely used because of the limitations in the timing > analysis > > tools in dealing with the macros, but the support is there. > > > > Regards, > > Bret Wade > > Xilinx Product Applications > > > > Bryan wrote: > > > > > So lets talk controversial.... > > > > > > If Lucent can support hard macros in Epic with hard routing, then why > can't > > > Xilinx. My application requires it and Xilinx doesn't support it in > FPGA > > > editor(which was programmed by the same softies as Epic). Oh, I > remember > > > why they don't support it. Because nobody cares about designs that push > the > > > limitations of FPGAs. Because everybody else that is making designs for > > > Xilinx parts is still in kindergarten finger painting with verilog and > hdl. > > > Ha, I didn't get my EE degree to be a soft weirdo. Anybody can throw > code > > > together and get poor performance. > > > > > > flame away kindergarten kids > > > > > > Bryan > > > > > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message > > > news:3C1F8AEC.BFD2E067@xilinx.com... > > > > This is a friendly and helpful newsgroup, but let's make sure that it > does > > > not > > > > get abused. > > > > Lots of textbooks explain how to divide by a power of 2, where the > > > remainder is, > > > > and how you sign-extend the MSB. Explaining that is not the purpose of > > > this > > > > newsgroup. > > > > > > > > Let's use our "bandwidth" for more complex and perhaps controversial > > > questions > > > > that are not explained in textbooks and data books. > > > > > > > > Peter Alfke, Xilinx Applications > > > > > > > > > > --------------02E14D37B3671B885B255E54 Content-Type: text/x-vcard; charset=us-ascii; name="dhawke.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Hawke Content-Disposition: attachment; filename="dhawke.vcf" begin:vcard n:;David Hawke tel;cell:(44) 778 875 5002 tel;fax:(44) 1291 621 541 tel;home:(44) 1291 621 655 tel;work:(44) 870 7350 517 x-mozilla-html:FALSE org:Xilinx UK;Northern European Sales version:2.1 email;internet:dhawke@xilinx.com title:Xilinx Field Applications Engineer adr;quoted-printable:;;Benchmark House=0D=0A203 Brooklands Road=0D=0A;Weybridge;Surrey;KT14 ORH;United Kingdom fn:David Hawke end:vcard --------------02E14D37B3671B885B255E54--Article: 37721
S. Ramirez wrote: > I don't know about you guys and gals and pals, but everytime I do a > design, without exception, I ALWAYS go into the Xilinx Design Manager > Design --> Optiions --> Implementation Edit Options and select and select > "Inputs and Outputs" for Pack I/O Registers/Latches into IOBs for. I ALWAYS > want my designs to use IOB flip flops if possible. It seems to me that the > default "Off" is a waste of these flip flops. Does anyone here every turn > this off? Simon, Amen. ---aArticle: 37722
"David Hawke" <dhawke@...inx.com> wrote > Also for everyone here, you might also want to try the Directed Routing > constraint (which appends it to the ucf or ncf file) Tools > Directed Routing > cst.... I guess "Tools > Directed Routing cst" is not to be confused with "Tools > DRC" :) Which revision of FPGA Editor for DirectedRoutingCst ?Article: 37723
Stephen Byrne wrote: > I originally posted this yesterday on google groups, but I'm not seeing it > on my home news server. In case it is not visible to all, I'm reposting. > > Hello All, > > My company is currently comparing 66MHz PCI core solutions from Xilinx > and Altera, as well as debating using a home-spun core. One issue > I've come upon is the PCI requirement for a MAX clock-to-out time of 6 > ns and MIN clock-to-out time of 2 ns. Both the Xilinx ISE and Altera > Quartus II tools seem very helpful in supplying MAX (worst-case) Tco > times, but I don't see any info on best-case times. Apparently the > SDF files for back-annotated timing sim have the same worst-case > numbers repeated 3 times, resulting in the same simulation regardless > of case selection. My question is: how is anyone (FPGA vendors > included) guaranteeing a MIN Tco of 2 ns across all conditions and > parts if the design tools don't even yield that information? You like to live dangerously if you depend on best-case timing information. --aArticle: 37724
"Austin Franklin" <austin@dark98room.com> wrote in message
news:u1va20nslv01fe@corp.supernews.com...
> Hi Simon,
>
> That's what you get for using Design Mangler...er...Manager ;-)
>
> Austin
Hi Austin,
Is Max Pus II any better?
Simon
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