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 94625

Article: 94625
Subject: Caution, Rant follows
From: Ray Andraka <ray@andraka.com>
Date: Sat, 14 Jan 2006 21:16:06 -0500
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Ray,
> 
> I know, I know!
> 
> We are really open to any good ideas.

Austin,

For starters, it would help if your hotline folks were up on the current 
cases.  For example, I recently ran across an issue in 7.1sp4 where 
pipeline stages are getting added to my DSP48's by teh implementation 
tools, and causing the hardware to behave differently than functional 
sim (first off, that should be left to synthesis, not PAR).  I opened a 
case for it (case 614397 if you are interested) a bit over a week ago.

The only responses I got (and I had to go to the website to find the 
first after getting the second offering to close the case) was a 
superbly helpful statement that he wasn't aware of any differences in 
the behavior between 6.3 (which works fine) and 7.1, and were there any 
differences between the timing simulations for the two.

I found out asking around inside Xilinx that the 7.1sp4 mapper tries to 
be cute by moving registers in and out of DSP48's, but ignores any 
effects it might have on timing in parallel pipeline paths.  Now, I 
searched high and low through the answers database for anything with 
pipeline register and DSP in it, but couldn't find a relevant answer 
anywhere.  My source inside xilinx asked around and found out about 
answer 22314, which tells how to disable this odd behavior with an 
environment variable (turns out the word pipeline wasn't in the 
keywords, so your search engine didn't turn up this answer record). 
Once again a "known" behavior that took close to a week of my time 
tracking down, and even the hotline help couldn't find a relevant answer.

Perhaps you see this as acceptable (I sure wish I could bill someone for 
all the debug time I have expended this past 6 months chasing down 
problems in the silicon or tools and finding suitable work-arounds), but 
I certainly don't.  The current system is broken when the designer has 
to resort to inside contacts in order to track down problems in his 
design caused by undocumented but known behavior of the silicon or the 
tools.  I can't imagine that I am the only one running into these issues 
with Virtex4 (this one, placement of DSP48s with pre-SP4 7.1 tools, 
problems with the Xilinx DCM NBTI fix circuit, and FIFO16 problems to 
name a few of the big ones that tripped me up).  It wouldn't inflame me 
if it didn't come down to me spending tens or hundreds of hours on each, 
and then hearing "oh, yeah, we knew about that".  I have spent well over 
1/3rd of my time in the past 6 months chasing or correcting issues 
caused by tools or silicon.  That is time that is generally not paid by 
my customers, plus it makes a significant dent in my schedule.

OK, so for a better way.  #1 Listen to the users of your software, and I 
mean all of them, not just your biggest 5 accounts. #2, stop the 
software folks from mucking with the software.  Fix what is broken 
before adding new features, and for Gosh sakes stop the gratuitous 
changes that seem to break everything.  #3, work on the support for the 
software you have.  #4, organize the answers data base, perhaps with a 
pre-filter that asks you which device, version of ISE, and maybe 
synthesis tool you are using so I don't get 1001 answers for ISE4.1 when 
I am trying to use 7.1.  #5, don't just cut off support for an older 
version (eg 6.3sp3, which works better than 7.1 except the timing 
parameters haven't been updated) if the newer version is still loaded 
with fatal bugs.  When I report a problem with 6.3, the only answer that 
is returned is use 7.1 (never mind the fact that 7.1 did not work at all 
until sp4 for any design I ran it on)  #6.  Fix the bugs in a major 
release before committing all your effort to the next major release.  #7 
Listen to your users, some of them do know what they are talking about.

Things like the FIFO16 restrictions need to be in the user manual so 
that the designer is aware of them before he design them in so that he 
can work around the limitations.  Easy to work around if given the 
information.  A real pain the tail to find the problem if you are not 
aware of the limitations, and none too fun to rework the design to work 
within the limitations when you do learn about them.  For known bugs in 
the software, there really should be an errata sheet listing the known 
issues that can trip up a design (like the pipeline register remapping 
or what ever you call it) so that when you run into a problem like this 
you have a prayer of finding an answer record on it.  Maybe all it takes 
is a refinement of the search engine.  I don't know, that isn't my area 
of expertise.  I think the fact that you also didn't post any relevant 
answer records to Brads post that started this should be a flag to you 
showing you that the system isn't working too.

Another suggestion is better testing of your software before you release 
it, not just on the mainstream push the big green button to make a 40 
Mhz design designs either, but some with some handcrafting that are 
pushing the clock capabilities of the devices.  While the compile 
completion times have gotten remarkably good, the quality of results for 
  a pretty well optimized design (one that includes tight floorplanning) 
have fallen off with each major release since 4.1.  I know other users 
have remarked as such here, so I know I am not the only one.  The 
regression testing really does need to include the full spectrum of 
designs, unless Xilinx really is trying to kill off the RLOC as was 
speculated here many years ago.

OK, sorry about the rant (well, not really).  This thread just happened 
to pour vinegar into an open wound, and well, your answer did nothing to 
soothe the pain.

Article: 94626
Subject: Re: Xilinx Virtex-4 BRAM-16 Simulation
From: Ray Andraka <ray@andraka.com>
Date: Sat, 14 Jan 2006 21:33:16 -0500
Links: << >>  << T >>  << A >>
Brad, it is your addressing.  For the wider data widths, the lsbs of the 
address should be held at zero.  You should use bits 14 downto whatever 
is appropriate for the aspect ratio you are using (in your case the 36 
bit should leave the 5 lsbs '0').



Brad Smallridge wrote:

> Thanks for words of encouragement Ray.
> 
> I went back to double check if all the simulation
> and libraries were downloaded and installed. It
> seems as if they are.  All from the download page
> that Xilinx is advertising on the home page right
> now for the 8.i software. Three packages in all,
> the ISE, ModelSim III, and it's library.
> 
> I am still not getting any output from the RAMB16
> p

Article: 94627
Subject: Re: bandpass filter design for ACTEL FPGA
From: Ray Andraka <ray@andraka.com>
Date: Sat, 14 Jan 2006 21:41:32 -0500
Links: << >>  << T >>  << A >>
mughat wrote:

> Anyone have experience with designing band pass filters for ACTEL FPGAs? 
> Tools, appnotes anything is of interest.
> 
> I my project I have to make some DSP on 3 audio signals (100Hz-22Khz). 
> Planing on using the new Fusion mixed-signal FPGA from ACTEL.
> 
> 

You need to design the filter first using some filter design software 
(this will give your the filter architecture and coefficients).  Then 
you can worry about putting into the device.  You don't say much about 
your requirements or environment.  Audio sample rates are much lower 
than what modern FPGAs can be clocked at, so it is perfectly reasonable 
to use a combination of bit serial and time-multiplexed logic to reduce 
the footprint of your filter.

Article: 94628
Subject: Re: FPGA Journal Article
From: Philip Freidin <philip@fliptronics.com>
Date: Sun, 15 Jan 2006 04:08:55 GMT
Links: << >>  << T >>  << A >>
On 12 Jan 2006 12:15:13 -0800, "Kevin Morris" <kevin@techfocusmedia.com> wrote:
>I'm writing a feature article for FPGA Journal (www.fpgajournal.com)
>about FPGAs and the re-birth of the electronics hobbyist.  My theory is
>that electronics as a hobby went through a "dark age" period, maybe
>from the early/mid 1970s until recently becuase of the inaccessibility
>and cost of designing with state-of-the-art technology.  Radio Shack
>shifted their focus from 50-in-1 project kits and hobbyist parts to
>selling toys, cell-phones, and stereo equipment.

I agree that electronics as a hobby is not as vibrant as it has been in
the past, but not on your time line or for your reasons.

My theory is that the decline started no earlier than late 80's and
has not really recovered. But the projects that are now created are
far more complex than those of yester year, but at a level comensurate
with the technology available today.

The decline has little to do with Radio Shack and 50-in-1 kits. While
it is probably true that most electronic hobbyists have at some time
owned and played with these kits, there are probably far more that
had these kits, and after a few hours, they were put away never to be
used again until passed on to some younger cousin. These kits were
way too limited, had fairly poor educational content, and no
direction as to how one might expand, experiment, and learn more.

My theory is that the decline in the late 80's was driven by several
things that started in the early 80's:

- Reasonably cheap personal computers with sufficient software that
  hobbyists that may have become electronic hobbyists, instead became
  software weenies. The open-source movement now extends this to
  colaborative projects that are very challenging, and include the
  opportunity for others to use your work, and to get recognition for
  your contribution. I am not criticising the O-S movement at all
  here, just pointing out that it is an alternative path for
  potential electronic hobbyists.

- Many of the things that electronic hobbyists used to build could be
  purchased complete and working for less than the raw components
  cost. There is not as much fun in building a 7 transistor radio
  that has mediocre reception in a cardboard box, versus a buying a
  walkman for the same price. Other projects just are not possible,
  such as build a CD player or cell phone.

- Many of the components that you might want to buy that are used in
  commercial products were not available to hobbyists.

- Many of the challenges that may have enticed an electronic hobbyists
  are now replaced by toys such as playstations etc.. that consume
  vast amounts of what would have been hobby time. Electronics as a
  hobby requires significant study to be able to do interesting
  projects. 150 channels of TV probably don't help either.

- Mentors are in short supply. I think the pressures of work have
  increased (because electronic work projects are more complex) so
  the pool of mentors is diminishing. Their hair is getting thinner
  and grayer too.

- Specialization. As the electronics profession has grown over the
  last 25 years, the amount of new stuff is such that few if any can
  master (or even be reasonably competent) in multiple sub-fields.
  This affects the mentor pool, and also the breadth of available
  literature that might guide a starting-out electronic hobbyists.
  This was driven home for me about 10 years ago when I met with a
  world renown Verilog expert, who had no clue that a 74LS74 was a
  flipflop!

- Minaturization of packaging makes some products un-useable by
  hobbyists, or requires much higher levels of enthusiasm. Surface
  mount made the older wire-wrap no longer an easy solution for
  projects, as the availability of wire-wrappable sockets is far
  more limited, and the latest packages such as QFN and BGA are
  beyond almost all hobbyists. I am not saying that this kills the
  hobby, but it certainly raises the bar.


>Now, with the emergence of low-cost, high-capability FPGAs, development
>boards, and design software, I see a new age of hobbyist activity
>beginning (as often evidenced in this group).

FPGAs on development boards

   http://www.fpga-faq.org/FPGA_Boards.shtml

go along way to allowing any hobbyist to start playing and
experimenting with FPGAs, HDL, simulation, hardware design and
interfacing to the real world. Best of all, there are many low
priced boards available, and all of the software for the low
end products are available free to anyone with a computer and
an internet connection (and a few gig of disk space).

While this re-enables electronic hobbyists to work with current
technology, and pursue it with tools that are similar to what
professionals are using, I don't think this is going to get
anyone to put down their XBOX-360 and start writing VHDL.

>I'm looking for a few people that would be willing to express views on
>this topic for the article.

This group is full of them. I've been an electronics hobbyists for
over 40 years. Sometimes I get to be paid for it (employment), and
sometimes not.


Cheers,
Philip Freidin



Philip Freidin
Fliptronics

Article: 94629
Subject: Re: FPGA Journal Article
From: spammersarevermin <spammersarevermin@krumpli.com>
Date: Sun, 15 Jan 2006 00:15:14 -0500
Links: << >>  << T >>  << A >>
On 12 Jan 2006 12:15:13 -0800, Kevin Morris blurted:

I don't feel qualified to comment on the dark ages, but in the last
several years have moved from the software side into hardware. I keep
a blog about some of the stuff that I'm doing (www.dtool.com) & read
this group regularly - understanding about 5% of it. I am playing w/ a
Digilant Spartan3 board, & when the Xilinx software doesn't crash, am
making slow progress in understanding how to move from, say a
hardware-based ethernet, to one designed w/ logical tools.

I don' get paid for this stuff - it's just very cool. My wish is for
more tutorials & even more access to free software (Chipscope for more
than 60 days for example), as buying all of the ancillary tools,
chips, hardware, scopes, probes, etc. can get expensive after awhile.

My $.02, Tom

Spamming this account signifies 
your unqualified consent to a free security audit

Article: 94630
Subject: Re: Caution, Rant follows
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sun, 15 Jan 2006 19:33:02 +1300
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
[User feedback that should have almost everyone in Xilinx cringing..]
<snip>
> OK, so for a better way.  #1 Listen to the users of your software, and I 
> mean all of them, not just your biggest 5 accounts. #2, stop the 
> software folks from mucking with the software.  Fix what is broken 
> before adding new features, and for Gosh sakes stop the gratuitous 
> changes that seem to break everything.  #3, work on the support for the 
> software you have.  #4, organize the answers data base, perhaps with a 
> pre-filter that asks you which device, version of ISE, and maybe 
> synthesis tool you are using so I don't get 1001 answers for ISE4.1 when 
> I am trying to use 7.1.  #5, don't just cut off support for an older 
> version (eg 6.3sp3, which works better than 7.1 except the timing 
> parameters haven't been updated) 

Very good point :
Xilinx: So HOW hard is it, to update the timing parameters ?

Actually, SURELY Xilinx do that internally, otherwise HOW do they know
they ARE moving forwards in SW, and not simply being carried
by the silicon ??!

if the newer version is still loaded
> with fatal bugs.  When I report a problem with 6.3, the only answer that 
> is returned is use 7.1 (never mind the fact that 7.1 did not work at all 
> until sp4 for any design I ran it on)  #6.  Fix the bugs in a major 
> release before committing all your effort to the next major release.  #7 
> Listen to your users, some of them do know what they are talking about.

How about #8 : Get the SW writers to actually USE the tools ?!

Some of the failings reported here, are frankly, stunningly stupid.
eg Inverted outputs on CPLDs - I'd really LOVE to hear just how that
flew thru all the supposed regression testing ?.

--Let me guess - they only tested SW, and no one thought to try real 
silicon ?!


> Things like the FIFO16 restrictions need to be in the user manual so 
> that the designer is aware of them before he design them in so that he 
> can work around the limitations.  Easy to work around if given the 
> information.  A real pain the tail to find the problem if you are not 
> aware of the limitations, and none too fun to rework the design to work 
> within the limitations when you do learn about them.  For known bugs in 
> the software, there really should be an errata sheet listing the known 
> issues that can trip up a design (like the pipeline register remapping 
> or what ever you call it) so that when you run into a problem like this 
> you have a prayer of finding an answer record on it.  Maybe all it takes 
> is a refinement of the search engine.  I don't know, that isn't my area 
> of expertise.  I think the fact that you also didn't post any relevant 
> answer records to Brads post that started this should be a flag to you 
> showing you that the system isn't working too.

This is something of a catch 22: To fully document problems, Xilinx must 
first understand them. However, if they understood them, they would be
fixed/eliminated very quickly.
There is a natural vested interest in NOT listing too many bugs in SW.

It is classic large company spin, to appear to give support and 
information, when actually doing neither.


> 
> Another suggestion is better testing of your software before you release 
> it, not just on the mainstream push the big green button to make a 40 
> Mhz design designs either, but some with some handcrafting that are 
> pushing the clock capabilities of the devices. 

I'm sure Ray could give Xilinx some very good 'real world' test cases ?

  While the compile
> completion times have gotten remarkably good, the quality of results for 
>  a pretty well optimized design (one that includes tight floorplanning) 
> have fallen off with each major release since 4.1.  I know other users 
> have remarked as such here, so I know I am not the only one.  The 
> regression testing really does need to include the full spectrum of 
> designs, unless Xilinx really is trying to kill off the RLOC as was 
> speculated here many years ago.
> 
> OK, sorry about the rant (well, not really).  This thread just happened 
> to pour vinegar into an open wound, and well, your answer did nothing to 
> soothe the pain.

-jg


Article: 94631
Subject: Re: Caution, Rant follows
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 15 Jan 2006 01:27:52 -0600
Links: << >>  << T >>  << A >>
>There is a natural vested interest in NOT listing too many bugs in SW.

Not where I come from.

Doug Clark wrote a great paper - "Bugs are Good".  Unfortunately, I
don't think it's available online.

Context is roughly:

  Don't shoot the messenger.  Praise the people who find the problems
  before you tape out.

  Discuss the bugs you find.  Why weren't they found sooner?
  Where are there similar structures that should be examined/probed?

  If you can accurately keep track of bugs, then you can plot bugs
  discovered over time.  When that falls off it's time to ship.


I think it's a culture thing.  It's much better to find bugs sooner.
The trick is to make sure that everybody understands that - management
too.  You need somethingthings like a senior designer standing up in public
and saying thanks to a new hire.

-- 
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: 94632
Subject: Re: DSP soft processors
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sun, 15 Jan 2006 20:40:41 +1300
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> Sudhir.Singh@email.com wrote:
> 
>> Hi folks,
>> are there any DSP soft processor cores for fpgas available. I have done
>> a search and only found 32 bit RISCs but no DSP processor cores.
>> Thanks in advance
>> Sudhir
> 
> 
>  I thought the tool flows supported this now, but via the DSP blocks ?
> -ie rather than a separate 'core', you compile what you want, into
> as many DSP Cells as you need ?
>  A Soft-DSP will never be as fast as a dedicated device, the key
> in FPGA is to spawn DSP in parallel and in HW.
>  Check with Altera, Lattice, Xilinx...

  For a topical update on this, check Xilinx website news on their
purchase of AccelChip.

  As you can see, these newest tool flows somewhat side-step the need for
DSP Cores, per-se.

-jg




Article: 94633
Subject: Re: Caution, Rant follows
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sun, 15 Jan 2006 22:44:55 +1300
Links: << >>  << T >>  << A >>
Hal Murray wrote:

>>There is a natural vested interest in NOT listing too many bugs in SW.
> 
> 
> Not where I come from.
> 
> Doug Clark wrote a great paper - "Bugs are Good".  Unfortunately, I
> don't think it's available online.
> 
> Context is roughly:
> 
>   Don't shoot the messenger.  Praise the people who find the problems
>   before you tape out.
> 
>   Discuss the bugs you find.  Why weren't they found sooner?
>   Where are there similar structures that should be examined/probed?
> 
>   If you can accurately keep track of bugs, then you can plot bugs
>   discovered over time.  When that falls off it's time to ship.
> 
> 
> I think it's a culture thing.  It's much better to find bugs sooner.
> The trick is to make sure that everybody understands that - management
> too.  You need somethingthings like a senior designer standing up in public
> and saying thanks to a new hire.

100% Agree - for a properly-run engineering company.

  However, as companies get more dominated by market-droids, and someone
suggests this info is made more public/user accessible, that's
where you will see the push-back :

  Write your own Dilbert lines here  :
  " Hang on, All these defect reports makes our SW look bad - quality 
was better before"
  " Those defects will only affect very few customers, so why tell everyone
about them ? "

  Xilinx press releases show some of this mindset already : My present
most entertaining favourite is the ISE 8.1i release that says ::

"WebPACK 8.1iís ISE Fmax Technology ... up to 70 percent faster 
performance than competing FPGA products"

[Is this a laundry product, or Engineering SW they are selling ? ]

Sounds great, warm fuzzies all round, until you look for meaning....

- Note, no comparison with EARLIER ISE releases, only with someone 
else's (un-named) offering, and then it's the meanginless "up to" caveat.
  There is another end to this scale as well, which is "down to" - why 
is that never published in these press releases ? :)

-jg



Article: 94634
Subject: Re: Student Pricing Now on our Website
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Sun, 15 Jan 2006 10:15:36 -0000
Links: << >>  << T >>  << A >>
At the moment the only link is a button top right on the root page. Just 
click on that to get back to it. I will try and get it added to the general 
menu in a more appropriate fashon and on most pages but that may need to 
wait for the new website to go live.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development 
Board.
http://www.enterpoint.co.uk


"kd" <kdfake@spam.com> wrote in message 
news:43c9a63a$0$62585$ec3e2dad@news.usenetmonster.com...
> Whats the direct link to this info?
> I cannot find it on your site!
> -- 
> ----------------------------------------------
> Posted with NewsLeecher v3.5 Beta 2
> * Binary Usenet Leeching Made Easy
> * http://www.newsleecher.com/?usenet
> ----------------------------------------------
> 



Article: 94635
Subject: Re: FPGA Altair Advice
From: "logjam" <grant@cmosxray.com>
Date: 15 Jan 2006 05:08:48 -0800
Links: << >>  << T >>  << A >>
I'm interested in these kits Eric.  What else other than the board
would you recomend I get?  Does this board come with things like a VGA
core?  I read on some dev board descriptions that they came with a few
modules ready to use.  Are the WebPack tools good enough?

I love the 96 uncomitted I/O on the dev-board.  This will allow the
Altair's switches and LEDs to be connected without a bunch of logic
other than buffers.  :)  I've got some crazy ideas for a "serial port"
inside the FPGA that emulates a terminal with the VGA and PS2 port, but
I'm not sure how practical that is yet.  ;)

Also on a completely different project, I need some advice.  I'm
building a 176wX110h pixel display using LEDs.  I'm almost half way
through soldering!  ;)  I plan on it being a memory mapped display for
the Altair.  I bought a bunch of LEDs surplus a while back and have to
use them.  Plus, the Altair is all about blinking lights...but I don't
know of an Altair with 17,000+ blinking LEDs.  :)

The project requires 110 shift registers to be loaded every 14ms.  I'm
going to use some dual port SRAM from cypress, which will basically
take care of ALL the Altair's RAM needs!  ;)  Would a good beginning
project be an FPGA which reads from the dual port SRAM and sends the
correct byte to the correct shift register?  Basically a compicated
parallel to serial converter?  An evolution of the project will be
character generation ability (I organized the display as 22x10
characters of 8x11 pixels)

This looks like a good board for the project:
http://www.digilentinc.com/Products/Detail.cfm?Prod=D2FT&Nav1=Products&Nav2=Programmable

Any suggestions on either crazy project would be great to have.  :)


Article: 94636
Subject: Re: what happens in SDR-SDRAM if i exceed tRAS(max)
From: "PeteS" <ps@fleetwoodmobile.com>
Date: 15 Jan 2006 05:14:01 -0800
Links: << >>  << T >>  << A >>
Subhasri krishnan wrote:
> Hi all,
> There is a situtation in my controller when tRAS(max) is exceeded. My
> controller starts to read out from some row but I am not sure exactly
> which one. Does anyone know what row will be opened under this
> situation?
> Thanks
> Subhasri.K

tRAS is defined as
'ACTIVE to PRECHARGE command' in a typical Micron datasheet
(http://download.micron.com/pdf/datasheets/dram/sdram/512MbSDRAM.pdf)

As a row can maintain itself only so long before being refreshed (the
purpose of precharge being part of the refresh system), it can only be
accessed without a precharge for some maxima. If you exceed that
maxima, you will not change the row, you will simply get invalid data.

Bottom line is - meet the tRAS spec.

Note that the datasheet I mention above has full simulation models
freely available at the Micron website:

http://www.micron.com/products/dram/sdram/part.aspx?part=MT48LC64M8A2P-75

Verilog, VHDL, IBIS, HSPICE, Denali and Synopsis are all available.

Cheers

PeteS


Article: 94637
Subject: Re: FPGA Journal Article
From: "Hahnsolo" <coreyhahn@gmail.com>
Date: 15 Jan 2006 07:23:57 -0800
Links: << >>  << T >>  << A >>
Well, I guess I would be one of those "rebirth" hobbyists.  I am
younger and just "discovered" the fpga.  I was under the impression
that things like this were very expensive, but when I see starter kits
for $150, I had to snatch one up and try it out.  For the last 5 months
I have been feverishly programming and learning with Webpack 7.1
implimenting different ideas on codecs, processor cores, and so on.
Now I that I have a handle on whats available and possible on most
platforms I bought my first dev board a couple of days ago.  I can't
wait for sun to open up there sparc cores.  So many ideas so little
time!!

I can't believe I went through my undergraduate education without
trying fpga's out, and my focus on RF and optics was not very close to
VLSI or control.  After 5 months though there are a ton of optics
processing problems that can be sped up with fpgas.  Like I said, can't
wait to start debugging!!

So much to do, so little time...
new Hobbyist


Article: 94638
Subject: Re: ISE 8.1i WebPack available
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 15 Jan 2006 07:37:46 -0800
Links: << >>  << T >>  << A >>
You don't need the DISPLAY :0 for ise project navigator and impact but
you still need it for almost all the other progz (PACE, FPGA editor,
FloorPlanner etc).

Mehdi


Article: 94639
Subject: Re: FPGA Journal Article
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 15 Jan 2006 16:45:09 +0100
Links: << >>  << T >>  << A >>
"Hahnsolo" <coreyhahn@gmail.com> schrieb im Newsbeitrag 
news:1137338637.940229.315040@g49g2000cwa.googlegroups.com...
> Well, I guess I would be one of those "rebirth" hobbyists.  I am
> younger and just "discovered" the fpga.  I was under the impression
> that things like this were very expensive, but when I see starter kits
> for $150, I had to snatch one up and try it out.  For the last 5 months
> I have been feverishly programming and learning with Webpack 7.1
> implimenting different ideas on codecs, processor cores, and so on.
> Now I that I have a handle on whats available and possible on most
> platforms I bought my first dev board a couple of days ago.  I can't
> wait for sun to open up there sparc cores.  So many ideas so little
> time!!
>
> I can't believe I went through my undergraduate education without
> trying fpga's out, and my focus on RF and optics was not very close to
> VLSI or control.  After 5 months though there are a ton of optics
> processing problems that can be sped up with fpgas.  Like I said, can't
> wait to start debugging!!
>
> So much to do, so little time...
> new Hobbyist
>

no need to wait for sun

commercial quality SPARC core and system on chip library is available now

http://www.gaisler.com

you need XC3S400 or larger (better larger) to implement a SPARC based system

-- 
Antti Lukats
http://www.xilant.com



Article: 94640
Subject: Re: Any FPGA with programming info available?
From: Kolja Sulimma <news@sulimma.de>
Date: Sun, 15 Jan 2006 17:26:32 +0100
Links: << >>  << T >>  << A >>
Tobias Weingartner schrieb:
> No, I'm not talking which pins to toggle how fast and when, but is
> there any 600K+ gate (roughly) FPGA available which also gives the
> layout and programming information for their bitstreams/etc?

Xilinx has JBits. It does not give you the bitstream information but it
allows you to quickly modify details of a bitstream on the fly.

Think of it as controlling the FPGA editor by a Java programm.


Kolja Sulimma

Article: 94641
Subject: Re: FPGA Journal Article
From: Ray Andraka <ray@andraka.com>
Date: Sun, 15 Jan 2006 15:58:34 -0500
Links: << >>  << T >>  << A >>

> 
> Hmm, really? ;-) As far as I know the only "pure" hobbyists
> here are Antti and myself, the rest is more or less professional.
> 

There are many of us here who started out as pure hobbyists, but then 
grew our passion into a paying endeavor.  I started out in the mid '70's 
first with dissected radios, tape recorders etc, whatever I could get my 
hands on, with radio shack kits (many of which I heavily modified...one 
that comes to mind was a regulated power supply where the 2N3055 got hot 
enough to melt through the red plastic board/box that soon got a 
heatsink and a darlington pair for more output current and a switch to 
select output voltages).  From there, I started getting into logic. 
Between a 1976 Signetics IC databook (which is still on my bookshelf) 
and several of Lancaster's cookbooks (some of his circuits would never 
get past a critical review, but they were great for learning) I taught 
myself digital design.   Even built a couple of computers based on the 
then brand new 6800 (on an Ohio Scientific board), and then the Z-80 
scratch built on wire-wrap boards before graduating from high school in 
1979.

Like Philip said, I had a mentor (a friend of the family who is an EE 
and was consulting mostly in audio and telephony back in the 60's and 
70's) that gave me much of the motivation to make and improve on the 
projects in Radio Electronics (which I was subscribed to from 1971 to 
1982, I dumped the entire collection when it caused me to exceed my 
weight allowance in a move with the Air Force, Killed me, but I couldn't 
even give them away).

Article: 94642
Subject: Re: FPGA Journal Article
From: ptkwt@aracnet.com (Phil Tomson)
Date: 15 Jan 2006 21:39:16 GMT
Links: << >>  << T >>  << A >>
In article <slrndsgqr4.i5.weingart@irricana.cs.ualberta.ca>,
Tobias Weingartner <weingart@cs.ualberta.ca> wrote:
>Kevin Morris wrote:
>> 
>> Any takers?
>
>Real/Complete programming information would be a very good start to a new
>hobby phase.  But I think that all the FPGA vendors are too scared to give
>out this information.  Come on, xilinx, altera, etc, etc.  What could there
>possibly be so secret in the format for how to program your parts?  :)
>

Indeed.  I don't get it either.  How much can be reverse engineered from a 
bitstream format?  This closedness is a real hindrance to the development of 
an open source eco-system around FPGAs.

Any university open FPGA architectures being developed out there?  While it's 
probably too late in the game for a new FPGA company to enter the race, it's 
possible that one of the smaller, hungier players might be able to 
differentiate themselves by opening up their bitstream formats.

Phil

Article: 94643
Subject: Re: FPGA Journal Article
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 15 Jan 2006 14:16:51 -0800
Links: << >>  << T >>  << A >>
Nostalgia...
I built radios in high-school days, and was a ham operator during
college years. Later, in Sweden, I designed and built power supplies
and sold a hundred of them as a moonlight operation. Then the usual
audio amplifiers and speaker boxes.
Now the interest is rekindled and I play with the design of my
second-generation programmable clock module (1 Hz to 2.5 GHz with,
hopefully, 30 ps jitter). But this also taught me that, for top-notch
performance, you need the help of several friends and experts (software
design, pc-board lay-out, GHz trickery, test instrumentation) and of a
commercial manufacturer. We built a few hundred of the first generation
"X-Pod", and are using them inside the company on many test benches. So
it's more "skunk works" than hobby activity, but still the same fun.
I have toyed with the idea of a storage scope. The digital part in an
FPGA plus external RAM looks easy. But less than 500 MHz sample rate
seems to make it a toy, and at that rate the A/D becomes quite
expensive, and an input attenuator looks forbidding, But there are neat
examples of using the PC for display and control.
Peter Alfke, from home.


Article: 94644
Subject: Re: Directed routing in Xilinx V2PRO.
From: "Jim Wu" <jimwu88NOOOSPAM@yahoo.com>
Date: Sun, 15 Jan 2006 17:19:00 -0500
Links: << >>  << T >>  << A >>
If you have access to ISE 8.1, you can use FPGA_EDITOR to find out which
DIRTs failed.

HTH,
Jim

"Symon" <symon_brewer@hotmail.com> wrote in message
news:43c7d5ac$0$15784$14726298@news.sunsite.dk...
> All,
> I've got some directed routing constraints in my UCF file. After some
recent
> changes I get the following message in the P&R PAR file:-
>
> # of EXACT MODE DIRECTED ROUTING found:14, SUCCESS:9, FAILED:5
>
> Anyone know how to find out which nets are failing? I can't find anything
in
> the report files.
>
> TIA, Syms.
>
>
>



Article: 94645
Subject: Re: Xilinx Virtex-4 BRAM-16 Simulation
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Sun, 15 Jan 2006 14:32:35 -0800
Links: << >>  << T >>  << A >>
OK, well, I think I have my addressing fixed, and the code below
is for a 9 bit ROM, which is what I originally wanted.  It seems to
generate acceptable output, at least for small numbers. I am using
the new ISE 8.i simulator. I will test it with larger values later.

Thanks Ray and Sylvain for taking the time to pick out my mistake.
I should have known.

A number of new questions arise:

1)  Is the code around the "begin" keyword, which maps the inputs
to the primitive RAMB16 (BRAM or Block RAM) acceptable or
is there a more concise/better method?

2)  I initially went to the V4 library guide and found this primitive.
I did not see there the RAMB_Sx_Sy primitives of Spartan yore,
which lead me to believe that they are abandoned in Virtex-4.
The Xilinx Virtex-4 User Guide ( ug070.pdf ) page 133 would
lead one to believe that they are available.  What is the story here?

3) Generally, I would like to transport my future designs between
Spartan3s and Virtex-4 effortlessly.  Are their any tips, ap notes,
or other information out there on how to do this?

4) The INIT_xx => sytax is clumsy.  Especially if I choose
to use the ninth bit.  What alternatives do I have?

5) I have been searching Google for code examples with the words
RAMB16 and std_logic.  Is there any primitive or keyword
specific to Virtex-4 that would further refine my search?

6) I did not see the INIT value on the ISE 8.1 simulation which
I expect to see at time 0.  Is this a glitch in the 8.1 simulator?

Regards,

Brad Smallridge
aivision dot com

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

library UNISIM;
use UNISIM.VComponents.all;

entity bram9p is
 port (
   clkb   :  IN std_logic;
   enb    :  IN std_logic;
   ssrb   :  IN std_logic;
   regceb :  IN std_logic;
   addrb  :  IN std_logic_VECTOR(11 downto 0);
   web    :  IN std_logic;
   doutb  : OUT std_logic_VECTOR( 8 downto 0) );
end bram9p;

architecture Behavioral of bram9p is

   signal addrb15 : std_logic_vector(14 downto 0);
   signal dob32   : std_logic_vector(31 downto 0);
   signal dopb4   : std_logic_vector( 3 downto 0);
   signal web4    : std_logic_vector( 3 downto 0);

begin

   addrb15(14 downto 3) <= addrb;
   addrb15( 2 downto 0) <= "000";
   doutb(7 downto 0)    <= dob32(7 downto 0);
   doutb(8)             <= dopb4(0);

   -- Update all web bits,
   -- otherwise only some addresses will be written.
   web4(0) <= web;
   web4(1) <= web;
   web4(2) <= web;
   web4(3) <= web;

   -- RAMB16: Virtex-4 16k+2k Parity Paramatizable BlockRAM
   -- Xilinx  HDL Language Template version 8.1i
   RAMB16_inst : RAMB16
   generic map (
      DOA_REG => 0, -- Optional output registers on the A port (0 or 1)
      DOB_REG => 0, -- Optional output registers on the B port (0 or 1)
      INIT_A => X"000000000", --  Initial values on A output port
      INIT_B => X"000000001", --  Initial values on B output port
      INVERT_CLK_DOA_REG => FALSE, -- TRUE or FALSE
      INVERT_CLK_DOB_REG => FALSE, -- TRUE or FALSE
      RAM_EXTENSION_A => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
      RAM_EXTENSION_B => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
      READ_WIDTH_A =>  9, -- Valid values are 1,2,4,9,18 or 36
      READ_WIDTH_B =>  9, -- Valid values are 1,2,4,9,18 or 36
      SIM_COLLISION_CHECK => "NONE", --  
"ALL","WARNING_ONLY","GENERATE_X_ONLY,"NONE
      SRVAL_A => X"000000000", --  Port A ouput value upon SSR assertion
      SRVAL_B => X"000000002", --  Port B ouput value upon SSR assertion
      WRITE_MODE_A => "READ_FIRST", --  WRITE_FIRST, READ_FIRST or NO_CHANGE
      WRITE_MODE_B => "READ_FIRST", --  WRITE_FIRST, READ_FIRST or NO_CHANGE
      WRITE_WIDTH_A =>  9, -- 1,2,4,9,18 or 36
      WRITE_WIDTH_B =>  9, -- 1,2,4,9,18 or 36
      -- The following INIT_xx declarations specify the initial contents of 
the RAM
      INIT_00 => 
X"1F1E1D1C1B1A191817161514131211100F0E0D0C0B0A09080706050403020100",
      INIT_01 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_02 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_03 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_04 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_05 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_06 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_07 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_08 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_09 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_0A => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_0B => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_0C => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_0D => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_0E => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_0F => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_10 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_11 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_12 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_13 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_14 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_15 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_16 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_17 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_18 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_19 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_1A => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_1B => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_1C => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_1D => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_1E => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_1F => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_20 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_21 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_22 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_23 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_24 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_25 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_26 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_27 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_28 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_29 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_2A => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_2B => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_2C => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_2D => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_2E => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_2F => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_30 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_31 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_32 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_33 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_34 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_35 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_36 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_37 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_38 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_39 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_3A => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_3B => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_3C => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_3D => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_3E => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_3F => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      -- The next set of INITP_xx are for the parity bits
      INITP_00 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INITP_01 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INITP_02 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INITP_03 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INITP_04 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INITP_05 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INITP_06 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
      INITP_07 => 
X"0000000000000000000000000000000000000000000000000000000000000000")
   port map (
      CASCADEOUTA => open,                  -- 1-bit cascade output
      CASCADEOUTB => open,                  -- 1-bit cascade output
      DOA         => open,                  -- 32-bit A port Data Output
      DOB         => dob32,                 -- 32-bit B port Data Output
      DOPA        => open,                  -- 4-bit  A port Parity Output
      DOPB        => dopb4,                 -- 4-bit  B port Parity Output
      ADDRA       => (others=>'0'),         -- 15-bit A port Address Input
      ADDRB       => addrb15,               -- 15-bit B port Address Input
      CASCADEINA  => '0',                   -- 1-bit cascade A input
      CASCADEINB  => '0',                   -- 1-bit cascade B input
      CLKA        => '0',                   -- Port A Clock
      CLKB        => clkb,                  -- Port B Clock
      DIA         => (others=>'0'),         -- 32-bit A port Data Input
      DIB         => (others=>'0'),         -- 32-bit B port Data Input
      DIPA        => (others=>'0'),         -- 4-bit  A port parity Input
      DIPB        => (others=>'0'),         -- 4-bit  B port parity Input
      ENA         => '0',                   -- 1-bit  A port Enable Input
      ENB         => enb,                   -- 1-bit  B port Enable Input
      REGCEA      => '0',                   -- 1-bit A port register enable 
input
      REGCEB      => regceb,                -- 1-bit B port register enable 
input
      SSRA        => '0',                   -- 1-bit  A port Synchronous 
Set/Reset Input
      SSRB        => ssrb,                  -- 1-bit  B port Synchronous 
Set/Reset Input
      WEA         => "0000",                -- 4-bit  A port Write Enable 
Input
      WEB         => web4 );                -- 4-bit  B port Write Enable 
Input

end Behavioral;




Article: 94646
Subject: Re: best evm for virtex-4 and linux
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Mon, 16 Jan 2006 08:43:36 +1000
Links: << >>  << T >>  << A >>
Hi Clark,

Anonymous wrote:

> That's interesting. So if I have an FX12 part, for example, your suggestion
> is that I run uclinux in a soft core and implement my DSP code in the PPC
> core? This is the opposite of what I had expected.

As Antti says, you could invert your expectation and do the Linux on
MicroBlaze, and an ultra-controller type design on the PPC.  Or better
still, nothing beats FPGA logic for DSP performance.  Why not do your
DSP in hardware, make use of those lovely programmable gates, and do the
control/interface logic in SW on a MicroBlaze.  V4-LX parts are (will
be?) cheaper than FX, for equivalent gate counts.  The PPC does not come
for free.

> What do I give up for ucLinux versus PPC Linux? Speed? Device driver
> support?

MicroBlaze uClinux is slower than PPC Linux, but as the MicroBlaze bus
and memory architecture evolves, we are catching up.

> Also, what's your suggestion for unit control? I imagined a webserver
 interfaced to some type of CGI. Maybe perl scripts or php?

Sure, the default mb-uclinux bulid has a webserver in it, adding CGI
apps is simple.  Someone's ported PHP to uClinux before, but it might be
overkill.  I haven't tried Perl, but I did port a recent Python
interpreter to mb-uclinux - performance was pretty ordinary. Better off
in C, I think.

Feel free to contact me in "commercial mode" to discuss in more detail -
john.williams@petalogix.com

Regards,

John

Article: 94647
Subject: Re: FPGA Journal Article
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 16 Jan 2006 11:57:27 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Nostalgia...
> I built radios in high-school days, and was a ham operator during
> college years. Later, in Sweden, I designed and built power supplies
> and sold a hundred of them as a moonlight operation. Then the usual
> audio amplifiers and speaker boxes.
> Now the interest is rekindled and I play with the design of my
> second-generation programmable clock module (1 Hz to 2.5 GHz with,
> hopefully, 30 ps jitter). 

Digits of precision & granularity ?


But this also taught me that, for top-notch
> performance, you need the help of several friends and experts (software
> design, pc-board lay-out, GHz trickery, test instrumentation) and of a
> commercial manufacturer. 

A tad outside the average hobbiest resource pool ?

We built a few hundred of the first generation
> "X-Pod", and are using them inside the company on many test benches. So
> it's more "skunk works" than hobby activity, but still the same fun.
> I have toyed with the idea of a storage scope. The digital part in an
> FPGA plus external RAM looks easy. But less than 500 MHz sample rate
> seems to make it a toy, and at that rate the A/D becomes quite
> expensive, and an input attenuator looks forbidding, But there are neat
> examples of using the PC for display and control.

Yes, scopes are dominated by things other than the FPGA, so are not
ideal demo-examples.

My favourites would be for Xilinx to do a split
a) Freq Ctr & Signal Generator - Smallest/Cheapest FPGA version

b) Freq Ctr & Signal Generator - Money-no-object version

FreqCtr's can become quite complex - so a series of designs would show 
users more and more, but still have a HW platform that is
i)  FPGA dominated
ii) Clearly ahead of any uC alternative

-jg


Article: 94648
Subject: Re: FPGA Journal Article
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 15 Jan 2006 15:39:52 -0800
Links: << >>  << T >>  << A >>
Jim, beware, you are hitting a hot-button !
Jim Granville wrote:
>> Digits of precision & granularity ?
10 decimal digits fixed-point display, but 2 ppm accuracy.
Above 1 MHz limited by time base accuracy, below 1 MHz by display
(just because we are too lazy to make the display floating point...)
>
> > A tad outside the average hobbiest resource pool ?
I think so.
> >
> Yes, scopes are dominated by things other than the FPGA, so are not
> ideal demo-examples.
Yes and no. For low-performance, most complexity would be in FPGA,
DRAM, and PC.
>
> My favourites would be for Xilinx to do a split
> a) Freq Ctr & Signal Generator - Smallest/Cheapest FPGA version
Wait for the S3Eeval board. It includes a freq.gen design based on my
box. Ken Chapman did the control for both of them (PicoBlaze-based), so
you can be convinced it is good.
But it only goes to 80 MHz (?) and the jitter may be more than 100 ps,
since he has no PLL to clean it up further.
>
> b) Freq Ctr & Signal Generator - Money-no-object version
I am going for 2.5 GHz square wave, 1 Hz resolution, and lowest jitter.
But no arbitrary function, adjustable amplitude or duty cycle. All
those things are possible, but clutter up the design. Maybe there will
also come a USB-controlled derivative that offers more freedom.

Please tell me what people need a frequency counter for. I have thought
of a design for years, including reciprocal counting at low frequency
for high resolution with short capture time. But it died for lack of
interest. We could of course include something in the S3E eval board.
>
> FreqCtr's can become quite complex - so a series of designs would show
> users more and more, but still have a HW platform that is
> i)  FPGA dominated
> ii) Clearly ahead of any uC alternative
The S3E eval board accuracy will be limited by its 50 ppm xtal, and the
resolution might be pushed to almost 1 GHz. Display is no problem @ 2 x
16 digits.
A 20 times more accurate time base would cost <$20 extra.
I warned you, this is a hot button with me.
My thesis project, looong ago, was a frequency counter. It's deep in my
genes.
Peter


Article: 94649
Subject: Re: Don't even get me started on lead,
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Mon, 16 Jan 2006 13:44:52 +1300
Links: << >>  << T >>  << A >>
dp wrote:
> you name it) plan to ruin the European electronics industry (which is
> not

Ahem..  Europe's a major market - it's more than European companies that 
are affected :)

Jeremy



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