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 61450

Article: 61450
Subject: Re: Interesting article about FPGAs
From: "Paul Leventis" <paul.leventis@utoronto.ca>
Date: Sat, 04 Oct 2003 02:52:19 GMT
Links: << >>  << T >>  << A >>
Hal,

Here's my best guess for why an anti-fuse FPGA could have lower dynamic
power (I don't know if this is the case):  If I recall correctly, anti-fuse
FPGAs can do some forms of switching with direct metal-to-metal connection
through anti-fuse vias.  In an SRAM FPGA, all switching must be done through
SRAM-controlled multiplexors & buffers.  The additional switches in a given
route increase the C and (maybe) add more crow-bar current during switching.
Also, many of the transistors in the muxing fabric are off during operation.
So you've got more transistors (higher static power) and more dynamic power.

- Paul



Article: 61451
Subject: Re: Digesting runs of ones or zeros "well"
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 04 Oct 2003 02:54:19 -0000
Links: << >>  << T >>  << A >>
>I overuse the syn_keep attribute and I hate the idea of instantiating
>LUTs.  My Carnot skills aren't exactly used regularly.

Are Carnot skills needed?  I can generally count to 4.  A 4 input LUT
can implement any function of 4 inputs.

-- 
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: 61452
Subject: Re: large integer support in GNUPro for Altera Nios software development
From: maxlim79@hotmail.com (Maxlim)
Date: 3 Oct 2003 20:10:22 -0700
Links: << >>  << T >>  << A >>
"Ken Land" <kland1@neuralog1.com> wrote in message news:<vnqtu2fqaeqhcd@news.supernews.com>...
> I would tackle it one .h file at time.  Do a search and make sure you don't
> already have the required header files, but your compiler search path is not
> including their location.  Then, if you don't have them, start copying them
> over from the working systems.  Or possibly do a search on sourceforge, etc.
> 
> You could also post the particular header filenames here with for better
> help.
> 
> Ken


Thanks a lot, Ken. I tried to copy all header files needed by the
library into nios-gnupro/nios-elf/include folder when the compiler
asking for those files. After I'd done that, a lot of errors appeared.
It seem like the library files for multi-precision arithmetic is not
supported by GNUPro compiler. Is there any other multi-precision
arithmetic library files available for GNUPro compiler?

Article: 61453
Subject: Re: your opinion about Avnet (Silica) VirtexII Pro evaluation board
From: lrj176d02@sneakemail.com (Heng Tan)
Date: 3 Oct 2003 20:39:59 -0700
Links: << >>  << T >>  << A >>
yes, i think so. I am not familiar with spartan. but I wonder there
should be some IP core in it like vertex 2 pro so that you can use
softcore too. This is not a real strong version. I believe it is just
a the basic core of linux which will be no more than hundreds of k(
maybe even less). Since I do not use linux, I never tried to spend too
much time to study this. But as far as I can understand, it is not
even as strong as avmon( the software I had mentioned). I don't think
you can monitor the board on it or use it to do any real job unless
you rebuild it. Basically, it is just a demo.
for the 2nd question, no you don't need to. It support both pci and
pci-x, which means 32-bit is just fine. But you may meet some voltage
problem as i had met. But we can discuss that later when you get the
board and unluckily meet that, too :P
And for my question, do you have any clue how to establish that in
general?? please give me some hints. It really bothers me a lot now.

And by the way, I stupidly used one of my real email address last
time. and I received lot of idiot messages. any solutions to that.
what the hell!!!!!!!!:-(

"Mancini Stephane" <nospam@nospam.nospam> wrote in message news:<pan.2003.10.03.13.20.33.631867@nospam.nospam>...
> Thanks a lot for your responses but I still don't understand some points.
> For example, what do you mean whan you say there's a linux core running on
> the spartan ? Doas it mean that there a soft CPU wich runs linux ?
> 
> About you P.S, it's exactly what we want to do.
> 
> Could you also tell me if the PCI bus is 32 or 64 bits ?
> Do I have to buy a PC with a 64 bit PCI slot ?
> 
> Regards,
> 
> Stephane
> 
> 
> 
> 
> 
> On Tue, 30 Sep 2003 15:22:12 -0700, Heng Tan wrote:
> 
> > Hi,there
> > I received my avnet VirtexII Pro development kit(XC2VP7) this month. I
> > know it is somehow different from the evaluation board(stronger in
> > general). But I guess I can try to give some premitive views. And
> > right now, since I am still a newbie on this board,  the information I
> > gave may not be accurate.
> > 
> > 1.In the flash memory of the development board, there already stores a
> > linux core there, which will run on the spartan(the pci bridge) when
> > power up. you can use a serial cable to connect with a host pc and use
> > a hypertermianl program to watch. The flash also installed some other
> > applications which will help you monitor the board like avmon. I can't
> > provide further details right now since my work are usually done in
> > windows
> > 
> > 2.I already installed the board into a pci slot and used it. So the
> > answer to the second question is yes.( although it took me more than a
> > week to contact avnet engieer and figure out some tedious technique
> > detail. The documment coming with the board is not that helpful.) 
> > There is a tool called PCIutility which can help you to debug the
> > board and download the file. However all these work are finished under
> > the 3rd party driver (jungo or to say windriver). So as far as I know,
> > probably only on windows.
> > 
> > 3.I havn't test the memory speed yet. So I can't tell whether there is
> > a bottleneck yet.( you need to write your own project both hd and sw
> > to contol all types of the memory)
> > 
> > 4. with the pciutility I mentioned above, yes you can program the FPGA
> > through PCI.
> > 
> > 5. you can connect it to a host pc not simply a monitor.
> > 
> > Hope it is helpful to you.
> > 
> > P.S. Do you know whether it is possible to feed input to the FPGA on
> > board from a PC and read output to the PC??  If so, how??  I need to
> > implement an algorithm and now stuck here. I mean write your own API
> > instead of using some tools.
> >

Article: 61454
Subject: Re: ISE 6.1 Dies Out of the Gate
From: soar2morrow@yahoo.com (Tom Seim)
Date: 3 Oct 2003 22:34:44 -0700
Links: << >>  << T >>  << A >>
Marc Guardiani <marc@guardiani.com> wrote in message news:<5T2fb.20355$541.16572@nwrdny02.gnilink.net>...
> What OS are you using? Xilinx dropped NT support with version 5.1i (even 
> though it worked). Now with 6.1i I can't get Impact or Core Generator to 
> run.
>

XP Home. I have since been advised to turn off virus scanning (McAfee
in my case) during installation. I have done this, resulting in mixed
success. Now the project nav starts ok, but if I try to launch coregen
it fails. I have gone thru NUMEROUS uninstalls/installs with 2
different computers running 2000 and XP Home without success. I did an
install on a virgin laptop running XP PRO w/o problems. I am in touch
with tech support and will advise on the outcome.

Tom

Article: 61455
Subject: Re: Graphics rendering revisited
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Sat, 04 Oct 2003 05:51:35 GMT
Links: << >>  << T >>  << A >>
"Jon Elson" <jmelson@artsci.wustl.edu> wrote:

> I guess you are talking about raster-scan displays without a pixel to
pixel
> frame buffer behind it, and not about vector-drawing displays (like an
> oscilloscope in X-Y mode).
>
> Interesting theoretical enterprise, but I really don't see the point.

And you wouldn't outside of a contextual reference frame that allowed you to
understand where/why this might be important.  It's a very narrow field of
application.  Not mainstream at all.


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

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





Article: 61456
Subject: Re: Graphics rendering revisited
From: "Jan" <no_spam_iolo@yucom.be>
Date: Sat, 04 Oct 2003 10:53:00 GMT
Links: << >>  << T >>  << A >>
Martin,

Looked at the spec's of the EDP100. Looking very nice indeed.. So to convert
the HDSDI into DVI you would need a deïnterlacer and a frame rate converter.
Guess that's where your 4 framestores come from. If you don't mind, I'd like
to know how many fieldstores are actually used in the deinterlacer.
Normally, you'd need two stores for doing the frame rate conversion (double
buffered). So that would leave you with 2 stores left to do deinterlacing
which allows for some nice 3field algorithms.

sorry to go off topic with this.. I'm just curious since I'm roughly in the
same business.

regards,
Jan

"Martin Euredjian" <0_0_0_0_@pacbell.net> schreef in bericht
news:d_3fb.8955$N67.802@newssvr27.news.prodigy.com...


>>>>>>  insane quote removed by archive manager



Article: 61457
Subject: Re: Graphics rendering revisited
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Sat, 04 Oct 2003 17:08:11 GMT
Links: << >>  << T >>  << A >>
"Jan" wrote:

> Looked at the spec's of the EDP100. Looking very nice indeed.. So to
convert
> the HDSDI into DVI you would need a deïnterlacer and a frame rate
converter.
...
> If you don't mind, I'd like
> to know how many fieldstores are actually used in the deinterlacer.

I can't get into the internals at that level as some things must remain
proprietary.  I'm sure you understand.

The de-interlacer uses some conventional algorithms and a couple of
not-so-standard techniques.  Keep in mind, this is a monitoring device, and,
as such, it tries very hard to not modify the incoming HD stream too much.
Some de-interlacing techniques produce great looking pictures that are
highly synthetic.  That's OK if you are building a deinterlacer for a system
that will then have to process the image further or for something like home
TV.  Probably no OK for professional use.  At least that's my approach.
Seems to work.


> I'm just curious since I'm roughly in the
> same business.

Can you elaborate?  Privately would be OK, of course.

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

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





Article: 61458
Subject: Reusing code (Altera Quartus II 3.0)
From: "Panic" <panic74@hotmail.com>
Date: Sat, 4 Oct 2003 21:07:20 +0200
Links: << >>  << T >>  << A >>
Hi

I am a relative "n00b" with regard to FPGA-programming,
but I'm currently working on a Rijndael-implementation on
a APEX1A dev.board. And I have run into some problems.

I want to put my top-level design together from several smaller
building blocks, that I want to design, compile, simulate and
"forget". So when I need them later on, I'd like to simply import
them into my design.

The only way I have managed to do this so far, is to copy the design-
files from their original location, and into my new project directory.
And this clearly isn't very efficient or simple.

I know there has to be a simpler and better way, but I haven't benn
able to figure it out yet. So all suggestions would be greatly appreaciated.

-"Panic"






Article: 61459
(removed)


Article: 61460
Subject: Re: Xilinx courses
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Sat, 04 Oct 2003 20:35:08 GMT
Links: << >>  << T >>  << A >>
Maybe so.  Hart to tell at this point.  Certainly the material in the book
would open the door to very interesting and useful discussion of advanced
topics, none of which were explored, some were recited, others skipped over.

I think there are two groups within your company that might need a flame
(not a match) lit under their chairs:  web design and
education/documentation.

The website can be incredibly retarded and just not up to par with what good
website design folks can do today.  Sure, it's expensive to hire these heavy
hitters, but Xilinx can afford it.

I only have one sample of the education group's output and, as you learned,
they didn't put on a good show as far as I am concerned.

I think there are huge gaping holes in the available documentation and
devices are getting increasingly more complex.  I think there's a need to
address this --by experts, not fresh grads-- and it's not being done.

Some of these topics might include floorplanning, design optimization,
timing optimization, FPGA Editor, design flow optimization and automation
(XFLOW, scripting, command-line tricks, etc.).  I'm not talking about being
able to download a document describing the various available timing
constraints, for example, but a practical, in-the-trenches set of docs
treating these topics in order to support designers in both adopting and
succesfully utilizing these devices in an already difficult marketplace.

Within the next few months I'll probably have a need to hire a couple of
FPGA/Embedded guys, and the realization that I can't seem to rely on even
sending them to a manufacturer-provided course in order to enhance their
ability to generate accurate designs that perform well is what triggered
some of my concern.

Still, this is not a Xilinx putdown but rather costructive criticism.  I
love the chips and will probably continue to use them for a long time.  I
have over half a dozen high-performance imaging products in the works and,
at this point, all of them have Xilinx FPGA's in them.


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

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




"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3F7DB8E8.A11339E0@xilinx.com...
> Martin,
>
> I am sorry you had a bad experience.
>
> I will ask about it.  I had heard from others that this particular course
was a
> good one (some of my own staff have taken it), so I am hoping that your
> experience was not the course, but perhaps the instructor (still
unfortunate,
> and not acceptable).
>
> Austin
>
> Martin Euredjian wrote:
>
> > I recently took the "Advanced FPGA Implementation (v6)" Instructor-Led
> > Course and came out of it with a fair bit of dissappointment.  I don't
want
> > to engage in Xilinx-bashing but it bothers me that the course was simply
not
> > worthy of the title it was given.
> >
> > The only reason I might get something out of it will be because I will
pour
> > over the 500 page book on my own and experiment for many, many hours.
The
> > class boiled down to a bunch of slides (a very small subset of the book,
> > maybe 20%) being read out loud with a degree of re-interpretation.  The
labs
> > were based on an obscure design that was not introduced at all.  So, all
you
> > could do in the alloted time was type from the book like a robot and
move
> > on.  No real learning took place there.
> >
> > I took the course because, after a two-year effort --starting from
scratch--
> > to learn FPGA's, I thought that an advanced course taught by an expert
in
> > the field would be a great way to take my skills up a notch or two.  I
> > needed to get to that proverbial last few percent and, frankly, I also
felt
> > stuck with regards to timing optimization, floorplanning and other
advanced
> > areas.  I thought that an "advanced" course would be taught by a peer
who'd
> > offer the sort of insight that only comes from significant experience in
the
> > field and, yes, inside information.  That is certainly not what
happened.  I
> > can read slides just as well as the next guy.  I don't need to pay
$1,000,
> > travel and burn two days' work to endure that experience.
> >
> > So, I wonder.  Was this a fluke?  Are the other coursed different,
better,
> > worst?  Are Altera's courses better?  It seems that Xilinx contracts out
the
> > trainig to a third party (a company called "Technically Speaking".  I
heard
> > that Altera chooses to use insiders.  Is this true?  Does it make a
> > difference?
> >
> > Thanks,
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Martin Euredjian
> >
> > To send private email:
> > 0_0_0_0_@pacbell.net
> > where
> > "0_0_0_0_"  =  "martineu"
>



Article: 61461
Subject: Re: Xilinx courses
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Sat, 04 Oct 2003 20:45:51 GMT
Links: << >>  << T >>  << A >>
Well, I think there's a very important distinction that needs to be
understood.  The "intro" or "beginner" classes can probably be taught by
just about anyone who passes the cold mirror test and is a decent teacher
(although my preference would be to have an experienced individual instead).
However, the minute you characterize a class as "Advanced" you better get a
guy who's had some skin in the game for a while and can truly shed some
light on some of the dark corners of these technologies.

I think all of you guys (meaning FPGA companies) have had it good.
Engineers bust their butt's digging and experimenting and figuring things
out...digging for information that you should be providing.  I hope things
change before we get to the 100 million gate devices, 'cause the real cost
of designing with these chips is being borne by the OEMs that pay for these
individuals to (through no fault of their own) put a lot more hours into a
project than might be required with a higher quality of documentation.


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

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




"Jesse Kempa" <kempaj@yahoo.com> wrote in message
news:95776079.0310031106.71c90277@posting.google.com...
> > So, I wonder.  Was this a fluke?  Are the other coursed different,
better,
> > worst?  Are Altera's courses better?  It seems that Xilinx contracts out
the
> > trainig to a third party (a company called "Technically Speaking".  I
heard
> > that Altera chooses to use insiders.  Is this true?  Does it make a
> > difference?
>
> To answer your question about Altera: Yes, we do have a dedicated
> training department with teachers who do the classes at customer
> sites. I understand that our distributor Arrow also leads traning
> events. For special workshops and things like that (such as the SOPC
> World events going on now or other internal training events), other
> Altera employees specializing in that area may present. Occasionally
> we have had third parties present *on their specific product*, such as
> those who do synthesis tools.
>
> Here's a link to the Altera Training homepage:
> https://buy.altera.com/etraining/etraining.asp
>
> Hope this helps,
>
> Jesse Kempa
> Altera Corp.
> jkempa at altera dot com



Article: 61462
Subject: Re: Interesting article about FPGAs
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Sat, 04 Oct 2003 21:06:59 GMT
Links: << >>  << T >>  << A >>
There's one thing Zeidman mentions that I feel very strongly about.  In
fact, I've been repeating a phrase very similar to the one he used in the
article for about four years now:  WE NEED BETTER TOOLS.

I sincerely think that FPGA manufacturers need to figure out a way to get
out of the tool business and pour their resources into making better chips.
Open it up to the masses.  The first company to do that is bound to take a
big huge bite out of the other's market share simply because of all the
tools that will be offered by the engineering community.  There's probably a
ton of very capably and creative guys out there who are ready, eager and
able to create wonderful new --and very powerful-- tools with which to craft
designs.  Instead, we are gang-chained to the vision and approach offered by
the vendors.

Well meaning as they might be, I doubt that any real progress will come out
of their shops.  Just incremental improvements, but that's it.  For example:
Why is it that I can't use a farm of twenty PC's to compile a complex design
quckly?

When your very survival as a business is predicated upon how well your
product performs in a free market, the best tools tend to float to the top
and others fizzle.  No FPGA manufacturer's survival, at the current stage of
things, depends on the quality of their tools.  As long as they are adequate
engineers make them work.  What us end-users want are the chips, so we
put-up with whatever we are forced to use in order to put the chips on our
boards.  If a better tool appeared we'd probably drop the current offerings
in a nanosecond.


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

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






"jakab tanko" <jtanko@ics-ltd.com> wrote in message
news:bljsjs$4me$1@news.storm.ca...
> A good read for anyoane interested in FPGA
> http://www.embedded.com/showArticle.jhtml?articleID=15201141
> ---
> jakab
>
>



Article: 61463
Subject: Re: Digesting runs of ones or zeros "well"
From: johnhandwork@mail.com (John_H)
Date: 4 Oct 2003 14:16:35 -0700
Links: << >>  << T >>  << A >>
hmurray@suespammers.org (Hal Murray) wrote in message news:<vnsdiro5e8e272@corp.supernews.com>...
> >I overuse the syn_keep attribute and I hate the idea of instantiating
> >LUTs.  My Carnot skills aren't exactly used regularly.
> 
> Are Carnot skills needed?  I can generally count to 4.  A 4 input LUT
> can implement any function of 4 inputs.

Do you realize how patronizing your response was?

Please, quickly give the appropriate INIT for a LUT4 where the desired
output is

   &(in[3:1]^~in[2:0])

Since you can count to 4, this should be simple.
Can you guarantee that other engineers looking at your code later will
understand what you're trying to do?

With Regards,
John_H

Article: 61464
Subject: Re: Digesting runs of ones or zeros "well"
From: johnhandwork@mail.com (John_H)
Date: 4 Oct 2003 14:34:27 -0700
Links: << >>  << T >>  << A >>
"Vinh Pham" <a@a.a> wrote in message news:<XBnfb.23230$Ak3.11431@twister.socal.rr.com>...
 
> But something is nagging me.  Can't your xnor/and scheme be implemented in
> two levels of LUTs without the need of a MUXF5?  I must be missing
> something, or maybe the problem is the synthesizer isn't mapping it that
> way?
> 
> The first level LUTs would implement (output = (bit0 xnor bit1) and (bit1
> xnor bit2)).  You'd have four LUTs in the first level, then the second level
> LUT would AND all of them together.

The implementation can, indeed, be as you imagine.  No nagging
necessary.  Your earlier pseudocode did just what you're suggesting
here.  One of the reasons I went with the MUXF5 was that the primitive
doesn't need the syn_keeps that I use to coerce the synthesis into
thinking how I want; a LUT savings is nice though at a slight cost in
delay if I want the combinatorial output.  But your discussion makes
me wonder if the Xilinx AND3 primitive will work just as well.  I'll
test it out when I get back to work.  Comparing the implementations
below, the only advantage to "mine" is one fewer LUT.

Maybe the synthesizer will let this stay.  I don't have to define
intermediate variables to syn_keep and I don't need nested loops. 
Since I don't need to use the xnors, I don't even need to comment the
code any more than usual.

generate
  for( h=0; h<8; h=h+1 )
  begin : run
    AND4 y ( .O(yours[h])
           , .I0( bytesPlus1[h*8+2:h*8+1] == bytesPlus1[h*8+1:h*8+0] )
           , .I1( bytesPlus1[h*8+4:h*8+3] == bytesPlus1[h*8+3:h*8+2] )
           , .I2( bytesPlus1[h*8+6:h*8+5] == bytesPlus1[h*8+5:h*8+4] )
           , .I3( bytesPlus1[h*8+8:h*8+7] == bytesPlus1[h*8+7:h*8+6] )
);`
    AND3 m ( .O(mine[h]),
           , .I0( bytesPlus1[h*8+3:h*8+1] == bytesPlus1[h*8+2:h*8+0] )
           , .I1( bytesPlus1[h*8+6:h*8+4] == bytesPlus1[h*8+5:h*8+3] )
           , .I2( bytesPlus1[h*8+8:h*8+7] == bytesPlus1[h*8+7:h*8+6] )
);`
  end
endgenerate

Thanks for keeping me thinking.
- John_H

Article: 61465
Subject: Re: newbie to FPGA
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Sat, 04 Oct 2003 22:07:26 GMT
Links: << >>  << T >>  << A >>
Where are you coming from?  Are you a software or hardware guy?  Hobby or
professional use?

Some useful books/references (sorry, I'm Xilinx/Verilog-centric):

Real World FPGA Design with Verilog by Ken Coffman
Verilog Designers Library by Bob Zeidman
Verilog HDL Synthesis by Bhasker
Verilog HDL Primer by Bhasker

If you can find it in the Xilinx website: "Programmable Logic Design
Quickstart Handbook"

The Xilinx education portal can be useful while getting started.
http://www.xilinx.com/univ/

Get a simply dev board, like the Avnet Virtex II eval board.  Spend cubic
hours playing with it.

Read the data book for the device you are using.

Print out a pile of application notes and make sure you understand them on
paper.  Then, if your board will support it, try to implement.

The subject is wide and deep.  I'd recommend getting a real tangible sense
of what it is all about before considering taking any classes (if that's
something you are considering).

One of the toughest things to understand is that logically correct code (no
bugs from a software standpoint) is not necessarily equal to a working
device.

Pick a simple project and try your hand at it.  Start with something as
simple as sending the output of an eight bit counter to a set of LED's.
Then, using the same design, you might want to explore clocking and clock
synthesis options.  You might want to then move on to using parts of the
same design to also create something like a pulse-width-modulator.  These
are just some ideas.

One bit of advice probably worth a ton:  Don't even bother with chips until
you know your simulator intimately.  In fact, don't even buy a dev board
until you've explored creating and simulating a bunch of little designs.  As
your designs get larger the realities of current technology are that you'll
need to rely on simulation in order to get any productivity out of the
process (as well as good design verification, etc.).

These are just a few random points.  There's a lot more others can
contribute.


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

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




"Robert Monsen" <postmaster@BulkingPro.com> wrote in message
news:bI1eb.631002$YN5.453735@sccrnsc01...
> Looking for useful books, articles, and development kits for FPGA
> development, and perhaps some war stories about coming up to speed on
these.
>
> TIA
>
> Regards,
>   Bob Monsen
>
>
>



Article: 61466
Subject: Re: Xilinx courses
From: "Theron Hicks (Terry)" <hicksthe@egr.msu.edu>
Date: Sat, 04 Oct 2003 19:27:49 -0400
Links: << >>  << T >>  << A >>
I agree with Martin!  I can't speak for the classes, but the rest is definitely
true.  I hope someone at Xilinx is listening.  There is no doubt (at least in my
mind) that Xilinx has some great FPGAs, etc.  The software seems to be fairly
well done, although it could use some improvement.  The area of improvement is
in simple, useable documentation.  If I need to check three or for different
areas for a full picture of what it taakes to get a job done, can you at least
create a link between the areas.  Xilinx could save a bundle in tech support, if
they would just improve the documentation.  It might even get them a few more
customers.  It generally is not a good idea to PO the customer.  (Usually Xilinx
does not do that.)

Theron Hicks


Martin Euredjian wrote:

> Maybe so.  Hart to tell at this point.  Certainly the material in the book
> would open the door to very interesting and useful discussion of advanced
> topics, none of which were explored, some were recited, others skipped over.
>
> I think there are two groups within your company that might need a flame
> (not a match) lit under their chairs:  web design and
> education/documentation.
>
> The website can be incredibly retarded and just not up to par with what good
> website design folks can do today.  Sure, it's expensive to hire these heavy
> hitters, but Xilinx can afford it.
>
> I only have one sample of the education group's output and, as you learned,
> they didn't put on a good show as far as I am concerned.
>
> I think there are huge gaping holes in the available documentation and
> devices are getting increasingly more complex.  I think there's a need to
> address this --by experts, not fresh grads-- and it's not being done.
>
> Some of these topics might include floorplanning, design optimization,
> timing optimization, FPGA Editor, design flow optimization and automation
> (XFLOW, scripting, command-line tricks, etc.).  I'm not talking about being
> able to download a document describing the various available timing
> constraints, for example, but a practical, in-the-trenches set of docs
> treating these topics in order to support designers in both adopting and
> succesfully utilizing these devices in an already difficult marketplace.
>
> Within the next few months I'll probably have a need to hire a couple of
> FPGA/Embedded guys, and the realization that I can't seem to rely on even
> sending them to a manufacturer-provided course in order to enhance their
> ability to generate accurate designs that perform well is what triggered
> some of my concern.
>
> Still, this is not a Xilinx putdown but rather costructive criticism.  I
> love the chips and will probably continue to use them for a long time.  I
> have over half a dozen high-performance imaging products in the works and,
> at this point, all of them have Xilinx FPGA's in them.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_"  =  "martineu"
>
> "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
> news:3F7DB8E8.A11339E0@xilinx.com...
> > Martin,
> >
> > I am sorry you had a bad experience.
> >
> > I will ask about it.  I had heard from others that this particular course
> was a
> > good one (some of my own staff have taken it), so I am hoping that your
> > experience was not the course, but perhaps the instructor (still
> unfortunate,
> > and not acceptable).
> >
> > Austin
> >
> > Martin Euredjian wrote:
> >
> > > I recently took the "Advanced FPGA Implementation (v6)" Instructor-Led
> > > Course and came out of it with a fair bit of dissappointment.  I don't
> want
> > > to engage in Xilinx-bashing but it bothers me that the course was simply
> not
> > > worthy of the title it was given.
> > >
> > > The only reason I might get something out of it will be because I will
> pour
> > > over the 500 page book on my own and experiment for many, many hours.
> The
> > > class boiled down to a bunch of slides (a very small subset of the book,
> > > maybe 20%) being read out loud with a degree of re-interpretation.  The
> labs
> > > were based on an obscure design that was not introduced at all.  So, all
> you
> > > could do in the alloted time was type from the book like a robot and
> move
> > > on.  No real learning took place there.
> > >
> > > I took the course because, after a two-year effort --starting from
> scratch--
> > > to learn FPGA's, I thought that an advanced course taught by an expert
> in
> > > the field would be a great way to take my skills up a notch or two.  I
> > > needed to get to that proverbial last few percent and, frankly, I also
> felt
> > > stuck with regards to timing optimization, floorplanning and other
> advanced
> > > areas.  I thought that an "advanced" course would be taught by a peer
> who'd
> > > offer the sort of insight that only comes from significant experience in
> the
> > > field and, yes, inside information.  That is certainly not what
> happened.  I
> > > can read slides just as well as the next guy.  I don't need to pay
> $1,000,
> > > travel and burn two days' work to endure that experience.
> > >
> > > So, I wonder.  Was this a fluke?  Are the other coursed different,
> better,
> > > worst?  Are Altera's courses better?  It seems that Xilinx contracts out
> the
> > > trainig to a third party (a company called "Technically Speaking".  I
> heard
> > > that Altera chooses to use insiders.  Is this true?  Does it make a
> > > difference?
> > >
> > > Thanks,
> > >
> > > --
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Martin Euredjian
> > >
> > > To send private email:
> > > 0_0_0_0_@pacbell.net
> > > where
> > > "0_0_0_0_"  =  "martineu"
> >


Article: 61467
Subject: Re: LVDS_25_DCI : Top Ten List
From: brimdavis@aol.com (Brian Davis)
Date: 4 Oct 2003 20:00:49 -0700
Links: << >>  << T >>  << A >>
Austin,

>
>First, I checked the IBIS model in Hyperlynx v7, and it works fine.
>

 That's good news; was that a coupled-line simulation in BoardSim
of a fast driver whacking a LVDS_25_DCI input? Or, an uncoupled
LineSim model with a V2 for both driver and receiver?

 I don't currently have access to Hyperlynx or the problematic 
design files (previous employer), but as I recall it was v7-beta
with which I had encountered problems.

>
>Next, the driver for LVDS is required to have a 100 ohm drive impedance.  If
>you use a device that does not comply to this, then you most definitely can
>and will get reflections shot back to the input.
>
>I can not comment on parts that do not meet the LVDS specifications
>when connected to the FPGA:  that requires some engineering (as always).
>

 That's quite a stretch: blaming the hypothetical faults of the
driver for not correcting the known sins of the receiver...

 Please re-read my original post, and notice that when I mentioned
the impact of the large C_COMP values in the presence of a high
speed driver, I used the phrase "requires external back termination 
and/or input matching".

 Firstly:

    Yes, a perfect 100 ohm transmission line back terminated with
  a perfect 100 ohm source impedance can completely absorb the
  large reflection generated by a highly capacitive input.

    Personally, I prefer not to generate (or propagate) such massive
  ringbacks in the first place.


 Secondly:

    To the best of my recollection, the output impedance specified
  by the original LVDS spec was fairly broad- in the presence of a 
  50%-60% ringback, another 40% re-reflection can be significant.


 Thirdly:

    Although the original LVDS specification did not directly
  specify a max Cin value, newer specifications such as
  HyperTransport do; for example, HyperTransport requires a 
  maximum 2pf (single-ended) Cin for receivers rated > 800 Mbps.


 Fourthly:

    Left uncompensated, the reflections created by a large input 
  capacitance can render the part useless for multidrop topologies.
  The back propagation of the reflection makes the signal on the
  line unusable except at the die input ( ignoring here any
  reflections off any mid-stream taps, which would be just as bad.)
  
    Before you attack a multidrop system as being a special case,
  let me point out that the simple act of probing the line will
  create a multidrop system out of a point to point link.
  
    Also, in most high speed systems, there is a need to monitor
  the link in some fashion, either as part of a system jitter/skew
  or setup/hold verification, or perhaps a non-intrusive signal
  tap for operational monitoring.

    This is often done by placing a passive resistive coupler
  in-line with the signal, or perhaps probe pads for one of the
  low-loading differential active probes.

    If the tap is placed close to the highly capacitive receiver
  input, the ringback can leave the differential signal in limbo
  at the probe point ( both inputs  within the differential Vih/Vil
  hysteresis switching threshold ) until the reflected pulse has 
  passed; if you place it farther up the line, the reflection can
  re-clock the probe, or interfere with the next incoming bit.


  Fifthly:

    You seem to be suffering from a bad case of input capacitance
  denial here- admit that the V2 LVDS inputs are far from perfect
  for 840 Mbps operation, and put that energy to use identifying 
  the problem to your customers, and explaining how to work around
  it, instead of propping up your straw men.

    At no point have I claimed that the V2 inputs are unusable,
  but only that, in the presence of high speed drivers, extra
  engineering effort needs to be expended to both understand the
  impact of the V2 input capacitance on the interconnect, and
  find a work-around that is appropriate for the design at hand.

>
>I have received back confirmation that the issues are being worked on from
>the support group, and I also notified the apps folks about some kind of app
>note for use of the LVDS DCI feature, since it is not as clean as the
>internal solution (in Virtex II Pro).
>

  Might I suggest splitting that into two app notes: one explaining
the various DCI problems in general (they affect more than just the
LVDS_25_DCI standard), and another for the particular quirks of high
speed differential signaling with a V2.

>
>Not ignored at all.....
>

 Where did I say that?
 
 However, since you bring it up, I might point out that the wheels
of documentation update at Xilinx seem to grind quite slowly - what
prompted me to write up my original post was noticing last week,
5-6 months after informing Xilinx of the DCI power problem, that
Answer Record 15633 STILL had that worthless 62.5 mW number with
no mention of the ~200 mW per bank VRP/VRN overhead.


Brian


Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F7DA078.521C7B51@xilinx.com>...
> Brian,
> 
> First, I checked the IBIS model in Hyperlynx v7, and it works fine.
> 
> Next, the driver for LVDS is required to have a 100 ohm drive impedance.  If
> you use a device that does not comply to this, then you most definitely can
> and will get reflections shot back to the input.
> 
> I can not comment on parts that do not meet the LVDS specifications when
> connected to the FPGA:  that requires some engineering (as always).
> 
> I have received back confirmation that the issues are being worked on from
> the support group, and I also notified the apps folks about some kind of app
> note for use of the LVDS DCI feature, since it is not as clean as the
> internal solution (in Virtex II Pro).
> 
> Not ignored at all.....
> 
> Austin
> 
> Brian Davis wrote:
>

Article: 61468
Subject: Re: Interesting article about FPGAs
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sun, 05 Oct 2003 16:07:40 +1300
Links: << >>  << T >>  << A >>
Martin Euredjian wrote:
> 
> There's one thing Zeidman mentions that I feel very strongly about.  In
> fact, I've been repeating a phrase very similar to the one he used in the
> article for about four years now:  WE NEED BETTER TOOLS.
> 
> I sincerely think that FPGA manufacturers need to figure out a way to get
> out of the tool business and pour their resources into making better chips.
> Open it up to the masses.  The first company to do that is bound to take a
> big huge bite out of the other's market share simply because of all the
> tools that will be offered by the engineering community.  There's probably a
> ton of very capably and creative guys out there who are ready, eager and
> able to create wonderful new --and very powerful-- tools with which to craft
> designs.  Instead, we are gang-chained to the vision and approach offered by
> the vendors.
> 
> Well meaning as they might be, I doubt that any real progress will come out
> of their shops.  Just incremental improvements, but that's it.  For example:
> Why is it that I can't use a farm of twenty PC's to compile a complex design
> quckly?
> 
> When your very survival as a business is predicated upon how well your
> product performs in a free market, the best tools tend to float to the top
> and others fizzle.  No FPGA manufacturer's survival, at the current stage of
> things, depends on the quality of their tools.  As long as they are adequate
> engineers make them work.  

and if they are in-adequate, engineers choose another vendor - so FPGA
vendors
are actually VERY dependant on tool quality.

> What us end-users want are the chips, so we
> put-up with whatever we are forced to use in order to put the chips on our
> boards.  If a better tool appeared we'd probably drop the current offerings
> in a nanosecond.

 It depends very much where in the tool chain you mean.
 For front end, silicon independant compilers/simulators, then there is
scope for
any tool chain to create a connectivity file.
 What you need here is enough competent designers, with enough spare
time....

 For back end tools, and some IP generators, that have to map closely to 
the silicon, then it is not practical to 3rd party that. Tools would
come
out MUCH later, or the silicon would have to 'freeze' features.

 If there are features you want to see, then talk with the FPGA
vendors....

-jg

Article: 61469
Subject: Re: Digesting runs of ones or zeros "well"
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 05 Oct 2003 04:13:06 -0000
Links: << >>  << T >>  << A >>
>Do you realize how patronizing your response was?
>
>Please, quickly give the appropriate INIT for a LUT4 where the desired
>output is
>
>   &(in[3:1]^~in[2:0])
>
>Since you can count to 4, this should be simple.
>Can you guarantee that other engineers looking at your code later will
>understand what you're trying to do?

Sorry.  I wasn't trying to be an asshole.

I thought you were into trying to partitioning logic into LUTs in some
sneaky way.

I assumed software is smart enough to compute an INIT string
from a logic equation.  The old Xilinx tools could do that for
3000 series parts.  Has that fallen through the cracks with the
newer software?

-- 
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: 61470
Subject: Re: Interesting article about FPGAs
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Sun, 05 Oct 2003 05:09:39 GMT
Links: << >>  << T >>  << A >>
"Jim Granville" wrote:

> and if they are in-adequate, engineers choose another vendor - so FPGA
> vendors are actually VERY dependant on tool quality.

I don't think you got my point.  Tools today are adequate.  And that's it.
Without competition the rate of progress is slow.  So everyone deals with it
and life goes on.  But, you only have one choice per vendor.  So, as long as
the pain/results threshold is on the correct side of the scale, vendors are
safe and few are going to switch chips and redo complete designs just 'cause
of the tools.  In some companies managers would let an engineer pop a blood
vessel before incurring the additional cost of a redesign just 'cause the
FPGA guy is complaining.  If there was real competition things would be
different.

Take hierarchical floorplanning, for example.  Badly needed.  Nowhere in
sight.
Or more intelligent routers.
Or RPM's that contain more than just placement.
How about parallel processing (network-based, bunch of cheap computers) to
speed up compile runs that take too long?
How about better design entry environments (recent thread about editors is
one example).
Or better documentation.
Etc., etc.

Take something like Xilinx's Incremental flow.  Sounds great, but, if you
instantiate a module more than once you can't use that approach on it.  Why?
And, depending on how which documents you read, it doesn't work with
submodules in a hierarchy, only modules instantiated in the top level.  If
this is the case, why?  I have a fair degree of certainty that an
independent developer would not take this approach, cause the competition
would tear them to shreads.

An open market and real competition would no doubt result in a quantum leap
in FPGA design tool quality.  I have no doubts about this.  The problem is
that the critical bits of info are not available for anyone to even attempt
to generate their own bit files.

Compare the FPGA world to the embedded/C world.  Most microcontroller
manufacturers' compilers stink.  There are a number of great compilers and
design environments out there available from various companies.  Some are
wonderful.  Some are not.  Others are free.  And, of course, there are those
that are too expensive.  But, you have choices, and companies dedicated to
that small segment of the business have proven that they can do a better job
than the chip manufacturers.


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

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



Article: 61471
Subject: Re: Interesting article about FPGAs
From: soar2morrow@yahoo.com (Tom Seim)
Date: 4 Oct 2003 23:18:31 -0700
Links: << >>  << T >>  << A >>
Boy, how long have you been in the business? The tools these days are
excellent. That's not to say they can't be improved, because they can.
I recall hand routing fpga designs and thinking I was in 7th heaven.
But, then, I have done designs with hand drawn schematics and
wire-wrapped TTL logic (I had a drafting board & machine until a
couple of years ago).

Article: 61472
Subject: Re: Interesting article about FPGAs
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Sun, 05 Oct 2003 07:46:15 GMT
Links: << >>  << T >>  << A >>
20+ years.  I go back to hand-drawn schematics and wire-wrapped boards as
well.  Had lots of fun designing boards the size of pizza boxes with loads
of TTL chips.

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

-Martin


"Tom Seim" <soar2morrow@yahoo.com> wrote in message
news:6c71b322.0310042218.5ca0dfba@posting.google.com...
> Boy, how long have you been in the business? The tools these days are
> excellent. That's not to say they can't be improved, because they can.
> I recall hand routing fpga designs and thinking I was in 7th heaven.
> But, then, I have done designs with hand drawn schematics and
> wire-wrapped TTL logic (I had a drafting board & machine until a
> couple of years ago).



Article: 61473
Subject: Re: Quartus II tutorial vs the real world
From: "Nial Stewart" <nial@spamno.nialstewart.co.uk>
Date: Sun, 5 Oct 2003 12:05:50 +0100
Links: << >>  << T >>  << A >>
crob <crob714@yahoo.com> wrote in message
news:cb769f6b.0310031119.75684510@posting.google.com...
> Make sure all unused pins are "As Inputs Tri-Stated".  This is done in
> the Settings-> Device ->Device & Pin Options
> I think having the default "As output, driving ground" causes problems
> on the development board, because some of the unused pins may be
> connected to other things such the recofiguration signal to the Max
> Device (active low).
> I have burned myself plenty of times on this.
> --Chris

Aye, this is explicitly mentioned in the tutorial (Cyclone).

Nial.

------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk



Article: 61474
Subject: Free timing diagram drawing software
From: "Michael Chan" <s354025@student.uq.edu.au>
Date: Mon, 6 Oct 2003 00:08:37 +1000
Links: << >>  << T >>  << A >>
Hi,

I'm not sure if this is the best place to ask, but anyway, does anyone know
of any free software that draws timing diagrams?

Thanks,

Michael.





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