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

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

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

Custom Search

Messages from 27200

Article: 27200
Subject: Re: Job posting info
From: husby@my-deja.com
Date: Wed, 15 Nov 2000 04:27:57 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: CRC, LFSR and scramblers
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 14 Nov 2000 23:41:17 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 27202
Subject: test test just test
From: xiao_john@excite.com (frank johson)
Date: 15 Nov 2000 06:49:11 +0100
Links: << >>  << T >>  << A >>
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.ORG

Article: 27203
Subject: Re: Clear AND Preset Pins
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Wed, 15 Nov 2000 06:13:31 GMT
Links: << >>  << T >>  << A >>
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.com

Article: 27204
Subject: BUFT conflict with LOC
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Wed, 15 Nov 2000 09:24:26 +0200
Links: << >>  << T >>  << A >>

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.

Utku




Article: 27205
Subject: Re: BUFT conflict with LOC
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Wed, 15 Nov 2000 10:41:00 +0200
Links: << >>  << T >>  << A >>

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?

Utku

Article: 27206
Subject: Re: Webpack 3.2WP3.x from Xilinx is useless
From: Nicolas Matringe <nicolas.matringe@IPricot.com>
Date: Wed, 15 Nov 2000 10:11:12 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: Des warning matter?
From: Michael Strothjohann <strothjohann@rheinahrcampus.de>
Date: Wed, 15 Nov 2000 09:46:21 +0000
Links: << >>  << T >>  << A >>
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: 27208
Subject: Re: Leonardo for Altera
From: cadmanager@my-deja.com
Date: Wed, 15 Nov 2000 10:17:50 GMT
Links: << >>  << T >>  << A >>



 Hi,

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
Subject: Problem with Endianess in Xilinx Tools.
From: "Richard Rooney" <richardrooney@hotmail.com>
Date: Wed, 15 Nov 2000 11:57:52 -0000
Links: << >>  << T >>  << A >>
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




Article: 27210
Subject: .mif and .coe files in coregen vs. green mountain 68hc11
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Wed, 15 Nov 2000 11:28:53 -0500
Links: << >>  << T >>  << A >>
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. Hicks


Article: 27211
Subject: Re: CRC, LFSR and scramblers
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 15 Nov 2000 09:20:47 -0800
Links: << >>  << T >>  << A >>


"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 Alfke


Article: 27212
Subject: Re: Job posting info
From: "Jan Gray" <jsgray@acm.org>
Date: Wed, 15 Nov 2000 17:57:19 GMT
Links: << >>  << T >>  << A >>
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 LLC




Article: 27213
Subject: Re: BUFT conflict with LOC
From: Tom Branca <thomas.branca@xilinx.com>
Date: Wed, 15 Nov 2000 10:32:47 -0800
Links: << >>  << T >>  << A >>
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: 27214
Subject: jobs for FPGA designer (remote)
From: "Ron Proveniers" <ron@proveniers.myweb.nl>
Date: Wed, 15 Nov 2000 20:29:28 +0100
Links: << >>  << T >>  << A >>
Hi 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.nl







Article: 27215
Subject: Re: jobs for FPGA designer (remote)
From: Jamie Lokier <spamfilter.nov2000@tantalophile.demon.co.uk>
Date: 15 Nov 2000 20:36:11 +0100
Links: << >>  << T >>  << A >>
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 :-)

-- Jamie

Article: 27216
Subject: Re: Job posting info
From: murray@pa.dec.com (Hal Murray)
Date: 15 Nov 2000 20:33:45 GMT
Links: << >>  << T >>  << A >>

> 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
Subject: Schematics & VHDL
From: V Ram <ipickledthefigsmyeslf@mrbourns.com>
Date: Wed, 15 Nov 2000 21:41:34 +0000 (UTC)
Links: << >>  << T >>  << A >>
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
Subject: ANNOUNCE: Checksum and CRC Code/Article
From: Michael Barr <mbarr@netrino.com>
Date: Wed, 15 Nov 2000 21:51:46 GMT
Links: << >>  << T >>  << A >>
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: 27219
Subject: Re: BUFT conflict with LOC
From: Tim Jaynes <tim.jaynes@xilinx.com>
Date: Wed, 15 Nov 2000 14:49:42 -0800
Links: << >>  << T >>  << A >>
The 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.
Tim


Article: 27220
Subject: Re: .mif and .coe files in coregen vs. green mountain 68hc11
From: Vikram Pasham <Vikram.Pasham@xilinx.com>
Date: Wed, 15 Nov 2000 14:58:17 -0800
Links: << >>  << T >>  << A >>
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. Hicks


Article: 27221
Subject: FPGA Pin Nunber
From: "Qian Zhang" <qianz@cae.wisc.edu>
Date: Wed, 15 Nov 2000 17:46:01 -0600
Links: << >>  << T >>  << A >>
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: 27222
Subject: Re: ViewLogic ViewDraw questions
From: "napier_surf" <napier_surf@yahoo.com>
Date: Thu, 16 Nov 2000 00:04:29 -0000
Links: << >>  << T >>  << A >>
take 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
Subject: Re: Problem with Endianess in Xilinx Tools.
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Wed, 15 Nov 2000 18:50:29 -0700
Links: << >>  << T >>  << A >>
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
Subject: Xilinx Foundation Sudent Version 1.5
From: "djley" <djley@email.msn.com>
Date: Wed, 15 Nov 2000 18:23:08 -0800
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search