Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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
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
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
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: 17905New 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.comArticle: 17906
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
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 YarbroughArticle: 17908
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
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 BambynekArticle: 17910
> 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
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: 17912leejp@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
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 DardiaArticle: 17914
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> 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
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/~randrakaArticle: 17917
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. MarkArticle: 17918
May we presume that you are prepared to pay for such advice? J.LegrisArticle: 17919
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
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
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
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 DardiaArticle: 17923
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
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:
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