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 21875

Article: 21875
Subject: Re: MaxPlus9.5 License and Fitter problems
From: Ray Andraka <randraka@ids.net>
Date: Wed, 05 Apr 2000 00:07:50 GMT
Links: << >>  << T >>  << A >>


Tim wrote:

> Oh, I did have to turn off the Quartus fitter to make the timing
> requirement in a design that easily makes the timing requirements in
> 9.3.
>
> Up to 25xs faster compile....the gods of marketing are feeling playful
> today.
>

This is not my experience at all.  I found 9.5 to compile quite a bit faster (a
few hours instead of days for a 10K250 design), and the result was better.  25x
might be a stretch, but my results certainly indicate that it is in the
ballpark.  9.5 also made timing on the first pass where 9.3 wouldn't make timing
no matter what I did.  That was mostly because the designs I was dealing with
were heavily arithmetic (some 70% of the used LEs in arithmetic mode), and for
some reason 9.3 pushes additional pipeline registers toward the previous
flip-flop instead toward the combinatorial logic leading up to the next
register.  Where that combinatorial logic is a carry chain and the previous
flip-flop is in another row, this is a problem.

One thing I did notice with 9.5 is that you have to have the timing driven route
turned on.  It doesn't seem to work well without timing guidelines (In fact 9.3
seems to generate better non-timing constrained results, even if it takes a bit
longer).  9.5 also ignores any cliques you have in the design, but then it was
never really clear that 9.3 really followed them anyway.


--
-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: 21876
Subject: Re: Clocks and BUFGP
From: Ray Andraka <randraka@ids.net>
Date: Wed, 05 Apr 2000 00:41:41 GMT
Links: << >>  << T >>  << A >>
All the CLBs can be connected to the BUFGPs, and in fact that is the way
a clock is normally distributed.  The K pin is the CLB clock pin.  If
your signal goes thru the switch matrices, you can get to any CLB pin,
but you wind up with some skew.  Each of the 4 BUFGPs have skew
controlled  connections to the K input of every CLB.  Additionally, the
Top Left one can be wired directly to the F3 and/or G3 inputs, the BL
one goes to the F1 and G1 inputs,  BR connects to the C3 and TR connects
to C1.  F and G inputs are inputs to the LUTs, K is the clock input, and
C inputs go to some muxes that then connect to either the H generator or
the flip-flop.  This applies to all the CLBs in the 4K/spartan devices.
Normally, you wouldn't use the CLB as a library element, instead you
would use logic primitives and either explicitly map them into the CLB
with FMAPs or let the tools do the mapping automatically.  If you
connect a clock to something other than a flip-flop clock input, then
the tools will normally map the logic such that it makes the connection
through a direct path.  Exceptions only occur if the CLB pins are
locked.  Normally, the pins should not be locked so the PAR software can
switch them around for a better route.  Using the carry chain does lock
the pins however, so that if you have a BUF_GP driving a carry chain it
is likely to be routed through a longer path unless you are careful
about the BUFGP assignments.

Chuck Carlson wrote:

> I'm using BUFGP to drive a clock and the docs seem to indicate it
> can be connected to K and F3 pins of a CLB only.  I've been trying
> to find such a CLB in the library and cannot.  Does anyone know
> of CLB's that BUFGP can drive?
>
> Thanks
>
> Chuck

--
-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: 21877
Subject: Re: JTAG programming
From: "Grzegorz" <g_lis@microtech.com.pl>
Date: Wed, 05 Apr 2000 06:39:48 GMT
Links: << >>  << T >>  << A >>

"Jean-Paul GOGLIO" <goglio@getris.com> wrote in message
news:8ccl3c$3lc$1@reader1.fr.uu.net...
> We got a similar problem with a board including about 12 Xilinx FPGA and 7
> Sharc DSP in a single JTAG Chain.
> The Xilinx JTAG programmer didn't see the FPGA that were after a DSP in
the
> chain and the DSP emulator didn't work if the DSP were not first in the
> chain. (We checked that BSDL files for DSP were OK, but we found no
> solution)
>
> So we had to split the JTAG chain in 2 chains, one for xilinx chips, and
one
> other for DSP. After that, it worked fine.

Right. Another thing is : should JTAG interface work with ADSP21160 if it
doesn't
get clock ? Clock is supplied by one of  FPGA - not programmed yet. Is
JTAG's
TCK enough ?


Regards,

Grzegorz

// g_lis@microtech.com.pl


Article: 21878
Subject: Area ratio between routing resource and logic block
From: Bingfeng Mei <bennet@imec.be>
Date: Wed, 05 Apr 2000 13:25:43 +0200
Links: << >>  << T >>  << A >>
Hi, who knows the die area ratio between routing resource (local and
global) and logic block (such as CLB) in a typical commercial FPGA?
Thanks.

Article: 21879
Subject: Re: MaxPlus9.5 License and Fitter problems
From: timjeno@visto.com (Tim )
Date: Wed, 05 Apr 2000 12:51:19 GMT
Links: << >>  << T >>  << A >>
Hmmm, I reviewed your suggestions and the only one I didn't match on
was that I had "Ignore timing requirements during fitting" on.  I'll
flip on the Quartus fitter and try again at least for academic
curiosity.

Here's a couple of the details from the two compiles I referred to
earlier:

Old software:   compiled successfully after 39 minutes
	          size : 4319 Logic Cells
	          peak memory allocated during compilation : 140 MB

New  : compiled after 37 minutes UNSUCCESSFULLY implementing one
timing constraint
		    size : 4328 logic cells
		    peak memory allocation : 199 MB

The timing constraint on the global clock was 20Mhz.  The logic is an
assortment of communications related blocks, correlators,
synchronization, etc and a blob of glue logic.  The part is a 10k130E.


I am happy to hear both of you have had good results with 9.5 and the
Quartus fitter.  It certainly wouldn't be fair for me to evaluate it
on a single sample point.  These radios will have to ship without help
from the Quartus fitter but I'll try again next project.

           Thanks for the info!

                      Tim.


Article: 21880
Subject: Re: JTAG programming
From: rob_dickinson@my-deja.com
Date: Wed, 05 Apr 2000 13:25:24 GMT
Links: << >>  << T >>  << A >>
In article <UcBG4.35842$a01.783952@news.tpnet.pl>,
  "Grzegorz" <g_lis@microtech.com.pl> wrote:
>
> "Jean-Paul GOGLIO" <goglio@getris.com> wrote in message
> news:8ccl3c$3lc$1@reader1.fr.uu.net...
> > We got a similar problem with a board including about 12 Xilinx
FPGA and 7
> > Sharc DSP in a single JTAG Chain.
> > The Xilinx JTAG programmer didn't see the FPGA that were after a
DSP in
> the
> > chain and the DSP emulator didn't work if the DSP were not first in
the
> > chain. (We checked that BSDL files for DSP were OK, but we found no
> > solution)
> >
> > So we had to split the JTAG chain in 2 chains, one for xilinx
chips, and
> one
> > other for DSP. After that, it worked fine.
>
> Right. Another thing is : should JTAG interface work with ADSP21160
if it
> doesn't
> get clock ? Clock is supplied by one of  FPGA - not programmed yet. Is
> JTAG's
> TCK enough ?
>
> Regards,
>
> Grzegorz
>
> // g_lis@microtech.com.pl
>
I used to work with JTAG, with MACH4-128's and SHARC DSP's.  I'm sure
that you have worked out the common thread by now.  If memory serves,
the SHARCs don't quite meet the JTAG spec in terms of the JTAG id
registers, the hardware implementation is correct.  We got around it
because we had our own jtag program, I've no idea how to get the Xilinx
tools to work around this.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21881
Subject: Re: MaxPlus9.5 License and Fitter problems
From: timjeno@visto.com (Tim )
Date: Wed, 05 Apr 2000 13:58:12 GMT
Links: << >>  << T >>  << A >>

...
>longer).  9.5 also ignores any cliques you have in the design, but then it was
>never really clear that 9.3 really followed them anyway.
...

That would be unfortunate if it really ignores cliques.  They've been
very valuable to me.  If you don't mind, what is it that indicated to
you 9.5 is ignoring cliques.


                   Tim.
Article: 21882
Subject: PCI Bridge to Xilinx XCV*E
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Wed, 05 Apr 2000 17:20:49 +0300
Links: << >>  << T >>  << A >>
Can you recommend any bridge through which Motorola's
860 or 8240 processors can control XCV*E FPGAs? There
will be many Virtex-E devices on the board, like 10.
FPGA's CPU Interface will communicate to this Bridge.
Or is there any better newsgroup to direct this q?

Utku

-- 
I feel better than James Brown.
Article: 21883
Subject: Re: MaxPlus9.5 License and Fitter problems
From: Vaughn Betz <vaughn@rtrack.com>
Date: Wed, 05 Apr 2000 14:27:39 GMT
Links: << >>  << T >>  << A >>


Tim wrote:
> 
> Hmmm, I reviewed your suggestions and the only one I didn't match on
> was that I had "Ignore timing requirements during fitting" on.  I'll
> flip on the Quartus fitter and try again at least for academic
> curiosity.

That will be your problem then.  When Ignore timing requirements during
fitting is on, it's exactly as if you hadn't specified any timing
requirements (the fitter truly does ignore them all).  It's rather
counter-intuitive that you have to turn off that setting to make your
timing assignments have any effect, but that's the way it is.

Vaughn Betz
Right Track CAD

> 
> Here's a couple of the details from the two compiles I referred to
> earlier:
> 
> Old software:   compiled successfully after 39 minutes
>                   size : 4319 Logic Cells
>                   peak memory allocated during compilation : 140 MB
> 
> New  : compiled after 37 minutes UNSUCCESSFULLY implementing one
> timing constraint
>                     size : 4328 logic cells
>                     peak memory allocation : 199 MB
> 
> The timing constraint on the global clock was 20Mhz.  The logic is an
> assortment of communications related blocks, correlators,
> synchronization, etc and a blob of glue logic.  The part is a 10k130E.
> 
> I am happy to hear both of you have had good results with 9.5 and the
> Quartus fitter.  It certainly wouldn't be fair for me to evaluate it
> on a single sample point.  These radios will have to ship without help
> from the Quartus fitter but I'll try again next project.
> 
>            Thanks for the info!
> 
>                       Tim.
Article: 21884
Subject: CHES 2000 deadline extended
From: Christof Paar <christof@ece.wpi.edu>
Date: Wed, 5 Apr 2000 11:00:41 -0400
Links: << >>  << T >>  << A >>
The submission deadline was extended to April 30. - Christof

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

      Workshop on Cryptographic Hardware and Embedded Systems 2000
                            (CHES 2000)
              http://www.ece.WPI.EDU/Research/crypt/ches

                  Worcester Polytechnic Institute
                  Worcester, Massachusetts, USA
                       August 17 & 18, 2000

                  Third and Final Call for Papers
                     --- DEADLINE EXTENDED ---

General Information

The focus of this workshop is on all aspects of cryptographic hardware
and embedded system design. The workshop will be a forum of new results
from the research community as well as from the industry. Of special
interest are contributions that describe new methods for efficient
hardware implementations and high-speed software for embedded systems,
e.g., smart cards, microprocessors, DSPs, etc. We hope that the
workshop will help to fill the gap between the cryptography research
community and the application areas of cryptography. Consequently, we
encourage submission from academia, industry, and other organizations.
All submitted papers will be reviewed.

This will be the second CHES workshop. The first workshop, CHES '99,
was held at WPI in August of 1999 and was very well received by
academia and industry. There were 170 participants, more than half of
which were from outside the United States.

The topics of interest include but are not limited to:

   * Computer architectures for public-key cryptosystems
   * Computer architectures for secret-key cryptosystems
   * Reconfigurable computing and applications in cryptography
   * Cryptographic processors and co-processors
   * Modular and Galois field arithmetic architectures
   * Tamper resistance on the chip and board level
   * Smart card attacks and architectures 
   * Efficient algorithms for embedded processors
   * Special-purpose hardware for cryptanalysis
   * Fast network encryption
   * True and pseudo random number generators
   * Cryptography in wireless applications

Mailing List

If you want to receive emails with subsequent Call for Papers and
registration information, please send a brief mail to
ches@ece.orst.edu.

Instructions for Authors

Authors are invited to submit original papers. The preferred submission
form is by electronic mail to ches@ece.orst.edu. Papers should be
formatted in 12pt type and not exceed 12 pages (not including the title
page and the bibliography). The title page should contain the author's
name, address (including email address and an indication of the
corresponding author), an abstract, and a small list of key words.
Please submit the paper in Postscript or PDF. We recommend that you
generate the PS or PDF file using LaTeX, however, MS Word is also
acceptable. All submissions will be refereed.

Only original research contributions will be considered. Submissions
must not substantially duplicate work that any of the authors have
published elsewhere or have submitted in parallel to any other
conferences or workshops that have proceedings.

Workshop Proceedings

The post-proceedings will be published in Springer-Verlag's Lecture
Notes in Computer Science (LNCS) series. Notice that in order to be
included in the proceedings, the authors of an accepted paper must
guarantee to present their contribution at the workshop.

Important Dates

 Submission Deadline:          April 30th, 2000.
 Acceptance Notification:      July  1st, 2000.
 Final Version due:            August 1st, 2000.
 Workshop:                     August 17th & 18th, 2000.
 
NOTES: The CHES dates August 17 & 18 are the Thursday & Friday
       preceding CRYPTO 2000 which starts on August 20.

Invited Speakers

Alfred Menezes, University of Waterloo, Canada.
       "Elliptic curve cryptography in constrained environments"

David Naccache, Gemplus, France.
       "How to explain side channel leakage to your kids"

Program Chairs

All correspondence and/or questions should be directed to either of the
Program Chairs:

 Cetin Kaya Koc                       Christof Paar
 Dept. of Electrical & Computer       Dept. of Electrical & Computer
 Engineering                          Engineering
 Oregon State University              Worcester Polytechnic Institute
 Corvallis, Oregon 97331, USA         Worcester, MA 01609, USA
 Phone: +1 541 737 4853               Phone: +1 508 831 5061
 Fax: +1 541 737 8377                 Fax: +1 508 831 5491
 Email: Koc@ece.orst.edu              Email: christof@ece.wpi.edu

Program Committee

Gordon Agnew,  University of Waterloo, Canada
Wayne Burleson,   University of Massachusetts at Amherst, USA
Kris Gaj, George Mason University, USA
Peter Kornerup, Odense University, Denmark
Arjen Lenstra, Citibank, USA
Jean-Jacques Quisquater,   Universite Catholique de Louvain, Belgium
Patrice Roussel,  Intel Corporation, USA
Christoph Ruland,   University of Siegen, Germany
Joseph Silverman, Brown University and NTRU Cryptosystems, Inc., USA
Colin Walter, Computation Department - UMIST, U.K.
Michael Wiener,   Entrust Technologies, Canada

Location

WPI is in Worcester, the second largest city in New England. The city
is 80 km (50 miles) west of Boston and 280 km (175 miles) north-east of
New York City.

Worcester is home to a wealth of cultural treasures, many of which are
just a short distance from WPI. These include the historic Higgins
Armory Museum, which houses one of the world's largest collections of
armor; the EcoTarium (formerly New England Science Center), one of the
only museums in the country dedicated to environmental education; and
the beautifully restored Mechanics Hall, one of America's finest
concert halls. The Worcester Art Museum, holding one of the nation's
finest collections, and the world-renowned American Antiquarian
Society, with the largest collection of items printed during the
nation's colonial period, are within two blocks of the WPI campus.
Worcester is also well known for its ten colleges, which cooperate
through the Colleges of Worcester Consortium.

Recreation areas within easy driving distance include Boston and Cape
Cod to the east, the White and Green mountains to the north, and the
Berkshires to the west.

August weather in New England is usually very pleasant with average
temperatures of 20 C (70 F).

Workshop Sponsors

This workshop has received generous support from cv cryptovision,
Intel, secunet AG, and SITI.  The organizers express their sincere thanks.

Article: 21885
Subject: Cheacksum implementation in VHDL
From: "Ron" <skalarv@usa.net>
Date: Wed, 5 Apr 2000 17:12:18 +0200
Links: << >>  << T >>  << A >>
I'm looking for checksum implementation in VHDL (or at least the basic rules
to build one).

Regards
Ron


Article: 21886
Subject: Re: Memory cores
From: Janos Ero <Janos.Ero@cern.ch>
Date: Wed, 05 Apr 2000 17:17:30 +0200
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> If you want to initialize the rams (upon configuration only) with something
> other than zeros you'll have to instantiate the primitives rather than infer
> the RAM.  The primitives have generics on them for the initial values
> (xilinx), which default to 0.

Could you please describe this more detailed?

My attempts to put ROM into an on-chip RAM of an 
Altera 10KE using VHDL Synthesis were not successful.

The whole thing works in AHDL perfectly. You define the 
DP-ROM module and write the content into a HEX-file,
which is nothing else than an Intel-Hex file derivate.
The MaxPlus Synthesis does not touch the content, but
the resulted Programming Device code will contain it. 
If you activate the VHDL Output Interface, you get 
a chip-level VHDL code that DOES contain the ROM code.

For the VHDL Behavioral model I wrote a program,
that reads the above HEX file and puts into
the RAM array. This is in a Process that is
started only once, after simulation start.

Nothing worked for the VHDL synthesis, however.
The HEX file read routine was (of course) unsynthesisable.
When declaring simply the ROM without content
I got an error message from the Synthesis Tool
(Leonardo), that I wanted to create a RAM
without Write Port.

There is, of course, a way, that is described
in the MaxPlus Help file: you can define
the RAM content in the VHDL model as a 
VHDL Constant's in-line code. This might
work for a small ROM, but not for a ROM
that fills out the full memory area.

Is there a possibility to describe a
ROM with content gibven in an external file?

Janos Ero

Article: 21887
Subject: ASIC synthesys using Leonardo Spectrum: any suggestion ?
From: "giuseppe giachella" <il_templare@hotmail.com>
Date: Wed, 05 Apr 2000 09:38:06 CEST
Links: << >>  << T >>  << A >>
I'm going to synthetize a 200Kgates design using Leonardo Spectrum. Our 
department has
always used Synopsys Design Compiler in Asic synthesys and I don't know 
exactly what
kind of problems I will have to face. Any suggestion ?
Can anyone make a comparison between Design Compiler and Leonardo in Asic 
synthesys ?

Thanks in advance.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com



 Sent via Deja.com http://www.deja.com/
 Before you buy.
Article: 21888
Subject: Re: MaxPlus9.5 License and Fitter problems
From: Ray Andraka <randraka@ids.net>
Date: Wed, 05 Apr 2000 16:42:12 GMT
Links: << >>  << T >>  << A >>
A conversation with someone on Altera's hotline when I got a beta version of 9.5.

Tim wrote:

> ...
> >longer).  9.5 also ignores any cliques you have in the design, but then it was
> >never really clear that 9.3 really followed them anyway.
> ...
>
> That would be unfortunate if it really ignores cliques.  They've been
> very valuable to me.  If you don't mind, what is it that indicated to
> you 9.5 is ignoring cliques.
>
>                    Tim.

--
-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: 21889
Subject: Re: Initialization of Ram in a marco
From: "Steve Casselman" <sc@vcc.com>
Date: Wed, 5 Apr 2000 10:11:21 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.

------=_NextPart_000_0021_01BF9EE7.4A7DDDE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

So I figured out how to do it. If you have a macro say beta.edn which is =
called once=20
by the top level alpha.edn the ram in beta.edn is initialize by ncf file =
beta.ncf. Simple=20
enough. If you use 2 betas in your design you need to have a beta1.edn =
and beta2.edn with files=20
beta1.ncf and beta2.ncf to initialize them.=20


Steve


  "Steve Casselman" <sc@vcc.com> wrote in message =
news:sekocur3eop82@corp.supernews.com...
  I reported a bug 2 service packs ago and I'm wondering if anyone has =
the same problem or a fix.

  I desgned a controler using viewlogic which has hierarchical ram =
control store. I also have a C compiler that generates (what was at that =
time a ucf and is now a ncf) file initializes the ram. Works great with =
1.5. Now however all ram is supposed to be initulized in the NCF file. =
The problem is that the NCF file is read BEFORE the design is resolved. =
In other words the software tries to find the ram before it reads in the =
entire design. So design "alpha" calls out macro "beta" I have a =
alpha.ngo and a beta.ngo. The ram is in beta and the software reads =
alpha reads the NCF file and bombs because it can't find "beta". The =
fact that the NCF file is read in the translator and the design is =
resolved in the mapper doesn't make sense to me.=20

  The Hotline put in a notice to the software group 6 months ago I think =
that is a little too long to fix something so trivial.=20

  =20

  Steve Casselman, President

  Virtual Computer Corporation


------=_NextPart_000_0021_01BF9EE7.4A7DDDE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>So I figured out how to do it. If you =
have a macro=20
say beta.edn which is called once </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>by the top level alpha.edn the&nbsp;ram =
in beta.edn=20
is initialize&nbsp;by ncf file beta.ncf. Simple </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>enough. If you use 2 betas in your =
design you need=20
to have a beta1.edn and beta2.edn with files </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>beta1.ncf and beta2.ncf to initialize =
them.=20
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Steve</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV>"Steve Casselman" &lt;<A =
href=3D"mailto:sc@vcc.com">sc@vcc.com</A>&gt;=20
  wrote in message <A=20
  =
href=3D"news:sekocur3eop82@corp.supernews.com">news:sekocur3eop82@corp.su=
pernews.com</A>...</DIV>
  <DIV>
  <P><FONT face=3DArial size=3D2>I reported a bug 2 service packs ago =
and I'm=20
  wondering if anyone has the same problem or a fix.</FONT></P>
  <P><FONT face=3DArial size=3D2>I desgned a controler using viewlogic =
which has=20
  hierarchical ram control store. I also have a C compiler that =
generates (what=20
  was at that time a ucf and is now a ncf) file initializes the ram. =
Works great=20
  with 1.5. Now however all ram is supposed to be initulized in the NCF =
file.=20
  The problem is that the NCF file is read BEFORE the design is =
resolved. In=20
  other words the software tries to find the ram before it&nbsp;reads in =
the=20
  entire design. So design "alpha" calls out macro "beta" I have a =
alpha.ngo and=20
  a beta.ngo. The ram is in beta and the software reads alpha reads the =
NCF file=20
  and bombs because it can't find "beta". The fact that the NCF file is =
read in=20
  the translator and the design is resolved in the mapper doesn't make =
sense to=20
  me. </FONT></P>
  <P><FONT face=3DArial><FONT size=3D2>The Hotline put in a notice to =
the software=20
  group 6 months ago I think that is a little too long&nbsp;to fix =
something so=20
  trivial. </FONT></FONT></P>
  <P><FONT face=3DArial></FONT>&nbsp;</P>
  <P><FONT face=3DArial><FONT size=3D2>Steve Casselman, =
President</FONT></FONT></P>
  <P><FONT face=3DArial><FONT size=3D2>Virtual Computer=20
  Corporation</FONT></P></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0021_01BF9EE7.4A7DDDE0--

Article: 21890
Subject: Re: Clocks and BUFGP
From: Brian Philofsky <brianp@xilinx.com>
Date: Wed, 05 Apr 2000 10:45:20 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------E400E8404817860B6926BC6A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



If you are talking about an XC4000/XC4000E/Spartan device which is
assumed by the nomenclature, take a look at:
 http://support.xilinx.com/techdocs/107.htm  and/or
http://support.xilinx.com/techdocs/116.htm  .  I believe these describe
what you are asking for.


--  Brian


Chuck Carlson wrote:

> I'm using BUFGP to drive a clock and the docs seem to indicate it
> can be connected to K and F3 pins of a CLB only.  I've been trying
> to find such a CLB in the library and cannot.  Does anyone know
> of CLB's that BUFGP can drive?
>
> Thanks
>
> Chuck

--------------E400E8404817860B6926BC6A
Content-Type: text/x-vcard; charset=us-ascii;
 name="brianp.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brian Philofsky
Content-Disposition: attachment;
 filename="brianp.vcf"

begin:vcard 
n:Philofsky;Brian
tel;work:1-800-255-7778
x-mozilla-html:TRUE
url:http://www.xilinx.com
org:Xilinx, Inc.;Software Marketing
adr:;;2100 Logic Dr.;San Jose;CA;95124;USA
version:2.1
email;internet:brianp@xilinx.com
title:Technical Marketing Engineer
fn:Brian Philofsky
end:vcard

--------------E400E8404817860B6926BC6A--

Article: 21891
Subject: Re: Clocks and BUFGP
From: Brian Philofsky <brianp@xilinx.com>
Date: Wed, 5 Apr 2000 13:45:20 -0400
Links: << >>  << T >>  << A >>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF9F1D.E85A9342
Content-Type: text/plain;
	charset="iso-8859-1"



If you are talking about an XC4000/XC4000E/Spartan device which is
assumed by the nomenclature, take a look at:
 http://support.xilinx.com/techdocs/107.htm  and/or
http://support.xilinx.com/techdocs/116.htm  .  I believe these describe
what you are asking for.


--  Brian


Chuck Carlson wrote:

> I'm using BUFGP to drive a clock and the docs seem to indicate it
> can be connected to K and F3 pins of a CLB only.  I've been trying
> to find such a CLB in the library and cannot.  Does anyone know
> of CLB's that BUFGP can drive?
>
> Thanks
>
> Chuck


------_=_NextPart_000_01BF9F1D.E85A9342
Content-Type: text/x-vcard;
	name="brianp.vcf"
Content-Disposition: attachment;
	filename="brianp.vcf"
Content-Description: Card for Brian Philofsky

begin:vcard 
n:Philofsky;Brian
tel;work:1-800-255-7778
x-mozilla-html:TRUE
url:http://www.xilinx.com
org:Xilinx, Inc.;Software Marketing
adr:;;2100 Logic Dr.;San Jose;CA;95124;USA
version:2.1
email;internet:brianp@xilinx.com
title:Technical Marketing Engineer
fn:Brian Philofsky
end:vcard

------_=_NextPart_000_01BF9F1D.E85A9342--

Article: 21892
Subject: Re: Memory cores
From: Ray Andraka <randraka@ids.net>
Date: Wed, 05 Apr 2000 19:22:01 GMT
Links: << >>  << T >>  << A >>
You need to get the data into the VHDL one way or another.  In the Xilinx case I
previously addressed, you's still have to get the data into VHDL to put the values
in the Generics in the VHDL components.  That example was intended for the case
where you have RAM that you will be writing, but that you want to come up with
known contents upon FPGA configuration.

Here's what I'd recommend for what you want to do:  Put the ROM contents into a
separate VHDL package, which you then include when you compile your VHDL.  The
package would be a separate file containing a constant integer array which has the
hex values.  Then, you can write a fairly simple program in the language of your
choice (I use C to do this) to generate the VHDL package file.

for example, your adjuct program would generate the following VHDL file from your
hex file:

library ieee;
use ieee.std_logic_1164.all;
package parameters is
    type TABLE_TYPE is array (NATURAL range <>) of integer;
    constant EXP_LUT: TABLE_TYPE:= (
  5918491, 5721208, 5523925, 5326641, 5129358, 4932075, 4734792, 4537509,  --  0:7

  4340226, 4142943, 3945660, 3748377, 3551094, 3353811, 3156528, 2959245,  --
8:15
  2761962, 2564679, 2367396, 2170113, 1972830, 1775547, 1578264, 1380981,  --
16:23
  1183698, 986415, 789132, 591849, 394566, 197283,     0, -197283  -- 24:31
 );
end package parameters;

Then in your VHDL code you would put:

library work;
use work.parameters.all;

to make the constant EXP_LUT visible to the rest of your code.

Janos Ero wrote:

> Ray Andraka wrote:
> >
> > If you want to initialize the rams (upon configuration only) with something
> > other than zeros you'll have to instantiate the primitives rather than infer
> > the RAM.  The primitives have generics on them for the initial values
> > (xilinx), which default to 0.
>
> Could you please describe this more detailed?
>
> My attempts to put ROM into an on-chip RAM of an
> Altera 10KE using VHDL Synthesis were not successful.
>
> The whole thing works in AHDL perfectly. You define the
> DP-ROM module and write the content into a HEX-file,
> which is nothing else than an Intel-Hex file derivate.
> The MaxPlus Synthesis does not touch the content, but
> the resulted Programming Device code will contain it.
> If you activate the VHDL Output Interface, you get
> a chip-level VHDL code that DOES contain the ROM code.
>
> For the VHDL Behavioral model I wrote a program,
> that reads the above HEX file and puts into
> the RAM array. This is in a Process that is
> started only once, after simulation start.
>
> Nothing worked for the VHDL synthesis, however.
> The HEX file read routine was (of course) unsynthesisable.
> When declaring simply the ROM without content
> I got an error message from the Synthesis Tool
> (Leonardo), that I wanted to create a RAM
> without Write Port.
>
> There is, of course, a way, that is described
> in the MaxPlus Help file: you can define
> the RAM content in the VHDL model as a
> VHDL Constant's in-line code. This might
> work for a small ROM, but not for a ROM
> that fills out the full memory area.
>
> Is there a possibility to describe a
> ROM with content gibven in an external file?
>
> Janos Ero

--
-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: 21893
Subject: JBits
From: Anshuman Sharma <gte600f@prism.gatech.edu>
Date: 6 Apr 2000 00:39:45 GMT
Links: << >>  << T >>  << A >>

does anyone know where I can get a copy of JBits?


-- 
---------------------------------------------------
"time and space are modes by which we think...... |
they are not the conditions in which we live."    |
                                                  |
   ~~Einstein                                     |       
---------------------------------------------------


Anshuman Sharma
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: gte600f@prism.gatech.edu
       anshu@abraxis.com

Article: 21894
Subject: Re: PCI Bridge to Xilinx XCV*E
From: krw@attglobal.net (Keith R. Williams)
Date: 6 Apr 2000 01:20:28 GMT
Links: << >>  << T >>  << A >>
On Wed, 5 Apr 2000 14:20:49, Utku Ozcan <ozcan@netas.com.tr> 
wrote:

> Can you recommend any bridge through which Motorola's
> 860 or 8240 processors can control XCV*E FPGAs? There
> will be many Virtex-E devices on the board, like 10.
> FPGA's CPU Interface will communicate to this Bridge.
> Or is there any better newsgroup to direct this q?

I'm using the PLX PCI9054.  It is a full PCI master and quite 
cheap (well compared to a Virtex-E).  I think the boss paid about
$30 for the BG256 part in small quantities. 

I don't know what you're trying to do (I'm also targeting a PPC 
chip, but not a Motorola part ;-), but the PCI9054 has a PPC860 
bus mode.  My processor is on the other side of the Virtex-E, so 
I'm not using the "M" mode.  Depending on your needs, PLX also 
has the IOP480, which has a PPC-503(I think) integrated in.  In 
any case, check out PLX at http://www.plxtech.com/.

I wouldn't bother using a PCI core on an expensive part like the 
Virtex-E.  I started down this road (not with Xilinx) and it was 
a huge mistake. 

----
  Keith
Article: 21895
Subject: Re: Memory cores
From: Janos Ero <Janos.Ero@cern.ch>
Date: Thu, 06 Apr 2000 08:53:46 +0200
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> You need to get the data into the VHDL one way or another.  
<snip>
> library ieee;
> use ieee.std_logic_1164.all;
> package parameters is
>     type TABLE_TYPE is array (NATURAL range <>) of integer;
>     constant EXP_LUT: TABLE_TYPE:= (
>   5918491, 5721208, 5523925, 5326641, 5129358, 4932075, 4734792, 4537509,  --  0:7

Hm, actually I wanted to avoid exactly this. 
This means I have to reformat all my LUTs
and they are numerous :-(

For me an ideal solution would be to open
"empty" ROMs and fill them at fitting, as
it happens when developing in the AHDL way.

Thanks for the hints.

Janos Ero

Article: 21896
Subject: Re: JTAG programming
From: "Jean-Paul GOGLIO" <goglio@getris.com>
Date: Thu, 6 Apr 2000 09:48:09 +0200
Links: << >>  << T >>  << A >>

rob_dickinson@my-deja.com wrote in message <8cferj$onc$1@nnrp1.deja.com>...

>I used to work with JTAG, with MACH4-128's and SHARC DSP's.  I'm sure
>that you have worked out the common thread by now.  If memory serves,
>the SHARCs don't quite meet the JTAG spec in terms of the JTAG id
>registers, the hardware implementation is correct.  We got around it
>because we had our own jtag program, I've no idea how to get the Xilinx
>tools to work around this.
>
>


You say that it was your own JTAG program. I don't believe that there is any
JTAG hardware problem with Xilinx or AD components. I just believe that
Xilinx software works with Xilinx products only and AD software with AD
products only.


J-P GOGLIO
GETRIS S.A.
13 Chemin des Prés
38240 Meylan
Tel : (33) 4 76 18 52 10
E-mail : goglio@getris.com
Fax : (33) 4 76 18 52 01



Article: 21897
Subject: hwdebugr vs. jtag
From: Joerg RiTTer <ritter@informatik.uni-halle.de>
Date: Thu, 06 Apr 2000 10:22:45 +0200
Links: << >>  << T >>  << A >>
SGksDQoNCkkndmUgc3VjY2Vzc2Z1bGx5IGRvd25sb2FkZWQgZGVzaWducyB0byBhIGZwZ2Et
ZGVtby1ib2FyZCB3aXRoIHRoZQ0KaGFyZHdhcmUtZGVidWdnZXItc29mdHdhcmUgYW5kIHRo
ZSB4Y2hlY2tlci1jYWJsZS4NCk5vdyBJIHdhcyBsb29raW5nIGZvciBhIGNvbW1hbmQgbGlu
ZSB2ZXJzaW9uLg0KSSd2ZSByZWFsaXplZCwgdGhhdCB0aGUganRhZ3Byb2cgY29tbWFuZCBs
aW5lIHRvb2wgY291bGQgYmUgYSBzb2x1dGlvbi4NCkRvd25sb2FkaW5nIHdpdGgganRhZyAv
IGp0YWdwcm9nIGZhaWxzIHdpdGggdGhlIGZvbGxvd2luZyBlcnJvciBtZXNzYWdlDQo6DQoN
CkpUQUcgUHJvZ3JhbW1lciBTdGFydGVkIDIwMDAvMDQvMDYgMTA6MjA6MzcNCiAgICBMb2Fk
aW5nIEJvdW5kYXJ5LVNjYW4gRGVzY3JpcHRpb24gTGFuZ3VhZ2UgKEJTREwpIGZpbGUNCidn
Oi9YaWxpbngveGM0MDAwZS9kYXRhL3hjNDAwNWVfcGM4NC5ic2QnLi4uLi5jb21wbGV0ZWQN
CnN1Y2Nlc3NmdWxseS4NCiAgICBDaGVja2luZyBib3VuZGFyeS1zY2FuIGNoYWluIGludGVn
cml0eS4uLkVSUk9SOkpUYWcgLSBCb3VuZGFyeS1zY2FuDQpjaGFpbiB0ZXN0IGZhaWxlZCBh
dCBiaXQgcG9zaXRpb24gJzEnIG9uIGluc3RhbmNlICdhZGRzdWIoRGV2aWNlMSknLg0KICAg
ICBDaGVjayB0aGF0IHRoZSBjYWJsZSwgc3lzdGVtIGFuZCBkZXZpY2UgSlRBRyBUQVAgY29u
bmVjdGlvbnMgYXJlDQpjb3JyZWN0LA0KICAgICB0aGF0IHRoZSB0YXJnZXQgc3lzdGVtIHBv
d2VyIHN1cHBseSBpcyBzZXQgdG8gdGhlIGNvcnJlY3QgbGV2ZWwsDQogICAgICB0aGF0IHRo
ZSBzeXN0ZW0gZ3JvdW5kcyBhcmUgY29ubmVjdGVkIGFuZCB0aGF0IHRoZSBwYXJ0cyBhcmUN
CnByb3Blcmx5IGRlY291cGxlZC4NCiAgICBFUlJPUjpKVGFnIC0gQm91bmRhcnkgc2NhbiBj
aGFpbiBoYXMgYmVlbiBpbXByb3Blcmx5IHNwZWNpZmllZC4NClBsZWFzZSBjaGVjayB5b3Vy
IGNvbmZpZ3VyYXRpb24gYW5kIHJlLWVudGVyIHRoZSAgICAgYm91bmRhcnktc2NhbiBjaGFp
bg0KaW5mb3JtYXRpb24uDQogICAgQm91bmRhcnktc2NhbiBjaGFpbiB2YWxpZGF0ZWQgdW5z
dWNjZXNzZnVsbHkuDQogICAgRVJST1I6SlRhZyAtIDogVGhlIGJvdW5kYXJ5LXNjYW4gY2hh
aW4gaGFzIG5vdCBiZWVuIGRlY2xhcmVkDQpjb3JyZWN0bHkuDQogICAgIFZlcmlmeSB0aGUg
c3ludGF4IGFuZCBjb3JyZWN0bmVzcyBvZiB0aGUgZGV2aWNlIEJTREwgZmlsZXMsIGNvcnJl
Y3QNCnRoZSBmaWxlcywNCiAgICAgcmVzZXQgdGhlIGNhYmxlIGFuZCByZXRyeSB0aGlzIGNv
bW1hbmQuDQoNCkkgd2FzIHVzaW5nIHRoZSBzYW1lIHhjaGVja2VyIGNhYmxlLCBmcGdhLWJv
YXJkIGFuZCB0aGUgZXhhY3RseSB0aGUgc2FtZQ0Kc3dpdGNoL2ZseWluZyBsZWFkcyBzZXR0
aW5ncy4NCkFueSBpZGVhcyA/DQpJcyB0aGVyZSBhIGNvbW1hbmQgbGluZSB2ZXJzaW9uIG9m
IHRoZSBoYXJkd2FyZSBkZWJ1Z2dlciA/DQoNClRoYW5rcw0KSvZyZw0K

Article: 21898
Subject: Spartan on chip oscillator
From: bjorn_lindegren@my-deja.com
Date: Thu, 06 Apr 2000 08:34:26 GMT
Links: << >>  << T >>  << A >>
Using Spartan XCS10-PC84, when I read the manual for this FPGA, I found
that the on chip oscillator falls between 10 Mhz and 4 Mhz.

I want to use this oscillator to determine a frequens, and I need a
constant oscillator. Is it possible to use this on chip oscillator in a
lower mode or do I have to use an extern oscillator.

In other words, is it possible to do the on chip oscillator temperatur
undependent?

Thankful for help

Björn Lindegren


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21899
Subject: Re: JTAG programming
From: rob_dickinson@my-deja.com
Date: Thu, 06 Apr 2000 09:00:39 GMT
Links: << >>  << T >>  << A >>
In article <8cheob$b6g$1@reader1.fr.uu.net>,
  "Jean-Paul GOGLIO" <goglio@getris.com> wrote:
>
> rob_dickinson@my-deja.com wrote in message
<8cferj$onc$1@nnrp1.deja.com>...
>
> >I used to work with JTAG, with MACH4-128's and SHARC DSP's.  I'm sure
> >that you have worked out the common thread by now.  If memory serves,
> >the SHARCs don't quite meet the JTAG spec in terms of the JTAG id
> >registers, the hardware implementation is correct.  We got around it
> >because we had our own jtag program, I've no idea how to get the
Xilinx
> >tools to work around this.
> >
> >
>
> You say that it was your own JTAG program. I don't believe that there
is any
> JTAG hardware problem with Xilinx or AD components. I just believe
that
> Xilinx software works with Xilinx products only and AD software with
AD
> products only.
>
> J-P GOGLIO
> GETRIS S.A.
> 13 Chemin des Prés
> 38240 Meylan
> Tel : (33) 4 76 18 52 10
> E-mail : goglio@getris.com
> Fax : (33) 4 76 18 52 01
>
I have to disagree completely with this.  The jtag spec was defined to
allow anything to be put on the chain by anyone.  A decent tool
(software) will find out how many devices are on the chain and their
manufacturers id and how "long" each device is.  Its fairly
straightforward to make a device on the chain transparent (via
software), allowing debuggers (for instance) to get to one device
without having to keep clocking data through an enormous shift register
(the other devices).  I am fairly certain that the AD debugger turns
off the other SHARCS in the chain to debug the SHARC of interest.

I  "watched" a software engineer doing boundary scan with tcl about 3
years ago and I simply remember a passing comment that AD had not quite
kept to the letter of the JTAG spec in terms of the id it returns. I
used the same JTAG path to just ISP the machs and the SHARCS ( and some
JTAG quickswitches etc) got "out of the way" just fine.

My original post said that the SHARC "hardware implementation is
correct" as the original guy was questioning his hardware.  I expect
that the XILINX jtag kit can't quite cope with the SHARC which has bent
the JTAG rules, allthough MACHPRO (the mach JTAG ISP software) could.

Rob


Sent via Deja.com http://www.deja.com/
Before you buy.


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