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 18325

Article: 18325
Subject: Re: Reading a Lattice ispLSI 1016
From: mikeandmax@aol.com (Mikeandmax)
Date: 14 Oct 1999 22:31:40 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: compiling vhdl code(help please)
From: Kai Troester <kai.troester@imms.de>
Date: Fri, 15 Oct 1999 09:07:58 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: compiling vhdl code(help please)
From: Matthieu LIGER <ligerm@esiee.fr>
Date: Fri, 15 Oct 1999 09:09:36 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx FPGA Programmer
From: "Ulf Samuelsson" <ulf.samuelsson@atmel.spamme.com.not>
Date: Fri, 15 Oct 1999 22:48:34 +0200
Links: << >>  << T >>  << A >>
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
Subject: SRAM FPGA with hardwired 40 MHz AVR RISC processor, memory and peripherals
From: "Ulf Samuelsson" <ulf.samuelsson@atmel.spamme.com.not>
Date: Fri, 15 Oct 1999 23:09:24 +0200
Links: << >>  << T >>  << A >>
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
Subject: Verilog FAQ
From: rajesh52@hotmail.com
Date: Fri, 15 Oct 1999 21:45:54 GMT
Links: << >>  << T >>  << A >>
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
Subject: Xilinx PCI Bridge
From: prager@ieee.org (Kenneth Prager)
Date: Fri, 15 Oct 1999 15:06:44 -0700
Links: << >>  << T >>  << A >>
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
Subject: Xilinx MAKE file
From: simon_bacon@my-deja.com
Date: Sat, 16 Oct 1999 04:36:50 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Interconnecting LUTs on a Virtex
From: simon_bacon@my-deja.com
Date: Sat, 16 Oct 1999 04:47:46 GMT
Links: << >>  << T >>  << A >>
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: 18334
Subject: VITERBI
From: Alessandro Pinto <alessandro.pinto@tei.ericsson.se>
Date: Sat, 16 Oct 1999 10:52:01 +0200
Links: << >>  << T >>  << A >>
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


Article: 18335
Subject: Re: VITERBI
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 16 Oct 1999 11:59:34 +0200
Links: << >>  << T >>  << A >>
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
Article: 18336
Subject: Download Ia.n.i.!!! It's free!
From: madQ <madq968@djeksta.comNOSPAM>
Date: 16 Oct 1999 10:24:23 GMT
Links: << >>  << T >>  << A >>

Download Ia.n.i. RemoteControlSystem 1.2 beta. It's free!!!
New site: http://jump.to/IaniProject

Article: 18337
Subject: Re: VITERBI
From: Alessandro Pinto <alessandro.pinto@tei.ericsson.se>
Date: Sat, 16 Oct 1999 12:49:54 +0200
Links: << >>  << T >>  << A >>
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

ALESSANDRO



Article: 18338
Subject: Xilinx 4k and DPRAM for leonardo question
From: "kalle Henriksson" <kalle.henriksson@sth.frontec.se>
Date: Sat, 16 Oct 1999 13:10:31 +0200
Links: << >>  << T >>  << A >>
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
Kalle


Article: 18339
Subject: Re: VITERBI
From: murray@pa.dec.com (Hal Murray)
Date: 16 Oct 1999 12:13:42 GMT
Links: << >>  << T >>  << A >>

> 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
Subject: Re: Interconnecting LUTs on a Virtex
From: Ken McElvain <ken@synplicity.com>
Date: 16 Oct 1999 06:46:37 PDT
Links: << >>  << T >>  << A >>
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
Subject: Re: Interconnecting LUTs on a Virtex
From: Ray Andraka <randraka@ids.net>
Date: Sat, 16 Oct 1999 10:07:51 -0400
Links: << >>  << T >>  << A >>
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/~randraka


Article: 18342
Subject: Re: VITERBI
From: Ray Andraka <randraka@ids.net>
Date: Sat, 16 Oct 1999 10:11:41 -0400
Links: << >>  << T >>  << A >>
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/~randraka


Article: 18343
Subject: Re: VITERBI
From: Ray Andraka <randraka@ids.net>
Date: Sat, 16 Oct 1999 10:18:00 -0400
Links: << >>  << T >>  << A >>
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/~randraka


Article: 18344
Subject: Re: SRAM FPGA with hardwired 40 MHz AVR RISC processor, memory and peripherals
From: avms@my-deja.com
Date: Sat, 16 Oct 1999 15:10:09 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx 4k and DPRAM for leonardo question
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 16 Oct 1999 18:26:36 +0200
Links: << >>  << T >>  << A >>
"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.se
Article: 18346
Subject: Re: SRAM FPGA with hardwired 40 MHz AVR RISC processor, memory and peripherals
From: "Ulf Samuelsson" <ulf.samuelsson@atmel.spamme.com.not>
Date: Sun, 17 Oct 1999 02:22:54 +0200
Links: << >>  << T >>  << A >>


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
Subject: Re: SRAM FPGA with hardwired 40 MHz AVR RISC processor, memory and peripherals
From: simon_bacon@my-deja.com
Date: Sun, 17 Oct 1999 07:28:16 GMT
Links: << >>  << T >>  << A >>
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: 18348
Subject: Q
From: "Alexey Ovchinnikov" <princessd@mail.ur.ru>
Date: 17 Oct 1999 14:13:34 GMT
Links: << >>  << T >>  << A >>
Is 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
Subject: Re: Xilinx PCI Bridge
From: Gary Helbig <"ghelbig"@mailcity(.)com>
Date: Sun, 17 Oct 1999 10:10:47 -0700
Links: << >>  << T >>  << A >>
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:
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