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
"NewToFPGA" <hetzme@yahoo.com> wrote in message news:1179855312.907650.145950@w5g2000hsg.googlegroups.com... > Does Operating System need to provide an FPGA a device driver? > > If no application needs the additional services from an FPGA, all we > do is initialize and start an FPGA... right? Anything else that need > to be done? You are persistent with your questions, aren't you? In applications where you want to define the functionality of an FPGA that doesn't need any other interaction with the central CPU, you don't even NEED a CPU to program and run the FPGA. External configuration memories can be used. It's often convenient in a processor-based system to update the FPGA from system memory but the programming interface (often implemented through GPIO) has no FPGA requirements beyond programming. The FPGA itself has plenty that needs to be done. If you're doing an ethernet packet switch, the FPGA should be tolerant to the ethernet cable being removed and reinserted, for instance, which might put reset requirements on a Digital Clock Manager (DCM) block as a for-instance. Are you going to be responsible for the FPGA design? Is your duty restricted to the system software/hardware side? - John_HArticle: 119551
Answer record 23249 outlines this change: http://www.xilinx.com/xlnx/xil_ans_display.jsp?BV_UseBVCookie=yes&getPagePath=23249 Nju Njoroge wrote: > On May 20, 10:26 am, Joseph Samson <jsam...@the-company-name.com> > wrote: >> Nju Njorogewrote: >>> Hello, >>> In our *working* EDK 8.1i project, we locked aDCMin the following >>> manner in the UCF file (located in <proj_dir>/data/system.ucf): >> [snip]... >> >> comment out theDCMLOC in your .ucf file, then run place and route. >> Open the design in FPGA Editor, find theDCMand look at the instance >> name. Now uncomment theDCMLOC and substitute the instance name that >> ISE 9.1i assigned. Rerun the place and route. > Great suggestion. I tried it and this is the name it uses: dcm_sys/ > dcm_sys/Using_Virtex.DCM_INST > > For some reason, the new tools appended a prefix "Using_Virtex" to the > DCM_INST. >Article: 119552
This forces XST to ignore analyzing/elaborating the HDL files for components that were marked black_box. This makes sense as the implementation for the blackbox component will be filled by a supplied netlist by the user in the later NGDBUILD assembly stage. L. Schreiber wrote: > Hi again, > > What does the setting of the attribute box_type to "black_box" for my > toplevel components effect (concerning modular design flow)? > > Syntax checking in ISE projnav searchs for the components' modules > anyway, whether black boxed or not. > > greetingsArticle: 119553
You seem to be missing gmake on SOL. This is typically available in /usr/local/bin/gmake Perhaps you don't have /usr/local/bin in your $PATH Do "whereis gmake" to locate it on SOL. Compling the elf file on either WIN or SOL would not matter since you are compiling for the target powerpc405 and not the development platform. So long as you have same sources and versions EDK tools on both WIN and SOL, then you should have the same ELF. Contact xilinx hotline for assistance on simgen. ferorcue wrote: > Hi friends, > > > I am working with Solaris and with all the systems that i generate > with XPS have the same problem. > > I have a Problem with LIBGEN. If I execute > XPS->Software->generate libreries and BSPs, gmake ist not compiling > the libraries and the directory ./ppc405/include possesses only the > file xparameters.h and the directory ./ppc405/lib is empty > *************************************************************************** > XPS INFO: > Configuring make for target include using: > gmake -s include "COMPILER=powerpc-eabi-gcc" "ARCHIVER=powerpc-eabi- > ar" > "COMPILER_FLAGS= -O2 -c" "EXTRA_COMPILER_FLAGS=-g" > > gmake: Command not found. > gmake: Command not found. > gmake: Command not found. > gmake: Command not found.` > gmake: Command not found. > gmake: Command not found. > Configuring make for target libs using: > gmake -s libs "COMPILER=powerpc-eabi-gcc" "ARCHIVER=powerpc-eabi-ar" > "COMPILER_FLAGS= -O2 -c" "EXTRA_COMPILER_FLAGS=-g" > gmake: Command not found. > gmake: Command not found. > gmake: Command not found. > gmake: Command not found. > gmake: Command not found. > gmake: Command not found. > Libraries generated in > /home/ferorcue/my_work/project/xps/xps_lin_v1_e/ppc405_0/lib/ > directory > Running execs_generate for OS'es, Drivers and Libraries ... > LibGen Done. > powerpc-eabi-gcc -O2 TestApp_Memory/src/TestApp_Memory.c -o > TestApp_Memory/executable.elf \ > -Wl,-T -Wl,TestApp_Memory/src/TestApp_Memory_LinkScr.ld -g - > I./ppc405_0/include/ -L./ppc405_0/lib/ \ > > TestApp_Memory/src/TestApp_Memory.c:39:19: > xutil.h: No such file or directory > make: *** [TestApp_Memory/executable.elf] Error 1 > > *************************************************************************** > > To solve this problem I use windows with the same system and I execute > XPS->Software->generate libreries and BSPs. The files of /lib and / > include are created > > > > *************************************************************************** > XPS INFO: > > Configuring make for target include using: > make -s include "COMPILER=powerpc-eabi-gcc" "ARCHIVER=powerpc-eabi-ar" > "COMPILER_FLAGS= -O2 -c" "EXTRA_COMPILER_FLAGS=-g" > Configuring make for target libs using: > make -s libs "COMPILER=powerpc-eabi-gcc" "ARCHIVER=powerpc-eabi-ar" > "COMPILER_FLAGS= -O2 -c" "EXTRA_COMPILER_FLAGS=-g" > Compiling common > powerpc-eabi-ar: creating ../../../lib/libxil.a > Compiling bsp > Compiling plb_arbiter > Compiling opbarb > Compiling uartlite > Compiling cpu_ppc405 > Libraries generated in > \\storage\ferorcue\my_work\project\xps\xps_lin_v1_e\ppc405_0\lib\ > directory > Running execs_generate for OS'es, Drivers and Libraries ... > LibGen Done. > Created mapping for /xygdrive -> /cygdrive > Done! > > *************************************************************************** > > After that I can execute >Generate libraries and HDL files > And >launch HDL simulator > > In modelsim I compile the design by running the EDK compile script, > Later I change the modelsim.ini to use the smartmodels. > And I click s to simulate > > s => load the design for simulation. (ModelSim 'vsim' > # *** command with 'system') After loading the design, > # *** set up signal displays (optional) and run the simulation. > # *** (ModelSim 'run' command) > > > This is the error that I get : > > *************************************************************************** > XPS INFO: > > > s > # vsim -t ps system_conf > # ** Note: (vsim-3812) Design is being optimized... > # ** Note: (vsim-3865) Due to PLI being present, full design access is > being specified. > # Loading /opt/modeltech/6.2a/linux/libswiftpli.sl > # Loading /opt/modeltech/6.2a/linux/../std.standard > # Loading /opt/modeltech/6.2a/linux/../ieee.std_logic_1164(body) > # Loading /home/ferorcue/simlib/EDK8.2_mti_se_linux/ISE_Lib/ > unisim/.vcomponents > # Loading /opt/modeltech/6.2a/linux/../std.textio(body) > # Loading /opt/modeltech/6.2a/linux/../ieee.vital_timing(body) > # Loading /opt/modeltech/6.2a/linux/../ieee.vital_primitives(body) > # Loading /home/ferorcue/simlib/EDK8.2_mti_se_linux/ISE_Lib/ > unisim/.vpkg(body) > # Loading work.system_conf#1 > # Loading work.system(structure)#1 > # Loading work.ppc405_0_wrapper(structure)#1 > # Loading ppc405_virtex4_v1_01_a.ppc405_virtex4(structure)#1 > # Loading /home/ferorcue/simlib/EDK8.2_mti_se_linux/ISE_Lib/ > unisim/.ppc405_adv(ppc405_adv_v) > # Loading /home/ferorcue/simlib/EDK8.2_mti_se_linux/ISE_Lib/ > unisim/.ppc405_adv_swift_bus(ppc405_adv_swift_bus_v) > # Loading /home/ferorcue/simlib/EDK8.2_mti_se_linux/ISE_Lib/ > unisim/.ppc405_adv_swift(smartmodel) > # Loading /opt/modeltech/6.2a/linux/libsm.sl > # ** Note (SmartModel): > # Copyright (c) 1984-2007 Synopsys Inc. ALL RIGHTS RESERVED > # ** Note (SmartModel): > # Platform Type: x86_linux (32-bit). > # ** Note (SmartModel): > # You can use the Browser tool to configure the SmartModel > # Library and access information about SmartModels: > # $LMC_HOME/bin/sl_browser > # > # SmartModel product documentation is available here: > # $LMC_HOME/doc/smartmodel/manuals/intro.pdf > # http://www.synopsys.com/products/lm/doc/smartmodel.html > # > # Notice: timing checks disabled with +notimingcheck at compile-time > # Loading /home/ferorcue/simlib/EDK8.2_mti_se_linux/ISE_Lib/ > unisim/.fpga_startup_virtex4(fpga_startup_virtex4_v) > # Loading work.jtagppc_0_wrapper(structure) > # Loading jtagppc_cntlr_v2_00_a.jtagppc_cntlr(structure) > # Loading /home/ferorcue/simlib/EDK8.2_mti_se_linux/ISE_Lib/ > unisim/.jtagppc(jtagppc_v) > # Loading work.reset_block_wrapper(structure)#1 > # Loading /opt/modeltech/6.2a/linux/../ieee.std_logic_arith(body) > # Loading proc_sys_reset_v1_00_a.proc_sys_reset(imp)#1 > # Loading proc_sys_reset_v1_00_a.upcnt_n(imp)#1 > # Loading proc_sys_reset_v1_00_a.lpf(imp)#1 > # Loading /home/ferorcue/simlib/EDK8.2_mti_se_linux/ISE_Lib/ > unisim/.srl16(srl16_v) > # Loading proc_sys_reset_v1_00_a.sequence(imp)#1 > # Loading proc_sys_reset_v1_00_a.upcnt_n(imp)#2 > # Loading work.plb_wrapper(structure)#1 > # Loading plb_v34_v1_02_a.plb_v34(simulation)#1 > # Loading /home/ferorcue/simlib/EDK8.2_mti_se_linux/ISE_Lib/ > unisim/.fds(fds_v)#1 > # Loading plb_v34_v1_02_a.plb_addrpath(implementation)#1 > # Loading proc_common_v1_00_b.mux_onehot(imp)#1 > # Loading proc_common_v1_00_b.mux_onehot(imp)#2 > # Loading proc_common_v1_00_b.mux_onehot(imp)#3 > # Loading proc_common_v1_00_b.mux_onehot(imp)#4 > # Loading proc_common_v1_00_b.mux_onehot(imp)#5 > # Loading proc_common_v1_00_b.mux_onehot(imp)#6 > # Loading plb_v34_v1_02_a.plb_wr_datapath(simulation)#1 > # Loading proc_common_v1_00_b.mux_onehot(imp)#7 > # Loading plb_v34_v1_02_a.plb_rd_datapath(simulation)#1 > # Loading plb_v34_v1_02_a.plb_slave_ors(implementation)#1 > # Loading /opt/modeltech/6.2a/linux/../ieee.std_logic_unsigned(body) > # Loading proc_common_v1_00_b.or_gate(imp)#1 > # Loading proc_common_v1_00_b.or_gate(imp)#2 > # Loading proc_common_v1_00_b.or_gate(imp)#3 > # Loading proc_common_v1_00_b.or_gate(imp)#4 > # Loading proc_common_v1_00_b.proc_common_pkg(body) > # Loading /opt/modeltech/6.2a/linux/../synopsys.attributes > # Loading /opt/modeltech/6.2a/linux/../ieee.std_logic_misc(body) > # Loading plb_v34_v1_02_a.plb_arbiter_logic(implementation)#1 > # Loading plb_v34_v1_02_a.plb_priority_encoder(simulation)#1 > # Loading plb_v34_v1_02_a.priority_encoder(simulation) > # Loading plb_v34_v1_02_a.qual_request(simulation) > # Loading /home/ferorcue/simlib/EDK8.2_mti_se_linux/ISE_Lib/ > unisim/.muxcy(muxcy_v) > # Loading /home/ferorcue/simlib/EDK8.2_mti_se_linux/ISE_Lib/ > unisim/.lut4(lut4_v) > # Loading plb_v34_v1_02_a.pending_priority(simulation)#1 > # Loading plb_v34_v1_02_a.qual_priority(qual_priority) > # Loading plb_v34_v1_02_a.pend_request(simulation)#1 > # Loading plb_v34_v1_02_a.arb_addr_sel(simulation)#1 > # Loading plb_v34_v1_02_a.arb_control_sm(simulation)#1 > # Loading plb_v34_v1_02_a.gen_qual_req(simulation)#1 > # Loading plb_v34_v1_02_a.muxed_signals(implementation)#1 > # Loading proc_common_v1_00_b.or_bits(implementation) > # Loading plb_v34_v1_02_a.arb_registers(simulation)#1 > # Loading plb_v34_v1_02_a.bus_control(simulation) > # Loading plb_v34_v1_02_a.watchdog_timer(simulation)#1 > # Loading proc_common_v1_00_b.down_counter(simulation)#1 > # Loading plb_v34_v1_02_a.plb_interrupt(plb_interrupt)#1 > # Loading /home/ferorcue/simlib/EDK8.2_mti_se_linux/ISE_Lib/ > unisim/.fdre(fdre_v)#1 > # Loading plb_v34_v1_02_a.bus_lock_sm(implementation) > # Loading work.opb_wrapper(structure)#1 > # Loading /opt/modeltech/6.2a/linux/../ieee.std_logic_signed(body) > # Loading proc_utils_v1_00_a.conv_funs_pkg(body) > # Loading opb_arbiter_v1_02_e.opb_arb_pkg(body) > # Loading opb_v20_v1_10_c.opb_v20(imp)#1 > # Loading opb_arbiter_v1_02_e.or_gate(imp)#1 > # ** Fatal: (vsim-3348) Port size (1) does not match actual size (32) > for port '/system/opb/opb/opb_abus_i/y'. > # Time: 0 ps Iteration: 0 Instance: /system/opb/opb/opb_abus_i > File: /opt/xilinx/EDK8.2/hw/XilinxProcessorIPLib/pcores/ > opb_arbiter_v1_02_e/hdl/vhdl/or_gate.vhd Line: 125 > # FATAL ERROR while loading design > # Error loading design > > > > > Do you know why "gmake" is not working? > > Windows uses "make" and it compiles the libraries, but later It should > work. Why I have a problem with a ip core from Xilinx > (opb_arbiter_v1_02_e). > > Do you think, that if I get the "gmake" working in Solaris it will > compile the libraries in a different way and the simulation will work? > > Thank you for your consideration >Article: 119554
I'm making an assumption that you're using EDK and the opb_ddr core. This core instantiates IOBUF primitive on DDR_DQ port, you cannot use the output of the IOBUF for internal logic connections. You'll need to access the nets that connect up the T, I, and O ports of the IOBUF. You can do this from opb_ddr by connecting to the DDR_DQ_O, DDR_DQ_I, or DDR_DQ_T pins instead of DDR_DQ. koustav79@gmail.com wrote: > Hello everybody, > > I was trying NGDbuild for a DDR memory controller > implementation. I am getting the following error: > > ERROR:NgdBuild:924 - bidirect pad net 'cntrl0_ddr1_dq(0)' is driving > non-buffer > primitives: > pin I0 on block _n00001 with type LUT4 > > Does anybody encountered this before? Any suggestions will be helpful. > > Thanks, > Koustav >Article: 119555
Hi
I need to implement 33-bit data BRAM.
Obviously, following BRAM will not work.
Does anyone suggest how to implement 33-bit data, if possible?
Thank you in advance.
component RAMB16_S36_S36
port (DOA : out STD_LOGIC_VECTOR (datawidth-1 downto 0);
DOB : out STD_LOGIC_VECTOR (datawidth-1 downto 0);
DOPA : out STD_LOGIC_VECTOR (3 downto 0);
DOPB : out STD_LOGIC_VECTOR (3 downto 0);
ADDRA : in STD_LOGIC_VECTOR (8 downto 0);
ADDRB : in STD_LOGIC_VECTOR (8 downto 0);
CLKA : in STD_ULOGIC;
CLKB : in STD_ULOGIC;
DIA : in STD_LOGIC_VECTOR (datawidth-1 downto 0);
DIB : in STD_LOGIC_VECTOR (datawidth-1 downto 0);
DIPA : in STD_LOGIC_VECTOR (3 downto 0);
DIPB : in STD_LOGIC_VECTOR (3 downto 0);
ENA : in STD_ULOGIC;
ENB : in STD_ULOGIC;
SSRA : in STD_ULOGIC;
SSRB : in STD_ULOGIC;
WEA : in STD_ULOGIC;
WEB : in STD_ULOGIC);
Article: 119556On 8 May 2007 06:49:13 -0700, Antti <Antti.Lukats@xilant.com> wrote: >On 8 Mai, 15:32, Brian Drummond <brian_drumm...@btconnect.com> wrote: >> On 3 May 2007 01:18:48 -0700, Antti <Antti.Luk...@xilant.com> wrote: >> >Xilinx hasnt provided ANY MicroBlaze demos for the new Spartan-3A >> >Starterkit so others have to fill the gap, ... >> Heh, at least you are (rightly) one of the inner circle who has the >> board! >> >> Consider the situation for those in the cold outside who might happen to >> want one. ... rant snipped >> - Brian > >Oh gosh - you know I asked my firend in the US to order the S3A board >IMMEDIATLY when it was announced to be available. To our suprise it >arrived from Avnet US very quickly (my last order from Avnet US >Virtex-4 kit was delayes more then 6 months). Well it actually arrived! So now to try it out... - BrianArticle: 119557
bwilson79@gmail.com wrote:
> In our design, there are 80MHz system-synchronous interfaces between
> two FPGA's. There is a common clock source on the board with matched
> trace lengths to each of the FPGA's.
Matched lengths is good.
You might consider a zero-delay clock buffer
at the source to allow independent line termination
resistors.
> Can we [almost] guarantee
> that the clocks coming out of the DCM's on the separate FPGA's are
> near phase-aligned, assuming matched trace lengths coming in?
Close enough for most purposes.
> If anyone could reassure me that this design is relatively common
Don't know, but I've done very similar boards with 3 or 4
matched clocks that worked fine.
-- Mike Treseler
Article: 119558For some reason i am not able to download ISE service pack for 9.1i version. Can any body upload it ?Article: 119559
Hi everyone! I'm new to the group and quite a beginner in FPGA business. I have this very general question on BSDL files and JTAG - is there any possibility to include any internal signal (not connected directly to the output pin) in the scan register? ChrisArticle: 119560
Hello, Maybe I don't have enough background, but I have a ISE project with several black-boxed components instantiated in my toplevel design. This toplevel vhdl-module was generated by the EDK. Now I have the problem, that XST throws errors, when I try to check the syntax, because it can't find the instantiated modules, even they are marked black boxed. So I added the concerning wrapper vhdl-sources also generated by the EDK to the ISE project. But now I run in a kind of recursion, because these wrapper modules use several library modules themselves, that are unknown to the ISE. Why does the ISE even look inside the wrapper modules, when it shouldn't take care for their implementation at all, because of the "black_box"-ing. Did I get you wrong? thanks Paulo Dutra schrieb: > This forces XST to ignore analyzing/elaborating the HDL files for > components that were marked black_box. This makes sense as the > implementation for the blackbox component will be filled by a supplied > netlist by the user in the later NGDBUILD assembly stage. > > L. Schreiber wrote: >> Hi again, >> >> What does the setting of the attribute box_type to "black_box" for my >> toplevel components effect (concerning modular design flow)? >> >> Syntax checking in ISE projnav searchs for the components' modules >> anyway, whether black boxed or not. >> >> greetingsArticle: 119561
Keep the RAMB16_S36_S36 definitions as they started (no datawidth-1, please) out so your primitive doesn't generate errors when it tries to get reconciled with the code. Instead, just use the 32 data bits and 1 of the 4 parity bits. Ta da! 33-bit memory. "Pasacco" <pasacco@gmail.com> wrote in message news:1179860020.963159.287400@z24g2000prd.googlegroups.com... > Hi > > I need to implement 33-bit data BRAM. > Obviously, following BRAM will not work. > Does anyone suggest how to implement 33-bit data, if possible? > Thank you in advance. > > component RAMB16_S36_S36 > port (DOA : out STD_LOGIC_VECTOR (datawidth-1 downto 0); > DOB : out STD_LOGIC_VECTOR (datawidth-1 downto 0); > DOPA : out STD_LOGIC_VECTOR (3 downto 0); > DOPB : out STD_LOGIC_VECTOR (3 downto 0); > ADDRA : in STD_LOGIC_VECTOR (8 downto 0); > ADDRB : in STD_LOGIC_VECTOR (8 downto 0); > CLKA : in STD_ULOGIC; > CLKB : in STD_ULOGIC; > DIA : in STD_LOGIC_VECTOR (datawidth-1 downto 0); > DIB : in STD_LOGIC_VECTOR (datawidth-1 downto 0); > DIPA : in STD_LOGIC_VECTOR (3 downto 0); > DIPB : in STD_LOGIC_VECTOR (3 downto 0); > ENA : in STD_ULOGIC; > ENB : in STD_ULOGIC; > SSRA : in STD_ULOGIC; > SSRB : in STD_ULOGIC; > WEA : in STD_ULOGIC; > WEB : in STD_ULOGIC);Article: 119562
"Silver" <K.Pisaniec@gmail.com> wrote in message news:f2vgaq$5o2$1@matrix2.idg.com.pl... > Hi everyone! > > I'm new to the group and quite a beginner in FPGA business. I have this > very general question on BSDL files and JTAG - is there any possibility to > include any internal signal (not connected directly to the output pin) in > the scan register? > > Chris There is a primitive you can use to get JTAG access. See for instance the BSCAN_SPARTAN3 library element. You should find similar primitives for different families. Some folks on this newsgroup have utilized those primitives for more than just ChipscopePro (Xilinx) or Identify (Synplicity)debugging. - John_HArticle: 119563
Yes, there is documentation on the Xilinx site about how to do it and also many previous posts on this very newsgroup about it. Think BSCAN. ---Matthew Hicks > Hi everyone! > > I'm new to the group and quite a beginner in FPGA business. I have > this very general question on BSDL files and JTAG - is there any > possibility to include any internal signal (not connected directly to > the output pin) in the scan register? > > Chris >Article: 119564
<bwilson79@gmail.com> wrote in message news:1179854709.907510.165320@g4g2000hsf.googlegroups.com... > This may seem like an elementary question/application, but I'll bring > it up nonetheless in hopes of getting a thorough understanding... > > In our design, there are 80MHz system-synchronous interfaces between > two FPGA's. There is a common clock source on the board with matched > trace lengths to each of the FPGA's. The clocks then go into DCM's > and the DCM 1x output clock is used to clock the IOB registers and > also used as internal feedback to the DCM. Can we [almost] guarantee > that the clocks coming out of the DCM's on the separate FPGA's are > near phase-aligned, assuming matched trace lengths coming in? These > are V4-LX160 parts. I was looking over the V4 user guide and couldn't > find a fitting clocking application example. It seems it can never be > fully guaranteed, since the DCM's deskew compensation on each of the > FPGA's will certainly differ, not to mention small process > variations. Since we have a 12.5ns period, I think we should have > room in our timing budget to absorb these small phase differences. I > will ensure that all the inputs and outputs utilize the IOB registers. > > If anyone could reassure me that this design is relatively common and > safe, and provide me with some information regarding the DCM output > clock relationships on the separate devices, I will feel much better. > I've definitely worked with these types of designs in the past, but > never fully understood why things just work. Do you *really* need the internals of the chips to be synchronized to the system clock? The specifications that are usually important are the setup/hold times of input data and clock-to out times relative to the system-synchronous clock. The DCM usually improves these timing margins to eliminate hold time and reduce the clock-to-out. The only reason I could think of to force the internals to the same clock would be to 1) build up a power-plane resonance, or 2) to have analog-like correlation between digital signals from multiple chips - generally not a good idea. Perhaps your problem isn't a problem. - John_HArticle: 119565
bwilson, To insure the system remains synchronous, and aligned with the clocks as delivered to the devices, a DDR output should be used which is then routed right back to the DCM CLKFB input. So, DCM CKL0 output, to a BUFG, to a DDR output IO, which is connected to an input IO, to a IBUFG, back to the CLKFB input pin of the DCM. In this way, regardless of any variations on the devices, the difference between the DDR output, and the system reference clock input, is kept to under 100 ps at all times. Leaving the feedback off of the IO pins (doing this internally), will remove variation in the device BUFG, but will not compensate for variation in the IO, and IBUFG's. At 80 MHz, you may have a great deal of slack, but I provide you with this information, just in case you need better matching (which can be done as described, above). AustinArticle: 119566
Sorry, I don't know much about the check syntax function. I think what you describe is a concern. The "box_type" attributes are synthesis directives that only XST understands when it parses/analyzes HDL files. Given that the check syntax function doesn't understand XST attributes, then it will flag an error for components that do not have an associated entity declaration. You have the correct line of thinking by including wrapper modules. But, this will get into trouble as you outlined. What's needed here are wrapper modules that declare blackbox entity declarations. For your situation, you would have to bypass the check syntax. The HDL is still correct for synthesis. L. Schreiber wrote: > Hello, > > Maybe I don't have enough background, but I have a ISE project with > several black-boxed components instantiated in my toplevel design. This > toplevel vhdl-module was generated by the EDK. Now I have the problem, > that XST throws errors, when I try to check the syntax, because it can't > find the instantiated modules, even they are marked black boxed. So I > added the concerning wrapper vhdl-sources also generated by the EDK to > the ISE project. But now I run in a kind of recursion, because these > wrapper modules use several library modules themselves, that are unknown > to the ISE. > > Why does the ISE even look inside the wrapper modules, when it shouldn't > take care for their implementation at all, because of the > "black_box"-ing. Did I get you wrong? > > thanks > > Paulo Dutra schrieb: >> This forces XST to ignore analyzing/elaborating the HDL files for >> components that were marked black_box. This makes sense as the >> implementation for the blackbox component will be filled by a supplied >> netlist by the user in the later NGDBUILD assembly stage. >> >> L. Schreiber wrote: >>> Hi again, >>> >>> What does the setting of the attribute box_type to "black_box" for my >>> toplevel components effect (concerning modular design flow)? >>> >>> Syntax checking in ISE projnav searchs for the components' modules >>> anyway, whether black boxed or not. >>> >>> greetingsArticle: 119567
On 22 maio, 17:28, Alan Nishioka <a...@nishioka.com> wrote: > On May 22, 7:03 am, luciorech <lucior...@gmail.com> wrote: > > > I'm using PLB to read and write 64bit data through burst transactions. > > I can read and write data correctly, but watching the signals through > > chipscope I can see a strange behavior: the PLB_MWrDAck and > > PLB_MRdDAck don't occur in consecutive clock cycles. For instance, > > during a 16 words burst read, instead of taking 16 clock cycles to > > read all data after the bus has been granted to my peripheral, it > > takes about 190 clock cycles. Did anyone have the same problem?? > > PLB burst can indeed read/write in consecutive clock cycles. > Perhaps your peripheral can't supply data fast enough? > Assuming Xilinx ppc, the cache only reads/write 4 cycles (8 words) at > a time. > > Alan Nishioka Hi, I'm reading/writing directly from the DDR, so this can't be the problem. The peripheral is also using the highest priority and I double checked the signals, they are exactly how the IBM's Guide say. Lucio RechArticle: 119568
Symon wrote: (snip on TAB character) > ...but I'd recommend CSV as a better solution for that application. CSV is probably best as long as the fields can't contain a comma. If they do, then some will quote each string, unless the strings can contain quotes. If the do, then... -- glenArticle: 119569
On Apr 6, 12:04 pm, Markus Knauss <markus.kna...@gmx.net> wrote: > Jon Elson wrote: > > > Markus Knauss wrote: > > >> Hi all, > > >> at the moment, we are using AT17LV010configurationdevices for a > >> spartan 2S100. > >> I have to look for a different solution which is not so expensive. > > >> The Xilinx XC17V01 is OTP and more expensive than the AT17LV010. > > >> Does someone know a different prom (OTP, EEPROM, Flash)? > > > SST makes a series of VERY cheap serial flash memories. I figured out > > how to > > create the command bit stream that it needs to command a read starting > > from addr > > zero function, using just 2 SSI CMOS chips in SSOP packages, so the > > interface is > > under $1, and the SST chip is well under $2 in small quantities. I had > > to make my > > own programmer, and a little C program to read the .MCS file and program > > the > > device. I haven't actually produced a product using this setup yet, but > > I did build > > a prototype board for Spartan 2E and verify that it could do the FPGA > > configure. > > I did this for the 2S50E part, but SST has up to 4 mbit chips, I think, > > that should > > handle the 2S100. > > > Jon > > Thank you Jon for the hint. It should be possible to get a preprogrammed > 8 bit controller (PIC, AVR) for 1$ and with a little bit banging in > software you could use the original .mcs file. > > Markus- Hide quoted text - > > - Show quoted text - Markus: Have you had a chance to discuss pricing with your local Sales Rep ? Another option is a low cost 1 Mbit with JTAG that Atmel should begin sampling in a few weeks. Yad [Atmel]Article: 119570
"bwilson79@gmail.com" <bwilson79@gmail.com> wrote: >This may seem like an elementary question/application, but I'll bring >it up nonetheless in hopes of getting a thorough understanding... > >In our design, there are 80MHz system-synchronous interfaces between >two FPGA's. There is a common clock source on the board with matched >trace lengths to each of the FPGA's. The clocks then go into DCM's >and the DCM 1x output clock is used to clock the IOB registers and >also used as internal feedback to the DCM. Can we [almost] guarantee >that the clocks coming out of the DCM's on the separate FPGA's are >near phase-aligned, assuming matched trace lengths coming in? These >are V4-LX160 parts. I was looking over the V4 user guide and couldn't >find a fitting clocking application example. It seems it can never be >fully guaranteed, since the DCM's deskew compensation on each of the >FPGA's will certainly differ, not to mention small process >variations. Since we have a 12.5ns period, I think we should have >room in our timing budget to absorb these small phase differences. I >will ensure that all the inputs and outputs utilize the IOB registers. > >If anyone could reassure me that this design is relatively common and >safe, and provide me with some information regarding the DCM output >clock relationships on the separate devices, I will feel much better. >I've definitely worked with these types of designs in the past, but >never fully understood why things just work. > Just make sure the sending and receiving flipflops are inside the IOB and you will be fine. You'll have 12.5ns minus some IOB delays and jitter uncertainty (say 500ps) to transport the signal over the PCB. You can probably get away with using a slow slew-rate setting. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 119571
Does anybody know if this is a 90nm device from their AT72K process? It would seem so from the device's Vdd (1.08v core). - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 119572
Thanks for ur response. I never worked with FPGAs before. I always worked on the layers above the Device Drivers. Now I am getting chance to work with the hardware. I will be configuring the FPGAs and dealing with the exception handling, etc. Just want to brush up on these topics. I have been reading some general documents. Thought of clarifying my questions with experienced people here.Article: 119573
I am using spartan3 fpga with lvcmos33 output pin set to 16 mA drive strength and fast slew rate. I am assuming that 16 mA is the source current at 3.3V as my VCCO voltage is 3.3V. I would like to know what is the sink current capability for LVCMOS33 OUTPUT pin is. Or is there any way I can increase the sink current capability? I am using this output pin as open drain type with 150 Ohm pulllup to 1.8V Plane. With this I am seeing low swing of 400mV. If the sink current was truely 16 mA, then the low swing should have been 0v. I raised the pullup value to 330 Ohms and the low swing was 200mV. In my opinion the 16 mA is source current capability. I need to make the output go down to 0v. Any help will be great.Article: 119574
Let me take the mystery out of source and sink capabilities. In a cormal CMOS output, you have a p-chsnnrl transistor pulling High, towards Vcco, and an n-chnnel transistor pulling Low towards ground. In an active output, one-but only one-of these transistors is always turned on. The sink or source capability is always documented for a certain difference from the supply ends (usually 400 mV for sink) since only zero current will get you precisely to ground (or Vcco) In your case you permanently disabled the pull-up transistor in order to achieve open drain operation. You should see less than 400 mV at 16 mA sink current. That is, if your Vcco is actually 3.3 V. if you have lowered that voltage, you will get a weaker output. Look in the data sheet whether there is a stronger output current option. Consider an active transistor just as a resistor (to the first approximation)16 mA at 400 mV = 25 Ohm. I hope I have explained the basics of CMOS I/O output strength. Peter Alfke, Xilinx, from home =================== On May 22, 7:53 pm, Test01 <cpan...@yahoo.com> wrote: > I am using spartan3 fpga with lvcmos33 output pin set to 16 mA drive strength and fast slew rate. I am assuming that 16 mA is the source current at 3.3V as my VCCO voltage is 3.3V. I would like to know what is the sink current capability for LVCMOS33 OUTPUT pin is. Or is there any way I can increase the sink current capability? > > I am using this output pin as open drain type with 150 Ohm pulllup to 1.8V Plane. With this I am seeing low swing of 400mV. If the sink current was truely 16 mA, then the low swing should have been 0v. I raised the pullup value to 330 Ohms and the low swing was 200mV. > > In my opinion the 16 mA is source current capability. I need to make the output go down to 0v. > > Any help will be great.
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