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 17900

Article: 17900
Subject: Re: simple VHDL?
From: leejp@my-deja.com
Date: Thu, 16 Sep 1999 12:33:30 GMT
Links: << >>  << T >>  << A >>
I have Design Direct Base installed on my machine and while I find it
rich in features, I don't find the documentation and the tutorials
straightforward at all as with the previous generation products that I
have used PALASM and MACHXL...  especially when it comes to ABEL-HDL (I
am new to ABEL-HDL as well).  Further, my desire is to go to a more
widely accepted language...  VHDL or Verilog.

The book "VHDL for Programmable Logic" by Kevin Skahill has been
recommended to me by many..  along with the Warp software.  My Cypress
rep is sending me both and offering to run a 1 day VHDL class for us.
So I'm kind of leaning towards this route...  The price is right and I
understand that the Warp software can generate output for simple PLD's
from multiple vendors...  26V12's 22V10's and 16V8's for example.  Is
this true?  Additionally, for larger devices, you can compile, simulate
your designs using
Warp and target to a non Cypress part using a fitter from that vendor...
True as well?

Thanks...


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Article: 17901
Subject: Re: Xilinx on PMC?
From: Bill Blyth <bb@alphadata.co.uk>
Date: Thu, 16 Sep 1999 14:29:31 GMT
Links: << >>  << T >>  << A >>
In article <qYYD3.13881$wW2.14983@news.rdc1.ct.home.com>,
  "Paul Clapis" <pclapis@pantheon.yale.edu> wrote:
> Does anyone know of commercial PMC cards with Xilinx FPGA capability?
> (Ideally I need a card with DMA or FIFO capability).  If you have any
leads,
> please drop me a line at pclapis@pantheon.yale.edu.
>
> Thanks!
>
>
Try Alpha Data at www.alphadata.co.uk for Virtex based PMC supporting
V400 up to v1000. Uses PLX PCI9080 for DMA engine.

regards

bill


--
-----------------------------
Alpha Data
-----------------------------


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Article: 17902
Subject: Re: free/demo/low cost verilog synthesis tools available?
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Thu, 16 Sep 1999 07:44:25 -0700
Links: << >>  << T >>  << A >>
You can find a list of free or low-cost development tools, both for Altera,
Xilinx and others, on The Programmable Logic Jump Station at
http://www.optimagic.com/lowcost.shtml.


--
-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------

<dr0ne@my-deja.com> wrote in message news:7rlvgn$qqe$1@nnrp1.deja.com...
>
>
>
> Hi,
>
> I'm currently doing some HW/SW codesign with xilinx & altera fpga's and
> I was wondering if there are such things as low cost/demo/free verilog
> synthesis software available? I use synplify but I'd like to be able to
> do some stuff from home, without having to *sell* my home in order to
> afford these tools. I don't need anything really complicated at
> all...just something that'll take simple behavioral/structural verilog
> and download it into a xilinx or altera chip (via JTAG if possible). Do
> any of the companies out there offer time or functionality limited
> demos?
>
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.


Article: 17903
Subject: Question for Circuit Designers of Large High-Speed Boards: Best Means to
From: Wayne Long <wcl@risc.sps.mot.com>
Date: Thu, 16 Sep 1999 09:54:54 -0500
Links: << >>  << T >>  << A >>
This question is for experienced circuit designers of
large boards that require a lot of net/bus topology
control, and use Mentor's Design Architect as a schematic
entry tool and BoardStation 500/Specctra CCT/Interconnectix
as a Layout tool(s).  (Note:  The layout newsgroups tend
to have primarily board layout participants; this newsgroup
is more likely to have actual circuit/systems designers.)

By large boards, I am referring to both physically large
boards, with schematic pages numbering in the forty plus
region.  By experienced, I mean that you've had to design
at least two or more boards of this size in succession,
preferably with the current design based largely on the
previous design but with different layout requirements.

We would like to hear your opinions as to what you have
found to be the overall fastest and most efficient way to
convey net topology/control information from one large design
to the next when they are similar (taking into account, of
couse, overall time to board fabrication).

We have used these methods in the past:

  1. Typed lists of net requirements (length, separation,
     impedance, source/load termination location, etc.)
     In the next large design, we simply modify the last
     design's list for the changes in the new design.

  2. Specctra CCT "Do" files.  We copy and modify the do
     file to the next design and modify/update as needed.

Note: We typically use a field solver throughout the layout
      on copies of the design to test/monitor actual signal
      integrity.

We are considering going to a new method where we add high-
speed class properties to the schematic, which feed the
layout tools (Specctra, Boardstation 500, and possibly
Interconnectix).  However, we see a large reusability issue
with this method that seems to be a failing of the existing
toolset.  A local FAE made it clear that high-speed
net classes are generally not transferable from one design
to the next without modification (due invariably to changing
component counts, locations, bus loads and positions on the
new board, etc.).  Since we would have hundreds of these
class properties hidden and attached to our schematic nets,
not only would there be a large up-front price to pay to enter
this information in the first large design (because of the
GUI menuing system in combination with the high number of nets),
but an almost similar price to pay in subsequent large designs.
We see that some of this could be alleviated if high-speed
properties were assignable by net segment, rather than the
entire net, but the current tools (not referring to do files
here) do not appear to allow for this.  It also seems that if
the high-speed design property database could be edited just
like a Specctra do file (with a text editor), it would be much
faster than going through the GUI menu system currently in place.

(Additionally, if layout tools had better support for interactive
on-the-fly net rule definition that allowed the ability to
simply highlight a group of nets for "like-kind" high-speed
rule adherence, the speed of directing interactive place-
ment and routing could be improved as well. Back-annotation of
such rules to the database would be ideal.)

As you may have surmised, these concerns only apply to
large designs with a lot topology control required.  For
smaller boards/designs, with shorter net lengths, less rules
are required overall (or they are concentrated on a fewer
number of schematic pages), and the entry or re-entry of
high-speed net properties in the schematic is much less
of an issue.

We would like to hear from circuit designers of the larger
boards as to what you have found to be the best method(s).
We'd like to know if you actually experienced the drawbacks
mentioned above (or others we are yet unaware of), and how,
if at all, did you overcome/mitigate them.  We would like
to hear of the failures as well as the successes, and whether
you ultimately adopted high-speed net class properties as
part of your schematic entry phase or went to other approaches.
And what is missing from the toolset(s) in this respect?

It is a given that board designers would always prefer to
see the high-speed properties rather than a typed list, and
a Specctra Do file would be second best, so those viewpoints
are pretty much already understood, in terms of time and
effort from the board designer's perspective.  Whereas the
board designer primarily see's her/his improvement in layout
design flow and downstream, the circuit designer sees the
overall improvement/degradation in project cycle time from
conception through production and maintenance, from project
to project.

Wayne Long
wcl@risc.sps.mot.com

Article: 17904
Subject: Question for Circuit Designers of Large High-Speed Boards: Best Means to
From: Wayne Long <wcl@risc.sps.mot.com>
Date: Thu, 16 Sep 1999 09:55:34 -0500
Links: << >>  << T >>  << A >>
This question is for experienced circuit designers of
large boards that require a lot of net/bus topology
control, and use Mentor's Design Architect as a schematic
entry tool and BoardStation 500/Specctra CCT/Interconnectix
as a Layout tool(s).  (Note:  The layout newsgroups tend
to have primarily board layout participants; this newsgroup
is more likely to have actual circuit/systems designers.)

By large boards, I am referring to both physically large
boards, with schematic pages numbering in the forty plus
region.  By experienced, I mean that you've had to design
at least two or more boards of this size in succession,
preferably with the current design based largely on the
previous design but with different layout requirements.

We would like to hear your opinions as to what you have
found to be the overall fastest and most efficient way to
convey net topology/control information from one large design
to the next when they are similar (taking into account, of
course, overall time to board fabrication).

We have used these methods in the past:

  1. Typed lists of net requirements (length, separation,
     impedance, source/load termination location, etc.)
     In the next large design, we simply modify the last
     design's list for the changes in the new design.

  2. Specctra CCT "Do" files.  We copy and modify the do
     file to the next design and modify/update as needed.

Note: We typically use a field solver throughout the layout
      on copies of the design to test/monitor actual signal
      integrity.

We are considering going to a new method where we add high-
speed class properties to the schematic, which feed the
layout tools (Specctra, Boardstation 500, and possibly
Interconnectix).  However, we see a large reusability issue
with this method that seems to be a failing of the existing
toolset.  A local FAE made it clear that high-speed
net classes are generally not transferable from one design
to the next without modification (due invariably to changing
component counts, locations, bus loads and positions on the
new board, etc.).  Since we would have hundreds of these
class properties hidden and attached to our schematic nets,
not only would there be a large up-front price to pay to enter
this information in the first large design (because of the
GUI menuing system in combination with the high number of nets),
but an almost similar price to pay in subsequent large designs.
We see that some of this could be alleviated if high-speed
properties were assignable by net segment, rather than the
entire net, but the current tools (not referring to do files
here) do not appear to allow for this.  It also seems that if
the high-speed design property database could be edited just
like a Specctra do file (with a text editor), it would be much
faster than going through the GUI menu system currently in place.

(Additionally, if layout tools had better support for interactive
on-the-fly net rule definition that allowed the ability to
simply highlight a group of nets for "like-kind" high-speed
rule adherence, the speed of directing interactive place-
ment and routing could be improved as well. Back-annotation of
such rules to the database would be ideal.)

As you may have surmised, these concerns only apply to
large designs with a lot topology control required.  For
smaller boards/designs, with shorter net lengths, less rules
are required overall (or they are concentrated on a fewer
number of schematic pages), and the entry or re-entry of
high-speed net properties in the schematic is much less
of an issue.

We would like to hear from circuit designers of the larger
boards as to what you have found to be the best method(s).
We'd like to know if you actually experienced the drawbacks
mentioned above (or others we are yet unaware of), and how,
if at all, did you overcome/mitigate them.  We would like
to hear of the failures as well as the successes, and whether
you ultimately adopted high-speed net class properties as
part of your schematic entry phase or went to other approaches.
And what is missing from the toolset(s) in this respect?

It is a given that board designers would always prefer to
see the high-speed properties rather than a typed list, and
a Specctra Do file would be second best, so those viewpoints
are pretty much already understood, in terms of time and
effort from the board designer's perspective.  Whereas the
board designer primarily see's her/his improvement in layout
design flow and downstream, the circuit designer sees the
overall improvement/degradation in project cycle time from
conception through production and maintenance, from project
to project.

Wayne Long
wcl@risc.sps.mot.com

Article: 17905
Subject: Chip Level Ciruit Designers needed, please read
From: M Murphy <mmurphy@newmill.com>
Date: Thu, 16 Sep 1999 11:13:37 -0400
Links: << >>  << T >>  << A >>
New Millennium Inc., a leading supplier of Software, Hardware and IT
professionals to end clients across the country, has a client in
Freemont, CA with the following position available for immediate
placement. Please review the description of the position below and let
me know if you are interested in pursuing this position. I have my
contact information listed at the bottom of this posting. You must be a
US citizen or have the applicable work visa to apply for this position.

Location: Freemont, CA
Duration: 3-6 months
Description: Client is looking for 3 Chip level Circuit Designers who
has experience working on the integration of large chips (5 million
gates). Will be responsible for clock distibution, timing analysis and
chip verification. Should be experienced in integrating high speed,
complex graphics or 3-D chips. Will be working in a team environment of
4-6 people.

Thanks for taking the time to peruse this posting. I look forward to
hearing from you soon.

--
Michael Murphy
New Millennium Inc.
800-381-9507 (V)
800-381-8708 (F)
mmurphy@newmill.com


Article: 17906
Subject: Re: PCI core for Orca 3T
From: "Wade D. Peterson" <peter299@maroon.tc.umn.edu>
Date: Thu, 16 Sep 1999 10:28:34 -0500
Links: << >>  << T >>  << A >>
I think Lucent has a part which includes PCI core hardware.  You don't need the
core...you just connect up the internal routes to it.

--
Wade D. Peterson
Silicore Corporation
3525 E. 27th St. No. 301, Minneapolis, MN USA 55406
TEL: (612) 722-3815, FAX: (612) 722-5841
URL: http://www.silicore.net/  E-MAIL: peter299@maroon.tc.umn.edu

Robert Sefton <rsefton@cosinecom.com> wrote in message
news:37DE8BFA.75C6574C@cosinecom.com...

> Has anyone successfully ported a PCI core to the Lucent Orca 3T family?
> If so, who was the core vendor? Also, how fast did you run it and what,
> if any, major problems did you encounter?
>
> Thanks,
>
> --
>
> --------------------------
> --
> -- Robert Sefton
> -- Senior Design Engineer
> --
> -- CoSine Communications
> -- 1200 Bridge Parkway
> -- Redwood City, CA 94065
> --
> -- Direct: 650.637.2441
> -- Main:   650.637.4777
> -- Fax:    650.637.2412
> --
> --------------------------

Article: 17907
Subject: speeding up place and route
From: Geoff Yarbrough <yarbroug@cs.colostate.edu>
Date: Thu, 16 Sep 1999 09:54:31 -0600
Links: << >>  << T >>  << A >>
Does anyone know any nifty ways to reduce the place and route time with
the Xilinx M1 PAR.  I know I can fiddle with PAR switch settings to help
a little bit, but am wondering if there are any other ways to reduce the
PAR time.

I've toyed with the ideas of macros, but from what Xilinx says, macros
are definitely not the way to go.  Is there any way to use them, (say by
assigning only a reference component within the macro, and letting PAR
do the rest) that will reduce PAR time.

Admittedly I'm a novice at this, but any ideas or insights would be
helpful.

Thanks

Geoff Yarbrough

Article: 17908
Subject: Re: xilinx v2.1i
From: Greg Neff <gregneff@my-deja.com>
Date: Thu, 16 Sep 1999 16:49:56 GMT
Links: << >>  << T >>  << A >>
In article <937466849.683923@zaphod.avm.de>,
  "Ansgar Bambynek" <a.bambynek@xxx.avm.de> wrote:
> Interesting, but where to find the service pack 1?
> The following URL http://www.xilinx.com/support/techsup/sw_updates/
states,
> that there is no service Pack for
> 2.1i so far

Your were at the right URL, you just have to select the software and
platform, and then press the "generate list" button.

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Article: 17909
Subject: Re: xilinx v2.1i
From: Jason.Wright@ericsson. (Jason T. Wright)
Date: Thu, 16 Sep 1999 16:51:43 GMT
Links: << >>  << T >>  << A >>
I downloaded the update a couple days ago.  Are you possible reading a
cached version of the web page? I get that problem a lot for certain
sites, since I go through a proxy server with an associated cache
(gets to be quite a pain, sometimes.)

Jason


On Thu, 16 Sep 1999 09:31:18 +0200, "Ansgar Bambynek"
<a.bambynek@xxx.avm.de> wrote:

>Interesting, but where to find the service pack 1?
>The following URL http://www.xilinx.com/support/techsup/sw_updates/ states,
>that there is no service Pack for
>2.1i so far
>
>Best Regards
>
>Ansgar Bambynek

Article: 17910
Subject: Re: simple VHDL?
From: "Austin Franklin" <austin@dark88room.com>
Date: 16 Sep 1999 18:47:48 GMT
Links: << >>  << T >>  << A >>
> Further, my desire is to go to a more
> widely accepted language...  VHDL or Verilog.

I don't know that I agree with the basis for that...  Abel is VERY easy to
learn, and works (very well) across all PLDs and FPGAs etc.  The big
problem using VHDL/Verilog is going to be control over getting the design
to fit in the part.  With Abel, it is easy, and the compiler is usually
very good..and if you have problems, they are easily resolved.  With
VHDL/Verilog...oh well, you may not get a simple and gate to fit into a
22V10 and you may spend months fighting tool problems that you may never be
able to solve.

Personally, I would STRONGLY recommend considering Abel over
VHDL/Verilog...

Just my .02..

Article: 17911
Subject: Re: xilinx v2.1i
From: "Andy Peters" <apeters.nospam@nospam.noao.edu.nospam>
Date: Thu, 16 Sep 1999 11:49:18 -0700
Links: << >>  << T >>  << A >>
Austin Franklin wrote in message <01befff8$a1f73e60$c627f7a5@drt4>...
>> now I actually understand
>> configurations, so I guess it was a couple of days' pain for a lifetime
>of
>> gain!
>
>How about a brief on what you learned....

Awwright, real quick:

first, note that configurations are not supported by FPGA Express, so you
need to use translate_off pragmas around them.   For the FPGA Express user,
they are really a convenience used for simulation, because the synthesis
tool considers the component you're configuring to be a black box and the
P+R tools fill in the blanks later.

A configuration lets you declare a component and bind it to an
entity/architecture in an arbitrary library (that you need to specify!) that
might have a different name.  The Xilinx Core stuff provides an example.
The tools let you create a RAM block that you can call whatever you want.
For instance, I created a RAM block called ram16x32.  the tools create a
component called ram16x32.  However, the library (in this case, the
XilinxCoreLib) doesn't have an entity called ram16x32; however, it does have
something called syncramVHT, which is a generic sync RAM.  The configuration
lets you "bind" your specific instances of your component to the generic
entity in the library.  It's (somewhat) analogous to putting a generic
"8051" on your schematic and deciding to use the DS5000 when you stuff the
actual board.

In a nutshell.  Given an entity:

entity foo
    port ();
end entity foo;

and an architecture that uses a component:

architecture foo_arch of foo is
    -- bar is something in a library called theLibrary, but declare the
interface here
    component bar is
        port ( );
    end component bar;
begin
    mycomp : bar port map ();
end architecture foo_arch;

You need to add (at the end of the file):

library theLibrary;    -- where whatever will be used for bar comes from

configuration foo_cfg of foo is -- configuration of the entity
    for foo_arch                -- and for the specific architecture in the
entity
        for all : bar           -- for all instances of component bar
            -- tell it what entity/architecture pair that's in theLibrary to
use for all
            -- instances for the component bar that occur in the
architecture foo_arch:
            use entity theLibrary.bletch(bletch_arch);
        end for; -- all bar
    end for; -- foo_arch
end configuration foo_cfg;

You've now caused the entity bletch (with architecture bletch_arch) to be
used wherever the component bar is instantiated.

Now, that's half of the battle.  Consider what happens if your entity foo is
used as a component of a higher-level entity.  You need to inform the
higher-level how to handle foo.  Because foo uses a configuration, **you
have to tell the higher-level to use the __configured__ foo.**  You do that
in - yep - another configuration.

given the higher-level entity:

entity mancha is
    port ();
end entity mancha;

architecture mancha_arch of mancha is
    -- use foo as a component:
    component foo is
        port ();
    end component foo;
begin
    -- instantiate foo:
    myfoo : foo port map ();
end architecture mancha_arch;

-- here's a configuration that tells us how we use foo.  Note that we don't
need to tell
-- it what library whatever we used for bar came from; that's all hidden by
foo.  foo can
-- be a black box, for all we care here.
configuration mancha_cfg of mancha is      -- configuration for the entity
    for mancha_arch                        -- and for the specific
architecture
        for all : foo                      -- and for the component foo
            use configuration work.foo_cfg; -- use this config for foo
        end for; -- all foo
    end for; -- mancha_arch
end configuration mancha_cfg;

You need to remember that when you use a configuration in lower-level
modules, you have to configure the higher-level modules to use that
configuration.  So, if mancha is the top-level of your chip and you want to
make a test bench for it:

entity mancha_tb is
end entity mancha_tb;

architecture testbench of mancha_tb is
    component mancha is
        port ();
    end component mancha;
begin
    uut : mancha port map ();
end architecture testbench;

You need a configuration:

configuration cfg_mancha_tb of mancha_tb is
    for testbench
        for all : mancha
            use configuration work.mancha_cfg;
        end for;
    end for;
end configuration cfg_mancha_tb;

and the simulation gotcha is that when you hit the VSIM button, you need to
choose the __configuration cfg_mancha_tb ___ instead of the entity mancha_tb
(very important!!)

you can be clever and use a configuration to bind different entities to
different instantiantions.  you can also use a generate and a configuration.
configurations also handle generics.

Conclusion:  yes, you need to do a helluva lot of typing.  (That must be why
they call VHDL a "strongly-typed" language.)  Once you figure out how it
works, it makes sense.

I leave the philosophical discussion of, 'is this all really necessary?' as
an exercise for the reader.


-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Creation Science" is oxymoronic.




Article: 17912
Subject: Re: simple VHDL?
From: "Andy Peters" <apeters.nospam@nospam.noao.edu.nospam>
Date: Thu, 16 Sep 1999 11:55:39 -0700
Links: << >>  << T >>  << A >>
leejp@my-deja.com wrote in message <7rqo2q$7l7$1@nnrp1.deja.com>...
> Additionally, for larger devices, you can compile, simulate
>your designs using
>Warp and target to a non Cypress part using a fitter from that vendor...
>True as well?

Well, that depends on how you write your code.  Most of the Warp examples
I've seen instantiate architecture-specific features that won't be portable
to another device family.  I'm not sure whether that's because the Warp
synthesizer is brain-dead and requires hints, or the people who wrote the
app notes haven't bothered to learn VHDL.

There's always the problem of trying to balance writing 100% portable code
vs taking advantage of architectural features.  Oftentimes you'll have to
instantiate those features directly if the synthesis tool can't infer them.
that statement is by no means inferring that Warp is the only tool limited
in that respect.  Tho I'd imagine that for $99, you get what you pay for.


-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Creation Science" is oxymoronic.



Article: 17913
Subject: Xilinx XC4005E
From: Arthur Dardia <ahdiii@webspan.net>
Date: Thu, 16 Sep 1999 16:10:54 -0400
Links: << >>  << T >>  << A >>
I was recently given 5 of these my a friend.  What do I need to learn and get to
program these?  All I have are the chips.  I'd like to build a DES cracker out
of the five chips for a science project that shows how the government is holding
back our crytography technology by keeping the strength of exportable crypto
limited.  Is it possible to put all 5 of these processors in parallel and have
them crunch away?  How would I program them, and in what language?  Where can I
learn?  Any tutorails or books I could get?  My friend used to work at Xilinx
and National Semiconductor.  He said that he'd try to get me some more stuff if
I need it, such as the programming software.  I have stacks of books from Xilinx
on their chips, but I don't understand a word in them.  Please give me resources
and/or help.

					Thanks,
					Art Dardia
Article: 17914
Subject: Xilinx development board > XVC400
From: Steve Martindell <s-martindell@_nospammm_ti.com>
Date: Thu, 16 Sep 1999 16:41:04 -0500
Links: << >>  << T >>  << A >>
I'm looking for a Xilinx FPGA developement board with and XCV400
or XCV600 Virtex.  The only Virtex development board I have found
is the Virtual Computing board, which only has the XCV300.

      steve martindell
      s-martindell@ti.com





Article: 17915
Subject: Re: Xilinx XC4005E
From: "Austin Franklin" <austin@dark88room.com>
Date: 16 Sep 1999 22:24:14 GMT
Links: << >>  << T >>  << A >>
> I have stacks of books from Xilinx
> on their chips, but I don't understand a word in them.

If that is the case, then I believe you are underestimating the task you
are attempting to attempt.

Article: 17916
Subject: Re: Xilinx development board > XVC400
From: Ray Andraka <randraka@ids.net>
Date: Thu, 16 Sep 1999 19:37:01 -0400
Links: << >>  << T >>  << A >>
GO to http://www.optimagic.com  You'll find what is probably the most
comprehensive list of FPGA boards, consultants, conferences etc there.

Steve Martindell wrote:

> I'm looking for a Xilinx FPGA developement board with and XCV400
> or XCV600 Virtex.  The only Virtex development board I have found
> is the Virtual Computing board, which only has the XCV300.
>
>       steve martindell
>       s-martindell@ti.com



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 17917
Subject: Re: simple VHDL?
From: Mark Summerfield <m.summerfield@ieee.org>
Date: Fri, 17 Sep 1999 10:20:17 +1000
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> I don't know that I agree with the basis for that...  Abel is VERY easy to
> learn, and works (very well) across all PLDs and FPGAs etc.  The big
> problem using VHDL/Verilog is going to be control over getting the design
> to fit in the part.  With Abel, it is easy, and the compiler is usually
> very good..and if you have problems, they are easily resolved.

That's because there's virtually a 1:1 correspondence between ABEL
constructs
and device resources -- you explicitly declare inputs, outputs, registers,
polarity, etc.  VHDL is a more abstract description language, and has to
infer
what resources are required from your attempt to describe the desired
behaviour.

>  With
> VHDL/Verilog...oh well, you may not get a simple and gate to fit into a
> 22V10 and you may spend months fighting tool problems that you may never be
> able to solve.

I've found that the Cypress VHDL tools (the version with my copy of Skahill,
anyway) cope perfectly well with 22V10's.  I had trouble with simpler
devices
like 16R8's which do not have output macrocells with programmable polarity.
As far as I can tell, unless you're very lucky (or perhaps careful -- I
never figured it out) the tools infer an implementation which is simply
impossible in the specified part.

> Personally, I would STRONGLY recommend considering Abel over
> VHDL/Verilog...

I would recommend learning both/all, and then using the appropriate tool for
the
job on a case-by-case basis.  But that's a somewhat idealistic viewpoint,
perhaps.

Mark
Article: 17918
Subject: Re: Question for Circuit Designers of Large High-Speed Boards: Best Means to
From: "Joseph A. Legris" <jlegris@xympatico.ca>
Date: Fri, 17 Sep 1999 00:54:04 GMT
Links: << >>  << T >>  << A >>
 May we presume that you are prepared to pay for such advice?

J.Legris

Article: 17919
Subject: Re: PROBLEMS WITH ORCA
From: "cort" <cortl@fast.net>
Date: 17 Sep 1999 01:51:05 GMT
Links: << >>  << T >>  << A >>
Dear Jose,
	I am an applications engineer for Lucent Technologies ORCA FPGAs.  I would
liketo get some more information from you about your design, but first of
all, are your instantiating your IO's?  Check in the EDIF and make sure
that there are IO buffers in the netlist.  Look for IBMs, BUF6, etc...  The
only time the mapper will remove nets is when there are no loads on them,
i.e. there are no IO primitives.
	If you could include some more information, as to your synthesis flow,
that would be helpful.
Take Care
Cort,

Mark Harvey <mark.harvey@farsystems.it> wrote in article
<9187BE60F64ED21189FE00609783E66303C9FB@PC022>...
I had a similar problem with Xilinx - all I/Os were removed because they
weren't connected to anything in the EDIF netlist. If I remember correctly,
I had to to set an option in my synthesis tool. The problem was something
to
do with ports in my VHDL source design not being translated into I/O in the
EDIF netlist. Sorry I can't be more specific.

Mark Harvey

> -----Messaggio originale-----
> Da:	Rickman [SMTP:spamgoeshere4@yahoo.com]
> Inviato:	martedì 14 settembre 1999 6.48
> A:	comp.arch.fpga@list.deja.com
> Oggetto:	Re: PROBLEMS WITH ORCA
> 
>  Message from the Deja.com forum: 
>  comp.arch.fpga
>  Your subscription is set to individual email delivery
> > 
> "José Luis Ayala" wrote:
> > 
> >         Hi,
> >         Anyone have any experience with FPGAs from Lucent (ORCA FPGA)?
> > I have a problem with the mapping process because the ORCA's software
> > clips and removes all my output ports, giving error messages like:
> > '<output_register_name>/NEOBUF (NEOINV) undriven or does not drive
> > anything', '<output_register_name>/NEOLATCH (NEOLATCH) undriven or does
> > not drive anything', '<pad_name>.PAD (NEOPAD) undriven or does not
drive
> > anything'.
> >         Thanks a lot
> > 
> > Jose Luis Ayala
> > Electronic Engineering Department
> > Technical University of Madrid
> > Spain
> > 
> >  Sent via Deja.com http://www.deja.com/
> >  Share what you know. Learn what you don't.
> 
> I am not an expert, but I might be able to help. But you will need to
> provide a little more info. What are you using for design entry, an HDL
> or schematic? If you think your IOs are being clipped, have you traced
> the netlist back to see what step is clipping them? Is it possible that
> your net list out of your front end tool is not really connecting the IO
> port to the rest of the circuit?
> 
> The error messages you give indicate that perhaps the rest of the
> circuit has been clipped. Or are those messages from the tool that is
> clipping the unconnected elements?
> 
> 
> -- 
> 
> Rick Collins
> 
> rick.collins@XYarius.com
> 
> remove the XY to email me.
> 
> 
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
> 
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
> 
> Internet URL http://www.arius.com
> 
> 
> 
>  _____________________________________________________________
>  Deja.com: Share what you know. Learn what you don't.
>  http://www.deja.com/
>  * To modify or remove your subscription, go to
>  http://www.deja.com/edit_sub.xp?group=comp.arch.fpga
>  * Read this thread at
>  http://www.deja.com/thread/%3C37DDD363.32FD1DD9%40yahoo.com%3E


 Sent via Deja.com http://www.deja.com/
 Share what you know. Learn what you don't.

----------

Article: 17920
Subject: Re: Xilinx XC4005E
From: Greg Neff <gregneff@my-deja.com>
Date: Fri, 17 Sep 1999 03:38:01 GMT
Links: << >>  << T >>  << A >>
In article <37E14ECE.67F75FC3@webspan.net>,
  ahdiii@webspan.net wrote:
> I was recently given 5 of these my a friend.  What do I need to learn
and get to
> program these?  All I have are the chips.  I'd like to build a DES
cracker out
> of the five chips for a science project that shows how the government
is holding
> back our crytography technology by keeping the strength of exportable
crypto
> limited.  Is it possible to put all 5 of these processors in parallel
and have
> them crunch away?  How would I program them, and in what language?
Where can I
> learn?  Any tutorails or books I could get?  My friend used to work
at Xilinx
> and National Semiconductor.  He said that he'd try to get me some
more stuff if
> I need it, such as the programming software.  I have stacks of books
from Xilinx
> on their chips, but I don't understand a word in them.  Please give
me resources
> and/or help.
>
> 					Thanks,
> 					Art Dardia
>

Check the Xilinx Foundations base software package, I think it's only a
couple of hundred dollars.  www.xilinx.com

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Article: 17921
Subject: Re: speeding up place and route
From: fliptron@netcom.com (Philip Freidin)
Date: 17 Sep 1999 06:22:01 GMT
Links: << >>  << T >>  << A >>
One of the most effective ways to speed up the place and route times
is to floor plan some or all of your designs. In particular, 
floorplanning of data path structures is rellatively easy to do and can 
radically improve the routing time, and also your design's performance.

Typically I floorplan just the data path part of my designs, and leave the
random logic and state machines up to the placer. You can see some good
examples of floorplanned designs in the "chip gallery" part of my web site
at www.fliptronics.com . Take particular note of some of the designs shown
at the bottom of the gallery page. I have designs that are 95% full
XC4085XLA that complete in about an hour. Without floorplanning it could
take days, and the results would suck, even if it did get to completion. 

Of course if you are using HDL's for your design specification, you dont 
have much hope.

Philip Freidin


In article <37E112B7.6EB46AA3@cs.colostate.edu>,
Geoff Yarbrough  <yarbroug@cs.colostate.edu> wrote:
>Does anyone know any nifty ways to reduce the place and route time with
>the Xilinx M1 PAR.  I know I can fiddle with PAR switch settings to help
>a little bit, but am wondering if there are any other ways to reduce the
>PAR time.
>
>I've toyed with the ideas of macros, but from what Xilinx says, macros
>are definitely not the way to go.  Is there any way to use them, (say by
>assigning only a reference component within the macro, and letting PAR
>do the rest) that will reduce PAR time.
>
>Admittedly I'm a novice at this, but any ideas or insights would be
>helpful.
>
>Thanks
>
>Geoff Yarbrough
>
Article: 17922
Subject: Re: Xilinx XC4005E
From: fliptron@netcom.com (Philip Freidin)
Date: 17 Sep 1999 06:38:31 GMT
Links: << >>  << T >>  << A >>
The Xilinx student edition version 1.5 can support these devices, and
includes schematic capture, simulation, VHDL, and verilog support.
It also comes with a GREAT book by David Van den Bout. $99.75
from Barnes and Noble.com 

ISBN is 0-13-020586-9


Philip Freidin


In article <37E14ECE.67F75FC3@webspan.net>,
Arthur Dardia  <ahdiii@webspan.net> wrote:
>I was recently given 5 of these my a friend.  What do I need to learn and get to
>program these?  All I have are the chips.  I'd like to build a DES cracker out
>of the five chips for a science project that shows how the government is holding
>back our crytography technology by keeping the strength of exportable crypto
>limited.  Is it possible to put all 5 of these processors in parallel and have
>them crunch away?  How would I program them, and in what language?  Where can I
>learn?  Any tutorails or books I could get?  My friend used to work at Xilinx
>and National Semiconductor.  He said that he'd try to get me some more stuff if
>I need it, such as the programming software.  I have stacks of books from Xilinx
>on their chips, but I don't understand a word in them.  Please give me resources
>and/or help.
>
>					Thanks,
>					Art Dardia


Article: 17923
Subject: Re: simple UART for ACTEL (SX) wanted
From: nospam_ees1ht@ee.surrey.ac.uk (Hans)
Date: 17 Sep 1999 07:11:17 GMT
Links: << >>  << T >>  << A >>
Not VHDL :-).. you might want to download Designer light or get a copy of their 
"free" Veribest development tool  which you can use up to the end of this year. 
This will be a lot quicker than doing it in schematics. However, if you insist 
on schematics an old April 1990 Actel databook contains an UART design for an 
old 1020,

Good luck,
Hans.


In article <7rqilu$1u87$1@black.news.nacamar.net>, purnhagen@ohb-system.de 
says...
>
>Hi again,
>
>hope somebody can help me.
>I am looking for a simple SCHEMATIC UART (not vhdl) for ACTEL FPGAs with 1
>start, 8 data, parity (even, odd, no), 1 stop bit.
>
>
>
>
>

Article: 17924
Subject: Re: Xilinx development board > XVC400
From: Bill Blyth <wdblyth@my-deja.com>
Date: Fri, 17 Sep 1999 08:48:06 GMT
Links: << >>  << T >>  << A >>
In article <37E163F0.5E97EBE1@_nospammm_ti.com>,
  Steve Martindell <s-martindell@_nospammm_ti.com> wrote:
> I'm looking for a Xilinx FPGA developement board with and XCV400
> or XCV600 Virtex.  The only Virtex development board I have found
> is the Virtual Computing board, which only has the XCV300.
>
>       steve martindell
>       s-martindell@ti.com
>
>
Try the ADC-RC1000 and ADM-XRC from www.alphadata.co.uk. They can
support V400 up to V1000 in BG560 package.

Bill
--


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


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