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
2019JanFebMar2019

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 54050

Article: 54050
Subject: Re: What would it take?
From: "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca>
Date: Tue, 01 Apr 2003 04:45:55 GMT
Links: << >>  << T >>  << A >>

That's an interesting thought.  But how will you record which CLBs/LEs are
defective?  At one bit per CLB, you're approaching 100Kbits of programmable
data.  And you need to store this at test time, via one-time programmable
fuses or NV memory of some sort.  How much impact will you have on your test
times?

- Paul


"Jerry" <nospam@nowhere.com> wrote in message
news:v8i3rii71fhq6a@corp.supernews.com...
> With scan one can get above 99% fault coverage so detecting defective
logic
> shouldn't be a problem.
>
> > Otherwise if there are defects that are detected during the manufacture
> > process, would it be possible to store a defect list that could be
> retrieved
> > by the tools ?
>
> Yes thats what I'm getting at. During test the defective CLBs and routes
are
> stored in on chip memory. At power on
> time the on chip router takes the defective list in to consideration to do
> the palce and route.
>
> Maybe whats stored is the results of the Xilinx mapping process.
>
> "Robert Finch" <robfinch@sympatico.ca> wrote in message
> news:Bg6ia.1407$DD6.332428@news20.bellglobal.com...
> > > place and router could map around defective silicon thereby boasting
> > yield.
> > > Anyway its a thought, maybe a thread, maybe
> > > a product?
> > >
> >
> > How would it be possible to know whether or not there is a defect in the
> > FPGA until the application is actually run ?
> >
> > Surely in a multi-mega gate FPGA it's not possible to test every
possible
> > combination of programming pattern that could be used ?
> >
> > Otherwise if there are defects that are detected during the manufacture
> > process, would it be possible to store a defect list that could be
> retrieved
> > by the tools ?
> >
> > Rob
> >
> >
> >
>
>



Article: 54051
Subject: Re: What would it take?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 01 Apr 2003 17:19:08 +1200
Links: << >>  << T >>  << A >>
Jerry wrote:
> 
> With scan one can get above 99% fault coverage so detecting defective logic
> shouldn't be a problem.
> 
> > Otherwise if there are defects that are detected during the manufacture
> > process, would it be possible to store a defect list that could be
> retrieved
> > by the tools ?
> 
> Yes thats what I'm getting at. During test the defective CLBs and routes are
> stored in on chip memory. At power on
> time the on chip router takes the defective list in to consideration to do
> the palce and route.

That's still a layer of complexity that's not needed.

Altera claim redundancy - so are doing something.
They also noted it has a significant die impact, then
go on to say that's offset by yield gains, so they then claim 
'a smaller effective die size'.

 One simple way to implement that is with a row bypass scheme,
where a swap mux allows a spare, good row to replace a failed one.
It needs a laser-fuse or similar at-die-test method to set the MUX,
which is only needed on a fail. ( so good chips test faster )
 Once done, it looks 100% identical in logic, so does not need
fix-adaption.

-jg

Article: 54052
Subject: Re: What would it take?
From: "Robert Finch" <robfinch@sympatico.ca>
Date: Tue, 1 Apr 2003 02:49:50 -0500
Links: << >>  << T >>  << A >>
How about just allowing the design tools to run defect tests on an FPGA ?
That way nothing in the FPGA would have to change? Does production testing
check the entire FPGA or does it quit once a defect is detected ? Is there a
way to tell how defective the part is ?
It wouldn't be that useful for production, but for prototyping it might be
handy.
It seems a bit of waste to throw out FPGA's when there's only a single bad
route or LUT, when a lot of the time that resource doesn't even end up
getting used anyway.

Rob





Article: 54053
Subject: Re: uP interface question
From: "Jonathan Bromley" <jonathan.bromley@doulos.co.uk>
Date: Tue, 1 Apr 2003 08:56:03 +0100
Links: << >>  << T >>  << A >>
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:Z2%ha.215$Iz6.14915853@newssvr14.news.prodigy.com...
> In order to maximize access speed I'm thinking of using both edges of the
> uP's WE pulse to run these SelecRAM ports.  The idea is to capture the
data
> byte on the leading edge and use the trailing edge to increment the
address
> counter that is driving the SelectRAM block.  With this, all the uP has to
> do is present  new data and pulse WE until it fills the memory bank.
> I'm looking for feedback on this technique.  Any problems?  Any reason for
> not taking this approach?  Any other approaches that might warrant
> consideration?

I've used this kind of "autoincrement" mechanism successfully in the
past, but you must pay attention to the details.

I'm guessing that your FPGA system clock is way faster than the
CPU I/O write cycles, so it's reasonable to run some kind of
state machine inside the FPGA, controlled by activity on WE.
That way you can schedule your memory writes and address updates
in whatever way is most appropriate.  You could even do
address pre-increment (instead of post-increment) if you wanted.

Look out for data setup and hold times relative to WE edges.  Like
I said, it's all in the detail.  Watch out, too, for the
comparatively long delays through FPGA I/Os - particularly if
you're relying on timing relative to the CPU clock, and you
generated that CPU clock inside the FPGA.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.



Article: 54054
Subject: Re: [Question] FPGA/PLX9054
From: already5chosen@yahoo.com (Michael S)
Date: 1 Apr 2003 00:21:13 -0800
Links: << >>  << T >>  << A >>
Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0303311512.2a51334e@posting.google.com>...
> "Garrett Mace" <g.ryan@macetech.com> wrote in message news:<v8d6qmog6fr357@corp.supernews.com>...
> > Simple question, for those who've done it before:
> > 
> > How many I/O's are required to implement an interface to PLX9054?
> > 
> > I'm running pretty tight on I/O right now, and this may not be a high-volume
> > project, so the customer may prefer $18 extra per board as opposed to $2000
> > for a Xilinx core (still fuzzy on that, you can use and sell the $2000 IP on
> > one project, right?).
> > 
> > I can get by with the ~50 pins needed for in-FPGA PCI; do I need much more
> > than that to use a PLX chip?
> 
> Well, for starters, you could look at the PLX documentation and count
> how many pins are used by the local bus.
> 
> You have to choose the PLX local bus mode, either "C" (non-muxed
> address and data bus) or "J" (muxed address and data bus).  There's
> another dozen or so control lines you'll need.  If you only require an
> 8-bit local bus, you can save some pins.  If you need all 32 data
> pins, and need to decode all 32 address bits, AND don't want to use
> the "J" mode (does ANYONE use the "J" mode?), then you'll need maybe
> 80 pins.
>  

We use J mode exclusively in all our newer designs. We feel really
sorry that we used C mode earlier. For the systems like ours which
have nothing, but FPGA, on the PLX local bus, C mode is pure wast of
pins with zero advantage.
The complete J mode 32bit interface (no support for local bus
mastering) requires only 41 pins in the FPGA - LAD[31:0], LBE[3:0],
ADS#, BLAST#, LW/R#, READY# and LCLK.
DT/R# and DEN# are not necessery. 
If you don't need byte/word wide writes, you don't have to connect
LBE[3:0].
For the demand-mode DMA - connect DREQn#. You can do fine without
DACKn#.
For the interrupt to host - connect LINT#.

+ There is a way to configure your FPGA with PCI9080/54/54 signals
witout PROM and additional PLDs. Think a little and you would find it
yourself. I'm not going to tell you how :)

Article: 54055
Subject: Re: ModelSIM XE wave files
From: "Michael Nicklas" <michaeln@nospam.slayer.com>
Date: Tue, 1 Apr 2003 09:59:28 +0100
Links: << >>  << T >>  << A >>
Kevin, thanks very much!

this is exactly what I was after!!!

Mike

"Kevin Neilson" <kevin_neilson@removethistextattbi.com> wrote in message
news:w70ia.321601$sf5.300503@rwcrnsc52.ops.asp.att.net...
> Here are the methods I use:
>
> o Do a 'print screen' to copy the image to the paste buffer.  Then you can
> paste it into Word.  This is quick, but the image is big.
>
> o Do the same thing, but paste it into a program like Paint, and then you
> can crop it and save it as JPEG if you wish.
>
> o Use the Adobe Acrobat (the one you have to buy) PDF distiller function.
> You print the image, but use the PDF Distiller instead of a printer
driver.
> The result is a small, clean, B&W image that you can put in docs or just
> print out by itself.
>
> -Kevin
>
> "Michael Nicklas" <michaeln@nospam.slayer.com> wrote in message
> news:b6927n$6sp$1$8300dec7@news.demon.co.uk...
> > Hi
> >
> > does anybody know if there is a way to export the wave file created
during
> a
> > simulation to a Word document or other package instead of just taking a
> > screen capture??
> >
> > I honestly cant seem to find anything about this in the pdf
documentation
> or
> > release notes etc.
> >
> > Thanks in advance.
> >
> > --
> > Cheers!
> >
> > Mike
> >
> >
>
>



Article: 54056
Subject: parity checking trick for PCI core
From: praveenkumar1979@rediffmail.com (praveen)
Date: 1 Apr 2003 03:05:22 -0800
Links: << >>  << T >>  << A >>
Hello Sirs/Friends,
I am designing a PCI core in which i have parity checker module. I
wanted to know how can design a parity checker which can meet the PCI
specification. I will have registered AD[31:0] and C/BE[3:0] signal
whose parity should be checked and PAR signal come in the next clock
and i have signal the  PERR the next clock itself. How to design this.
Waiting for ur reply
Praveen

Article: 54057
Subject: Re: Spartan vs. Cyclone for arithmetic functions
From: Ray Andraka <ray@andraka.com>
Date: Tue, 01 Apr 2003 13:41:39 GMT
Links: << >>  << T >>  << A >>
A+B+C can't be done with one LUT deep logic unless C is a single bit carry in,
in which case Altera does this too.  The advantage Xilinx offers on arithmetic
is that it can handle adds with more complex controls on them than Altera can
because they have a 4 input LUT available for the sum function, where Altera has
a 3 input LUT.  Altera adds some dedicated logic around the LUT in Cyclone to
permit an add-subtract or an add-mux, which improves the usability relative to
older Altera devices.

sanjay wrote:

> Hi Matt,
> what Ray says is perfect.
> There is no competition to Spartan-IIE when it comes to arithmatic
> operations.
> Apart from SRL [ which according to Ray is biggest plus point of Xilinx ],
> LUT can be configured as Distributed RAM which may be useful to you.
> This you can't do with Cyclone.
> Also 3 operand arithmatic Function [Sum = A+B+C]  goes in one Logic Block in
> Spartan-IIE, which takes two Logic Blocks with Cyclone.
> Apart from that Spartan-II E has Mult-AND for doing Fast Multiplications.
>
> So I don't think there can be a any substitute for Spartan-IIE for your app.
> --Sanjay

--
--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: 54058
Subject: Re: [Question] FPGA/PLX9054
From: "Garrett Mace" <g.ryan@macetech.com>
Date: Tue, 1 Apr 2003 07:49:48 -0600
Links: << >>  << T >>  << A >>
(i meant to say J mode *was* attractive...obviously)




-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Article: 54059
Subject: Re: [Question] FPGA/PLX9054
From: "Garrett Mace" <g.ryan@macetech.com>
Date: Tue, 1 Apr 2003 07:50:57 -0600
Links: << >>  << T >>  << A >>
OK...this is bad. Switch ISP's today and now my news server's got a stupid
banner after every post.

"Garrett Mace" <g.ryan@macetech.com> wrote in message
news:3e8999b4$1_4@corp.newsgroups.com...
> (i meant to say J mode *was* attractive...obviously)
>
>
>
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----==  Over 80,000 Newsgroups - 16 Different Servers! =-----




-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Article: 54060
Subject: Re: Looking for Virtex2Pro and Linux (PPC)
From: Peter Ryser <ryserp@xilinx.com>
Date: Tue, 01 Apr 2003 08:33:57 -0800
Links: << >>  << T >>  << A >>
John, Martin,

Linux is already ported for Virtex-II Pro including device drivers for our
most often used peripherals. The Linux distribution is available through
licenses from MontaVista (http://www.mvista.com) or from the open source
repository in the linuxppc_2_4_devel tree (http://www.penguinppc.org).

The same drivers can also be used for any uClinux port for MicroBlaze.

John, if you don't mind, keep me posted on how the uClinux port goes.

- Peter


John Williams wrote:

> Martin wrote:
>
> > Also I'm looking for an operation system for the hardcore PPC 405 in
> > the virtex 2 pro.
> > Is there an open source projekt which have ported linux for the PPC
> > for the virtex 2 pro?
>
> Hi Martin,
>
> Does the PPC in V2pro have an MMU (I think it does?)?  If so, you should
> be able to get standard PPC linux up and running pretty quickly.  This
> won't be like installing linux on a PC from a red hat distro, but it's
> feasible to get something up and running reasonably quickly.  You'll
> have to do all the hardware interfacing stuff (interrupts, MMU setup etc
> etc).  At least the deep kernel source should work unchanged.
>
> If it does not have an MMU, then you'll need to look into uClinux
> (www.uclinux.org).   There is no PPC_nommu branch in the uclinux source,
> so you'd have to do the port yourself.  Not trivial, but a great
> learning exercise.   I'm busy porting uClinux to the microblaze - I've
> just about got a complete kernel image ready to bring into the debugger!
>
> The two books you simply *must* have for this project are "Understanding
> the Linux Kernel" by Bovet & Cesati, and "Linux Device Drivers" by
> Rubini & Corbet, both published by O'Reilly.  The 2nd one is available
> freely as PDFs from somewhere on O'Reailly's website.
>
> Regards,
>
> John


Article: 54061
Subject: Re: [Question] FPGA/PLX9054
From: Bassman59a@yahoo.com (Andy Peters)
Date: 1 Apr 2003 09:37:28 -0800
Links: << >>  << T >>  << A >>
already5chosen@yahoo.com (Michael S) wrote in message news:<f881b862.0304010021.1e95769b@posting.google.com>...

> We use J mode exclusively in all our newer designs. We feel really
> sorry that we used C mode earlier. For the systems like ours which
> have nothing, but FPGA, on the PLX local bus, C mode is pure wast of
> pins with zero advantage.
> The complete J mode 32bit interface (no support for local bus
> mastering) requires only 41 pins in the FPGA - LAD[31:0], LBE[3:0],
> ADS#, BLAST#, LW/R#, READY# and LCLK.
> DT/R# and DEN# are not necessery. 
> If you don't need byte/word wide writes, you don't have to connect
> LBE[3:0].
> For the demand-mode DMA - connect DREQn#. You can do fine without
> DACKn#.
> For the interrupt to host - connect LINT#.

Now that I've thought about it, "J" mode is probably perfect if you
are implementing an SDRAM controller in the FPGA.

It boils down to: "do I need to have the local bus give me an address
every cycle?"
 
> + There is a way to configure your FPGA with PCI9080/54/54 signals
> witout PROM and additional PLDs. Think a little and you would find it
> yourself. I'm not going to tell you how :)

ummm, use an ISP CPLD?

Seriously, tho', I guess you would use the FPGA's parallel config
mode.

--a

Article: 54062
Subject: Re: Xilinx announces 90nm sampling today!
From: kolja@bnl.gov (Kolja Sulimma)
Date: 1 Apr 2003 10:59:12 -0800
Links: << >>  << T >>  << A >>
Austin Lesea <Austin.Lesea@xilinx.com> wrote 
> I think you can make a good educated guess at what the core voltage is
> for 90 nm, however.

You fab with IBM, so it looks like 0.7V to 1.3V, probably 1.0V ???
http://www-3.ibm.com/chips/products/asics/products/stdcell.html

Kolja Sulimma

Article: 54063
Subject: Re: DSP-FPGA interface
From: "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it>
Date: Tue, 01 Apr 2003 19:44:15 GMT
Links: << >>  << T >>  << A >>
"Tony McKay" <tonym@gallagher.co.nz> ha scritto nel messaggio
news:927d5a5c.0303311221.29028391@posting.google.com...

> > 'f2407 is a fixed point DSP and has something between
> > 100 and 200 MIPS,
> > while c67xx family is floating point and some models go
> > beyond 2000
> > MFLOPS. They aren't exactly equivalent. ;)
>
> Its worse than that, the 240X are 40MIPS tops.

You are right, I was thinking to the 28x family instead of 24x...

> Mybe the 240X could be used with the 67XX. The 2402 has 6
> PWMs and the
> 2407 has 12 as well as heaps of other peripherals that
> maybe handy,
> like I/O, in-circuit writable flash, and serial commms.
> This may free
> up the 67XX to do other tasks. If cost is a big factor
> then mybe a
> cheap micro to run the peripherals? You could send it a
> command then
> leave it to accomplish its job.

There is a big drawback: while the FPGA development tools are free,
developing for 24x will cost you $4000 (Code Composer Studio for 2000
family) plus $2000 (JTAG interface for emulation).

--
Lorenzo



Article: 54064
Subject: Re: More xilinx webpack verilog questions: always @(clock) legal?
From: sharp@cadence.com (Steven Sharp)
Date: 1 Apr 2003 12:44:06 -0800
Links: << >>  << T >>  << A >>
Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0303311531.415ad136@posting.google.com>...
>  
> Your comparison, 
> 
>     if (fstate >= 50)
> 
> may not do what you want.  I would guess that fstate is not declared
> an integer.  However, Verilog helpfully considers the constant 50 to
> be an integer, which is a 32-bit signed value.  What happens is that
> fstate is sign-extended to a 32-bit integer, and a bit-for-bit
> comparison is made.

While it is possible that some tool does this, it would be wrong
to do so.

The IEEE Verilog-1995 standard does not specify what happens with
mixed signed and unsigned values, but Verilog-XL, the de facto
standard, does not do it this way.  The IEEE Verilog-2001 standard
isn't terribly clear in this area, but it tries, and the intent is
known.

If fstate is unsigned (not declared as an integer or a signed reg
or wire), then both operands will be converted to unsigned before
any width extension.  So fstate will be zero-extended to 32 bits,
not sign-extended.  Then an unsigned compare will be done.

There will be some unexpected results for signed arithmetic under
the Verilog-2001 rules.  But they will be from converting everything
to unsigned whenever there is anything unsigned in the expression,
not from unexpectedly converting things to signed.

It is still good advice to avoid mixing signed values (such as
unsized decimal constants) and unsigned ones.  The rules in the
standard for such situations are difficult to understand, both
for users and for tool implementors.  Even if we get the wording
in the standard clarified, it still won't match what many people
will expect based on experience with other languages.

Article: 54065
Subject: Re: XC9572XL Macrocell power
From: "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com>
Date: Wed, 2 Apr 2003 08:46:33 +1200
Links: << >>  << T >>  << A >>
"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message
news:b6cqqa$mof$1@news.tu-darmstadt.de...
> Ralph Mason <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote:
> : I have this device configured to use the 'low power' setting for all the
> : macrocells.
>
> : I am using webpack and did this by right clicking on 'Implement Design',
> : Properties, Basic, Macrocell Power Setting.
>
> : However I need 4 of the Macrocells in STD power mode (they drive leds,
and
> : won't in Low power mode)
>
> : How can I go about overriding the default setting for just those
macrocells?
> : Is there a vhdl attribute I can use on the pin?
>
> Look for the constraint guide. PWR_MODE should be the option that you
want.

Hmmmm....

I have done this and the chip viewer shows the output macrocells for the
leds as STD power, and all the others as low. Exactly as expected.

However the leds still don't work (they work if I set the powermode of the
whole device to STD as above) - does it matter that a STD power marco cell
is driven by a low power one?

Does anyone have any ideas?

Thanks
Ralph



Article: 54066
Subject: Re: XC9572XL Macrocell power
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Tue, 1 Apr 2003 21:36:14 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ralph Mason <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote:
: I have done this and the chip viewer shows the output macrocells for the   
: leds as STD power, and all the others as low. Exactly as expected.

: However the leds still don't work (they work if I set the powermode of the
: whole device to STD as above) - does it matter that a STD power marco cell
: is driven by a low power one?

: Does anyone have any ideas?

The macrocells  are inside the chip. The LEDs are drive by the output. Show
us how you drive the LEDS. Only if you clock the LEDS well above perhaps 20
MHz, the powersetting of the Makrocells will affect the LED drive
capability.

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

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

Article: 54067
Subject: Re: Looking for Virtex2Pro and Linux (PPC)
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Wed, 02 Apr 2003 08:04:44 +1000
Links: << >>  << T >>  << A >>
Peter Ryser wrote:
> John, Martin,
> 
> Linux is already ported for Virtex-II Pro including device drivers for our
> most often used peripherals. The Linux distribution is available through
> licenses from MontaVista (http://www.mvista.com) or from the open source
> repository in the linuxppc_2_4_devel tree (http://www.penguinppc.org).
> 
> The same drivers can also be used for any uClinux port for MicroBlaze.

> 
> John, if you don't mind, keep me posted on how the uClinux port goes.

Status is as follows:  I can currently boot a primitive uClinux kernel 
on microblaze.  Memory management, kernel threads and scheduling are all 
there.  The uClibc C libraries are ported and more or less ready to go.

Immediate development objectives are elf2flt and bin_flt loader support 
for userland executables. A bit more tweaking is required to get a root 
filesystem (romfs) up and running.  Once these are done, we can boot a 
kernel properly and launch a shell etc.  This will mark the end of the 
first stage of the port.

There has been some interest from various people around the world on 
this.  I'm looking into starting up a microblaze-uclinux specific 
mailing list, and preparing a set of patches so interested parties can 
get involved.  In the meantime, uclinux-dev@uclinux.org (subscribe via 
www.uclinux.org) is active and I'm posting there on a daily basis.

I'll report back in a couple of days when I have made the arrangements. 
  Keep this frequency clear!

John


Article: 54068
Subject: Re: [Question] FPGA/PLX9054
From: already5chosen@yahoo.com (Michael S)
Date: 1 Apr 2003 14:28:17 -0800
Links: << >>  << T >>  << A >>
Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0304010937.79425738@posting.google.com>...
> already5chosen@yahoo.com (Michael S) wrote in message news:<f881b862.0304010021.1e95769b@posting.google.com>...
> 
> > We use J mode exclusively in all our newer designs. We feel really
> > sorry that we used C mode earlier. For the systems like ours which
> > have nothing, but FPGA, on the PLX local bus, C mode is pure wast of
> > pins with zero advantage.
> > The complete J mode 32bit interface (no support for local bus
> > mastering) requires only 41 pins in the FPGA - LAD[31:0], LBE[3:0],
> > ADS#, BLAST#, LW/R#, READY# and LCLK.
> > DT/R# and DEN# are not necessery. 
> > If you don't need byte/word wide writes, you don't have to connect
> > LBE[3:0].
> > For the demand-mode DMA - connect DREQn#. You can do fine without
> > DACKn#.
> > For the interrupt to host - connect LINT#.
> 
> Now that I've thought about it, "J" mode is probably perfect if you
> are implementing an SDRAM controller in the FPGA.
> 
> It boils down to: "do I need to have the local bus give me an address
> every cycle?"
>  

No. It doesn't boil down to anything. If FPGA[s] is/are the only
slave/sleeve sitting on the local bus, the J mode is superior to the C
mode. Period. During the C mode burst transaction the address bus is
incremented linearly, so it doesn't carry usefull information.

> > + There is a way to configure your FPGA with PCI9080/54/54 signals
> > witout PROM and additional PLDs. Think a little and you would find it
> > yourself. I'm not going to tell you how :)
> 
> ummm, use an ISP CPLD?
> 

Nah. No CPLD. Just PCI9056, FPGA and one pullup resistor...

> Seriously, tho', I guess you would use the FPGA's parallel config
> mode.
> 

No, I don't. Everything works with Passive Serial (speaking in
A-terms).

Article: 54069
Subject: Re: parity checking trick for PCI core
From: marlboro <>
Date: Tue, 1 Apr 2003 14:40:16 -0800
Links: << >>  << T >>  << A >>
Hi, 
You don't have to register the AD and C/BE for parity checker, 
that can save you 1 clk, but beware of timing. How fast you want it gonna be? 




Article: 54070
Subject: Re: DSP-FPGA interface
From: already5chosen@yahoo.com (Michael S)
Date: 1 Apr 2003 14:47:47 -0800
Links: << >>  << T >>  << A >>
"Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it> wrote in message news:<CIIga.54210$7y3.1694665@twister1.libero.it>...
> "Mike Shonle" <mike@psychonic.net> ha scritto nel messaggio
> news:To-dndAX1_vqth6jXTWcrg@speakeasy.net...
> 
> > Why not use one of the TI dsp chips with built-in PWM &
> > encoder reading,
> > like the 320F2407?
> 
> 'f2407 is a fixed point DSP and has something between 100 and 200 MIPS,
> while c67xx family is floating point and some models go beyond 2000
> MFLOPS. They aren't exactly equivalent. ;)
> 

According to TI, the fastest C67 (TMS320C6713-225) has a _peak_
performance of 1350 MFLOPs: (4 FADD + 2 FMUL) * 225MHz.
Sorry for nit picking, I couldn't resist.

Article: 54071
Subject: Re: Spartan vs. Cyclone for arithmetic functions
From: mrand@my-deja.com (Marc Randolph)
Date: 1 Apr 2003 15:08:33 -0800
Links: << >>  << T >>  << A >>
"Paul Leventis \(at home\)" <paul.leventis@utoronto.ca> wrote in message news:<rH8ia.817$Mt1.69@news01.bloor.is.net.cable.rogers.com>...
> Marc,
> 
> If only comparing logic cells were that simple.
> 
> Though Xilinx's data sheet shows 6912 logic cells for XC2S300E, there are
> only physically 6144 logic cells in the part.  Take the CLB array size (32 x
> 48) and multiply it out (x4 LCs per CLB) = 6144.  Or look at the distributed
> RAM -- 98304/16 bits per LC = 6144 LCs.  So this is much closer to the 5980
> logic elements in the 1C6.
> 
> Why is this, you may ask?  It's a creative piece of marketing where Xilinx
> has decided their logic cell is worth 12.5% more than their past or Altera's
> (I forget which) logic cell.  This is due to all the goo that allows various
> functions to be rolled into the LC in addition to a 4-input LUT.
[...]

Hello Paul,

While I agree it is somewhat misleading for them to do this, I doubt
someone would pick a 2S300E over a 1C6 based the LUT count difference
between the two devices, especially if it is an estimated LUT count. 
IOW, I don't think you (Altera) have too much to fear.

If the design is that close to the edge of not fitting, running the
design through the place and route tools (as both you and I have
suggested) is the only way to verify a fit.  I have seen too much
variability in the place and route tools to do anything otherwise.

And THAT is why I was asking the original poster how/why he was
choosing the device he did.

   Marc

Article: 54072
Subject: Re: What would it take?
From: "Jerry" <nospam@nowhere.com>
Date: Tue, 1 Apr 2003 20:03:01 -0500
Links: << >>  << T >>  << A >>
This might be a way to introduce the concept of a partially defective FPGA.
Yes, allow the mapper/place/route
tool set to either test/map around the defective CLB & route segments or
read the bad map from the FPGA then take that
information into account for bit pattern generation. It would work for
prototyping and perhaps for very low quantity
production. If you could read/test and record the defective logic then when
field upgrades are required each unit would
have a unique bit pattern. Not effecient but do able.

Instead of bad mapping individual CLB perhaps the granularity could be
adjusted to say 4 clbs per bad bit. Much the
same way bad sector disk mapping is done. It doesn't tell you which bit is
bad in the sector only that the sector is
bad.

Using this bad logic mapping could be introduced for the 90 nanometer
process and then integrated into the
65 nanometer dies so its transparent to the user.

Jerry

"Robert Finch" <robfinch@sympatico.ca> wrote in message
news:xwbia.1535$DD6.399329@news20.bellglobal.com...
> How about just allowing the design tools to run defect tests on an FPGA ?
> That way nothing in the FPGA would have to change? Does production testing
> check the entire FPGA or does it quit once a defect is detected ? Is there
a
> way to tell how defective the part is ?
> It wouldn't be that useful for production, but for prototyping it might be
> handy.
> It seems a bit of waste to throw out FPGA's when there's only a single bad
> route or LUT, when a lot of the time that resource doesn't even end up
> getting used anyway.
>
> Rob
>
>
>
>



Article: 54073
Subject: Re: XC9572XL Macrocell power
From: "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com>
Date: Wed, 2 Apr 2003 13:19:38 +1200
Links: << >>  << T >>  << A >>
"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message
news:b6d0oe$oi0$1@news.tu-darmstadt.de...
> Ralph Mason <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote:
> : I have done this and the chip viewer shows the output macrocells for the
> : leds as STD power, and all the others as low. Exactly as expected.
>
> : However the leds still don't work (they work if I set the powermode of
the
> : whole device to STD as above) - does it matter that a STD power marco
cell
> : is driven by a low power one?
>
> : Does anyone have any ideas?
>
> The macrocells  are inside the chip. The LEDs are drive by the output.
Show
> us how you drive the LEDS. Only if you clock the LEDS well above perhaps
20
> MHz, the powersetting of the Makrocells will affect the LED drive
> capability.

Thanks for your help, it turns out that the CPLD wouldn't run in low power
mode, until I feed a WR line into a global clock pin.

There was a thread here a while back about feeding an input signal out a
global clock pin and then using the global clock signal - thus letting any
pin be a global clock.

Does anyone have any idea how to get the syntheses to understand that?

Thanks
Ralph



Article: 54074
Subject: Re: What would it take?
From: "Steve Casselman" <sc_nospam@vcc.com>
Date: Wed, 02 Apr 2003 02:19:24 GMT
Links: << >>  << T >>  << A >>
I wrote a little artical for EETimes that proposed having a full wafer of
FPGA fabric that included a purge map for defective resources. You could
have an area on the FPGA die that got laser burned to record the defects.
Once you have a "master" design rerouting around the defects would not be
that hard or take that long. Of course you know of the Xilinx program where
you give them a bitfile and they screen to that. But really someone will do
the work to include a bitmap someday. Like I say it would be great for wafer
sized FPGAs. Imagine a Billion gate device. You could put everything
including the OS on something that size.

Steve

"Jerry" <nospam@nowhere.com> wrote in message
news:v8kdtu3fs25le7@corp.supernews.com...
> This might be a way to introduce the concept of a partially defective
FPGA.
> Yes, allow the mapper/place/route
> tool set to either test/map around the defective CLB & route segments or
> read the bad map from the FPGA then take that
> information into account for bit pattern generation. It would work for
> prototyping and perhaps for very low quantity
> production. If you could read/test and record the defective logic then
when
> field upgrades are required each unit would
> have a unique bit pattern. Not effecient but do able.
>
> Instead of bad mapping individual CLB perhaps the granularity could be
> adjusted to say 4 clbs per bad bit. Much the
> same way bad sector disk mapping is done. It doesn't tell you which bit is
> bad in the sector only that the sector is
> bad.
>
> Using this bad logic mapping could be introduced for the 90 nanometer
> process and then integrated into the
> 65 nanometer dies so its transparent to the user.
>
> Jerry
>
> "Robert Finch" <robfinch@sympatico.ca> wrote in message
> news:xwbia.1535$DD6.399329@news20.bellglobal.com...
> > How about just allowing the design tools to run defect tests on an FPGA
?
> > That way nothing in the FPGA would have to change? Does production
testing
> > check the entire FPGA or does it quit once a defect is detected ? Is
there
> a
> > way to tell how defective the part is ?
> > It wouldn't be that useful for production, but for prototyping it might
be
> > handy.
> > It seems a bit of waste to throw out FPGA's when there's only a single
bad
> > route or LUT, when a lot of the time that resource doesn't even end up
> > getting used anyway.
> >
> > Rob
> >
> >
> >
> >
>
>





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
2019JanFebMar2019

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