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
Mark Mahoney <markmahoney1@mediaone.net> wrote: > Can anybody suggest a mailing list or news group where I can post a > job opportunity(other than the usual-Monster, ne.jobs, etc. I have > done that) I have for a FPGA designer in the Boston Ma. area? > I don't want to insult the integrity of this group by posting > the details here. There are varying opinions as to whether job postings are appropriate here or not. I don't think you'll insult our integrity too much (assuming we have any to start with) if you post a well written job description for an FPGA-related job. My preference would be to limit this to "exceptional" jobs since anyone who is really looking for a job would probably check all of the obvious places. Also, I have a bias against headhunters since I view them as middlemen who don't offer much service for what they get paid. I'd be much more likely to look at a job if I can look at the company website, find out what kind of products they make, and where they fit in the market. By neccesity, a headhunter has to keep all of that secret until you contact him. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27201
I am not able to post from work. I see my postings from the office, but I can't see them from home. I assume that no one else sees them either. So here is my post from Monday again... Yes, this occurred to me over the weekend too. But I see it a little differently. First, I don't think the result and the feedback are distinct calculations. There are three forms for the logic in the shift register and in each case the data in the shift register and the output data are directly related. Secondly, I think it would be simpler to push the feedback portion to the end of the calculation. The equations all have the form of (where the $ indicates summation) : n-1 m-1 $ cx(i)*x(i) + $ cn(i)*n(i) i=0 i=0 cx is the set of coefficients for the feedback and cn is the set of coefficients for the inputs. The summation is done modulo 2. So the result is always the exclusive OR of a set of inputs and feedback terms. It is very simple to separate the inputs from the feedback terms. The inputs can be XOR'd with each other in as many pipeline stages as needed. This intermediate result can then be fed to the final stage which will incorporate the feedback terms in one cycle producing the result for the next calculation and the output. I have written a program to calculate the coefficients for one of the three forms in the general case of up to 32 bit data busses and 32 feedback terms. I will be working on the other two forms next. Scott Hauck wrote: > > I haven't looked at the details of CRC to know how feasible this is, but > here's an approach you can try: > > You are trying to compute functions > > result(i) = F1(input(i), feedback(i-1)) > > feedback(i) = F2(input(i), feedback(i-1)) > > The feedback is your main concern, since obviously we can pipeline or delay > the result computation. So we focus on F2. Let's hope that F2 is somewhat > restructurable (if it was associative that would be wonderful, but in general > it may be somewhat refactorable). Restructure it so that as much work on the > input(i) is grouped together. You'll have something like: > > feedback(i) = F3(F4(input(i)), feedback(i-1)) > > Hopefully F4 will reduce the number of input(i) bits needed by F3 from the > full 32 to some smaller subset. Now, put a pipeline stage on the output of F4 > (in fact, you can pipeline F4 arbitrarily, but we'll assume only one delay > here). This means that although feedback(i) is computed one cycle later than > you expected, it is needed one cycle later in the computation. Also, since > result(i) can be arbitrarily delayed, it doesn't worry about the delay. > > Hope this helps, > > Scott -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 27202
no reply necessary _______________________________________________________ Tired of slow Internet? Get @Home Broadband Internet http://www.home.com/xinbox/signup.html -- Posted from kuku-rwcmta.excite.com [198.3.99.63] via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 27203
You can use synchronous reset to load initial values to counters. You can get sync reset by using the reset signal just as a load condition in your counter logic. But you have to synchronize reset signal so that it won't cause any metastability issues when you use it as a sync input. On Tue, 14 Nov 2000 20:14:20 -0600, "Qian Zhang" <qianz@cae.wisc.edu> wrote: >but if I wanna to setup an initial value >what can I do? >For example I have a counter while the counter starts not from 0 >but from 11 what can I do? >Thank you very much! Muzaffer http://www.dspia.comArticle: 27204
Design Entry: VHDL Synthesis: Synplify v6.0.0 P&R: Xilinx Alliance M2.1i SP6 Technology: Xilinx Virtex XCV1600E-8-BG560 I have looked at former postings but haven't found any related, therefore I'm asking you. I meet some error when I try to floorplan the chip with LOC= attribute in UCF, for example: INST "top/transmit/block/*" LOC=CLB_R1C22:CLB_R20C59; The error is as follows: map -p xcv1600e-8-bg560 -o map.ncd -c 100 dakota.ngd dakota.pcf map: version C.22 Copyright (c) 1995-1999 Xilinx, Inc. All rights reserved. Using target part 'v1600ebg560-8'. Reading NGD file "dakota.ngd"... Processing FMAPs... Removing unused or disabled logic... Running cover... Writing file map.ngm... Running directed packing... ERROR:xvkpu:52 - Could not pack the TBUF Chan_B/trm/stg/sts_group_ram_1.out_reg_tb_1[3]. The symbol has a constraint (LOC=CLB_R36C48:CLB_R63C108) that specifies an illegal physical site for the component. Please correct the constraint value. Problem encountered during the packing phase. Design Summary -------------- Number of errors : 1 Number of warnings : 67 That means, LOC= for CLB conflict with TBUF. The errors are related to the tri-state buffers which have been generated by Synplify. The tri-state buffers generated are primarily used for RAM. RAMs have been modelled in VHDL behavioral description. The RAM interfering method Synplify recommended has been used. This problem also arises when we use the same thing for XC40150XV devices with M1.5 tools. UtkuArticle: 27205
Oops, I have forgotten my question. How can I floorplan a unit which contains TBUF? Is it the only way that I convert the tristate buffers into muxes so that TBUFs do not conflict with LOC=CLB_... properties in UCF? UtkuArticle: 27206
Rick Filipkiewicz wrote: > ... or, alternatively, dump the GUI & run ngdbuild from the > command line ? If only it worked... At least here, it keeps complaining about a missing dll (not Xilinx's Delay Locked Loop, MS's Dynamic Link Library) -- Nicolas MATRINGE IPricot European Headquarters Conception electronique 10-12 Avenue de Verdun Tel +33 1 46 52 53 00 F-92250 LA GARENNE-COLOMBES - FRANCE Fax +33 1 46 52 53 01 http://www.IPricot.com/Article: 27207
Hi,
it depends on you.
Your VHDL-code is interpreted by the synthesis-tool.
This tool is (probably) abel to warn you, if it suggests a
missinterpretion or it could not check your design
(e.g. some components are seen as black box by
the syntehsis-tool).
It may also warn you in the later PAR-state.
( intern bus-driving: not enough, etc. ). All warnings
generated by the tools require a knowlage of
the underling processes. I'm sorry, the classification of the
warnings
( importand , .. , don't care) have to be done by the user.
Take the generated warnings as 'hints'.
by
michael
Qian Zhang schrieb:
> Hi There
> the Xilinx Foundation 3.li tells me that the synthesis sucessfully
> implemented
> but there are a lot of warning, does it matter?
>
> Thank you very much!
>
> Qian
Article: 27208Hi, To use the best methodology between Leonardo Spectrum and MAXPLUS2 or QUARTUS or any other Place & Route tools you have to : 1st : synthesize your VHDL or Verilog code, in a separate directory, whith leonardo, and don't forget to uncheck the automatic generation of ACF file. It is not usable. 2nd: copy the edif output file from leonardo to a different directory where you use MAXPLUS2 or QUARTUS or anyone else. launch MAXPLUS2, it create a goof ACF file for the first time. then you have now and Forever, a ACF file that you can modify to fix pinout. 3rd: modify the ACF file in the Place&route directory, an then re- launch the tool. That's all. A other methodology is to copy a existing ACF file from a other design, modifying the content, and launch MAXPLUS2 Best Regards In article <8ur6lf$nk3$1@nnrp1.deja.com>, flavioas@my-deja.com wrote: > > > Hi, > > Thank you all for your answers. As i could see, the best thing to > do is before launching Leonardo, starts maxplus2 to set .ACF correctly. > I heard from Mentor that there were a bug in Leonardo level 1, for > Altera. > > Bye, > > Flávio > > Sent via Deja.com http://www.deja.com/ > Before you buy. > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27209
I I have a lot of busses declared, unconventionally, as std_logic_vector(1 to 64), etc. These pass through Leonardo Spectrum O.K., but the o/p EDIF(2.0 ?) does not indicate to downstream tools which bit is the MSB,etc. This then causes me problems with the simulation VHDL netlists (time_sim.vhd) written out by Xilinx Design Manager - the busses in this netlist are reversed as it assumes that bit 64 is MSB, etc. Any ideas on how to solve this - without re-writing 1000's of lines if code ? richardrooney@hotmail.comArticle: 27210
How can I _easily_ create a ROM with preset data in it? I am trying to use the Green Mountain HC11 core as part of a grad school class project. I would like to use a Xilinx FPGA (probably a Vertex device) to demonstrate actual hardware as weel as to demonstrate a simulation of the actual device. Thus it would be nice to have a "real" ROM instantiated in the Virtex device with "real" instructions at the right locations in the ROM. For example I am using a 256 by 8 ROM to demonstrate the HC11 device. While the Green Mountain core implements a very nice user friendly ROM it does not synthesize very well (if at all). I have not actually tried it out but the prefered way to generate a ROM is to use COREGEN as COREGEN uses the available RAM primitives as ROM with preset values set. Is there a simple way to define these preset values, preferably without re synthesizing and re-implementing the whole device? Thanks, Theron J. HicksArticle: 27211
"John L. Smith" wrote: > The algorithm above only needs a 256 deep x 32 wide table. > That's a mere 1 BlockRAM, using 256 x 16 x Dualport. I don't think so. Virtex BlockRAM store only 4 Kb each, although you have parallel and independent access from two ports. So you have effectively two 256x16 identical LUTs with independent addressing. Take it from there... > > Unfortunately, the need for a clocked read out of the > BlockRAMs means this takes two cycles (Peter, here is > another case where the clocked read is a nuisance! Is > there really no way to design these things with flow-thru > address->data? ). No, there is not. It would require a totally different, bigger and probably slower read access structure. Peter AlfkeArticle: 27212
One ad begets another, and sometimes two. "If everybody else is doing it, why don't we?" type thinking. If a small fraction of the thousands of (headhunters, employers, peers) who have FPGA positions to fill posted FPGA-content-free ads here they could easily drown out the technical discussion. (On the other hand, on-topic technical job ad postings (prepared by a member of technical staff) might be good -- something where the content outweighs the "ad" by 5:1 or so -- "Here at XYZ Diagnostic Systems, we are now shipping our latest ZZZ product. Apropos to comp.arch.fpga, it uses 12 XiTera-300E's to match mumble templates at mumble megapixels per second. One of the tricky problems we had to overcome was blat, and we devised a foo to do that. We found foo's map particularly well to the mumble feature of the devices. The design is 12,000 lines of VeriHDL. Here's how we tested it: ... . For tools, we used WizardSynth and MumbleSim. We switched from BogoSynth because it didn't smurf. The project took three engineers five months. ... Oh yes, almost forgot -- we're hiring FPGA designers. If you'd like to join us to design more great widgets, see www.xyz-diag-sys.com/jobs." -- but this won't happen out of trade secret and recruiter disintermediation concerns.) I think there needs to be an outlet for these job ads. Can we find a way to welcome all comers into the big tent, find a way to freely exchange technical-content-free job ads, but which never distracts us from the good stuff? Something that scales up over the years, as FPGAs become mainstream and FPGA jobs ultimately equate to "digital design jobs"? Here are some ideas. 1. standard job ad tag in subject -- no good, still incurs too many new subject lines each day, obscuring the technical discourse 2. create alt.jobs.fpga -- good so long as the ads are not cross-posted to comp.arch.fpga -- but most techies won't subscribe so recruiters won't reach their audience -- no good. 3. create fpga-jobs@egroups.com -- again, no good for recruiters, they won't reach the desired audience. 4. create a regularly posted "available jobs digest". Mail your ad to the fpga-jobs-digest-submit alias and it will run in comp.arch.fpga within two weeks. Over in comp.compilers, the moderator, John Levine, collects job ads into a digest and posts that once a month or so. It works very well. Easy to read if you're interested, easy to ignore if you're not interested. Disruption kept to the barest whisper. That would be more like it. All we need is a digest admin volunteer... Jan Gray, Gray Research LLCArticle: 27213
Hello Utku,
I think I would use the area group constraints in this situation,
rather than the LOC range constraints. Area groups allow you to define
groups of logic by assigning logical instance to a specific area group,
then you can assign this area group to a specific range in the device.
There is more flexibility with area groups because you can specify the
type of resource that you want constrained to the area via the RANGE
constraint. I have included some syntax and usage information for the
area group constraint below.
Cheers,
Tom
----------------------------------------------------------------------------------------
The area group constraint when used in the UCF or NCF has the following
syntax.
INST <logical_block> AREA_GROUP = <group_name> ;
<logical_block> - Name of logical block assigned to group <group_name>.
If the AREA_GROUP constraint is attached to a hierarchical block, all
the children in the block are assigned to the group.
<group_name> - This is the name of the area group and is used to
uniquely define a group.
In addition to the INST command, AREA_GROUP can be used as a separate
command to define a range and compression factor for an area group as
follows:
AREA_GROUP <group_name> RANGE=<range>;
AREA_GROUP <group_name> COMPRESSION=<percent>;
<range> - Defines the physical area for <group_name> using RLOC_RANGE
syntax. The site names for Virtex and VirtexII are as follows:
CLB/Slice Constraint: CLB_RnCm
Block RAM: RAMB4_RnCm
TBUF: TBUF_RnCm
The constraint will only apply the range to a logical block if it of the
appropriate type (e.g. LUTs and FLOPs get CLB range and TBUFs get TBUF
range).
<percent> - Defines the compression factor for <group_name>. This is
equivalent to -c option in map but operates on the group instead of the
whole design. The mapper computes the available resources in the group
from the <range> and attempts to compress the logic to the percentage
specified. The percent values can be from 0 to 100. If the group does
not have a RANGE, only 0 (no compression) and 1 (maximum compression)
are meaningful.
Compression does not apply to TBUFs or block RAMs.
<group_name> - Name of area group. The mapper will generate an error
if an RANGE or COMPRESSION command is specified and there is not a
corresponding area group <group_name> defined in an INST command.
Article: 27214Hi There I see al these nice job opportunities the US. Are there any possibilities for remote work???. I am a senior design engineer and have some spare time. have the following job experience: -Xilinx FPGA (spartan2) development ATM linecards DS3/ATM25/ATM45/ethernet/live-video in VHDL -Altera FPGA (virtex/10KE100) development DECT burst mode logic controller in VHDL -Xilinx FPGA development of UART/PWM/ 1/4 VGA LCD controllers EDA tools Altera max++/ RENOIR/ LEONARDO / FPGA EXPRESS/ MODELSIM/ Xilinx FOUNDATION etc. and of course the usual stuff of assembler/C/C++ /RTOS etc. for embedded. over 30 year of experience in electronics ( do like the old EL34 tubes and Westectors)... Living in the netherlands (sorry). pls. let me know if somebody(one) has an interrest. email:ron@proveniers.myweb.nlArticle: 27215
Ron Proveniers writes: > I see al these nice job opportunities the US. Are there any possibilities > for remote work???. A clearing house that offers short term remote contracts would be great. Wouldn't mind doing a few extra FPGAs on the side :-) -- JamieArticle: 27216
> I think there needs to be an outlet for these job ads. Can we find a way to > welcome all comers into the big tent, find a way to freely exchange > technical-content-free job ads, but which never distracts us from the good > stuff? Something that scales up over the years, as FPGAs become mainstream > and FPGA jobs ultimately equate to "digital design jobs"? Here are some > ideas. I'd be a lot happier if there were no job ads in comp.arch.fpga (or any of the other newsgroups I read). The standard way to advertize on usenet is to put a line or two in the signature at the end of your msg. Only a line or two with email, phone, or URL, not a big ad. I see no reason why this isn't appropriate for jobs as well as other forms of advertising. -- These are my opinions, not necessarily my employers. I hate spam.Article: 27217
I have a quick question... What third-party tools offer "good" schematic entry combined with the ability to graphically hook up VHDL blocks? I have MaxPlusII which allows this, but I'm using some outside tools for the VHDL synthesis and didn't know if better third-party schematic entry tools existed. As far as I know, things like Renoir & Active HDL are only meant for "block" diagrams and VHDL entry, not providing the ability to tack down a DFF and some combinational logic, etc. I know Aldec has such a program and I think that's what is bundled with the Xilinx Foundation tools and I wasn't too impressed. Any others? Anyone use ViewDraw? Thanks! Vasant.Article: 27218
This is a cryptographically signed message in MIME format.
--------------ms4B962FB2094CDF47ED9278AE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've just (finally) gotten around to posting a three-part article I
wrote about a year ago on computing checksums and CRCs and the source
code that goes with it. The URLs of the three articles are:
http://www.netrino.com/Connecting/1999-11/
http://www.netrino.com/Connecting/1999-12/
http://www.netrino.com/Connecting/2000-01/
If you're new to the subject, I recommend reading them in order. If,
however, you are familiar with the theory of checksums and CRCs and just
want to get directly into the CRC implementation, you can just read the
third.
A ZIP file containing just the source code for the CRC routines is at:
http://www.netrino.com/Connecting/2000-01/crc.zip
The code is placed into the public domain and may be used for any purpose
public or private. There are some limitations in its use (it's written
in C), but the underlying algorithms are solid and could be ported to the
assembly language (or hardware) of your choice if necessary.
Enjoy,
Michael Barr
--------------ms4B962FB2094CDF47ED9278AE
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIDwYJKoZIhvcNAQcCoIIIADCCB/wCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeAwggLEMIICLaADAgECAgMDEAswDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU
aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h
bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgxMTE0MDgyMVoXDTAxMDgxMTE0MDgy
MVowaDENMAsGA1UEBBMEQmFycjEXMBUGA1UEKhMOTWljaGFlbCBKb3NlcGgxHDAaBgNVBAMT
E01pY2hhZWwgSm9zZXBoIEJhcnIxIDAeBgkqhkiG9w0BCQEWEW1iYXJyQG5ldHJpbm8uY29t
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPW0HFztiNxFaw5uv5erG4nAS1Ed69/f73
4PuydSX/IYhUMiZXoqqdKgToW+wexUC/aHqpdsYJZCYOQj1jK8P3dtuKPZge4IiHqJCjCbbs
CUpGrITYMNXAnarD97g4ZiUUo6ts7PkUsqAvB683RpUr0tjJtjWBQt5ybjs23Tww1QIDAQAB
o08wTTAcBgNVHREEFTATgRFtYmFyckBuZXRyaW5vLmNvbTAMBgNVHRMBAf8EAjAAMB8GA1Ud
IwQYMBaAFIir8WCDZlX05FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GBAF0IhPhr9QMF
hZaDH8O20cd9kiYLoXuRzpg3HWde9Gw75l1k3j9Ke1gM7dx8YQi0xRiRkxq/F+1z5oysoc+/
GsQ0iUqrXcP4xUWeGTBwsPI1+S4axmn8wb4hhjQuBMjIAnOa9uTV5TIlBIdTZ8ws+Fg3zPgY
xzbGAhS75FSL3l4DMIIDFDCCAn2gAwIBAgIBCzANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UE
BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD
VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl
cyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ
KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk5MDkxNjE0MDE0
MFoXDTAxMDkxNTE0MDE0MFowgZQxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh
cGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENl
cnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMTk5
OS45LjE2MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzaVqX1NAWC3q1xV3pIZwjcs0S
TEv3fs/H+8pyJPRCUqxXleN7YXoXhOf9cjk4lLTq7WWnkgZeveBl9hm7lHl2TD65aHB1hBz0
EXQAvAUsTwkDFzHM9EHUcsamXeKIRLCLLsRN8fDWhT5s85WUeJF+QOmc0Y0VV47Cc+Uw3kb1
TwIDAQABozcwNTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFHJJwnM0xlX0C3Zy
gX539IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBAGvGWekx+um27LED2N9ycv6RYEjqxlXde/Bn
jsZhcOdtwqU32J23FyhWBYvdXHVvxpGQxmxmcRPQEHxrkW+G4CE2LcHX6rIJrc8tbcaDUpv7
u/6ch538t+l0kuRcl678fqzKDW9yemcsa3P1hvmd9QBu9B0Hzp2egmMp75MJflXeMYIB9zCC
AfMCAQEwgZwwgZQxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNV
BAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl
IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2AgMD
EAswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0wMDExMTUyMTUxNDRaMCMGCSqGSIb3DQEJBDEWBBQrnmIvisR2KMJuah6dGW45kjzu
ZDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC
BzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgG3eHy7n
YK94V3LgxvAGp2nbEtAJrDL9kdkNngqDYSdXMCBh9K17scmdsCaEz4383L60HMX9B4wIf6Q/
kDZOLqGLz/bgPwKk+mGhklrJcHfM+LZPxNfC0DidBOYp2xWxNtxCCWRLsN344wZhQAeDS4zy
pH7rxJrix6E2Rxf6HOVG
--------------ms4B962FB2094CDF47ED9278AE--
Article: 27219The problem essentially boils down to the fact that you've used: > > CLB/Slice Constraint: CLB_RnCm > But should have used: > TBUF: TBUF_RnCm > a LOC is fine, you just need to use the right element group. TimArticle: 27220
Theron, You can generate RAM/ROM components with initialized values in Xilinx Coregen. Specify the RAM/ROM initial values in the .coe file and Coregen will generate a .mif file. The .mif file is only used for functional simulation while the values in .coe file are written into the netlist file generated by Coregen. The only way to change these initial values is by re-generating the core with a new .coe file. You must re-implement the design whenever the initial values are changed. Hope this helps !!! Vikram Xilinx Applications Theron Hicks wrote: > How can I _easily_ create a ROM with preset data in it? I am trying to > use the Green Mountain HC11 core as part of a grad school class > project. I would like to use a Xilinx FPGA (probably a Vertex device) > to demonstrate actual hardware as weel as to demonstrate a simulation of > the actual device. Thus it would be nice to have a "real" ROM > instantiated in the Virtex device with "real" instructions at the right > locations in the ROM. For example I am using a 256 by 8 ROM to > demonstrate the HC11 device. While the Green Mountain core implements a > very nice user friendly ROM it does not synthesize very well (if at > all). I have not actually tried it out but the prefered way to generate > a ROM is to use COREGEN as COREGEN uses the available RAM primitives as > ROM with preset values set. Is there a simple way to define these > preset values, preferably without re synthesizing and re-implementing > the whole device? > > Thanks, > Theron J. HicksArticle: 27221
now I plan to setup my Spartan S40PQ240 pins,
but check syntax says:
"pinnum not declared "
can anyone tell me how to define the FPGA pins
to the corresponding input and output?
Thank you very much!
Here is my program
--LIBRARY ieee;
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use ieee.STD_LOGIC_arith.all;
ENTITY PWM5 IS
generic( WIDTH: INTEGER :=23);
T(
SWITCHING_F: in STD_LOGIC_VECTOR(WIDTH downto 0);
DUTYRATIO : in STD_LOGIC_VECTOR(WIDTH downto 0);
DEADTIME: in STD_LOGIC_VECTOR(WIDTH downto 0);
SAMPLING_F: in STD_LOGIC_VECTOR(WIDTH downto 0);
SAMPLING_I: in STD_LOGIC_VECTOR(WIDTH downto 0);
PHASE: in STD_LOGIC_VECTOR(WIDTH downto 0)
;
MINDEADTIME: in STD_LOGIC_VECTOR(WIDTH downto 0); -- MI
NDEADTIME CAN ONLY BE GIVEN AT RESET TIME
CONTROL: in STD_LOGIC;
CLK: in STD_LOGIC;
RESET: in STD_LOGIC;
WAVE1: out STD_LOGIC;
WAVE2: out STD_LOGIC;
CONV_START: out STD_LOGIC
);
attribute pinnum of WAVE1:signal is "P13";
END PWM5;
Article: 27222take a 32 bit buffer, On the output connect bus c[31:0], on the the input add a bus and name it as a[31:16],b[15:0] you need the ',' and if it's in a componet, add two busses a[31:0] b[31:] which are not connect to nything( else save ans check / sim won't work). I do this all the time with no problems. Tobin Fricke <tobin@pulsar.CS.Berkeley.EDU> wrote in message news:Pine.SOL.4.20.0011051941340.17939-100000@pulsar.CS.Berkeley.EDU... > > What is the proper way to do these things in ViewLogic's ViewDraw? > > o Merge multiple buses. Eg, say that I have A[31:0] and B[31:0]. > I'd like to form C[31:0] from A[31:16] concatenated with B[15:0]. > Is there an elegant way of doing this without making a VHDL block? > > o Set a bus to a constant value. Say I want F[31:0] to be set to > the constant value 0xDEADBEEF. How is this done in the schematic > editor without resorting to a VHDL block? > > Thanks, > Tobin > >Article: 27223
This is a multi-part message in MIME format. --------------B380E7ECE27A2309A01276B2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My suggestion is when you create the timing simulation netlist, invoke ngd2vhd with the -a switch. This will generate an architecture only and not the enitity declaration. Re-use the entity from your top-level RTL code and the two should hopefully link with the proper bus-notation without testbench modifications. You may want to write a simple configuration to link the two to ensure you are pointing at the correct architecture. I have successfully done this in the past and hopefully it will work for you. Note: This is also a good trick for designs which have top-level entities with generics, non std_logic type ports, "buffer" type ports, and/or unconnected ports that get removed by the place and route tools. Also works well for those who choose to do a positional type of port mapping for the design instantiation in the testbench although I still suggest connecting via implicit naming association just to be safe. -- Brian Richard Rooney wrote: > I I have a lot of busses declared, unconventionally, as std_logic_vector(1 > to 64), etc. > These pass through Leonardo Spectrum O.K., but the o/p EDIF(2.0 ?) does not > indicate to downstream tools which bit is the MSB,etc. > This then causes me problems with the simulation VHDL netlists > (time_sim.vhd) written out by Xilinx Design Manager - > the busses in this netlist are reversed as it assumes that bit 64 is MSB, > etc. > > Any ideas on how to solve this - without re-writing 1000's of lines if code > ? > > richardrooney@hotmail.com --------------B380E7ECE27A2309A01276B2 Content-Type: text/x-vcard; charset=us-ascii; name="brian.philofsky.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Philofsky Content-Disposition: attachment; filename="brian.philofsky.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:;;2300 55th Street;Boulder;CO;80301;USA version:2.1 email;internet:brianp@xilinx.com title:Sr. Technical Marketing Engineer fn:Brian Philofsky end:vcard --------------B380E7ECE27A2309A01276B2--Article: 27224
Would some one be interested in answering questions on this software. I'm not a student but would like to learn and there is no support for this product by Xilinx.
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