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 28450

Article: 28450
Subject: Re: Alliance for Linux
From: shiva@well.com (Kenneth Porter)
Date: Fri, 12 Jan 2001 22:56:17 -0000
Links: << >>  << T >>  << A >>
bjrosen <bjrosen@polybus.com> wrote in <93m3nr$j82$1@nnrp1.deja.com>:

>The Redhat Package Manager makes sure that this doesn't happen on Linux.
>When you do an install it checks all of the dependencies and tells you
>what applications you are going to break.

This assumes the app uses a packaging system. Some developers avoid 
packaging systems to remain less tied to a distribution. In many cases 
RPM's are provided by 3rd party packagers or a distribution vendor, not the 
original source of the tarball.

>On Windows every installer assumes that it's free to replace anything it
>wants.

But that's a matter of convention, not something enforced either on Linux 
or Windows. Package managers can help, but they're not a panacea. A vendor 
can either supply only tarballs, or supply packages that are just as broken 
as Windows installers. (I regularly help newbie packagers of packages I'm 
interested in to fix their packages. A common error is to forget %config 
attributes in the %files list, which clobbers one's customized config files 
when upgrading with the next version's stock config files.)

>Also on Linux you can use different libraries for every app if you want,
>thats what the LD_LIBRARY_PATH env variable is for.

In Windows, an app can put all its DLL's in the app directory. Why doesn't 
this happen? Why do so many apps insist on dropping their stuff in the 
system directory?


Article: 28451
Subject: Virtex counter speed
From: Lawrence Peregrim <lperegrim@nospam.ksa1.com>
Date: Fri, 12 Jan 2001 23:01:41 GMT
Links: << >>  << T >>  << A >>
What's the fastest binary up-counter speed that can be wrung from a
speed grade 6 Virtex?  I need to emulate a few ASIC counters (one 16
bit and one 32 bit) that are presently implemented with simple chained
toggle flops.  These counters have async. clear only, no load/preset.
Before getting to the post P&R sims and after looking at Xilinx literature,
it looks like I should expect around 100 MHz.  I'm looking to use the
secondary interconnect lines.

TIA
Lawrence

Article: 28452
Subject: Re: CRC - from long division to XOR, how?
From: Duane <junkmail@junkmail.com>
Date: Fri, 12 Jan 2001 16:18:34 -0800
Links: << >>  << T >>  << A >>
Jamie Sanderson wrote:
> 
> I guess what I thought was a clear question really wasn't, since I've had a
> number of responses which didn't address the issue. (not that I don't
> appreciate the effort)
> 
> I think it would be illuminating if I posted an example of Jan's code. To
> keep it short, I used the polynomial from E1, which is a CRC-4 with a
> generating polynomial of x^4 + x + 1, calculated over a byte.
> 
> Looking at the code below, you'll find that it contains a set of four XOR
> statements which compute successive values of the CRC. What I don't
> understand is how these statements were generated. Clearly there is an
> algorithm for doing this since Jan's tool obviously makes use of one. I'd
> like to know what that is (assuming it's not proprietary).

I don't know of resources on the web with this info (though they may
well exist). The book that I found best explained going from the
polynomial to XOR gates is Lin and Costello's Error Control Coding. Kind
of old (1983) but still relevant.

--
My real email is akamail.com@dclark (or something like that).

Article: 28453
Subject: Re: Virtex counter speed
From: Ray Andraka <ray@andraka.com>
Date: Sat, 13 Jan 2001 01:08:49 GMT
Links: << >>  << T >>  << A >>
Depends!  (gotta love that answer)

If you can live with a ripple counter, for example, the speeds can be more than
500MHz.  But then you have to deal with non-synchronous outputs.  For
synchronous binary counters the carry chain limits non-pipelined performance. 
For 16 bits in a -6, you can get about 195 MHz, but you need to be careful about
fan-in on any controls.  For a free running counter, the automatic tool flow
should get you pretty close to that.  As soon as you add controls, you'll need
to be careful about fan-in and implementation to get it. You'll need to play
some tricks with the 32 bit such as pipelining the carry to get the 32 bit
counter running near the same rate.  That said, 100 MHz is a pretty easy to hit
target for a -6.  I've been doing 100+ MHz DSP designs with 16-24 bit carry
chains in virtex -4's.

Lawrence Peregrim wrote:
> 
> What's the fastest binary up-counter speed that can be wrung from a
> speed grade 6 Virtex?  I need to emulate a few ASIC counters (one 16
> bit and one 32 bit) that are presently implemented with simple chained
> toggle flops.  These counters have async. clear only, no load/preset.
> Before getting to the post P&R sims and after looking at Xilinx literature,
> it looks like I should expect around 100 MHz.  I'm looking to use the
> secondary interconnect lines.
> 
> TIA
> Lawrence

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 28454
Subject: Re: Alliance for Linux - not a technical issue
From: Simon Gornall <simon@unique-id.com>
Date: Sat, 13 Jan 2001 09:58:13 +0000
Links: << >>  << T >>  << A >>
Kenneth Porter wrote:
> 
> bjrosen <bjrosen@polybus.com> wrote in <93m3nr$j82$1@nnrp1.deja.com>:
> 
> >The Redhat Package Manager makes sure that this doesn't happen on Linux.
> >When you do an install it checks all of the dependencies and tells you
> >what applications you are going to break.
> 
> This assumes the app uses a packaging system. Some developers avoid
> packaging systems to remain less tied to a distribution. In many cases
> RPM's are provided by 3rd party packagers or a distribution vendor, not the
> original source of the tarball.

But we are talking about the Alliance tools. Should Xilinx ever distribute
(hint! hint!) Linux tools, I'd expect them to be in .rpm format. I don't
mean 'expect' as in "they'd better be", I mean it in the sense "most 
distributors do"
 
> >On Windows every installer assumes that it's free to replace anything it
> >wants.
> 
> But that's a matter of convention, not something enforced either on Linux
> or Windows. Package managers can help, but they're not a panacea. A vendor
> can either supply only tarballs, or supply packages that are just as broken
> as Windows installers. (I regularly help newbie packagers of packages I'm
> interested in to fix their packages. A common error is to forget %config
> attributes in the %files list, which clobbers one's customized config files
> when upgrading with the next version's stock config files.)
>
> >Also on Linux you can use different libraries for every app if you want,
> >thats what the LD_LIBRARY_PATH env variable is for.
> 
> In Windows, an app can put all its DLL's in the app directory. Why doesn't
> this happen? Why do so many apps insist on dropping their stuff in the
> system directory?

Why? Who knows. Certainly most linux apps don't have this problem.

Perhaps it's just a "typical use" thing - most Windows programmers are
used to having "wizards" to do the grunt work for them. I'd guess the
"create a package" wizard in Visual C++ defaults to stuffing everything
into the system (system32) folder.

Under Linux it's the opposite by convention - you install into /opt/<package>/{lib,bin,man,etc...} or /usr/local/<package>/...
I think the /usr/local... is no longer part of the LFS spec
though, I think /opt/<package> is the recommended layout now.

Two "absolutely safe" methods come to mind for supporting linux:

 o Xilinx could install their own versions of the shared libs 
   they use, and use LD_LIBRARY_PATH as above, or

 o They could link the programs statically.

So the 'make world' target makes 2 rpm's, one the "this is only going
to work on 99.9% of glibc systems" (the standard rpm) or the "this 
will always work" (the static/own libraries rpm). End of problem.

The first "safe" case has the advantage you only need to download 
the libs once, then it's a faster download for the changing code, 
but frankly I wouldn't care - given the choice "You can have
statically linked binaries or nothing" I would be a happy bunny :-)

ATB,
	Simon.
-- 
Physicists get hadrons!

Article: 28455
Subject: Re: CHES 2001 --- 2nd CFP
From: "A Al-Sabagh" <aalsabagh@hotmail.com>
Date: Sat, 13 Jan 2001 06:19:34 -0500
Links: << >>  << T >>  << A >>
testing

--
Al Sabagh
98081-2150 Burnhamthorpe Rd W.
Mississauga, ON L5L 3A0
Canada
Fax: 530 504 9330
"Christof Paar" <christof@ece.wpi.edu> wrote in message
news:Pine.OSF.4.10.10101121557500.3338-100000@goya.WPI.EDU...
> We apologize for multiple mailings. -Christof Paar
>
> ===================================================================
>
>            WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS
>                                  (CHES 2001)
>
>                              www.chesworkshop.org
>
> Paris - France
>        May 13 - 16, 2001
>
>                             Second Call for Papers
>
> 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 third 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 second workshop, CHES
> 2000, was also held at WPI in August of 2000 and had an attendance of
> 180.
>
> The third workshop, CHES 2001, will be held in Paris in May of 2001.
> 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
>
>
> Instructions for Authors
>
> Authors are invited to submit original papers. The preferred
> submission form is by electronic mail to submission@chesworkshop.org.
> 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.
>
>
> Important Dates
>
>  Submission Deadline:          February 15th, 2001.
>  Acceptance Notification:      March 31st, 2001.
>  Final Version due:            April 21st, 2001.
>  Workshop:                     May      13th - 16th, 2001.
>
> NOTE: The CHES dates May 13th - 16th are the Sunday - Wednesday
> succeeding Eurocrypt 2001 which ends on Thursday, May 10th.
>
>
> Mailing List
>
> If you want to receive emails with subsequent Call for Papers and
> registration information, please send a brief mail to:
>   mailinglist@chesworkshop.org
>
>
> Invited Speakers
>
> Ross Anderson, University of Cambridge, U.K.
>   Protecting Embedded Systems - the Next Ten Years
>
>
> Program Committee
>
> Ross Anderson, University of Cambridge, England
> Jean-Sebastien Coron, Gemplus, France
> Kris Gaj, George Mason University, USA
> Jim Goodman, Chrysalis-ITS, Canada
> Anwar Hasan, University of Waterloo, Canada
> Peter Kornerup, Odense University, Denmark
> Bart Preneel, Katholieke Universiteit Leuven, Belgium
> Jean-Jacques Quisquater, Universite Catholique de Louvain, Belgium
> Christoph Ruland, University of Siegen, Germany
> Erkay Savas, cv cryptovision, Germany
> Joseph Silverman, Brown University and NTRU Cryptosystems, Inc., USA
> Jacques Stern, Ecole Normale Superieure, France
> Colin Walter, Computation Department - UMIST, U.K.
> Michael Wiener,   Entrust Technologies, Canada
>
>
> Organizational Committee
>
> All correspondence and/or questions should be directed to either of the
> Organizational Committee Members:
>
> Cetin Kaya Koc
> (Publications Chair)
> Dept. of Electrical & Computer Engineering
> Oregon State University
> Corvallis, Oregon 97331, USA
> Phone: +1 541 737 4853
> Fax: +1 541 737 8377
> Email: Koc@ece.orst.edu
>
> David Naccache
> (Program Chair and Local Organization)
> Gemplus Card International
> 34 Rue Guynemer
> 92447 Issy les Moulineaux Cedex, FRANCE
> Phone: +33 1 46 48 20 11
> Fax: +33 1 46 48 20 04
> Email: David.Naccache@gemplus.com
>
> Christof Paar
> (Publicity Chair)
> Dept. of Electrical & Computer Engineering
> Worcester Polytechnic Institute
> Worcester, MA 01609, USA
> Phone: +1 508 831 5061
> Fax: +1 508 831 5491
> Email: christof@ece.wpi.edu
>
>
> 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.
>



Article: 28456
Subject: I wanna Model Sim cracked
From: "Changeun" <albong@nownuri.net>
Date: Sat, 13 Jan 2001 23:50:40 +0900
Links: << >>  << T >>  << A >>
I want cracked Model Sim
Where is it?
Plz. give me.




Article: 28457
Subject: ANN: Test Bench tool V2.01 - powerful and cheap
From: Malcolm Reeves <mreeves@fullcircuit.com>
Date: Sat, 13 Jan 2001 18:51:19 +0000
Links: << >>  << T >>  << A >>
ANNOUNCE:

Full Circuit releases greatly enhanced 'TestBench Tool':
Easily create testbenches (VHDL) with this low cost but powerful tool.

AUTOMATIC
Extracts entity from VHDL source and creates testbench VHDL source.
Fills in signal names on tool so that all the user has to do is
construct the test patterns.

FAST
Testbench VHDL source is not changed each time a test is revised (Test
patterns are saved to a test vector file) so VHDL is only compiled
once.

POWERFUL
Supports complex formulae for describing signal relationships. Has
repeat sub section and repeat section. Text entry and plot view.
Description displays in simulator as each test is executed.

MODULAR
Tests can be constructed in sections and test vectors built from one
or all sections.

FLEXIBLE
Testbench source is small and simple to allow easy user enhancement.
User modifications are protected from change by tool. User can modify
project testbench for local changes or template testbench for global
changes (i.e. adding user functions).

Test vectors are not limited just to entity signals but can include
variables and times. A typical use of this would be to pulse a clock
line N times rather than have N vector file entries.  Note that the
clock line can still be a signal so the vectors can drive the clock
directly at the change over for better control (i.e. use N-1 in
variable). Another use could be to supply data where source is
incomplete

LOW COST
80 GBP (+VAT if applicable).  Demo and 30 day full functional trial
version available.
Note requires Excel 97 or greater.

SCREENSHOTS & WORKED EXAMPLE
www.fullcircuit.com/TBtool.htm  or www.fullcircuit.com (for site
navigation menu and other items)  


FOR MORE INFO CONTACT
Malcolm Reeves
mreeves@fullcircuit.com


--
 Malcolm Reeves BSc CEng MIEE MIRSE, Full Circuit Ltd, Chippenham, UK
 (mreeves@fullcircuit.com, mreeves@fullcircuit.co.uk or mreeves@iee.org).
 Design Service for Analogue/Digital H/W & S/W Railway Signalling and Power
 electronics. More details plus freeware, Win95/98 DUN and Pspice tips, see:

 http://www.fullcircuit.com      or    http://www.fullcircuit.co.uk

 NEW - VHDL test bench tool

Article: 28458
Subject: Altera and LVDS
From: "an" <an@an.com>
Date: Sat, 13 Jan 2001 23:39:36 +0200
Links: << >>  << T >>  << A >>
Did anyone tried the LVDS pins on the 20k?
I'm trying to run it @670Mhz. Anything I should now?

Thanx,
  Gabby



Article: 28459
Subject: Re: I wanna Model Sim cracked
From: Ray Andraka <ray@andraka.com>
Date: Sat, 13 Jan 2001 22:49:53 GMT
Links: << >>  << T >>  << A >>
Contact Model Technology, www.model.com.  They'll sell you a crack for a fair
price.

Changeun wrote:
> 
> I want cracked Model Sim
> Where is it?
> Plz. give me.

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 28460
Subject: Re: grey code counters
From: Bill Lenihan <lenihan3weNOSPAM@earthlink.net>
Date: Sat, 13 Jan 2001 23:22:27 GMT
Links: << >>  << T >>  << A >>
This sounds convenient, but the problem remains .... if a normal binary up
counter looks like this:

always @(posedge clk) count <= count +1;

and we want the synthesis tool to turn this into a grey code counter for us:

always @(posedge clk) count <= count +1 /* synthesis counter = grey */ ;

.... then there's going to be a big discrepency between RTL & gate-level
simulation results, if our simulator checks the counter!



>
> What I'd like to see (and I think I suggested this to the Synplicity
> guys) is an attribute or something in the synthesis tool that lets you
> select gray-code or binary-code counters.
>
> That would be useful.
>
> -- a
> ----------------------------
> Andy Peters
> Sr. Electrical Engineer
> National Optical Astronomy Observatory
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) n o a o [dot] e d u

--
==============================
William Lenihan
lenihan3weNOSPAM@earthlink.net
.... remove "NOSPAM" when replying
==============================



Article: 28461
Subject: Re: grey code counters
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 14 Jan 2001 05:16:22 GMT
Links: << >>  << T >>  << A >>
I do not want to sound arrogant or pretentious,
but I have already described a Grey counter design ( XORing the D inputs of a
binary counter) that offers the fastest, most flexible and even cheapest
solution in a Virtex-like environment. Why look at anything else ? A 24-bit
synchronous binary counter runs 300 MHz in Virtex-II, and the Grey addition
slows this down by less than one ns per period, still over 230 MHz in a fully
synchronous and non-pipelined operation. What more do we need?
All that still remains is to make available the right VHDL/Verilog code.

Peter Alfke
=============================
Bill Lenihan wrote:

> This sounds convenient, but the problem remains .... if a normal binary up
> counter looks like this:
>
> always @(posedge clk) count <= count +1;
>
> and we want the synthesis tool to turn this into a grey code counter for us:
>
> always @(posedge clk) count <= count +1 /* synthesis counter = grey */ ;
>
> .... then there's going to be a big discrepency between RTL & gate-level
> simulation results, if our simulator checks the counter!
>
> >
> > What I'd like to see (and I think I suggested this to the Synplicity
> > guys) is an attribute or something in the synthesis tool that lets you
> > select gray-code or binary-code counters.
> >
> > That would be useful.
> >
> > -- a
> > ----------------------------
> > Andy Peters
> > Sr. Electrical Engineer
> > National Optical Astronomy Observatory
> > 950 N Cherry Ave
> > Tucson, AZ 85719
> > apeters (at) n o a o [dot] e d u
>
> --
> ==============================
> William Lenihan
> lenihan3weNOSPAM@earthlink.net
> .... remove "NOSPAM" when replying
> ==============================


Article: 28462
Subject: Re: grey code counters
From: bob elkind <eteam@aracnet.com>
Date: Sun, 14 Jan 2001 00:46:01 -0800
Links: << >>  << T >>  << A >>
The challenge was tempting...  Here is an 8-bit grey counter, coded to make
the
"algorithm" clearly understood (hopefully).  It is coded in Altera HDL (or
AHDL),
but the syntax is simple enough to be decipherable by the legions of
VHDL/Verilogs
designers out there.

The code could be modified without much effort to have width determined by
parameter passing.  If you take this step, please post it to the newsgroup.

The advantage of this coding is that the delay paths and bit "dependencies"
are
much closer to the conventional binary counter structure than some of the
other
algorithms mentioned in this thread.  A disadvantage is that for N bits of
counter,
N x 1.5 FFs are needed.  Each pair of bits in the count is treated as an
8-state
value, where the extra bit represents the current count direction for the
bit-pair.
An advantage is that the "immediate" dependencies (or logic equations) are
limited
to three input terms, rather than the entire width of the counter (as long
as you
ignore carry terms!).

Hopefully inspection of the code will be more clear than my attempts at
explanation.

-- Bob Elkind, eteam@aracnet.com

Code follows:

SUBDESIGN grey8
%
8-bit grey code counter, generalised to be extensible.

structure is a unidirectional ripple carry, similar
to conventional binary counter.

counter is up *only*, not bidirectional.

Bob Elkind, eteam@aracnet.com
%

(
 clock   : INPUT;  -- main clock
 enable   : input=vcc; -- clock enable
 reset   : input=gnd; -- reset the puppy, default is off
 out[7..0]  : output;  -- outputs
)

variable
 up[4..1]  : srffe;
 temp[4..1][1..0] : node;
 cry[4..0]  : node;
 cnt[4..1][1..0] : dffe;

begin
 up[].clk  = clock;
 up[].ena  = enable;
 up[].prn  = !reset;

 cnt[][].clk  = clock;
 cnt[][].ena  = enable;
 cnt[][].clrn = !reset;

 cry[0]   = vcc;

%
The grey counter is segmented into bit pairs.
For each bit-pair, there are 4 count values, and 2 direction-of-count
values, hence 8 states.

Sequence is:

  value   direction  carry out
    0       up          0
    1       up          0
    3       up          0
    2       up          1
    2      down         0
    3      down         0
    1      down         0
    0      down         1

This is sequence is implemented as a case statement or state machine,
for each of the bit-pair segments.

Also note that a "carry out" from the bit-pair to the next more significant
bit-pair occurs on the same "states" which produce count direction changes.
%


FOR i IN 1 to 4 GENERATE

case cnt[i][] is
 when 0 =>
  if up[i] then
   temp[i][] = 1;
  else
   temp[i][] = 0;
  end if;
 when 1 =>
  if up[i] then
   temp[i][] = 3;
  else
   temp[i][] = 0;
  end if;
 when 2 =>
  if up[i] then
   temp[i][] = 2;
  else
   temp[i][] = 3;
  end if;
 when 3 =>
  if up[i] then
   temp[i][] = 2;
  else
   temp[i][] = 1;
  end if;
end case;

if cry[i-1] then
 cnt[i][].d = temp[i][];
 up[i].s  = (cnt[i][]==0); -- change direction to up
 up[i].r  = (cnt[i][]==2); -- change direction to down
 cry[i]  = !cnt[i][0] and (cnt[i][1] == !up[i]);
else
 cnt[i][].d = cnt[i][];
 up[i].s  = gnd;
 up[i].r  = gnd;
 cry[i]  = gnd;
end if;

END GENERATE;

out[1..0] = cnt[1][];
out[3..2] = cnt[2][];
out[5..4] = cnt[3][];
out[7..6] = cnt[4][];


end;

Bill Lenihan wrote:

> I know how to make binary up/down counters and LFSR-based counters in
> verilog, but does anyone know of an algorithmic/equation-based way to
> make grey-code counters?
>


Article: 28463
Subject: Re: grey code counters
From: bob elkind <eteam@aracnet.com>
Date: Sun, 14 Jan 2001 00:55:58 -0800
Links: << >>  << T >>  << A >>
The challenge was tempting...  Here is an 8-bit grey counter, coded to make the
"algorithm" clearly understood (hopefully).  It is coded in Altera HDL (or AHDL),
but the syntax is simple enough to be decipherable by the legions of VHDL/Verilogs
designers out there.

The code could be modified without much effort to have width determined by
parameter passing.  If you take this step, please post it to the newsgroup.

The advantage of this coding is that the delay paths and bit "dependencies" are
much closer to the conventional binary counter structure than some of the other
algorithms mentioned in this thread.  A disadvantage is that for N bits of counter,
N x 1.5 FFs are needed.  Each pair of bits in the count is treated as an 8-state
value, where the extra bit represents the current count direction for the bit-pair.
An advantage is that the "immediate" dependencies (or logic equations) are limited
to three input terms, rather than the entire width of the counter (as long as you
ignore carry terms!).

Hopefully inspection of the code will be more clear than my attempts at
explanation.

-- Bob Elkind, eteam@aracnet.com

Code follows:

SUBDESIGN grey8
%
8-bit grey code counter, generalised to be extensible.

structure is a unidirectional ripple carry, similar
to conventional binary counter.

counter is up *only*, not bidirectional.

Bob Elkind, eteam@aracnet.com
%

(
 clock   : INPUT;  -- main clock
 enable   : input=vcc; -- clock enable
 reset   : input=gnd; -- reset the puppy, default is off
 out[7..0]  : output;  -- outputs
)

variable
 up[4..1]  : srffe;
 temp[4..1][1..0] : node;
 cry[4..0]  : node;
 cnt[4..1][1..0] : dffe;

begin
 up[].clk  = clock;
 up[].ena  = enable;
 up[].prn  = !reset;

 cnt[][].clk  = clock;
 cnt[][].ena  = enable;
 cnt[][].clrn = !reset;

 cry[0]   = vcc;

%
The grey counter is segmented into bit pairs.
For each bit-pair, there are 4 count values, and 2 direction-of-count
values, hence 8 states.

Sequence is:

  value   direction  carry out
    0       up          0
    1       up          0
    3       up          0
    2       up          1
    2      down         0
    3      down         0
    1      down         0
    0      down         1

This is sequence is implemented as a case statement or state machine,
for each of the bit-pair segments.

Also note that a "carry out" from the bit-pair to the next more significant
bit-pair occurs on the same "states" which produce count direction changes.
%


FOR i IN 1 to 4 GENERATE

case cnt[i][] is
 when 0 =>
  if up[i] then
   temp[i][] = 1;
  else
   temp[i][] = 0;
  end if;
 when 1 =>
  if up[i] then
   temp[i][] = 3;
  else
   temp[i][] = 0;
  end if;
 when 2 =>
  if up[i] then
   temp[i][] = 2;
  else
   temp[i][] = 3;
  end if;
 when 3 =>
  if up[i] then
   temp[i][] = 2;
  else
   temp[i][] = 1;
  end if;
end case;

if cry[i-1] then
 cnt[i][].d = temp[i][];
 up[i].s  = (cnt[i][]==0); -- change direction to up
 up[i].r  = (cnt[i][]==2); -- change direction to down
 cry[i]  = !cnt[i][0] and (cnt[i][1] == !up[i]);
else
 cnt[i][].d = cnt[i][];
 up[i].s  = gnd;
 up[i].r  = gnd;
 cry[i]  = gnd;
end if;

END GENERATE;

out[1..0] = cnt[1][];
out[3..2] = cnt[2][];
out[5..4] = cnt[3][];
out[7..6] = cnt[4][];


end;

Bill Lenihan wrote:

> I know how to make binary up/down counters and LFSR-based counters in
> verilog, but does anyone know of an algorithmic/equation-based way to
> make grey-code counters?


Article: 28464
Subject: Re: I wanna Model Sim cracked
From: Christoph Hauzeneder <chauzen@fh-landshut.de>
Date: Sun, 14 Jan 2001 14:06:24 +0100
Links: << >>  << T >>  << A >>
Changeun wrote:

> I want cracked Model Sim
> Where is it?
> Plz. give me.

This is a bit stupid. Because each license file of Model Sim can be used
only for one year. You can get a free license to evaluate Package Power
from Mentor Graphics (this program includes Model Sim) for 30 days.

Christoph


Article: 28465
Subject: Re: I wanna Model Sim cracked
From: bjrosen <bjrosen@polybus.com>
Date: Sun, 14 Jan 2001 15:15:49 GMT
Links: << >>  << T >>  << A >>
If you are looking for legitmately free CAE tools then check out the GNU
EDA site which lists CAE tools that are available under the GPL.

http://www.geda.seul.org

In article <93ppol$olk$1@news1.kornet.net>,
  "Changeun" <albong@nownuri.net> wrote:
> I want cracked Model Sim
> Where is it?
> Plz. give me.
>
>


Sent via Deja.com
http://www.deja.com/

Article: 28466
Subject: IDS 6.0 - FPGA Compiler Problem
From: ppetener@my-deja.com
Date: Sun, 14 Jan 2001 15:44:54 GMT
Links: << >>  << T >>  << A >>
Hi,

When importing a netlist (edif) from FPGA Compiler
II with ATMEL 6.0 (as a design) I get this
message:

"Unable to create instance ... of AML064 from
ATMEL - master not found"

looking inside the edif netlist file, I see the
following:
(edif  ATA66Host
  (edifVersion 2 0 0)
  (edifLevel 0)
  (keywordMap
    (keywordLevel 0)
  )
...
  (external ATMEL
    (edifLevel 0)
    (technology
      (numberDefinition)
    )
...
    (cell AML064
      (cellType GENERIC)
      (view Netlist_representation
        (viewType NETLIST)
        (interface
          (port D
            (direction INPUT)
          )
          (port C
            (direction INPUT)
          )
          (port Q
            (direction OUTPUT)
          )
        )
      )
    )
...
  (library DESIGNS
    (edifLevel 0)
    (technology
      (numberDefinition)
    )
    (cell ATA66Host
      (cellType GENERIC)
      (view Netlist_representation
        (viewType NETLIST)
        (interface
          (port ...
....
        )
        (contents
          (instance currState_reg_5
            (viewRef Netlist_representation
              (cellRef AML064
                (libraryRef ATMEL)
              )
            )
          )
...

1) Does thar error message means that the library
ATMEL wasn't found?
2) If it does, where is it? (I only found 'at40k'
library in
$ATMEL_INSTALL_DIR/lib/fpgaexp/At40k.net)
3) Looking in the tutorial for IDS 6.0 (pdf), i
found that I should have a file named at40k.syn
for synthesis.  But actually I don't.

Hope someone can help me,

PP


Sent via Deja.com
http://www.deja.com/

Article: 28467
Subject: Please explain these terms
From: strshn99@my-deja.com
Date: Sun, 14 Jan 2001 19:29:22 GMT
Links: << >>  << T >>  << A >>
Dear Gurus,

I am trying to write up a little article for our college little
newspaper but I am sort of a newbie at VHDL and FPGA. So I would like
you gurus to explain to me:
1) what these terms means.
2) what are the tools used to do these kind of things.

The terms are:

a) Logical Design
b) Physical Design
c) Logical Verification
d) Physical Verification

thanks very much


Sent via Deja.com
http://www.deja.com/

Article: 28468
Subject: revision control tools ??
From: strshn99@my-deja.com
Date: Sun, 14 Jan 2001 19:58:53 GMT
Links: << >>  << T >>  << A >>


Dear Gurus,

I have a newbie question to ask you.  What kind of Revision control
tools do you use when you are working on a design?  Any recommendation
as to which is better?

What tools are recommended for coverage analysis?

What tools are recommended for formal verification

What tools are recommended for timing verification, is it acceptable to
conduct timing verification by embedding timing delays in a VHDL test
bench? you know X <== ( Y AND Z ) AFTER 12 NS

thanks in advance



Sent via Deja.com
http://www.deja.com/

Article: 28469
Subject: Re: APEX
From: pineji@my-deja.com
Date: Sun, 14 Jan 2001 20:03:47 GMT
Links: << >>  << T >>  << A >>
In article <93n68n$c8v$1@s1.read.news.oleane.net>,
  "Le Mer Michel" <michel.lemer@sta.fr> wrote:
> Hi
> The exact message is :
> # ** Warning: */APEX20k_ASYNCH_MEM SETUP High VIOLATION ON WADDR(1)
WITH
> RESPECT TO WE;
> #   Expected := 2.06 ns; Observed := 1.41 ns; At : 49989.401 ns
> #    Time: 49989401 ps  Iteration: 4  Instance:
> /test/i1/i1_ai3_ai2_ai1_alpm_ram_dp_component_asram_asegment_a0_a_a4_a
/apexm
> em
> # ** Warning: */APEX20k_ASYNCH_MEM SETUP  Low VIOLATION ON WADDR(0)
WITH
> RESPECT TO WE;
> #   Expected := 2.06 ns; Observed := 1.41 ns; At : 49989.401 ns
> #    Time: 49989401 ps  Iteration: 4  Instance:
> /test/i1/i1_ai3_ai2_ai1_alpm_ram_dp_component_asram_asegment_a0_a_a4_a
/apexm
> em
> ....
>
> Michel Le Mer.
>
> S.K. Sharma <sanjay.kumar.sharma@philips.com> a écrit dans le
message :
> 93hoat$r9c$1@porthos.nl.uu.net...
> > Hi Michel,
> > Could you post the exact error message!
> > Thanks
> > Sanjay
> >
> > --
> > Sanjay Kumar Sharma
> > ASIC Design Engineer
> > Philips Semiconductors
> > Eindhoven, The Netherlands
> > "Le Mer Michel" <michel.lemer@sta.fr> wrote in message
> > news:93c9gj$kk4$1@s1.read.news.oleane.net...
> > > Hello
> > >
> > > I have a strange message about APEX20K_ timing violation during
> simulation
> > > despite I use the APEX 20KE family and that all the frequencies
are met
> > > according to Quartus.
> > >
> > > Any suggestions?
> > >
> > > Thanks
> > > --
> > > Michel Le Mer     immeuble Cerium
> > > STA                    12, square du Chene Germain
> > > 02 23 20 04 72   35510 Cesson-Sevigne
> > >
> > >
> >
> >
> >
>
>
     With the small amount of information provided I'd venture to guess
that you are using the built in SRAM in an asynchronous fashion.  The
static timing check should have yielded an error but did not either
because a generated clock was not properly described to Quartus or the
tool may just be incapable of detecting this error for this
configuration.  I would suggest using the SRAM in its synchonous
configuration and generating the control signals for the synchronous
SRAM with the same clock as the SRAM.

Josh
--
Altera FPGA Consulting- Not ACAP Affiliated


Sent via Deja.com
http://www.deja.com/

Article: 28470
Subject: Re: HELP: Problem with interfacing an Altera MAX7000 device to the ISA bus
From: pineji@my-deja.com
Date: Sun, 14 Jan 2001 20:45:03 GMT
Links: << >>  << T >>  << A >>
In article <3A55F0E8.68DB6254@earthlink.net>,
  Ashok Mahadevan <ashokm1@earthlink.net> wrote:
> Kenneth Porter wrote:
>
> > Ashok Mahadevan <ashokm1@earthlink.net> wrote in
> > <3A553937.7FB8DA30@earthlink.net>:
> >
> > >http://home.earthlink.net/~ashokm1/max7000_isa_bus.htm
> >
> > Nice web page!
>
> Thank you!.....if only the circuit worked as nicely :o)
>
> > One thing that jumps out at me is that you're using different edges
of IOWR
> > for different registers. Why? For an active low write signal, one
usually
> > clocks a register on the rising edge. Your registers at 300, 301,
and 303
> > are clocking on the falling edge of nIOWR.
>
> Okay, from what I understand about the PC/104 bus, this is how the
nIOWRsignal
> works with the data bus SD7-SD0:
>
>        ------------            ------------
> nIOWR              \          /
>                     ----------
>
>                 -----------------
> SDx    -------<                   >-------
>                 -----------------
>
> The signals on the data bus are stable, then the nIOWR signal is
asserted
> for a period of time, and then brought back high. I can latch the
data on
> the first falling edge of nIOWR. Am I wrong here?
>
> As to why I am using different edges of nIOWR for the latches, it was
the
> only way I could get them to latch!. I tried different edges, and this
> seemed to work the best. The operation is not consistent however
since it
> works only on one 74373 latch and not the other. I am doing something
> wrong, but am unable to find out what.
>
> > The 245 structure looks ok. Are you running the latest Altera
software?
>
> I thought so too, but the warnings from the Compiler and the fact that
> the setup does not work unless the 74245 section is disabled leads me
to
> believe that it is not an accepeted form of implementing a bi-
directional
> bus interface.
>
> Has anybody implemented a 74245 in an Altera device that they would
like
> to share with me? I received a reply from another person who had done
some
> interfacing with the PC/104 bus, but he used an external 74245 chip
in his
> design.
>
> I am using the student edition 9.23 of the Altera MAX+Plus II
software.
> This is not the latest (I believe version 10 is), but I think it is
> recent enough and in fairly common use.
>
> Thanks for your inputs.....
>
> Ashok
>
>

I looked over your great web page and have a few comments.  I did a
circuit similar to this a few years back and I think made similar
mistakes.  lol

First- Although the FPGA schematic editor leads you to belive you can
draw anything and it will compile it, the reality is that the FPGA (or
CPLD in this case) architecture is fixed.  Its your job to draw a
circuit that fits with the preexisting structure of the part.  Having
said that, you are best served by following synchronous design
practices.  Don't use the word "latch", its hurts peoples ears, use
flip flops whenever possible at all costs.  Latchs are used to solve
messy asynch problems of which you don't have for this design.  The
only thing that you should be connecting to clock pins on your flip
flops are clocks, not combinational circuity.  Whenever that circuity
glitchs as its settling in or decoding another ISA bus address, it will
trigger your flops.  The approach I would suggest is conencting the IOW
signal to the flip flip clock ports, and then connecting your selects
to the flop enable (place a DFFE).  What you've done is a common
mistake made when people are moving from MSI TTL part design to FPGAs.
In general, use flops that have enables, feed your complex decoding
into the enable, the clock into the clock port.  This means you may not
be able to use those TTL look-alike blocks, but who cares, those things
are headed the way of the dinosaur anyway.

As for your compiler message, relating to what I was saying about the
FPGA architecture being fixed and all, there is no such thing as a
tristate signal INTERNAL to the FPGA.  The only place trisate buffers
exist on the die are in the IO blocks.  Now I can see that you have
connected the tri cells to IO pins, but there is not direct path in the
CPLD from IO cell to I/O cell, you must go through the internals of the
CPLD between IO pins.  So if you put 2 lcells between each pair of
cross coupled tri cells, then the compiler should be able to route your
design.

Okay, hope this helps, good luck, and have fun!

Josh

--
Altera FPGA Consulting- Not ACAP Affiliated


Sent via Deja.com
http://www.deja.com/

Article: 28471
Subject: Re: Newbie question on clock timing generation
From: pineji@my-deja.com
Date: Sun, 14 Jan 2001 21:33:48 GMT
Links: << >>  << T >>  << A >>
In article <3a5310ff.10804430@news.dial.pipex.com>,
  eml@riverside-machines.com.NOSPAM wrote:
> On Wed, 27 Dec 2000 17:52:30 GMT, Greg Neff <gregneff@my-deja.com>
> wrote:
>
> >> - To keep the power low, the clocks for each subcircuit may be
gated.
> >>
> >
> >No, they may not be gated.  Unless you know exactly what you are
doing,
> >and the internal architecture of the FPGA, you *must* clock all flip-
> >flops directly from global clock nets.  No gates.
>
> Remember that you can do all your gating *before* the clock buffer -
>
> Evan
>

You can do what you want but not to an unlimited degree and not without
added complexity.  The FPGA has a limited number of intenally generated
global clock nets (e.g. 4).

If you want you life to be easy, I don't recommend doing what you were
suggesting with a bunch of clocks.  The suggestion made earlier to use
one high speed clock with enables for various lower frequecies is sound
synchronous design but you will pay in power for this architecture.  As
far as the "if (clk3en) then ..." don't worry about this too much, the
FF's have enables in general.

Josh
--
Altera FPA Consulting- Not ACAP Affiliated


Sent via Deja.com
http://www.deja.com/
Article: 28472
Subject: Re: FPGA to ASIC conversion
From: pineji@my-deja.com
Date: Sun, 14 Jan 2001 21:54:03 GMT
Links: << >>  << T >>  << A >>
In article <f9tl3tg228htuk39c9kdkfs9o2999ggbi9@4ax.com>,
  Muzaffer Kal <muzaffer@dspia.com> wrote:
> On Sat, 16 Dec 2000 03:21:15 GMT, hchenry@comsoc.com wrote:
>
> >Dear all,
> >
> >Does anyone know how to make/steps conversion from FPGA gate-level
> >netlist to ASIC gate-level netlist ?
> >
> >I'm currently triying convert Xilinx FPGA to ASIC's CMOS Technology
by
> >using Synopsys Design Compiler.
> >But, some instance was unresolved references such OBUF , DFF ( flip-
> >flop )!!
> >Could anyone share your experiences with me ?
>
> First of let me ask you why you are trying to convert the gate level
> netlist. It would be much easier to convert the RTL. Assuming that you
> really want to do the gate level conversion, you have to make models
> of all the cells in the netlist. Put them in a library file and
> include it in your synthesis script. It can be a tedious and error
> prone process.
>
> Muzaffer
>
> FPGA DSP Consulting
> http://www.dspia.com
>

Ya, what happened to the RTL used to generate your FPGA netlist?  This
is the best way to do it.

If you're very lucky, and the cells you're missing have direct
equivalents in your ASIC library, the missing cells might be able to be
replaced with a script. For example, the ASIC library probably has a
buffer (OBUF) and probably has a positive edge triggered F/F without
set/reset.

Josh
--
Altera Consulting- Not ACAP Affiliated


Sent via Deja.com
http://www.deja.com/
Article: 28473
Subject: Re: async interface
From: pineji@my-deja.com
Date: Sun, 14 Jan 2001 22:08:17 GMT
Links: << >>  << T >>  << A >>
Hi Rob,

Ya Martin is right, that's what I was going to suggest.

The other suggestion I was going to make was to run everything on the
high speed counter clock and use the low frequency shift
register "clock" as a control signal to enable the shifter to shift.

Josh

In article <3a3de248@news.datacomm.ch>,
  "Martin Heimlicher" <heimlicher@scs.ch> wrote:
> Hi Rob,
>
> You could implement the store registers on the counter clock. You
could
> sample the en signal on the counter clock and load the new value from
the
> shift register when you see a rising edge on en. This requires a 2
state
> FSM.
>
> Regards,
>   Martin Heimlicher, Supercomputing Systems AG, Switzerland
>
> "rob" <rob4@xyz123abc.com> wrote in message
> news:<91gtko$g7l$1@neptunium.btinternet.com>...
> > Hi,
> >
> >         I am trying to design a method of loading a number of
counters
> with
> > a preset values stored in store  registers.
> >     Data is clked serially clked into a shift register on the
rising edge
> of
> > the serial clk(10 MHz) whilst the en signal is low, the serial to
parallel
> > converted data is then clked into store registers on the rising
edge of
> the
> > en signal( high for min period of 50 ns) which is asynchronous to
the clk
> > that is clking the counters .The clk to the counters can range
between 10
> > Mhz to 400 Mhz, the counters count down to 0 then are reloaded with
a
> preset
> > value stored in the store registers.
> > Any ideas how I can ensure that the no problems occur whilst new
data is
> > being loaded into the store registers and the counter is being
reloaded?
> >
> > Thanks
> >
> > Rob
> >
> >
>
>

--
Altera Consulting- Not ACAP Affiliated


Sent via Deja.com
http://www.deja.com/
Article: 28474
Subject: Re: Please explain these terms
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 14 Jan 2001 15:46:10 -0800
Links: << >>  << T >>  << A >>
strshn99@my-deja.com writes:
> I am trying to write up a little article for our college little
> newspaper but I am sort of a newbie at VHDL and FPGA. So I would like
> you gurus to explain to me:
> 1) what these terms means.
> 2) what are the tools used to do these kind of things.

They should be defined in the text book for your class.

I'd suggest not writing an article for the college newspaper until you
have at least 1/2 a clue about the subject matter.

On the other hand, why should a college newspaper be different than any
other newspaper?  Every time I read an article in the newspaper about
anything of which I happen to have first-hand knowledge, the article
tends to be very inaccurate.  So I suppose I should conclude that ALL
articles in newspapers are very inaccurate.




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