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
2017JanFebMarApr2017

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 41525

Article: 41525
Subject: Re: powerpc in virtex2pro
From: Peter Alfke <palfke@earthlink.net>
Date: Mon, 01 Apr 2002 16:36:19 GMT
Links: << >>  << T >>  << A >>
There are hard cores and soft cores.
Hard cores are specialized silicon areas that implement a fnction very efficiently,
but only the manufacturer ( Xilinx, Altera, etc ) can do that.
Soft macros use the logic fabric ( CLBs etc ), and any user can instantiate them
anywhere. Soft macros consume more silicon area per function, and are slower, but
more flexible. (eg MicroBlaze and Nios)
IMHO, both PowerPC and ARM are too complex to be implemented as soft macros.
Xilinx picked PowerPC as the hard core in Virtex-II Pro, Altera picked ARM for
Excalibur, and, surprisingly enough, no microprocessor at all for Stratix, their
future flagship...

Peter Alfke
===================
Ron Huizen wrote:

> Peter,
>
> Are you saying that putting an ARM core into a Virtex II is not doable,
> or just not practical?  Or are you only talking about the V2 Pro?
>
> ---------
> Ron Huizen
> BittWare
>
> Peter Alfke wrote:
> >
> > "Cyrille de Brébisson" wrote:
> >
> > > In our design we are using an ARM CPU. My question is:
> > > Can we put an ARM in the virtex 2 pro?
> > > Were can I find/buy an ARM cpu core source (or precompiled) file to program
> > > in my FPGA?
> > >
> >
> > Cyrille,
> > the answer to both your questions is: No.
> > The PowerPC in Virtex-II Pro is a "hard" implementation, packing the
> > microprocessor with its caches and MMU into the smallest possible silicon
> > area, <4 square millimeters.
> > What you seem to be looking for is a "soft" implementation, using the
> > programmable logic "fabric".
> > That solution is impractical for something as complex as PowerPC or even ARM.
> > It would take up an unreasonable portion of a large chip, and achieve mediocre
> > performance at best.
> > Xilinx offers a soft microprocessor, called MicroBlaze, especially tuned for
> > efficient implementation in the Virtex architecture. It is not as fast and
> > capable as PowerPC, but uses only ~900 slices.
> > "Half the size and twice the speed of NIOS" is the Xilinx slogan. Please, no
> > flames...
> >
> > Peter Alfke, Xilinx Applications


Article: 41526
Subject: Re: Data Compression in FPGAs
From: John_H <johnhandwork@mail.com>
Date: Mon, 01 Apr 2002 16:40:22 GMT
Links: << >>  << T >>  << A >>
Performance LZW compression is a bear.  The algorithm isn't friendly to
single channels at top performance and under most circumstances requires
an external SRAM (about 60 FPGA pins).  It's achievable but not a project
for the feint of heart.  For items like text, you have to use a lossless
algorithm so your choices are limited.  For audio and video, lossless
algorithms are a bit of overkill - there are many compression algorithms
with almost no human-perceptible loss that would be much more effective
than the lossless alternatives.

I've seen a few people on the newsgroups talk about hardware MP3
implementations (audio) and know that JPEG cores are available for FPGAs,
but lossless algorithms haven't found much play on the newsgroups or in
the IP offerings I've seen.


VP wrote:

> Hi all,
>
> I am trying to find best general purpose data (text, audio, video and
> other types) compression algorithm suitable for FPGA implementation.
> On doing some research LZW compression and variations of LZ (LZ-77,
> LZS etc) compression seems to be a good fit. Can someone point me to
> other hardware based loss less data compression algorithms? Did anyone
> implement data compressors in FPGAs? Any pointers/references would be
> greatly appreciated.
>
> Thanks


Article: 41527
Subject: Re: Update: A petition for Synplify's new fature (FPGA synthesis tool)
From: John_H <johnhandwork@mail.com>
Date: Mon, 01 Apr 2002 16:49:31 GMT
Links: << >>  << T >>  << A >>
I didn't respond initially because of one underlying issue.  Tristate multiplexers
are a design element best left in the past.  The efficiencies aren't high in current
silicon with respect to performance and are only available (as far as I know) in one
brand of devices.  If it weren't for legacy issues, I'd almost expect the feature
would've been dropped a generation or two ago.

There are so many different approaches to multiplexing that - in my opinion - the
tools should concentrate on generic logic implementation issues.  Non-generic items
that are used most frequently might benefit from optimization;  tristate
multiplexing is just used less and less these days.


Aki Niimura wrote:

> I still would like to have more responses from FPGA/ASIC designers.
> With few more responses, I will wrap up this petition and present to Synplicity.
> (However, developers in Synplicity are already following this petition.)
>
> The more I hear others' opinions, the more I feel that this is something
> Verilog standard didn't do a good job. I can find both "for" and "against"
> reasons in the standard.


Article: 41528
Subject: Re: Data Compression in FPGAs
From: Keith R. Williams <krw@btv.ibm.com>
Date: Mon, 1 Apr 2002 13:07:34 -0500
Links: << >>  << T >>  << A >>
In article <3CA88D75.1468E42C@mail.com>, johnhandwork@mail.com says...
> Performance LZW compression is a bear.  The algorithm isn't friendly to
> single channels at top performance and under most circumstances requires
> an external SRAM (about 60 FPGA pins).  It's achievable but not a project
> for the feint of heart.  

What about a CAM based LZ?  Xilinx has datasheets describing how to 
make a CAM out of BlockRAMs.  The CAM sizes seem reasonable for LZ (512 
to 1024 entries give reasonable compression) in the moderate sized 
Virtex-2.  Unless the chip has a lot more to do than LZ, the cost is 
going to be outrageous though.

----
  Keith

Article: 41529
Subject: Laying out the design
From: "Spaced Cowboy" <cowboy@gornall.net>
Date: Mon, 1 Apr 2002 19:12:56 +0100
Links: << >>  << T >>  << A >>
I've been playing with the Webpack floorplanner this weekend, and have
created a few "planned" designs from modules within my verilog source. The
question is how to use those nice layouts within the encompassing module:
say for example I have module X that contains an instance of module Y. I've
floorplanned Y, how do I get X to use the floorplanned design for Y when
laying out X ?

Any hints gratefully received.

Simon




Article: 41530
Subject: Re: Laying out the design
From: Ray Andraka <ray@andraka.com>
Date: Mon, 01 Apr 2002 18:59:30 GMT
Links: << >>  << T >>  << A >>
Unfortunately, the floorplanner doesn't really export floorplans and it
produces a flat (not hierarchical) floorplan.  That makes it hard to export a
pattern from one design into another.  WHat you can do is embed the
floorplanning information in the source by putting RLOCs on the instances.  Of
course, that means that you need to instantiate primitives in your source
rather than working with an RTL description.

You can also write a UCF file from the floorplanner.  That produces LOC
constraints for all the instances in the floorplan.  You can then go in with a
parser written in your favorite text processing language (Perl) to parse the
floorplan file looking for matching primitive names, then add x,y offsets to
the LOCs in the floorplan ucf file.  This presents two challenges:  one, the
easier, is to find the LOCs and tranlate them to the new origin.  The tougher
part is matching up the symbol names to those in your second design, which will
have additional hierarchy on top of it.  If you can manage to keep the instance
names from changing (ie, don't recompile your macro through the synhtesizer),
you have a fighting chance of making tht work.  Wish I had a better answer for
you.  Unfortunately, until Xilinx finally decides to do a hierarchical
floorplanner and allow copying parts of floorplans across designs or across
instances in the design, this is about the best you can do.  We lean toward
RLOCing the source, since it is less prone to headache later.  A hint: most of
the time you can get away with just RLOCing the flip-flops.  The combinatorial
logic, if it is restricted to one level, will get placed with the flip-flop.
The second level of combinatorial logic is much more troublesome, as the
autoplacement doesn't seem to like to put that second level near the first.

Spaced Cowboy wrote:

> I've been playing with the Webpack floorplanner this weekend, and have
> created a few "planned" designs from modules within my verilog source. The
> question is how to use those nice layouts within the encompassing module:
> say for example I have module X that contains an instance of module Y. I've
> floorplanned Y, how do I get X to use the floorplanned design for Y when
> laying out X ?
>
> Any hints gratefully received.
>
> Simon

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41531
Subject: Configuring the Virtex II FPGA
From: yaot@hotmail.com (Terry)
Date: 1 Apr 2002 11:13:48 -0800
Links: << >>  << T >>  << A >>
Hi all,

I am testing my designs using the Insight MicroBlaze development board
with the Virtex II 1 million gate FPGA.  When configuring the FPGA
directly (ie. bypassing PROM) using the JTAG port, I first attempt to
establish communication through reading the idcode.  I received an
error message from iMPACT that the device idcode doesn't match the
idcode in the bsdl file.  I'm guessing the problem is related to
bypassing the ISP PROM, and I should perhaps associate the ISP PROM
with either a dummy .mcs file or a .bsd file to bypass it.  My
question is:  can I just use the generic bsdl file available on the
Xilinx site as the dummy .bsd file?  And if so, where should I save
this file and how do I specify that it's targeted for the PROM?

I'd appreciate any help on this matter,

Terry

Article: 41532
Subject: Re: Where to get MAX7000S
From: "Ulf Samuelsson" <ulf@atmel.REMOVE.com>
Date: Mon, 1 Apr 2002 21:57:58 +0200
Links: << >>  << T >>  << A >>
"Alexander Miks" <monstrum@tiscali.se> skrev i meddelandet
news:z7_o8.1055$m4.19213@news010.worldonline.se...
> Where can I get the MAX7000S-series of chips in Sweden. Do you know of any
> place shipping devices over here. I know a place here in Sweden, but they
> only have the 7064S.
>
>

Or try out the pin compatible Atmel ATF1500 series ...

--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.




Article: 41533
Subject: Re: FPGA config without boot PROM???
From: "Ulf Samuelsson" <ulf@atmel.REMOVE.com>
Date: Mon, 1 Apr 2002 22:02:43 +0200
Links: << >>  << T >>  << A >>
"Chris Wilkson" <cwilkson@mit.edu> skrev i meddelandet
news:ee75da9.-1@WebX.sUN8CHnE...
> I'm looking for an FPGA family that doesn't require a separate boot
> PROM.  (I can't afford the board space for the second chip.)
>
> Does anyone have any suggestions?
> Please respond by email as I don't regularly read this forum.
>
> Thanks!
> -Chris

The AT94S Family (S for Secure) is available with
the FPGA and Configurator in a single BGA package.
The FPGA also contains the AVR micro, SRAM and AVR peripherals.

--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.




Article: 41534
Subject: Re: Data Compression in FPGAs
From: "D.A.Kopf" <dak@dakx.com>
Date: 01 Apr 2002 20:39:59 GMT
Links: << >>  << T >>  << A >>
VP wrote:
> 
> Hi all,
> 
> I am trying to find best general purpose data (text, audio, video and
> other types) compression algorithm suitable for FPGA implementation.
> On doing some research LZW compression and variations of LZ (LZ-77,
> LZS etc) compression seems to be a good fit. Can someone point me to
> other hardware based loss less data compression algorithms? Did anyone
> implement data compressors in FPGAs? Any pointers/references would be
> greatly appreciated.

Not sure why you want a single algorithm for all these data types; I'd think
multiple algorithms sharing common routines and having the smallest footprint
would be the engineering choice. But http://dakx.com describes a lossless
method suitable for low-complexity FPGAs. It's not great for text, maybe
compression 80-90% of original without using a character remapping table, but
competitive for audio or video.


Article: 41535
Subject: Re: powerpc in virtex2pro
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 01 Apr 2002 22:00:20 +0100
Links: << >>  << T >>  << A >>


"Keith R. Williams" wrote:

> In article <a82m6n$lvj$1@web1.cup.hp.com>, cyrille_de-brebisson@hp.com
> says...
> > Hello,
> >
> > Actually, I have a related question.
> > In our design we are using an ARM CPU. My question is:
> > Can we put an ARM in the virtex 2 pro?
> > Were can I find/buy an ARM cpu core source (or precompiled) file to program
> > in my FPGA?
>
> In the interest of full disclosure... Xilinx doesn't do ARM, but Altera
> has an ARM hard core in their Excalibur series.  I don't know anything
> more than what is on their web site though.
>
> Xilinx chose the right processor. ;-)
>
>

Nah! It should have been one of the MIPS cores.

- Speaking as someone for whom the bigger the MIPS world, the bigger my earnings.





Article: 41536
Subject: Re: HELP me, about chipscope analyzer
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 01 Apr 2002 22:23:41 +0100
Links: << >>  << T >>  << A >>


William L Hunter Jr wrote:

> Changchun
>
> Core version 0.0 is not valid means that you have not inserted a ILA core
> using the ILA core inserter or by instaniating one in VHDL.
>

I've also had this error with a perfectly o.k. ILA and control core, I've even
had it complaining about Core version 15.15 not being valid!. Basically it means
that its not reading the JTAG stream correctly.

My case is slightly different since I'm using the old-fashioned Parallel-III
Centronics cable. This was based on advice I got that using MultiLinx with
ChipScope was very flakey.

So far I've found 3 sources of this, but there's at least one other I haven't
got at yet.

o If there's another heavy compute process running in the background e.g. a PAR
for the next level of debug.

o iMPACT JTAG programmer is running. This seems to sometimes cause problems even
if I get iMPACT to disconnect before opening up the ChipScope analyser.

o Doing a `print' through the parallel port with ChipScope analyser up & running
but disconnected.



Article: 41537
Subject: Re: Data Compression in FPGAs
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 1 Apr 2002 21:34:17 GMT
Links: << >>  << T >>  << A >>
lucky_hero@yahoo.com (VP) writes:

>I am trying to find best general purpose data (text, audio, video and
>other types) compression algorithm suitable for FPGA implementation. 
>On doing some research LZW compression and variations of LZ (LZ-77,
>LZS etc) compression seems to be a good fit. Can someone point me to
>other hardware based loss less data compression algorithms? Did anyone
>implement data compressors in FPGAs? Any pointers/references would be
>greatly appreciated.

IBM has a hardware compression chip with a patented algorithm.  See:

http://www.google.com/search?q=cache:NMXQVGVNNR0C:www.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF778525697500612122+aldc+ibm&hl=en


The most appropriate algorithm depends on how you need to use
it?  It may be that compression can be slow and decompression
fast, or the other way around.  That and cost constraints should
help determine the best algorithms.

-- glen

Article: 41538
Subject: Re: Data Compression in FPGAs
From: John_H <johnhandwork@mail.com>
Date: Mon, 01 Apr 2002 21:38:14 GMT
Links: << >>  << T >>  << A >>
CAM based LZ would be spectacular.  I haven't seen that the Xilinx CAM
implementations allowed the width and breadth needed for a decent LZW
implementation (20 bits tag, 12 bits data, 4k elements per channel).  Oh, to
have an embedded CAM with a worthwhile size!


"Keith R. Williams" wrote:

> In article <3CA88D75.1468E42C@mail.com>, johnhandwork@mail.com says...
> > Performance LZW compression is a bear.  The algorithm isn't friendly to
> > single channels at top performance and under most circumstances requires
> > an external SRAM (about 60 FPGA pins).  It's achievable but not a project
> > for the feint of heart.
>
> What about a CAM based LZ?  Xilinx has datasheets describing how to
> make a CAM out of BlockRAMs.  The CAM sizes seem reasonable for LZ (512
> to 1024 entries give reasonable compression) in the moderate sized
> Virtex-2.  Unless the chip has a lot more to do than LZ, the cost is
> going to be outrageous though.
>
> ----
>   Keith


Article: 41539
Subject: Announce: TimingAnalyzer Program Update
From: d2fabrizio@aol.com (D2fabrizio)
Date: 01 Apr 2002 21:43:14 GMT
Links: << >>  << T >>  << A >>
Hello All,

The TimingAnalyzer can be used to draw timing diagrams and
check for timing problems in digital systems. The diagrams
can be included in word processing documents, printed, or
saved as image files.  

http://members.aol.com/d2fabrizio

Regards,
Dan Fabrizio
d2fabrizio@aol.com

--------------------------------------------------------------------------
-------------------
  Beta Versrion 0.70 New Features and Improvements


    1  A new help gui which shows all the topics in a tree on the left
       and the html help files on the right. The topics are stored in an
       xml file in the docs dir. The Aelfred XML parser has been added and
       is used to parse this file and coming soon, TDML.
  
    2  Increment(+) and decrement (-) now works with multiple selected
       edge values. This makes it easy to increment or decrement 
       all the values in counter output or burst output

    3  You can now add multiple constraints per edge

    4  You can optionally specify color, fonts, fontsize, and font styles
       for Delays, Constraints, Text objects, Delta Time Text objects,
       StateBars, and bus values.  If they are not specified, the defaults 
       values are used and they are not saved in the *.tim file.  
       Any non-default values are saved in the *.tim file. 
       See file format help for the object.

    5  .taDefaults has been renamed to .ta_defaults
            This contains only InstallDirectory and Password values.
       .taOpenFileList has been renamed to .ta_open_files_list
       .taRecentFiles has been renamed to .ta_recent_files
       .td_defaults contains all the default values for timing diagrams.

       All of the above files are stored in a subdirectory off of the user home
       directory called .ta-0.XX when XX is the version number. In this case it
is 
       .ta-0.70.  This should improve previously seen issues with upgrading.

    6  Added more scripting API descriptions.

    7  File reload menu.   This is handy if you edit the *.tim with a text
editor.
   
    8  Zooming centers selected object in window.

    9  changing global options settings in dialog now effect the timing diagram

       immediately. If you want use the settings for all timing diagrams, just
hit        save.


Article: 41540
Subject: Re: Laying out the design
From: "Spaced Cowboy" <cowboy@gornall.net>
Date: Mon, 1 Apr 2002 23:43:47 +0100
Links: << >>  << T >>  << A >>
Ray Andraka wrote:

> Unfortunately, the floorplanner doesn't really export floorplans and it
> produces a flat (not hierarchical) floorplan.  That makes it hard to
> export a pattern from one design into another.  WHat you can do is
> embed the floorplanning information in the source by putting RLOCs
> on the instances. Of course, that means that you need to instantiate
> primitives in your source rather than working with an RTL description.

Cheers Ray. Not the news I wanted :-) but at least it will stop me trying
to figure out the impossible.

I'd chosen a reasonably simple module because one look at the cpu
module was enough to give me nightmares :-(  I was hoping to break
the problem down into manageable chunks. It's a shame the tools don't
let you do that.

I don't suppose you have a simple example of how to use an RLOC
(in verilog), or a url showing how to do it. Actually, this *must* be a
FAQ, I'll go search :-)

> You can also write a UCF file from the floorplanner.  That produces
> LOC constraints for all the instances in the floorplan.  You can then
> go in with a parser written in your favorite text processing language
> (Perl)

<grin> is this a compulsory "favourite" then :-) Actually I'm pretty keen
on Perl, but I prefer python. :-)

> to parse the floorplan file looking for matching primitive names, then
> add x,y offsets to the LOCs in the floorplan ucf file.  This presents two
> challenges:  one, the easier, is to find the LOCs and tranlate them to the
> new origin.  The tougher part is matching up the symbol names to those
> in your second design, which will have additional hierarchy on top of it.
> If you can manage to keep the instance names from changing (ie, don't
> recompile your macro through the synhtesizer), you have a fighting
> chance of making tht work.

Yeah, the chances of that are fairly slim though - I tend to work on a
chunk at a time (divide & conquer). Unless the gui tool doesn't re-make
already-synthesised parts (I don't know if it does or not) I'll almost
certainly run afoul of that stipulation.

Gaaah. I could do this *much* easier if I had 'make' and a shell...
Perhaps I should invest some time in getting Webpack to work under
Wine, and learning what actually happens when you click on the little
circle thing. At least then I could be sure what was happening behind the
scenes. Alternatively, XILINX - I WOULD LIKE WEBPACK UNDER
LINUX. THANKYOU. Hell, it has to be worth a try!

> Wish I had a better answer for you.  Unfortunately, until Xilinx finally
> decides to do a hierarchical floorplanner and allow copying parts of
> floorplans across designs or across instances in the design, this is
> about the best you can do.

I take it I'm not the first person to hit this one then ? <grin>

>We lean toward RLOCing the source, since it is less prone to headache
> later.  A hint: most of the time you can get away with just RLOCing the
> flip-flops.  The combinatorial logic, if it is restricted to one level,
will get
> placed with the flip-flop. The second level of combinatorial logic is much
> more troublesome, as the autoplacement doesn't seem to like to put that
> second level near the first.

Thanks for the hint :-)

So for larger designs (when you'll get bitten by >1 layer combinatorial) do
you professional types get down and dirty and floorplan big modules
directly ? I don't really see how you could keep track of the N entities,
where N is a *large* number!

Cheers,
    Simon




Article: 41541
Subject: Re: Laying out the design
From: "Jan Gray" <jsgray@acm.org>
Date: Mon, 1 Apr 2002 14:57:36 -0800
Links: << >>  << T >>  << A >>
> I don't suppose you have a simple example of how to use an RLOC
> (in verilog), or a url showing how to do it. Actually, this *must* be a
> FAQ, I'll go search :-)

Ray will tell you to use VHDL which has generate. :-)

Here's what I do in Verilog.  I write Python programs that generate Verilog
with RLOCs.  For example, here's some Python to build an n-bit register
floorplanned into a column of slices.

(edited slightly)

def fde(n):
    for s in range(3):
        print '''
module fde%d%s(clk, ce, d, q) /* synthesis syn_hier="hard" */;
  input clk, ce;
  input [%d:0] d;
  output [%d:0] q;
''' % (n,Sls[s],n-1,n-1)

        for i in range(n):
            print '  FDE r%d(.C(clk), .CE(ce), .D(d[%d]), .Q(q[%d]))' %
(i,i,i)
            if s < 2:
                print '    /* synthesis RLOC="R%dC0.S%d" */;' %
((n-i-1+n%2)/2,s)
            else:
                print '    /* synthesis RLOC="X0Y%d" */;' % (i/2)
        print 'endmodule\n'

Which emits .S0, .S1, and Virtex-2 versions of an n-bit register:

(also edited slightly)
module fde6v2(clk, ce, d, q) /* synthesis syn_hier="hard" */;
  input clk, ce;
  input [5:0] d;
  output [5:0] q;

  FDE r0(.C(clk), .CE(ce), .D(d[0]), .Q(q[0]))
    /* synthesis RLOC="X0Y0" */;
  FDE r1(.C(clk), .CE(ce), .D(d[1]), .Q(q[1]))
    /* synthesis RLOC="X0Y0" */;
  FDE r2(.C(clk), .CE(ce), .D(d[2]), .Q(q[2]))
    /* synthesis RLOC="X0Y1" */;
  FDE r3(.C(clk), .CE(ce), .D(d[3]), .Q(q[3]))
    /* synthesis RLOC="X0Y1" */;
  FDE r4(.C(clk), .CE(ce), .D(d[4]), .Q(q[4]))
    /* synthesis RLOC="X0Y2" */;
  FDE r5(.C(clk), .CE(ce), .D(d[5]), .Q(q[5]))
    /* synthesis RLOC="X0Y2" */ ;
endmodule

(No warranties, your mileage may vary, etc.)

Jan Gray, Gray Research LLC




Article: 41542
Subject: Re: Laying out the design
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Tue, 2 Apr 2002 00:03:38 +0100
Links: << >>  << T >>  << A >>
Jan Gray wrote

> Ray will tell you to use VHDL which has generate. :-)

Generate is a good feature of VHDL, but the point is that VHDL
is a more complete programming language and it allows you to
compute the functions which otherwise need something like a
Python script.

On the main issue, a hierarchical floorplan system keyed to
"hierarchical EDIF" is not too difficult, but productising
such a piece of software is not so trivial.  Keep pressing
the X to do it.





Article: 41543
Subject: Re: Laying out the design
From: Ray Andraka <ray@andraka.com>
Date: Tue, 02 Apr 2002 00:19:13 GMT
Links: << >>  << T >>  << A >>
Yep,  That's what I'd say.  We do extensive floorplanning in many
of our designs.  Stuff that is expected to be reused, either
multiple times in a design or over more than one design gets
floorplanned hierarchically in the code.  One time stuff is
generally done in the floorplanner since it is faster to do it
there and the code is more readable.  I've posted here several
times in the past on putting RLOCs in VHDL using the generate, and
I believe it is also on the comp.arch.fpga faq.

I'm not holding my breath for a hierarchical floorplanner.  We've
(XEUC and XPERTs) have been asking for it for as long as I can
remember, and it seems never to make it to the short list.  Before
that can be addressed, the new bugs in the 4.x floorplanner have
to be addressed just to get us back to where we were with 3.3sp8

Tim wrote:

> Jan Gray wrote
>
> > Ray will tell you to use VHDL which has generate. :-)
>
> Generate is a good feature of VHDL, but the point is that VHDL
> is a more complete programming language and it allows you to
> compute the functions which otherwise need something like a
> Python script.
>
> On the main issue, a hierarchical floorplan system keyed to
> "hierarchical EDIF" is not too difficult, but productising
> such a piece of software is not so trivial.  Keep pressing
> the X to do it.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759




Article: 41544
Subject: Re: powerpc in virtex2pro
From: Ray Andraka <ray@andraka.com>
Date: Tue, 02 Apr 2002 00:20:32 GMT
Links: << >>  << T >>  << A >>


Rick Filipkiewicz wrote:

> "Keith R. Williams" wrote:
>
> > Xilinx chose the right processor. ;-)
> >
> >
>
> Nah! It should have been one of the MIPS cores.
>

I voted for an RCA1802 knock off ;-)


--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41545
Subject: Re: Filter design problem
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Tue, 2 Apr 2002 09:04:28 +0800
Links: << >>  << T >>  << A >>
Hi, Adrian:

I know it's a pretty interesting topic on how to design a digital filter for
a complex filter.
Do you know any websites on this topic? Or else do you have any soft copy of
your
materials i can get from you? In fact you can opt trade for something from
me.
Thanks.

--
Best Regards,
-----------------------------------------------------------------
Xu Qijun
Engineer
OKI Techno Centre (S) Pte Ltd
Tel: 770-7049 Fax: 779-1621
Email: qijun@okigrp.com.sg

"Noddy" <g9731642@campus.ru.ac.za> wrote in message
news:1017299896.720952@turtle.ru.ac.za...
> Hi,
>
> This is more of a signal processing problem which I am implementing on
FPGA
> (Spartan II 200k). I have two 40 tap FIR filters for a complex signal. The
> imaginary filter is a normal low pass filter which has been convolved with
a
> hilbert transform. The real filter is just a normal low pass filter.
>
> My question is this: I want to add a dc blocker into the real filter to
> attempt to get my passbands in the imaginary and real filters the same.
The
> imaginary filter has one automatically due to the nature of the hilbert
> transform, which makes the roll-off to DC very large. As the filters were
> designed using a hamming window, my first attempt was to subtract a 40
unit
> hamming window from the real coefficients such that the DC gain of the
> coefficients was 0. This is effectively a DC block. However, due to the
> nature of the infinite negative spike I have put in the pass band, the
> roll-off to DC is not as large as the imaginary filter => pass bands do
not
> match.
>
> Does anyone have any other ideas on how to implement a DC block and still
> have the same roll-off to DC as that in a hilbert transform. It seems this
> won't be possible, since the "negative spike" in a hilbert transform is
> finite, but the DC block is infinite.
>
> Thanks
> Adrian
>
>
>



Article: 41546
Subject: Re: Laying out the design
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Mon, 01 Apr 2002 19:11:54 -0600
Links: << >>  << T >>  << A >>
        Although I am not sure if it will help, but what I will suggest
is to create two separate project files for X and Y.
Synthesize Y by itself, likely without I/O pads being inserted.
Then, create a blackbox for Y in X, and synthesize X without Y.
XST's user manual talks about how to declare a blackbox for a module.
Copy Y's netlist (If you are using XST, which I will assume, a .ngc
file.) to X's project directory, and run NGDBUILD.
NGDBUILD should automatically find Y's netlist, and will attach it to X.
You can put X and Y in the same directory to save time. (That way, you
won't have to copy Y's netlist each time you make modifications to Y.)
Now that X and Y are separated, you should be able to floorplan X and Y,
and even if you make modifications to Y, X's floorplan information won't
change. (In theory.)
Regarding the Floorplanner, I find UCF flow easier to deal with than the
regular flow.
Speaking of my wish list for ISE WebPACK, I will like to see FPGA Editor
being added to the future versions of ISE WebPACK.
I know most people won't use such a tool, and if that's the case, that's
fine with me, but I will probably use it to see how LUTs are being
routed in my design.




Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)




Spaced Cowboy wrote:
> 
> I've been playing with the Webpack floorplanner this weekend, and have
> created a few "planned" designs from modules within my verilog source. The
> question is how to use those nice layouts within the encompassing module:
> say for example I have module X that contains an instance of module Y. I've
> floorplanned Y, how do I get X to use the floorplanned design for Y when
> laying out X ?
> 
> Any hints gratefully received.
> 
> Simon

Article: 41547
Subject: Re: powerpc in virtex2pro
From: gacalac@yahoo.com (Alan Calac)
Date: 1 Apr 2002 17:40:43 -0800
Links: << >>  << T >>  << A >>
Microblase has an unofficial slogan too: 
"Half the size of Nios, and a quarter of the features".  

Xilinx certainly doesn't prefer this one, but it seems to be catching
on with those who have used both processors.

--------->Alan

Peter Alfke <palfke@earthlink.net> wrote in message news:<3CA54B02.A18049F2@earthlink.net>...
> "Cyrille de Brébisson" wrote:
> 
> > In our design we are using an ARM CPU. My question is:
> > Can we put an ARM in the virtex 2 pro?
> > Were can I find/buy an ARM cpu core source (or precompiled) file to program
> > in my FPGA?
> >
> 
> Cyrille,
> the answer to both your questions is: No.
> The PowerPC in Virtex-II Pro is a "hard" implementation, packing the
> microprocessor with its caches and MMU into the smallest possible silicon
> area, <4 square millimeters.
> What you seem to be looking for is a "soft" implementation, using the
> programmable logic "fabric".
> That solution is impractical for something as complex as PowerPC or even ARM.
> It would take up an unreasonable portion of a large chip, and achieve mediocre
> performance at best.
> Xilinx offers a soft microprocessor, called MicroBlaze, especially tuned for
> efficient implementation in the Virtex architecture. It is not as fast and
> capable as PowerPC, but uses only ~900 slices.
> "Half the size and twice the speed of NIOS" is the Xilinx slogan. Please, no
> flames...
> 
> Peter Alfke, Xilinx Applications

Article: 41548
Subject: Re: Any Stratix impressions based on results?
From: "Guy Schlacter" <g.schlact@attbi.com>
Date: Tue, 2 Apr 2002 01:48:56 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ray -
What would set me apart is the "secret methodology sauce" of 10 years of
inside Altera
experience.  Thus improvements are attained including: 
increased performance, increased device utilization,
 and decreased development schedule - all these results would be a few
things that set my services apart from the average user.

Thus, I was asking what kind of results people were seeing as the
baseline.
True, I could do my own pushbutton, but this would not provide me with 
apples to apples comparison because my process of obtaining these better
results start at the beginning
of the design process and can not truly be seperated out into pushbutton
and
non-pushbutton results as both benefit from earlier stages of my
methodology.

I hope you can understand this better with this explanation.
Thanks for questioning my intent.
Guy




"Ray Andraka" <ray@andraka.com> wrote in message
news:3C980C21.F136647D@andraka.com...

> Why?  Your clients can push the button just as well as you can.  How does
> that set you apart?
> 
> Guy Schlacter wrote:
> 
> >  Now as an independent consultant,
> > I need to sensitize myself to push-button expectations of users.
> >
> > Thanks,
> > Guy Schlacter
> > ex-Altera Field Specialist
> >
> > President
> > Abosulte Consulting, Inc.
> >
> > --
> > Posted via Mailgate.ORG Server - http://www.Mailgate.ORG




-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 41549
Subject: CAM info: Data Compression in FPGAs
From: "Guy Schlacter" <g.schlact@attbi.com>
Date: Tue, 2 Apr 2002 02:05:18 +0000 (UTC)
Links: << >>  << T >>  << A >>
For those looking for improved CAM efficiencies for larger CAMs ask 
your Altera FAE person for the STratix Cam Emulation write-up.
you will find "cheaper" costs of implementing 
larger CAMs rather than "burning" 16kbit block rams.
CAM implementation is not just a function of array size, but also, data
rate,
latency acceptable, and frequency/periodicity of 
implementing a search/matching on data.
Just a suggestion,
Guy



"John_H" <johnhandwork@mail.com> wrote in message
news:3CA8D347.47F2ED0E@mail.com...

> CAM based LZ would be spectacular.  I haven't seen that the Xilinx CAM
> implementations allowed the width and breadth needed for a decent LZW
> implementation (20 bits tag, 12 bits data, 4k elements per channel).  Oh, to
> have an embedded CAM with a worthwhile size!
> 
> 
> "Keith R. Williams" wrote:
> 
> > In article <3CA88D75.1468E42C@mail.com>, johnhandwork@mail.com says...
> > > Performance LZW compression is a bear.  The algorithm isn't friendly to
> > > single channels at top performance and under most circumstances requires
> > > an external SRAM (about 60 FPGA pins).  It's achievable but not a project
> > > for the feint of heart.
> >
> > What about a CAM based LZ?  Xilinx has datasheets describing how to
> > make a CAM out of BlockRAMs.  The CAM sizes seem reasonable for LZ (512
> > to 1024 entries give reasonable compression) in the moderate sized
> > Virtex-2.  Unless the chip has a lot more to do than LZ, the cost is
> > going to be outrageous though.
> >
> > ----
> >   Keith




-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.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
2017JanFebMarApr2017

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