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

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

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

Custom Search

Messages from 119550

Article: 119550
Subject: Re: Does FPGA need CPU for processing a packet/frame
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 22 May 2007 10:58:19 -0700
Links: << >>  << T >>  << A >>
"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_H 



Article: 119551
Subject: Re: EDK 8.1i to EDK 9.1i UCF file errors
From: Paulo Dutra <paulo.dutra@xilinx.com>
Date: Tue, 22 May 2007 11:12:42 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: "black_box"-ing of components in toplevel
From: Paulo Dutra <paulo.dutra@xilinx.com>
Date: Tue, 22 May 2007 11:19:50 -0700
Links: << >>  << T >>  << A >>
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.
> 
> greetings

Article: 119553
Subject: Re: Problems to simulate (behavioural) in XPS
From: Paulo Dutra <paulo.dutra@xilinx.com>
Date: Tue, 22 May 2007 11:28:53 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Error in NGDBuild
From: Paulo Dutra <paulo.dutra@xilinx.com>
Date: Tue, 22 May 2007 11:36:20 -0700
Links: << >>  << T >>  << A >>
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
Subject: how 33-bit BRAM?
From: Pasacco <pasacco@gmail.com>
Date: 22 May 2007 11:53:41 -0700
Links: << >>  << T >>  << A >>
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: 119556
Subject: Re: First MicroBlaze demo design for Spartan-3A Starterkit
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Tue, 22 May 2007 19:56:43 +0100
Links: << >>  << T >>  << A >>
On 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...

- Brian

Article: 119557
Subject: Re: System-synchronous interface clocking between FPGA's
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 22 May 2007 12:09:29 -0700
Links: << >>  << T >>  << A >>
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: 119558
Subject: ISE Service pack
From: sudarshan.onkar@gmail.com
Date: 22 May 2007 12:17:32 -0700
Links: << >>  << T >>  << A >>
For some reason i am not able to download ISE service pack for 9.1i
version.
Can any body upload it ?


Article: 119559
Subject: JTAG FPGA Debugging
From: "Silver" <K.Pisaniec@gmail.com>
Date: Tue, 22 May 2007 21:34:11 +0200
Links: << >>  << T >>  << A >>
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: 119560
Subject: Re: "black_box"-ing of components in toplevel
From: "L. Schreiber" <l.s.rockfan@web.de>
Date: Tue, 22 May 2007 21:48:43 +0200
Links: << >>  << T >>  << A >>
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.
>>
>> greetings

Article: 119561
Subject: Re: how 33-bit BRAM?
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 22 May 2007 12:56:41 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: JTAG FPGA Debugging
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 22 May 2007 13:00:37 -0700
Links: << >>  << T >>  << A >>
"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_H 



Article: 119563
Subject: Re: JTAG FPGA Debugging
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Tue, 22 May 2007 20:03:06 +0000 (UTC)
Links: << >>  << T >>  << A >>
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
Subject: Re: System-synchronous interface clocking between FPGA's
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 22 May 2007 13:04:29 -0700
Links: << >>  << T >>  << A >>
<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_H 



Article: 119565
Subject: Re: System-synchronous interface clocking between FPGA's
From: austin <austin@xilinx.com>
Date: Tue, 22 May 2007 13:14:56 -0700
Links: << >>  << T >>  << A >>
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).

Austin

Article: 119566
Subject: Re: "black_box"-ing of components in toplevel
From: Paulo Dutra <paulo.dutra@xilinx.com>
Date: Tue, 22 May 2007 13:55:09 -0700
Links: << >>  << T >>  << A >>
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.
>>>
>>> greetings

Article: 119567
Subject: Re: PLB behaviours strangely during burst transactions
From: luciorech <luciorech@gmail.com>
Date: 22 May 2007 14:23:52 -0700
Links: << >>  << T >>  << A >>
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 Rech


Article: 119568
Subject: Re: How to insert tab in Write() function in VHDL
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 22 May 2007 13:51:10 -0800
Links: << >>  << T >>  << A >>
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...

-- glen


Article: 119569
Subject: Re: Config PROM for Spartan II
From: Atmel_PLDs_Rock <ydhami@gmail.com>
Date: 22 May 2007 14:55:41 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: System-synchronous interface clocking between FPGA's
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 22 May 2007 22:23:27 GMT
Links: << >>  << T >>  << A >>
"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.nl

Article: 119571
Subject: Re: Atmel release Metal Programmable Cell Fabric uC ARM9
From: Adam Megacz <megacz@cs.berkeley.edu>
Date: Tue, 22 May 2007 18:01:04 -0700
Links: << >>  << T >>  << A >>

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 C380

Article: 119572
Subject: Re: Does FPGA need CPU for processing a packet/frame
From: NewToFPGA <hetzme@yahoo.com>
Date: 22 May 2007 19:16:51 -0700
Links: << >>  << T >>  << A >>
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
Subject: LVCMOSS33 I/O sink current
From: Test01 <cpandya@yahoo.com>
Date: Tue, 22 May 2007 19:53:00 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: LVCMOSS33 I/O sink current
From: Peter Alfke <alfke@sbcglobal.net>
Date: 22 May 2007 20:39:07 -0700
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search