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 16300

Article: 16300
Subject: Re: Fancy Dram problem
From: roman pollak <roman.pollak@Sun.COM>
Date: Fri, 14 May 1999 13:07:43 +0200
Links: << >>  << T >>  << A >>
Hi Georg,

This could be the reason as well. However, do you know any source how
exactly DRAMS works ?
Especially about the timing what the dram does to any specific time? 
I actualy didn't know, after selecting the correct address (ras/cas),
the dram selects a line and modify only particular bit on the line.
After this it writes it back to the array. But some how it make perfect
sense.

regards roman


Georg Acher wrote:
> 
> In article <37394D92.7080B6C0@Sun.COM>, roman pollak <roman.pollak@Sun.COM> writes:
> |> I'm currently develope a graphic interface for my 68040 board at home
> |> using FPGA and VDRAM.
> |> But I got a very fancy problem with it, which I can't get of it.
> |> When the CPU is writing to the RAM, sometimes it also overwrite other
> |> locations as well.
> |> For example when the cpu is writing on the line X pos Y, it overwrites
> |> also some other location on the same line. Could it be some kind of
> |> reflection problem? Or some other effects, which I don't know about it?
> |> I saw in other designs, they use resistors between DRAM and Mux on the
> |> address lines. But some other designs don't. Some use thouse on RAS/CAS,
> |> some don't. What is the point of thouse resistors?
> 
> The resistors are some sort of series termination to avoid reflections,
> especially useful on RAS/CAS. Modern DRAM can react so fast that they interprete
> the RAS ringing as access termination and start. Since the DRAM had no time to
> write its line buffer back (precharge), the whole line can be destroyed. The
> problem you have is possibly a similar effect: If you violate the RAS-low
> access time or the precharge time, you will get everything from one-bit-failures
> to 4096bit-failures.
> Try to relax the timing a bit...
> --
>         Bye
>          Georg Acher, acher@in.tum.de
>          http://www.in.tum.de/~acher/
>           "Oh no, not again !" The bowl of petunias
Article: 16301
Subject: Bitstream Compression
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 14 May 1999 10:23:02 -0400
Links: << >>  << T >>  << A >>
I am looking at storing several bitstreams in a Flash part on an
embedded processor board and I would like to consider compression of the
data to save space. I seem to recall this topic being discussed here
several months ago. I am planning on using the Lucent OR3T and OR2T
parts which should be substantially similar to the XC4000 series. 

Has anyone looked at a method of compression which is easy to implement,
uses a small amount of code, and runs quickly? Although I will have
enough RAM available for temporary storage, I would prefer to not have
to decompress the entire block of data. However, this is a secondary
requirement and the other results are more important. What degree of
compression is resonable given these constraints, 2:1, 5:1, 20:1?



-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.
Article: 16302
Subject: Re: Need Altera 10k Prototype bd
From: "Edwin Grigorian" <edwin.grigorian@jpl.nasa.gov>
Date: Fri, 14 May 1999 08:36:58 -0700
Links: << >>  << T >>  << A >>
Nova Engineering has just the board you are looking for.  Check out the
Constellation board at:

    http://www.nova-eng.com/constellation.html

Edwin Grigorian

Carl Martin wrote in message <926356074.143.100@news.remarQ.com>...
>Looking for a 10k Altera prototype board with a
>pc104 or PC-isa or PC-pci interface on one side
>and maximum number of io pins on the other side.
>
>Found one from Nova engineering www.nova-eng.com
>are there others
>
>
>Thanks
>Carl R. Martin
>cmart@hypercon.com
>
>
>


Article: 16303
Subject: Re: High speed reconfigurability
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Fri, 14 May 1999 11:37:27 -0400
Links: << >>  << T >>  << A >>
Rickman wrote:
<snip> 
> I am looking really hard at using an OR3T chip for the main FPGA on a
> board I am designing and I would like to find out how you like the
> software. I have read the data sheet on both the OR2t and OR3T parts and
> like the chips alot, but I haven't had time yet to play with the
> software.
> 
> I have been using the Xilinx parts off and on for several years. I also
> did a design once using an OR1C (ATT1C?) part. At that time the ODS
> tools (as well as the Xilinx) were really pretty bad. The current Xilinx
> tools are much improved over what they were even just a couple of years
> ago. Can you compare the current Lucent tools with the current Xilinx
> tools?
> 
> Can you offer any cavets or point out any special bonuses to using the
> Lucent tools over the Xilinx tools?
> 
> For example, how do they handle timing constraints? Do they use a
> constraints file like Xilinx? Or do they have some sort of GUI as the
> latest Xilinx software supports?
> 

The Lucent and Xilinx tools are very similar to each other, as they are
based on the old NeoCad stuff. The Lucent tools accept constraints (
.prf preference file, similar to Xilinx .ucf) and can parse most of them
right from the EDIF file into the preference file.

The Lucent tools do not have a GUI in the same sense as the Xilinx tools
do (and I consider that a good thing.... boy do I hate that Xilinx
GUI!). What they do have is a GUI "shell" (descended from the Unix
version) for each step, i.e. a map shell (mapsh), p&r (parsh), and
bitgen (bitsh) where you select the options you want at each step (or
load them from a previously saved .opt option file). The shell then
executes the tools on the command line. Nice thing about that is you can
easily determine what the commands and arguments are so you can wrap
them into a DOS batch file or a make script.

Like anything else they have come a long way but still show the
occasional bugs. I don't really have a preference tool wise. I find
Xilinx Tech support to be better, but like the 3T architecture better
than 400XL.

Just my $0.02

-- 
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>
Article: 16304
Subject: Who do you know? Motorola FPGA
From: rubi@165.246.73.60 (Yoo)
Date: Fri, 14 May 1999 17:35:57 GMT
Links: << >>  << T >>  << A >>

Hi.

I heard that Motorola launched the FPGA which  following the Xilinx 

XC6200 series.but can;t see the chip unitl now.

Please know me how the  project is going !!!!

Thanks.

Article: 16305
Subject: Re: Who do you know? Motorola FPGA
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 14 May 1999 18:04:14 GMT
Links: << >>  << T >>  << A >>

It's dead.

In article <373e5df2.95932951@news.kreonet.re.kr> rubi@165.246.73.60 (Yoo) writes:
>
>Hi.
>
>I heard that Motorola launched the FPGA which  following the Xilinx 
>
>XC6200 series.but can;t see the chip unitl now.
>
>Please know me how the  project is going !!!!
>
>Thanks.
>


Article: 16306
Subject: Re: Verilog example for Xilinx?
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Fri, 14 May 1999 18:11:08 GMT
Links: << >>  << T >>  << A >>
On Thu, 13 May 1999 15:58:11 GMT, Timothy Miller <tim@techsource.com>
wrote:

>I would like a trivial example of a circuit written in Verilog that can
>be synthesized with Exemplar and loaded onto a Xilinx part.  I just need
>something that shows typical pin instantiations, etc.

You do not do pin instantiation, buffer insertion, pin numbering, and
most other device specific stuff in your Verilog. That is what the
constraint editor and resulting control file is for.

Instantiation of buffer types etc. is just regular structural
port-mapping of a cell in Verilog so should not hold any surprises.

>I have searched both Exemplar's web site and Xilinx's web site and have
>found nothing of the sort.

Try looking in the "demo" directory in your Spectrum installation
directory.

Cheers
Stuart
For Email remove "NOSPAM" from the address
Article: 16307
Subject: Re: Synchronizer design?
From: Tim Davis <timdavis@tdcon.com>
Date: Fri, 14 May 1999 13:20:27 -0600
Links: << >>  << T >>  << A >>
The approach Jamie specified works quite well. We had an I2C module running in a 4036xl. The rise
time on I2C signals is spec'd at 2-300 ns and we found that the circuit was flakey. Simulations
didn't help a bit and showed perfect functionality. After adding the low pass filter things got
dramatically more reliable (I'd say the problem was fixed). My colleague located the Xilinx app note
that described the same solution as outlined by Jamie.

Whether this was a metastability problem or simply a problem of slow rise time isn't clear. (Nor do
I really care.)

Jamie Sanderson wrote:

>
> Add one or two stages to your flip-flop chain, bring it to three or four.
> Then take all of the outputs to two logic functions, one which causes the
> output to be high only when all flip-flop outputs are high, and one which
> causes the output to be low only when all flip-flop outputs are low. That
> output signal can also be run through a final flip-flop.
>
> It slows your signal down considerably, but acts like a low-pass filter.
>
> Cheers,
> Jamie
>

--

Tim Davis
Timothy Davis Consulting

TimDavis@TDCon.com - +1 (303) 426-0800 - Fax +1 (303) 426-1023


Article: 16308
Subject: Re: Who do you know? Motorola FPGA
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 14 May 1999 13:10:32 -0700
Links: << >>  << T >>  << A >>
Yoo wrote:

> Hi.
>
> I heard that Motorola launched the FPGA which  following the Xilinx
>
> XC6200 series.but can;t see the chip unitl now.
>
> Please know me how the  project is going !!!!
>  

Motorola announced and even shipped a family of fine-grained SRAM-based FPGAs
with a strong similarity to the Atmel and XC6200 devices.
Motorola has cancelled that program a while ago, and Xilinx stopped
manufacturing XC6200. The fine-grained architecture has not found wide
acceptance.

Peter Alfke

Article: 16309
Subject: Re: Who do you know? Motorola FPGA
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 14 May 1999 13:10:59 -0700
Links: << >>  << T >>  << A >>
Yoo wrote:

> Hi.
>
> I heard that Motorola launched the FPGA which  following the Xilinx
>
> XC6200 series.but can;t see the chip unitl now.
>
> Please know me how the  project is going !!!!
>  

Motorola announced and even shipped a family of fine-grained SRAM-based FPGAs
with a strong similarity to the Atmel and XC6200 devices.
Motorola has cancelled that program a while ago, and Xilinx stopped
manufacturing XC6200. The fine-grained architecture has not found wide
acceptance.

Peter Alfke

Article: 16310
Subject: Re: Bitstream Compression
From: Armin Mueller <ual6@rz.uni-karlsruhe.de>
Date: Fri, 14 May 1999 23:39:46 +0200
Links: << >>  << T >>  << A >>
Rickman wrote:
> 
> I am looking at storing several bitstreams in a Flash part on an
> embedded processor board and I would like to consider compression of the
> data to save space. I seem to recall this topic being discussed here
> several months ago. I am planning on using the Lucent OR3T and OR2T
> parts which should be substantially similar to the XC4000 series.
> 
> [...]

Yes boy, have a look at

http://wildsau.idv.uni-linz.ac.at/mfx/lzo.html

Armin
Article: 16311
Subject: Re: Fancy Dram problem
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: Fri, 14 May 1999 16:09:39 -0700
Links: << >>  << T >>  << A >>
Olaf Birkeland wrote in message
<01be9deb$eeaf64e0$0801a8c0@pascal.fast.no>...
>RAS/CAS *must* come directly from a register to be reliable in a FPGA due
>to  variations in routing between different synthesis runs, and even
>process variations. I made the fault of generating RAS/CAS by decoding the
>state machine registres in my first controller design (...some years
>ago...), and got errors very similar to the ones metioned ("random"
>destruction of data when doing an access).
>
>The cause was sub 1ns spikes in the RAS signal that sometimes occurred
>inbetween state changes. Took me quite some time (and a good scope!) to
>identify the cause. These did not show up in simulations, as these only
>covered worst case delays.
>
>If your FPGA allows it, also place the RAS/CAS registers in the I/O block
>to get much better control of the timing.


Also register the address bus outputs.  That's a lesson learned the hard
way, too.

-- a
------------------------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters@noao.edu

"Space, reconnaissance, weather, communications - you name it. We use space
a lot today."
-- Vice President Dan Quayle



Article: 16312
Subject: Re: Fancy Dram problem
From: Phil Short <pjs3@nospam.ix.netcom.com>
Date: Sat, 15 May 1999 00:07:27 +0000
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> 
> Olaf Birkeland wrote in message
> <01be9deb$eeaf64e0$0801a8c0@pascal.fast.no>...
> >RAS/CAS *must* come directly from a register to be reliable in a FPGA due
> >to  variations in routing between different synthesis runs, and even
> >process variations. I made the fault of generating RAS/CAS by decoding the
> >state machine registres in my first controller design (...some years
> >ago...), and got errors very similar to the ones metioned ("random"
> >destruction of data when doing an access).
> >

Agreed.

> >The cause was sub 1ns spikes in the RAS signal that sometimes occurred
> >inbetween state changes. Took me quite some time (and a good scope!) to
                                                     ^^^^^^^^^^^^^^^^

> >identify the cause. These did not show up in simulations, as these only
> >covered worst case delays.
> >
> >If your FPGA allows it, also place the RAS/CAS registers in the I/O block
> >to get much better control of the timing.
> 
> Also register the address bus outputs.  That's a lesson learned the hard
> way, too.

In general, I disagree with this one.  Setup and hold times for address
WRT RAS and CAS will generally require extra delay in the asynchronous
DRAM access cycle.  I suspect that there were better solutions to
whatever problem that you were trying to solve.  There are, I am sure,
cases where registering the address lines is a useful technique, but I
would never suggest this as a general solution.

But in any case, I strongly suggest the use of an oscilloscope to
actually observe the circuit in action.

> 
> -- a
> ------------------------------------------
> Andy Peters
> Sr. Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters@noao.edu
> 
> "Space, reconnaissance, weather, communications - you name it. We use space
> a lot today."
> -- Vice President Dan Quayle

-- 
Phil
Article: 16313
Subject: Re: How synthesize tools concern with size of the design?
From: Jim Kipps <jkipps@viewlogic.com>
Date: Fri, 14 May 1999 22:38:31 -0400
Links: << >>  << T >>  << A >>
Ray-

This is what I mean by tools changing from release to
release.  FPGA Express has supported user attributes
since 3.0 was released six months ago.  I include an
example below showing how an RLOC property assigned in
a structural VHDL design and passed to Xilinx place
and route.

Of course, I'm a little surprised that this is the
criterion by which you judge a synthesis tool.  The
whole reason for doing synthesis is to get away from
technology-specific, structural designs.  If you need to
design this way, then the visual appeal of schematics
make more sense than VHDL, but let's not get into a
religious debate.

What I look for in synthesis is: 1) library coverage
(you can't synthesize what you can't target), 2) quality
of results, and 3) language support.  There are other
things that are important, like ease of use, price, and
runtime performance, but these are the three biggies.

I've had experience with Leonardo (which also supports
user attributes), Synplify, and FPGA Express and can
honestly say that all three are competitive with regard
to libraries, performance, and language.  With each new
release of any one of these tools, the library coverage
improves, the quality of results improves, and language
features are enhanced.

Over the last two years, the biggest improvements have
been in FPGA Express (although I may be suspect because
I resell it).  Two years ago this tool was fourth in a
four man race -- even Aurora (derived from ViewSynthesis)
had better libraries and results.  Today, FPGA Express
rivals Exemplar and Synplicity in supported vendors and
devices and Altera claims that only FPGA Express can
handle the new APEX20K family (but I'm sure that this will
change with the next releases of Leonardo and Synplify).
In terms of quality of results, I've seen the latest version
of FPGA Express (3.1) improved area and delay by over 30%
from the 2.x releases.  FPGA Express (or, rather, the FPGA
synthesis competition) has also driven many language
enhancements into the Synopsys subset.

Synopsys has had to do a lot of catch up with FPGA Express.
They got into the FPGA synthesis game very late, but they
have a lot of resources and very clever people to throw
at this problem.  I can send you an eval copy if you like.

Regards,
-Jim

Passing attributes to place and route
------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity testmac is
  port (D, CLR, CE, C : in std_logic; Q : out std_logic);
end testmac;

architecture struct of testmac is
  component FDCE is
    port (D, CLR, CE, C : in std_logic; Q : out std_logic);
  end component;
  attribute RLOC : STRING;
  attribute RLOC of U1 : label is "R1C0.FFY";
begin
  U1 : FDCE port map (D, CLR, CE, C, Q);
end struct;


Ray Andraka wrote:

> FPGA express is not currently as capable as SYnplicity and Exemplar, at least
> from a standpoint of creating relatively placed macros.  I do alot of structural
> instantiation with relative placement to get the performance and density I
> need.  I previously was constrained to schematics to do this, but with the
> capability to support and pass user attributes through to the EDIF output, I
> know I can get the results I need from Synplicity, and while I haven't tried it
> in exemplar, I understnd their tool will do it too.  FPGA express definitely
> does not.
>
> Jim Kipps wrote:
>
> > Different tools deliver different results.  Different versions of the same
> > tool will also give different results.  Further, the results can vary by the
> > type of design, style of VHDL coding, and target vendor and device.
> >
> > You received other emails pointing you towards Synplify from Synplicity
> > and Leonardo from Exemplar.  You should also look at FPGA Express,
> > which is engineered by Synopsys and distributed through Viewlogic,
> > VeriBest and Xilinx.  You can go to the Viewlogic (www.viewlogic.com)
> > to get evaluation software; you can also get evaluation software from
> > VeriBest and Xilinx.
> >
> > Regards,
> > -Jim
> >
> > Tippawan Aranwattananon wrote:
> >
> > > I have design a small core in VHDL and I would like to know if I use
> > > difference tools to synthesize my VHDL code, will the numbers of CLB from
> > > those tools be difference.
> > > And if you know any excellent tools for synthesize please recommend.
> > >
> > > realk@thaimail.com
> >
> > --
> > --------------------------------------------------------
> > James R. Kipps                  FPGA Marketing Manager
> > jkipps@viewlogic.com            Phone: (508) 303-5246
> > --------------------------------------------------------
>
> --
> -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

--
--------------------------------------------------------
James R. Kipps                  FPGA Marketing Manager
jkipps@viewlogic.com            Phone: (508) 303-5246
--------------------------------------------------------


Article: 16314
Subject: Re: How synthesize tools concern with size of the design?
From: murray@pa.dec.com (Hal Murray)
Date: 15 May 1999 03:44:02 GMT
Links: << >>  << T >>  << A >>

In article <373CDE27.B8F24A8C@viewlogic.com>,
 Jim Kipps <jkipps@viewlogic.com> writes:

> What I look for in synthesis is: 1) library coverage
> (you can't synthesize what you can't target), 2) quality
> of results, and 3) language support.  There are other
> things that are important, like ease of use, price, and
> runtime performance, but these are the three biggies.

I think that library coverage is a great goal, but what
I really want is to be able to add or modify things in
the library to make them do what I really need this time.

Alternatively, I want to be able to get a higher quality
result by making a libary element that fits the device
I'm using today better that the ones provided.

-- 
These are my opinions, not necessarily my employers.
Article: 16315
Subject: Re: How do I design this ?(synchronous interface)
From: murray@pa.dec.com (Hal Murray)
Date: 15 May 1999 03:45:08 GMT
Links: << >>  << T >>  << A >>

> It is a good suggestion but I have some limitations as far as how fast I can
> go in digital domain. The data rates are as high as 8Mbits. The highest I
> can use in my system will be at 60 MHz.

You can process things 2 (or more) bits at a time if you can find a 2x clock
to sample the input data.  The falling edge of the main clock will work if your
clock duty cycle is tight enough.

-- 
These are my opinions, not necessarily my employers.
Article: 16316
Subject: Re: Synchronizer design?
From: murray@pa.dec.com (Hal Murray)
Date: 15 May 1999 04:04:08 GMT
Links: << >>  << T >>  << A >>

> My digital design books don't cover synchronizers in detail. So I am
> asking here and hoping for feedback. Basically I have an asynchronous
> input signal and I want to synchronize this to the FPGA clock. This
> can of course be done by simply sampling the signal with an input
> flip-flop and depending on the clock rate and the characteristic of
> the flip-flop I can estimate a MTBF. But how do I reduce this MTBF by
> designing synchronizer? I know I can cascade two flip-flops, but are
> there other/better ways?

Here is the way I think about that area...

The key idea is settling time.  The MTBF gets exponentailly better
if you want longer.  The exponential is very important.  You want
to do everything you can to make that time longer.

For the simple case of FF-FF, the settling time is the clock cycle time
minus the clock-output time of the first FF, minus the routing time
minus the setup time of the second FF.

So the first thing to make sure you don't do is put the FFs on
opposite sides of the chip and eat up a lot of settling time by
going through lots of routing.

Similarly, don't put any logic in between the FFs - the prop
time through that logic would subtract from the settling time.
Of course, if you have lots of extra time, then you can put
logic in there (perhaps saving a whole cycle later on) as long
as the MTBF is still good enough.  With FPGAs, there is often
a "free" layer of logic available.

If the MTBF of the basic FF-FF circuit isn't good enough, then
you can either find a slower clock (to get more settling time)
or go FF-FF-FF...  FF-FF-FF takes two cycles but doesn't work
as well (lower MTBF) as FF-FF at half the clock speed because
the setup and clock-output and routing times of the middle FF get
subtracted off the (doubled) clock time.


If anybody suggests some kludge circuit that will "solve" the
problem and prevent metastability you should send them back to
school or try to get them a job working for somebody else.
Usually they make the MTBF worse and harder to analyze.
-- 
These are my opinions, not necessarily my employers.
Article: 16317
Subject: Re: Synchronizer design?
From: murray@pa.dec.com (Hal Murray)
Date: 15 May 1999 04:11:11 GMT
Links: << >>  << T >>  << A >>

> Either way, I still think that two flip-flops chained together will give you
> all the protection from metastability that is needed. Of course, I say this
> from my perspective only, I'm not designing equipment for life support or
> anything like that.

How can you say that without knowing more about the system timing?

With modern/fast FPGAs, it's quite reasonable to build designs
that run fast enough to invite problems if you don't think
carefully about metastability.

Yes, two FFs is the right solution in most cases but we need to be
careful to understand when they aren't good enough and why.
-- 
These are my opinions, not necessarily my employers.
Article: 16318
Subject: Re: How synthesize tools concern with size of the design?
From: Ray Andraka <randraka@ids.net>
Date: Sat, 15 May 1999 00:22:48 -0400
Links: << >>  << T >>  << A >>


Jim Kipps wrote:

> Ray-
>
> This is what I mean by tools changing from release to
> release.  FPGA Express has supported user attributes
> since 3.0 was released six months ago.  I include an
> example below showing how an RLOC property assigned in
> a structural VHDL design and passed to Xilinx place
> and route.

Hallelujah!  To be honest, I haven't looked at FPGA express since last fall.

>
>
> Of course, I'm a little surprised that this is the
> criterion by which you judge a synthesis tool.  The
> whole reason for doing synthesis is to get away from
> technology-specific, structural designs.  If you need to
> design this way, then the visual appeal of schematics
> make more sense than VHDL, but let's not get into a
> religious debate.

Agreed, however I have been playing with structural VHDL for generation of fairly
complex DSP macros that want to be relationally placed.  The VHDL gives me the ability
to parameterize and generate; a capability which is not currently available for
schematics.  It also allows me to still produce designs that push the capability of
the silicon for those customers who want nothing to do with schematics (you know who
you are).

>
>
> What I look for in synthesis is: 1) library coverage
> (you can't synthesize what you can't target), 2) quality
> of results, and 3) language support.  There are other
> things that are important, like ease of use, price, and
> runtime performance, but these are the three biggies.
>

These are all important too, although none of them currently give me the quality of
results I need for some of my higher data rate designs (some data rates exceeding
100MSPS) without resorting to structural coding with placement.  Library coverage for
the major vendors seems to have been be pretty even.  Sure one of you gets the new
device out a few weeks before the others, but then the next new device belongs to
another one of you first.  The library coverage issue is for the most part really only
an issue for the people using the less common devices like Atmel.  Language support
also has been pretty much neck and neck between exemplar and synplicity.  You guys
were way behind when I last looked, but again, I'll have to look at your new release
to see where you stand.  Full support of unconstrained vectors in the port list is a
biggie for me.

> I've had experience with Leonardo (which also supports
> user attributes), Synplify, and FPGA Express and can
> honestly say that all three are competitive with regard
> to libraries, performance, and language.  With each new
> release of any one of these tools, the library coverage
> improves, the quality of results improves, and language
> features are enhanced.
>

> Over the last two years, the biggest improvements have
> been in FPGA Express (although I may be suspect because
> I resell it).  Two years ago this tool was fourth in a
> four man race -- even Aurora (derived from ViewSynthesis)
> had better libraries and results.  Today, FPGA Express
> rivals Exemplar and Synplicity in supported vendors and
> devices and Altera claims that only FPGA Express can
> handle the new APEX20K family (but I'm sure that this will
> change with the next releases of Leonardo and Synplify).
> In terms of quality of results, I've seen the latest version
> of FPGA Express (3.1) improved area and delay by over 30%
> from the 2.x releases.  FPGA Express (or, rather, the FPGA
> synthesis competition) has also driven many language
> enhancements into the Synopsys subset.
>
> Synopsys has had to do a lot of catch up with FPGA Express.
> They got into the FPGA synthesis game very late, but they
> have a lot of resources and very clever people to throw
> at this problem.  I can send you an eval copy if you like.
>
> Regards,
> -Jim
>
> Passing attributes to place and route
> ------------------------------------
> library ieee;
> use ieee.std_logic_1164.all;
>
> entity testmac is
>   port (D, CLR, CE, C : in std_logic; Q : out std_logic);
> end testmac;
>
> architecture struct of testmac is
>   component FDCE is
>     port (D, CLR, CE, C : in std_logic; Q : out std_logic);
>   end component;
>   attribute RLOC : STRING;
>   attribute RLOC of U1 : label is "R1C0.FFY";
> begin
>   U1 : FDCE port map (D, CLR, CE, C, Q);
> end struct;
>
> Ray Andraka wrote:
>
> > FPGA express is not currently as capable as SYnplicity and Exemplar, at least
> > from a standpoint of creating relatively placed macros.  I do alot of structural
> > instantiation with relative placement to get the performance and density I
> > need.  I previously was constrained to schematics to do this, but with the
> > capability to support and pass user attributes through to the EDIF output, I
> > know I can get the results I need from Synplicity, and while I haven't tried it
> > in exemplar, I understnd their tool will do it too.  FPGA express definitely
> > does not.
> >
> > Jim Kipps wrote:
> >
> > > Different tools deliver different results.  Different versions of the same
> > > tool will also give different results.  Further, the results can vary by the
> > > type of design, style of VHDL coding, and target vendor and device.
> > >
> > > You received other emails pointing you towards Synplify from Synplicity
> > > and Leonardo from Exemplar.  You should also look at FPGA Express,
> > > which is engineered by Synopsys and distributed through Viewlogic,
> > > VeriBest and Xilinx.  You can go to the Viewlogic (www.viewlogic.com)
> > > to get evaluation software; you can also get evaluation software from
> > > VeriBest and Xilinx.
> > >
> > > Regards,
> > > -Jim
> > >
> > > Tippawan Aranwattananon wrote:
> > >
> > > > I have design a small core in VHDL and I would like to know if I use
> > > > difference tools to synthesize my VHDL code, will the numbers of CLB from
> > > > those tools be difference.
> > > > And if you know any excellent tools for synthesize please recommend.
> > > >
> > > > realk@thaimail.com
> > >
> > > --
> > > --------------------------------------------------------
> > > James R. Kipps                  FPGA Marketing Manager
> > > jkipps@viewlogic.com            Phone: (508) 303-5246
> > > --------------------------------------------------------
> >
> > --
> > -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
>
> --
> --------------------------------------------------------
> James R. Kipps                  FPGA Marketing Manager
> jkipps@viewlogic.com            Phone: (508) 303-5246
> --------------------------------------------------------



--
-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: 16319
Subject: How can I get a ISA/PCI BUS model?
From: "lijun2611" <lijun1126@yahoo.com>
Date: Sat, 15 May 1999 06:37:11 GMT
Links: << >>  << T >>  << A >>
I'm designing a ISA and PCI card.However,I need a testbench to generate
all signals.Thank for any info.
--
Posted via Talkway - http://www.talkway.com
Exchange ideas on practically anything (tm).

Article: 16320
Subject: Re: Who do you know? Motorola FPGA
From: (NO-SPAM)md7114@mclink.it (damiano)
Date: 15 May 1999 07:11:57 GMT
Links: << >>  << T >>  << A >>
I know Motorola dismissed any activity on FPGAs

On Fri, 14 May 1999 17:35:57, rubi@165.246.73.60 (Yoo) wrote:

> 
> Hi.
> 
> I heard that Motorola launched the FPGA which  following the Xilinx 
> 
> XC6200 series.but can;t see the chip unitl now.
> 
> Please know me how the  project is going !!!!
> 
> Thanks.
> 


Damiano Rullo
Trezzano S/N
Milan, Italy
http://members.it.tripod.de/Damianoux/index.html
mailto: dmn@cheerful.com
mailto: damiano@mclink.it

Article: 16321
Subject: Re: Fancy Dram problem
From: steve@rsn-tech.demon.co.REMOVEuk (Steve Rencontre)
Date: Sat, 15 May 1999 09:14:44 +0100
Links: << >>  << T >>  << A >>
In article <373CBABF.768BD300@nospam.ix.netcom.com>, 
pjs3@nospam.ix.netcom.com says...

[snip]
> But in any case, I strongly suggest the use of an oscilloscope to
> actually observe the circuit in action.

But make sure the probe capacitance doesn't swallow the spikes you're 
looking for!

I'm sure we've all had problems where the act of measurement makes the 
effect go away :-)
-- 
Steve Rencontre - Design Consultant
http://www.rsn-tech.demon.co.uk/
Article: 16322
Subject: Re: How synthesize tools concern with size of the design?
From: "Jan Gray" <jsgray@acm.org.nospam>
Date: Sat, 15 May 1999 21:46:07 GMT
Links: << >>  << T >>  << A >>
Ray Andraka wrote in message <373B97D6.98A5BAE3@ids.net>...
>FPGA express is not currently as capable as SYnplicity and Exemplar, at
least
>from a standpoint of creating relatively placed macros.  I do alot of
structural
>instantiation with relative placement to get the performance and density I
>need.  I previously was constrained to schematics to do this, but with the
>capability to support and pass user attributes through to the EDIF output,
I
>know I can get the results I need from Synplicity, and while I haven't
tried it
>in exemplar, I understnd their tool will do it too.  FPGA express
definitely
>does not.


I recently downloaded the FPGA Express 3.1 upgrade to Xilinx Foundation
Express from the Xilinx website.  Attribute passing is described in
http://www.xilinx.com/techdocs/4392.htm.

Alas, my hopes for explicitly floorplanned datapaths, via structural
Verilog, via RLOC attributes on FMAP primitives, were dashed when I found
that my explicitly instantiated FMAPs were swallowed by FPGA Express and
were not copied into the output netlist.  This is explained in
http://www.xilinx.com/techdocs/4395.htm.

As a workaround, I created a schematic macro named FMAP_, which contains a
single FMAP primitive with an RLOC=R0C0 attribute, exported it as EDIF, and
instantiated those through structural Verilog, applying RLOC attributes to
my FMAP_ macros.  Express kindly passes these through to my output netlist.

With this technique, I was able to build a test section of a datapath with
the right relative placement.

However, if I recall correctly, when explicitly instantiating other device
primitives, like INV, Express would sometimes emit its own FMAPs which
covered the same nets as mine.  This led to map failure.  So, I defined and
used my own INV_ macro instead, and this suppressed the undesired FMAPs on
INVs.  But this way lies madness.

(If I am mistaken, or have overlooked something obvious, please let me
know!)

In other experiments, I tried something like an assign plus an FMAP
  assign o = ... a ... b ... c ... d ... ;
  FMAP_ fmo(.I1(a), .I2(b), .I3(c), .I4(d), .O(o)); //synopsys attribute
RLOC "R0C0"
but my fmo/fmap covered the same nets as the unattributed FMAP that Express
emits for the assign, and again map fails.  I briefly contemplated
post-processing Express output netlists to either 1) remove Express FMAPs
that covered my RLOC'd FMAPs, or 2) remove my FMAPs but propagate their
attributes to the equivalent Express generated FMAPs, but this way too lies
madness.

(Maybe it would be nice if, as with my custom netlist generator, an assign
which could be covered by a single FMAP could be attributed:
  assign o = ... a ... b ... c ... d ... ; // FMAP attribute RLOC "R0C0"
but maybe not.)

This is "pushing on a rope".  You know exactly what you want -- a particular
optimal, hand-mapped, hand-placed layout for your datapath -- but the tools
get in the way, and you spend hours trying to discover an incantation that
persuades the tools to emit the desired result.

Do Synplicity or Exemplar honor explicit instantiations of FMAPs, and enable
them to be attributed with RLOC constraints?


If you will indulge me, here are two desiderata for FPGA and synthesis tools
vendors to consider.

HDL Floorplanning Desiderata

1. there should be straightforward way to take a schematic and write an
equivalent structural HDL module.

(Corollaries:
1.a. If I can specify attributes on components and nets in the schematic,
then I can also attach them to the instances and nets in the structural HDL.
1.b. Just as with a schematic, if I DO instantiate a component, DO emit it
to the netlist.
1.c. Just as with a schematic, if I DON'T instantiate a component, DON'T
unhelpfully create one from whole cloth and emit it to the netlist.)

2. that way (1) should be standard across vendors

Somehow I doubt that '//synopsys attribute RLOC "R0C0"' is going to have the
desired effect when my design is built with Synplicity.  While I admire
synthesis vendor extensions which deliver new innovations, the issue of
passing attributes seems so fundamental to quality FPGA design that I hope
the FPGA and synthesis vendors can work together to define a common
notation.

Jan Gray



Article: 16323
Subject: Re: Synchronizer design?
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 16 May 1999 09:45:23 +0200
Links: << >>  << T >>  << A >>
Mark Summerfield <m.summerfield@ee.mu.oz.au> writes:

[...]

> On the other hand, I know very few engineers of any age who are 
> socialists...

I know quite a few who are...

What was your point again?

Homann
-- 
   Magnus Homann  Email: d0asta@dtek.chalmers.se
                  URL  : http://www.dtek.chalmers.se/DCIG/d0asta.html
  The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html
Article: 16324
Subject: Re: High Speed Reconfigurability
From: "Italian Cowboy" <gmeardi@geocities.com>
Date: Sun, 16 May 1999 17:19:13 +0200
Links: << >>  << T >>  << A >>
Personally, I'm working on dynamic reconfiguration (PoliMorph Project,
Politecnico of Milan), i.e. exactly what you guys are talking about. Despite
the loads of projects in this promising field, though, I always notice that
everybody neglects what I deem the most important problem of all.
Steve himself pointed out that "the SW IS the computer", but maybe he forgot
the implications: the biggest hurdle here is *not* the reconfigurable array
(today's Xilinx could already provide us with outstanding results, were we
able to use them fully), but a suitable and overall automatic way to take
advantage of the beast.
I mean, everybody can imagine a computer that goes on reconfiguring the FPGA
on the fly and boosting performance like crazy, but as long as we don't have
a sort of compiler that gets a standard C++ code or whatever and understands
what portions of the code are to be implemented in Hardware and how, our
vision will just remain what it is... a vision.
That's why we at the Politecnico are working on the compiler better than on
hardware issues:
right now we already have a way to identify (in a standard C code)
interesting portions (we called them MISO, for Multiple In Single Out, since
they are kind of a generalization of a "normal" RISC instruction, where you
have a number of input operands but just one output), we have a way to
assess their value (GAIN heuristic, Gross Advantage INdex), and we're
developing a genetic algorithm that, working on the Control Flow Graph and
considering reconfiguration penalties, substitution policies and so forth,
decides which MISOs should be implemented in hardware for real (GENIUS,
GENetic Identification of Useful Superinstruction).
It's REAL tough, I'm telling you, and that's why I'm all too convinced that
here lies the S. Graal of reconfigurable computing.

Remember, Steve, "the software IS the computer"...

Aside from that, you can find info about DPGAs in the MIT web site: it was
DeHon's PhD Dissertation.


Guido Meardi









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