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 51475

Article: 51475
Subject: Re: SChematic design approach compared to VHDL entry approach
From: Keith R. Williams <krw@btv.ibm.com>
Date: Tue, 14 Jan 2003 14:27:03 -0500
Links: << >>  << T >>  << A >>
In article <v28gs5g1c1mkbc@corp.supernews.com>, austin@da98rkroom.com 
says...
> Hi Keith,
> 
> > For dataflow, no.  For state machines, I don't think HDLs can be
> > beat.
> 
> Well, it depends.  If you have a schematic library that allows you to draw a
> flow diagram and makes it drag and drop, it's REALLY easy...and easy to
> do...and easy to read.

Doesn't that make it more of an HDL rather than schematic? There is 
some "synthesis" going on then.  Perhaps I don't understand your tool.
> 
> > The design is simply too large
> > to make it practical though.
> 
> There is NO design that is "simply too large to make it practical", as it
> depends on how you draw your schematics.  You actually think 1000 pages of
> TEXT is "easier"???

You snipped the rest of my paragraph: 

> > I'm working on a custom logic design right now.  It's done in 
> > VHDL and is very hard to follow, since many signals have 
> > different names depending on where they are.  It's taken me 
> > *hours* to trace simple registers about a few muxes.  I *wish* I 
> > had a schematic generating tool.  The design is simply too large 
> > to make it practical though.

I believe that generating schematics from this VHDL would be 
impractical.  For example, the entity for the unit I'm responsible for 
(verification) is roughly 1000 lines of INs/OUTs (comments not 
included).  That's going to make some rather large schematic blocks. I 
*highly* doubt even 1000 pages would contain this design.  Add a zero 
and it still would likely not make it.  OTOH, since it's text I can 
grep the files and trace signals between components rather quickly. 

I was a long time schematic bigot but I did the FPGA designs in VHDL, 
primarily as a learning exercise.  If I had it to do over I'd likely do 
a mixed schematic/VHDL design and mix it along the dataflow/control 
logic line.  I'd strongly consider a schematic tool that output VHDL 
netlists. Though I doubt I'll get the chance to play again. 

> > > > * Time consuming
> > >
> > > I'd argue that....as well
> >
> > Again, schematics are nice for dataflow.  I very much dislike
> > schematics for state machines.
> 
> It depends on how it's drawn.  Any tool can be abused, or used properly.
> Fought with, or worked with.

Very true.  I'd like to learn some of the tools you work with.  Perhaps 
I'd be an easy convert.
  
> > With the "proper library" I'd rule the world.
> 
> Bingo, and that is why I DO rule the world ;-)

I guess I can't argue with that.
 
> > > Er, actually, that is not true.  It IS used for very large designs that
> have
> > > high clock frequencies.
> >
> > VHDL is too.  ;-)
> 
> Er, yeah.  That's why the fast PCI cores are done in schematics ;-)

PCI is fast?! 
 
> > > For most designs, it is better to simply use what you are most
> comfortable
> > > with.
> >
> > I'll dissent here.  Documentation means something.  My comfort
> > isn't everything.
> 
> Hum.  I think we strap you to a chair, and make you drink four 2L bottles of
> Diet Coke and see you say that after a few hours...

Gee, you work in a nice relaxed atmosphere. I could get to enjoy such  
enlightened management. ;-)

> >  I document my VHDL to the nines (mostly
> > because even I can't remember what I did last month).  I find it
> > hard to document schematics to the same degree.
> 
> As I've said, a tool is only as good as the person using it.  I have no
> problem documenting schematics, and far better than I've seen HDLs
> documented.  And, as you've said, data path is just obvious...and therefore
> would require much less documentation.  It even has a built-in block
> diagram.

Again, I'd like to see your schematics.  I'm always open to new ways of 
doing things. I get bored with the old ones. ;-) 
 
> > > As with any thing engineering, any tool can be used exceptionally as
> > > well as poorly.
> >
> > Poor tools tend to be used poorly.  Good tools may not be any
> > better, but there is at least a chance.  ;-)
> 
> Well, then...DON'T USE ORDAD!

Ordad? Tell us how you really feel! Don't hold it in!

I used it for the board schematics.  Orcad's output fit well into the 
fabs tool chain and it sorta did what I wanted it to do and the 
schematics worked well for debug. I certainly wasn't going to venture 
into the FPGAs with Orcad.  One of the best decisions I made was to go 
with the Synplicity tools.

----
  Keith  
   


Article: 51476
Subject: Re: SChematic design approach compared to VHDL entry approach
From: "Austin Franklin" <austin@da98rkroom.com>
Date: Tue, 14 Jan 2003 14:33:43 -0500
Links: << >>  << T >>  << A >>
Michael,

> Basically, schematic entry tools are still in use only because people
> without a software background are still allowed into a FPGA design
> field.

Your statement is just simply so foolish I have to believe you simply are
not serious.  If you are in fact serious, please let me know, so I can
'splain to you just how foolish such a statement is, for so many, many
reasons.

Austin



Article: 51477
Subject: Re: Virtex, Virtex II and Virtex II Pro
From: Tullio Grassi <tullio@umd.edu>
Date: Tue, 14 Jan 2003 14:36:40 -0500
Links: << >>  << T >>  << A >>
Ann wrote:
> Hello
> My name is Ann and I'm student from Poland. I have to make a presentation
> about Virtex, Virtex II and Virtex II Pro devices. I've got a few questions.
> What is a slice and what for it was developed?
> What are the major differences between Virtex, Virtex II and Virtex II Pro
> devices?
> If you have any presentation about those devices I would be very grateful
> for sending it to me.
> Thank you very much!
> Ann
> 
> 
> 
> 
> 

Hi Ann,

  the "official" info is 
on:http://support.xilinx.com/xlnx/xweb/xil_publications_index.jsp

Some presentations and student materials are at:
   http://university.xilinx.com/univ/xup/labsfnd/downld.htm
-- 

Tullio Grassi

======================================
Univ. of Maryland - Dept. of Physics
College Park, MD 20742 - US
Tel +1 301 405 5970
Fax +1 301 699 9195
======================================


Article: 51478
Subject: Re: SChematic design approach compared to VHDL entry approach
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Tue, 14 Jan 2003 20:14:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <MPG.188e2e7468c2d13198989d@enews.newsguy.com>,
Keith R. Williams  <krw@btv.ibm.com> wrote:
>> Well, it depends.  If you have a schematic library that allows you to draw a
>> flow diagram and makes it drag and drop, it's REALLY easy...and easy to
>> do...and easy to read.
>
>Doesn't that make it more of an HDL rather than schematic? There is 
>some "synthesis" going on then.  Perhaps I don't understand your tool.

When I had to do a moderate complexity state-machine oh-so-many years
ago for a class project (a MIDI synthesizer), I decomposed it into a
high level one-hot machine with a series of counter-driven steps
within each superstate, coupled to a textual representation to guide
my hand-translation.  It actually worked fairly well, producing
something which was reasonable to debug and modify.

That style of design wasn't TOO bad.  And you had to be clever when
the class project was a Midi Synthesizer in a 4005, we didn't have
much area budget in the FPGA.  I LIKED that project.

>> > VHDL is too.  ;-)
>> 
>> Er, yeah.  That's why the fast PCI cores are done in schematics ;-)
>
>PCI is fast?! 

Some of the timing loops, when you consider that even 33 MHz PCI goes
through I/O and that people had to get it to work on a Gen1
Virtex/Spartan II (or even a late generation 4000 series), its not
easy.

And with new ones being 133 MHz at 64 bit, PCI-X ain't trivially slow
either.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 51479
Subject: Re: Open FPGA please!
From: "glen herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Tue, 14 Jan 2003 20:25:22 GMT
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3E233518.FDC1C675@xilinx.com...
> My question is a big: WHY?
> Yes, you might grow your own. When I was a kid we grew our own
potatoes and
> vegetables and made butter and slaughtered a pig every year. But
that was out
> of necessity, not choice.
> Now I much rather make a decent salary and buy most of these
things, and for
> a hobby do some gardening, just for the fun of it....
> The benefit of the closed FPGA architecture ( and the intense
competition
> between "you know who") is an almost unbelievable rate of
progress in
> capabilities and ease of design.
> Does anybody really want to go back to XC3000 and EXACT-like
tools?
>
> For the user, the FPGA should just be a device that gets the job
done with a
> minimum of fuss and headache, sweat, risk, delay and money. Only
for Xilinx
> and Altera (plus a few others) is it the raison d'etre, but we
are a small
> community that gets their kicks ( and salary ) out of this
effort. If you are
> so eager to design an FPGA, come and join us and help us speed up
progress
> even more !
> But none of this griping about "open bitstreams". That's not
where the real
> progress could possibly be!
> The exciting progress is in innovative FPGA applications.
> End of soapbox.
>
(snip)

First, I haven't actually done it yet, but I believe that Jbits is
as close to open as just about anyone needs.  It should be enough
that one could write all the tools to generate bitstreams.

But second, If you follow the argument above, Intel should
distribute their processors without documenting the instruction
set.  If we all program in high-level languages we should never
need to know it.  Maybe that day will come, but it isn't here yet.
If that did happen, we would not have things like Linux or FreeBSD
which require at least a small amount of assembly code in the
lowest level device drivers.  (I doubt the competition between
Xilinx and Altera is comparable to that between Intel and AMD.)

Someone should define a file format containing all the information
that is necessary to program the device, and write a Jbits calling
program to generate the bits from such a file.   )Though the
challenge is to come up with a file format allowing forward
compatability.)  Then open source design tools could be written to
generate such files.

-- glen





Article: 51480
Subject: Re: Open FPGA please!
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Tue, 14 Jan 2003 20:56:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <Sm_U9.73636$3v.13458@sccrnsc01>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>First, I haven't actually done it yet, but I believe that Jbits is
>as close to open as just about anyone needs.  It should be enough
>that one could write all the tools to generate bitstreams.

Actually, I say that .xdl is more important.  Jbits replaces the
back-end bitgen with a published API.  

But .xdl allows one to snip into the flow between placement and
routing as well as between routing and bitgen/timing analysis, keeping
everything else.  Or to bypass mapping and construct your own mapper,
with output to the router (no RLOC's however at this point,
unfortunatly).

It's much nicer to be able to rely on everything else in the flow.

>But second, If you follow the argument above, Intel should
>distribute their processors without documenting the instruction
>set.  If we all program in high-level languages we should never
>need to know it.  Maybe that day will come, but it isn't here yet.
>If that did happen, we would not have things like Linux or FreeBSD
>which require at least a small amount of assembly code in the
>lowest level device drivers.  (I doubt the competition between
>Xilinx and Altera is comparable to that between Intel and AMD.)

Intel documents the ISA, but it doesn't document a lot of internal
instructions used in developing/testing.

>Someone should define a file format containing all the information
>that is necessary to program the device, and write a Jbits calling
>program to generate the bits from such a file.   )Though the
>challenge is to come up with a file format allowing forward
>compatability.)  Then open source design tools could be written to
>generate such files.

Open source tools would do better targeting .xdl, and then someone
writing an .xdl to bit translator with JBits if one wants to
completely bypass the xilinx flow.

I don't think anyone's done the logical experiment: Take a bunch of
designs, pass them through Xilinx placement and an academic placement
tool (eg, VPR) hacked to place Xilinx slices, then route with Xilinx's
router.  But I'd bet money that, on a large benchmark set and
comparable effort (time), Xilinx will win if the academic placer is
also simulated annealing based.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 51481
Subject: Re: CONCEPT OF BALL GRID ARRAY
From: cvmnk@yahoo.com (naveen)
Date: 14 Jan 2003 13:07:59 -0800
Links: << >>  << T >>  << A >>
hi,
      1)wats wire-bond BGA and flip chip?
      2)wat r other bit stream converters other than UART? i mean most
used     bit-strem coverters?
      3)concept of single data rate (SDR)  and double data rate (DDR
I/O BLOCKS?

 regards
  naveen


Andrew Rogers <andrew@rogerstech.co.uk> wrote in message news:<3E21E328.10105@rogerstech.co.uk>...
> naveen wrote:
> > hi,
> >  i would like to know the 
> >  concept of "BALL GRID ARRAY" used in the fpga technology.
> >  thnax
> >   naveen
> 
> It's the method of soldering used. Cirular pads are fabricated on both 
> the chip package and PCB. Small balls of solder are sandwiched between 
> the chip package and the PCB.
> 
> Regards
> Andrew Rogers

Article: 51482
(removed)


Article: 51483
Subject: How to run XST from command line?
From: "Jeff" <dsfdsaf@hotmail.com>
Date: Tue, 14 Jan 2003 16:18:31 -0500
Links: << >>  << T >>  << A >>
Hi,
I am using ISE 4.2i webpack on a PC, OS is Windows ME. From the XST user's
manual, it says it support command line mode.
How to run a script file "xst -ifn script_file_name [-ofn] log_file_name"?
In a DOS shell? I have tried, but it needs to setup new path. Where is the
guide instruction about these settings if there were?

The second question is about XFLOW. I searched the *.opt files and found
they are only under epld and xc9500xl/xv directory. No *.opt files under
fpga directory. And like the above question, in which shell to run XFLOW?


Thanks in advance.



Article: 51484
Subject: software for
From: cvmnk@yahoo.com (naveen)
Date: 14 Jan 2003 13:20:02 -0800
Links: << >>  << T >>  << A >>
HI,
  iam working with the xilinx virtex 2 fpga board.
  can u tell me the sites where i can download the software on my PC.
  
 thanx
 naveen

Article: 51485
Subject: Re: Open FPGA please!
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 14 Jan 2003 13:27:32 -0800
Links: << >>  << T >>  << A >>
Well, I go back to my "WHY?"
If somebody can prove that Xilinx sits as a hindrance between smart ideas and
their implementation in a Xilinx FPGA, then I might cave in.

Like the tasteless commercial tomatoes that enticed me to grow my own.

But just based on some ill-founded wild conspiracy theory, coupled with
complete disregard for the required effort and economic realities in a very
fast moving field, I don't think it makes sense to argue for open-source
FPGAs.

There are much better things to get excited about.

Peter Alfke
=========================

"Nicholas C. Weaver" wrote:

> In article <Sm_U9.73636$3v.13458@sccrnsc01>,
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> >First, I haven't actually done it yet, but I believe that Jbits is
> >as close to open as just about anyone needs.  It should be enough
> >that one could write all the tools to generate bitstreams.
>
> Actually, I say that .xdl is more important.  Jbits replaces the
> back-end bitgen with a published API.
>
> But .xdl allows one to snip into the flow between placement and
> routing as well as between routing and bitgen/timing analysis, keeping
> everything else.  Or to bypass mapping and construct your own mapper,
> with output to the router (no RLOC's however at this point,
> unfortunatly).
>
> It's much nicer to be able to rely on everything else in the flow.
>
> >But second, If you follow the argument above, Intel should
> >distribute their processors without documenting the instruction
> >set.  If we all program in high-level languages we should never
> >need to know it.  Maybe that day will come, but it isn't here yet.
> >If that did happen, we would not have things like Linux or FreeBSD
> >which require at least a small amount of assembly code in the
> >lowest level device drivers.  (I doubt the competition between
> >Xilinx and Altera is comparable to that between Intel and AMD.)
>
> Intel documents the ISA, but it doesn't document a lot of internal
> instructions used in developing/testing.
>
> >Someone should define a file format containing all the information
> >that is necessary to program the device, and write a Jbits calling
> >program to generate the bits from such a file.   )Though the
> >challenge is to come up with a file format allowing forward
> >compatability.)  Then open source design tools could be written to
> >generate such files.
>
> Open source tools would do better targeting .xdl, and then someone
> writing an .xdl to bit translator with JBits if one wants to
> completely bypass the xilinx flow.
>
> I don't think anyone's done the logical experiment: Take a bunch of
> designs, pass them through Xilinx placement and an academic placement
> tool (eg, VPR) hacked to place Xilinx slices, then route with Xilinx's
> router.  But I'd bet money that, on a large benchmark set and
> comparable effort (time), Xilinx will win if the academic placer is
> also simulated annealing based.
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu


Article: 51486
Subject: Re: Open FPGA please!
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Wed, 15 Jan 2003 08:09:59 +1000
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Well, I go back to my "WHY?"
> If somebody can prove that Xilinx sits as a hindrance between smart ideas and
> their implementation in a Xilinx FPGA, then I might cave in.

I'd like partial reconfiguration on rectangular regions, rather than 
entire columns... pretty please? :)

John


Article: 51487
Subject: Re: SChematic design approach compared to VHDL entry approach
From: "Bryan" <bryan@srccomp.com>
Date: Tue, 14 Jan 2003 15:20:09 -0700
Links: << >>  << T >>  << A >>
Yeah, about the same time schematics are history, HDL will be so easy to use
that monkeys will do most of the designs.  I guess you better start eating
more bananas.  Got to keep that software background up to date. :-)




"Michael S" <already5chosen@yahoo.com> wrote in message
news:f881b862.0301141000.6baec97c@posting.google.com...
> Basically, schematic entry tools are still in use only because people
> without a software background are still allowed into a FPGA design
> field. The day management will finally realize how much money can be
> saved by keeping these people (a.k.a. hardware engineers) out of all
> but the simplest FPGA designs - the time of the schematics will be
> over.
> These HW guys can't spell "version control" !!! Enough said.
>



Article: 51488
Subject: Off Topic: Single Board Computers?
From: Terry Herter <tlh10@cornell.edu>
Date: Tue, 14 Jan 2003 17:29:53 -0500
Links: << >>  << T >>  << A >>
Off topic question...but I suspect many will have some insight...

Looking for a good single board computer/passive backplane in a rack
mount.

Can anyone suggest a good company to deal with, that just may be around
in a few years to come?

Thanks,
Bruce
bp22@cornell.edu


Article: 51489
Subject: Re: Off Topic: Single Board Computers?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Tue, 14 Jan 2003 22:36:04 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3E248F61.77E1748E@cornell.edu>,
Terry Herter  <tlh10@cornell.edu> wrote:
>Off topic question...but I suspect many will have some insight...
>
>Looking for a good single board computer/passive backplane in a rack
>mount.
>
>Can anyone suggest a good company to deal with, that just may be around
>in a few years to come?

How small/what backplane?

Eg, Via makes a nice all-in-one PC motherboard (C3 processor, chipset,
video, audio, 100 mb ethernet, USB2, firewire) which retails for <$150
with a 900 MHz processor, <$130 for a FANLESS 600 MHz processor, and
is 17cm x 17cm in dimension (mini-ITX form factor)

http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 51490
Subject: Re: Open FPGA please!
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 14 Jan 2003 22:45:04 GMT
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter@xilinx.com> wrote in message
news:3E2480C5.3B181E45@xilinx.com...
> Well, I go back to my "WHY?"
> If somebody can prove that Xilinx sits as a hindrance between smart ideas
and
> their implementation in a Xilinx FPGA, then I might cave in.

I'd be ecstatic if the mapper no longer decided what was irrevocably grouped
together before the P&R phase "took over" and I'd be ever so humbled if the
router could actually produce critical routes the same as or better than
what I get in FPGA editor with my "stumble around" approach to manual
routing.  I don't want to "thank god" every time I use the directed route
constraints because I shouldn't have to go there in the first place.

The whole concept of "critical path routing" has fallen on deaf ears over
the years.  Estimates can be made based on supplied constraints as to what
the best achievable times are for certain paths then those paths prioritized
in the placement and routing.  The worst case paths are routed first, slowly
filling up the part until only the paths with greatest slack are left.  One
thing I expect this would require is an ability to remap as suggested above.

The silicon is ecellent, only desiring better propagation delays here or
there (BlockRAM enable setup and clock to out times or delays to get on and
off carry chains, for instance).  The tools just don't seem to want to let
us get the most out of the beautifully engineered devices.

- another John



Article: 51491
Subject: Re: RS-232 connection with SOPC Development Kit
From: prashantj@usa.net (Prashant)
Date: 14 Jan 2003 15:30:01 -0800
Links: << >>  << T >>  << A >>
Hi,
What exactly is the error message that you get ? I had this problem
with the APEX development board (Professional Version) from Altera.
Then I found out that the COM port was being used by a backup power
supply software on my computer. I uninstalled the s/w and it worked.
The error message should help you out.

bye,
Prashant


satchit_h@hotmail.com (satchit) wrote in message news:<ddf018f6.0301131035.4364f1c3@posting.google.com>...
> Hi,
> 
> I am trying to port a Nios-32 system on the SOPC Development board
> with the Apex "EP20k1500EBC652-1X" chip. I am using the simple UART
> core provided in Altera's Nios Development Kit to interface with the
> RS-232 DTE interface provided on the board. But I can't get it to
> work. Does anybody have a solution to this problem?
> 
> thanks in advance.
> 
> regards,
> Satchit

Article: 51492
Subject: Re: SChematic design approach compared to VHDL entry approach
From: spam_hater_7@email.com (Spam Hater 7)
Date: 14 Jan 2003 15:38:11 -0800
Links: << >>  << T >>  << A >>
See earlier thread about signal (net, language) naming conventions.

There is a reason that we use them!

You may consider doing just that; pick a naming convention, and start
cleaning up the code.  It will make it much easier for the -next- bug.

Couple of perl scripts, emacs with vhdl-mode, and a fair amount of time.

SH

Keith R. Williams <krw@attglobal.net> wrote in message 
> 
> I'm working on a custom logic design right now.  It's done in 
> VHDL and is very hard to follow, since many signals have 
> different names depending on where they are.  It's taken me 
> *hours* to trace simple registers about a few muxes.  I *wish* I 
> had a schematic generating tool.  The design is simply too large 
> to make it practical though.
>

Article: 51493
Subject: Re: SChematic design approach compared to VHDL entry approach
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Tue, 14 Jan 2003 23:59:07 -0000
Links: << >>  << T >>  << A >>
Austin Franklin wrote
> For most designs, it is better to simply use what you are most comfortable
> with.  As with any thing engineering, any tool can be used exceptionally as
> well as poorly.

I can see how you can mimic the functionality of a schematic
in a programming language.  But the other way round seems tough.




Article: 51494
Subject: Re: Open FPGA please!
From: Steve Lass <lass@xilinx.com>
Date: Tue, 14 Jan 2003 17:03:05 -0700
Links: << >>  << T >>  << A >>
John_H wrote:

> "Peter Alfke" <peter@xilinx.com> wrote in message
> news:3E2480C5.3B181E45@xilinx.com...
> > Well, I go back to my "WHY?"
> > If somebody can prove that Xilinx sits as a hindrance between smart ideas
> and
> > their implementation in a Xilinx FPGA, then I might cave in.
>
> I'd be ecstatic if the mapper no longer decided what was irrevocably grouped
> together before the P&R phase "took over"

This is planned for our next major release.

> and I'd be ever so humbled if the
> router could actually produce critical routes the same as or better than
> what I get in FPGA editor with my "stumble around" approach to manual
> routing.

I'll need some more info on this.  Did the design meet timing?  That is the
goal of our tools, not getting the best route for each net.

>  I don't want to "thank god" every time I use the directed route
> constraints because I shouldn't have to go there in the first place.
>
> The whole concept of "critical path routing" has fallen on deaf ears over
> the years.  Estimates can be made based on supplied constraints as to what
> the best achievable times are for certain paths then those paths prioritized
> in the placement and routing.  The worst case paths are routed first, slowly
> filling up the part until only the paths with greatest slack are left.

Even if we routed a net first, there is no guarantee that the router wouldn't rip it
up to meet timing on another net.  The current router is constantly making
tradeoffs to improve the overall design.

>  One
> thing I expect this would require is an ability to remap as suggested above.
>
> The silicon is ecellent, only desiring better propagation delays here or
> there (BlockRAM enable setup and clock to out times or delays to get on and
> off carry chains, for instance).  The tools just don't seem to want to let
> us get the most out of the beautifully engineered devices.

On the other hand, if the silicon had twice as many routing resources, we wouldn't
have to make so many tradeoffs in the software.  Routing is a difficult task.  I would
guesstimate that we have over 60 man years of effort into the router.  The placer has
even more.  Does somebody really want to take this project on?

Steve

>
>
> - another John


Article: 51495
Subject: Clock routing in Virtex/E/II
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Wed, 15 Jan 2003 00:05:31 -0000
Links: << >>  << T >>  << A >>
I posted this afew days ago.  Nobody answered, possibly out of
compassion for my ignorance.  But the truth will (may?) set me
free so I am still interested in a clarification.

BTW, I know that the DLLs are really in the corners of the die.
At least I _think_ I know that :-)

Peter Alfke wrote

> We always distribute the global clock(s) on one or two horizontal "backbones"
> across the chip, but we gate off any vertical "rib" or "branch" that is not
> used. This is done automatically without any user intervention. It means that
> vertically oriented clocked logic draws less power than horizontally oriented
> one. And the carry structure always groups counters and accumulators
> vertically.  :-)

This is probably a nomenclature confusion, but if I go into
fpga_editor, it looks as if the backbones are vertical, with
horizontal distribution spines feeding all the flops in a quarter
of a row.  I always assumed that it is these horizontal lines
which are turned off to minimize power.  This is with Virtex/E.





Article: 51496
Subject: Re: Open FPGA please!
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 15 Jan 2003 00:24:45 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3E24A539.2A9E34B8@xilinx.com>, Steve Lass  <lass@xilinx.com> wrote:
>> I'd be ecstatic if the mapper no longer decided what was irrevocably grouped
>> together before the P&R phase "took over"
>
>This is planned for our next major release.

Thats very good.

>> and I'd be ever so humbled if the
>> router could actually produce critical routes the same as or better than
>> what I get in FPGA editor with my "stumble around" approach to manual
>> routing.
>
>I'll need some more info on this.  Did the design meet timing?  That is the
>goal of our tools, not getting the best route for each net.

I've personally noticed that, without turning on maximum effort
routing, there is a noticable drop-off in performance even for a fully
laid out datapath.  This always struck me as strange, as most of the
connections in the design were direct horizontal/vertical alignment
and the critical path was being defined by one of these connections to
an ajacent BlockRAM.

>On the other hand, if the silicon had twice as many routing
>resources, we wouldn't have to make so many tradeoffs in the
>software.  Routing is a difficult task.  I would guesstimate that we
>have over 60 man years of effort into the router.  The placer has
>even more.  Does somebody really want to take this project on?

However, I think someone can do a lot better than the placer for
datapath designs.  Is it the responsibility of the synthesis tool
(which can easily infer the datapath but throws this away) or the
placer?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 51497
Subject: Re: Open FPGA please!
From: Steve Lass <lass@xilinx.com>
Date: Tue, 14 Jan 2003 17:56:14 -0700
Links: << >>  << T >>  << A >>
"Nicholas C. Weaver" wrote:

> In article <3E24A539.2A9E34B8@xilinx.com>, Steve Lass  <lass@xilinx.com> wrote:
> >> I'd be ecstatic if the mapper no longer decided what was irrevocably grouped
> >> together before the P&R phase "took over"
> >
> >This is planned for our next major release.
>
> Thats very good.
>
> >> and I'd be ever so humbled if the
> >> router could actually produce critical routes the same as or better than
> >> what I get in FPGA editor with my "stumble around" approach to manual
> >> routing.
> >
> >I'll need some more info on this.  Did the design meet timing?  That is the
> >goal of our tools, not getting the best route for each net.
>
> I've personally noticed that, without turning on maximum effort
> routing, there is a noticable drop-off in performance even for a fully
> laid out datapath.  This always struck me as strange, as most of the
> connections in the design were direct horizontal/vertical alignment
> and the critical path was being defined by one of these connections to
> an ajacent BlockRAM.
>
> >On the other hand, if the silicon had twice as many routing
> >resources, we wouldn't have to make so many tradeoffs in the
> >software.  Routing is a difficult task.  I would guesstimate that we
> >have over 60 man years of effort into the router.  The placer has
> >even more.  Does somebody really want to take this project on?
>
> However, I think someone can do a lot better than the placer for
> datapath designs.  Is it the responsibility of the synthesis tool
> (which can easily infer the datapath but throws this away) or the
> placer?

It's currently the job of the placer.  Physical synthesis may change
that.

Steve

>
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu


Article: 51498
Subject: Re: Off Topic: Single Board Computers?
From: Terry Herter <tlh10@cornell.edu>
Date: Tue, 14 Jan 2003 20:04:30 -0500
Links: << >>  << T >>  << A >>
Sorry...should have been more informative.  Looking for a 19" rackmount
system...with a passive backplane and a single board computer...6U type
size...etc.  Desktop PCI in a more rugged frame...

Thanks.

"Nicholas C. Weaver" wrote:

> In article <3E248F61.77E1748E@cornell.edu>,
> Terry Herter  <tlh10@cornell.edu> wrote:
> >Off topic question...but I suspect many will have some insight...
> >
> >Looking for a good single board computer/passive backplane in a rack
> >mount.
> >
> >Can anyone suggest a good company to deal with, that just may be around
> >in a few years to come?
>
> How small/what backplane?
>
> Eg, Via makes a nice all-in-one PC motherboard (C3 processor, chipset,
> video, audio, 100 mb ethernet, USB2, firewire) which retails for <$150
> with a 900 MHz processor, <$130 for a FANLESS 600 MHz processor, and
> is 17cm x 17cm in dimension (mini-ITX form factor)
>
> http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu


Article: 51499
Subject: Re: How to run XST from command line?
From: "John Retta" <jretta@rtc-inc.com>
Date: Tue, 14 Jan 2003 18:52:22 -0700
Links: << >>  << T >>  << A >>




"Jeff" <dsfdsaf@hotmail.com> wrote in message
news:4b%U9.3017$%W2.514607@news20.bellglobal.com...
> Hi,
> I am using ISE 4.2i webpack on a PC, OS is Windows ME. From the XST user's
> manual, it says it support command line mode.
> How to run a script file "xst -ifn script_file_name [-ofn] log_file_name"?
> In a DOS shell? I have tried, but it needs to setup new path. Where is the
> guide instruction about these settings if there were?
>

All You need to do is :
[1] Add the system variable XILINX and set to the top level webpack install
directory.
     On my PC this is C:\xilinx_webpack.
[2] Add to Path variable : %XILINX\bin\nt.

To modify, go to control panel .... system ... Advanced .... environment
variables.

I am not sure where these were defined in documention.  Good luck.

--
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.
303-926-0068

email : jretta@rtc-inc.com
web :  www.rtc-inc.com





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