Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 14925

Article: 14925
Subject: Re: Where do I connect my reset pins to?
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 25 Feb 1999 11:45:10 -0800
Links: << >>  << T >>  << A >>
Joel Kolstad wrote:

> Any insight into the correct way to deal with the reset
> pins would be
> appreciated.  Thank you.
>  

The chip will initiate all flip-flops ( either set or reset
) during the configuration phase, and will initiate each
flip-flop the same way ( either reset or set, per
configuration ) whenever you activate the global set/reset.
There is no way to interfere with this, you cannot even
exclude any flip-flop from it. So from a hardware point of
view, this all happens automatically.

Peter Alfke, Xilinx Applications

Article: 14926
Subject: Re: JTAG HANG UP......
From: rk <stellare@NOSPAMerols.com>
Date: Thu, 25 Feb 1999 15:08:21 -0500
Links: << >>  << T >>  << A >>
hmmm ... thought that the jtag spec called for trst* to be lowed to hold
the state machine in reset (but don't have the spec here) and didn't
think it was optional (choice of polarity).

also, if you don't have trst* (optional pin) you might wanna consider
running tck with tdi high to eliminate any lockup states in case
something bad happens to the jtag state machine.

rk

=====================================

Mike H. wrote:

> Jim wrote in message <36D4AA69.E95CB74@erols.com>...
> >Any folks run into any JTAG gotchas with pulling up the
> >tdi and tclk pins?
>
> The only problems I've experienced have been with the
> /TRST pin, which seems to be interpreted differently
> by different devices. Some like it pulled up when the
> JTAG port isn't being used, some like it pulled down.
> Can lead to operational inconsistencies.
>
> Mike H.



Article: 14927
Subject: Where To FIND Info on Basic CPU Components
From: "L.O.S." <leon@cableone.net>
Date: Thu, 25 Feb 1999 12:15:35 -0800
Links: << >>  << T >>  << A >>

Hi,

     I was looking for a good web site (or book) with  wealth of
information on implementing some of the basic components used in today's
microprocessors (e.g. ALU, BTB, Floating Point Unit, and etc).

Thanks,
              leon

p.s. Free resources if possible. I once (a long time ago) implemented a
small portion of a PDP-11. I am interested in simulating a Pentium
processor. Do you know on a cheap design program and simulator?
Thanks in advance.









Article: 14928
Subject: Re: Xilinx ABEL?
From: "Austin Franklin" <austin@darkr8oom.com>
Date: 25 Feb 1999 20:41:02 GMT
Links: << >>  << T >>  << A >>
> I have not been able to get a registered output to
> hold its value when the machine enters a new state.  Xilinx tells me to
> define all the outputs in every state.

Why not setup an equation for the flops CE, where the CE is true only in
the states you want to change the output?

Austin Franklin
austin@darkroom.com

Article: 14929
Subject: Re: Xilinx ABEL?
From: ems@riverside-machines.com.NOSPAM
Date: Thu, 25 Feb 1999 21:02:45 GMT
Links: << >>  << T >>  << A >>
On Thu, 25 Feb 1999 10:12:26 -0500, "Don  Brouse" <dcbrouse@yahoo.com>
wrote:

<snipped>

well, you've already had half a dozen answers on this, but here's a
different perspective. VHDL is an abstract language, and has no
concept of any underlying hardware (even registers, or clock cycles).
once you've set a signal to a given value, the only way to change the
signal is, at some later time, to set it to another value. in other
words, signals keep their value, as you'd expect.

abel is very different. it's fundamentally a language which is based
on a sum-of-products hardware model. when you set the appropriate
AND/OR inputs to 1, then the output is 1; when the inputs aren't 1,
then the output isn't 1. it knows about registers, and expects you to
specify your input conditions for every clock cycle. in other words,
it doesn't keep values (except in some cases - another example of the
ad-hoc basis of the language).

by the way, from a language viewpoint, abel is a real mess. it's
illogical, and seems to have initially been written to describe simple
pals, and added to (inconsistently) over the years. i looked at
writing an abel parser recently, and it's *very* difficult - the
syntax is a mess, and the documentation is inconsistent, and simply
incorrect in many cases.

abel or vhdl? on the plus side, abel is easy to learn, once you've
figured out a way to cope with polarities. simulation is nice and
easy, and fairly powerful. on the minus side, the language is almost
dead, and, if you're targetting xilinx, it can be hugely inefficient.
this was certainly true in 1.4, but it may have been fixed now. if it
hasn't been fixed, forget it.

vhdl is much harder to learn than abel. it's further removed from the
hardware, so you have to think about it more. the upside is that it's
*much* better for system descriptions, and simulation. there are lots
of other pros and cons for/against VHDL, but those are probably the
main points.

evan

Article: 14930
Subject: Re: Where do I connect my reset pins to?
From: "Joel Kolstad" <JKolstad@Electroglas.Com>
Date: Thu, 25 Feb 1999 13:14:18 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote in message <36D5A61E.5D78078C@xilinx.com>...
>The chip will initiate all flip-flops ( either set or reset
>) during the configuration phase, and will initiate each
>flip-flop the same way ( either reset or set, per
>configuration ) whenever you activate the global set/reset.

This is certainly what I want.  (The FPGA does not have an external reset.)
From what you say, it sounds safe to do any of the following:

-- Ground the reset pin on the macro
-- Leave it floating (probably a bad practice, though, from the
documentation point of view)
-- Connect it to the reset output of the startup block

In the first two instances, nothing will get routed to the 'flops reset/set
line and only GSR will be able to reset/set it.  In the last instance, PAR
should be smart enough to figure out that resetting/setting a flop from GSR
itself is redundant and realize that actually consuming routing resources to
connect to the reset/set on the 'flop is unnecessary.

If I did have an external reset, I believe the correct thing to do would be
to connect it to the startup block.  The wrong thing to do would be to
connect it directly to the macros' reset inputs, since then the reset
connections would consume routing resources.

Is that correct?

---Joel Kolstad



Article: 14931
Subject: Re: High Fanout Signals
From: Ray Andraka <randraka@ids.net>
Date: Thu, 25 Feb 1999 16:16:48 -0500
Links: << >>  << T >>  << A >>
There is no need for all 128 CLBs to use the same LFSR address counter.
Consider the 256x16 bit shift register to be say 16 16x16 shift registers,
and run each one with it's own address counter.  The address counters do not
even have to be synchronized (they will be anyway as long as they all come
out of reset on the same clock).  Depending on your clock speed, you might
find you need to reduce these to 8 bits wide, so that you have 32 LFSRs,
each driving an 8 bit by 16 clock shift register.

Khaled benkrid wrote:

> Hi All,
>
> I am implemeting shift registers in Xilinx 4kE using a LFSR counter and
> Synchronous RAMs. I need a big shift (256*16 bits) which requires 128
> CLBs for the RAMs. I need high fanout signals to address the RAM's from
> the counter outputs in order to get high speed. What is the best
> solution ( I am thinking about using BUFG to derive these signals).  Any
> ideas????.
>
> Cheers.



--
-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: 14932
Subject: Re: Xilinx Virtex
From: Ray Andraka <randraka@ids.net>
Date: Thu, 25 Feb 1999 16:28:26 -0500
Links: << >>  << T >>  << A >>
The only real flaw (if you can call it that) I've found so far in the Virtex
design is the design of the carry chain logic.  The carry chain works fine for
the usual add, subtract, increment, decrement type functions; that is
expected.  However, the 4k carry chain is far more versatile so there is a loss
of capability in the virtex design.
The fact that the carry chain precedes the LUT in the 4K architecture allows
you to use it independently, as well as use the progressive carry out in
functions other than arithmetic which is dictated by the exclusive OR hardwired
into the virtex design.  As an example, I have frequently used the 4K carry
chain as a bargraph circuit, which is a useful component in things like
priority encoders and data framing logic.  For the bargraph, you need the carry
chain output at each bit.  With the 4K, you have that access, and can also
perform a 4 input logic function using that carry, the input bit and two other
controls plus you can register the result in one CLB.  With virtex,  you can
only get the required access by going out the xb and yb combinatorial outputs
to another LUT,  The LUT in the carry CLB is used up for making the carry
work.  This is a lot closer to Altera's carry structure than to the 4K.  Too
bad, since I've always felt that the 4K carry architecture was one of the
advantages the 4K had over other FPGAs.

mark wrote:

> I've done one design in the XV300 part.  My design contains four 5 tap FIR
> filters with loadable coefficients (10 bit input data and 10 bit
> coefficients) and several adders to combind the output of the taps plus
> some general decode logic.  All of this needs to run at 50MHz.
>
> The Foundation tools are a real pain to deal with.  Many functions (ie.
> library components / macros) either don't work at all or don't simulate
> quite right.  But, after a bunch of help from our local FAE we got through
> the issues.
>
> Once past the design entry portion of the design things got much better.
> It was truly a push button implementation.  The design uses about 70% of
> the part and will run at 58MHz (as reported by PPR).  Reality seems to
> agree with this as everything is working on the bench at 50Mhz.
>
> In my opinion the Foundation tools have a ways to go before they are solid,
> but the Virtex part itself is great.
>
> mark
>
> Daryl Bradley <dwb105@ohm.york.ac.uk> wrote in article
> <36D13540.3F98B5A8@ohm.york.ac.uk>...
> > Anyone had any experience using the new Xilinx Virtex chips along with
> > any of the development boards as yet?
> >
> > Cheers
> >
> > Daryl Bradley
> >
> > --
> >
> > Bio-Inspired Architectures
> > Department of Electronics
> > University of York, UK
> > http://www-users.york.ac.uk/~dwb105
> >
> >
> >



--
-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: 14933
Subject: Re: Where do I connect my reset pins to?
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Thu, 25 Feb 1999 13:55:34 -0800
Links: << >>  << T >>  << A >>
Xilinx has a VHDL component called a ROCBUF that you instantiate.  This also
provides a way you can assert the GSR in behav. simulation.  In Verilog, you
are supposed to leave it disconnected, but the tool does not cope well with
that and the GSR is not assigned to the reset net.

I think the ROCBUF is what you want, but I have not used it myself since I
use Verilog.

bruce


Joel Kolstad wrote in message <7b424t$cl7$1@ffx2nh2.uu.net>...
>Under Xilinx Foundation, I have a bunch of VHDL modules that have reset
>inputs.  I use FPGA Express to synthesize them, and then use Xilinx's
>schematic editor to turn them into macros that are placed into the
schematic
>(which principally ties all the VHDL modules together -- and no, I don't
get
>"multiple startup block" errors :-) ).  The macro symbols still have
"reset"
>pins on them.  In order to get GSR to reset the 'flops in the design, what
>should I do with the reset pins?
>
>If I leave them disconnected, Design Manager gives me warnings but does PAR
>correctly.  If I ground them, the warnings go away.  In both causes, as far
>as I can tell, in the actual FPGA all the 'flops do get reset at power-up.
>
>Any insight into the correct way to deal with the reset pins would be
>appreciated.  Thank you.
>
>---Joel Kolstad
>JKolstad@Electroglas.Com
>
>
>


Article: 14934
Subject: Re: Xilinx ABEL?
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Thu, 25 Feb 1999 14:01:11 -0800
Links: << >>  << T >>  << A >>
I have a book called "Xilinx-ABEL Software Design" with the Xilinx Logo on
it, but it looks like it was published by Data I/O (981-0300-002).  I use it
a lot.  (November 1993)

bruce

ems@riverside-machines.com.NOSPAM wrote in message
<36d5b8f7.3525004@news.dial.pipex.com>...
>On Thu, 25 Feb 1999 10:12:26 -0500, "Don  Brouse" <dcbrouse@yahoo.com>
>wrote:
>
><snipped>
>
>well, you've already had half a dozen answers on this, but here's a
>different perspective. VHDL is an abstract language, and has no
>concept of any underlying hardware (even registers, or clock cycles).
>once you've set a signal to a given value, the only way to change the
>signal is, at some later time, to set it to another value. in other
>words, signals keep their value, as you'd expect.
>
>abel is very different. it's fundamentally a language which is based
>on a sum-of-products hardware model. when you set the appropriate
>AND/OR inputs to 1, then the output is 1; when the inputs aren't 1,
>then the output isn't 1. it knows about registers, and expects you to
>specify your input conditions for every clock cycle. in other words,
>it doesn't keep values (except in some cases - another example of the
>ad-hoc basis of the language).
>
>by the way, from a language viewpoint, abel is a real mess. it's
>illogical, and seems to have initially been written to describe simple
>pals, and added to (inconsistently) over the years. i looked at
>writing an abel parser recently, and it's *very* difficult - the
>syntax is a mess, and the documentation is inconsistent, and simply
>incorrect in many cases.
>
>abel or vhdl? on the plus side, abel is easy to learn, once you've
>figured out a way to cope with polarities. simulation is nice and
>easy, and fairly powerful. on the minus side, the language is almost
>dead, and, if you're targetting xilinx, it can be hugely inefficient.
>this was certainly true in 1.4, but it may have been fixed now. if it
>hasn't been fixed, forget it.
>
>vhdl is much harder to learn than abel. it's further removed from the
>hardware, so you have to think about it more. the upside is that it's
>*much* better for system descriptions, and simulation. there are lots
>of other pros and cons for/against VHDL, but those are probably the
>main points.
>
>evan
>


Article: 14935
Subject: Re: JTAG HANG UP......
From: matthew@murph.xsj.xilinx.com (Matthew Murphy)
Date: 25 Feb 1999 14:27:54 -0800
Links: << >>  << T >>  << A >>
In article <7b3509$23u$1@supernews.com>, Mike H. <mikeh@imageproc.com> wrote:
>
>Jim wrote in message <36D4AA69.E95CB74@erols.com>...
>>Any folks run into any JTAG gotchas with pulling up the 
>>tdi and tclk pins?
>

Many devices have internal pullups on TCK and TDI you should check the vendors
devices for there pull up values. Also, keep in mind that with each device 
you add to your jtag chain will pull the signals up from ground. Depending 
on thestrength of the pullups, this can cause intermittent noise problems
for large chains. 

Matt


-- 
//\/\ Matt Murphy        matthew.murphy@xilinx.com
\\  / XILINX             Main: 408-559-7778
//  \ 2100 Logic Drive   Direct: 408-879-4666
\\/\/ San Jose, CA 95124 FAX: 408-879-5171
Article: 14936
Subject: Re: Your view on this article?
From: Christof Paar <christof@ece.wpi.edu>
Date: Thu, 25 Feb 1999 17:37:42 -0500
Links: << >>  << T >>  << A >>
Very interesting comments from Tom.

Does anyone know whether people (in academia or industry) are actually
working on ASICs with on-chip FPGA in a systematic manner?

Is there info on the web or research literature on that?

Christof


>>>  WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS (CHES) <<<
>>>                   WPI, August 12 & 13, 1999                     <<<
>>>         check  http://ece.wpi.edu/Research/crypt/ches           <<<

***********************************************************************
                 Christof Paar,  Assistant Professor
          Cryptography and Information Security (CRIS) Group
      ECE Dept., WPI, 100 Institute Rd., Worcester, MA 01609, USA
fon: (508) 831 5061    email: christof@ece.wpi.edu   
fax: (508) 831 5491    www:   http://ee.wpi.edu/People/faculty/cxp.html
***********************************************************************

On Thu, 25 Feb 1999, Tom Kean wrote:

[cut]

> My view is that the architecture will split off in two ways to take
> advantage of the potential of the process technology:

> 1.  ASIC's with FPGA blocks.  This lets customers build a high volume
> solution with the level of programmability required by their market.  
> High volume products need programmable logic but they can't afford
> single chip FPGA's.  The question is can the FPGA vendors own this
> market or will the FPGA get reduced to just another core.


> 2. Specialist computing.  Computing will always eat as much silicon as
> you can throw at it.  This is the place where an FPGA vendor can sell
> catalog parts.  And there are real advantages to custom computing.  
> But there is a big problem: you cannot compete in this market with
> classic FPGA's.  You have to build something new which has some
> features of an FPGA and lots of features from conventional processors
> and you have to redefine the company to sell compute power, not
> programmable ASIC's.
> 
> The question is whether the FPGA companies are entrepreneurial enough
> to risk today's business addressing the opportunities.  If they do not
> they will be left with a 'cash cow' product in a shrinking market.
> 
> Tom Kean.
> 
> 

Article: 14937
Subject: Re: JTAG HANG UP......
From: Jim <jok@erols.com>
Date: Thu, 25 Feb 1999 19:45:49 -0500
Links: << >>  << T >>  << A >>
I think in this particular glitch the part relied on a 
power up reset based on ramp voltage of the Vdd. I will not mention
vendor, but it appears to save pins they neglected to provide
a specific reset pin, but recomend pulling both clk and data high.
But, if race between clk and data... and clk wins we get 0 into
jtag controller. The solution was to pull them low during power
up.

Mike H. wrote:
> 
> Jim wrote in message <36D4AA69.E95CB74@erols.com>...
> >Any folks run into any JTAG gotchas with pulling up the
> >tdi and tclk pins?
> 
> The only problems I've experienced have been with the
> /TRST pin, which seems to be interpreted differently
> by different devices. Some like it pulled up when the
> JTAG port isn't being used, some like it pulled down.
> Can lead to operational inconsistencies.
> 
> Mike H.
Article: 14938
Subject: Re: Xilinx ABEL?
From: ibaggett@bagotronix.com
Date: Fri, 26 Feb 1999 01:22:36 GMT
Links: << >>  << T >>  << A >>
On Thu, 25 Feb 1999 10:12:26 -0500, "Don  Brouse" <dcbrouse@yahoo.com>
wrote:

>Hi
>I am trying to learn to use the ABEL HDL language included with the Xilinx
>Foundations Base package.  Xilinx tech support tells me that the only
>documentation on this language is in the help files included with the
>software.  I am new to HDL and am having trouble getting started with this.
>
>Does anyone know where I can learn more about this language and is it worth
>using, or should I pay to get the VHDL upgrade?
>
>I have been experementing with the state machine editor and looking at the
>ABEL code it generates.  I have not been able to get a registered output to
>hold its value when the machine enters a new state.  Xilinx tells me to
>define all the outputs in every state.  Is this true?  According to one of
>their tutorials, designs coded in VHDL will hold the outputs.  Its hard to
>believe that VHDL will hold the values and ABEL won't.
>
>

If you have not invested much time in ABEL, you should skip it and go
to VHDL.  I personally like ABEL better than VHDL, but maybe my
opinion will change once I know VHDL better.  I am being forced into
VHDL by market forces and I don't like it.  I have yet to find a good
tutorial on VHDL - the textbooks I've seen are written by people who
are gurus but obviously have never designed actual hardware to fit
into real FPGAs to go into real products.

I find ABEL easier to learn and use to describe digital logic.
Supposedly VHDL has applicability to other areas besides digital
logic, so is touted as the "holy grail" of description languages.  Big
deal.  All I want to do is synthesize digital logic for real parts.
The only thing I have not been able to do in ABEL that can be done is
VHDL is to explicitly assign a clocking signal to a dedicated global
clock line in a Xilinx FPGA.  The only reason this is so is that
Xilinx never added the feature to ABEL that would let you make the
assignment.  It is not a shortcoming of ABEL itself - the Lattice
ispDS+ system will let you specify "properties" in the ABEL file to do
this sort of thing.

Just remember, market forces are bigger than you are, and the market
forces say "VHDL" :-(

Best regards,
Ivan Baggett
Bagotronix

Article: 14939
Subject: Re: Your view on this article?
From: "Wade D. Peterson" <peter299@maroon.tc.umn.edu>
Date: Thu, 25 Feb 1999 20:00:56 -0600
Links: << >>  << T >>  << A >>
Ilija Hadzic wrote in message <7b1gmt$nlu$1@netnews.upenn.edu>...
>Well, most of the stuff said in the article was known before. It was
>never an intent to replace ASICs with FPGAs. All FPGA vendors have
>always stressed that the main strength is in time-to-market which makes
>FPGAs useful in prototyping and early stages of production. On a long run
>ASIC pays off, but it is tough to know in advance which product will live
>sufficiently long.
>
>The main place for FPGAs is in R&D labs and early-stage/low-volune
>production and it will stay this way unless the run-time reconfigurable
>computing gets onto the main stream when things might change dramatically.
>
>Ilija Hadzic
>University of Pennsylvania

There are also many companies who ship their entire product line on FPGAs, so I
think there will always be a place for large programmable logic devices.  A lot
of ASIC vendors won't work with you unless you buy 5K - 10K pieces, which is out
of range for many types of products/companies.  Certainly, FPGAs don't work well
for consumer goods, but for industrial/military/telecom applications, they fill
a niche perfectly.

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



Article: 14940
Subject: Bus Interface
From: bender@rexnet.net (Joe Bender)
Date: Thu, 25 Feb 1999 20:08:22 -0800
Links: << >>  << T >>  << A >>
TYPE FlowDirectionType IS
(
 XILINX_TO_SBUS,
 SBUS_TO_XILINX
);

SIGNAL FlowDirection: FlowDirectionType;


 -- Assuming SBus is 16 bits wide
-- SBusData is in your PORT definitions


SIGNAL DataOut : std_logic_vector (15 DOWNTO 0);
SIGNAL DataIn   :  std_logic_vector (15 DOWNTO 0);

-- This directional control is not in a PROCESS
SBusData <=  DataOut WHEN ( FlowDirection = XILINX_TO_SBUS) ELSE
                  "ZZZZZZZZZZZZZZZZ";

-- These are located within a clocked process.
 FlowDirection <= SBUS_TO_XILINX;
DataIn <= SBusData;





*** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ***
Article: 14941
Subject: Re: Xilinx ABEL?
From: Mark Summerfield <m.summerfield@ee.mu.oz.au>
Date: Fri, 26 Feb 1999 16:31:57 +1100
Links: << >>  << T >>  << A >>
Don,

You might want to take a look at a Web page I put together at
  http://www.ee.mu.oz.au/staff/summer/pl_case_study/casestudy.html

It's a single (fairly contrived) design assignment implemented using
PALASM, ABEL and VHDL.  I am least familiar with ABEL, and so I might
have missed some language features that would have made the design
I little more elegant, maintainable and/or portable -- I'd welcome
feedback on this.  The case study also looks at the results of 
implementing the VHDL version in two different architectures (a CPLD
and an FPGA).

You will find a simple four-state FSM at the heart of the design, so
you can see how I handled exactly the same problem in both ABEL and
VHDL.  Note that I separated the state machine and the output decoding
in both cases -- in ABEL I used one module for the state machine and
another module to decode its outputs.  In both ABEL and VHDL I specify
explicitly (with "else") that when no transition conditions are true,
the FSM should stay in the current state.  As others have pointed out,
in VHDL this is optional, because a default of "no change" is implied
(i.e. registers are inferred by the compiler -- if I deleted all the
"else" clauses in the VHDL state-transition code, it would still
describe the same behaviour).  In ABEL it is mandatory -- the compiler 
must be explicitly told what to do under all circumstances.

I think the main strength of VHDL is its level of abstraction.  It's
probably also its main weakness ;-)  I discuss my conclusions on the
Web page, so I won't repeat myself here.

Mark.
Article: 14942
Subject: wanted: info about Fast Ethernet cores
From: charles@efficient.com (Charles F. Shelor)
Date: Fri, 26 Feb 1999 00:27:57 -0600
Links: << >>  << T >>  << A >>
Howdy,

I am involved in a make/buy decision to develop or purchase a VHDL
based Fast Ethernet core for use in an FPGA and then migrate to
an ASIC.  I am interested in any opinions, recommendations, etc
from anyone who has purchased/used a Fast Ethernet core in an
FPGA/ASIC.  Core vendors are welcomed to respond as well.

Thanks,

Charles

charles@efficient.com

Charles F. Shelor
Efficient Networks
"DSL for the Masses"
972 991 3884

-- 
Charles Shelor                      (formerly  SHELOR ENGINEERING
Sr ASIC Designer                     VHDL Training and models)
Efficient Networks, Inc              http://www.efficient.com
972 991 3884                         mailto:charles@efficient.com
Article: 14943
Subject: Re: Problem with xilinx M1
From: "Sergio A. Cuenca Asensi" <sergio@dtic.ua.es>
Date: Fri, 26 Feb 1999 10:50:48 +0100
Links: << >>  << T >>  << A >>


Jonas Thor wrote:

> On Tue, 23 Feb 1999 08:40:54 +0100, "Sergio A. Cuenca Asensi"
> <sergio@dtic.ua.es> wrote:
>
> >
> >
>
> >Hi,
> >you are right, the number of startups is the reason. I created three
> >vhdl modules, one fsm and two for datapath, all three with asynchronous
> >reset and connected in the schematic to the same ipad (rst), so I donīt
> >understand why it produces three startup.
>
> Did you synthesize the VHDL modules separately?

YES

> If you did, turn the
> "force global reset" option off and instantiate the startup symbol in
> the schematics instead. I believe you have a startup symbol for each
> VHDL module.
>
> / Jonas Thor

OK but where is the "force global reset" option, I can't find it (I'm usign
FPGAExpress v2.0).
TIA

--
===================================================================
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
===================================================================


Article: 14944
Subject: Xilinx 9500XL
From: "Bill" <bb@alphadata.co.uk>
Date: Fri, 26 Feb 1999 09:55:40 -0000
Links: << >>  << T >>  << A >>
I'm using 95144XLTQ100 and have found that 1.5i+sp1+cpld_020799 still don't
produce correct jedec files. Simulation and verification produce OK results.

The main problem is that FDCE is now a primitive in XL (it wasn't in the 5V
parts)and when loaded into an XL produces a 1 on the ouput continuously.
Implementing FDCE using an FD and M2_1 is OK.

Anybody else got this problem and are there any more I don't know about ?

Bill



Article: 14945
Subject: Re: Problem with xilinx M1
From: "Sergio A. Cuenca Asensi" <sergio@dtic.ua.es>
Date: Fri, 26 Feb 1999 11:02:10 +0100
Links: << >>  << T >>  << A >>


Andy Peters wrote:

>
> >
> >Hi,
> >you are right, the number of startups is the reason. I created three
> >vhdl modules, one fsm and two for datapath, all three with asynchronous
> >reset and connected in the schematic to the same ipad (rst), so I donīt
> >understand why it produces three startup.
>
> Do you have a top-level module that instantiates the three lower-level
> modules?  It sounds like you've synthesized all three as top-level modules;
> hence, three startup blocks.
>
> -- a
>

Yes, I've synthesized all three as top-level modules.  I want three independent
modules but without starpup blocks, the problem is that I can't find any option
in FPGA express to avoid startup adding to them. Do you know where is it?
Regards

--
===================================================================
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
===================================================================


Article: 14946
Subject: pipelined multipliers for behavioral synthesis (->XC4062XL)
From: "Matthias Brucke" <Matthias.Brucke@Informatik.Uni-Oldenburg.DE>
Date: Fri, 26 Feb 1999 12:50:58 GMT
Links: << >>  << T >>  << A >>
Hi folks,

i am playing around with behavioral synthesis (synopsys bc). Target is
ilinx XC4062XL. 

I want to implement a IIR-filter in Behavioral VHDL, which makes
extensive use of the *-Operation ;). But one can use the
map_to_operator pragma to tell bc which synthetic operator it should
use. Then you can tell him in a synthetic library how to map this
synthetic operator to a synthetic module. And then it can find a
schedule and the depth of the pipeline (semi-automatically). So you
dont have to write the controller for memory-access etc.

When trying to map the synthetic operator * to a pipelined multiplier
from CoreGen I came across the problem that Coregen only produces an
instantiation template (VHDL) and an EDIF-Netlist (with lots of
unconnected ports and nets). 

From the view of VHDL this all is used as a black box which will be
linked in later by the Xilinx tools. That works very well.

But for scheduling, bc needs "some more information" about the
operator. So I wrote a synthetic library telling bc, that it is a 6
stage pipelined multiplier, defined the pins, bindings and stages,
and that it should be mapped to the apropriate module (which is a VHDL
entity instantiating the coregen module).

The problem is, that bc wants to compile the module to gates which is
not possible, because it is a black box.

Has anyone had a similiar problem and come to a a solution. This seems
to me not to be an unusual problem, beacuse I think many people use
blocks from their technology vendor.

BTW this works well for wappers for Xilinx RAMs

Thanks for an answer

Mats

PS: Reading my posting again it all sounds totally weird ;)
--
Matthias Brucke                             Computer Science Departement
VLSI Group                                       University of Oldenburg
Article: 14947
Subject: Re: Xilinx ABEL?
From: Richard Russell <rtr@rd.bbc.co.uk>
Date: 26 Feb 1999 13:34:56 GMT
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM wrote:
: abel or vhdl? on the plus side, abel is easy to learn, once you've
: figured out a way to cope with polarities. simulation is nice and
: easy, and fairly powerful. on the minus side, the language is almost
: dead, and, if you're targetting xilinx, it can be hugely inefficient.
: this was certainly true in 1.4, but it may have been fixed now. if it
: hasn't been fixed, forget it.

I use Abel-FPGA all the time, and efficiency is often important to me.
For the majority of designs I find the Xilinx fitter (ImproveX Release
5.0.0) quite acceptable, but for the most critical performance I disable
this (fitlca -strategy no_opt) and hand-craft the Abel code to suit the
CLB architecture (this isn't as difficult as it sounds).

Richard.
Article: 14948
Subject: Re: Xilinx ABEL?
From: russmay@ditmco.com (Russell May)
Date: Fri, 26 Feb 1999 15:26:58 GMT
Links: << >>  << T >>  << A >>
I tried to use XABEL in Foundation M1.4. I found it easy to use,
but so buggy and inefficient that I gave up on it after many tries and
communication with XILINX tech support; whose comment (according to my
local XILINX distributor) was "XABEL sucks", at least for FPGA's.
I find Altera AHDL to be nearly as easy to use as XABEL, much faster,
and much more efficient. The one design I tried with XABEL took ten
minutes total compile, check, and output time versus one minute for
AHDL; and used four times as many macrocell-equivalents as AHDL.
Unfortunately AHDL is proprietary to Altera. Despite its complexity
and cost, I would recommend VHDL over XABEL for Xilinx products of any
significant complexity. MHO

Russell May

>Don Brouse wrote in message <7b3pc1$kl7$1@news1.fast.net>...
>>Hi
>>I am trying to learn to use the ABEL HDL language included with the Xilinx
>>Foundations Base package.  Xilinx tech support tells me that the only
>>documentation on this language is in the help files included with the
>>software.  I am new to HDL and am having trouble getting started with this.
>>
>>Does anyone know where I can learn more about this language and is it worth
>>using, or should I pay to get the VHDL upgrade?
>>
>>I have been experementing with the state machine editor and looking at the
>>ABEL code it generates.  I have not been able to get a registered output to
>>hold its value when the machine enters a new state.  Xilinx tells me to
>>define all the outputs in every state.  Is this true?  According to one of
>>their tutorials, designs coded in VHDL will hold the outputs.  Its hard to
>>believe that VHDL will hold the values and ABEL won't.
>>
>>
>
>

Article: 14949
Subject: Re: wanted: info about Fast Ethernet cores
From: Wiggo Olufsen <wiggo.olufsen@online.no>
Date: Fri, 26 Feb 1999 16:57:20 +0100
Links: << >>  << T >>  << A >>
Charles,

You may find something at this location:
http://www.design-reuse.com/index.html

Good luck.
Wiggo.

Charles F. Shelor wrote:

> Howdy,
>
> I am involved in a make/buy decision to develop or purchase a VHDL
> based Fast Ethernet core for use in an FPGA and then migrate to
> an ASIC.  I am interested in any opinions, recommendations, etc
> from anyone who has purchased/used a Fast Ethernet core in an
> FPGA/ASIC.  Core vendors are welcomed to respond as well.
>
> Thanks,
>
> Charles
>
> charles@efficient.com
>
> Charles F. Shelor
> Efficient Networks
> "DSL for the Masses"
> 972 991 3884
>
> --
> Charles Shelor                      (formerly  SHELOR ENGINEERING
> Sr ASIC Designer                     VHDL Training and models)
> Efficient Networks, Inc              http://www.efficient.com
> 972 991 3884                         mailto:charles@efficient.com



--
+---------------------------------------------------------------+
| Wiggo Olufsen                                                 |
| Cypress Software AS           Phone : +47-73-52 46 59         |
| P.O.Box 2668                  Fax   : +47-73-52 46 80         |
| N-7001 TRONDHEIM              E-mail: wiggo.olufsen@online.no |
| NORWAY                                                        |
+---------------------------------------------------------------+




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search