1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr 2017

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 20650

Article: 20650
Subject: Request for Info
From: rudy munguia <rmunguia@globalcenter.net>
Date: Wed, 16 Feb 2000 15:55:02 -0700
Links: << >>  << T >>  << A >>
Hello all,

I am new to fpga, have been working w/ mcu such as 68hcxx/AVR/XA, I am
looking at possibly porting over an AI app, but I am unsure as to the
nature of the fpga "beast"

Could any recommend both intro's to and tech source's for fpga's?

--
Rudolfo X. Munguia

There are perhaps 5% of the population that simply *can't* think.
There are another 5% who *can*, and *do*.
The remaining 90% *can* think, but *don't*.
-- R. A. Heinlein

Article: 20651
Subject: Re: Choosing the correct size FPGA
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Wed, 16 Feb 2000 23:00:54 +0000
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
>
> This a non-trivial problem.
> My first approach would be to estimate the number of flip-flops, and then
> slect a part that has twice as many as required. All vendors tell you how
> many flip-flops they have per block ( XC4000 has 2, Virtex and Spartan2
> have 4 ffs per CLB).
> But that can be wrong in either direction. If you have a lot of complex
> combinatorial logic, the estimated chip might be too small. If you can
> "hide" some of what you think as ffs in the RAMs, BlockRAMs or even the
> 16-bit shift registers available in each Virtex LUT, then you can be far
> more compact.
>
> I think you have to invest a bit of time in studying the architectures.
> Hell, there are only two or three contenders. I obiously prefer the "end of
> the alphabet"...
>
Don't forget that multiplexes too take up several CLBs and can have a
rather
large delay.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
The Lagging edge of technology:
http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.html

Article: 20652
Subject: Re: [NEED HELP] Carry Select Adder?
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 16 Feb 2000 23:42:01 GMT
Links: << >>  << T >>  << A >>
rk <stellare@nospam.erols.com> writes:

>Perhaps we should consider tactics that some other newsgroups do and give
>technical sounding answers that people like aboob will hand in without
>bothering to think that are obviously false to anyone who's loosened
>up the spine a bit on their text book.

>rk

Yes, but the adder logic is so well described in
"The Programmable Logic Data Book" which Xilinx will send to anyone
who calls and asks for one.  And maybe even in http://www.xilinx.com/

Probably that is the place he (or she) should look.

-- glen

Article: 20653
Subject: Re: Xilinx hold time problems...
From: bobperl@best_no_spam_thanks.com (Bob Perlman)
Date: Thu, 17 Feb 2000 00:32:16 GMT
Links: << >>  << T >>  << A >>
On Wed, 16 Feb 2000 13:44:04 -0800, Peter Alfke <peter@xilinx.com>
wrote:

>The classical solution to this old problem is to utilize the input flip-flop with
>its input delay, but configured as a latch, and hold it permanently transparent.
>
>Peter Alfke

I tried the latch trick some years ago.  It worked, but one
significant complication was that PPR (this was back in '92-'93) kept
trying to help by optimizing out the always-transparent latch.  I
don't know if M2.1 has the same problem.

If you try this approach, go into FPGA editor after the route and
confirm that the latch(es) didn't disappear.

Finally, thanks to Joseph for posting the issue.  I've been looking
for the simple, automatic solution for a long time.  It's easy to say,
"Always go through the IOB FF," but in practice there are those
situations where the additional latency isn't tolerable.

Good luck,
Bob Perlman

>==============================
>Joseph H Allen wrote:
>
>> The M2.1i software now reports hold times on input pads in the data sheet
>> timing report file, and, of course, I have some significant (up to 2.5 ns)
>> hold times relative to the system clock.
>>
>> This does not happen when using the IOB flip flop, with its delay line.  It
>> does happen when there is small amount of logic between the input and the
>> first flip flop (so that the IOB flip flop can not be used), and when both
>> are placed together in a CLB near the pad.
>>
>> What is the best (easy+automatic) way to eliminate these hold times?  Has
>> anyone else noticed this?
>>
>> --
>> /*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
>> int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
>> +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
>> ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.best.com/~bobperl/cdw.htm
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------

Article: 20654
Subject: Re: Runtime Conditionals?
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Wed, 16 Feb 2000 18:20:04 -0700
Links: << >>  << T >>  << A >>
Gary Spivey wrote in message <88f4i7$r24$1@nnrp03.primenet.com>...
>I just went through the recent discussion in the group about conditional
>compilation, and I need to take it to a different level. I want to have a
>test bench that does:
>procedure ...
>
>if (a) {}
>else {}
>
>end proc ...
>
>where a is a value passed in from the command line.
>In verilog, I can simply pass in a plusarg and then use the $testplusarg >task. Is there a similar function in VHDL to do runtime decisions based on >command line parameters? Gary, Use a generic. Any simulation tool worth the kilobucks they charge will let you change the value of the generic (either with a dialog box or via command-line) when you elaborate. for instance, if you've got a test bench: entity blah_tb is generic (DOTHIS : boolean := TRUE); end entity blah_tb; Then in your architecture: testme : process is begin ... do stuff ... if DOTHIS then ... do some stuff ... else ... do this other stuff end if; ... keep doing stuff ... end process testme; you can also extend this to something like looping - a generic sets the number of loops to do, and you can override that generic. -a -- ----------------------------------------- Andy Peters Sr Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters (at) noao \dot\ edu "Money is property; it is not speech." -- Justice John Paul Stevens  Article: 20655 Subject: Re: Advice please From: Rickman <spamgoeshere4@yahoo.com> Date: Wed, 16 Feb 2000 20:31:51 -0500 Links: << >> << T >> << A >> Dragon wrote: > > I used to do back annotation, but have since found static timing analysis > to be much more efficient with the design flows we experience. Too many > times I've func simmed, targeted, and back annotated only to have the > spec change the next day! Every time you place and route you had to > perform back annotated regression sims. Back annotation was causing > most of my headache and overtime. With static timing you can specify > one set of timing constraints that apply each and every time you reroute. > > The only caveat is that your static timing analysis had damn well better > be right!!! If your analysis is incorrect you can have timing problems > even though your constraints are met. I will usually sit down with one > or two senior engineers and go through it with a fine tooth comb. It's > not a bad way to learn stuff too! > > I've also found that static timing usually requires more up-front time and > effort. I've had some program managers make noise about it while > fingering their Gantt chart. They usually quiet down when we get into > the lab and have a first-time 'go'. ;-) > >$0.02                - Craig

I would agree with what you are saying. I use static timing analysis as
well and have not had a problem with it yet. But it does have the
potential of missing important paths if you don't lay the specs out
carefully enough.

I find that a global clock spec usually covers everything inside the
design. Then the IOs each get an offset spec. This should tightly spec
everything in the design.

But it is often too tight since many paths are really two or more clock
cycles. So then the hard work sets in to identify the slow paths and to
carefully constrain them without relaxing any other paths that need to
be tight.

The worse I have ever had with this method is to overconstrain portions
of a design so that the router had to work harder. If it fails to route,
you can always go back into your constraints and see what you can relax.
But that is better than having timing errors which come and go based on
temperature, humidity and the phase of the moon.

--

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 20656
Subject: Re: Xilinx Virtex Reset
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 16 Feb 2000 20:44:01 -0500
Links: << >>  << T >>  << A >>
Mark Luscombe wrote:
>
> Ray,
>
> Yes, if it doesn't meet 74MHz, then the GSR net is useless for us, but
> it is worth enquiring.
>
> If a non GSR-net reset is used, then this uses routing (i know Xilinx
> say that Virtex has plentiful routing) that could impact timing etc,
> and it uses the SR input of the Virtex CLB meaning that RAM LUTs can't
> exist with DFFs.
>
> I understand your concern about synchronising the Reset signal with a
> CLB DFF (chicken and egg scenario), but there is a technical note by
> Peter Alfke ? which details the construction of a synchronising FF
> with a CLB's LUTs (cross coupled Nand gates).
>
> Cheers, Mark.

I don't think this will work any better than any other approach if your
clock speed is faster than the GSR routing. In fact this may be a bit
slower because of the output delay.

I think you need to consider the GSR input to be a way to put the entire
chip into an known state and use another signal to synchronize the
release of reset. Once the asynchronous GSR input has been released, you
need another signal, which is synchronous, to hold the circuits in the
reset state. This synch reset signal can be routed to just the subset of
circuitry that controls the intial state of FSMs or other sequential
circuits. If you have counters and such, they need to be controlled by
the synch reset signal or another signal from your FSMs.

The point is that if you can't release the GSR across the chip on the
same clock cycle, then design your chip so that the GSR does not need to
be released on the same clock cycle!

--

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 20657
Subject: Re: Xilinx hold time problems...
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 16 Feb 2000 21:01:48 -0500
Links: << >>  << T >>  << A >>
Xanatos wrote:
> 3) Check, using EPIC or the FPGA Editor in 2.1i, that the inputs are not
> going thru the DELAY element. This is turned ON by default in 2.1i, and was
> off in 1.5. Go figure. In the UCF file, put all input pins with the NODELAY
> tag if you havn;t done so already. This one seemed to save the most in the
> timing department for me.
>
> Hope it helps....and if not, sorry, but I tried.
> -Xanatos

I thought that the delay element is used to eliminate the hold time
requirement. The more delay in the data path relative to the clock path
means more setup time and less hold time on the input, no?

--

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 20658
Subject: Re: Choosing the correct size FPGA
From: Ray Andraka <randraka@ids.net>
Date: Thu, 17 Feb 2000 02:31:02 GMT
Links: << >>  << T >>  << A >>
Depends on how you do it, how doesn't it?  :-)

Ben Franchuk wrote:

> Peter Alfke wrote:
> >
> > This a non-trivial problem.
> > My first approach would be to estimate the number of flip-flops, and then
> > slect a part that has twice as many as required. All vendors tell you how
> > many flip-flops they have per block ( XC4000 has 2, Virtex and Spartan2
> > have 4 ffs per CLB).
> > But that can be wrong in either direction. If you have a lot of complex
> > combinatorial logic, the estimated chip might be too small. If you can
> > "hide" some of what you think as ffs in the RAMs, BlockRAMs or even the
> > 16-bit shift registers available in each Virtex LUT, then you can be far
> > more compact.
> >
> > I think you have to invest a bit of time in studying the architectures.
> > Hell, there are only two or three contenders. I obiously prefer the "end of
> > the alphabet"...
> >
> Don't forget that multiplexes too take up several CLBs and can have a
> rather
> large delay.
>
> --
> "We do not inherit our time on this planet from our parents...
>  We borrow it from our children."
> The Lagging edge of technology:
> http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.html

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 20659
Subject: Re: Xilinx hold time problems...
From: bobperl@best_no_spam_thanks.com (Bob Perlman)
Date: Thu, 17 Feb 2000 02:34:53 GMT
Links: << >>  << T >>  << A >>
On Wed, 16 Feb 2000 21:01:48 -0500, Rickman <spamgoeshere4@yahoo.com>
wrote:

>Xanatos wrote:
>> 3) Check, using EPIC or the FPGA Editor in 2.1i, that the inputs are not
>> going thru the DELAY element. This is turned ON by default in 2.1i, and was
>> off in 1.5. Go figure. In the UCF file, put all input pins with the NODELAY
>> tag if you havn;t done so already. This one seemed to save the most in the
>> timing department for me.
>>
>> Hope it helps....and if not, sorry, but I tried.
>> -Xanatos
>
>I thought that the delay element is used to eliminate the hold time
>requirement. The more delay in the data path relative to the clock path
>means more setup time and less hold time on the input, no?

Yes, you want more delay, not less, to reduce hold time.

By the way, this discussion pointed out something that I hadn't
realized before.  In the 4K and Spartan families, an input signal
going directly from the pin to the chip core does not pass through the
programmable delay element; in Virtex families (Virtex, VirtexE, and
Spartan 2) it does pass through it.  So--at least in theory--you could
insert the delay and reduce the hold time, provided you're designing
something in a Virtex architecture.  If you're not, see Peter Alfke's
through-the-always-transparent-latch suggestion.

Bob Perlman

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.best.com/~bobperl/cdw.htm
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------

Article: 20660
Subject: Re: Request for Info
From: Ray Andraka <randraka@ids.net>
Date: Thu, 17 Feb 2000 02:53:08 GMT
Links: << >>  << T >>  << A >>
To start off with, an FPGA is nothing like a microprocessor.  Nope, not in
the least bit.  About all they have in common is they are made of purified
sand, and get a little warm when you put power on the right pins (and
really hot when you put power on the wrong pins).  So what is this FPGA
thingy you've been hearing all this good stuff about then, you ask
yourself.

Well, an FPGA is, in simple terms, a big bucket of logic gates that the
user needs to figure out how to wire up to make a circuit that does what
he wants.   The chip itself has a large number of logic blocks (anywhere
from 64 to well over 10000), each of which can take on one of a small set
of boolean functions.  These are typically four input, one output
arbitrary function gates implemented as small look-up tables.  The tables
outputs typically can be wired to a flip-flop or directly out of that
logic cell.  The logic cells are then connected to a huge matrix of wire
segments interconnected by switches.  The FPGA 'program' is a long binary
word that sets the function of each logic cell and the condition of every
switch in the array.  Obviously, we wouldn't get very far if we had to
directly set each bit.  Instead we use special compilers that take a
circuit design expressed as either a schematic or in a textual hardware
description language (HDL) as input and produce the bitstream as the final
output.

In any event, designing for FPGAs is basically digital logic circuit
design with several significant constraints due to the limited structure
of the device.  Obviously then, a skill set that includes digital logic
design is needed to 'program' the FPGA.  I put program in quotes because I
think it is a bad name for the process of designing an FPGA circuit.  For
algorithmic applications, which I suspect you are probably interested in
based on your background, you'll get alot farther if you also have a
background in computer (hardware) arithmetic so that you understand how to
map algorithms into hardware. (There are plenty of people out there who
don't but think they do).  Without some inkling of good digital logic
design practices, you are not likely to have much success in doing FPGA
designs. If you don't have the background, I would encourage you to take a
digital course or two at your favorite university, and then pick up one of
the many 'student kits' containing an FPGA evaluation board and design
software.  Even if you have a digital design background but are unfamiliar
with fPGAs, I would encourage buying such a kit and playing with it to get
a flavor of what it is all about.

rudy munguia wrote:

> Hello all,
>
> I am new to fpga, have been working w/ mcu such as 68hcxx/AVR/XA, I am
> looking at possibly porting over an AI app, but I am unsure as to the
> nature of the fpga "beast"
>
> Could any recommend both intro's to and tech source's for fpga's?
>
> --
> Rudolfo X. Munguia
>
> There are perhaps 5% of the population that simply *can't* think.
> There are another 5% who *can*, and *do*.
> The remaining 90% *can* think, but *don't*.
> -- R. A. Heinlein

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 20661
Subject: Re: launching a FPGA cores start-up
From: Ray Andraka <randraka@ids.net>
Date: Thu, 17 Feb 2000 03:02:12 GMT
Links: << >>  << T >>  << A >>
Depends on the experience, skill level, location and type of designs.  A senior
engineer with a couple successful FPGAs under his belt might cost $60-100/hr _fully burdened_. A seasoned expert gets a bit more. Rickman wrote: > Ray, > > Can you give us some ball park numbers for rates for FPGA designers and > for ASIC designers? > > Ray Andraka wrote: > > > > fpgaer@my-deja.com wrote: > > > > > Ray, > > > > > > what's the market like for custom FPGA designs (ie; consultancy ) ? > > > > Right now there is plenty of opportunity for experienced FPGA designers, > > although customers are not willing to pay anywhere near what they are > > willing to pay for equivalent ASIC designs or experience. > > > > > > > > > > > In article <38A80ABE.33E78BB5@ids.net>, > > > Ray Andraka <randraka@ids.net> wrote: > > > > My point is that there seems to be very little money in doing > > > commercial > > > > cores for FPGAs. The silicon vendors have set the price point > > > expectations > > > > so low (free in many cases) that I suspect you will find little if any > > > > return on your investment especially after you factor in the cost of > > > > marketing and support. > > > > > > > > fpgaer@my-deja.com wrote: > > > > > > > > > Ray, > > > > > > > > > > Thanks for your comments. > > > > > > > > > > I know that the FPGA core market is limited and is dominated by big > > > > > vendors. But would I be right in saying that this market is growing, > > > > > as the gate/price ratio is increasing (slowly) and with their > > > > > reconfigurable nature & the time-to-market FPGAs win over ASICs ? > > > > > To add to it the 'fabrication-from-foundary' cost factor attached to > > > > > ASICs disappears in FPGAs so that individuals can think of designing > > > > > complete working systems (an impossible taks when concidering > > > ASICs). > > > > > I see scenarios where ONLY FPGA's qualify in terms their > > > reconfigurable > > > > > nature - which are increasing by the day ! > > > > > > > > > > Taking all the pros & cons and reasoning from the above points ( I'm > > > > > still not sure if they're right ! ), would it be a wise decision to > > > > > concentrate on the business ??? > > > > > > > > > > In article <38A6E467.E85DCE58@ids.net>, > > > > > Ray Andraka <randraka@ids.net> wrote: > > > > > > Good luck. From what I've seen, people are not willing to pay > > > much > > > > > for > > > > > > FPGA based cores. Seems the silicon vendors have set the price > > > > > > expectations for cores well below the cost to develop, maintain > > > and > > > > > > support such cores. Optimized FPGA cores are more difficult to > > > design > > > > > > than comparable cores in ASICs, yet the market price for FPGA > > > cores is > > > > > > orders of magnitude less than similar ASIC cores. > > > > > > > > > > > > fpgaer@my-deja.com wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > wld. appreciate if anyone cld. share their views on launching a > > > co. > > > > > > > which delivers custom-made FPGA cores ? Wld. the effort be worth > > > in > > > > > > > terms of time ( & money ) ...... specifically, is there a > > > demanding > > > > > > > market for FPGA cores ??? > > > > > > > > > > > > > > Any comments wld. be highly appreciated !!! > > > > > > > > > > > > > > Thanks in advance........ > > > > > > > > > > > > > > Sent via Deja.com http://www.deja.com/ > > > > > > > Before you buy. > > > > > > > > > > > > -- > > > > > > -Ray Andraka, P.E. > > > > > > President, the Andraka Consulting Group, Inc. > > > > > > 401/884-7930 Fax 401/884-7950 > > > > > > email randraka@ids.net > > > > > > http://users.ids.net/~randraka > > > > > > > > > > > > > > > > > > > > > > Sent via Deja.com http://www.deja.com/ > > > > > Before you buy. > > > > > > > > -- > > > > -Ray Andraka, P.E. > > > > President, the Andraka Consulting Group, Inc. > > > > 401/884-7930 Fax 401/884-7950 > > > > email randraka@ids.net > > > > http://users.ids.net/~randraka > > > > > > > > > > > > > > Sent via Deja.com http://www.deja.com/ > > > Before you buy. > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email randraka@ids.net > > http://users.ids.net/~randraka > > -- > > Rick Collins > > rick.collins@XYarius.com > > remove the XY to email me. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.com -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka  Article: 20662 Subject: Re: Lattice isp programming problems From: kapp_harald@my-deja.com Date: Thu, 17 Feb 2000 08:46:11 GMT Links: << >> << T >> << A >> In article <38a1252a$1@pull.gecm.com>,
"Andrew Dow" <andrew.dow@gecm.com> wrote:
> As anyone had any problems with in system programming of Lattice
devices or
> have any suggestion to the following problem.
>
> I've started working on piece of hardware that hasn't been programmed
during
> the time I've been working on it. It decided I wanted to read the
contents
> out of the EPLD's I was working on and had got to the stage of putting
the
> download cable into the board and turning on the hardware. The power
supply
> immediately cut out and once the cable had been removed the system
stopped
> working.
>
> I think the ispEN line has been damaged as it is sitting below 1V and
> comparing to other boards in the system it should be at 3.5V approx.
>
> I have been trying to work out how this could happen, as I do not want
to
> replace the chip for the whole thing to happen again.  I have the
ground
> differences  and they seem OK.
>
> Any suggestions?
>
> Andrew Dow
>
>
Andrew,
I have no explanation for your problem, never had that one myself.
However, Lattice recommends to place not only a pull-up resistor
(approx. 1kOhm) from ispEN to Vcc but also a small cap (10nF) from ispEN
to GND.
An don't forget the external MUX when using the isp-pins as inputs in

Harald Kapp

Sent via Deja.com http://www.deja.com/

Article: 20663
Subject: Re: Logiblox and virtex
From: Steven Derrien <sderrien@irisa.fr>
Date: Thu, 17 Feb 2000 09:50:27 +0100
Links: << >>  << T >>  << A >>


Federico Silla wrote:

> Hi everybody,
>
> I am trying to get started with the fpga design on a Virtex. Up to now, I
> have designed my circuits with the Xilinx 4000 family, using logiblox when
> needed. However, when I have moved to Virtex, I have realized that the
> software tool Foundation (verion 2.1i) does not allow to design logiblox for
> virtex. Does anybody know where have logiblox gone? Does anyone know how to
> use some other design tool instead of logiblox?
>

You should use the CoreGen tool instead, which does almost the same, and which
is included in the foundation tools.

Steven


Article: 20664
Subject: Re: Spartan-II Pricing - What gives?
From: Steven Derrien <sderrien@irisa.fr>
Date: Thu, 17 Feb 2000 09:55:12 +0100
Links: << >>  << T >>  << A >>


Andy Krumel wrote:

> Hi all,
>
> My company is working on a networking product that uses an FPGA for
> performing some analysis of Ethernet packets. The algorithms require quick
> access to some RAM based tables and dual port on-chip block Ram structures
> fit the bill perfectly. The final product is for a price sensitive market so
> Xilinx's Spartan-II line looks perfect, but...
>
> I called a distributor to get pricing for 50,000 XC2S100 Spartan-II chips
> and received a quote of $58.65 (down from a single chip at$77). Yet
> Xilinx's literature claims this chip to cost under $10 in volume. these prices are for volume of 250000 units and are actually only a estimation for the expected price at the end of year 2000. > What constitutes "volume" to get this kind of price? > Is there an FPGA with 30-40K dual port RAM blocks that costs <=$10 in
> volumes of 50,000?

You might want to look at older Spartan families, but i'm not sure they'll match

> Quote from http://www.xilinx.com/products/spartan2/index.htm:
>
> "Say hello to a new level of performance. The Spartan-II family delivers
> 100,000 system gates for under $10, at speeds of 200 MHz and beyond, > giving you design flexibility that's hard to beat." > > Also, I looked and looked and could not find any disclaimers or volume > quotes for these prices. It written in 0.0005 font size somewhere on the advertising. > There are plenty of flashing GIFs proclaiming this > price though. Steven  Article: 20665 Subject: Re: Logiblox and virtex From: P Little <little_pete@hotmail.com> Date: Thu, 17 Feb 2000 09:04:03 +0000 Links: << >> << T >> << A >> Use the Xilinx COREGen tool to generate macros for VIRTEX. Federico Silla wrote: > > Hi everybody, > > I am trying to get started with the fpga design on a Virtex. Up to now, I > have designed my circuits with the Xilinx 4000 family, using logiblox when > needed. However, when I have moved to Virtex, I have realized that the > software tool Foundation (verion 2.1i) does not allow to design logiblox for > virtex. Does anybody know where have logiblox gone? Does anyone know how to > use some other design tool instead of logiblox? > > Thanks in advance > > Federico Silla  Article: 20666 Subject: CLAy 31 datasheet From: Riad BOURGUIBA <bourguiba@ensea.fr> Date: Thu, 17 Feb 2000 10:58:13 +0100 Links: << >> << T >> << A >> Hello, I am looking for the CLAy 31 datasheet. This is an old dynamically configurable FPGA from National Semiconductor. I was unable to find it on the net. Does anyone have it? Could you send it to me please. Thanks Riad  Article: 20667 Subject: Re: 100% slice utilization in Virtex FPGA From: gazit@my-deja.com Date: Thu, 17 Feb 2000 12:31:10 GMT Links: << >> << T >> << A >> As we all know, the utilization you get depends strongly on the coding style and the architecture you use. If you are prototyping an ASIC the coding style and architecture you will approach will not be FPGA optimized and the ratio you should expect is ~1/5. It is undoubted that you can rewrite the the ASIC code and achieve better density, but when your ASIC size is > 2000K gates you have so many partition problems that you will not even consider touching the HDL (and than verifyng your changes) as an option :-) . ----------------------------------------------- Rotem Gazit mailto:rotemg@mysticom.com MystiCom LTD. http://www.mysticom.com ----------------------------------------------- In article <38AAD59E.11AA8C1F@algor.co.uk>, Rick Filipkiewicz <rick@algor.co.uk> wrote: > > > gazit@my-deja.com wrote: > > > Matt, > > try to use "map -c 1 ..........." it will improve your device > > utilization. > > My experience shows that the ratio between the real gate count and > > Xilinx numbers is ~1/5 ( 60K ASIC system gates into a "xcv300" device > > sounds reasonable ratio). > > If your design is going to be changed you should consider immigrating > > to a larger device. I believe you can use the same foot print. > > Good luck. > > I think the 1/5 ration is a little pessimitic esp. if there's a fair > amount of memory involved. We recently did an ASIC prototype in a Xilinx > XCV300. The FPGA usage was 89% of LUTs, 55% of CLB FFs, 14 out out 16 > Block RAMs [each of these only 30-50% used]. The final ASIC gate count was > about 210K pre scan insertion. With scan & boundary scan it went up to > about 240K. The ASIC partition between logic & memory was about 55/45. > > However I would agree with using a bigger FPGA. The XCV300-4 was all we > could get back last April and it was really not big enough to allow fast > P&R and to get decent timing took a lot of work. The best we could get we > could get with a (nearly) pure HDL design & no Floorplanning [F1.5i > floorplanner didn't support Virtex] was 66MHz. The ASIC signed off @ > 91MHz. > > Sent via Deja.com http://www.deja.com/ Before you buy.  Article: 20668 Subject: Re: Simple (?) Question about FPGA Test/Demo Boards.... From: gazit@my-deja.com Date: Thu, 17 Feb 2000 12:52:52 GMT Links: << >> << T >> << A >> Here: http://www.optimagic.com/boards.html you will find plenty of links to programmable logic boards . See for your self what "basic/general things" they are offering. ----------------------------------------------- Rotem Gazit mailto:rotemg@mysticom.com MystiCom LTD. http://www.mysticom.com ----------------------------------------------- In article <ChDq4.37277$ri.891987@news20.bellglobal.com>,
"Xanatos" <deletemeaoe_londonfog@hotmail.com> wrote:
> Hey all,
>
> As we are approaching the end of a few projects, we have a need to
make a

> few demo boards for our FPGA's. We want to have two - a Virtex board
for one
> design, and an Altera APEX board for another. I have never done a
demo board
> before, and while I am not responsible for it, it would heighten my
learning
> to find out a little more about them.
>
> My question - What are some of the basic/general things that you
include on
> the demo board. For instance, we plan on having a PCI interface on
the APEX
> board....granted, that is specific to what we want, but a
general "Well,
> when I start a demo board, the first things I make sure I have on the
board
> are: " is what I am asking.
>
> Thanks - please post or email (remove the spam block to email)
>
> -Xanatos
>
>

Sent via Deja.com http://www.deja.com/

Article: 20669
Subject: Re: How to manage projects with Xilinx?
From: jlamorie@engsoc.carleton.ca
Date: Thu, 17 Feb 2000 13:42:00 GMT
Links: << >>  << T >>  << A >>
In article <38AAEE78.9B969870@xess.com>,
Dave Vanden Bout <devb@xess.com> wrote:
> You can take a look at http://www.xess.com/fndmake.pdf.  This document
> shows you how to implement Xilinx projects using a makefile and batch
> mode processing.  You can store the makefiles and VHDL files in a CVS
> tree and recall them to regenerate your project bit files.
>
> The makefile described in the document is a bit simple, but you can
> probably modify it to make it smarter.

This is absolutely wonderful!!  I'll try it out today, and try to figure
out how to include the source files for FSM, schematics and logiblox.

Thanks again.

Joshua Lamorie
Systems Designer

Sent via Deja.com http://www.deja.com/

Article: 20670
Subject: Suggested prototyping boards < $200 From: "Matt Billenstein" <mbillens@one.net> Date: Thu, 17 Feb 2000 13:58:41 GMT Links: << >> << T >> << A >> All, I'm interested in purchasing a prototyping board based on a Xilinx FPGA and I have about$200 to spend.  I've looked a little at the boards at
www.xess.com so far.  Does anyone have any recommendations?

m

Matt Billenstein
REMOVEhttp://w3.one.net/~mbillens/
REMOVEmbillens@one.net


Article: 20671
Subject: Re: CLAy 31 datasheet
From: Ray Andraka <randraka@ids.net>
Date: Thu, 17 Feb 2000 15:13:44 GMT
Links: << >>  << T >>  << A >>
I used to have these in paper form, but have since discarded them.  The
device architecture, and to some extent even the timing is very close to
that of an Atmel AT6005-4.  If the purpose of your search is for a report,
just use the Atmel data sheets.  There are some subtle differences, most
notably in the connections of the 'express' routes to the cells.

> Hello,
>
> I am looking for the CLAy 31 datasheet. This is an old dynamically
> configurable FPGA from National Semiconductor. I was unable to find it
> on the net. Does anyone have it? Could you send it to me please.
>
> Thanks
>

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 20672
Subject: Re: multiplier
From: "Keith Jasinski, Jr." <jasinski@mortara.com>
Date: Thu, 17 Feb 2000 09:58:42 -0600
Links: << >>  << T >>  << A >>
The new FPGAs that have RAM that can be configured/initialized like a ROM
are touting the ability to use the RAM as a single clock cycle multiplier by
using it as a look-up table.  Maybe that might be your answer.

--
Keith F. Jasinski, Jr.
kfjasins@execpc.com
news:88fc5e$b84$1@news.vsnl.net.in...
> Hi,
>
> Which would be the best implimentation of a multiplier in VHDL
> (synthesisable) in terms of speed/area?
> I know of array implimentation and the ragister configuration using a
single
> adder. Are there any other better ones ?
> Thanks in anticipation,
>
>
>
>
>


Article: 20673
Subject: Re: Spartan-II Pricing - What gives?
From: "Keith Jasinski, Jr." <jasinski@mortara.com>
Date: Thu, 17 Feb 2000 10:01:53 -0600
Links: << >>  << T >>  << A >>
The "fine-print" I've seen states that those are 250K pricing at about the
end of this year, in the cheapest package and slowest speed grade.  If you
are really looking at 50K/year, I suggest you call your manufacturers rep
and work with him/her directly to setup what you need.  He can work with
your preferred distributor to work out the details.

--
Keith F. Jasinski, Jr.
kfjasins@execpc.com
Andy Krumel <andy@krumel.com> wrote in message
news:salqu8jo2pd94@corp.supernews.com...
> Hi all,
>
> My company is working on a networking product that uses an FPGA for
> performing some analysis of Ethernet packets. The algorithms require quick
> access to some RAM based tables and dual port on-chip block Ram structures
> fit the bill perfectly. The final product is for a price sensitive market
so
> Xilinx's Spartan-II line looks perfect, but...
>
> I called a distributor to get pricing for 50,000 XC2S100 Spartan-II chips
> and received a quote of $58.65 (down from a single chip at$77). Yet
> Xilinx's literature claims this chip to cost under $10 in volume. > > What constitutes "volume" to get this kind of price? > Is there an FPGA with 30-40K dual port RAM blocks that costs <=$10 in
> volumes of 50,000?
>
> Quote from http://www.xilinx.com/products/spartan2/index.htm:
>
> "Say hello to a new level of performance. The Spartan-II family delivers
> 100,000 system gates for under \$10, at speeds of 200 MHz and beyond,
> giving you design flexibility that's hard to beat."
>
> Also, I looked and looked and could not find any disclaimers or volume
> quotes for these prices. There are plenty of flashing GIFs proclaiming
this
> price though.
>
> Thanks,
> Andy
>
>
>


Article: 20674
Subject: Re: Xilinx hold time problems...
From: jhallen@world.std.com (Joseph H Allen)
Date: Thu, 17 Feb 2000 16:23:22 GMT
Links: << >>  << T >>  << A >>
In article <38ab3f43.13235782@nntp.best.com>,
Bob Perlman <bobperl@best_no_spam_thanks.com> wrote:
>On Wed, 16 Feb 2000 13:44:04 -0800, Peter Alfke <peter@xilinx.com>
>wrote:

>>The classical solution to this old problem is to utilize the input flip-flop with
>>its input delay, but configured as a latch, and hold it permanently transparent.

>>Peter Alfke

>I tried the latch trick some years ago.  It worked, but one
>significant complication was that PPR (this was back in '92-'93) kept
>trying to help by optimizing out the always-transparent latch.  I
>don't know if M2.1 has the same problem.

Acutally it's map which is doing it.  It has the same problem in M2.1, no
matter how many KEEP and NOREDUCE attributes you add to the input or gate
(however I was able to get leonardo verilog synthesizer to keep it with the
'dont_touch' attribute: //exemplar attribute delay dont_touch true).

Then I realized that you can just attach the latch gate to the clock for the
same effect, which is by far the easiest solution:

ild_1 delay(.Q(original_input), .D(new_input), .G(clk));

always @(clk)
begin
... state machine which uses original_input ...
end
--
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}