Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 42225

Article: 42225
Subject: Re: 1000 I/O Pins -- What is cheapest FPGA?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 18 Apr 2002 19:38:44 +0200
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter.alfke@xilinx.com> schrieb im Newsbeitrag
news:3CBEF902.77945FC@xilinx.com...

> Yes, the XC2V6000 is in production, and it has 1,104 user I/O pins in the
FF1517
> package.  The small-quantity price is several thousand dollars. You can
find it
> listed at the distributors web sites. ( insight-electronics.com,
avnet.com,
> nuhorizons.com,)

Question is, does he really need the pins AND logic, or just the pins. Maybe
its a good idea to have some low cost, low capacity FPGAs to handle the IOS,
bundle the data stream, and process it in a not so big FPGA.

--
MfG
Falk





Article: 42226
Subject: Addressing Error Ram on Virtex E.
From: 13378988@qub.ac.uk (almost_a_gnome)
Date: 18 Apr 2002 11:01:02 -0700
Links: << >>  << T >>  << A >>
I am using xilinx foundation series software,

In simulations,

I have found that if you try and address a memory location higher than
1023 on the rams on the virtex e there is an error.

i.e every time you set the 10 or 11 address lines to 1, on any of the
12 bit addressable RAM's (B4RAM_S1 etc).

Please could someone tell me if this is a software problem and how i
can fix it so i can use the full 12 address lines on the RAM's rather
than just the first 10.

Article: 42227
(removed)


Article: 42228
Subject: Re: just bought Cohen's book...Real Chip Design and Verification using Verilog and VHDL
From: Mike Treseler <tres@tc.fluke.com>
Date: Thu, 18 Apr 2002 11:25:28 -0700
Links: << >>  << T >>  << A >>
Martin E. wrote:


  > What is it with HDL programmers?  Is there a fobia for commenting code?  I
  > mean, huge app notes for things like synthesizable DDR RAM code and
  > virtually not a single comment to be found!


Designers writing production code are more
motivated to document design intent than ap note writers are.
A historical aspect is that programmable devices used
to be much smaller and the default HDL writer used to be a pcb designer
in a big hurry. As more engineers become full time
coders, I expect that quality will improve.


  > A hands-on, practical, "this is how you do this" book would be of value to
  > beginners and advanced HDL programmers alike.  I'd pay $150 for a book like
  > that.


There is an economic problem in writing books for a niche market.
It takes a year of full time work and the publisher would only sell
only a few thousand copies. The author might get $10 a book.


   -- Mike Treseler




Article: 42229
Subject: Re: 1000 I/O Pins -- What is cheapest FPGA?
From: kayrock66@yahoo.com (Jay)
Date: 18 Apr 2002 11:34:44 -0700
Links: << >>  << T >>  << A >>
So you're talking basically about an XC2V6000.  We've been paying
several thousand dollars each for these.

What speed are we talking about anyway?  

Regards

"Sum" <anonymous@nospam.invalid> wrote in message news:<a9mink$arv$1@wanadoo.fr>...
> "Steffen Thieringer" <steffen.thieringer@nmb.co.uk> a écrit dans le message
> news: a9mf36$4g6ga$1@ID-41871.news.dfncis.de...
> >
> > "UK Gary" <deton8@aol.com> schrieb im Newsbeitrag
> > news:a9m9g1$28d$1@helle.btinternet.com...
> > > I need to design something where the FPGA must have about 1000 I/O pins.
> > > What is my cheapest option?  The design must fit into a single FPGA, but
> > > apart from that and the pin count I don't have any special requirements.
> >
> > Upcoming Altera Stratix devices do have more than 1000 I/O (up to 1310)!
> >
> > http://www.altera.com/products/devices/stratix/overview/stx-overview.html
> 
> Xilinx Virtex-II have more than 1000 I/O (up to 1108) and they are not
> upcoming !
> http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Platform+FPGAs

Article: 42230
Subject: Re: fpga limitation
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Thu, 18 Apr 2002 20:45:59 +0200
Links: << >>  << T >>  << A >>
Correct me if I am wrong, but I think its up to you
to constraint the pins with respect to the simultanous
switching rule.

-Manfred Kraus



Article: 42231
Subject: Re: 8051 Core for Motor Electronics
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 19 Apr 2002 07:54:20 +1200
Links: << >>  << T >>  << A >>
Steffen Thieringer wrote:
> 
> "Russell" <rjshaw@iprimus.com.au> wrote
> 
> > How about just using a smaller fpga as a dedicated pwm/timer peripheral
> > for a cpu. Better still, a motor control dsp.
> 
> sure, a motor control dsp solution is better, but not done in 10 minutes.
> i need a driver now, and for the changeover (8051-hardware to dsp-hardware)
> i want to go for the 8051 software.
> 
> the way to go for a speeded up 8051 ip-core is for using a program which has
> done the job very well on 8051 hardware, but became obsolete because of
> speed.

First check out the fast 80C51s :

www.Cygnal.com - Single clock, 25 MIPS, Mixed signal/PWM/ADC
Dallas Semi    - Single Clock, 50 MIPS
Sharp          - Mentor M8051 core, 2 clocks, 24 MIPS, Mixed signal,
smart PWM (new) 

A FPGA will struggle to deliver a CPU core + Code memory that competes
with
available 80C51, and will find Voltage references, and ADC's very
difficult.

FPGA will do PWM and Timers easily, but is typically a 3 chip solution :
FPGA + Loader + ExternalCode Memory.

Mentor offer a soft-core 8051, that Sharp use in their device.

Seems a better tack would be Fast C51 + CPLD/FPGA PWM logic, or if it's
a complex inner control loop, move that small but critical SW function
into
FPGA HW.

eg Sharp have a interesting idea, of a dual port scanning memory for
their DACs,
targeting motor control.

- jg

-- 
======= 80x51 Tools & IP Specialists  =========
= http://www.DesignTools.co.nz

Article: 42232
Subject: XCV812E-6BG560C - Virtex - E !!!!!!!!!
From: "Jeff Wallace" <jeff@ptsolutionsinc.com>
Date: Thu, 18 Apr 2002 19:57:06 +0000 (UTC)
Links: << >>  << T >>  << A >>
If you use this device, could someone please contact me immediately! We
have 210pcs in stock that we can no longer use. They are factory sealed,
factory original, new parts. Avnet, Insight, NuHorizons, Digi-Key, etc.
sell these for $1,100.00+ EACH (!!) I will let whoever needs them have
the parts @ $580.00 per chip. We paid $1,160.00, and are willing to take
a 50% hit in order to re-claim some of our money for other projects.
Please call me Toll-Free @ 888-690-8899 x40. Thanks!!


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

Article: 42233
Subject: Re: 1000 I/O Pins -- What is cheapest FPGA?
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Thu, 18 Apr 2002 20:18:19 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <a9m9g1$28d$1@helle.btinternet.com>, UK Gary <deton8@aol.com> wrote:
>I need to design something where the FPGA must have about 1000 I/O pins.
>What is my cheapest option?  The design must fit into a single FPGA, but
>apart from that and the pin count I don't have any special requirements.

Why?  Could you possibly split the design into 2 or 4 parts, with some
of the parts using high speed dedicated IOs to interconnect them?
Harder design, but it may be MUCH cheaper.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 42234
Subject: Re: problem installing xilinx foundation 3.1 on a P4
From: Hari Devanath <harid@xilinx.com>
Date: Thu, 18 Apr 2002 14:20:31 -0600
Links: << >>  << T >>  << A >>



Vaggelis,
This is a known issues too: Follow this answer:
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10717

Cheers,
Hari.







Article: 42235
Subject: Re: 1000 I/O Pins -- What is cheapest FPGA?
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Thu, 18 Apr 2002 21:20:48 +0100
Links: << >>  << T >>  << A >>
Jay wrote:

> So you're talking basically about an XC2V6000.  We've been paying
> several thousand dollars each for these.

Somewhere around $2000?  Is anyone using these in volume?

Does anyone have a projection on when these parts go below
$1000 (in hundreds, not thousands)?  How about $500?




Article: 42236
Subject: Re: fpga limitation
From: kayrock66@yahoo.com (Jay)
Date: 18 Apr 2002 13:34:10 -0700
Links: << >>  << T >>  << A >>
There is a also an equivalent limitation for simultanious switching
outputs in ASIC's as well.  Basically you can't try to dump a ton of
current out one side of the chip (ASIC or FPGA) all at once because
the supply pin inductance is too high to do so without significant
voltage droop.  Its usually not as big an issue in FPGA's because they
generally operate at low frequencies (and thus lower required edge
rates) compared to the ASIC cousins.  So do the tools automatically
handle this?  The answer is no, but it most cases your FPGA emulation
of your ASIC will be a in a completely different package anyway.

Ways to help SSO (simulatanious switching outputs)
1) Use the slowest edge rate you can get away with
2) Use the lowest current driver you can get away with
3) Don't use flops in the output cells they tend to synchronize (by
design) the output changes.

Regards

Sujatha Sriram <sujathasriram@yahoo.com> wrote in message news:<3CBE8A79.FB53A92C@yahoo.com>...
> I have read that there is a limitation to the number of adjacent output
> drivers that can switch at the same time in an FPGA. There are rules
> stated in terms of SSO(simultaneous switching outputs) pads between
> power/gnd pins. Can anyone please elaborate on that..
>  In such a case, consider a RTL written for ASIC, and say it has to be
> prototyped. Tools are used to partition the design into multiple FPGA's.
> How is this condition taken care of by the tool. Does it place the
> interface signals taking the limitation into account? or does the
> designer have to take care of it manually..
> 
> 
> >

Article: 42237
Subject: Re: 1000 I/O Pins -- What is cheapest FPGA?
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Thu, 18 Apr 2002 20:45:52 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <1019161867.29969.0.nnrp-13.9e9832fa@news.demon.co.uk>,
Tim <tim@rockylogic.com.nooospam.com> wrote:
>Jay wrote:
>
>> So you're talking basically about an XC2V6000.  We've been paying
>> several thousand dollars each for these.
>
>Somewhere around $2000?  Is anyone using these in volume?
>
>Does anyone have a projection on when these parts go below
>$1000 (in hundreds, not thousands)?  How about $500?

Probably never, those things are BIG.  

According to what I've heard, if xilinx can yield 3/wafer, they have
customers who'd buy them.  Which, by delidding the largest chip, gives
you an idea of the defect density of the process they are using.  

At a few thousand $$$/wafer for just manufacturing, I doubt you will
ever get the parts to drop THAT much in price, even in large volume.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu


Article: 42238
Subject: Re: 1000 I/O Pins -- What is cheapest FPGA?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 18 Apr 2002 13:57:02 -0700
Links: << >>  << T >>  << A >>



Nicholas,

Don't forget about the EasyPath program:  up to 70% off for a part that does
exactly what you want it to do.

For details:

 http://www.xilinx.com/prs_rls/silicon_vir/0248easypath.html

As for commenting on yield, that is considered Proprietary and Confidential.

I will say that in 12" fab, in a few months, the yield will be much improved
(from whatever it is today - 'good' or 'bad' - do not assume anything, as it
is nothing but idle speculation, or unfounded rumors from disgruntled
competitors).

Intel already announced that fab in 12" resulted in better gross margins.  No
secret here.

That is why it is always a safe bet to wager that the present technology will
be the least expensive in time.

Otherwise, why would we be so hell-bent on shrinking geometries?

Check out the finanical news for Xilinx for last quarter:  that will give some
insight into the comments above.

Austin




Article: 42239
Subject: Re: FPGA Timing Problem
From: kayrock66@yahoo.com (Jay)
Date: 18 Apr 2002 14:06:16 -0700
Links: << >>  << T >>  << A >>
I've noticed the same thing over the years also.  I'm thinking that
maybe the lower paying jobs like tech jobs require 2 incomes to
support a household with children.  The kids have to be at school
early anyway, so they just go from dropping kids at school to work. 
I've had similar frustrations with needing tech support late in the
afternoon and everybody has just taken off (gotta get my kids!).  My
solution- learn to work the tools yourself, if they can be trained to
do it, you can too.

And to answer the timing problem question: sounds like you've got an
asynchrounous timing situtation with at least 3 different domains. 
FPGA tools don't like this, they want it nice simple single clock
design.  Many static timing checks won't even try to check between
domains.  Make sure you're interfaces between domains are bullet
proof, so that regardless of phase, no setup-hold violations will
happen.  Think about a DataReady/Acknowledge protocol. The issue of
having different behaviour for each P&R kind of points in the
direction of relying on some timing that is not guaranteed.  You never
want to have a design that you can't turn at will.  If seen this too
many times to mention "Don't rebuild the FPGA, last time it took 10
trys to get it to work!"

Regards



John  Larkin <jjlarkin@highlandSNIPTHIStechnology.com> wrote in message news:<Xt68PBLDZOsrEop6+udYs5ye81GL@4ax.com>...
> Why is it that all the production people like to get to work real
> early and then leave early, while the engineers arrive late and work
> late, so that when you really need a big chip replaced there's nobody
> around to do it for you?
> 
> John

Article: 42240
Subject: Re: fpga limitation
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 18 Apr 2002 14:08:09 -0700
Links: << >>  << T >>  << A >>



Jay,

I disagree with 3, below, as we take this into account when we design our IOBs.

The SSO guidelines in the datasheets takes into account both AC and DC currents (ie for DCI), so
that it makes design easier.

It is a manual operation, however.

The guideline does assume near perfect bypassing.  By that I mean that if you can not bypass every
power ground pin pair with a cap, then the guideline must be reduced by the reduction in bypassing.

Near perfect bypassing is a cap from 0.1uF to 0.01 uF (not much difference) 604 surface mount, with
at least two vis at each end abutting the pads to the power planes, along with some lo esr
tantalums (maybe 1 390 uF or larger) per IO bank.

Traces to pads, minimum via diameters, are all very bad for ground bounce.

Flip chip packages, and minimal inductance is very good for minimizing ground bounce.

After all, V= - L di/dt.

As for low frequencies, 420 MHz in Virtex II, and 500 MHz in Virtex II Pro doesn't sound all that
low to me.

Wake up:  FPGAs are right up there with the ASICs.....and we are available NOW.  About the time you
finish that ASIC that you claim beats us flat out, we will already have our next generation, after
the next one, and still be ahead.

Austin



Jay wrote:

> There is a also an equivalent limitation for simultanious switching
> outputs in ASIC's as well.  Basically you can't try to dump a ton of
> current out one side of the chip (ASIC or FPGA) all at once because
> the supply pin inductance is too high to do so without significant
> voltage droop.  Its usually not as big an issue in FPGA's because they
> generally operate at low frequencies (and thus lower required edge
> rates) compared to the ASIC cousins.  So do the tools automatically
> handle this?  The answer is no, but it most cases your FPGA emulation
> of your ASIC will be a in a completely different package anyway.
>
> Ways to help SSO (simulatanious switching outputs)
> 1) Use the slowest edge rate you can get away with
> 2) Use the lowest current driver you can get away with
> 3) Don't use flops in the output cells they tend to synchronize (by
> design) the output changes.
>
> Regards




Article: 42241
(removed)


Article: 42242
Subject: Re: just bought Cohen's book...Real Chip Design and Verification using Verilog and VHDL
From: "Paul Baxter" <pauljnospambaxter@hotnospammail.com>
Date: Thu, 18 Apr 2002 22:21:23 +0100
Links: << >>  << T >>  << A >>
Firstly let me reiterate one thing I originally said:
>
You may think I absolutely loathed the book. That's not the case as it does
present some useful cookbook-style topics, but its lack of a coherent
presentation style, poorly chosen example code and in the end is a missed
opportunity
<

That doesn't mean the book is worthless. It means I had high expectations
and a combination of poor presentation in places and 'thorough' code
examples rather than illustrated snippets with the full code on the CD made
me think it was a missed opportunity.

My previous review was a little unfair in that I mainly criticised style and
layout but didn't applaud what I do like about this book.

Ben has spent time with all of these designs. He has created simulations and
shows you timing waveforms and in most cases an RTL view. We all know this
takes time and helps our understanding of the results.

There are some diagrams that Ben has created that really do bring home the
ideas. For instance I'm currently looking at figure 3.5.5 which clearly
showed a dual clock FIFO with its control logic and the clocking associated
with all that logic. Diagrams like that are invaluable to understanding.

There are topics here that are not covered particularly well in app notes
which Ben has expanded upon, so all in all I don't doubt that some of the
information will be invaluable to everyone.

I am certainly unhappy about the way my first review may have belaboured the
issue of lack of original content. Yes there are whole sections almost
lifted from app notes, but they are usually expanded, and there are
certainly many other sections that Ben has created original content or
summarised from multiple sources. As such this will no doubt save valuable
time for the engineer.

Now onto the reply itself...

"VhdlCohen" <vhdlcohen@aol.com> wrote in message
news:20020418130404.01584.00001197@mb-mg.aol.com...
> <I'm afraid that the ad-hoc style of presentation with poor and
> inconsistently styled diagrams is the first thing to hit you.
> Tables of text that look like they were converted to bitmap and then
> stretched are really unacceptable in this day and age. Same applies to
> certain equations (how long would that have taken to typeset
> properly?)Probably an easy way of scanning source material though :( >

You quoted this IMHO valid criticism and then talk about unrelated issues.

In fairness I should say that this is only distracting in a few places
though.
The MTBF section is a particular mess with pixellated equations, a
spreadsheet where you can't actually see the numbers (well the all important
exponent digits).

Its a shame that things like timing diagrams couldn't have been exported to
one tool for a consistent polished display. Instead we have a combination of
about four or five different simulators/waveform display tools or styles of
which one or two look quite dreadful on the page.
I know many tools make it difficult to get a good waveform display but we've
probably all found ways round this if such waveforms need to be presented in
a customer report.

I say all this because quite apart from being distracting, it makes it
difficult to see the information you're trying to view.

> BEN: The goals for the book "Real Chip Design and Verification Using
> Verilog and VHDL" were:
> 1. Address issues that I experienced with designers who thought that
> knowing an HDL meant that you were ready to do designs.  That in why
> in the chapter on Fundamentals, I covered with guidelines, the topics of
> reg, latch, 2 edges of clk, and various types of counters (e.g., LFSR,
> Johnson, etc), memories, primitives, and clockboost).  It is true that
> some material were extracted, with permission, from various vendors and
> authors.  However, the object here was to put relevent information in
> one place.

I have not criticised your choice of topics. On the whole I was very pleased
with them. Better arrangement of the topics into chapters would definitely
have helped though.

> 2. Address the topic of asynchronous signals.  Again, you'll be surprised
> as to the number of engineers who fail to understand how to deal with that
> issue.

Agreed

> 3. Verification: Here I used 2 examples: a counter and a memory with EDAC.
> I was working on a project that spent many many (really many!) hours on
> the design and verification of a memory with EDAC, anyway, far more than
> the $80 cost of the book.

Cost of the book isn't an issue. I certainly know just have long it takes to
do this kind of thorough job.

> 4. Design process in defining a control machine: I have seen horrible code
> an processes in the definition of such design.  Here I attempted to define
> a usable, and hopefully practical approach  with a process, or a flow.

Yep

> 5. In arithmetic machines, I was defining the usable packages, and issues
> with Verilog.

> 6. Mixed simulation is something that is common now because many vendors
> require Verilog for the release sims, and many IPs come in Verilog (at
> first).
> 7. I wanted to present Verilog as an HDL for several reasons:
>  a. Verilog is really gaining in popularity.
>  b. Many IPs come in VErilog first.
>  c. Release sioms are often required in Verilog.
> By demonstrating designs in both HDLs, my intent was to facilitate the
> transition from one HDL into the other, and to sho that the real design
> issues are not necessarily the HDL, but the process and architectures.
>  I also includes a tutorial of Verilog for VHDL users to explain the
> differences between the two HDL.

A cookbook of ideas/things you should know is one thing, a book describing
the transitions between VHDL and Verilog is another. I don't think the two
ideas sit well together in one book as it often leaves part of the
readership out. That said, the Mixed simulation chapter is a useful adjunct
to even a VHDL-only book.

> <Granted there's a CD with a lot of the files on, and the book does
> provide a central repository, but I don't think that justifys the
expenditure
> of your effort>
> The book sells for $80.  If you can do better thatn than by searching
>things on the web, extracting meaningful info, print the material needed
> for less than $80, my hat goes to you!

I deliberately DID NOT mention money as you are right, it isn't at all
expensive in this field of publishing.

I also think I was a little unfair, in that I perhaps expected too much of
this book. I see lots of mainly presentation issues that stop this book
being a must-have book. Perhaps that's where most of my frustration lies.
This book was SO close to being a classic as you have all the content
required just not the execution of bringing it together.

If you were to republish this content having tidied up the diagrams/tables
(and removed that annoying Synplicity/Synplify pro or Cadence NC next to
every other diagram), rearranged the chapters and maybe presented it as two
volumes ( a VHDL and a Verilog volume) you really would have an instant
classic. Economic realities probably mean this wouldn't be possible but its
hopefully a clear indication that I do think highly of the content. If an
engineer is prepared to take the time avoiding the pitfalls, he will come
away having learned something valuable.

> <There are items that everyone from newcomers to moderately well-versed
> HDL engineers will learn, but it isn't presented in a coherent style,
> instead my impression is that its stitching articles together in the hope
> of getting a book published quickly>
> You are entitled to your opinions.  If you feel cheated after receiving
> the book, you may return for a refund. However, the reviewers of the
> book, including corporate VPs from Cadence and Synplicity really felt
> that the book had a lot of values as an investment.

I'm afraid your need to put a Synplify or Cadence tag line next to half the
diagrams rather than a simple acknowledgement at the start did rather temper
my opinion of the validity of these reviews.
I look forward to viewing other independent reviews.

> By the way, writing a book, and going the process of publishing (wheter
> thru a major publisher or self-publishing) is not a "quick" manner and
> DOES take many, many hours of work, particularly when the code has
> to also be verified and explained.  It also does take research on the web,
> something that was brought up as a "trivial manner, not worth the effort
> of the consolidation of the necessary, and filtered information".

I never suggested it was 'quick'. I also did not suggest that research on
the web was at all trivial. In fact I don't recall seeing your quoted
statement in the thread.
I personally find the internet an invaluable source of such information and
know how time-consuming it can be to take some information and validate it
yourself.

> I hope that this explanation provides some info as to why I wrote the
> book.  I know that I did my best, and with a lot of effort.  Style is an
> issue own by the beholder.  My style, like it or not, is by complete
> example and graphics.

If anything the book tries too hard to give too much content at the expense
of polish. My opinion only.

I really look forward to future books aiming to provide this sort of
cookbook style guide to hard-fought design tips.

I wish Ben well with this and I hope many other books in the future.

Paul Baxter



Article: 42243
Subject: Re: 8051 Core for Motor Electronics
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 18 Apr 2002 21:22:52 GMT
Links: << >>  << T >>  << A >>
On Thu, 18 Apr 2002 11:07:55 +0200, "Steffen Thieringer"
<steffen.thieringer@nmb.co.uk> wrote:
>Hello newsgroup!
>I am looking for a 8051 Core to implement in an Xilinx Spartan2 FPGA.
>The task for it is a control of a sensorless brushless DC motor.
>The software for the processor is already done but needs to be speeded up.
>So i need pwm, capture/compare units, several timers ans so on...
>I have several in my mind but not yet found 'the one'.
>I am not looking for freeware, but if there are some out there, please let
>me know:-)
>
>Thanks in advance
>
>Steffen Thieringer
>

Since you want custom peripherals with an 8051, this seem like an excellent
opportunity for you to look at the Triscend E5.

   http://www.triscend.com/products/indexe5.html



Philip Freidin
Fliptronics

Article: 42244
Subject: Re: Schematic editor and module descriptions
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 18 Apr 2002 21:37:37 GMT
Links: << >>  << T >>  << A >>
On Thu, 18 Apr 2002 14:40:47 +0200, "Stefano M"
<stefano.mora@antispam.libero.it> wrote:

>Hi everybody,
>i'm using WebPack by Xilinx and in particular the
>Schematic Editor.
>How can i draw (and how can i specify) grafically
>a 4-bits vector starting from a 8-bits vector ?
>

I haven't used this sw, but usually you do it by drawing
a sub-bus with then required range.

I.e. if you have a bus line drawn, and the signal label is
data_bus_[7:0]  , then if you attach another bus line and
label it data_bus_[5:2] you will have extracted the middle
4 bits.

If you want to rename a bus, you usually do this by passing
the signals through a BUF symbol.

I.e. connect data_bus_[2] to the input of a BUF, and label
the BUF output net new_bus_[0]

(in some schematic systems, the brackets must not be included
for single signals)

>Where i can find a description of some library
>modules ? Example: what's the difference between
>CC8CE and CB8CE counters ?

Look in the libraries guide sectio  of:

   http://toolbox.xilinx.com/docsan/xilinx4/manuals.htm


>Thanks a lot !
>Bye

Good luck,

Philip Freidin


Philip Freidin
Fliptronics

Article: 42245
Subject: Re: prototyping an ASIC
From: kayrock66@yahoo.com (Jay)
Date: 18 Apr 2002 14:43:49 -0700
Links: << >>  << T >>  << A >>
Both Altera and Xilinx compete for this application, nobody else is
even close to being as large.  Both vendors have very capable parts of
similar density.  If one of them has a special feature that you can
directly deploy (Built in ARM9 as one person mentioned), this might be
the deciding factor.  Don't worry about probing the ARM busses because
in general, for pin densities like this, you're going to want to use
one of the great embedded logic analyzer functions that these 2
vendors offer.

The speed will be much less than your ASIC unless you are willing to
spend alot of time writing FPGA specific code.  On all the projects
I've done, we always seem to end up about 1/4 speed of the real part
we are emulating.

Size- The biggest FPGA isn't that big by comparison to ASIC standards.
 Remember, the FPGA is likely build with the same process technology
that your ASIC will be.  The considerable overhead of the general
purpose layout really cuts into your effective density.  My advice,
get a temp license if you can and compile your source code to FPGA
LUTs before your buy your proto hardware so you know if you're buying
enough LUTS in your FPGA protoboard.  On one of my ASIC proto projects
we ended up scaling the design to fit in the available gates.  And no,
it wasn't a identicle source code data base, but the emulation was
still an invaluable tool.

"Peter Ormsby" <faepete.deletethis@attbi.com> wrote in message news:<q2Bt8.4749$c6.413595@typhoon.mn.ipsvc.net>...
> Gil,
> 
> It might be worth your while to take a look at Altera's Excalibur ARM FPGA.
> 
> It's a device that put an ARM 922T processor on the same die as a 100K,
> 400K, or 1M marketing gate FPGA array (if you have good idea of the number
> of registers in your design, it's better to use that to determine size
> requirements rather than ASIC gates).  Inside the Excalibur part, the ARM
> will run at 200 MHz and is attached (via AMBA AHB bus) to 256K Bytes SRAM,
> 128K Bytes dual-port SRAM, an SDRAM controller, a serial port, and several
> other peripherals.  The device is available today and Altera sells a
> development board with the 1M gate version of the part on it.  The
> development board also has PMC connectors on it for expansion daughter
> cards.  You can get more details on Altera's web site.
> 
> In case you're not familiar with the clocking differences between an FPGA
> and an ASIC, I should point out that the much-used practice of gating clocks
> in ASICs is generally a big no-no in FPGAs.  Synplicty's Certify is a tool
> which can convert gated-clocks in your design to the more FPGA-friendly use
> of clock enables if you don't want to do it manually.  There's sort of a
> trade-off between keeping your design as close to your ASIC as possible
> (gated clocks) and getting the most speed out of the FPGA (clock enables).
> 
> -Pete-
> 
> Gil Herbeck <gil@radix20.com> wrote in message
> news:3CB61C7B.700@radix20.com...
> > I need to prototype an ASIC design and am looking for
> > advice on type of FPGA and on FPGA board as well.
> >
> > The board needs to have an ARM9, external memory, an
> > interface to a PC (serial is ok), the FPGA (or ASIC),
> > and a header to plug in a daughter card with some pins
> > routed to the FPGA.
> >
> > The ASIC will have between 100K and 500K ASIC Logic
> > Gates.  It will run at about 150 MHz.  It needs about
> > 200 KB of internal RAM.  And it will have a lot of
> > multipliers.  There will probably be some pipelining
> > in the ASIC to meet speed - and probably deeper pipes
> > in the FPGA.  We want to match the FPGA to the ASIC
> > as closely as possible.
> >
> > I think the key factors in FPGA selection are:
> > - Capacity.  We want to fit in one FPGA.
> > - Performance.  We want to run at speed.
> > - "ASIC-like" synthesis library (see below)?
> > - Availability of board described above.
> >
> > "ASIC-like" synthesis library...  The datapath
> > content on the ASIC may force us to use one of the
> > datapath synthesis tools.  These tools don't support
> > FPGA architectures directly.  I've heard that since
> > the Actel architecture is "fine-grain" that it works
> > best for these types of designs.
> >
> > Any advice will be much appreciated.
> >
> > Thanks,
> > Gil
> >

Article: 42246
Subject: Re: Understanding clock routing (or not)
From: John_H <johnhandwork@mail.com>
Date: Thu, 18 Apr 2002 21:52:22 GMT
Links: << >>  << T >>  << A >>
Take a look at the clock net in the FPGA editor and you'll find the jumpoff
point for the clock that goes to the IOB is right by the global clock buffer.
The very low skew global clock distribution only feeds clocks - clocks on the
IOBs, clocks in the CLBs, no .O pins are accessible directly or indirectly
through the routing boxes.

You could achieve a "with the data" timing if you used a /4 clock instead of the
/8 clock but you don't have guaranteed zero hold.

If you move your clock by the global clock buffer and use the net which drives
the global clock input to drive your /8 external clock, you may get a better
timing relationship at the cost of a (different) sub-optimal PC board layout.
You should get clock-to-out times for the flops and in-to-out times for the
36MHz clock to 5MHz clock path from the timing analyzer, but I'm not certain
dince the DLL adds some confusion to the mix.

Right now I'm spelunking into the Virtex-II's resources by way of the FPGA
editor so I have a particular empathy for your situation.

Enjoy.
- John_H


Falk Brunner wrote:

> Hello everyone,
>
> Iam afraid Iam missing a major point in FPGA clock routing.
> I have a Virtex-E (300), feed a clock from a Xtal (36 MHz) into a global
> clock input, divide it down by 8 by means of a DLL and provide this clock to
> a clock buffer. A big part of my design runs at this ~5Mhz clock. So far, so
> good. But now comes the tricky part. I have some block which handles a
> interface with another device (its a UTOPIA2). All output signals use IO
> FFs. The clock is simply routed to an IO pin and from there to the other
> chip. The interface is fully synchronous, everything works on the rising
> edge.
> I expected, that the datas are slightly delayed behing the clock, by the
> clock-2-output time of the IOB FF, but they were NOT!!!!
> The clock IS delayed by ~3 ns behind the data!!!!
> First question, how does this happen? I thougt the clock nets are low skew,
> means the clock arrives at all cell at the same time. But the P&R tools tell
> me, that the clock is driving non-clock load, which can cause skew trouble
> (and it does :-(
> Second, what is the clean approach for clock distribution (without DLL
> usage)
> At the moment, I use a registers clocked on the other (falling) edge to
> "simulate" the right phase relation between clock and data.
>
> --
> MfG
> Falk


Article: 42247
Subject: Re: Addressing Error Ram on Virtex E.
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 18 Apr 2002 21:58:08 GMT
Links: << >>  << T >>  << A >>
On 18 Apr 2002 11:01:02 -0700, 13378988@qub.ac.uk (almost_a_gnome) wrote:

>I am using xilinx foundation series software,
>
>In simulations,
>
>I have found that if you try and address a memory location higher than
>1023 on the rams on the virtex e there is an error.
>
>i.e every time you set the 10 or 11 address lines to 1, on any of the
>12 bit addressable RAM's (B4RAM_S1 etc).
>
>Please could someone tell me if this is a software problem and how i
>can fix it so i can use the full 12 address lines on the RAM's rather
>than just the first 10.

You should have the source for the simulation models. Have you looked
at the code?

Philip Freidin
Fliptronics

Article: 42248
Subject: Re: 1000 I/O Pins -- What is cheapest FPGA?
From: John_H <johnhandwork@mail.com>
Date: Thu, 18 Apr 2002 21:59:46 GMT
Links: << >>  << T >>  << A >>
I'd like to have the option of lotsa pins available for some of my designs.
I've been buying extra logic to get my needed pin count (Altera sometimes gives
better pin counts than the Xilinx I've been designing with lately)  but the sad
truth is that the number of I/O often dictate the amount of silicon area - the
"pad limited" characteristics you hear about with ASICs.  For the highest pin
count device in a series, you effetively buy the pins and you get the logic for
free.


Falk Brunner wrote:

> "Peter Alfke" <peter.alfke@xilinx.com> schrieb im Newsbeitrag
> news:3CBEF902.77945FC@xilinx.com...
>
> > Yes, the XC2V6000 is in production, and it has 1,104 user I/O pins in the
> FF1517
> > package.  The small-quantity price is several thousand dollars. You can
> find it
> > listed at the distributors web sites. ( insight-electronics.com,
> avnet.com,
> > nuhorizons.com,)
>
> Question is, does he really need the pins AND logic, or just the pins. Maybe
> its a good idea to have some low cost, low capacity FPGAs to handle the IOS,
> bundle the data stream, and process it in a not so big FPGA.
>
> --
> MfG
> Falk


Article: 42249
Subject: Re: 8051 Core for Motor Electronics
From: "Ulf Samuelsson" <ulf@atmel.REMOVE.com>
Date: Fri, 19 Apr 2002 00:00:54 +0200
Links: << >>  << T >>  << A >>
> Hello newsgroup!
> I am looking for a 8051 Core to implement in an Xilinx Spartan2 FPGA.
> The task for it is a control of a sensorless brushless DC motor.
> The software for the processor is already done but needs to be speeded up.
> So i need pwm, capture/compare units, several timers ans so on...
> I have several in my mind but not yet found 'the one'.
> I am not looking for freeware, but if there are some out there, please let
> me know:-)
>
> Thanks in advance
>
> Steffen Thieringer
>
>
The Atmel FPSLIC is a very good part for your application, but it does not
have
the 8051, it has an AVR, which runs at 25 Mhz for about 20 MIPS.
The AT94S series has a built in configurator for small foot print.
The FPGA SRAM makes it ideal for making multi-channel timers/capture
registers
--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.







Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search