Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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/~randrakaArticle: 21876
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/~randrakaArticle: 21877
"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.plArticle: 21878
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
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: 21880In 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
...
>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: 21882Can 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
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
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: 21885I'm looking for checksum implementation in VHDL (or at least the basic rules to build one). Regards RonArticle: 21886
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 EroArticle: 21887
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
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/~randrakaArticle: 21889
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 ram = in beta.edn=20 is initialize 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> </DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Steve</FONT></DIV> <DIV> </DIV> <DIV> </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" <<A = href=3D"mailto:sc@vcc.com">sc@vcc.com</A>>=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 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 to fix = something so=20 trivial. </FONT></FONT></P> <P><FONT face=3DArial></FONT> </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
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
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
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
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: 21894On 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. ---- KeithArticle: 21895
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 EroArticle: 21896
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 01Article: 21897
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/DQoNClRoYW5rcw0KSvZyZw0KArticle: 21898
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
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:
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