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 61475

Article: 61475
Subject: Re: Interesting article about FPGAs
From: "Paul Leventis" <paul.leventis@utoronto.ca>
Date: Sun, 05 Oct 2003 14:19:30 GMT
Links: << >>  << T >>  << A >>
[Opinions below are my own]

Martin,

I must say, as an FPGA software developer I disagree with most of what you
have to say.  Altera (and I'm sure Xilinx too) has 100's of sw engineers
banging on the software at any given time.  Software can be a great
differentiator -- in the past 10 years, there have been times when a company
has pulled ahead on the basis of better software, or fell behind due to
buggy/unstable software.  Most customers don't pick our chips until they've
tried them out, and that means using the software.  Once someone has
committed to a given vendor's chips, they won't change chips just because of
software.  But a bad software experience can certainly influence a
customer's future vendor decision!

Now, you can argue this means we've brought the software up to "adequate"
levels.  But then why would we be constantly adding new features and
improving tool quality?  We feel the competitive pressure -- even in a
two-horse race you have to gallop as fast as you can.

To address a few of the features you point out as being in need:

- Hierarchical floorplanning.  I believe that you can make hierarchical
LogicLock constraints in Quartus.  I'm not sure if that meets your needs,
but if it doesn't you're welcome to build your own floorplanning tool and
pass constraints into Quartus.  There are 3rd party companies who have done
this.

- More intelligent routers.  What is lacking in current routers?  The
Quartus router is fully timing driven, and comes mighty close to the
best-possible routes even in the presence of congestion.  It inserts routing
to resolve hold-time.  What more do you want than a router that meets your
timing requirements, fits your design even if badly congested, and
automatically resolves hold-time issues?

- Parallel processing.  It is not easy to make a fine-grained parallel
algorithm.  Let's ignore FPGA vendors for a second.  Academics have been
trying to make parallel CAD for FPGAs/ASICs work for years.  I don't think
anyone has come up with a good solution.  The problem is that in placement
(a large part of compile time), everything is related to everything else.
So you have a lot of inter-process communication in order to keep the state
of independent processes from going stale.  You can do things like periodic
updates, etc. but then the resulting placements could have much worse
performance.  What you can do with FPGA tools is farm off multiple compiles
to different machines -- you could do a "seed sweep" to find the best
placement & routing.  Not ideal, but can be helpful at times.

- Design Entry Environments.  Agreed -- and I believe there are a number of
3rd party tools for this.  The inputs to FPGA tools are well documented so
that 3rd party vendors can write their own HDL environments and/or do their
own synthesis & placement.


I do believe that with more players in the tool market there would be more
novel ideas.  The 3rd party synthesis vendors have added all sorts of
features to their tools and new tool flows that the FPGA vendors have yet to
offer.  The area where the most innovation is needed is in front-end tools &
design entry.  I would argue that back-end tools (i.e. placement, routing,
and bit file generation) wouldn't benefit much from more documentation/open
standards.  There is a huge amount of complexity associated with creating a
functional bit stream for a REAL fpga design, and your average coder at home
won't be able to contribute much to the process.

Just my $0.02 worth.  This is an interesting thread...

- Paul Leventis
Altera Corp.




Article: 61476
(removed)


Article: 61477
Subject: Re: Digesting runs of ones or zeros "well"
From: johnhandwork@mail.com (John_H)
Date: 5 Oct 2003 08:47:53 -0700
Links: << >>  << T >>  << A >>
hmurray@suespammers.org (Hal Murray) wrote in message news:<vnv6iirmfn1jd2@corp.supernews.com>...
> >Do you realize how patronizing your response was?
> >
> >Please, quickly give the appropriate INIT for a LUT4 where the desired
> >output is
> >
> >   &(in[3:1]^~in[2:0])
> >
> >Since you can count to 4, this should be simple.
> >Can you guarantee that other engineers looking at your code later will
> >understand what you're trying to do?
> 
> Sorry.  I wasn't trying to be an asshole.
> 
> I thought you were into trying to partitioning logic into LUTs in some
> sneaky way.
> 
> I assumed software is smart enough to compute an INIT string
> from a logic equation.  The old Xilinx tools could do that for
> 3000 series parts.  Has that fallen through the cracks with the
> newer software?


If I'm manually instantiating LUTs, the Synplify synthesizer has
nothing to base the INIT upon: no equations, no clue.  If I manage to
convince the software to get into the LUTs that I need so I can go
into the EDIF netlist (or HDL Analyst) and find the INITs, I've
already achieved my goal of getting the design into teh desired LUTs. 
If I do get the INITs from those sources, I must be absolutely sure I
get the port order correct or the logic is blown (or I need to do the
ol' Carnot shuffle).

I tried to instantiate a LUT the other day and I couldn't figure out
the "right" way to do the Verilog for Synplify since there are INIT
parameters for simulation and xc_props="INIT=xxxx" for synthesis as
far as I can tell.  I had something that looked un-LUT-like in the HDL
Analyst technology viewer so I didn't pursue that furhter.

Code with LUTs and INITs is sincerely less supportable than code with
something as annoying as an AND3 primitive instantiation.  Interesting
thing with the AND3 - there was no primitive in the virtex2.v file
included in the Synplify flow but a quick black_box definition in my
source and the synthesizer knew it was a 3-input AND.  It implemented
in the Xilinx device just fine.


Oh - Vinh, if you're reading...  I used an inference of the form

  bytesPlus1[8:1]==bytesPlus1[7:0]

and got a note in Synplify saying it "detected a comparator ==" and
produced your two-levels of logic with the 4-input AND.  If you do
things "just" the right way....  Oy.

Article: 61478
Subject: Re: Reusing code (Altera Quartus II 3.0)
From: "Subroto Datta" <sdatta@altera.com>
Date: Sun, 05 Oct 2003 17:20:06 GMT
Links: << >>  << T >>  << A >>
There are several approaches based on different levels of complexity.

The simplest one
1. Create each block as a Quartus project in its own directory.
2. Create a symbol for each block. Use the File Create/Update Symbol Files
for Current File command. This command also creates Entity/module
definitions that can be referred to in other HDL files.
3. Next create a project called "top" where you can stitch all these
different symbols together into a single schematic (bdf file), using the
Quartus Block editor. Another alternative is to stitch them together using a
Verilog or VHDL file.
4. To compile this "top" project you will need to Create User Library
Entries that points to each of the directories that contain the separate
blocks. This is needed so that the source files of each of these blocks can
be found during netlist extraction and synthesis (quartus_map), at the start
of the compile. The User Libraries setting can be found from the
Assignment->Settings->Files and Directories->User Libraries dialog.

One word of caution: This approach requires that you do not have
entities/modules with the same name in different User Library Directories.
If you do have entities/modules with the same name in different directories
the extractor will find and use the first reference only which is not what
you want.

5. Next add the root level VHDL and Verilog Files for each block to the
"top" project. This is done from the Assignment->Settings->Files and
Directories->Add/Remove command. This is not needed if you have followed the
convention that each entity/module is in a HDL file with the same name.

6. Compile the "top" level project. If the software says that files cannot
be found this means you have missed something in steps 4 and 5.

- Subroto Datta
Altera Corp.


"Panic" <panic74@hotmail.com> wrote in message
news:2PEfb.28070$os2.390826@news2.e.nsc.no...
> Hi
>
> I am a relative "n00b" with regard to FPGA-programming,
> but I'm currently working on a Rijndael-implementation on
> a APEX1A dev.board. And I have run into some problems.
>
> I want to put my top-level design together from several smaller
> building blocks, that I want to design, compile, simulate and
> "forget". So when I need them later on, I'd like to simply import
> them into my design.
>
> The only way I have managed to do this so far, is to copy the design-
> files from their original location, and into my new project directory.
> And this clearly isn't very efficient or simple.
>
> I know there has to be a simpler and better way, but I haven't benn
> able to figure it out yet. So all suggestions would be greatly
appreaciated.
>
> -"Panic"
>
>
>
>
>



Article: 61479
Subject: Re: Reusing code (Altera Quartus II 3.0)
From: "Panic" <panic74@hotmail.com>
Date: Sun, 5 Oct 2003 19:51:06 +0200
Links: << >>  << T >>  << A >>

Thank you so very much, Subroto Datta. I had partly managed
to figure out how to do it, but you put the final pieces in their
places. So thank you once again.

It is such a luxury to be able to get expert help, from such a broad
variety of skilled engineers that frequent this news group.

Respect to all of you :-)

-"Panic"



Article: 61480
Subject: Re: Interesting article about FPGAs
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Sun, 05 Oct 2003 17:52:58 GMT
Links: << >>  << T >>  << A >>
"Paul Leventis" wrote:

I appreciate your opinion.  And thanks for jumping in.

> I must say, as an FPGA software developer I disagree with most of what you
> have to say.  Altera (and I'm sure Xilinx too) has 100's of sw engineers
> banging on the software at any given time.

Somehow I have more faith in third parties doing a better job.  Sorry, maybe
I'm a bit close-minded here.  There are blatant examples of this outside the
FPGA domain.  How many companies out there write software that is a million
times better than anything MS can put out?  Look at photo editing software.
You have things like Photoshop at the top and hundreds of other approaches
to choose from.

I guess my greater point is that we'll never know how much better things can
get until the whole process is opened-up, as opposed to just front-end
tools.


> Software can be a great
> differentiator -- in the past 10 years, there have been times when a
company
> has pulled ahead on the basis of better software, or fell behind due to
> buggy/unstable software.

Sure.  But, I argue that if the design community has five or six different
tools to choose from aside from yours chances are you'll have: 1)A higher
conversion rate (from your competition); 2) Probably higher performance
tools than offered today; 3) More resources to develop chips as opposed to
having huge software development departments.


> Most customers don't pick our chips until they've tried them out,
> and that means using the software.

I would think that most OEM's would decide on which architecture would work
best for the widget they are trying to build.  The tools are just a means to
an end: getting a working chip into their widget.  I think history can prove
that engineers will endure great pains to make whatever tools they have
available to them work.


> But a bad software experience can certainly influence a
> customer's future vendor decision!

You bet!  I think that this might be much less of an issue for larger
corporations that can afford to have huge offshore teams working on designs
for 1/5th the cost.  Small to medium shops might not have that flexibility
(or might feel very strongly about not screwing their local talent pool)
and, therefore, foot the hidden bill generated by the
inadequacies --whatever these may be-- of single-source tools.

Maybe I've come to the realization that highly efficient, tuned, and
high-performance tools are much more important to the small to medium shops.
There's a direct cost associated with the way these tools either help you or
get in the way.  As and example, I've seen $10K EDA (schematic/layout)
packages so poor that your productivity goes right down the drain.  I happen
to know several large corporations that swear by some of these packages.
That's because of the disconnect between the guy using the tools and the guy
writing the checks.


> Now, you can argue this means we've brought the software up to "adequate"
> levels.  But then why would we be constantly adding new features and
> improving tool quality?  We feel the competitive pressure -- even in a
> two-horse race you have to gallop as fast as you can.

But you still only have two horses.  How many people tried to build a
powered flying machine?  People with lots of money and resources failed
miserably.  Yet, a couple of bicycle makers hell-bent to make it happen did.
The fact that Altera and Xilinx have hundreds of people working on software
is great, but that, to me at least, does not necessarily translate into
tools that might incorporate the most innovative "out of the box" thinking.


> - Hierarchical floorplanning.  I believe that you can make hierarchical
> LogicLock constraints in Quartus.

I have yet to use Altera chips, so I can't comment on this.


> - More intelligent routers.  What is lacking in current routers?

If you read through the newsgroup archives you'll run into posts from those
who understand the subject a heck of a lot more than I do.  Some of the
things I remember (and I've seen looking at FPGA editor) are things like
weird inter-CLB routing (using snaking routes instead of short high-speed
routing resources.  Or, how about more intelligent data path alignment
tools?


> - Parallel processing.  It is not easy to make a fine-grained parallel
> algorithm.  Let's ignore FPGA vendors for a second.  Academics have been
> trying to make parallel CAD for FPGAs/ASICs work for years.

There has to be a better approach.  Some of these designs take hours to
compile.  Productivity goes right down the drain.  No wander large corps
look for offshore design teams.  So, what I'm saying is that you are also
affecting my local economy because it's simply too expensive to have whole
teams on hold for several hours for each iteration.

Again, FPGA synthesis/placement/routing software is not my field, so I'm not
the one to offer ideas on better ways to do it.


> - Design Entry Environments.  Agreed -- and I believe there are a number
of
> 3rd party tools for this.  The inputs to FPGA tools are well documented so
> that 3rd party vendors can write their own HDL environments and/or do
their
> own synthesis & placement.

This might even go further to include better HDL's.


> I do believe that with more players in the tool market there would be more
> novel ideas.  The 3rd party synthesis vendors have added all sorts of
> features to their tools and new tool flows that the FPGA vendors have yet
to
> offer.

And that encapsulates my thinking.  If these outside vendors had access to
the complete process I bet a lot of interesting tools would come out.

> There is a huge amount of complexity associated with creating a
> functional bit stream for a REAL fpga design, and your average coder at
home
> won't be able to contribute much to the process.

I don't think that what I'm pushing for is in the realm of garage operators.

Thanks again,


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"









Article: 61481
(removed)


Article: 61482
Subject: How To: 3-input NAND gate using ACTEL ACT 1 logic module
From: hsultan@utnet.utoledo.edu (zaf)
Date: 5 Oct 2003 12:58:52 -0700
Links: << >>  << T >>  << A >>
Hello members...i need urgent help with a digital design problem

can some please help me expand the following function using shannon's
expansion theorem

F = (A.B.C)'
  = C' + A'C + AB'C

I need to map this function to an Altera ACT 1 FPGA logic module with
three 2:1 MUX's and one OR Gate.

any help would be greatly appreciated 

thanks
zaf

Article: 61483
(removed)


Article: 61484
Subject: Re: Digesting runs of ones or zeros "well"
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 05 Oct 2003 20:08:00 -0000
Links: << >>  << T >>  << A >>
>I tried to instantiate a LUT the other day and I couldn't figure out
>the "right" way to do the Verilog for Synplify since there are INIT
>parameters for simulation and xc_props="INIT=xxxx" for synthesis as
>far as I can tell.  I had something that looked un-LUT-like in the HDL
>Analyst technology viewer so I didn't pursue that furhter.

This seems like a good addition to the tools discussion in other
threads.

There really should be a simple way to say something like:
  Generate this signal in a LUT (or whatever) with these inputs.
  Possibly constraining the location and/or locking some inputs to
    particular ports.
The idea is that the system will figure out the details from the
info it already has.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 61485
Subject: Re: Interesting article about FPGAs
From: soar2morrow@yahoo.com (Tom Seim)
Date: 5 Oct 2003 16:05:40 -0700
Links: << >>  << T >>  << A >>
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<b%Pfb.11841$R64.8513@newssvr25.news.prodigy.com>...
> 20+ years.  I go back to hand-drawn schematics and wire-wrapped boards as
> well.  Had lots of fun designing boards the size of pizza boxes with loads
> of TTL chips.

Well, I got you beat (I'm into my 35th year). Used to be that Xilinx
didn't have design entry (you had to buy Orcad). Now it's integrated,
which is a much superior arrangement.

There are third party tools out there, but they can be expensive. I
have just started to use Handle-C from Celoxica. It is very good at
implementing highly parallel algorithms. We are using it for real-time
image processing.

> 
> Don't be fooled by shinny GUI's.  Today's tools are adequate.  Not sure I'd
> call them good.
> I have a feeling they need to (and could/should) be substantially better.
> And I simply don't think that sole-sourcing is the way to go.  Not any more.
> That's all.

I don't think we have seen the end of tool development. I will give
some feedback on Handle-C after I've had the opportunity to do a few
designs.

Tom

Article: 61486
Subject: Re: Free timing diagram drawing software
From: soar2morrow@yahoo.com (Tom Seim)
Date: 5 Oct 2003 16:15:54 -0700
Links: << >>  << T >>  << A >>
"Michael Chan" <s354025@student.uq.edu.au> wrote in message news:<blp8id$7rp$1@bunyip.cc.uq.edu.au>...
> Hi,
> 
> I'm not sure if this is the best place to ask, but anyway, does anyone know
> of any free software that draws timing diagrams?
Try

http://www.timingtool.com/

the lite version is free.

Tom

Article: 61487
Subject: Re: Interesting article about FPGAs
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Sun, 05 Oct 2003 23:24:37 GMT
Links: << >>  << T >>  << A >>
"Tom Seim" wrote:

> There are third party tools out there, but they can be expensive. I
> have just started to use Handle-C from Celoxica. It is very good at
> implementing highly parallel algorithms. We are using it for real-time
> image processing.

I looked at Celoxica's tools two years ago and just couldn't afford the
time/effort to consider the switch.  I might look at them again next year.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 61488
Subject: Re: Interesting article about FPGAs
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Mon, 06 Oct 2003 12:48:07 +1300
Links: << >>  << T >>  << A >>
Martin Euredjian wrote:
> 
> "Paul Leventis" wrote:
> 
> I appreciate your opinion.  And thanks for jumping in.
> 
> > I must say, as an FPGA software developer I disagree with most of what you
> > have to say.  Altera (and I'm sure Xilinx too) has 100's of sw engineers
> > banging on the software at any given time.
> 
> Somehow I have more faith in third parties doing a better job.  Sorry, maybe
> I'm a bit close-minded here.  There are blatant examples of this outside the
> FPGA domain.  How many companies out there write software that is a million
> times better than anything MS can put out?  Look at photo editing software.
> You have things like Photoshop at the top and hundreds of other approaches
> to choose from.
> 
> I guess my greater point is that we'll never know how much better things can
> get until the whole process is opened-up, as opposed to just front-end
> tools.

The FPGA suppliers don't have such large SW teams just for the fun of
it.
They do it because it is crucial for their business.
ISTR a note recently that the SW teams are now larger than the HW teams.

If you want to see what 'SW here / HW over there' gave us, just go back
10-15 years.

> > - Hierarchical floorplanning.  I believe that you can make hierarchical
> > LogicLock constraints in Quartus.
> 
> I have yet to use Altera chips, so I can't comment on this.

?!
 
> > - Parallel processing.  It is not easy to make a fine-grained parallel
> > algorithm.  Let's ignore FPGA vendors for a second.  Academics have been
> > trying to make parallel CAD for FPGAs/ASICs work for years.
> 
> There has to be a better approach.  Some of these designs take hours to
> compile.  Productivity goes right down the drain.  No wander large corps
> look for offshore design teams.  So, what I'm saying is that you are also
> affecting my local economy because it's simply too expensive to have whole
> teams on hold for several hours for each iteration.

 I believe for the really big designs, you can do incremental designs.
Altera called this (strangely) 'back annotate' IIRC.

 If the change you have just done affects a large portion of logic, then
a full respin is a good idea - but more often it affects a small
section.

 What IS a positive thing for all tool chains, is the emergence of
NIOS / MicroBlaze etc - this means there are teams INSIDE the companies
who USE the tools, and have a vested interest in just what you
describe - ability to keep optimised layouts, and faster iteration
times.
 Each minor improvement can win them 'boasting rights for fastest core'.

 I have not tracked it closely, but I believe SW gains alone have given 
significant performance gains for the NIOS/Microblaze core speeds. 
 Silicon gains will always improve the numbers....
-jg

Article: 61489
Subject: Re: Interesting article about FPGAs
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Mon, 06 Oct 2003 01:29:09 GMT
Links: << >>  << T >>  << A >>
"Jim Granville" wrote:

> The FPGA suppliers don't have such large SW teams just for the fun of
> it.

How are these teams organized?  Where does innovative thinking (as opposed
to sustaining or evolutionary thinking) fit into their infrastructure?  Are
there parallel teams competing to create the best possible tools?  How many
layers removed from actual users are these developers?

I'm not saying that they are not doing a decent job.  But, what's out there
to compare to?  All I'm saying is that the history of humanity shows that
there's always someone who, for some reason, can figure out how to do a
better job.  Until you open it up to the entrepreneurial masses we'll never
know what we might be missing (or not).  There are countless examples of
small dedicated teams running circles around large ones.  So, developer
count alone does not tend to mean much.

> > > - Hierarchical floorplanning.  I believe that you can make
hierarchical
> > > LogicLock constraints in Quartus.
> >
> > I have yet to use Altera chips, so I can't comment on this.
>
> ?!

I'm not sure what you mean by "?!".  I don't need to know about Altera's
offerings to know that hierarchical floorplanning is important.  The tools I
use don't offer this.  I can't comment on Altera's tools 'cause I don't use
them.  For all I know, they might be wonderful.

In the Xilinx tool flow, if you took the time to write your own code to
drive the tools outside of the GUI you could probably achieve a degree of
parallel processing and something akin to hierarchical floorplanning.  You'd
have to use the modular design flow.  With enough segmentation you could
launch compilation runs for different modules on a bunch of machines on the
network.  Your code would have to wait for everyone to be done and then
launch NGDBUILD to glue it all together.  If the flow could do more than one
hierarchical level this could be useful.  Not having attempted this I'm not
sure what problems one might run into, but it could be an interesting way to
boost throughput.

In general terms, as devices get faster, cheaper and larger (gate count) the
whole idea of segmenting designs down to basic hierarchical pieces that get
stiched together to form larger functional modules becomes more and more
important.  This, probably at the expense of packing the logic in as tightly
as possible (meaning that you'd have to accept CLB waste you might not
otherwise have accepted years ago).  But you have to have control of all the
branches and leaves of the tree, not just the first level.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 61490
Subject: Re: Interesting article about FPGAs
From: "Paul Leventis" <paul.leventis@utoronto.ca>
Date: Mon, 06 Oct 2003 02:35:20 GMT
Links: << >>  << T >>  << A >>
[Opinions below are my own]

Martin,

I agree that competition drives innovation, and that no matter how large the
team, progress can stagnate.  Why would an FPGA company take a risk on some
radically new tool when there are a gazillion incremental improvements that
still need to be implemented?  Having outside parties developing tools can
provide quantum leaps or totally fresh ways of approaching a problem.

However, the major motivator is probably going to be money.  And the FPGA
CAD business is a tough one; not only is the target market (of FPGA
developers) relatively small (but growing quickly), they are for the most
part highly cost sensitive.  Not only do you need a good product, but you
need a product that provides a significant advantage over the freely (or
close to) provided tools from the vendors themselves.  In some senses, by
pricing their CAD tools so low, FPGA vendors have made it difficult for any
third party company to survive, at least on the back-end of the flow.

In areas such as synthesis & simulation, there is a greater opportunity and
market.  Not only do the various 3rd party vendors offer good products, they
provide users with some level of FPGA vendor-independence, which has value.
Much of the development done on these tools can be leveraged across various
FPGA families from different companies.  And the expertise can be applied to
the much larger (but hopefully shrinking ;-)) ASIC business.

There have been a handful of FPGA CAD start-ups over the years that have
attacked various problems with some success.  The few that I can think off
hand are ADT (now part of Magma), Hier Designs, Right Track CAD (happily a
part of Altera), and NeoCAD (part of Xilinx).  So some innovation has been
happening, though often development agreements were the means of obtaining
the documentation & interfaces required.

Perhaps the best solution (as you suggest) would be for Altera/Xilinx to let
the market decide by providing publicly documented interfaces to their
tools.  If nobody sees an advantage to writing such a tool, no one will.
However, there is a cost associated with documenting and supporting such
interfaces.  And there is always the fear that more and more disclosure will
aid competitors by providing insights into how both the hardware and
software tools work.  Does the good outweigh the bad?  I dunno.

None of my arguments are new, or unique to FPGAs for that matter -- almost
any open-source or open-standard debate eventually ends up circling around
these issues!

Regards,

Paul Leventis
Altera Corp



Article: 61491
(removed)


Article: 61492
Subject: Re: Spartan 2e implementation
From: jamese@sterling.net (Jim English)
Date: 5 Oct 2003 21:30:10 -0700
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote in message news:<3F7885B8.D724DC73@xilinx.com>...
> Don't do it.
> Clock gating is an ugly and error-prone design methodology.
> In 99% of all cases there are better ways to design.
> What are yiou really trying to do?
> Peter Alfke
> ======
> jose wrote: 
> > I try to do gating clock.
> > 
> > What I can do?

OK in general; Clock gating sucks, don't do it.

In specific; An asic I was involved with had a clock gating circuit (I
call them precision kluges).  To test the design in the fpga I just
ran the gated clock out of the chip, then back on using a dedicated
global clock buffer.  This worked great, and the fitter didn't
complain either.

je

Article: 61493
Subject: Re: Good VHDL/Verilog editor?
From: "Alex Gibson" <alxx/remove/@/remove/ihug./remove/com./remove/au>
Date: Mon, 6 Oct 2003 15:10:06 +1000
Links: << >>  << T >>  << A >>

"Jake Janovetz" <jakespambox@yahoo.com> wrote in message 
news:d6ad3144.0310011643.21599fc8@posting.google.com...
> I'm growing increasingly weary of my current editor lot and am in the
> market for a new one.  What I'd like is something akin to the Visual
> Studio editor.  You know, syntax highlighting (easy) as well as
> on-line lookup for functions/instances, project management, etc.
>
> It would be especially nice if the editor would integrate with the
> FPGA primitive libraries so I can get parameters and usage information
> just like in Visual Studio.
>
> Visual Slick Edit seems somewhat close, but is pretty rough around the
> edges for its price tag.  Anyone?
>
>    Jake

Codewright. now owned by Borland.
http://www.codewright.com/cwhome75.asp

Give the demo a whirl.
http://www.codewright.com/download
(stingy people, it was a 30 day eval a while back)
(The demo eval key you recieve  says its a 30 day key that expires in
two weeks)

http://www.codewright.com/support/faq.asp

I've been using it for a few years for c,c+,fortran,java, asm.
Recently for vhdl(last 6 months)

Even with the demo make sure to download the addons.
especially for vhdl and verilog also the visual studio synch plugin.

Alex

Article: 61494
Subject: Re: MicroBlaze size
From: Goran Bilski <goran@xilinx.com>
Date: Mon, 06 Oct 2003 09:05:38 +0200
Links: << >>  << T >>  << A >>
Hi,

The version that is shipped with EDK instanciate Xilinx primitives.
But there exists a pure RTL version of MicroBlaze which can be purchased 
as source code.

Göran

Jon Beniston wrote:

>Goran Bilski <goran@xilinx.com> wrote in message news:<blj44a$hht2@cliff.xsj.xilinx.com>...
>  
>
>>Hi,
>>
>>The register file is included in that number.
>>
>>Göran
>>    
>>
>
>Thanks. One other question, is it a pure RTL design or does it
>instantiate Xilinx specific primitives? Ditto for NIOS?
>
>Cheers,
>Jon
>  
>


Article: 61495
Subject: Timing from 1x to 2x and back
From: "Morten Leikvoll" <m-leik@online.nospam>
Date: Mon, 6 Oct 2003 09:27:25 +0200
Links: << >>  << T >>  << A >>
My collegue and I discussed how our placer (xilinx's) handled going from 1x
clocks to 2x clocks and back. (These have of course common rising edge)

For this example I use a 100Mhz clock and a 200Mhz clock:

There are 3 ways of doing this:

1 (based on the timing of the previous ff's output ) Signals coming from 1x
to 2x will be routed with max 10ns delay. This means that you can not tell
wether the signal will appear at the 2x at the 5ns or 10ns rising 2x clock.

2 (based on the input timing) Signals coming from 2x to 1x will be routed
with max 10ns delay. This means that the output can sometimes skip the first
1x edge.

3 (based on the lowest delay of input and previous output) This works, but
my collegue claims this tool doesn't do it this way. Can anyone confirm this
is the case?

How DOES the placer tool handle this?




Article: 61496
Subject: Re: Digesting runs of ones or zeros "well"
From: Goran Bilski <goran@xilinx.com>
Date: Mon, 06 Oct 2003 09:29:34 +0200
Links: << >>  << T >>  << A >>
Hi,

The way I use to do it is to draw a carnaugh map and include it in a 
comment above the instanciated lut.

Göran

John_H wrote:

>hmurray@suespammers.org (Hal Murray) wrote in message news:<vnsdiro5e8e272@corp.supernews.com>...
>  
>
>>>I overuse the syn_keep attribute and I hate the idea of instantiating
>>>LUTs.  My Carnot skills aren't exactly used regularly.
>>>      
>>>
>>Are Carnot skills needed?  I can generally count to 4.  A 4 input LUT
>>can implement any function of 4 inputs.
>>    
>>
>
>Do you realize how patronizing your response was?
>
>Please, quickly give the appropriate INIT for a LUT4 where the desired
>output is
>
>   &(in[3:1]^~in[2:0])
>
>Since you can count to 4, this should be simple.
>Can you guarantee that other engineers looking at your code later will
>understand what you're trying to do?
>
>With Regards,
>John_H
>  
>


Article: 61497
Subject: Re: Memory Handling in Altera Cyclone devices
From: andres.vazquez@gmx.de (Vazquez)
Date: 6 Oct 2003 00:33:15 -0700
Links: << >>  << T >>  << A >>
Hello Mr Leventis,

you said that to clear memory I have to iterate through it and write 0s.
In Cyclone Devices there is the possibility to create FIFO and RAM structures
by using the MegaWizard Manager. By doing so there is a signal called 'aclr'.
What function does this signal have in
a) FIFOs
b) RAMs    ?
Is the content of the memory set to 0 or only the surrounding registers?

Thank you very much

Kind regards
Andrés Vázquez
G&D System Development


"Paul Leventis" <paul.leventis@utoronto.ca> wrote in message news:<rgAeb.22504$lKj.10858@news04.bloor.is.net.cable.rogers.com>...
> Hi Andres,
> 
> The problem isn't your "writing" signal -- it is the asynchronous clearing
> of the memory.  Memories are not clearable -- if you want to clear your
> memory, you must do so by iterating through it and writing 0s.
> 
> Regards,
> 
> Paul Leventis
> Altera Corp.
> 
> 
> 
> "Vazquez" <andres.vazquez@gmx.de> wrote in message
> news:eee19a7a.0310010044.249af36e@posting.google.com...
> > Dear Mr Leventis,
> >
> > thank you for your answer.
> >
> > The problem of the QuartusII-Software-Compiler seems to be
> > the recognition of RAM-structures.
> > The following source code is synthesized using memory bits
> > when the signal writing is not used.
> > When the signal writing is used then QuartusII tries to synthesize
> > it without any memory bits.
> > Where could be the problem in the use of the signal writing?
> >
> > Kind regards
> > Andrés
> > G&D System Development - FPGA design
> >
> >
> > -------------------------------------------------
> > -------------------------------------------------
> > LIBRARY ieee;
> > USE ieee.std_logic_1164.ALL;
> >
> > PACKAGE test_ram_package IS
> >
> >    CONSTANT ram_width : INTEGER := 8;
> >    CONSTANT ram_depth : INTEGER := 2048;
> >
> >    TYPE word IS ARRAY(0 to ram_width - 1) of std_logic;
> >    TYPE ram IS ARRAY(0 to ram_depth - 1) of word;
> >    SUBTYPE address_vector IS INTEGER RANGE 0 to ram_depth - 1;
> >
> >    CONSTANT xram_width : INTEGER := 12;
> >    CONSTANT xram_depth : INTEGER := 16;
> >
> >    TYPE xword IS ARRAY(0 to xram_width - 1) of std_logic;
> >    TYPE xram IS ARRAY(0 to xram_depth - 1) of address_vector;
> >    SUBTYPE xaddress_vector IS INTEGER RANGE 0 to xram_depth - 1;
> >
> > END test_ram_package;
> >
> > LIBRARY ieee;
> > USE ieee.std_logic_1164.ALL;
> > USE ieee.std_logic_arith.ALL;
> > USE ieee.std_logic_unsigned.ALL;
> > USE work.test_ram_package.ALL;
> >
> >
> > ENTITY test_inferred_ram IS
> >    PORT
> >    (  --reset  : IN   std_logic;
> >       clock1 : IN   std_logic;
> >       clock2 : IN   std_logic;
> >       data   : IN   word;
> >       write_address: IN  address_vector;
> >       read_address:  IN  xaddress_vector;
> >   write_xaddress : IN xaddress_vector;
> >   xdata : IN address_vector;
> >       we     : IN   std_logic;
> >       q      : OUT  word
> >    );
> > END test_inferred_ram;
> >
> > ARCHITECTURE rtl OF test_inferred_ram IS
> >
> >
> >    SIGNAL ram_block : RAM;
> >    SIGNAL xram_block : XRAM;
> >    SIGNAL read_address_reg : xaddress_vector;
> >    SIGNAL writing : std_logic;
> >
> > BEGIN
> >
> >    PROCESS (clock1)
> >    BEGIN
> >       --IF reset='1' then
> >       --   ram_block <= (others => (others=>'0'));
> >       --   xram_block <= (others=>0);
> >       --   writing <= '0';
> >       IF (clock1'event AND clock1 = '1') THEN
> >          IF (we = '1' and writing='0') THEN
> >             ram_block(write_address) <= data;
> > xram_block(write_xaddress) <= xdata;
> > writing <= '1';
> >      ELSIF (we='1' and writing='1') then
> >            ram_block(write_address) <= data;
> >    xram_block(write_xaddress) <= xdata;
> >    writing <= '0';
> >          END IF;
> >       END IF;
> >    END PROCESS;
> >
> >    PROCESS (clock2)
> >    BEGIN
> >       IF (clock2'event AND clock2 = '1') THEN
> >          q <= ram_block(xram_block(read_address_reg));
> >          read_address_reg <= read_address;
> >       END IF;
> >    END PROCESS;
> >
> > END rtl;

Article: 61498
Subject: Re: Digesting runs of ones or zeros "well"
From: "Vinh Pham" <a@a.a>
Date: Mon, 06 Oct 2003 08:09:22 GMT
Links: << >>  << T >>  << A >>
> Oh - Vinh, if you're reading...  I used an inference of the form
>
>   bytesPlus1[8:1]==bytesPlus1[7:0]
>
> and got a note in Synplify saying it "detected a comparator ==" and
> produced your two-levels of logic with the 4-input AND.  If you do
> things "just" the right way....  Oy.

Great John :_)  Glad you found a compact way of getting Synplify to do what
you want.  It's a great synthesizer, but like all of them, it's got it's own
quirky "dialect."  Good ol' trial and error.

Heh one annoying situation is when the synthesizer "optimizes" 90% of your
design away, and you have to hunt down that little itty bitty bit of code
that caused it.



Article: 61499
Subject: Re: Digesting runs of ones or zeros "well"
From: "Morten Leikvoll" <m-leik@online.nospam>
Date: Mon, 6 Oct 2003 10:17:56 +0200
Links: << >>  << T >>  << A >>
"John_H" <johnhandwork@mail.com> skrev i melding
news:Xwoeb.26$XP3.4711@news-west.eli.net...
> Greetings,
>
> I need to detect runs.  I want to look at 65 bits and show when there are
9
> consecutive 1s or 0s from the byte boundaries resulting in 8 values per
> clock.  This should be comfortably done in two logic levels (I need clean
> logic delays).
>
> The idea is simple but the implementation is tough.  I'm working with
> Verilog in Synplify, targeting a Xilinx Spartan-3.  I have to resort to
> design violence to get the results that I believe are "best."
>
> Any thoughts on how to do this "better?"  (the following code likes fixed
> fonts)

I just started reading this thread.. Am I correct if you really want to
detect 9 EQUAL bits in a row from a stream?
Could you not do this just with a 4bits counter and a comparator/zero
detector?






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