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 48275

Article: 48275
Subject: VHDL v. Verilog, Xilinx v. Altera.
From: symon_brewer@hotmail.com (Symon)
Date: 15 Oct 2002 10:08:17 -0700
Links: << >>  << T >>  << A >>
Dear All,
     At last an answer to these interminable threads about which is
better! Just go to www.googlefight.com !

VHDL v. Verilog, winner is VHDL.
Xilinx v. Altera, winner is Altera.
Synchronous v. Asynchronous, winner is Asynchronous.
Hardware v. Software, winner is software.

     It's foolproof!?

                cheers, Syms.

Article: 48276
Subject: PCI simulation model, available as open source
From: Dave Nelson <pci_model@nelsim.com>
Date: Tue, 15 Oct 2002 10:15:44 -0700
Links: << >>  << T >>  << A >>

I have a PCI model for verilog simulators which includes:
    arbiter
    master(s)
    slave(s)
    monitor with GUI

It is designed to interface with PCI designs to exercise them and display
activity and protocol errors.

If there is interest, I will release this as open-source software for
free download.

Requirements: Unix/Linux/Solaris system with gcc compiler
              Verilog simulator with PLI interface

Please email me if you would find this useful.

Dave Nelson
pci_model@nelsim.com


Article: 48277
Subject: Re: FPGA breadboard with a SmartMedia Card to store the bit file.
From: "Austin Franklin" <austin@da98rkroom.com>
Date: Tue, 15 Oct 2002 13:16:29 -0400
Links: << >>  << T >>  << A >>

"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
news:ao9q80$rqb$1@agate.berkeley.edu...
> In article <3DA867BB.40301@mail.com>, John_H  <johnhandwork@mail.com>
wrote:
> >CPLDs are typically not SRAM based and maintain their programming on
> >startup.
> >
> >Take a look at the "System ACE" configuration solution from Xilinx, for
> >instance.  This method can use Compact Flash cards which is close to
> >what you're looking for.  Compact Flash is easier to use than SmartMedia
> >cards because both systems need some intelligence in the interface; in
> >SmartMedia, the intelligence is in the host or the reader while Compact
> >Flash has the smarts on the card.  This solution is great for the large
> >FPGA designs but not so good for the little ones (cost and space).
>
> Unless, of course, your app would benefit from having some other
> storage beyond just teh configuration, in which case Compact Flash is
> nice.
>
> Compact Flash is nice and cheap for 32, 64, and 128 MB cards, with
> microdrives if you need 1 GB of storage.

Last time I checked...a Xilinx PROM was something like $10+.  The SmartMedia
cards are only that much, if not less for the same bit capacity.  Of course,
you need the socket and the CPLD too...

Austin



Article: 48278
Subject: Re: Xilinx microblaze vs. picoblaze
From: emanuel stiebler <emu@ecubics.com>
Date: Tue, 15 Oct 2002 11:24:40 -0600
Links: << >>  << T >>  << A >>
Falk Brunner wrote:
> 
> "emanuel stiebler" <emu@ecubics.com> schrieb im Newsbeitrag
> news:3DABA42C.8321741C@ecubics.com...
> > Hi,
> >
> > anybody out here has some insight, why the 8 bit picoblaze (up 112 MHz)
> 
> 112 MHz (one hundred twelf megahertz???)
> In what device? the fastest Virtex-II??

http://www.xilinx.com/ipcenter/processor_central/picoblaze/index.htm

was even a typo. It runs at 116 MHz ;-)
at least in the press release ...

> My expirience is somewhere 50 MHz in a -5/-6 Spartan-II(E).

There are two "picoblazes". One for the Spartan, one for the Virtex.
Pretty different beasts.

> > is clocked lower than the 32 bit microblaze (up 150 MHz) ?
> 
> Looks like the microblaze is more pipelied than the picoblaze (which has
> some pipelining too). Picoblaze (Hello Ken ;-) was developed for minimum
> size on top priority, speed was second (AFAIK)

AFAIRC, the microblaze still needs only two clock per instruction ...

cheers

Article: 48279
Subject: xilinx: VirtexII in a pqfp208 or pqfp240 ?
From: emanuel stiebler <emu@ecubics.com>
Date: Tue, 15 Oct 2002 11:33:15 -0600
Links: << >>  << T >>  << A >>
Is there any chance we could see something like this ?
I would love to use the speed of the VirtexII on a cheaper PCB.

Am I the only one who is dreaming about this packaging ?

cheers

Article: 48280
Subject: Re: AHDL Command Reference?
From: Jacky Renaux <renaux.jacky@wanadoo.fr>
Date: 15 Oct 2002 17:39:48 GMT
Links: << >>  << T >>  << A >>

Hi , 
The xilinx webpack is getting a basic command which is translating 
AHDL to VHDL files 

this is a free package, you will have to "pack" a bit some created lines 
but it speed a lot design migration 

hope it will help you too 
 

-- 
Use our news server 'news.foorum.com' from anywhere.
More details at: http://nnrpinfo.go.foorum.com/

Article: 48281
Subject: Re: VHDL v. Verilog, Xilinx v. Altera.
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Tue, 15 Oct 2002 18:54:58 +0100
Links: << >>  << T >>  << A >>
Symon wrote
>      Just go to www.googlefight.com !
>
> VHDL v. Verilog, winner is VHDL.
> Xilinx v. Altera, winner is Altera.
> Synchronous v. Asynchronous, winner is Asynchronous.
> Hardware v. Software, winner is software.

schematic beats HDL ;-)




Article: 48282
Subject: Re: Xilinx microblaze vs. picoblaze
From: Goran Bilski <Goran.Bilski@Xilinx.com>
Date: Tue, 15 Oct 2002 11:03:16 -0700
Links: << >>  << T >>  << A >>
Hi,

MicroBlaze is more pipelined and is more floorplanned than PicoBlaze.
The 150 MHz for MicroBlaze is on a V2Pro and 116MHz for PicoBlaze is on VII-6.
MicroBlaze runs at 135 MHz on a VII-6.

Since PicoBlaze is optimized for area and more pipeline has a big area cost in
processor design.

There is also not that big difference on performance with different datasizes.
The carry-chain is pretty fast as soon you starting to use it.
A 64-bit MicroBlaze would probably run at 100 MHz and a 8 bit MicroBlaze would
just run a little faster than the 32-bit version since the control decoding will
probably be the limiting factor.

By the way for most instruction MicroBlaze needs only 1 clock/instruction.

Göran

emanuel stiebler wrote:

> Falk Brunner wrote:
> >
> > "emanuel stiebler" <emu@ecubics.com> schrieb im Newsbeitrag
> > news:3DABA42C.8321741C@ecubics.com...
> > > Hi,
> > >
> > > anybody out here has some insight, why the 8 bit picoblaze (up 112 MHz)
> >
> > 112 MHz (one hundred twelf megahertz???)
> > In what device? the fastest Virtex-II??
>
> http://www.xilinx.com/ipcenter/processor_central/picoblaze/index.htm
>
> was even a typo. It runs at 116 MHz ;-)
> at least in the press release ...
>
> > My expirience is somewhere 50 MHz in a -5/-6 Spartan-II(E).
>
> There are two "picoblazes". One for the Spartan, one for the Virtex.
> Pretty different beasts.
>
> > > is clocked lower than the 32 bit microblaze (up 150 MHz) ?
> >
> > Looks like the microblaze is more pipelied than the picoblaze (which has
> > some pipelining too). Picoblaze (Hello Ken ;-) was developed for minimum
> > size on top priority, speed was second (AFAIK)
>
> AFAIRC, the microblaze still needs only two clock per instruction ...
>
> cheers


Article: 48283
Subject: Re: Upgrading...
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Tue, 15 Oct 2002 20:04:38 +0200
Links: << >>  << T >>  << A >>
Just to double check, you are talking about the SET XILINX = {path} in my
config.sys file? (I am running Windows 98 in case this makes any difference)

adrian


> You can do separate installs for 3.3 and 4.2 on the same machine.  In
order to
> switch back and forth between them, you need to modify the XILINX
environment
> variable to point to the tools directory you are currently using.  Other
than
> that, there is nothing special that needs to be done.  IIRC, there was a
new
> xilinx registration number to enter when first installing 4.x, but that is
a
> one-time thing.
>
> I have both 3.3 and 4.2 installed on the same drive, different
sub-directories
> on my NT machine.  To switch, I change just the directory name in the
XILINX
> environment variable, then I'm good to go.  Can't use both at the same
time
> unless you are strictly command line, in which case you can use the set
command
> to do the enviroment locally.
>
> Noddy wrote:
>
> > Hi,
> >
> > I am presently designing for a Spartan II using Foundation 3.3 software.
We
> > have upgrades (still in their boxes) to Foundation 4.2 aswell as ISE
4.2. We
> > need to upgrade the software sometime as I am going to be redesigning
and
> > modifying for a Spartan IIE.
> >
> > My question is the following: I was under the impression the ISE was
really
> > only useful if I was going to design for Virtex. Under this
understanding,
> > will probably want to install the software for Foundation 4.2. However,
I
> > still want to use Foundation 3.3 as I am still working on the design,
and am
> > worried about the design having problems in 4.2. So what I want to do is
put
> > Foundation 4.2 onto a separate hard drive, and plug into the same
system.
> > Will I have any registry issues? Is it possible to run two versions of
the
> > Xilinx Foundation software on the same machine? Do have to do the entire
> > Xilinx licensing thing again when I install 4.2? Finally, should I
rather be
> > install ISE instead?
> >
> > Thanks
> >
> > Adrian
>
> --
> --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: 48284
Subject: Re: Xilinx microblaze vs. picoblaze
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Tue, 15 Oct 2002 20:06:43 +0200
Links: << >>  << T >>  << A >>
"emanuel stiebler" <emu@ecubics.com> schrieb im Newsbeitrag
news:3DAC4F58.D2AE56ED@ecubics.com...

> > My expirience is somewhere 50 MHz in a -5/-6 Spartan-II(E).
>
> There are two "picoblazes". One for the Spartan, one for the Virtex.
> Pretty different beasts.

?? R u sure?
I think there are NOT two picoblaze versions, since Sparten-II (why the hell
is everyone talking about Spartan when it is actually Spartan-II, which, our
honour, is a BIG difference???) is practically identical to Virtex.

> > size on top priority, speed was second (AFAIK)
>
> AFAIRC, the microblaze still needs only two clock per instruction ...

PICOBLAZE (TPFKAKCPSM , decode THIS;-)) executes EVERY instruction in two
clock cycles, this was made for simplicity (ressource usage). But still much
better than the original stupid 12 clocks/cycle design of the 8051  . .. .
I dont know about microblaze.

--
MfG
Falk





Article: 48285
Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?)
From: Neil Franklin <neil@franklin.ch.remove>
Date: 15 Oct 2002 20:07:45 +0200
Links: << >>  << T >>  << A >>
nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) writes:

> In article <6un0pgioiv.fsf@chonsp.franklin.ch>,
> Neil Franklin  <neil@franklin.ch.remove> wrote:
> >> How many users (outside a small cadre of open source true-believers)
> >> really do?
> >
> >As the "small cadre" is already in the 100'000s, those outside are not
> >really that important.
>
> Is the cadre of open source true blieveres that high?

Perhaps only 1-2 times 100'000, but it is astonishingly large. There
are a lot of people who have got fed up with closed source software.
Loads of then to recruit from.

And every time the "compromise and use closed when better" party burns
its fingers on yet annother free beer product that vanishes without
leaving source, the number grows.


> >> A very poor analogy.  C compilers can be simple (eg lcc), but you lose
> >> a good deal of performance (50%).
> >
> >Which is acceptabe for simple designs.
>
> We have this with LCC, and I'll argue that it is not acceptable to
> most.  People use GCC because it is competitive with commercial
> tools.  If they aren't competitive, all but a few early adopters will
> ignore them.

GCC also took time. It once was small, then it growed to what it is
today. I expect my stuff to start small and grow. So I an designeing
for it to be growable, but to already work from small up. How far and
how fast will be up to experimentation to see.


> Linus Torvald uses Bitkeeper because it does a better job, even if it
> does get RMS's panties in a twist.

In a _large_ twist. We will see whether Linux gets to regret this move
or not. Only time can show that.


> >Run it (I assume it to be VHDL or Verilog code) through an compiler
> >that targets my stuff as back end. Compare the results.
>
> The only way which this will occur is if you tie your flow in with the
> Xilinx flow:  If you want to do routing, accept post-placement XDL.
> If you just want to do bitfile manipulation, only do layers on Jbits.
> You will probably NEVER be able to do static timing analysis without
> being able to read the Xilinx databases.

And going through the official formats, all of them, is definitely too
much work. So I intend to be just compatible at the two endpoints,
source (where programmers put their time) at one, and bitstream (what
the chip wants to see) at the other.


> I doubt you could ever be independant of the Xilinx flow, but if you
> ever DO want to be, you are going to have to leverage that flow for as
> much as possible during development.

Or not waste time being compatible with it.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer
- hardware runs the world, software controls the hardware
  code generates the software, have you coded today?

Article: 48286
Subject: Re: FPGA breadboard with a SmartMedia Card to store the bit file.
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Tue, 15 Oct 2002 20:09:58 +0200
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@da98rkroom.com> schrieb im Newsbeitrag
news:uqojb9qj4l5j21@corp.supernews.com...
>
> "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
> news:ao9q80$rqb$1@agate.berkeley.edu...
> > In article <3DA867BB.40301@mail.com>, John_H  <johnhandwork@mail.com>
> wrote:
> > >CPLDs are typically not SRAM based and maintain their programming on
> > >startup.

I think this is not quite correct. If you take a closer look to the Xilinx
CPLDs datasheets, it says something about . . .configuration is finished
within 200us . .  .
So it looks like that CPLD (from Xilinx) are SRAM based CPLDs + Flash on one
chip.

--
MfG
Falk





Article: 48287
Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?)
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Tue, 15 Oct 2002 18:24:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <6u8z0zwp72.fsf@chonsp.franklin.ch>,
Neil Franklin  <neil@franklin.ch.remove> wrote:
>> Linus Torvald uses Bitkeeper because it does a better job, even if it
>> does get RMS's panties in a twist.
>
>In a _large_ twist. We will see whether Linux gets to regret this move
>or not. Only time can show that.

Personally, I think RMS could use a good twisting.  I much prefer BSD
style liscences, as they have more real freedom.  But thats a
religious issues, and I will say no more.

>> The only way which this will occur is if you tie your flow in with the
>> Xilinx flow:  If you want to do routing, accept post-placement XDL.
>> If you just want to do bitfile manipulation, only do layers on Jbits.
>> You will probably NEVER be able to do static timing analysis without
>> being able to read the Xilinx databases.
>
>And going through the official formats, all of them, is definitely too
>much work. So I intend to be just compatible at the two endpoints,
>source (where programmers put their time) at one, and bitstream (what
>the chip wants to see) at the other.

That will be a significant mistake, as the amount of work needed to
even get the "hello world" of FPGAs to compile will be enormous, an
not to mention significantly limiting the reach of your tools.

There are also really only 3 points where you should tying in, with
each one being a "leapfrog" process where you skip over more of the
tools:

Post Routing XDL: You should OUTPUT this so you can do static timing
analysis.  Without static timing analysis, NOBODY even remotely
serious will touch your tools.  I'm not kidding.  Static timing
analysis is essential, as there is no other way to know at what clock
a desgin can safely run.

The only other way is to reverse engineer the database format, with
the contents copyrighted so you can't distribute them anyway unless
you OK it with Xilinx.  So you want to start by using Xilinx static
timing analysis, before trying to ask nicely for the database format
and permission to distribute.


Post Placement XDL: You should start your tool, if you want to start
with routing and bitgen, taking this as input.  This allows you to
test your tool as you construct it, and allows you to leverage the
Xilinx toolflow to do mapping and placement and all other upstream
stuff.  This is a complete description of the design, after mapping,
in a form you can use.  The only things outside this representation at
this point are used for timing-driven back-annotation.


EDIF:  After you want to start doing mapping and placement as well,
this is the format which compilers (all compilers) targeting Xilinx
output as, with Xilinx specific libraries.  When you are reading in
EDIF and the static timing analysis libraries, you have completely
subsumed the Xilinx toolflow, which is what you want.


Don't bother with post-mapping, pre-placement XDL, it doesn't include
any user defined placement on modules, at least in 4.1 (yeah, I'm not
going to upgrade, what I got works for me).  :(


>> I doubt you could ever be independant of the Xilinx flow, but if you
>> ever DO want to be, you are going to have to leverage that flow for as
>> much as possible during development.
>
>Or not waste time being compatible with it.

It will save you considerably more time than it will cost you, and it
will allow you to at least get a skeleton working much earlier than
you otherwise would.

It will also make your tools usable by others.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 48288
Subject: Re: xilinx: VirtexII in a pqfp208 or pqfp240 ?
From: "Theron Hicks" <hicksthe@egr.msu.edu>
Date: Tue, 15 Oct 2002 14:28:09 -0400
Links: << >>  << T >>  << A >>
No you are not the only one.  The response I get is that the cost is minimal
to place the BGA type packages on a circuit board.  My experience tends to
lead me to think otherwise.  When I build a prototype I prefer that the
package be something I can solder myself.  The fact is that I typically
build only a few devices of each type.  Usually the prototype stage is only
5 boards or so.  I do not have the quantity of boards to allow the assembler
to experiment with my PCB in order to tweak their process to mount a BGA on
my board.  Nor can I use a standard board as the system will contain some
very sensitive low noise high spped analog circuitry.  As a result I stuck
with the SpartanXL for quite a while.  Now that the tools do not support the
SpartanXL I use the Spartan2E.


The Virtex2 would be an awesome device for me if it met three criteria.

1.    Available in a more traditional leaded package.
2.    More clock buffers readily accessable.  Each DCM should have at least
4 clock buffers available.  (5 or 6 buffers could be shared between two DCMs
acceptably)
3.    Parts readily available for purchase in small quantities for
prototyping.

Xilinx... Are you listening?  I hope you are not intentionally trying to cut
the small startups out of the picture?  That would be a bad move.

On the plus side... Having Xilinx people monitor this newsgroup is a very
strong plus.  That enables me to use the Spartan2 series with some ease.

Thanks,
Theron

"emanuel stiebler" <emu@ecubics.com> wrote in message
news:3DAC515B.A359A547@ecubics.com...
> Is there any chance we could see something like this ?
> I would love to use the speed of the VirtexII on a cheaper PCB.
>
> Am I the only one who is dreaming about this packaging ?
>
> cheers



Article: 48289
Subject: Re: xilinx: VirtexII in a pqfp208 or pqfp240 ?
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Tue, 15 Oct 2002 18:35:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
emanuel stiebler <emu@ecubics.com> wrote:
: Is there any chance we could see something like this ?
: I would love to use the speed of the VirtexII on a cheaper PCB.

: Am I the only one who is dreaming about this packaging ?

The question came up before. One answer was, that EMC problems nearly
prohibit use of leaded packages for devices fast and powerfull like the
virtex. One proposal was to put out a BGA package with 1.27 mm pitch. 4
Layer PCB prototypes with 0.3mm drill, 0.15mm lines/spaces designrules are
afordable and a 4 row BGA can be routed with these rules. 

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 48290
Subject: Re: Xilinx microblaze vs. picoblaze
From: emanuel stiebler <emu@ecubics.com>
Date: Tue, 15 Oct 2002 12:48:01 -0600
Links: << >>  << T >>  << A >>
Goran Bilski wrote:
> 
> There is also not that big difference on performance with different datasizes.
> The carry-chain is pretty fast as soon you starting to use it.
> A 64-bit MicroBlaze would probably run at 100 MHz and a 8 bit MicroBlaze would
> just run a little faster than the 32-bit version since the control decoding will
> probably be the limiting factor.
> 
> By the way for most instruction MicroBlaze needs only 1 clock/instruction.

That was the answer I was looking for, even that I didn't make
it clear what exactly my question was ;-)

So, we can't go faster at the actual Xilinx parts than around 100
"MIPS",
independent, if it is a 8,16,32,64 bit processor, right ?

And the problem is really in the instruction decoding, control path.

Thanks

Article: 48291
Subject: Re: Xilinx microblaze vs. picoblaze
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Tue, 15 Oct 2002 18:53:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3DAC62E1.5246FDF7@ecubics.com>,
emanuel stiebler  <emu@ecubics.com> wrote:
>That was the answer I was looking for, even that I didn't make
>it clear what exactly my question was ;-)
>
>So, we can't go faster at the actual Xilinx parts than around 100
>"MIPS",
>independent, if it is a 8,16,32,64 bit processor, right ?
>
>And the problem is really in the instruction decoding, control path.

Well, you CAN, but you are going to have to go multithreaded.  If your
critical path is 1 32 bit add + bypassing, yeah, you really can't do
any faster.  The only way to pipeline this (or the instruction decode,
if that is the critical factor) is to use an interleaving,
multithreading strategy (aka $C$-slow a microprocessor).
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 48292
Subject: Re: VHDL v. Verilog, Xilinx v. Altera.
From: nospam <nospam@please.com>
Date: Tue, 15 Oct 2002 20:04:17 +0100
Links: << >>  << T >>  << A >>
symon_brewer@hotmail.com (Symon) wrote:


>     At last an answer to these interminable threads about which is
>better! Just go to www.googlefight.com !

>VHDL v. Verilog, winner is VHDL.
>Xilinx v. Altera, winner is Altera.
>Synchronous v. Asynchronous, winner is Asynchronous.
>Hardware v. Software, winner is software.

>     It's foolproof!?

Completely. The site can also be used to prove sex is 177 times better than
VHDL. 

Article: 48293
Subject: Re: Xilinx microblaze vs. picoblaze
From: Goran Bilski <Goran.Bilski@Xilinx.com>
Date: Tue, 15 Oct 2002 12:38:59 -0700
Links: << >>  << T >>  << A >>
Hi,

If your definition of MIPS is maximum number of instruction per clock cycle, the 150
MHz MicroBlaze has 150 MIPS.
There is also possible to do a 200+ MIPS processor, if you want to optimize around
MIPS.
A heavy pipelined processor without any forwarding in the pipeline could easy run at
200+ MHz.
Would that processor be more efficient than MicroBlaze? I don't think so, the number
of stall due to pipeline hazardous will actually give it a lower performance than
MicroBlaze.

Processors in FPGAs has to be handle more delicate than ASIC processor due to
forwarding in pipeline could easy remove all benefits gain by more pipeline stages. In
FPGA a mux cost as much as an ALU which is not the case for ASIC or custom design.

Another approach is to rely on advanced compiler techniques for handling all the
pipeline hazardous but it would make it almost impossible to program the processor in
assembler since the user has to do the handling.
I personally don't think that this approach would gain that much more performance than
MicroBlaze and you have to spend a lot of resources on the compiler which could be
used for other stuff.

Another approach is to add multi-threading capabilities but I think that
multi-processing is better for FPGA than multi-threading.

Göran Bilski

emanuel stiebler wrote:

> Goran Bilski wrote:
> >
> > There is also not that big difference on performance with different datasizes.
> > The carry-chain is pretty fast as soon you starting to use it.
> > A 64-bit MicroBlaze would probably run at 100 MHz and a 8 bit MicroBlaze would
> > just run a little faster than the 32-bit version since the control decoding will
> > probably be the limiting factor.
> >
> > By the way for most instruction MicroBlaze needs only 1 clock/instruction.
>
> That was the answer I was looking for, even that I didn't make
> it clear what exactly my question was ;-)
>
> So, we can't go faster at the actual Xilinx parts than around 100
> "MIPS",
> independent, if it is a 8,16,32,64 bit processor, right ?
>
> And the problem is really in the instruction decoding, control path.
>
> Thanks


Article: 48294
Subject: Re: VHDL v. Verilog, Xilinx v. Altera.
From: Tom Burgess <tom.burgess@nrc.ca>
Date: Tue, 15 Oct 2002 12:57:07 -0700
Links: << >>  << T >>  << A >>
nospam wrote:
> symon_brewer@hotmail.com (Symon) wrote:
> 
> 
> 
>>    At last an answer to these interminable threads about which is
>>better! Just go to www.googlefight.com !
> 
> 
>>VHDL v. Verilog, winner is VHDL.
>>Xilinx v. Altera, winner is Altera.
>>Synchronous v. Asynchronous, winner is Asynchronous.
>>Hardware v. Software, winner is software.
> 
> 
>>    It's foolproof!?
> 
> 
> Completely. The site can also be used to prove sex is 177 times better than
> VHDL. 

And HTML is 5.6 times better than sex.


Article: 48295
Subject: Re: xilinx: VirtexII in a pqfp208 or pqfp240 ?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 15 Oct 2002 13:01:19 -0700
Links: << >>  << T >>  << A >>
Try using a ff1517 2V8000....

It is the number of pins.

Austin

Theron Hicks wrote:

> Uwe,
>     I can route the package,  I just can't assemble it.  Changing the number
> of pins won't solve the problem.  Furthermore, I don't buy that the EMC
> problems are insurmountable.  I regularly build ECL circuits at 1GHz in
> standard SOIC packages.  In fact, try to buy 100K ECL in anthing but leaded
> packages be they gullwing or J-lead.  The only available packages are
> leaded, not BGA.  For example the MC100EP32 is rated for 4 Gigahertz toggle
> (divide by 2).  It is only available in an 8 pin SOIC or 8 pin TSSOP
> package.  Check the http://www.onsemi.com web site  Only the reduced swing
> ECL (RSECL) parts go to BGA.  Those are rated for 12 GIGAHERTZ toggle.
>     Unless the problems are simply caused by the number of I/O pins then I
> am skeptical of the EMC issue.
>
> Just my opinionated opinion,
> Theron Hicks
>
> "Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message
> news:aohn4s$olb$1@news.tu-darmstadt.de...
> > emanuel stiebler <emu@ecubics.com> wrote:
> > : Is there any chance we could see something like this ?
> > : I would love to use the speed of the VirtexII on a cheaper PCB.
> >
> > : Am I the only one who is dreaming about this packaging ?
> >
> > The question came up before. One answer was, that EMC problems nearly
> > prohibit use of leaded packages for devices fast and powerfull like the
> > virtex. One proposal was to put out a BGA package with 1.27 mm pitch. 4
> > Layer PCB prototypes with 0.3mm drill, 0.15mm lines/spaces designrules are
> > afordable and a 4 row BGA can be routed with these rules.
> >
> > Bye
> > --
> > Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
> >
> > Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Article: 48296
Subject: Re: xilinx: VirtexII in a pqfp208 or pqfp240 ?
From: "Theron Hicks" <hicksthe@egr.msu.edu>
Date: Tue, 15 Oct 2002 16:02:26 -0400
Links: << >>  << T >>  << A >>
Uwe,
    I can route the package,  I just can't assemble it.  Changing the number
of pins won't solve the problem.  Furthermore, I don't buy that the EMC
problems are insurmountable.  I regularly build ECL circuits at 1GHz in
standard SOIC packages.  In fact, try to buy 100K ECL in anthing but leaded
packages be they gullwing or J-lead.  The only available packages are
leaded, not BGA.  For example the MC100EP32 is rated for 4 Gigahertz toggle
(divide by 2).  It is only available in an 8 pin SOIC or 8 pin TSSOP
package.  Check the http://www.onsemi.com web site  Only the reduced swing
ECL (RSECL) parts go to BGA.  Those are rated for 12 GIGAHERTZ toggle.
    Unless the problems are simply caused by the number of I/O pins then I
am skeptical of the EMC issue.

Just my opinionated opinion,
Theron Hicks

"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message
news:aohn4s$olb$1@news.tu-darmstadt.de...
> emanuel stiebler <emu@ecubics.com> wrote:
> : Is there any chance we could see something like this ?
> : I would love to use the speed of the VirtexII on a cheaper PCB.
>
> : Am I the only one who is dreaming about this packaging ?
>
> The question came up before. One answer was, that EMC problems nearly
> prohibit use of leaded packages for devices fast and powerfull like the
> virtex. One proposal was to put out a BGA package with 1.27 mm pitch. 4
> Layer PCB prototypes with 0.3mm drill, 0.15mm lines/spaces designrules are
> afordable and a 4 row BGA can be routed with these rules.
>
> Bye
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------



Article: 48297
Subject: Re: Xilinx microblaze vs. picoblaze
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Tue, 15 Oct 2002 20:14:45 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3DAC6ED3.A8E721C4@Xilinx.com>,
Goran Bilski  <Goran.Bilski@Xilinx.com> wrote:

>Another approach is to add multi-threading capabilities but I think that
>multi-processing is better for FPGA than multi-threading.

I disagree, based on the following observation: A 4-5 stage pipeline
is going to have 2-3 levels of FPGA logic between each pipeline stage,
suggesting that there are plentiful registers which can be exploited
if the design is retimed and interleaved.

Actual experience:  Leon I (synthesized Sparc), Virtex:  

Initially:      23 MHz
Retimed:        25 MHz
2-slow retimed: 46 MHz (so each thread at 23 MHz)
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 48298
Subject: Re: Xilinx microblaze vs. picoblaze
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 15 Oct 2002 21:30:48 +0100
Links: << >>  << T >>  << A >>


Goran Bilski wrote:

> Hi,
>
> MicroBlaze is more pipelined and is more floorplanned than PicoBlaze.
> The 150 MHz for MicroBlaze is on a V2Pro and 116MHz for PicoBlaze is on VII-6.
> MicroBlaze runs at 135 MHz on a VII-6.
>

Aha! There we have it caught on this very NG a Xilinx person admitting that
floorplanning is important :-)).


Article: 48299
Subject: Re: VHDL v. Verilog, Xilinx v. Altera.
From: mikeandmax@aol.com (Mikeandmax)
Date: 15 Oct 2002 20:36:48 GMT
Links: << >>  << T >>  << A >>
would these be signed or unsigned integer - logic_vector, or bit literals?
>> Completely. The site can also be used to prove sex is 177 times better than
>> VHDL. 
>
>And HTML is 5.6 times better than sex.





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