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

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

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

Custom Search

Messages from 117175

Article: 117175
Subject: Re: shift register with distributed ram
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 26 Mar 2007 03:35:24 GMT
Links: << >>  << T >>  << A >>
Marty Ryba wrote:
> "John McCaskill" <junkmail@fastertechnology.com> wrote in message 
> news:1174756909.000771.39330@e1g2000hsg.googlegroups.com...
>> The SLR16s have two outputs that can be used for serial to parallel
>> shifters, the Q15 for cascading, and the selectable output.  I finally
>> found the article that describes how to use an SRL plus a FF to build
>> a 6 bit per slice serial to parallel shifter. It is by Kris Chaplin,
>> not Ken Chapman like I had been thinking.
> 
> Slightly in another direction...is there a trick to setting up the cascades 
> on the SRL16s to maintain a consistent delay? We strung 8 in a row to get an 
> adjustable 1-bit delay line. It works, but there's a bunch of extra muxes, 
> etc. to get the delay consistent (3 clocks plus whatever tap I pull as 
> output). I'm actually the systems guy and not the VHDL coder (and 
> communication of requirements is always tricky when you're doing something 
> new), but I'm always interested in the mechanics to see if it can be done 
> better (smaller) while still meeting requirements. Especially since I'd 
> really like a 1024 tap delay but I ran out of space (I need tens of these, 
> plus other DSP goodies). Suggestions on other mechanisms to use are also 
> welcome.
> 
> Dr. Marty Ryba
> martin (dot) ryba (at) verizon (dot) net (man, I hate sp*m)

Shift registers are clocked.  Clocked elements don't have routing 
consistency issues, they have routing maximum issues.  I'd suggest using 
some Xilinx routing for combinatorial delays in an *extremely* well 
controlled situation, inverting consecutive stages of a multi-tap delay 
to reduce pulse width distortion.  But a 1024 element delay line?!  It 
sounds like you need a nice, clocked delay.  SRLs in series shouldn't 
have delay issues.

Is it that you're taking the output from a very long clocked shift 
register?  If so, just clock the muxed outputs to get all the SRLs to 
show up at the output pin at a predictable time.

Often the conceptual problem with unclocked delay lines is figuring out 
how to get a consistent input path or a consistent output path; the 
trouble is, both are needed.

What is your desired range and resolution?  Acceptable jitter?

Article: 117176
Subject: Re: shift register with distributed ram
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 25 Mar 2007 20:59:28 -0700
Links: << >>  << T >>  << A >>
Unclocked delay lines are really not stable over temperature and
voltage, although there are "servo' tricks to stabilize them (as done
in the IDELAY and ODELAY Virtex I/O functions)
For a very long clocked delay line, it might make sense to use a dual-
ported BlockRAM.
"Waste is often only in the eyes of the beholder..."
Peter Alfke, Xilinx

On Mar 25, 8:35 pm, John_H <newsgr...@johnhandwork.com> wrote:
> Marty Ryba wrote:
> > "John McCaskill" <junkm...@fastertechnology.com> wrote in message
> >news:1174756909.000771.39330@e1g2000hsg.googlegroups.com...
> >> The SLR16s have two outputs that can be used for serial to parallel
> >> shifters, the Q15 for cascading, and the selectable output.  I finally
> >> found the article that describes how to use an SRL plus a FF to build
> >> a 6 bit per slice serial to parallel shifter. It is by Kris Chaplin,
> >> not Ken Chapman like I had been thinking.
>
> > Slightly in another direction...is there a trick to setting up the cascades
> > on the SRL16s to maintain a consistent delay? We strung 8 in a row to get an
> > adjustable 1-bit delay line. It works, but there's a bunch of extra muxes,
> > etc. to get the delay consistent (3 clocks plus whatever tap I pull as
> > output). I'm actually the systems guy and not the VHDL coder (and
> > communication of requirements is always tricky when you're doing something
> > new), but I'm always interested in the mechanics to see if it can be done
> > better (smaller) while still meeting requirements. Especially since I'd
> > really like a 1024 tap delay but I ran out of space (I need tens of these,
> > plus other DSP goodies). Suggestions on other mechanisms to use are also
> > welcome.
>
> > Dr. Marty Ryba
> > martin (dot) ryba (at) verizon (dot) net (man, I hate sp*m)
>
> Shift registers are clocked.  Clocked elements don't have routing
> consistency issues, they have routing maximum issues.  I'd suggest using
> some Xilinx routing for combinatorial delays in an *extremely* well
> controlled situation, inverting consecutive stages of a multi-tap delay
> to reduce pulse width distortion.  But a 1024 element delay line?!  It
> sounds like you need a nice, clocked delay.  SRLs in series shouldn't
> have delay issues.
>
> Is it that you're taking the output from a very long clocked shift
> register?  If so, just clock the muxed outputs to get all the SRLs to
> show up at the output pin at a predictable time.
>
> Often the conceptual problem with unclocked delay lines is figuring out
> how to get a consistent input path or a consistent output path; the
> trouble is, both are needed.
>
> What is your desired range and resolution?  Acceptable jitter?



Article: 117177
Subject: Re: Where is Open Source for FPGA development?
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Mon, 26 Mar 2007 01:11:00 -0400
Links: << >>  << T >>  << A >>
> Plus, the vendors give free tools, so there is not the
> price, or sponsored, incentive other open-source targets have.

Yes... free tools... with large minimum quantity provisioning contract for 
anything besides economy/entry-level parts - Quartus Web/ISE Webpack only 
support Cyclone/Spartan FPGAs and small Stratix/Virtex devices. For small 
customers, the full Quartus/ISE usually costs a few grands.

While it would certainly be nice to have open-source tools to support FPGA 
development (more options is almost always good for those days where 
ISE&all keep on crashing and burning), the rather small world-wide pool of 
FPGA people with both the programming knowledge and motivation to build and 
maintain this sort of project as volunteers is, unfortunately, almost 
certainly far too small.

There are incentives to having independent tools such as avoiding 
XST/PAR/MAP bugs by replacing the whole tool chain... but the magnitude and 
complexity of such a project goes beyond what I believe can be expected 
from volunteer work. Whether or not the gains would offset the effort is a 
subjective matter but odds are mostly against it for the foreseeable future 
as you said.

Who knows, maybe some FPGA vendor will open-source their tools some day and 
get the ball rolling.

Article: 117178
Subject: Re: Where is Open Source for FPGA development?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Mon, 26 Mar 2007 17:49:54 +1200
Links: << >>  << T >>  << A >>
Daniel S. wrote:

>> Plus, the vendors give free tools, so there is not the
>> price, or sponsored, incentive other open-source targets have.
> 
> 
> Yes... free tools... with large minimum quantity provisioning contract 
> for anything besides economy/entry-level parts - Quartus Web/ISE Webpack 
> only support Cyclone/Spartan FPGAs and small Stratix/Virtex devices. For 
> small customers, the full Quartus/ISE usually costs a few grands.


True, but I did notice Altera is has decided to make the Entire Cyclone 
III for free :

PR:
"Quartus II software version 7.0 provides industry-leading performance 
and productivity features to support the new Cyclone III family, 
including the EP3C120 device with 120,000 LEs, 4 Mbits of memory and 288 
multipliers—the highest-device density available in any FPGA vendor’s 
free software package."

Q: So how many NIOS cores could fit in this device ?

-jg



Article: 117179
Subject: Re: Xilinx Platform cable USB and impact on linux without windrvr
From: "Luzerne" <luzerne.ganhir@gmail.com>
Date: 25 Mar 2007 23:33:42 -0700
Links: << >>  << T >>  << A >>
On 25 mar, 22:17, carlos.as...@gmail.com wrote:
>
> Thank you very much Luzerne for taking the time of explaining it step
> by step really clearly and slowly. I really really appreciate it.
>
> What I was doing wrong was doing "export LD_PRELOAD=/path/Travail/usb-
> driver/libusb-driver.so" in another terminal session since I thought
> this was a kind of global setting.
>
> Again thanks a lot for everything you have done.
>
> Carlos

You're welcome. My post was in fact more a contribution given back to
Michael GERNOTH's work than to you :) but I'm happy to know it helps
someone, and to discover this someone is so grateful :)
But I think your greets are misplaced, as Michael GERNOTH deserves all
of them.

Luzerne GANHIR


Article: 117180
Subject: Re: help needed
From: djoshi@btinternet.com
Date: 26 Mar 2007 01:32:37 -0700
Links: << >>  << T >>  << A >>
Dear Rob

Thank You for your reply below.

I am still a student learning more into FPGA so please excuse me style
of questioning

Quartus defaults to the most stringent hold requirement, 0ns.  A hold
violation is typically due to clock skew, gated clocks, or the sourse
and
destination register clocked by two different clocks.  Your state
machine
probably transistions from one state to another by CLK_H; and certain
states
within your state machine are probably creating strobes that are
clocking
registers.  My guess is that the source and destination register are
being
clocked by two different signals thus giving you this error.  If you
really
don't need a 0ns hold requirment on this path,  you can utilize the
Multicycle Hold assignment to get you by this timing warning.

Search on "hold relationship" and "Multicycle Hold timing assignment"
in the
help section of Quartus.  These two section should help you.


I got few things i need to ask.

When you say " your state machine are probably creating strobes that
are clocking
registers", would that mean that once i get to into a state i am
asserting signal, for example the input vector to the RAM gets
asserted to ceratain binary value. My design uses only one clock, so
how can "My guess is that the source and destination register are
being
clocked by two different signals thus giving you this error" i check i
am not having this problem.



Thank You very much for your help



Regards



Dharmesh Joshi


Article: 117181
Subject: Re: Where is Open Source for FPGA development?
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Mon, 26 Mar 2007 09:36:16 +0100
Links: << >>  << T >>  << A >>

<psihodelia@googlemail.com> wrote in message 
news:1174871961.121540.72100@d57g2000hsg.googlegroups.com...
> Today I see no alternative to use Xilinx or Alteras Web Packs. Both
> are in a very sad state. As Linux or PowerPC user you cannot develop
> your FPGA design with this tools. On x86 or on Windows they are very
> buggy, slow, and unproductive as well.

Strange... last time I looked, Xilinx provided full support for Linux as a 
host environment, even with the free WebPack software. True, it's only on 
x86. But if there was a great demand for e.g. Mac software for FPGA 
development, I'm sure FPGA vendors would at least think about providing it.

Personally I can't see FPGA vendors going completely open-source with their 
tool development - they have too much "secret sauce" tied up in their 
back-end algorithms. Still, it's not hard to imagine a more open approach 
than what we have at the moment...

        -Ben- 



Article: 117182
Subject: Re: help needed
From: djoshi@btinternet.com
Date: 26 Mar 2007 01:38:47 -0700
Links: << >>  << T >>  << A >>
Dear Rob

I also have some states that has not commands in them. The purpose of
these were to cause few clock cycle delays. Could this be a problem.


Regards

Dharmesh Joshi


Article: 117183
Subject: Re: Where is Open Source for FPGA development?
From: David Brown <david@westcontrol.removethisbit.com>
Date: Mon, 26 Mar 2007 10:48:36 +0200
Links: << >>  << T >>  << A >>
psihodelia@googlemail.com wrote:
> Many engineers today have Linux on Desktop as main-OS. Many engineers
> today use Open Source products because of their quality, stability,
> and configurability.
> 
> Today I see no alternative to use Xilinx or Alteras Web Packs. Both
> are in a very sad state. As Linux or PowerPC user you cannot develop
> your FPGA design with this tools. On x86 or on Windows they are very
> buggy, slow, and unproductive as well.
> 
> So, any idea, how can we change this situation? Will we meet the time
> of Open Source development tools for programmable logic devices?
> 

This is a mix of two different things - running tools in an open source 
environment, and open-source tools.

For a number of reasons, it is unlikely that we will see open source 
toolsets that cover the whole range of FPGA design.  In particular, 
placing, routing and timing are so tied in with the hardware, and so 
specialised, that there are few people in the world who are capable of 
writing such software that are not already working for an FPGA company. 
  Open source is not an appropriate development model for such software.

Other parts of the toolset are a different matter.  There are a number 
of open source HDLs, such as MyHDL or confluence, which are at a level 
above Verilog or VHDL.  There are open source synthesisers, compilers, 
interpreters and simulators (such as Icarus and GHDL).  There are also, 
of course, open source hardware designs (look at www.opencores.org for 
examples).

When it comes to running closed source fpga software in open source 
environments, however, it's a different matter.  Both X and A toolkits 
rely very heavily on open source software.  As far as I can see (and I'm 
sure I'll be corrected if I've got it wrong), Quartus is build around a 
few closed source binaries, a gui, a large collection of open source 
glue such as cygwin, perl, and tcl/tk, and scripts written in these 
languages.  For the binaries doing the hard work, it should make little 
difference which OS they run on.  The infrastructure, written in perl 
and tcl (and perhaps other languages too), Linux or another *nix would 
be a far more natural OS than windows.  About the only part that is 
actually tied to windows is the gui.

What is needed for a more open-source friendly Quartus (and presumably 
the same applies to ISE), is two things.  First, drop the proprietary 
closed-source kit used to run the win32 gui on linux (this is, I 
believe, the main reason why there is no free version of Q on Linux). 
Either re-write the gui using one of the many cross-platform toolkits 
available (such as Qt, GTK, or wxWidgets), or make the gui run with wine 
or winelib on Linux (that would avoid major re-writing).  Secondly, drop 
the requirement for particular distributions, and replace it with a 
simple requirements for minimum versions of the infrastructure like perl 
and tcl.  In these days of virtual machines, it should be a simple 
matter to set up automated testing on a dozen different distributions, 
and if your code works on Red Hat, Suse, Debian, and Ubuntu, then it 
will work on almost anything.

Personally, I don't think there would be any benefit in the critical 
tools themselves being open source, and have no problem with the idea of 
a free version supporting the low-end families and paying for support 
for the high-end families.  I don't do much fpga work at the moment - I 
do mostly embedded software development.  As with most professionals in 
the field, I am happy to pay for quality tools - but I would prefer 
greater choice in how I run these tools.

Article: 117184
Subject: Re: Where is Open Source for FPGA development?
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Mon, 26 Mar 2007 09:19:41 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Mon, 26 Mar 2007 10:48:36 +0200) it happened David Brown
<david@westcontrol.removethisbit.com> wrote in
<4607844a$0$31544$8404b019@news.wineasy.se>:

>What is needed for a more open-source friendly Quartus (and presumably 
>the same applies to ISE), is two things.  First, drop the proprietary 
>closed-source kit used to run the win32 gui on linux (this is, I 
>believe, the main reason why there is no free version of Q on Linux). 
>Either re-write the gui using one of the many cross-platform toolkits 
>available (such as Qt, GTK, or wxWidgets), or make the gui run with wine 
>or winelib on Linux (that would avoid major re-writing).

What are you talking about?
Quatus II 5.1 GUI running in wine-0.9.9 in Linux right now!
And the Linux version of webpack works too.




Article: 117185
Subject: Re: Where is Open Source for FPGA development?
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 26 Mar 2007 10:35:09 +0100
Links: << >>  << T >>  << A >>
<psihodelia@googlemail.com> wrote in message 
news:1174871961.121540.72100@d57g2000hsg.googlegroups.com...
> Many engineers today have Linux on Desktop as main-OS. Many engineers
> today use Open Source products because of their quality, stability,
> and configurability.
>
> Today I see no alternative to use Xilinx or Alteras Web Packs. Both
> are in a very sad state. As Linux or PowerPC user you cannot develop
> your FPGA design with this tools. On x86 or on Windows they are very
> buggy, slow, and unproductive as well.
>
> So, any idea, how can we change this situation? Will we meet the time
> of Open Source development tools for programmable logic devices?
>
I guess if more people donate more of their own time and effort to the FOSS 
effort for FPGAs, the situation might change. I'm curious as to how much 
effort you have contributed. ;-)
Cheers, Syms. 



Article: 117186
Subject: Re: Where is Open Source for FPGA development?
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: 26 Mar 2007 03:14:11 -0700
Links: << >>  << T >>  << A >>
On Mar 26, 3:48 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> psihode...@googlemail.com wrote:
> > Many engineers today have Linux on Desktop as main-OS. Many engineers
> > today use Open Source products because of their quality, stability,
> > and configurability.
>
> Hmm, yes, but your many is still a tiny %.
> Other are more pragmatic: as long as windows does not get in the
> way, they tolerate it.

I had a different impression.
In the ASIC EDA world until a few years ago the Windows market share
was about 0%.
It is a little higher now but most of the tools still do not support
windows.

Of course there are a lot more FPGA designs done than ASIC designs and
the number
of licenses sold/given away for FPGA tools outnumbers the ASIC
licenses by orders of magnitude,
but a lot of the algorithms used in FPGA tools are developed with ASIC
EDA money.
As an example Magma Design Automation paid something like 150
developers having less than a
hundred customers. (Very inaccurate and old numbers, but you get the
point.)

I soubt that the EDA user community is large enough to spin off a
enough developers to get anything useful
done. See for example how hard it is to get a working open source IP
community together and that should be
a lot easier.
Other successfull Open Source projects are either a lot easier than
EDA or have a marge larger user base to
draw developers from.

However what can be done, is the development of additional vendor
independant tools that complement the major
tools as well as replacing parts of the tool chain. One example on the
fringe of EDA is Octave as a replacement for
Matlab. Antoher one is a recent paper on a GI workshop that show how
easy it is to extend the synthesizable
subset of VHDL. They presented a VHDL to VHDL preprocessor that
allowed you to use more constructs in your
synthesizable code than Synopsys supports. Yet another example are
timing diagram editors for documentation.

Smaller projects like these are much more likely to yield high quality
results than aiming for a complete toolchain.
Also, they remain useful once they are not developed actively anymore.
A backend tool would become useless as soon
as development can not match the pace of the introduction of new
architectures.

Kolja Sulimma
(I did EDA research for years)




Article: 117187
Subject: Re: Where is Open Source for FPGA development?
From: David Brown <david@westcontrol.removethisbit.com>
Date: Mon, 26 Mar 2007 12:36:39 +0200
Links: << >>  << T >>  << A >>
Jan Panteltje wrote:
> On a sunny day (Mon, 26 Mar 2007 10:48:36 +0200) it happened David Brown
> <david@westcontrol.removethisbit.com> wrote in
> <4607844a$0$31544$8404b019@news.wineasy.se>:
> 
>> What is needed for a more open-source friendly Quartus (and presumably 
>> the same applies to ISE), is two things.  First, drop the proprietary 
>> closed-source kit used to run the win32 gui on linux (this is, I 
>> believe, the main reason why there is no free version of Q on Linux). 
>> Either re-write the gui using one of the many cross-platform toolkits 
>> available (such as Qt, GTK, or wxWidgets), or make the gui run with wine 
>> or winelib on Linux (that would avoid major re-writing).
> 
> What are you talking about?
> Quatus II 5.1 GUI running in wine-0.9.9 in Linux right now!

I am sure it works (I have not tried it - as I say, I haven't done much 
fpga work for a while), but the only "official" Altera way to run 
Quartus on Linux is the paid version, running on a few specific choices 
of distribution.  Since your experience proves that Quartus runs fine 
under wine, what is needed is for Altera to say so, and to provide 
instructions and relevant install scripts for their web edition.

> And the Linux version of webpack works too.
> 

I have heard that the Xilinx Linux webpack uses the same commercial 
win32 wrapper, and that Xilinx in fact have to pay a royalty fee for 
each Linux webpack that is downloaded.  I don't know whether this is 
fact or rumour - again, I hope someone will correct me if I'm wrong.


Article: 117188
Subject: Small memories in Cyclone
From: "MikeF" <mikefbase-google@yahoo.co.uk>
Date: 26 Mar 2007 04:47:47 -0700
Links: << >>  << T >>  << A >>
Hi

I am about to start on a design that will need a number of smallish
memories. i.e. 8 deep x 16 wide shift registers, small FIFOs etc. I am
looking at the Spartan 3E and Cyclone II/III.

The distributed memories in the Spartan 3E seem like the clincher. Why
would I use a Cyclone and either waste a block RAM or quite a few
Logic Elements when I can use distributed RAM in the S3E? The Cyclone
III just makes it worse with their 9K memory blocks as against the 4K
blocks in the CII.

Any thoughts from the Altera folks on the newsgroup?

Thanks

MikeF


Article: 117189
Subject: Delta Sigma A/D's integrated in FPGA's
From: ray@desinformation.de
Date: 26 Mar 2007 05:23:46 -0700
Links: << >>  << T >>  << A >>
Why don't you FPGA guys put delta sigma A/D's in future devices ?

The good thing about a delta sigma A/D is the resolution/bandwidth
tradeoff selected by the digital post-filter.
And if you already have a >3GBit serdes, you maybe could do a
continuous time delta sigma modulator with similar area, er even
combine it with a serdes.
National has a continuous time delta sigma A/D with 14 Bit at 40MSPS.

Again, the good thing about it would be, that the tradeoff between
resolution / bandwidth can easily be selected by post-filtering the
bitstream.
Resolutions from 6-16Bit's and 200MSPS - 1MSPS seem possible.


Article: 117190
Subject: Re: Austin the Altera Mole
From: "Paul" <pauljbennett@gmail.com>
Date: 26 Mar 2007 06:09:57 -0700
Links: << >>  << T >>  << A >>
Sanjay,

    I totally hear ya on different versions of the tools.  We try to
stick with one version on a project start to finish... for some of our
older projects that have been around a few years, we've got people
running ISE 6-something around here for that very reason.  As for
inference templates changes from version to version - I've only used
the vendor's synthesis tool on smaller hobby projects.  For the larger
stuff here, Synplify seems to be pretty stable in that regard.  I'm
just saying, when starting on a new project, clean slate...  I don't
understand the drive to go one way or the other, because it really
depends upon the application.



On Mar 25, 4:21 am, "fpgabuilder" <fpgabuilder-gro...@yahoo.com>
wrote:
> Paul,
>
> For the same reasons as you spelled out we wanted to migrate from QII
> 6.0 to QII 6.1 unfortunately, the signed multiplier did not get
> inferred correctly in QII 6.1.  I can still remember checking with the
> QII documentation to see if we incorrectly described the logic.  But
> everything was according to the docs on Altera's website.
>
> The point is that it is this kind of unpredictable behavior between
> releases of the tools that give us cold feet when it comes to moving
> an existing project to a new release of the software.
>
> -sanjay
>
>
>
>
>
> > So if you don't care about Stratix III or Cyclone III devices, don't
> > want faster & better compilation results, don't need to interface with
> > a PCB, and aren't hitting any bugs that affect your design, there's no
> > reason for you to move to QII v7.0.  However, the migration experience
> > is fairly painless, and you may find yourself liking some of the new
> > features you can by migrating.- Hide quoted text -
>
> - Show quoted text -



Article: 117191
Subject: Re: Small memories in Cyclone
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 26 Mar 2007 06:16:41 -0700
Links: << >>  << T >>  << A >>
MikeF wrote:

> I am about to start on a design that will need a number of smallish
> memories. i.e. 8 deep x 16 wide shift registers, small FIFOs etc. I am
> looking at the Spartan 3E and Cyclone II/III.
> 
> The distributed memories in the Spartan 3E seem like the clincher. Why
> would I use a Cyclone and either waste a block RAM or quite a few
> Logic Elements when I can use distributed RAM in the S3E?

I would focus on writing and simulating an HDL design first.
The only way I can know for sure if my design fits
a particular device is to prototype the design and try it.

The Spartan 3e has more block RAM than distributed RAM.
If I don't use the block RAM I lose it.
LUTs can be used for anything.

> The Cyclone
> III just makes it worse with their 9K memory blocks as against the 4K
> blocks in the CII.

There is no way to know which is worse until
the design is finished.

    -- Mike Treseler

Article: 117192
Subject: Re: Austin the Altera Mole
From: "Paul Leventis" <paul.leventis@gmail.com>
Date: 26 Mar 2007 06:34:11 -0700
Links: << >>  << T >>  << A >>
> The point is that it is this kind of unpredictable behavior between
> releases of the tools that give us cold feet when it comes to moving
> an existing project to a new release of the software.

Hi Sanjay,

Yes, there are always risks moving between versions of software. We
spend literally months between when we're finished programming a
Quartus II version and when we actually release it.  That time is
spent running tons of tests -- every single old test we have lying
around, plus a bunch of new ones we write to cover new cases.
However, we cannot cover every possible form of input to the tool.
Did you file a bug report on your issue?  Bug reports turn into new
tests that get run with each release, filling holes in our code
coverage.

In your case, was it a relatively small piece of code whose synthesis
changed?  Or was it a complex piece of code?  I don't know if in this
case it was a bug (somebody broke inferencing?) or just a subtle
change in the myriad of choices/trade-offs the synthesis tool must
make.

One approach to reduce the amount of change between releases is to
lock down the version of your synthesis tool -- be it Quartus or a 3rd
party tool.  But you can continue to update your Quartus back-end to
get the latest & greatest P&R, timing, features, etc.  I like to think
the *stability* and overall quality of Quartus does not degrade from
release to release -- in fact, as measured by number of IEs (internal
errors) per compile as reported by users, it has been steadily
improving.

As suggested by yourself and another poster, sometimes the best
approach is to lock down to one version of the software for your
entire design cycle.  We certainly have customers who do this.  When
the family you are designing to is reasonably mature (for example, has
Final timing models), this may be the best solution.  Or you could
take the Microsoft user approach -- wait until the first Service Pack
release when any of the little problems have been shaken out!

Regards,

Paul Leventis
Altera Corp.


Article: 117193
Subject: Re: Where is Open Source for FPGA development?
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: 26 Mar 2007 13:35:21 GMT
Links: << >>  << T >>  << A >>
In news:1174904051.342594.320050@e65g2000hsc.googlegroups.com
timestamped 26 Mar 2007 03:14:11 -0700, Kolja Sulimma
<ksulimma@googlemail.com> posted:
"[..]

[..] Antoher one is a recent paper on a GI workshop that show how
easy it is to extend the synthesizable
subset of VHDL. They presented a VHDL to VHDL preprocessor that
allowed you to use more constructs in your
synthesizable code than Synopsys supports. [..]

[..]

Kolja Sulimma
(I did EDA research for years)"


Hello,

Could you provide more details on this please? How does it compare to
the behavioral VHDL synthesizer advertised in Petru Eles & Krzysztof
Kuchcinski & Zebo Peng, "System Synthesis with VHDL", Kluwer Academic
Publishers, 1998?

Regards,
Colin Paul Gloster

Article: 117194
Subject: Re: Delta Sigma A/D's integrated in FPGA's
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 26 Mar 2007 14:35:22 +0100
Links: << >>  << T >>  << A >>
http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/2275800f3158eabf/fced326c44af23e3?tvc=1&q=adc+analog+group%3Acomp.arch.fpga&hl=en#fced326c44af23e3

<ray@desinformation.de> wrote in message 
news:1174911826.663025.272910@n76g2000hsh.googlegroups.com...
> Why don't you FPGA guys put delta sigma A/D's in future devices ?
>
> The good thing about a delta sigma A/D is the resolution/bandwidth
> tradeoff selected by the digital post-filter.
> And if you already have a >3GBit serdes, you maybe could do a
> continuous time delta sigma modulator with similar area, er even
> combine it with a serdes.
> National has a continuous time delta sigma A/D with 14 Bit at 40MSPS.
>
> Again, the good thing about it would be, that the tradeoff between
> resolution / bandwidth can easily be selected by post-filtering the
> bitstream.
> Resolutions from 6-16Bit's and 200MSPS - 1MSPS seem possible.
> 



Article: 117195
Subject: Re: Small memories in Cyclone
From: "Paul Leventis" <paul.leventis@gmail.com>
Date: 26 Mar 2007 06:52:04 -0700
Links: << >>  << T >>  << A >>
Hi Mike,

This of course depends on how many of these shift registers you have
as compared to other logic in your chip, and whether you're going to
be using all the block rams for another purpose.  "Wasted" blocks are
irrelevant when your design is using 70% of the logic and 30% of the
RAMs in the chip.

You can implement shift registers by using the alt_shift_taps
megafunction in Quartus II.  Assuming these are single-tap shift
registers, you can fit 36 of them per Cyclone II/III M4K/M9K block
RAM.  Or you can choose to implement them in LEs if you'd prefer (by
changing a flag in the megafunction), which may be the correct choice
if your design has spare FFs lying around.  Quartus will automatically
use the LUTs for other functions in your design, so you are not
"wasting" the rest of the LAB unless your design is FF limited.

If you use Spartan-3E, it will take you 36 LCs.  From a silicon area
perspective, a M4K/M9K RAM takes a similar amount of area, so
*archtiecturally* distributed RAM doesn't help in this case -- which
doesn't mean much to you since you can't change the number of RAMs we
choose to put in a chip.

In case this factors into your decision, remember that with Cyclone
III, you can buy a lot more logic / RAMs per $ than you can with an
older 90-nm family.  And you get lower power to boot.  Also, if
performance is a factor at all, Cyclone II/III of significantly higher
performance.

Distributed RAM isn't useless.  There are certain applications where
it makes sense.  But these applications where many small, narrow
independent memories are (a) needed and (b) dominate the logic/ram
utilization are rare.  And in exchange, each logic cell is costing
more silicon area to build -- would you prefer 10% or 20% more logic
cells in your chip or would you prefer distributed RAM?  Different
customers will say different things.

Regards,

Paul Leventis
Altera Corp.


Article: 117196
Subject: Re: Small memories in Cyclone
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 26 Mar 2007 14:22:42 GMT
Links: << >>  << T >>  << A >>
Paul Leventis wrote:

excerpt:

> In case this factors into your decision, remember that with Cyclone
> III, you can buy a lot more logic / RAMs per $ than you can with an
> older 90-nm family.

I thought the Lattice ECP2M series - "an older 90-nm family" - beat out 
the Cyclone III family in "logic / RAMs per $" and had a better 
memory-to-logic ratio and had embedded SERDES and included distributed 
memory.

Will the Cyclone-III price positioning outperform the Lattice offering?

Article: 117197
Subject: Re: Software Management
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 26 Mar 2007 09:10:23 -0700
Links: << >>  << T >>  << A >>
Paul,

I agree,

(this is getting pretty unusual, isn't it?  Fruit basket must have been
spiked with something...)

Locking down a release for a project is just smart engineering
management.  When I ran development groups, each project manager
submitted the tools they were to use, and the tools were all placed
under ECO control.  AT various times I would have QA audit the project,
to be sure we had control of our software.

If something horrible happened, and the tool had to change, at least it
was a structured process, and there was a paper trail to show what,
where, and why.  Additionally, an archive of everything would be made at
the transition point, just in case.

Austin

Article: 117198
Subject: Re: Austin the Altera Mole
From: "fpgabuilder" <fpgabuilder-groups@yahoo.com>
Date: 26 Mar 2007 09:50:02 -0700
Links: << >>  << T >>  << A >>
On Mar 26, 5:09 am, "Paul" <pauljbenn...@gmail.com> wrote:
> Sanjay,
>
>     I totally hear ya on different versions of the tools.  We try to
> stick with one version on a project start to finish... for some of our
> older projects that have been around a few years, we've got people
> running ISE 6-something around here for that very reason.  As for
> inference templates changes from version to version - I've only used
> the vendor's synthesis tool on smaller hobby projects.  For the larger
> stuff here, Synplify seems to be pretty stable in that regard.  I'm
> just saying, when starting on a new project, clean slate...  I don't
> understand the drive to go one way or the other, because it really
> depends upon the application.
>
> On Mar 25, 4:21 am, "fpgabuilder" <fpgabuilder-gro...@yahoo.com>
> wrote:
>
> > Paul,
>
> > For the same reasons as you spelled out we wanted to migrate from QII
> > 6.0 to QII 6.1 unfortunately, the signed multiplier did not get
> > inferred correctly in QII 6.1.  I can still remember checking with the
> > QII documentation to see if we incorrectly described the logic.  But
> > everything was according to the docs on Altera's website.
>
> > The point is that it is this kind of unpredictable behavior between
> > releases of the tools that give us cold feet when it comes to moving
> > an existing project to a new release of the software.
>
> > -sanjay
>
> > > So if you don't care about Stratix III or Cyclone III devices, don't
> > > want faster & better compilation results, don't need to interface with
> > > a PCB, and aren't hitting any bugs that affect your design, there's no
> > > reason for you to move to QII v7.0.  However, the migration experience
> > > is fairly painless, and you may find yourself liking some of the new
> > > features you can by migrating.- Hide quoted text -
>
> > - Show quoted text -

Paul,
I fall in the same camp as you do... i.e. look at the best
architecture for a project.  But lately with a processor inside the
FPGA, we find that the decision to move to a different vendor at the
start of any project gets a bit complicated as the software developers
would also like a say in the decision.

It would be interesting to see how others approach this problem.
Maybe a different thread.

Best,
Sanjay


Article: 117199
Subject: Re: FPGA with 5V and PLCC package
From: Herbert Kleebauer <klee@unibwm.de>
Date: Mon, 26 Mar 2007 18:52:07 +0200
Links: << >>  << T >>  << A >>
msg wrote:
> Herbert Kleebauer wrote:
 
> > 2. Was somebody able to run Viewlogic (DOS version) in a virtual
> >    PC emulation.  The  problem is, the virtual PC must provide
> >    the proper graphics mode, mouse type and support a physical
> >    dongle on the virtual parallel port.
 
> Also, it would be an interesting experiment to try running
> the software on a VMWare MSDOS VM (a no-cost experiment); please
> report the results!

Downloaded Microsoft Virtual PC 2007 and installed it on a 3.4 GHz P4
with Windows XP. Workview runs on a DOS 6.22 installation on the virtual 
PC (the parallel port dongle works) but needs an extra mouse on the serial 
port (the Windows USB mouse is not recognized by Workview). But it's not
usable because it is extremely slow (slower than on a 486), especially the
mouse movements.



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

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

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

Custom Search