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
2017JanFebMarApr2017

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 14775

Article: 14775
Subject: Re: orcad
From: "Steve" <reply.through.newsgroup@paranoid.com>
Date: Tue, 16 Feb 1999 20:31:17 GMT
Links: << >>  << T >>  << A >>
Do you know of a convertor for Xilinx parts to Orcad symbol???

As I said previously the Orcad tool is buggy.  We ended up having
to do a manual coversion last time.

Steve

bob elkind wrote in message <36C9D257.D4E658F9@aracnet.com>...
>Here's a tool that I've used, and I'm very happy with it...
>
>See http://members.tripod.com/~ma_gm/al2or.html
>


/snip/

>****************************************************************
>Bob Elkind                              mailto:eteam@aracnet.com
>7118 SW Lee Road               part-time fax number:503.357.9001
>Gaston, OR 97119           cell:503.709.1985   home:503.359.4903
>****** Video processing, R&D, ASIC, FPGA design consulting *****
>
>


Article: 14776
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: Ray Andraka <randraka@ids.net>
Date: Tue, 16 Feb 1999 16:16:59 -0500
Links: << >>  << T >>  << A >>
John,

What about RLOC'ing instead of LOC'ing so that I can build reusable
macros?  I can't say that schematics are the best way to do FPGA designs
either.  It is just that it has been less painful than VHDL in the
majority of the cases I've dealt with, which tend to be heavily data
path signal processors.  I'll make it a point of cornering you at FPGA99
next week.



John McCluskey wrote:

>  Gee, I seem to getting into this thread a bit late.   I've been
> floorplanning with macros from high level VHDL for years (using
> Exemplar).  I did a 2C40 design in 1996 that tiled an array with a
> pair of interlocking hard macros using a double generate loop in
> VHDL.    It's not a big deal to write a VHDL function that generates
> the proper LOC string that attaches to the black box instance of the
> hard macro.   The real problem is trying to get the synthesis tool to
> recognize the timing arcs contained in a black box.
> This can be done more or less with the Leonardo tool using script
> commands, but I haven't seen any docs on ways to do this in the source
> code.  Look me up at FPGA 99 and I'll tell you about it.    My stance
> is that VHDL is absolutely the worst design method for FPGA's, except
> for all other methods.
>
> John McCluskey
>
> Ray Andraka wrote:
>
>> Hmm,  I evaluated both synplicity and exemplar a while back and
>> could not get
>> either to do it.  I spent a good part of DesignCon this past week
>> talking to
>> both and pretty much got the same answer from the FAEs.  Exemplar's
>> FAE was the
>> one that said that it wasn't the spirit of synthesis.  Nevertheless,
>> I plan on
>> re-evaluating  both in the coming weeks.  I already am aware the
>> FPGA express
>> won't do it.  I'm downloading Evan's page as I type.  I was
>> encouraged by
>> synplicity...their FAE said that this capability is supported in the
>> next
>> release.
>>
>


--
-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: 14777
Subject: Re: xnf de-compiler
From: Ray Andraka <randraka@ids.net>
Date: Tue, 16 Feb 1999 16:22:08 -0500
Links: << >>  << T >>  << A >>
Viewlogic viewgen will do it, but the XNF source is more readable than
the schematic it creates.

Sergio A. Cuenca Asensi wrote:

> Hello
> somebody knows any tool to get a schematic from a xnf netlist?. I am
> using FPGA Express  in a digital design course and
> this tool could be very useful for my students (and for me).
> Thanks
>
> --
> ===================================================================
> Sergio A. Cuenca Asensi
> Dept. Tecnologia Informatica y Computacion (TIC)
> Escuela Politecnica Superior, Campus de San Vicente
> Universidad de Alicante
> Ap. Correos 99, E-03080 ALICANTE
> ESPAŅA (SPAIN)
> email   : sergio@dtic.ua.es
> Phone : +34 96 590 39 34
> Fax     : +34 96 590 39 02
> ===================================================================



--
-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: 14778
Subject: Re: Xilinx Foundation Base = Useless?
From: Jaroslaw Kaczynski <JerryBear@cyberdude.com>
Date: Tue, 16 Feb 1999 21:37:31 GMT
Links: << >>  << T >>  << A >>

Jeff,

Are you familiar at all with the concept of design flow? If yes, I don't 
understand some of your complaints:
- validity checking and program execution in the flow depends on
existence 
  of some files and their correct time stamp: if schematic file is newer
  than the schematic netlist, it's quite obvious that you will be asked
  if you want to update the netlist; if there is no schematic (or other
  source file) at all, from the design flow foint of view there is
nothing 
  to simulate
- if you click on the simulator icon in the flow, why should it ask you
  about the netlist? Current project and design flow determine which
  netlist should be loaded. You should start simulator from the Tools
  menu if you want to load the netlist of your choice...

Re: hierarchy in the simulator. The only really flat netlists in the
whole
system are post-routed EDIFs - all designs prior to routing ARE
hierarchical
and CAN be simulated. If you are using EDIF netlist load feature, the
whole
design is expected to be in one, hierarchical netlist, with external
references
only to system macros and primitives. If you are loading XNF (netlist
format flat
by nature), top level netlist and all underlying netlists are converted
to
internal, binary format, then loaded into the simulator.
In any case, correct project type must be selected to provide access to 
corect system libraries.

Re: invisible signals. Signal names can disappear in the simulator in
two
cases: - the signal name starts with $ sign and the 'Display Hidden
Nets'
option in the preferences is disabled; - Signal name in the netlist
contains
illegal characters.

Thank you,

Jerry





Article: 14779
Subject: Re: Opinions requested : Minc/Synario alternatives
From: Nick <"nick[nospam]hartl"@earthlink.net>
Date: Tue, 16 Feb 1999 19:49:53 -0600
Links: << >>  << T >>  << A >>


milostnik@my-dejanews.com wrote:

> In article <796uds$cb3@news.rsc.raytheon.com>,
>   rjmyers@ti.com wrote:
> > As some/many of you may know, Minc/Synario closed their
> > doors and had turn over their assets to be liquidated
> > (see EETimes article, dated around Dec 18, 1998).
>
> By now evrybody knows that Minc/Synario has been sold to
> Xilinx. Or better said, Xilinx aquired what they thought was
> worth in Minc.
>
> > I am trying to determine what people/other organizations
> > are doing to support the programming of PLDs (and possibly
> > CPLDs) now that the company that supplied ABEL has shut down.
> > It appears that Logical Devices may be the only "non-biased"
> > vendor out their, with their CUPL system that targets
> > multiple PLD vendor devices.

Simple I am using a language that is not tied to one manufacture,.......
VHDL

>
>
> The original company that invented Abel, was Data I/O.
> Since they are more focused on doing HW programmers,
> they already "sold" Abel to Synario (Synario beeing a
> spin off company of DataIO. In turn, Synario
> was bought by Minc, wich at the time was doing well, and
> needed a front end (entry) to complete their raw PLS compiler.
>
> On the other hand other front end were used for Abel.
> Xilinx used the Synario tool in a reduced version for their
> XAbel tools. Similar at Viewlogic. Minc was selling the
> PLS compiler and doing wery strong with the Minc tools for
> CPLDs. Lattice used to sell an adapted Synario too.
>
> > Any thoughts/insights on this matter are welcomed.
>
> From the announces from Xilinx, it is clear that Xilinx
> is not interested in maintaning Synario a vendor indipendent
> tool. They seem to be only after the PLS compiler and the
> rights to Abel, that will be used in their Foundation tools.
> The foundation tool is now based on a Aldec entry and
> the Synopsys compiler.
>
> The options for a vendor indipendent tools now seem to
> revert to the usual tools for entry like Mentor, Viewlogic, Veribest.
> We bought Synario because at the time was a better tool than the
> mentioned tools and had one front end with at least two compilers
> (Synopsys and Metamor).
>
> But now we see a great fragmentaion in the vendor tools.
> Most vendors prefer to have their own (as usual icompatible) tools.
> Vendor indipendent tools seem to be disapearing or are monolitic
> and pricy tools.
>
> Moving from Synario to Mentor, ViewLogic, Veribest, Cadence or OrCad
> can be quiet a step. Few of them offer a so nice envirnment as Synario,
> even if all of them offer the same capability.
>
> Whats next. I think for a while I suggest to stay with the version
> of Synario that you have right now. In the mean time look arround
> and let me know....
>
> Bye
>   Matija
>
> > -Bob
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


Article: 14780
Subject: Re: Xilinx de-compiler
From: Nick <"nick[nospam]hartl"@earthlink.net>
Date: Tue, 16 Feb 1999 20:21:59 -0600
Links: << >>  << T >>  << A >>


David Kessner wrote:

> Sergio A. Cuenca Asensi wrote:
>
> > Take a look at Xilinx programmable logic data book. In the paper
> > "Configuration issues: Power-up, volatility,Security , Battery Back-up"
> > they say that Xilinx keeps  the interpretation of the bitstream closely
> > guarded secret and it is  virtually impossible to interpret the bitstream
> > in order to undestand the design or make modifications on it.
>
> I've read this too, but I question it greatly.  I question it for several
> reasons:
>
>     1.  I doubt that the "FPGA based supercomputer"
>         (http://www.starbridgesystems.com/release.html)
>         uses Xilinx place/route/bitstream software.  For a
>         computer like that to be remotely useful, they would need
>         something more integrated into their development tools.

>
> I think the "Super Computer" was debunked in another thread.

>     2.  Someone (I forget who) used a genetic algorithm to "program"

>        a Xilinx FPGA to detect two tones.  This program basically
>         randomly generated xilinx bitstreams in a "genetic
>         permutation" way.  But, before actually programming the
>         xilinx, the bitstream was checked for faults that would
>         have fried the chip (bus contention, etc.).  So, this guy
>         would have had to know what the bitstream file did

Sounds like a 6200 design.  Xilinx was more informative about this part because
of the need for "on the fly Re-config:"

> .
>     3.  Xilinx has a "warning" on their web site about companies
>         that are doing some "rescreening" of their chips.  Basically
>         they are retesting and sorting the FPGA's to upgrade them
>         from Commercial to Industrial or Military temperature/voltage
>         range.  This warning didn't outright say it, but it implied
>         that these guys are playing around with the bitstream files.

I think I could figure a way to kinda test if a part was fast without having to
know all the the detatils of the bit steam.  Just load some boardline designs
into it and run it at the up rated clock.  If the part works say it is a dash
what ever.  Who said chip pirates were perfictly up front with their test
reults or that their tests were complete??

Have FUN!!!
Nick

>
>
> While, this isn't hard evidence, it passes at least a
> casual definition of "reasonable doubt", IMHO.
>
> If the original poster really wants to protect his design,
> I'd recommend using an antifuse based FPGA (I.E., Quicklogic)
> or a CPLD.  Once programed, it would be very difficult to
> read back the program from the chip.  Most of the time, you'd
> have to open the chip up and inspect it visually-- way beyond
> what almost everyone are capable of.
>
> David Kessner
> davidk@peakaudio.com


Article: 14781
Subject: Re: Xilinx de-compiler
From: Nick <"nick[nospam]hartl"@earthlink.net>
Date: Tue, 16 Feb 1999 20:24:50 -0600
Links: << >>  << T >>  << A >>


timolmst@cyberramp.net wrote:

> I may be wrong, but I believe that Orcad Express has a function to
> read an XNF file in,

>>An XNF file is not a bit steam.



> and generate VHDL from it. It's been awhile since
> I had that package loaded, but that's what I seem to remember. Don't
> know how complex a design it can handle. I do know that Orcad Express
> can import ABEl and turn it into VHDL.
>
> Tim Olmstead
> email : timolmst@cyberramp.net
> Visit the unofficial CP/M web site.
> MAIN SITE AT            : http://www.devili.iki.fi/cpm
> PRIMARY US MIRROR AT    : http://www.mathcs.emory.edu/~cfs/cpm
> SECONDARY US MIRROR AT  : http://CPM.INTERFUN.NET


Article: 14782
Subject: Re: Xilinx Spartan and pin-locking
From: ibaggett@bagotronix.com
Date: Wed, 17 Feb 1999 05:04:17 GMT
Links: << >>  << T >>  << A >>
On 15 Feb 1999 18:52:15 GMT, "Austin Franklin" <austin@dark0room.com>
wrote:


>If you do your floorplanning before choosing your pinout, you should have
>no problems.  I strongly recommend that you don't let the tools choose the
>pinout for you!  I don't know what frequency you are running, but I pinlock
>all the time.  By understanding the architecture of the FPGA, you can
>figure out how your design can best be placed in the design.  Also,
>registering the I/Os in the IOB helps dramatically too ;-)
>
>Austin Franklin
>austin@darkroom.com
>

I have not used the Xilinx parts yet (I do have the Foundation 1.5i
system), but I have used Lattice 2XXX series CPLDs.  I think it is
better to let the software choose pins for you than to pin-lock, since
it can do a better job of routing if it is free to choose pins.  You
should pin-lock only after the logic design is completed and
reasonably stable.  If this practice is not good for the Xilinx FPGA,
please explain why.

The original poster was essentially implying that he designs his
boards *before* designing the FPGA logic for them.  Not a practice I
would recommend - how do you know you have enough logic if you haven't
designed it yet?  I personally know of design projects (not mine)
where the design went through 4 revisions and still didn't have a
working board because the designer did not design his logic first.

Best regards,
Ivan Baggett
Bagotronix

Article: 14783
Subject: Re: Xilinx Foundation Base = Useless?
From: Jeff Hunsinger <huns@mediaone.net>
Date: Tue, 16 Feb 1999 23:04:49 -0600
Links: << >>  << T >>  << A >>
I'm familiar with design flows. Not all of them are so restrictive. The
more forgiving flows allow you to manipulate files outside the flow as
needed. Hence, I've given up on the Project Manager and work around it
instead.

The problem I experienced with automatic netlist loading was when I
selected File->Load Netlist from the simulator. A dialog window would
pop up, then instantly disappear as it proceeded to load in an undesired
netlist. Occasionally, it would work properly and allow me to actually
select the file. It's not consistent. I've found that by launching the
simulator on its own instead of from the framework, this bug disappears.

Also, XNF is only flat after the files have been merged. My netlisted
was omitting that step.

I've managed to make do with what I have. It's a pain, but I guess I
expected too much from a $99 tool. I remember paying $10k just for the
Neocad place and route tools only a few years ago, so progress is being
made. I'll spend a few more bucks and get VHDL to alleviate the pain.

Regards,
Jeff
Article: 14784
Subject: Re: Flex6016 config. problem.
From: fliptron@netcom.com (Philip Freidin)
Date: Wed, 17 Feb 1999 07:09:34 GMT
Links: << >>  << T >>  << A >>
Check the signal integrity on your configuration clock. In particular, 
look at both the rising and falling edge with a 300MHz scope (or better. 
a 100MHz or 200MHz scope can miss clock problems that the FPGA/EPROM can 
react to). Check at both ends of the trace, and check BOTH edges. 
Remember to keep the scope ground wire as short as possible (less than 2 
inches would be a good goal.) You are looking for "U" turns in the edges 
of the clock during the transitions. These can be only a few nanoseconds 
wide, and maybe only a few 100 mV high.
If you see anything like this, you have a termination problem that you
must remedy.

Philip




In article <7acf3t$1hug$1@nnrp01.iafrica.com> "Anthony Ellis - LogicWorks" <aelogic@iafrica.com> writes:
>On a new design (there are at least half a dozen similar designs working
>using the same devices and configuration setup) I am having problems
>configuring a Flex6016 using EPC1441 or EPC1. The device starts the config.
>cycle but aborts after about 6000 bits. (~6us at 140ns/bit) presumable
>because of a detected CRC error. Why just this one design I don't know. No
>other pins toggle during the config process although there are many unused
>floating pins????
>
>Any ideas?
>
>


Article: 14785
Subject: Re: Synplify resource usage report for Virtex devices
From: mushh@jps.net (David Decker)
Date: Wed, 17 Feb 1999 07:44:56 GMT
Links: << >>  << T >>  << A >>
Eduardo,

First be sure you really need FIFOs and not just temporary storage.

If you can use temporary storage than try to use the distributed RAM
in the 4000 series part. Each CLB can be used as 32 bits of RAM
storage plus 2 bits of flip flop storage for a total of 34 bits. 

From your description it looks like some of this could be done with
shift registers configured from RAM. Fill with data from one source,
then read while transferring data to the destination.

If you truly must have completely asynchronous, simultaneous read and
write, then try to use 4000 series Dual Port RAM. Each CLB can be used
as 16 bits of Dual Port RAM.

I doubt you really need Virtex, but if you do use it, don't forget its
Block RAM.

In short, use RAM for memories, as much as possible, speed permitting,
to save Flip Flops.

Cheers,

Dave Decker
Diablo Research Co LLC


Dave Decker
Diablo Research Co. LLC

Please use only one 'h' in mush. I'm trying to reduce the spam.



"Animals .  .  . are not brethren they are not 
underlings;  they are other nations, 
caught with ourselves in the net of life and time, 
fellow prisoners of the splendor and travail of 
the earth."
Henry Beston -  The Outermost House
Article: 14786
Subject: Re: Synplify resource usage report for Virtex devices
From: fliptron@netcom.com (Philip Freidin)
Date: Wed, 17 Feb 1999 09:00:22 GMT
Links: << >>  << T >>  << A >>

Well, from your second email, it looks like I "nailed it" in my previous 
response. What you are building is basically memories, and the fifos look 
like you are using them as shifters (but could be also memories, you dont 
quite give enough info to tell).

Unfortunately, VHDL has lived up to its promise of architecture
independent design, and has built your design out of a huge array of 
flip flops. Your synthesis tool has totally ignored the fact that the 
Xilinx chips have memory capability both in the CLBs, and in the case of 
Virtex, as sepparate blocks as well.

Unless your synthesis program has some way of inferring memories (which 
may only require a change in your coding style), the only way to get at 
the memories that are prebuilt into the FPGAs is to directly instantiate 
them. This will require more work on your part (both in coding, and in 
learning what these FPGAs are really capable of), but the pay back is 
potentially huge.

Your current design is reporting that it needs about 15500 CLBs (the packed 
number), in a XC40150XV, nominally a 150K (marketing) gate device.
 
>> Logic Mapping Summary:
>> FMAPs: 31017 of 10952 (284%)
>> HMAPs: 14037 of 5476 (257%)
>> Total packed CLBs: 15509 of 5476 (284%)

You asked whether your design would fit into a XCV1000 (1000K Marketing 
gates).

In raw FMAPS, the XCV1000 has 24576 FMAPs, and no HMAPs, and 24576 FFs, 
so it looks like it might be a problem. 

So lets look at what you really need for this application.

(for all calcs below, note that a 4 to 1 mux requires 1 CLB, so a 16 to 
1 mux requires 4 of these to get from 16 signals down to 4 signals, and 1 
more to get the final output. All calcs are for XC4000/E/EX/XL/XV style 
CLBs, with 2 flip flops, and 2 LUT/FMAP/Functiongenerators each. Since 
Virtex CLBs are basically like two of the XC4000 type CLBs, just halve 
the numbers to get a feel of what it would require in Virtex.)

First the FIFOs, which are 256 by 5  bits, and there are two of them.
What is not clear is whether you are reading the FIFOs at the same time 
you are writing them, and if you are doing both, whether the read clock 
and write clock are the same.

Worst case: reading and writing at same time, different clock. 256 by 1
requires 16 CLBs of dual-port memory (16 bits per CLB), plus a 16 to 1 mux
on the output that requires 5 CLBs, for a total of 21CLBs. for 5 bits
wide, this 105 CLBs, times 2 FIFOs, is a total 210 CLBs. There is some
overhead in address decode and read write logic, which is probably less
than 50 CLBs. 

So: worst case, two FIFOs of 256 x 5  => 260 CLBs

Best case would be only read or write at any time, only 1 clock: 256 by 1
requires 8 CLBs of single port memory (32 bits per CLB), plus an 8 to 1
mux on the output that requires 3 CLBs, for a total of 11CLBs. for 5 bits
wide, this 60 CLBs, times 2 FIFOs, is a total 120 CLBs. There is some
overhead in address decode and read write logic, which is probably less
than 50 CLBs. 

So: best case, two FIFOs of 256 x 5  => 170 CLBs

Next, lets look at the big block of RAM, 1K by 8

Assume read or write, but not both at same time, so single ported RAM, at 
32 bits per CLB:

1024 bits requires 32 CLBs, and a 32 to 1 mux (probably wil want to be 
pipelined, but the flipflops are free). 11 CLBs for the mux, so 43 CLBs 
per bit of this RAM. About 30 CLBs of address and control logic.

1K by 8 single port RAM   => 43 x 8 + 30 => 374 CLBs.

128 Bytes of output format memory. Your description makes it clear that 
this can be single ported, so:

5 CLBs per 128 bits (4 for the RAM, and 1 for a 4 to 1 mux), times 8,
plus about 10 CLBs for decode and control:

128 by 8 single port RAM => 5 x 8 + 10 => 50 CLBs.

So worst case your memory requirements could be handled by 

260 + 374 + 50 => 684 CLBs.

An XC4028XL has 1024 CLBs.

For an example of a similar design (Direct Sequence Spread Spectrum) 
Satellite communications, you may want to look at my web page, in the 
Chip Gallery:

www.fliptronics.com/gallery.html, and look at the second last FPGA (and 
maybe also the last one too:

"MFILT"
"The chip is an XC4028EX that implements two 256 stage match filters for
decoding a Spread Spectrum Satellite signal. This design uses a hybrid of
distributed arithmetic, serial/parallel computation, and required very
careful floorplanning. The design includes ROMs, RAMs, carry logic, and a
small ammount of control logic. Operating at 32MHz, it performs 256
multiplies (8 bit) and 254 adds (9 to 15 bit) every 4 clock, delivering
slightly over 4 billion operations per second. "


I believe you have three realistic options:
Find out if your synthesiser can infer RAMs, and if so change your coding 
style to suit.

Find out how to instantiate single and/or dual port RAM with your 
synthesis tools, and do a more detailed design, and instantiate all the 
RAMs directly.

Look into Xilinx's Coregen software. Maybe it can build the RAMs for you.

Non realistic option (but what I do for a living):
Redo the design with schematics, where you don't get situations like a 
design that fits in a XC4028XL not fitting into a XCV1000.

So we should also talk a little about a Virtex option for you too.
Virtex has LOTS more RAM than the 4000XL stuff described above, as block 
RAM, of 4096 bits each. For your application, the following 
configurations would seem to be appropriate:

For the FIFOs, a block configured as 256 by 16 would meet your 
requirement of 256 by 5. You just waste the other 11 bits. Times 2

For the 1K by 8, use two blocks configured as 1K by 4.

For the output RAM, 128 by 8, use one more block in 256 by 16 mode, and 
ground one of the address lines, and waste 8 of the 16 bits.

Looks like you need 5 such blocks. The smallest Virtex part, the XCV50 has
8 such blocks.

Of course, you still have the issue of how to get synthesis to 
instantiate these blocks, but it is probably simpler than the 
instantiating and stitching together CLB RAMs.


Looks like you have some fun ahead of you, but it shouldn't be in an XCV1000.


Philip Freidin.



In article <36C9A5DE.842C79C7@sussex.ac.uk> Eduardo Augusto Bezerra <E.A.Bezerra@sussex.ac.uk> writes:
>
>Philip Freidin wrote:
>> 
>> You seem to be using an insane number of flip flops, given the amount of
>> logic you are implementing. Over 11000 flipflops and over 8000 muxF5/F6,
>> almost no I/O, and almost no logic, ( I am asuming the Luts are doing
>> route thru or more muxes, as there is no reported logic in the
>> " Resource Usage Report" section.) Are you implementing a huge shifter,
>> or maybe a memory, and it is being implemented in FFs????
>> 
>> Imagine how much more help people could give you, if you had actually
>> described you application!
>> 
>> Philip.
>> 
>
>Ok. I'll try to describe my application.
>
>It's an ACF (auto correlation function) implemented in VHDL.
>The reports I post in my first message were from the low frequency
>module that basically:
>
>- receive data from IP1_IN and IP2_IN inputs (see entity
>  definition bellow);
>- store the data in two FIFOs (256x5 bits each one);
>- read the FIFOs and build a histogram in an 1 Kbytes memory
>  (the memory addresses are selected according to the
>   LAST_ENERGY_IN input);
>- transfer blocks of data from the 1 Kbytes memory to an 128 bytes
>  memory and put them in a specific format, according to a 
>  protocol, in order to the telemetry data be sent to the Earth
>  by the LIMBO_OUT output (it is a space application);
>- read the 128 bytes memory, convert the data from the parallel
>  to the serial format and send them to the LIMBO_OUT output.
>
>As you said, there is almost no I/O, and almost no logic. It is
>really a memory transfer application. Why do we want to use FPGAs?
>Because we want to change (reconfigure) the on-board hardware from
>the Earth.
>
>I've included bellow some definitions I used in my design.
>
>But what I really want to know is if my design fits in the V1000
>Virtex. The synplify report for the XC40150XV FPGA gave me the
>follow information:
>
>> Logic Mapping Summary:
>> FMAPs: 31017 of 10952 (284%)
>> HMAPs: 14037 of 5476 (257%)
>> Total packed CLBs: 15509 of 5476 (284%)
> 
>I don't know if it is possible to get this information for
>the V1000 Virtex FPGA. I'm interested in the % data.
>
>Eduardo.
>
>
>entity SVALHF is
>
>  port ( CLK_IN          : in  std_logic;  -- Global clock
>         RESET_NEG_IN    : in  std_logic;  -- Global reset
>         NEW_STEP_NEG_IN : in  std_logic;  -- New energy step pulse
>         LAST_ENERGY_IN  : in  std_logic_vector(3 downto 0);
>         IP1_IN          : in  std_logic;  -- Input1
>         IP2_IN          : in  std_logic;  -- Input2
>         TELEMTRY_CLK_IN : in  std_logic;  -- Telemetry clock
>         NEXT_OP_BIT_IN  : in std_logic;   -- Next O/P request
>         LIMBO_OUT       : out std_logic   -- Output data
>       );
>
>end SVALHF;
>
>architecture SVALHF_BEH of SVALHF is
>
>   component FSM_HF
>      port ( CLK_IN          : in  std_logic;
>             RESET_NEG_IN    : in  std_logic;
>             IP_IN           : in  std_logic;
>             WR_NEG_FIFO_OUT : out std_logic;
>             DATA_OUT        : out std_logic_vector (4 downto 0)
>           );
>   end component;
>
>   component FIFO_HF
>      port ( RESET_NEG_IN   : in  std_logic;
>             RD_NEG_IN      : in  std_logic;
>             WR_NEG_IN      : in  std_logic;
>             DATA_IN        : in 
>std_logic_vector(WORD_LENGTH_FIFO_HF_C-1 downto 0);
>             DATA_OUT       : out
>std_logic_vector(WORD_LENGTH_FIFO_HF_C-1 downto 0);
>             FIFO_HALF_OUT  : out std_logic;
>             FIFO_EMPTY_OUT : out std_logic;
>             FIFO_FULL_OUT  : out std_logic
>           );
>   end component;
>
>   component PAR2SER_HF
>      port( CLK_LD_IN    : in  std_logic;
>            CLK_SHIFT_IN : in  std_logic;
>            DATA_IN      : in  std_logic_vector( SIZE_OF_PAR2SER_HF_C -
>1 downto 0 );
>            DATA_OUT     : out std_logic
>           );
>   end component;
>
>   -- declarations for component FSM1_HF
>   signal CLK_FSM1_HF, RESET_NEG_FSM1_HF,
>          IP_FSM1_HF                      : std_logic;
>   signal WR_NEG_FIFO_FSM1_HF             : std_logic;
>   signal DATA_FSM1_HF                    : std_logic_vector (4 downto
>0);
>
>   -- declarations for component FSM2_HF
>   signal CLK_FSM2_HF, RESET_NEG_FSM2_HF,
>          IP_FSM2_HF                      : std_logic;
>   signal WR_NEG_FIFO_FSM2_HF             : std_logic;
>   signal DATA_FSM2_HF                    : std_logic_vector (4 downto
>0);
>
>   -- declarations for component FIFO1_HF
>   signal RESET_NEG_FIFO1,
>          RD_NEG_FIFO1, WR_NEG_FIFO1      : std_logic;
>   signal DATA_OUT_FIFO1, DATA_IN_FIFO1   :
>std_logic_vector(WORD_LENGTH_FIFO_HF_C-1 downto 0);
>   signal FIFO1_HALF_FULL, FIFO1_EMPTY,
>          FIFO1_FULL                      : std_logic;
>
>   -- declarations for component FIFO2_HF
>   signal RESET_NEG_FIFO2,
>          RD_NEG_FIFO2, WR_NEG_FIFO2      : std_logic;
>   signal DATA_OUT_FIFO2, DATA_IN_FIFO2   :
>std_logic_vector(WORD_LENGTH_FIFO_HF_C-1 downto 0);
>   signal FIFO2_HALF_FULL, FIFO2_EMPTY,
>          FIFO2_FULL                      : std_logic;
>
>   -- declarations for component PAR2SER_HF
>   signal CLK_LD_PAR2SER,
>          CLK_SHIFT_PAR2SER               : std_logic;
>   signal DATAIN_PAR2SER                  : std_logic_vector(
>SIZE_OF_PAR2SER_HF_C - 1 downto 0 );
>   signal DATAOUT_PAR2SER                 : std_logic;
>
>   -- declarations for TELEMETRY_HF
>   signal DATA_TELEMETRY                  : std_logic_vector(
>SIZE_OF_PAR2SER_HF_C - 1 downto 0 );
>
>   -- declarations for SVALHF
>   signal MEM1                            : RAM1K_TYP;     -- SRAM
>memory (1K bytes)
>   signal M1_PTR                          : std_logic_vector(9 downto
>0);
>   signal AUX_M1_PTR                      : std_logic_vector(9 downto
>0);
>   signal MEM2                            : RAM68_TYP;     -- SRAM
>memory (32 bytes)
>   signal M2_PTR                          : std_logic_vector(6 downto
>0);
>   signal AUX_DATA                        :
>std_logic_vector(WORD_LENGTH_FIFO_HF_C-1 downto 0);
>   signal FLAG_POWERUP                    : std_logic;
>   signal FLAG_WHICH_IP, DATA_READY       : std_logic;
>   signal OP_BLK_ENERGY                   : std_logic;
>   signal FLAG_NEW_NEXT_OP,
>          FLAG_NEXT_OP_REQ                : std_logic;
>   signal FLAG_NEW_ESTEP,
>          FLAG_NEW_ESTEP_OLD              : std_logic;


Article: 14787
Subject: Free circuit design
From: "J. Khatib" <khatib@ieee.org>
Date: Wed, 17 Feb 1999 11:56:19 +0200
Links: << >>  << T >>  << A >>
Hi
Do you like to have excellent pre-made designs for free?  Do you believe
that free design ideas can push design towards better solutions?
This what I believe, why not do not, have you seen what does the free
software do to the large companies like MS? the Free OS "Linux" and its
application is now the only competitor to MS. This is because those who
build this system gathers lot of ideas from people from all over the
world and made things that can handle what they want not what a single
man wants.

Do you think building free software is easier than building free
hardware. yes I know but lets try first.

I think the easiest hardware that can be built, is the reusable ASIC or
FPGA cores. This is the tech. trend now to build soft cores. that can be
integrated together to make SOC tech.

Tools!?   we can use the free tools designed by linux programmers who
need people to improve their tools by using them in real projects.

What I am thinking now is to build a DSP processor core and implement it
on FPGAs because this is the easiest way to verify the design.
I invite all those interested in this topic to help me " I am in the
phase of selecting a good architecture and I need your help" and to
visit this site 
http://www.geocities.com/SiliconValley/Pines/6639/freecir/free_circuit.html
and to give a feed back about this idea by replying to this message and
making a CC to khatib@ieee.org
Note: I did not prepare this site only I liked the ideas it discusses


Thanks in advance for your time
Article: 14788
Subject: Re: Xilinx Spartan and pin-locking
From: Keith Wootten <Keith@wootten.demon.co.uk>
Date: Wed, 17 Feb 1999 11:09:59 +0000
Links: << >>  << T >>  << A >>
In article <36ca4be7.22179624@news.nettally.com>,
ibaggett@bagotronix.com writes

[snip]

>I have not used the Xilinx parts yet (I do have the Foundation 1.5i
>system), but I have used Lattice 2XXX series CPLDs.  I think it is
>better to let the software choose pins for you than to pin-lock, since
>it can do a better job of routing if it is free to choose pins.  You
>should pin-lock only after the logic design is completed and
>reasonably stable.  If this practice is not good for the Xilinx FPGA,
>please explain why.
>
>The original poster was essentially implying that he designs his
>boards *before* designing the FPGA logic for them.  Not a practice I
>would recommend - how do you know you have enough logic if you haven't
>designed it yet?  I personally know of design projects (not mine)
>where the design went through 4 revisions and still didn't have a
>working board because the designer did not design his logic first.

For a low volume project, it can sometimes be more cost-effective to
design the PCB first and lock the FPGA pins.  The money saved on PCB
design (for example, fewer layers and lower NRE charges) can outweigh
the extra spent on a larger FPGA.

Cheers
-- 
Keith Wootten
Article: 14789
Subject: Re: xnf de-compiler
From: "Craig Slorach" <craigs@elec.gla.ac.uk>
Date: Wed, 17 Feb 1999 12:23:18 -0000
Links: << >>  << T >>  << A >>
The program is called 'xnf2wir' and is included on the XACT 5/6 CD- sadly
not on M1- you run the xnf through this and then use ViewGen to generate the
final schematics- works fairly well. Out of interest does anyone know if
there is an updated version of 'xnf2wir' available (my machine under NT
keeps looking to the floppy drive for some reason) ?

Craig


Bruce Nepple wrote in message ...
>Viewlogic used to draw schematics from xnf.
>



Article: 14790
Subject: Re: Synplify resource usage report for Virtex devices
From: Eduardo Augusto Bezerra <E.A.Bezerra@sussex.ac.uk>
Date: Wed, 17 Feb 1999 13:24:35 +0000
Links: << >>  << T >>  << A >>

Thank you for the detailed explanation. I know I have a long way
ahead. I think my big mistake was to try to use the technology
independent feature of VHDL. Just in case, I'll save the present
version in a safe place, and I hope in few years I can synthesize
it properly.

I'm going to make some changes in my design in order to turn it
a device specific one.

Many thanks

Eduardo.


P.S. Some answers for your questions:

Philip Freidin wrote:
> 
> Well, from your second email, it looks like I "nailed it" in my previous
> response. What you are building is basically memories, and the fifos look
> like you are using them as shifters (but could be also memories, you dont
> quite give enough info to tell).
> 

You are right. I think they can be implemented as shifters, because
there is one module (input module) that keep writing to the FIFOs,
and another module ("processing") that keep reading the FIFOs. The
problem is that there are two different clocks.

> Unless your synthesis program has some way of inferring memories (which
> may only require a change in your coding style), the only way to get at
> the memories that are prebuilt into the FPGAs is to directly instantiate
> them. This will require more work on your part (both in coding, and in
> learning what these FPGAs are really capable of), but the pay back is
> potentially huge.
> 

Synplify can infer memory. From the Synplify documentation:

"VHDL RAM Inferencing
Synplify can infer, from your VHDL source code, synchronous RAMs and
generate the
appropriate single or dual port RAMs. No special input such as
attributes or constraints
are need for this to happen. RAMs being mapped to Altera technology will
be mapped to
LPMs, while RAMs being mapped to Xilinx technology will be mapped to
Select-RAMs."

And there is an example in the documentation:

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity ram_test is
port (
   d : in std_logic_vector(7 downto 0);
   a : in std_logic_vector(6 downto 0);
   we : in std_logic;
   clk : in std_logic;
   q : out std_logic_vector(7 downto 0));
end ram_test;
architecture rtl of ram_test is
   type mem_type is array (127 downto 0) of
   std_logic_vector (7 downto 0);
   signal mem: mem_type;
   signal read_add : std_logic_vector(6 downto 0);
begin
   q <= mem(conv_integer(read_add));
   process (clk)
   begin
      if rising_edge(clk) then
         if (we = '1') then
            mem(conv_integer(read_add)) <= d;
         end if;
         read_add <= a;
      end if;
   end process;
end rtl ;

This was "almost" exactly what I've implemented. The source code
for my FIFO implementation is included at the end of this
message. I know it is not the best implementation, but it is
working well.

> 
> First the FIFOs, which are 256 by 5  bits, and there are two of them.
> What is not clear is whether you are reading the FIFOs at the same time
> you are writing them, and if you are doing both, whether the read clock
> and write clock are the same.
> 
> Worst case: reading and writing at same time, different clock. 256 by 1
> requires 16 CLBs of dual-port memory (16 bits per CLB), plus a 16 to 1 mux
> on the output that requires 5 CLBs, for a total of 21CLBs. for 5 bits
> wide, this 105 CLBs, times 2 FIFOs, is a total 210 CLBs. There is some
> overhead in address decode and read write logic, which is probably less
> than 50 CLBs.
> 
> So: worst case, two FIFOs of 256 x 5  => 260 CLBs
> 

Yes, I'm reading and writing in parallel, and using different clocks.

> 
> So worst case your memory requirements could be handled by
> 
> 260 + 374 + 50 => 684 CLBs.
> 
> An XC4028XL has 1024 CLBs.
> 
> 
> I believe you have three realistic options:

I'll try all of them, starting by the first one.

Thanks again

Eduardo.


------------------------------------------
Package
------------------------------------------
library IEEE;
   use IEEE.std_logic_1164.all;

package SVAL_PKG is
   --
   -- Definitions for entity FIFO_HF (file fifo_hf_ea.vhd)
   --
   -- FIFO has 256 words, each word == 4 bits
   --
   constant WORD_LENGTH_FIFO_HF_C : integer := 5;    
   constant FIFO_HF_SIZE_C        : integer := 7; --255;
   constant FIFO_HALF_FULL_HF_C   : integer := 4; --128;
   type     RAM_FIFO_HF_TYP is array(FIFO_HF_SIZE_C downto 0) of
            std_logic_vector(WORD_LENGTH_FIFO_HF_C-1 downto 0);

.
.
.
end SVAL_PKG;


------------------------------------------
FIFO
------------------------------------------
library ieee;
   use ieee.std_logic_1164.all;
   use IEEE.std_logic_arith.all;
   use IEEE.std_logic_unsigned.all;
   use work.SVAL_PKG.all;
entity FIFO_HF is
   port ( RESET_NEG_IN   : in  std_logic;     -- '0' -> reset FIFO
          RD_NEG_IN      : in  std_logic;     -- '0' -> read FIFO
          WR_NEG_IN      : in  std_logic;     -- '0' -> write FIFO
          DATA_IN        : in  std_logic_vector(WORD_LENGTH_FIFO_HF_C-1
downto 0);
          DATA_OUT       : out std_logic_vector(WORD_LENGTH_FIFO_HF_C-1
downto 0);
          FIFO_HALF_OUT  : out std_logic;     -- '1' when FIFO is > half
full
          FIFO_EMPTY_OUT : out std_logic;     -- '1' when FIFO is empty
          FIFO_FULL_OUT  : out std_logic      -- '1' when FIFO is full
        );
end FIFO_HF;

architecture FIFO_HF_BEH of FIFO_HF is
   signal COUNT, COUNT_RD,
          COUNT_WR              : std_logic_vector (8 downto 0);
   signal LAST_IDX, FIRST_IDX   : std_logic_vector (7 downto 0);
   signal MEM_FIFO_HF           : RAM_FIFO_HF_TYP;
   signal FIRST_TIME            : std_logic;
   signal FLAG_FIFO_EMPTY,
          FLAG_FIFO_FULL        : std_logic;

begin

   FIFO_WR_PRO: process(RESET_NEG_IN, WR_NEG_IN, COUNT, LAST_IDX )
   begin
      if RESET_NEG_IN = '0' then
         -- Initialization to avoid synplify warnings. In the design
         -- there is no need to initialize the FIFO with zeros.
         for i in 0 to FIFO_HF_SIZE_C loop
            MEM_FIFO_HF(i) <=  "00000";
         end loop;
         -- These intializations are necessary
         LAST_IDX          <= "00000000";
         FLAG_FIFO_FULL    <= '0';
         COUNT_WR <= "000000000";
      elsif WR_NEG_IN'event and WR_NEG_IN = '0' then
         if COUNT <= FIFO_HF_SIZE_C then    -- FIFO is not full
            FLAG_FIFO_FULL  <= '0';
            COUNT_WR <= COUNT + 1;
            MEM_FIFO_HF(conv_integer(LAST_IDX)) <= DATA_IN;
            if LAST_IDX = FIFO_HF_SIZE_C then
               for i in 0 to FIFO_HF_SIZE_C loop
                  MEM_FIFO_HF(i) <=  "00000";
               end loop;
               LAST_IDX <= "00000000";
            else
               LAST_IDX <= LAST_IDX + 1;
            end if;
         else
            FLAG_FIFO_FULL  <= '1';
         end if;
      end if;
   end process FIFO_WR_PRO;

   FIFO_RD_PRO: process(RESET_NEG_IN, RD_NEG_IN, COUNT, FIRST_IDX )
   begin
      if RESET_NEG_IN = '0' then
         DATA_OUT          <= "00000";
         FIRST_IDX         <= "00000000";
         COUNT_RD          <= "000000000";
         FLAG_FIFO_EMPTY   <= '1';
         FIRST_TIME        <= '1';
      elsif RD_NEG_IN'event and RD_NEG_IN = '0' then
         if COUNT > 0 then  -- FIFO is not empty
            FIRST_TIME      <= '0';
            FLAG_FIFO_EMPTY <= '0';
            COUNT_RD        <= COUNT - 1;
            DATA_OUT  <= MEM_FIFO_HF(conv_integer(FIRST_IDX));
            if FIRST_IDX = FIFO_HF_SIZE_C then
               FIRST_IDX <= "00000000";
            else
               FIRST_IDX <= FIRST_IDX + 1;
            end if;
         else
            COUNT_RD        <= "000000000";
            FLAG_FIFO_EMPTY <= '1';
         end if;
      end if;
   end process FIFO_RD_PRO;

   COUNT <=        "000000000" when RESET_NEG_IN = '0' else
                   COUNT_WR    when ((WR_NEG_IN    = '0') or (FIRST_TIME
= '1')) else
                   COUNT_RD    when RD_NEG_IN    = '0';

   FIFO_HALF_OUT   <= '0' when RESET_NEG_IN = '0' else
                      '1' when COUNT >= FIFO_HALF_FULL_HF_C else
                      '0';
   FIFO_EMPTY_OUT  <= '1' when RESET_NEG_IN = '0' else
                      '0' when ((COUNT > 0) and (FIRST_TIME = '1')) else
                      FLAG_FIFO_EMPTY;
   FIFO_FULL_OUT   <= '0' when RESET_NEG_IN = '0' else
                      FLAG_FIFO_FULL;

end FIFO_HF_BEH;



--
E.A.Bezerra@sussex.ac.uk
http://www.sussex.ac.uk/engg/research/space/
Article: 14791
Subject: Re: Xilinx Spartan and pin-locking
From: Ray Andraka <randraka@ids.net>
Date: Wed, 17 Feb 1999 10:04:10 -0500
Links: << >>  << T >>  << A >>


ibaggett@bagotronix.com wrote:

> I have not used the Xilinx parts yet (I do have the Foundation 1.5i
> system), but I have used Lattice 2XXX series CPLDs.  I think it is
> better to let the software choose pins for you than to pin-lock, since
> it can do a better job of routing if it is free to choose pins.  You
> should pin-lock only after the logic design is completed and
> reasonably stable.  If this practice is not good for the Xilinx FPGA,
> please explain why.
>

If you aren't willing to do a little up-front floorplanning, then go ahead an
let the tool assign the pins.  Be warned however, that re-running PAR will
generate a different solution, even if none of the logic is changed unless you
reuse the same seed (and only if the design remains the same).  If you are sure
your logic is never going to change, or if your timing is non-critical and the
part is not densely packed then you can get away with this.  Otherwise, you
would be wise to follow Austin's advice.

In theory, the "design the FPGA before you do the board" sounds enticing.  In
practice, this rarely happens.  The PWB cycle is often longer than the FPGA
design cycle, and problems found in debug often invalidate the automatically
assigned pins (these are assigned randomly, then moved around in an annealing
process).   By doing some preliminary floorplanning of the logic you plan to put
in the FPGA, you can do considerably better than the automatic placement
(especially in xilinx) in coming up with a pin placement that will not be
trashed by design tweaks.  BTW, Lattice suffers from the same malady, but to a
lesser degree, if you are pushing the speed or density of the part.

If you are following any kind of design methodology, you should have a pretty
good idea of what logic needs to go in the FPGA before you ever start the
design.  Blocking this out hierarchically should give you a fair wag at the
number of CLBs you need, as well as any desired features that might make one
FPGA family more favorable than another for the application.  I don't really see
how you can meet time to market objectives if you do the design using the flow
you are suggesting: design the FPGA (apparently with knowledge of the board
design), then select the FPGA device, then assign the pins using PAR, then
design the board, and then sit idle while you wait for it to go through layout,
fab and assembly.  What happens in debug when you discover a flaw in the FPGA
design?  Do you start over so that PAR can assign a new pinout?  Otherwise, you
have to live with the random pinout created by PAR even if it no longer works
for the modified design.   I've done hundreds of FPGA designs, and except for
one or two, I've had to provide pinouts immediately on project start to support
a parallel PWB effort.  In many of those cases, the board was a reconfigurable
processor so the FPGA pinout was fixed before many of the FPGA designs (and
there are multiple designs per device) were even concieved.   The vast majority
of these are first pass successes, despite a design flow you seem to consider
poor practice.  BTW, these designs also push the FPGA for performance and
density.

> The original poster was essentially implying that he designs his
> boards *before* designing the FPGA logic for them.  Not a practice I
> would recommend - how do you know you have enough logic if you haven't
> designed it yet?  I personally know of design projects (not mine)
> where the design went through 4 revisions and still didn't have a
> working board because the designer did not design his logic first.
>
> Best regards,
> Ivan Baggett
> Bagotronix



--
-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: 14792
Subject: Re: Xilinx Spartan and pin-locking
From: "Austin Franklin" <austin@dark0room.com>
Date: 17 Feb 1999 15:19:29 GMT
Links: << >>  << T >>  << A >>
> ibaggett@bagotronix.com wrote:
> 
> > I think it is
> > better to let the software choose pins for you than to pin-lock, since
> > it can do a better job of routing if it is free to choose pins.  You
> > should pin-lock only after the logic design is completed and
> > reasonably stable.  If this practice is not good for the Xilinx FPGA,
> > please explain why.

You are correct about one thing, the tools do ROUTE better, but they do NOT
PLACE better.  That is the mistake, and they are distinctly different
processes.

You should NOT pin lock with the pinout from the tools, it can lead to that
pinout not being usable.  I do not have to lay out one gate to create a
complete, FINAL pinout.

It is a fact that a human can do placement of regular structures better
than the tools.  Given this, it is better for an FPGA designer to take the
day or two and floorplan the data paths.  From this, the control logic can
be partitioned, and the associated pins placed too.

Austin

Article: 14793
Subject: Re: Anyone experience with Aptix?
From: edwinpark@my-dejanews.com
Date: Wed, 17 Feb 1999 16:25:33 GMT
Links: << >>  << T >>  << A >>
I have a lot of experience with Aptix.	I used an MP3A with Orca in my
previous design.  I am looking into the MP3C for the next design.

In the MP3A design, I got (with a lot of blood and sweat) it to run at 20 MHz.
Most of the ASIC got validated.

The biggest problem I had was (1) cost, (2) I/Os, (3) FPIC I/Os, (4) Speed.

-Edwin

In article <36C954F0.DC0E3025@nym.sc.philips.com>,
  Richard Hogers <Richard.Hogers@nym.sc.philips.com> wrote:
> Hello,
>
> Maybe a bit off topic, but is there anyone out there
> who has experience with the System Explorer product
> line from Aptix?
> I would like to hear what you think about it.
>
> Best regards
>
> Richard
>
> --
>
>   Richard Hogers
>   Philips Semiconductors Nijmegen
>   Business Line Cellular
>   Building FB-3, room 070
>   Gerstweg 2
>   6534 AE Nijmegen, The Netherlands
>
>   Tel. +31 24 3534374
>   Fax. +31 24 3533589,
>
>   E-mail: Richard.Hogers@nym.sc.philips.com
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14794
Subject: Digital PLL
From: schaltung@hotmail.com
Date: Wed, 17 Feb 1999 17:52:17 GMT
Links: << >>  << T >>  << A >>
Hi everyone,

I want to have some sort of Digital PLL implemented in an XILINX FPGA. Does
anyone know of any Literature, Core or information of this type of PLLs?

Regards
Antonio Moreno

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14795
Subject: Re: "Altera FreeCore Library" back on the web
From: "Paul Baxter" <paje@nospam.globalnet.co.uk>
Date: Wed, 17 Feb 1999 20:15:51 -0000
Links: << >>  << T >>  << A >>
Thanks Rune for the efforts you put in over the last few years with the
freecore library.

Sad to see that Altera couldn't make you an enticing offer to stay with
their product range!

Paul Baxter

Rune Baeverrud wrote in message <7aejo9$j3a$1@romeo.dax.net>...
>Hi All,
>
>Until quite recently - I worked as a Field Applications Engineer with one
of
>the distributors of Altera programmable logic. During that time - I created
>the "Altera FreeCore Library" - a web site of free information and logic
>cores written specifically for Altera CPLD's.
>
>Recently - I changed my job - and I'm now working with the Norwegian
>distributor of Xilinx programmable logic, BIT Elektronikk.
>

Article: 14796
Subject: P&R times for Altera10K200E and Virtex
From: edwinpark@my-dejanews.com
Date: Wed, 17 Feb 1999 20:38:37 GMT
Links: << >>  << T >>  << A >>
Does anyone have any P&R times for these two devices.  Also, could you post
some info about the design (% utilization, # of registers, # I/Os, computer
used to P&R, etc).

I am going to start a design that needs many iterations and am very worried
about P&R times.

-Edwin

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14797
Subject: Re: Digital PLL
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 17 Feb 1999 12:52:49 -0800
Links: << >>  << T >>  << A >>



schaltung@hotmail.com wrote:

> Hi everyone,
>
> I want to have some sort of Digital PLL implemented in an
> XILINX FPGA. Does
> anyone know of any Literature, Core or information of this
> type of PLLs?
>  

For a very simple digital PLL used in a Manchester decoder
see

      XCELL 17 Article - Manchester Decoder in 3 CLBs (2Q
1995)
      Manchester Decoder in 3 CLBs X ilinx FPGA
architectures are ideal for implementing high speed
efficient serial decoders For example the circuit
illustrated below uses an eight times oversampling clock to
decode Manchester encoded data The c...
      http://www.xilinx.com/xcell/xl17/xl17-30.pdf

Peter Alfke, Xilinx Applications



Article: 14798
Subject: Re: Free circuit design
From: Sander Vesik <sander@haldjas.folklore.ee>
Date: 17 Feb 1999 21:01:47 GMT
Links: << >>  << T >>  << A >>
In comp.arch "J. Khatib" <khatib@ieee.org> wrote:
> Hi
> Do you like to have excellent pre-made designs for free?  Do you believe
> that free design ideas can push design towards better solutions?

Defiantely. Anything at all can push the design towards better solutions.

> This what I believe, why not do not, have you seen what does the free
> software do to the large companies like MS? the Free OS "Linux" and its
> application is now the only competitor to MS. This is because those who

Why do you think so? 

> build this system gathers lot of ideas from people from all over the
> world and made things that can handle what they want not what a single
> man wants.

But the commercial companies can hire lots of very smart persons. Indeed,
some of the people working on free os's also work on commercial ones...

> Do you think building free software is easier than building free
> hardware. yes I know but lets try first.

I'm not sure one is easier than the other. Neither is easy, if it
has to work and be useful.

> I think the easiest hardware that can be built, is the reusable ASIC or
> FPGA cores. This is the tech. trend now to build soft cores. that can be
> integrated together to make SOC tech.

> Tools!?   we can use the free tools designed by linux programmers who
> need people to improve their tools by using them in real projects.

Can you actually name these tools? Yes, I specificly mean those written
by Linux people as opposed to say "magic".

> What I am thinking now is to build a DSP processor core and implement it
> on FPGAs because this is the easiest way to verify the design.

I'm not sure it can be "verified" in the sense you mean in a FPGA.

> I invite all those interested in this topic to help me " I am in the
> phase of selecting a good architecture and I need your help" and to
> visit this site 
> http://www.geocities.com/SiliconValley/Pines/6639/freecir/free_circuit.html
> and to give a feed back about this idea by replying to this message and
> making a CC to khatib@ieee.org
> Note: I did not prepare this site only I liked the ideas it discusses

I'm definately not interested in DSPs.

> Thanks in advance for your time

-- 
	Sander

	There is no love, no good, no happiness and no future -
	all these are just illusions.
Article: 14799
Subject: Xilinx Foundation V1.5
From: "EKC" <alpha3.1@ix.netcom.com>
Date: Wed, 17 Feb 1999 16:55:08 -0500
Links: << >>  << T >>  << A >>
Does anyone here know when version 1.5 of the Xilinx student edition
foundation package will be available? I had been told that it would be
available by February 1st, however it is nowhere to be seen.

Thanks,
-EKC




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
2017JanFebMarApr2017

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