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
I have a design implemented in Xilinx SpartanII 200. In Active Hdl 4.2 simulator, I'm troubled with how to view BlockRam contents generated by Xilinx Coregenerator. That is important for me, who can help me?Article: 32926
I have a design implemented in Xilinx SpartanII 200. In Active HDL simulator, I'm troubled with how to view Blockram content generated by Xilinx Coregenerator. It is important for both functional and timing simulation. Who can help me ?Article: 32927
One friend of mine says that deal with FPGA-based boards is a waste of time. Suggesting that the millions-ever-increasing size FPGA will handle every possible design without any hassle. What do you think? Are the architectures likes the Splash-based, DISC-based, etc. dead?Article: 32928
Try using Booth recoding.Article: 32929
Hi, As you've guessed from recent posts, I'm very new to using FPGAs (couple of months). I've been spending my time implementing schematic design entries (using Foundation ISE). This brings me to my question? Should I rather be attempting to implement my designs in VHDL instead? My experience with VHDL is the Designer's Guide to VHDL! Any suggestions? AdrianArticle: 32930
I'd like to know how to do this as well. If third-party supplied cores become common there needs to be some way to protect the ip and still allow customer customization. How about providing some sort of wedge or hook in the build process that allows a third party tool to generate a temporary source file for a core 'on the fly' ? ie the third party utility could read a license key then decrypt code for the core, and perform macro substitutions to accomodate parameters. There would have to be some sort of language extensions to VHDL or Verilog when instancing components to say ' use this vendor supplied tool , with the following parameters....' in order to get at the source code. But even then I don't think it's possible to protect the ip because someone could just create source that includes only that component, synthesize it, then use a tool to convert from the net list back to source code... The same problem exists for distributing source code for software. Non-disclosure agreements, licensing and sueing, are the only things I can think ok. RobArticle: 32931
Subodh: it is just a wild guess, but have you double checked that there is a 4.7K pullup at /INIT? This might be a reason for the /INIT behavior you have observed. Cheers Oliver Subodh Nijsure wrote: > > Hello, > > Is the following sequence to download bit file to Xilinx Vertex_E correct? > I am using CPLD which to send bit stream to FPGA. > > Here are the steps I am doing from my Linux driver that downloads the > bitstream to the FPGA. > > 1. Hold PROGRAM high wait for 400 us > 2. Hold PROGRAM low, monitor the INIT pin, wait for it to go high, this > will indicate FPGA has cleared the memory. > > 3. Then hold PROGRAM pin high, CCLK 0, send data bit 0, > 4. Then hold PROGRAM pin high, CCLK 1, send data bit 0, > Repeat steps 3 through 4 for entire .bit file. > > Now monitor the DONE pin if its high everything is okay else FPGA download > failed. > > WHat I have observed is after step 2 above if i wait for 100 us and go > back and check the INIT pin it has gone low, I haven't sent any data bits > to FPGA yet. So if INIT pin has gone low (0) should I still continue to > send data? > Also in steps 3 and 4 should one be checking if INIT has gone low or DONE > has gone high? > > /Subodh NijsureArticle: 32932
Use it to keep up to date with the latest 8, 16 and 32 bit Embedded Tools. * TCP/IP and Ethernet for 8051, AVR, PIC, M16C, H8, Z180, 16x * Flash programming for HC12 and other BDM/JTAG based CPUs * GNU Debugger for PowerPC, ARM, 683xx * Secure Embedded TCP/IP with SSL and SNMPv3 * Mon08 interface to program the 68HC908 on chip flash super fast * Debug TCP/IP serial and Ethernet data displayed in packets * New fast EPROM/Flash/Micro/PAL programmer Pick up a copy from our web site...... http://www.computer-solutions.co.uk Email me with your postal address ( Europe only please ) and I will be happy to send you a copy - tell me which of those products you are particularly interested in and I will include full details. If your reply says "email" I will email a copy ( .pdf format, size 200Kbytes). Visit our web site http://www.computer-solutions.co.uk - keep it book marked as in the "Information Zone" we have published a number of free services for Embedded Engineers - 1) Micro-Search - our searchable database of 300 + chip specs from 13 different 8051 manufacturers 2) Support Tools Directory - shows the development tools available for over 100 microprocessor families 3) The Embedded Web - 250 + links to useful sites from Chip Manufacturers to software algorithms Our aim - to make it the premier UK site for Embedded Engineers ----------------------------- Chris Stephens E-mail: sales@computer-solutions.co.uk Computer Solutions Ltd. Phone & Fax: +44 (0)1 932 829 460 1a New Haw Road, Addlestone, Surrey, KT15 2BZ England http://www.Computer-Solutions.co.uk For the largest range of embedded microprocessor development tools in the UKArticle: 32933
Dear all, I'm a beginner in programmable logic (just a few CPLD designs) so still got many basic questions. One of them is how can I estimate chip density for my future project? What should I consider: number of gates or CLBs. What I know for a moment is number of IO pins and a concept of internal functions I have to implement: two independent SDRAM controllers and some logic to access them (let's say same logic size as one SDRAM controller). The best would be to make a design and try to fit it in different chips but how can I do it before the project is done. I'm thinking of SpartanXL XCS40XL for a prototype so then I can use smaller device if I have free resources - can anyone say if this chip is enough or not? Many thanks for all replies. DanielArticle: 32934
Hi all, I've got a dsp driving an altera ep1k30, and was wondering if its ok to reprogram that chip even tho the dsp is still driving it. I've got a byteblaster connected to it. I read somewhere that all(?) the pins go to tri-state when programming (passive serial). -- ___ ___ / /\ / /\ / /__\ / /\/\ /__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/ \ \ / Victoria, Australia, Down-Under \ \/\/ \__\/ \__\/Article: 32935
Problem. Whether somebody will suggest what set-up of the computer influence On that ModelSim up to the version 5.5 beta 4 Steadily worked on all machines IBM PC, And all following versions on half Machines rush in the ambassador of a beginning simulations. And from a Renoir too not to leave on ModelSim on these Machines. Вопрос. Не подскажет ли кто-нибудь какие настройки компьютера влияют на то, что ModelSim до версии 5.5 beta 4 устойчиво работал на всех машинах IBM PC, а все следующие версии на половине машин вываливаются после начала симуляции. И из пакета Renoir тоже не выйти на симулятор ModelSim на этих машинах: ---------------------------------------------------------------------------- ----- Performing hierarchical compile through components on selection... Structure file written to temporary file C:\Temp\comp4 Current working directory is C:/ Executing data preparation plug-in for ModelSim 5.3 - 5.5 Nothing to be done Invoking simulator... Data preparation step completed, check transcript... ---------------------------------------------------------------------------- ----- Reading C:/Modelsim/win32/../tcl/vsim/pref.tcl Reading C:/Renoir/resources/misc/ModelSim.tc_ Connected to HDS # Attempting stack trace sig 11 # Signal caught: signo [11] # do_stack_trace called again before completion! # With signal: signo [11] Internal error: bad pointer access... Closing vsim. vsim is exiting with code 11 AndrejArticle: 32936
Hi, I just updated my Xilinx Foundation 3.1i with the very new 3.3i Service Pack 8. After that I am not able to open any Design in the Design Manager. I get always the message "Cannot initialize Automation -Synopsys initialization failed" thanks for any help peterArticle: 32937
Hello all, I have been working on this AHDL code but i don't understand how the register mapping works when chip select /up_cs5 is set.... i would also appreciate if someone can cooment the code.... Thx for ur help Abhimanyu Rastogi 2nd year student University of Ottawa Canada -- Include Section include "2x8mux.inc"; -- Title Section TITLE "NORMAL RUN MODE CONFIGURATION"; -- Constant Section -- Options Section -- OPTIONS BIT0 = LSB; -- Subdesign Section SUBDESIGN RM2RUNA ( -- micro I/O pins upa[19..8] :INPUT; upad[7..0] :BIDIR; up_ale , /up_bhe , /up_rd , /up_wr , /up_ucs , /up_lcs :INPUT; /up_cs0 , /up_cs1 , /up_cs2 , /up_cs3 , /up_cs4 , /up_cs5 :INPUT; up_int4 , /up_reset :OUTPUT; -- printer interface port I/O pins prtd[7..0] , prt_strb :INPUT; prt_ack , prt_busy , prt_paper , prt_slct , /pr_en :OUTPUT; -- micro flash , sram I/O pins ma[18..0] , /cs_flash , /rd_flash , /we_ldbfl , /we_udbfl :OUTPUT; /cs_upram1 , /cs_upram2 , /we_ldbupr , /we_udbupr , /rd_upram :OUTPUT; -- dsp I/O pins /cs_dsp1 , /we_dsp1 , /cs_arctic1 , /rd_arctic1 , /we_arctic1 :OUTPUT; /cs_dsp2 , /we_dsp2 , /cs_arctic2 , /rd_arctic2 , /we_arctic2 :OUTPUT; /dspa_reset , /dspb_reset :OUTPUT; -- misc I/O pins in_clk , sel[4..0] , XI[6..0] :INPUT; tp5 , tp6 , tp7 , tp8 , tp9 , sw_on , XO :OUTPUT; ) -- Variable Section VARIABLE ma[18..0] : DFFE; lobyte : DFFE; hibyte : DFFE; micro_reset : DFFE; -- in_clk : JKFF; pr_addr[7..0] : DFFE; pr_to_p186[7..0] : DFFE; pr_rcv_rdy : SRFFE; xmt_rdy_inten : DFFE; pr_xmt_rdy : NODE; rcv_rdy_inten : DFFE; p186_dspa_run : DFFE; p186_dspb_run : DFFE; panel_switch : DFFE; pr_rd : SRFFE; prd_en : NODE; pr_readbus[3..0] : NODE; pr_read_hi_P186 : NODE; pr_write_data : NODE; pr_write_ctrl : NODE; p186_to_pr[7..0] : DFFE; p186_rdmux : 2x8mux; p186_rdmux_tri[7..0] : TRI; p186_rcv_rdy : SRFFE; p186_xmt_rdy : NODE; p186_read : NODE; p186_write : NODE; p186_read_data : NODE; p186_write_data : NODE; p186_write_ctrl : NODE; strb[7..0] : DFFE; wr_lobyte : NODE; wr_hibyte : NODE; card_en : NODE; pr_strb_latch : SRFF; pr_strb_latchsr[1..0] : DFF; strb_on[1..0] : DFF; strb_off[1..0] : DFF; -- Logic Section BEGIN DEFAULTS (/dspa_reset , /dspb_reset) = GND; (/up_reset) = VCC; (/cs_flash , /rd_flash , /we_ldbfl , /we_udbfl , /cs_upram1 , /cs_upram2 , /we_ldbupr , /we_udbupr , /rd_upram) = VCC; (/cs_dsp1 , /we_dsp1 , /cs_dsp2 , /we_dsp2) = VCC; (/cs_arctic1 , /rd_arctic1 , /we_arctic1 , /cs_arctic2 , /rd_arctic2 , /we_arctic2) = VCC; (rcv_rdy_inten , xmt_rdy_inten) = GND; END DEFAULTS; -- micro address latch (ma[] , lobyte , hibyte).clk = !up_ale; -- (ma[] , lobyte , hibyte).ena = up_ale; ma[] = (upa[19..8] , upad[7..1]); lobyte = !upad[0]; hibyte = !/up_bhe; wr_lobyte = lobyte & !/up_wr; wr_hibyte = hibyte & !/up_wr; -- micro flash and sram address decode if(!/up_rd) THEN (/rd_flash , /rd_upram) = GND; END IF; if(!/up_lcs) THEN /cs_upram1 = GND; END IF; if(!/up_cs0) THEN /cs_upram2 = GND; END IF; if(!/up_ucs) THEN /cs_flash = GND; END IF; if(wr_lobyte) THEN (/we_ldbupr , /we_ldbfl) = GND; END IF; if(wr_hibyte) THEN (/we_udbupr , /we_udbfl) = GND; END IF; -- dsp sram address decode if(!/up_wr) THEN (/we_dsp1 , /we_dsp2) = GND; END IF; if(!/up_cs1 & !/dspa_reset) THEN /cs_dsp1 = GND; END IF; if(!/up_cs2 & !/dspb_reset) THEN /cs_dsp2 = GND; END IF; -- dsp arctic chip address decode if(!/up_wr) THEN (/we_arctic1 , /we_arctic2) = GND; END IF; if(!/up_rd) THEN (/rd_arctic1 , /rd_arctic2) = GND; END IF; if(!/up_cs3) THEN /cs_arctic1 = GND; END IF; if(!/up_cs4) THEN /cs_arctic2 = GND; END IF; -- -- printer port I/O logic -- -- printer reg map (xx denotes 5 bit card address): -- addr function -- xx0 ... read status #1 -- xx1 ... read status #2 -- xx2 ... read lo nibble P186 data port -- xx3 ... read hi nibble P186 data port -- xx4 ... write control reg -- xx5 ... write P186 data port -- -- status reg #1 bit assignments -- bit func -- 0 data available from P186 -- 1 data port to P186 empty -- -- control reg bit assignments -- bit func -- 0 release reset on P186 -- -- strobe line filtering and edge detection (pr_strb_latch , pr_strb_latchsr[] , strb[] , strb_on[] , strb_off[]).clk = in_clk; strb[] = (strb[6..0] , prt_strb); pr_strb_latch.s = strb[] == b"11111111"; pr_strb_latch.r = strb[] == b"00000000"; pr_strb_latchsr[] = (pr_strb_latchsr[0] , pr_strb_latch); strb_on[] = (strb_on[0] , pr_strb_latchsr[] == b"10"); strb_off[] = (strb_off[0] , pr_strb_latchsr[] == b"01"); -- card/brd address latch and card selection pr_addr[].clk = in_clk; pr_addr[] = prtd[]; pr_addr[].ena = strb_on[0]; card_en = pr_addr[7..3] == sel[]; -- register address selection truth table TABLE pr_addr[2..0] , card_en => prd_en , pr_read_hi_P186 , pr_write_ctrl , pr_write_data; X , 0 => 0 , 0 , 0 , 0 ; 0 , 1 => 1 , 0 , 0 , 0 ; 1 , 1 => 1 , 0 , 0 , 0 ; 2 , 1 => 1 , 0 , 0 , 0 ; 3 , 1 => 1 , 1 , 0 , 0 ; 4 , 1 => 0 , 0 , 1 , 0 ; 5 , 1 => 0 , 0 , 0 , 1 ; 6 , 1 => 0 , 0 , 0 , 0 ; 7 , 1 => 0 , 0 , 0 , 0 ; END TABLE; -- data port and control reg logic (pr_to_p186[] , micro_reset).clk = in_clk; pr_to_p186[] = prtd[]; pr_to_p186[].ena = strb_off[1] & pr_write_data; -- (pr_dsp_run , /up_reset) = prtd[1..0]; -- (pr_dsp_run , /up_reset).ena = strb_off[1] & pr_write_ctrl; micro_reset = !prtd[0]; (micro_reset).ena = strb_off[1] & pr_write_ctrl; /up_reset = !micro_reset; -- read logic pr_rd.clk = in_clk; pr_rd.s = strb_on[1] & prd_en; pr_rd.r = strb_off[1]; /pr_en = !pr_rd; CASE pr_addr[2..0] & card_en IS WHEN 1 => pr_readbus[] = (1 , 0 , 1 , 0); WHEN 2 => pr_readbus[] = p186_to_pr[3..0]; WHEN 3 => pr_readbus[] = p186_to_pr[7..4]; WHEN OTHERS => pr_readbus[] = (0 , 1 , pr_xmt_rdy , pr_rcv_rdy); END CASE; (prt_busy , prt_ack , prt_paper , prt_slct) = (!pr_readbus[3] , pr_readbus[2] , pr_readbus[1] , pr_readbus[0]); -- microcontroller bus decode logic p186_read = !/up_cs5 & !/up_rd; p186_write = !/up_cs5 & !/up_wr; p186_write_ctrl = p186_write & !ma[0]; p186_read_data = p186_read & ma[0]; p186_write_data = p186_write & ma[0]; -- microcontroller data port and control reg write logic -- -- ctrl reg bit assignments -- bit func -- 0 rcv_rdy interrupt enable -- 1 xmt_rdy interrupt enable -- 2 dspa reset (0 = reset , 1 = run) -- 3 dspa reset (0 = reset , 1 = run) -- 4 front panel switch (0 = off , 1 = on) -- (p186_to_pr[] , rcv_rdy_inten , xmt_rdy_inten , p186_dspa_run , p186_dspb_run , panel_switch).clk = in_clk; p186_to_pr[].ena = p186_write_data; (rcv_rdy_inten , xmt_rdy_inten , p186_dspa_run , p186_dspb_run , panel_switch).ena = p186_write_ctrl; p186_to_pr[] = upad[]; -- (panel_switch , p186_dsp_run , rcv_rdy_inten , xmt_rdy_inten) = upad[5..2]; (panel_switch , p186_dspb_run , p186_dspa_run , xmt_rdy_inten , rcv_rdy_inten) = upad[4..0]; /dspa_reset = p186_dspa_run; /dspb_reset = p186_dspb_run; sw_on = !panel_switch; -- microcontroller data port and status reg read logic p186_rdmux.a[] = pr_to_P186[]; -- p186_rdmux.b[] = (b"000" , p186_dsp_run , rcv_rdy_inten , xmt_rdy_inten , p186_xmt_rdy , p186_rcv_rdy); p186_rdmux.b[] = (0 , sel[] , p186_xmt_rdy , p186_rcv_rdy); p186_rdmux.sel = p186_read & ma[0]; p186_rdmux_tri[].in = p186_rdmux.y[]; p186_rdmux_tri[].oe = p186_read; upad[] = p186_rdmux_tri[].out; -- data port semaphore logic (pr_rcv_rdy , p186_rcv_rdy).clk = in_clk; pr_xmt_rdy = !p186_rcv_rdy; p186_xmt_rdy = !pr_rcv_rdy; pr_rcv_rdy.s = p186_write_data; pr_rcv_rdy.r = pr_read_hi_P186 & strb_off[1]; p186_rcv_rdy.s = pr_write_data & strb_off[1]; p186_rcv_rdy.r = p186_read_data; pr_xmt_rdy = !p186_rcv_rdy; p186_xmt_rdy = !pr_rcv_rdy; up_int4 = (p186_rcv_rdy & rcv_rdy_inten) # (p186_xmt_rdy & xmt_rdy_inten); -- misc logic XO = XI[] == 0; tp5 = p186_rcv_rdy; tp6 = p186_xmt_rdy; tp7 = up_int4 ; tp8 = strb_on[0] # strb_on[1]; tp9 = pr_strb_latch; -- in_clk.(j,k,prn,clrn) = VCC; -- in_clk.clk = in_clk_x2; END;Article: 32938
Goran Bilski wrote > and a calling is looking like this: > > constant RLOC_PLACE : string := Get_RLOC_Name(Target => C_TARGET, > > Y => C_Y, > > X => C_X); > > attribute RLOC of I_ALU_LUT : label is RLOC_Place; > This approach is not generic to all synthesis tools, as synopsys FPGA express only supports static RLOC names. i.e. The above line "attribute RLOC of I_ALU_LUT : label is RLOC_Place" gets passed through to the edif netlist as (property RLOC (String "RLOC_Place")) which generates errors in map as expected I wonder what synthesis tool you are using or if there is another way around this. Chris Mc Clements, Research Student, Univ of Dundee, Scotland.Article: 32939
Hi Steven, Steven Derrien wrote: > To avoid deadlocks, i must ensure that all IO write operation are > immediatly performed on the target file. This is easily handled in C > with > fflush(), however i didn't found any workaround for VHDL. > > Anyone with a clue ? I faced the same problem in Modelsim while communicating to a test bench written in Java. The problem was solved for me by closing and reopening the file. You probably need to enable VHDL-93 support for that. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- file declaration FILE my_outfile: text open append_mode IS my_outfile_name; [...] writeline(my_outfile, outline); -- flush my_outfile file_close(my_outfile); file_open(my_outfile, my_outfile_name, append_mode); [...] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Best regards, Michael.Article: 32940
I'm not that familiar with Xilinx IP, but I think I can help a bit here... Altera has a bunch of SDRAM controller cores on it's web site () ranging in size from 223 flip-flop/Look-up-table elements for a single-data-rate (SDR) core to 864 FF/LUTs for a double-data-rate (DDR) core. Assuming the bigger core, three of these would put you at almost 2600 FF/LUTs, which would fit into a Altera ACEX 1K50. I think that 2600 FF/LUTs is going to be too big for a XCS40, but it should fit in a XC2S150 (or possibly even an XC2S100). If you only need a bare-bones SDR implementation, you can probably get by with a ACEX 1K30 (1700 FF/LUTs) or a XCS30 (around 1200?). As far as the tools go, you can get the Altera tools for the ACEX devices for free off their web page. I'm not sure about the Xilinx tools, but I think their Spartan tools are free too. -Pete- Daniel HaЯczewski <danhan@wp.pl> wrote in message news:3B4D7839.C62C151E@wp.pl... > Dear all, > > I'm a beginner in programmable logic (just a few CPLD designs) so still > got many basic questions. One of them is how can I estimate chip density > for my future project? What should I consider: number of gates or CLBs. > What I know for a moment is number of IO pins and a concept of internal > functions I have to implement: two independent SDRAM controllers and > some logic to access them (let's say same logic size as one SDRAM > controller). The best would be to make a design and try to fit it in > different chips but how can I do it before the project is done. I'm > thinking of SpartanXL XCS40XL for a prototype so then I can use smaller > device if I > have free resources - can anyone say if this chip is enough or not? > > Many thanks for all replies. > Daniel > >Article: 32941
Michael Paar wrote: > > Hi Steven, > > Steven Derrien wrote: > > To avoid deadlocks, i must ensure that all IO write operation are > > immediatly performed on the target file. This is easily handled in C > > with > > fflush(), however i didn't found any workaround for VHDL. > > > > Anyone with a clue ? > > I faced the same problem in Modelsim while communicating to a > test bench written in Java. > > The problem was solved for me by closing and reopening the file. > You probably need to enable VHDL-93 support for that. thanks I also found a workaround using Synopsys VSS CLI (C language interface), but your solution seems much simpler. steven > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -- file declaration > FILE my_outfile: text open append_mode IS my_outfile_name; > [...] > > writeline(my_outfile, outline); > -- flush my_outfile > file_close(my_outfile); > file_open(my_outfile, my_outfile_name, append_mode); > [...] > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Best regards, > > Michael.Article: 32942
James, I'm pretty sure that you can't erase the EPC1441's. There may have been a UV eraseable version at one time, but the ones you buy today are not eraseable. However, if someone comes along with a solution that actaully works, but sure to post it here. I have a coffee cup full of EPC1441's loaded with not-quite-right designs that I'd like to erase... -Pete- James Baker <jbaker@halcyon.com> wrote in message news:jbaker-1107011849290001@76-a-usw.rb1.blv.nwnexus.net... > Does anyone know how to erase and Altera EPC-1441 configuration device > (serial EPROM)? I have the Altera MP-6 (ISA card) and MPU programmer with > PLMJ-1213 adapter on loan from Altera, but I'll get or make different > programming/erasing hardware if I have to. > > The literature says they're OTP but I know I've erased and reused them > before. I just can't remember how, and I'd like to reuse the several > thousand devices I have. > > Thanks. > > -- > James Baker > Seattle, WA > jbaker@halcyon.comArticle: 32943
Is there any document around which shows the relation between commands in SDC file of Synplify and commands in UCF file of Xilinx? UtkuArticle: 32944
Hi, I works with synplicity and Leonardo. /GЖran Chris Mc Clements wrote: > Goran Bilski wrote > > > and a calling is looking like this: > > > > constant RLOC_PLACE : string := Get_RLOC_Name(Target => C_TARGET, > > > > Y => C_Y, > > > > X => C_X); > > > > attribute RLOC of I_ALU_LUT : label is RLOC_Place; > > > > This approach is not generic to all synthesis tools, as synopsys FPGA > express > only supports static RLOC names. i.e. > The above line "attribute RLOC of I_ALU_LUT : label is RLOC_Place" gets > passed through to the edif netlist as > > (property RLOC (String "RLOC_Place")) > > which generates errors in map as expected > I wonder what synthesis tool you are using or if there is another way around > this. > > Chris Mc Clements, Research Student, Univ of Dundee, Scotland.Article: 32945
Synplify outputs an NCF file which is basically the SDC file translated to vendor (UCF) constraints. So if you put constraints in the SDC file you can synthesize and look at the NCF to see what the UCF equivalent is. "Utku Ozcan" <ozcan@netas.com.tr> wrote in message news:3B4DB5AE.5502217B@netas.com.tr... > > Is there any document around which shows the relation between > commands in SDC file of Synplify and commands in UCF file of Xilinx? > > Utku > > >Article: 32947
The Virtex DLL allows one to divide the input frequency by a number of values. However, it appears that the DLL feedback may not come from the divided output. I am wondering if that means that the divided output is frequency-locked but NOT phase-locked to the input, meaning it is essentially a separate clock domain. If this is true, what good is the divided output? It seems like it's just a gated clock, and no better than a clock I could derive myself with a T flipflop. When using the DLL in 2x mode, the 2x output is phase-locked to the input so I should be able to transfer data from the 1x domain to the 2x domain without any domain-crossing logic, but it looks like I can't do that with the DLL in 1/2x mode. The DLL doesn't seem to take into account the delay across the BUFG in 1/2x mode. Am I wrong? -KevinArticle: 32948
Kevin, All output delays are matched, so it does take this (trying to keep all DLL outputs in their proper phases) into account. So CLKDV is in phase, in that it only changes when CLK0 changes. There is a skew specified, worst case, for any DLL output from the feedback reference, which represents the errors in the matching due to variations of identical circuits on the same die due to process. The state of the CLKDV is not something that is known. By that I mean that when you start up the first CLK0 rising edge may cause CLKDV to transition, and it may not until the next rising edge (ie divide by 2 -- where does it ?start?). Austin Kevin Neilson wrote: > The Virtex DLL allows one to divide the input frequency by a number of > values. However, it appears that the DLL feedback may not come from the > divided output. I am wondering if that means that the divided output is > frequency-locked but NOT phase-locked to the input, meaning it is > essentially a separate clock domain. If this is true, what good is the > divided output? It seems like it's just a gated clock, and no better than a > clock I could derive myself with a T flipflop. > > When using the DLL in 2x mode, the 2x output is phase-locked to the input so > I should be able to transfer data from the 1x domain to the 2x domain > without any domain-crossing logic, but it looks like I can't do that with > the DLL in 1/2x mode. The DLL doesn't seem to take into account the delay > across the BUFG in 1/2x mode. Am I wrong? > > -KevinArticle: 32949
Is anyone experiencing block ram failures in Xilinx Virtex-E devices? We've seen a condition where different bit files will cause hard failures on a small percentage of the parts. The block rams are configured as 32-bit wide FIFO's; certain nibbles of the fetched data seem to be from the previous clock cycle. Locking the block RAM locations in the design doesn't always help; some devices still fail, some pass. Re-synthesising the design helps sometimes but not always. Working boards will fail with new bit files. We've seen the failure on multiple parts and on multiple designs. Is anyone experiencing anything similar or other unexplained failures with Virtex-E parts? Thanks
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