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
The ISP Daisy Chain Download program will read and save as JEDEC file the device. Set up the configuration you need to be able to 'see' the device, and change the command type to read and save. press the button and VOILA! it is written to the file you specifiy. Good Luck, Mike Thomas - LSC FAE Article 18586 of comp.arch.fpga:Article: 18326
have you already tried the -i switch (for interpreted mode). this do not solve the problem with the c compiler, but you can compile your code. kai -- ------------------------------------------ Kai Troester IMMS - Institut fuer Mikroelektronik- und Mechatronik-Systeme gGmbH Langewiesener Strasse 22 98693 Ilmenau Germany Tel: +49(3677)6783-42 Fax: +49(3677)6783-38 E-mail: kai.troester@imms.de ------------------------------------------- Article 18589 of comp.arch.fpga:Article: 18327
Ben wrote: > > When I try to compile a vhdl code for simulation with Synopsys tools and > the following command, > --- > vhdlan -nc -check -w mylib ./mydesign.vhd > --- > > the vhdl code is analyzed, but there come warning messages like > --- > Warning: vhdlan, 1500 ./mydesign.vhd(321): > > Error compiling file : ./mylib/mydesign__RTL.c, Reverting to > Interpreted code for design unit : RTL. > > Warning: vhdlan, 1504 ./mydesign.vhd(321): > > The C compiler, specified as /opt/SUNWspro/bin/cc, doesn't work > properly. > Change CS_CCPATH in the setup file or specify a path by the > -ccpath option. > Reverting to Interpreted Code. > --- > > I don't think there's really a problem with the specified C compiler > since it exists and works well with C code. > I also tried changing the -ccpath option to /usr/ucb/cc, but the result > is same. > Hi, I remember I had the same kind of problem when using vhdlan...unfortunately I dont remember exctly if/how I fixed it. When you use vhdlan, Synopsys create a C equivalent of your VHDL code, then it tries to compile it. This operation is meant to simulate designs faster. However, this is not a good solution for debug, since you can't use Breakpoints/Trace Mode...In the interpreted mode, simulation is slower, but better for debug. The CS_CCPATH appearing in the error message in located in the file .synpsys_vss.setup, in the $SYNOPSYS/admin/setup (or something like that). Maybye, your C compiler needs some options to work properly with vhdlan. I remember I read in the SOLV-IT articles that vhdlan is "optimized" for gcc, you should try a search with Adobe Acrobat in these articles, one shows the right configuration and option to use gcc (which I believe is free). Good luck ! Matthieu Liger Article 18588 of comp.arch.fpga:Article: 18328
You normally have some form of Non Volatile Memory in the system. At reset, the memory is read into the FPGA configuration bits. You may want to have a programmer for the NVM though. Atmel has the AT17 series of Flash configurators which is programmed using the ATDH2200E programmer also available from Atmel. -- This is a personal view which may or may not be shared by my employer Atmel Sweden Ulf Samuelsson ulf 'a't atmel 'd'o't com Sharad Kumar skrev i meddelandet <38054e0a@apathy.ibsystems.com>... > >Hi, > >I am interested in downloading my design in the xilinx netlist file format (.xnf) onto a Xilinx FPGA. >I wated to to know what kind of device programmers are available, what would be a good option and > where I can get more information about it. I am keen to use either the Xilinx -4000 series or the > Xilinx Virtex series of FPGA's. > >thanks, sharad Article 18590 of comp.arch.fpga:Article: 18329
If someone want to have a look at the FPSLIC, The FPGA+40 Mhz AVR RISC+Peripherals + Memory chip under development at Atmel, Here's the link: http://www.atmel.com/atmel/products/prod39.htm -- This is a personal view which may or may not be shared by my employer Atmel Sweden Ulf Samuelsson ulf 'a't atmel 'd'o't com Article 18591 of comp.arch.fpga:Article: 18330
Greetings This is semimonthly announcement of Verilog FAQ. Verilog FAQ is located at http://www.angelfire.com/in/verilogfaq/ Alternate Verilog FAQ is an attempt to gather the answers to most Frequently Asked Questions about Verilog HDL in one place. It also contains list of publications, services, and products. Alternate Verilog FAQ is divided into three logical parts. Part 1 : Introduction and misc. questions Part 2 : Technical Topics Part 3 : Tools and Services What's New section outlines the changes in different versions and announcements. Links connects you to related informative links in internet. Your suggestions to make this FAQ more informative are welcome. Rajesh Bawankule (Also Visit Verilog Center : http://www.angelfire.com/in/rajesh52/verilog.html ) Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18331
Greetings, Has anyone out there uses Xilinx's Synthesizable PCI Bridge design? If so, any comments... good, bad, indifferent? Thanks in advance, Ken Prager Raytheon Systems Co. prager@ieee.org Article 18550 of comp.arch.fpga:Article: 18332
From time to time people ask for a Xilinx MAKE file. Here is one
I use. I call it from an ancient copy of Borland TMAKE. The
PERL routine at the end can be deleted if your tools generate
EDIF which goes straight into the Xilinx stuff; mine never does.
This is a simple MAKE; a wizard could do better. This design flow
does not use floorplanning or separate compilation of RLOC modules,
both of which I tend to grind via additional makes.
Should deja wrap the lines, you will have to unwrap. Comments begin
with a #.
#####################################################################
# make file for an M2 build
# comments from the xilinx .usg files
#dn is the design name
part=xv6400e-9-bg12345
dn=mydesign
perl=c:\etc\perl5\bin\perl
all: $(dn).hex $(dn).twr
# bitgen generates a programming file, options:
# Usage: bitgen [-d] [-j] [-b] [-w] [-l] [-m] [-t] [-n] [-u] [-a] {-g
# <setting_value>} <infile[.ncd]> [<outfile>] [<pcffile[.pcf]>]
# Where:
# -d = Don't Run DRC (Design Rules Checker)
# -j = Don't create bit file
# -b = Create rawbits file
# -w = Overwrite existing output file
# -f <cmdfile> = Read command line arguments from file <cmdfile>
# -g <opt:val> = Set option to value, options are (1st is default):
#
# typical commands in bitgen.ut:
# -g ConfigRate 4
# -g StartupClk Cclk
# -g CclkPin Pullup
# -g DonePin Pullup
# -g M0Pin Pullup
# -g M1Pin Pullup
# -g M2Pin Pullup
# -g ProgPin Pullup
# -g TckPin Pullup
# -g TdiPin Pullup
# -g TdoPin Pullup
# -g TmsPin Pullup
# -g DONE_cycle 3
# -g GSR_cycle Done
# -g GWE_cycle Done
# -g GTS_cycle Done
# -g LCK_cycle NoWait
# -g Persist No
# -g DriveDone Yes
# -g DonePipe Yes
#
# promgen options:
# -b Disable bit swapping. Only valid for hex format (-p hex).
#
# -s <size> PROM size in K bytes (must be power of 2), multiple sizes
imply
# splitting the bitstream(s) into multiple PROMs.
#
# -x <xilinx_prom>
# Specific Xilinx PROM, multiple PROMs imply splitting the
# bitstream(s) into multiple PROMs.
#
# -p <format> PROM format (mcs, exo, hex, or tek)
#
# -o <file> Output PROM file name (default matches first .bit file),
# multiple names may be specified when splitting PROMs.
#
# -u <hexaddr> <file[.bit]> {<file[.bit]>}
# Load .bit file(s) up from address. Multiple .bit files
are
# daisychained to form a single PROM load.
#
# -d <hexaddr> <file[.bit]> {<file[.bit]>}
# Load .bit file(s) down from address. Multiple .bit files
are
# daisychained to form a single PROM load.
#
# -n <file[.bit]> {<file[.bit]>}
# Load .bit file(s) up or down starting from the next
address
# following previous load. Multiple .bit files are
daisychained
# to form a single PROM load. Must follow a -u, -d, or -n
option.
#
# -r <promfile>
# Load the PROM file. The -r and the -u, -d and -n options
are
# mutually exclusive.
#
# -f <cmdfile>
# Read command line arguments from file <cmdfile>.
#
#At least one -r, -u, or -d option must appear in the command line.
$(dn).hex : $(dn).ncd bitgen.ut
bitgen $(dn).ncd -w -f bitgen.ut
promgen -p hex -s 512 -o $(dn).hex -u 0 $(dn).bit
# generate a timing report
#<design[.ncd]> ... Xilinx physical design file (no default)
#<constraint[.pcf]> ... optional physical constraint file (default
design.pcf)
#-o <report[.twr]> ... optional report output file (default design.twr)
#-e [<limit>] ... produce detailed error report for timing
constraints,
# optionally limited to the specified number of
items
#-v [<limit>] ... produce verbose timing report for timing
constraints
# optionally limited to the specified number of
items
#-s <speed> ... run analysis with the specified speed grade
#-a ... perform advanced design analysis in the absence
# of a constraint file
#-u ... report paths which are not covered by the
constraints
# within the PCF file.
#-dfs ... use depth-first search timing analysis
#-kpaths ... use kpaths timing analysis
#-skew ... analyze clock skew for all clocks including
those
# utilizing non-dedicated clock routing resources
#-stamp <stampfile> ... optionally generate STAMP model and data files
$(dn).twr : $(dn).ncd
trce $(dn).ncd $(dn).pcf -u -e 3 -o $(dn).twr
# PAR: Places and Routes a design's logic components
# -l = Overall effort level (same as "-ol").
# -ol = Overall effort level. Level 5 is maximum effort.
# Default: dependent upon device family.
# -pl = Placer effort level. Level 5 is maximum effort. Overrides
# any placer effort level implied by "-ol" or "-l" options.
# Default: dependent upon device family.
# -rl = Router effort level. Level 5 is maximum effort. Overrides
# any router effort level implied by "-ol" or "-l" options.
# Default: dependent upon device family.
# -t = Placer cost table entry. Start at this entry.
# Default: 1.
# -p = Don't run the placer. (Keep current placement)
# -i = Run n iterations of the router. These router iterations are run
# to route the design completely and meet all timing constraints.
# Default: Run until router decides it will not complete
# without diverging.
# -c = Run n cleanup passes of the router. These router iterations are
# run to minimize resource utilization overall without degrading
# timing or routing.
# Default: 1.
# -d = Run n delay based cleanup passes of the router, n >= 0. These
# router iterations are run to minimize net delay over all of the
# nets without degrading timing or routing.
# Default: 0.
# -e = Run n delay based cleanup passes of the router if there are 0
# unrouted connections, n >= 0.
# Default: 0.
# -k = Re-entrant route. Keep the current placement and routing and
# continue the routing process.
# -r = Don't run the router.
# -w = Overwrite. Allows overwrite of an existing file (including
input
# file). If specified output is a directory, allows files in
# directory to be overwritten.
# -f = Read par command line arguments and switches from file.
# -gf = Use a guide file to place and route.
# Keep matching block names.
# Keep matching net names/pins.
# -gm = Guide mode to be used.
# leverage: Use initial design {guided or not} as hint.
# exact: Lock down all placement and routing.
# Default: exact.
# -n = P&R Iterations at this level. Use "-n 0" to run until a
# successful result is generated. The result must be fully
# routed and meet timing constraints. The output file must
# have a ".dir" extension for -n option != 1.
# Default: 1.
# -s = Save "n" best results for this run. Best is defined by the
# design score which is a combination of unroutes, net delay,
# and failed timing values.
# Default: Save all results.
# -m = Multi task par run. File <node list file> ",
# contains a list of node names on which to run the jobs.
# (This option is not currently supported on WIN NT/WIN 95
# systems).
# -x = Ignore Timing constraints in physical constraints file.
# -ub = Use bonded IOs. Allow bonded IO sites to be used for internal
# logic. This includes IOs which do not require the pad as well
# as allowing the router to route through the IO site.
# <infile> = Name of input NCD file.
# <outfile> = Name of output NCD file or output directory.
# Use format "<outfile>.ncd" or "<outfile>.dir".
# <pcffile> = Name of physical constraints file.
$(dn).ncd : map.ncd $(dn).pcf
par -ol 4 -w -d 0 map.ncd $(dn).ncd $(dn).pcf
#MAP: Maps the logic gates of the user's design (previously written to
an NGD
#file by NGDBUILD) into the CLBs and IOBs of the physical device, and
writes
#out this physical design to an NCD file.
#Usage: map [-p <partname>] [-u] [-ir] [-cm <covermode>] [-l] [-pr
# <iobfillmode>] [-o <outfile[.ncd]>] <infile[.ngd]> [<prffile[.pcf]>]
# where VIRTEX options are:
# -cm area|speed|balanced Cover mode. Default is "area".
# -f <cmdfile> Read command line arguments from file
<cmdfile>.
# -ir Do not use RLOC constraints to generate
RPMs. Use
# RLOCs to group logic together within a
CLB, but
# not to control the relative placement of
CLBs
# with respect to each other.
# -l Disable logic replication.
# -p <partname> Map to part <partname>.
# -pr i|o|b Pack internal flops/latches into input (i),
# output (o), or both (b) types of IOBs.
# -u Do not remove unnecessary/disabled logic.
map.ncd : $(dn).ngd
map -pr b -p $(part) -u -o map.ncd $(dn).ngd $(dn).pcf
#NGDBUILD: Translates and merges the various source files of a design
into a
#single "NGD" design database.
#Usage: ngdbuild [-p <partname>] {-sd <source_dir>} {-l <library>} [-ur
#<rules_file[.urf]>] [-dd <output_dir>] [-r] [-a] [-u] [-nt
timestamp|on|off]
#[-uc <ucf_file[.ucf]>] <design_name> [<ngd_file[.ngd]>]
#
# -p partname Use specified part type to implement the design
# -sd source_dir Add "source_dir" to the list of directories
# to search when resolving netlist file references
# -l library Add "library" to the list of source libraries
# passed to the netlisters
# -ur rules_file User rules file for netlist launcher
# -dd output_dir Directory to place intermediate .ngo files
# -nt value NGO file generation
# Options: "timestamp", "on", "off"
# -nt timestamp: Regenerate NGO only when source
# netlist is newer than existing
# NGO file (default)
# -nt on: Always regenerate NGO file from
# source design netlists
# -nt off: Do not regenerate NGO files
# which already exist. Build NGD
# file from existing NGO files
# -uc ucf_file Use specified "User Constraint File".
# The file <design_name>.ucf is used by default
# if it is found in the local directory.
# -r Ignore location constraints
# -a Infer pad components from ports in top-level
EDIF
# netlist (if any)
# -u Allow unexpanded blocks in output NGD design
$(dn).ngd : $(dn)x.edf $(dn).ucf
ngdbuild -p $(part) -uc $(dn).ucf $(dn)x.edf $(dn).ngd -a
# ngdbuild -p $(part) $(dn)x.edf $(dn).ngd -a
$(dn)x.edf : $(dn).edf edfmod.pl
$(perl) -w edfmod.pl $(dn).edf $(dn)x.edf
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18333
Yep, but if you have bazillions of fractionally different functions
in a design it is much nicer (but still yukky) to implement them
as Evan suggests:
attribute LOC of L1: label is "CLB_R12C23.S1";
L1: XLut3 generic map ( Expr => "(~I0*~I1*I2)")
port map(I0=>siga,I1=>sigb,I2=>sigc,O=>osig );
In article <38048D63.67F485EF@ids.net>,
Ray Andraka <randraka@ids.net> wrote:
> Use RLOC's to constrain the placement. You'll also need to define the
contents
> of the LUT to nail the logic to the LUT. For Virtex you can use the
LUT
> primitive or you can use an FMAP to specify the partitioning. The LUT
primitive
> needs an INIT= attribute to specify the contents, while the FMAP shows
the
> mapping of other logic to the LUT. If you are using VHDL, you'll have
to use
> the EQN attribute with the FMAP to specify the logic. With
schematics, the FMAP
> can be put in parallel with the logic it is to contain. You can also
put the
> luts into specific locations using the graphical floorplanner.
>
> The VHDL snippets below show one way of constraining some
combinatorial logic to
> a specific location. In this case, the 3 input comb. function
fmap_xnor3 is
> defined by a separate entity with the xc_xmap=lut attribute. That
contains the
> logic in a lut. Then when that component is instantiated, an rloc
string is
> attached to the component label. Here it is constrained to row 10,
column 20,
> LUT F in slice 0.
>
> entity fmap_xnor3 is
> port ( a, b, c : in std_logic;
> z : out std_logic);
> end fmap_xnor3;
> architecture rtl of fmap_xnor3 is
> attribute xc_map : STRING;
> attribute xc_map of rtl : architecture is "lut";
> begin
> z <= not a xor b xor c;
> end rtl;
>
> entity test is
> ....
> end test
>
> architecture structural of test is
> attribute RLOC: string;
> attribute RLOC of U1 : label is "R10C20.F.S0";
> begin
> U1: fmap_xnor3 port map(
> a=> a(i),
> b=> b(i),
> c=> add,
> z=> l);
>
> Espen Tislevoll wrote:
>
> > I want to connect different LUTs together on a Virtex chip.
> > For example, connecting output of F-LUT Slice 0 Column 1 Row 1 to
one of the
> > inputs of G-LUT Slice 1 Column 2 Row 1.
> >
> > Is it possible to put such low-level constraints, to a design, by
any of the
> > development tools available for Virtex ?
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930 Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18334Hi, I'm a young engineer and My hobby is the integration of algorithm on FPGA. Recently I've started to implement a DVB compliant viterbi decoder but I need a lot of memory to store the decision at each trellis state. The DVB standard has a 128 state trellis and the survovor depth for a punctured code is 96. To implement the trace back algoritm I need 6 dual port ram 48x128 that means about 36 kbit ram. Do somebody know if there is the possibility to use less ram or if there are some FPGA families that has the ram I need or Ihave to use an external ram chip? THANX ALESSANDROArticle: 18335
Alessandro Pinto <alessandro.pinto@tei.ericsson.se> writes: > Hi, > I'm a young engineer and My hobby is the integration of algorithm on > FPGA. > Recently I've started to implement a DVB compliant viterbi decoder but I > need a lot of memory to store the decision at each trellis state. > The DVB standard has a 128 state trellis and the survovor depth for a > punctured code is 96. > To implement the trace back algoritm I need 6 dual port ram 48x128 that > means about 36 kbit ram. > Do somebody know if there is the possibility to use less ram or if there > are some FPGA families that has the ram I need or Ihave to use an > external ram chip? Altera and Xilinx. Altera has a strangre definition of dual-port, so it might not be possible to use them. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 18336
Download Ia.n.i. RemoteControlSystem 1.2 beta. It's free!!! New site: http://jump.to/IaniProjectArticle: 18337
Magnus Homann wrote: > Alessandro Pinto <alessandro.pinto@tei.ericsson.se> writes: > > > Hi, > > I'm a young engineer and My hobby is the integration of algorithm on > > FPGA. > > Recently I've started to implement a DVB compliant viterbi decoder but I > > need a lot of memory to store the decision at each trellis state. > > The DVB standard has a 128 state trellis and the survovor depth for a > > punctured code is 96. > > To implement the trace back algoritm I need 6 dual port ram 48x128 that > > means about 36 kbit ram. > > Do somebody know if there is the possibility to use less ram or if there > > are some FPGA families that has the ram I need or Ihave to use an > > external ram chip? > > Altera and Xilinx. Altera has a strangre definition of dual-port, so > it might not be possible to use them. > > Homann > -- > Magnus Homann, M.Sc. CS & E > d0asta@dtek.chalmers.se The problem is the large dimension of the ram, for example XILINX has the basic 16x1 dual port ram but I will need to much CLB for my application (for example on a XC4085XL I have about 4000 CLB and they are not enough so I need a too expasive devise). THANX ALESSANDROArticle: 18338
Do anyone have a working code example in VHDL or know where to get one for a synchronos DPRAM that leonardo can do synthes on? Or do I have to build one myself out of two synchronos ram's? thanks KalleArticle: 18339
> To implement the trace back algoritm I need 6 dual port ram 48x128 that > means about 36 kbit ram. How fast are you trying to run? Can you do 36 reads and 36 writes for each major cycle? (If I understand what you want.) That would let you use an external SRAM chip. The Xilinx Virtex chips have chunks of RAM around the edges. That might fit your width better than a single chip. I think I've seen other FPGAs that include RAM but I don't remember where. Try browsing the web sites. -- These are my opinions, not necessarily my employers.Article: 18340
The way Ray did it you can simulate. With your Expr generic method, you can't . A compromise is to instantiate the luts directly with the LUT contents as bit string generic. It is more cryptic but you can simulate it. simon_bacon@my-deja.com wrote: > Yep, but if you have bazillions of fractionally different functions > in a design it is much nicer (but still yukky) to implement them > as Evan suggests: > > attribute LOC of L1: label is "CLB_R12C23.S1"; > > L1: XLut3 generic map ( Expr => "(~I0*~I1*I2)") > port map(I0=>siga,I1=>sigb,I2=>sigc,O=>osig ); > > In article <38048D63.67F485EF@ids.net>, > Ray Andraka <randraka@ids.net> wrote: > > Use RLOC's to constrain the placement. You'll also need to define the > contents > > of the LUT to nail the logic to the LUT. For Virtex you can use the > LUT > > primitive or you can use an FMAP to specify the partitioning. The LUT > primitive > > needs an INIT= attribute to specify the contents, while the FMAP shows > the > > mapping of other logic to the LUT. If you are using VHDL, you'll have > to use > > the EQN attribute with the FMAP to specify the logic. With > schematics, the FMAP > > can be put in parallel with the logic it is to contain. You can also > put the > > luts into specific locations using the graphical floorplanner. > > > > The VHDL snippets below show one way of constraining some > combinatorial logic to > > a specific location. In this case, the 3 input comb. function > fmap_xnor3 is > > defined by a separate entity with the xc_xmap=lut attribute. That > contains the > > logic in a lut. Then when that component is instantiated, an rloc > string is > > attached to the component label. Here it is constrained to row 10, > column 20, > > LUT F in slice 0. > > > > entity fmap_xnor3 is > > port ( a, b, c : in std_logic; > > z : out std_logic); > > end fmap_xnor3; > > architecture rtl of fmap_xnor3 is > > attribute xc_map : STRING; > > attribute xc_map of rtl : architecture is "lut"; > > begin > > z <= not a xor b xor c; > > end rtl; > > > > entity test is > > .... > > end test > > > > architecture structural of test is > > attribute RLOC: string; > > attribute RLOC of U1 : label is "R10C20.F.S0"; > > begin > > U1: fmap_xnor3 port map( > > a=> a(i), > > b=> b(i), > > c=> add, > > z=> l); > > > > Espen Tislevoll wrote: > > > > > I want to connect different LUTs together on a Virtex chip. > > > For example, connecting output of F-LUT Slice 0 Column 1 Row 1 to > one of the > > > inputs of G-LUT Slice 1 Column 2 Row 1. > > > > > > Is it possible to put such low-level constraints, to a design, by > any of the > > > development tools available for Virtex ? > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email randraka@ids.net > > http://users.ids.net/~randraka > > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 18341
Two problems with doing it the way you suggest: first, to simulate this you need to elaborate the VHDL and simulate the mapped output -- more steps, a slower simulation, and difficult to troubleshoot. second, this method of placement is absolute placement which means you can't use the same piece of code for multiple copies of the same instance, nor can you (or the tools) move the instance. If you've only got a few things to floorplan, this is fine, but if that were the case I would opt for just doing the floorplanning in the graphical floorplanner. To reuse the results of the graphical floorplanner in later iterations of the design, you should label instances in your design as much as possible so you get consistent names. Where floorplanning in the code is important is when you have a macro that is to be used either many times in the design or for many designs. Both cases, you really want that macro to be relocatable. The floorplanning, of course takes some of the variability out of the place and route solution since you are directing the placement. Also, don't believe the party line that says that virtex doesn't need to be floorplanned because it has an improved hierarchical routing structure blah,blah blah. I've done three largish macro designs in the past month for virtex, and every one of them got a better than 50% improvement in performance after floorplanning. All of them are arithmetic in nature (18 bit carry chains) and all now run at better than 150MHz in a virtex -4 (all were under 100MHz when placement was done by the PAR tools regardless of timing constraints and router effort). simon_bacon@my-deja.com wrote: > Yep, but if you have bazillions of fractionally different functions > in a design it is much nicer (but still yukky) to implement them > as Evan suggests: > > attribute LOC of L1: label is "CLB_R12C23.S1"; > > L1: XLut3 generic map ( Expr => "(~I0*~I1*I2)") > port map(I0=>siga,I1=>sigb,I2=>sigc,O=>osig ); > > In article <38048D63.67F485EF@ids.net>, > Ray Andraka <randraka@ids.net> wrote: > > Use RLOC's to constrain the placement. You'll also need to define the > contents > > of the LUT to nail the logic to the LUT. For Virtex you can use the > LUT > > primitive or you can use an FMAP to specify the partitioning. The LUT > primitive > > needs an INIT= attribute to specify the contents, while the FMAP shows > the > > mapping of other logic to the LUT. If you are using VHDL, you'll have > to use > > the EQN attribute with the FMAP to specify the logic. With > schematics, the FMAP > > can be put in parallel with the logic it is to contain. You can also > put the > > luts into specific locations using the graphical floorplanner. > > > > The VHDL snippets below show one way of constraining some > combinatorial logic to > > a specific location. In this case, the 3 input comb. function > fmap_xnor3 is > > defined by a separate entity with the xc_xmap=lut attribute. That > contains the > > logic in a lut. Then when that component is instantiated, an rloc > string is > > attached to the component label. Here it is constrained to row 10, > column 20, > > LUT F in slice 0. > > > > entity fmap_xnor3 is > > port ( a, b, c : in std_logic; > > z : out std_logic); > > end fmap_xnor3; > > architecture rtl of fmap_xnor3 is > > attribute xc_map : STRING; > > attribute xc_map of rtl : architecture is "lut"; > > begin > > z <= not a xor b xor c; > > end rtl; > > > > entity test is > > .... > > end test > > > > architecture structural of test is > > attribute RLOC: string; > > attribute RLOC of U1 : label is "R10C20.F.S0"; > > begin > > U1: fmap_xnor3 port map( > > a=> a(i), > > b=> b(i), > > c=> add, > > z=> l); > > > > Espen Tislevoll wrote: > > > > > I want to connect different LUTs together on a Virtex chip. > > > For example, connecting output of F-LUT Slice 0 Column 1 Row 1 to > one of the > > > inputs of G-LUT Slice 1 Column 2 Row 1. > > > > > > Is it possible to put such low-level constraints, to a design, by > any of the > > > development tools available for Virtex ? > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email randraka@ids.net > > http://users.ids.net/~randraka > > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 18342
Xilinx Virtex has anywhere from 8 to 32 4K bit dual port RAMs on chip. Should fill the bill. Alessandro Pinto wrote: > Hi, > I'm a young engineer and My hobby is the integration of algorithm on > FPGA. > Recently I've started to implement a DVB compliant viterbi decoder but I > need a lot of memory to store the decision at each trellis state. > The DVB standard has a 128 state trellis and the survovor depth for a > punctured code is 96. > To implement the trace back algoritm I need 6 dual port ram 48x128 that > means about 36 kbit ram. > Do somebody know if there is the possibility to use less ram or if there > are some FPGA families that has the ram I need or Ihave to use an > external ram chip? > > THANX > > ALESSANDRO -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 18343
Look at the Xilinx Virtex parts. They have 4K dual port bit block RAMs in addition to the LUT RAM capability in the CLBs. There are from 8 to 32 of the block rams on a chip depending on the size chip you get. Each block ram is a true synchronous dual port memory. Each port has its own complete set of controls including clocks, so the ports can be operated asynchronously with respect to each other (each side is still a synchronous port, but they can operate off different clocks). Also, the memory configuration (width and depth) can be set independently for each port so, for example, one port can access the data as bytes while the other accesses it as 16 bit words. The larger altera devices also have block memories, but even though altera calls them dual port, they do not meet the classic definition of dual port. Alessandro Pinto wrote: > Hi, > I'm a young engineer and My hobby is the integration of algorithm on > FPGA. > Recently I've started to implement a DVB compliant viterbi decoder but I > need a lot of memory to store the decision at each trellis state. > The DVB standard has a 128 state trellis and the survovor depth for a > punctured code is 96. > To implement the trace back algoritm I need 6 dual port ram 48x128 that > means about 36 kbit ram. > Do somebody know if there is the possibility to use less ram or if there > are some FPGA families that has the ram I need or Ihave to use an > external ram chip? > > THANX > > ALESSANDRO -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 18344
In article <iLMN3.2748$lz4.5538@nntpserver.swip.net>, "Ulf Samuelsson" <ulf.samuelsson@atmel.spamme.com.not> wrote: > If someone want to have a look at the FPSLIC, > The FPGA+40 Mhz AVR RISC+Peripherals + Memory chip > under development at Atmel, Here's the link: > http://www.atmel.com/atmel/products/prod39.htm When it will be in production? And what price is expected for unit? Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18345
"kalle Henriksson" <kalle.henriksson@sth.frontec.se> writes: > Do anyone have a working code example in VHDL or know where to get one for a > synchronos DPRAM that leonardo can do synthes on? Or do I have to build one > myself out of two synchronos ram's? Just out of curiosity, how do you plan to make a dual-port RAM out of two single-port ones? Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 18346
avms@my-deja.com skrev i meddelandet <7ua4gb$djg$1@nnrp1.deja.com>... >In article <iLMN3.2748$lz4.5538@nntpserver.swip.net>, > "Ulf Samuelsson" <ulf.samuelsson@atmel.spamme.com.not> wrote: >> If someone want to have a look at the FPSLIC, >> The FPGA+40 Mhz AVR RISC+Peripherals + Memory chip >> under development at Atmel, Here's the link: >> http://www.atmel.com/atmel/products/prod39.htm > > When it will be in production? Early next millenium :-) > And what price is expected for unit Slightly more expensive than the equivalent sized AT40k FPGA. Definitely dollars and not cents. -- This is a personal view which may or may not be shared by my employer Atmel Sweden Ulf Samuelsson ulf 'a't atmel 'd'o't com > >Sent via Deja.com http://www.deja.com/ >Before you buy.Article: 18347
Looks terrific but
- on-chip flash would have been good both for self-contained
products and for security
- wider access from the FPGA core to the SRAM (i.e. more
bandwith) would help with DSP-style algorithms.
In article <iLMN3.2748$lz4.5538@nntpserver.swip.net>,
"Ulf Samuelsson" <ulf.samuelsson@atmel.spamme.com.not> wrote:
> If someone want to have a look at the FPSLIC,
> The FPGA+40 Mhz AVR RISC+Peripherals + Memory chip
> under development at Atmel, Here's the link:
> http://www.atmel.com/atmel/products/prod39.htm
>
> --
> This is a personal view which may or may not be shared
> by my employer Atmel Sweden
> Ulf Samuelsson ulf 'a't atmel 'd'o't com
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18348Is there are PLD with integrated 256 wide 512 KB SRAM? -- Yours truly Alexey Ovchinnikov! Crashed Russia, Ural, Ekaterinburg. princessd@mail.ur.ru The Sun Needs 12 Hours To Light Up My Motherland!Article: 18349
Ken, Yes; it works. Saves a lot of time learning how to talk to the core. Most of the problems I had were with the clock skew in the core itself. And it comes with a very good test bench. Gary. Kenneth Prager wrote: > > Greetings, > > Has anyone out there uses Xilinx's Synthesizable PCI Bridge design? If > so, any comments... good, bad, indifferent? > > Thanks in advance, > > Ken Prager > Raytheon Systems Co. > prager@ieee.org
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