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

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

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

Custom Search

Messages from 12725

Article: 12725
Subject: Re: State machines in VHDL/Verilog
From: Todd Kline <todd@wgate.com>
Date: Mon, 26 Oct 1998 15:45:20 GMT
Links: << >>  << T >>  << A >>


Daniel Jones wrote:

> In article <36313CC4.9FD3D096@yahoo.com>,
>         Rickman <spamgoeshere4@yahoo.com> wrote:
>
> >Todd Kline wrote:
> >>
> >> If I care about the state encoding, I don't use enumerated types.  I
> >> use three different synthesis tools, two different simulators, and
> >> target FPGA's and ASIC's.  Just the differences in '87 and '93 are
> >> enough to drive me nuts.  I stay away from all tool specific constructs.
> >> For portability, I prefer the following structure:
> >>
> >>   ...
> >>
> >>   signal grants:               std_logic_vector(3 downto 0);
> >>    constant NO_GRANTS:         std_logic_vector(3 downto 0) := "0001";
> >>    constant VIDEO_GRANT:       std_logic_vector(3 downto 0) := "0010";
> >>    constant AUDIO_GRANT:       std_logic_vector(3 downto 0) := "0100";
> >>    constant CPU_GRANT:         std_logic_vector(3 downto 0) := "1000";
> >>
> >>   ...
> >>   variable next_grant:         std_logic_vector(3 downto 0);
> >>   ...
> >>
> >>    case grants is
> >>    when VIDEO_GRANT =>
> >>      ...
> >>      if(expression) then
> >>        next_grant   := VIDEO_GRANT;
> >>      else
> >>        next_grant   := NO_GRANTS;
> >>      end if;
> >>      ...
> >>    when AUDIO_GRANT =>
> >>      ...
> >>    when CPU_GRANT   =>
> >>      ...
> >>    when others      =>                        -- NO_GRANTS case
> >>      ...
> >>    end case;
> >>
> >> Of course, if the case statement is inside a clk'event, you don't need
> >> the variable.
> >
> >Todd,
> >
> >This was exactly the type of code I wrote in my first attempt to use
> >VHDL to build a state machine. I did not trust the FPGA tools (too many
> >bad experiences in the past) to do what I wanted using the methods I
> >read in the VHDL books. The problem was that the synthesizer did not
> >know that to detect state "VIDEO_GRANT" it only needed a single input.
> >It would use all N state variables as the input for each condition in
> >the case (state_variable == "0001" rather than just state_variable(0) ==
> >'1').

You are absolutely correct.  I just checked FPGA Express and Design
Compiler.  They both do exhaustive decodes rather then figuring out that only
one bit is active at a time.  I never noticed this before because I generally
have more trouble with my data path speed then state machine speed.

In FPGA Express you can select "one-hot" or "binary" encoding for
enumerated types, but again, you are giving up control to the synthesis tool,
and ALL of you state machines have to be the same type.

I think Dan Jones has the best approach for guaranteeing one-hot behavior
and still writing portable code.

Todd

Article: 12726
Subject: Re: Schematic entry?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 26 Oct 1998 10:55:24 -0500
Links: << >>  << T >>  << A >>
Ad Verschueren wrote:
> 
> "Glenn E. Hunt" <glennee@flash.net> writes:
> > One design team I know of got so frustrated with its inability to comprehend
> > the hierarchical structure of a device's HDL that they recast the design
> > into a top-level schematic of "black boxes" and put the HDL implementation
> > code under those, a technique that can obviously be extended as deeply into
> > a hierarchy as one desired.
> 
> I think that's not much more than a 'hack'. It works, but it's not optimal.

I would disagree with that assessment. Perhaps I am not familiar with
VHDL enough to understand how to easily represent hierarchy without
using structural VHDL. Structural VHDL is not easily read so that you
are much better using schematic in terms of readability. I am much more
comfortable using schematic at the top level while using VHDL for
modules, although not necessarily low level modules. Most of my modules
relate to funcitons and will have all of the datapath, data logic and
control logic for a given interface or major operation. This seems to be
a good balance between readability (VHDL becomes unwieldy with large
files) and functionality (schematics become cluttered when they contain
too much detail). 

 
> In MS-Word, I use outlining a lot and I like it - for writing normal texts
> like reports or manuals. I used the Transputer tools, and there it did not
> really help me - nothing beats a schematic to show structure. I don't know
> Synplicity, but our tool allows schematics to be (re-)used in a hierarchy.

This is a good idea. I use outlining when I write documents or when I
code in 'C'. I will try outlining the next time I use VHDL. One nice
feature of outlining is that you can preserve the high level code
constructs as comments which make the lowlevel code more readable. 

 
> > Having said that, it also seems to me that what we as hardware designers are
> > doing is thinking like schematic designers when we write our HDL.  I'm
> > starting to think this is not the best way to go about writing HDL.  Rather
> > than focus on tools, maybe we could gain improved clarity by changing the
> > way we think about the structure or partitioning of designs.  Can we devise
> > a design analysis/partition/capture technique or method that highlights or
> > exposes rather than obscures the relationships of HDL hierarchy?
> 
> IMHO, I think we have got one such method.

If you have the freedom in speed and density, then you can afford to
write the HDL as you would a 'C' program. But I have never worked on a
design where my gate count did not matter and most of my designs need
some level of performance which is not trivial in the technology which I
was using. 

 
> >  Is the
> > hybrid schematic-for-higher-levels with HDL underneath good enough?

That's what I use and like.   ;^)


-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 12727
Subject: 8B/10B Encoder Decoder
From: dch@Glue.umd.edu (David C. Hoffmeister)
Date: 26 Oct 1998 11:56:31 -0500
Links: << >>  << T >>  << A >>


	I am wondering if anyone knows where I might find a synthesizable
VHDL model for an 8B/10B encoder/decoder.  I know I saw a post a few months
ago asking a similar question, but I did not see if there were any replies.
Any help would be appreciated.

--
David C. Hoffmeister
dch@eng.umd.edu
University of Maryland at College Park
Article: 12728
Subject: Re: FPGA Decouple Capacitor values
From: geo@z9.com (George Pontis)
Date: Mon, 26 Oct 1998 09:53:36 -0800
Links: << >>  << T >>  << A >>
In article <363554C6.DDADB31C@associatedpro.com>, aps@associatedpro.com 
says...
> I read a XILINX technote that seemed to indicate that .1uf caps were
> barely adequate for decouple. What value decouple caps are generally
> reccomended with E, XL, XLA, and Spartan FPGAs for circuits in the 10,
> 50, 100 MHz ranges.

The amount of misinformation on the use of decoupling capacitors is 
remarkable, and even replying to this question is risking a mild flame 
war. However, I'm willing to engage some well-mannered discussion ...

For every Xilinx chip that you mention, as well as other logic, I assert 
that you will be quite safe with a single, 0.1uF, surface mount ceramic 
capacitor per power pin. You should do your layout such that the VCC and 
GND planes are on adjacent layers. The closely spaced planes maintain a 
low impedance between VCC and GND at all frequencies of interest, and as 
you go down in frequency the capacitors tend to work together as one 
larger value capacitor with exceptionally low ESR. Also, be sure that the 
layout connections between the capacitor pads and the planes are direct. 
The ideal, from a performance standpoint, would be to have vias directly 
under the cap contacts. (The least desireable is to have trace stubs 
connecting the capacitor pads to their vias.)

In some unusual cases it might be beneficial to use more capacitors. For 
example, a PCB containing mostly high current and fast bus buffers, or a 
memory board. But for a typical mix of logic, the above easy-to-follow 
recipe will produce excellent results.

As for the capacitors, I like the 50V X7R capacitors in 1206 case size. 
TDK is a good source; I am sure that there are many others.

-- 
George Pontis

(Replies to geo at z9 dot com.)
Article: 12729
Subject: Re: Need VHDL tools for Win NT/ Win 95
From: "Robert Ho" <rho@sarnoff.com>
Date: Mon, 26 Oct 1998 14:41:11 -0500
Links: << >>  << T >>  << A >>
Try searching www.isdmag.com. They have excellent eda tool summaries.

>Hi everyone !
>
>I am looking for some EDA tools that are running under Win 95/ Win NT
PC's.
>
>The tools should have :
>      - VHDL compiler & simulator
>      - FPGA synthesis
>      - some way to check that what goes out from synthesis is what
you
>need
>
>Anyone knows some tools like that please let me know. I heard about
>PeakVHDL,
>but I need some other, for comparison. Price/quality is the issue
here.
>
>Thank you, everybody.
>
>************************************************************
>Ovidiu Lupas
>Design Engineer
>TimTeh Electronics Ltd.
>
>e-mail      : ovilup@hotmail.com
>home e-mail : ovilup@mail.dnttm.ro      phone : 40-56-121951
>work e-mail : lupas@timteh.dnttm.ro phone/fax : 40-56-198943
>************************************************************
>

Article: 12730
Subject: CFP: EvoIASP '99
From: Stefano Cagnoni <cagnoni@ce.unipr.it>
Date: Mon, 26 Oct 1998 20:53:00 +0100
Links: << >>  << T >>  << A >>


                          CALL FOR PAPERS

                            EvoIASP '99
          FIRST EUROPEAN WORKSHOP ON EVOLUTIONARY COMPUTATION
                IN IMAGE ANALYSIS AND SIGNAL PROCESSING

                       GOTEBORG, 28 May, 1999

Evolutionary algorithms have been shown  to be tools which can be used
effectively in  the development of systems (software  or hardware) for
image  analysis  and signal  processing  in  complex  domains of  high
industrial and social relevance.

EvoIASP '99 will be the first European event specifically dedicated to
the applications  of evolutionary  computation (EC) to  image analysis
and signal  processing (IASP) and will give  European and non-European
researchers  in those  fields, as  well  as people  from industry,  an
opportunity  to   present  their  latest   research,  discuss  current
developments  and   applications,  besides  fostering   closer  future
interaction between members of the three scientific communities.

The  event  will be  held  at  Chalmers  University of  Technology  in
Goteborg, Sweden.

The  workshop is  sponsored by  EvoNet, the  Network of  Excellence in
Evolutionary Computing, and  is one of the activities  of EvoIASP, the
EvoNet working group on Evolutionary Computation in Image Analysis and
Signal  Processing. It  will be  held in  conjunction with  four other
major European events:

   * EuroGP'99, the second European workshop on genetic programming,
   * EvoRobot'99, the second European workshop on evolutionary robotics,

   * EuroECTel'99, the   first   European   workshop   on   evolutionary

     telecommunications,
   * EvoSCONDI'99,   the  first   European   workshop   on  evolutionary

     computation for systems, control and drives industry,

Topics of interest include, but are not limited to:

- Applications of evolutionary computation to real-life IASP problems
- Evolvable vision and signal processing hardware
- Evolutionary pattern recognition
- Hybrid  architectures  for machine  vision  and  signal  processing
  including evolutionary components
- Theoretical developments
- Comparisons between  different evolutionary techniques and  between
  evolutionary and non-evolutionary techniques in IASP applications
- Financial time series analysis by means of EC techniques.

The workshop will consist of:

- An invited talk by Dana Ballard
- Oral and poster sessions with periods for discussion
- Software demos and industrial stands

Fees:  Registration  fees  are  still  being  finalised  and  will  be
publicised shortly.

Registration   to  EvoIASP'99   will  include   free  non-transferable
registration to EvoRobot'99,  EuroGP'99, EuroECTel'99 and EvoSCONDI'99
(and vice versa).

A reduced registration rate will be available for students.

Submissions:

To submit,  send your manuscript (max  length: 10 A4 pages)  to one of
the  programme  co-chairs  in  PostScript (preferably  compressed  and
uuencoded) BY EMAIL (see addresses  below) not later than December 15,
1998.  The papers will be peer reviewed by at least two members of the
programme  committee,  of whom  at  least  one  from the  evolutionary
computation  community  and one  from  the  image  analysis or  signal
processing  community.  Authors  will  be notified  via  email on  the
results of the review by January 15, 1999.

The authors of  accepted papers will have four  weeks to improve their
paper on  the basis of  the reviewers' comments  and will be  asked to
send a  camera ready  version of their  manuscripts by  February 15th,
1999.  The  papers accepted  will appear  in the  workshop proceedings
which will be available at the workshop.

----------------------------------------------------------------------------

Organising Committee:

   * Riccardo Poli, The University of Birmingham, UK (Programme
co-chair)
     e-mail: R.Poli@cs.bham.ac.uk
   * Hans-Michael Voigt, GFaI - Center for Applied Computer Science,
Berlin,
     Germany (Programme co-chair) e-mail:voigt@gfai.de
   * Terry Fogarty, Napier University, UK (Publication chair) e-mail:
     T.Fogarty@dcs.napier.ac.uk
   * Stefano Cagnoni, University of Parma, Italy (Publicity chair)
     e-mail: cagnoni@ce.unipr.it
   * Peter Nordin,  Chalmers University of Technology (Local chair)
email:
     nordin@fy.chalmers.se

Programme Committee:

   * Giovanni Adorni, University of Parma, Italy
   * Jarmo Alander, University of Vaasa, Finland
   * Dana Ballard, University of Rochester, USA
   * Wolfgang Banzhaf, University of Dortmund, Germany
   * Suchendra Bhandarkar, University of Georgia, USA
   * Alberto Broggi, University of Pavia, Italy
   * Stefano Cagnoni, University of Parma, Italy
   * Ela Claridge, The University of Birmingham, UK
   * Jason Daida, University of Michigan, USA
   * Terry Fogarty, Napier University, UK
   * David Hogg, University of Leeds, UK
   * Mario Koeppen, FhG IPK, Germany
   * W.B. Langdon, The University of Birmingham, UK
   * Evelyne Lutton, INRIA, France
   * Peter Nordin, Chalmers University of Technology, Sweden
   * Riccardo Poli, The University of Birmingham, UK
   * Jim Smith, University of Western England, UK
   * Jacques Levy Vehel, INRIA, France
   * Hans-Michael Voigt, GFaI - Center for Applied Computer Science,
Germany

Venue:

Main Aula, Goteborg University, Vasaparken, Goteborg Directions can be
found
on the Web site of the workshops.

Information on Goteborg

Accommodation:

Some prices for May 99 are still approximate. Breakfast usually
included.

   * Maria Erikssons Pensionat, Chalmersgatan 27,  +46 31 20 70 30,
395-595
     SEK, Dorm 200SEK-250SEK, +46 31 166463, Distance 100 m
   * Hotel Flora, Gronsakstorget 2, +46 31 13 86 16, Fax +46 31 13 24
08,
     360-850 SEK, hotelflora.ab@swipnet.se, up to 6 beds in a few
     rooms,Distance 600m
   * Hotel Vanilj, Kyrkogatan 38, +46 31 7116220, Fax: +46 31 7116230,
     info@vaniljhotel.entersol.se, 595-895 SEK , 4 beds 1295 SEK,
Distance
     300m
   * Hotel Posseidon, Storgatan 33, +49 31 10 05 50, Fax: +49 31 13 83
91,
     Single 890 SEK, Double 1250, jige@algonet.se, Distance 200m
   * Hotel Mornington, 800 SEK, Kungsportsavenyn 9,
     mornington.hotel-gbg@wmhotels.se, +49 31 176540, Fax +49 31 711 34
39,
     Distance 200m
   * Hotel Excelsior, Karl Gustavsgatan 7, +46 31 17 54 35, Fax +46 31
17 54
     39, email: hotel.exelisio@tripnet.se,
http://www.tripnet.se/excelsior,
     625-792 SEK, Distance 150m
   * Hotel Rubinen Kungsportavenyn 24, +46 31 81 08 00, Fax +46 31
167586,
     reception.rubinen@scandic-hotels.se,
     reservation.rubinen@scandic-hotels.se, 1295-1965 SEK, Distance 300m

Local arrangements:

In case help is needed regarding venue and/or accommodation, please
contact

Peter Nordin
email: nordin@fy.chalmers.se
Institute of Physical Resource Theory
Chalmers University of Technology
S-412 96 Goteborg, SWEDEN

Timetable:

Submission deadline: 15 December 1998
Notification of acceptance: 15 January 1999
Camera ready papers for workshop: 15 February 1999
Workshop: 28 May 1999

Workshop Web Site:

http://www.ce.unipr.it/people/cagnoni/evoiasp99.html

Contacts:

Stefano Cagnoni
email: cagnoni@ce.unipr.it
Department of Computer Engineering
University of Parma
43100 Parma ITALY
Tel: +39 0521 905731, Fax +39 0521 905723

Peter Nordin
email: nordin@fy.chalmers.se
Institute of Physical Resource Theory
Chalmers University of Technology
S-412 96 Goteborg, SWEDEN
Tel: +46 31 607213, Fax +46 31 607201





Article: 12731
Subject: Q: Configure FPGA from an ISA bus?
From: AT_farhad_abdolian@hotmail.com (Farhad Abdolian)
Date: Mon, 26 Oct 1998 20:24:06 GMT
Links: << >>  << T >>  << A >>
Hi,
I am working on a home project to make a small Xilinx FPGA based hobby board!

I want to make it as cheap as possible and want to configure the board directly
from the ISA bus.

My plan is to have a small PLD (16V8) to decode the main address of the board,
and a 245 on the data bus.

Then I conect the DIN to DATA(0) (after buffer) and connect all the other
configuarion pins to signals from the PLD.

I found an application note on xilinx'x homesite, about the similar project, but
there they send the data in serial, but I wonder if anyone knows if it is
possible to send the data in parallell, using the "peripheral Synchronous" mode?
And in that case how do I download the bit file?

Really appreciate your help,

Regards,
Farhad A.

Article: 12732
Subject: Re: FPGA Decouple Capacitor values
From: "Ken Coffman" <kcoffman@intermec.com>
Date: Mon, 26 Oct 1998 14:26:01 -0800
Links: << >>  << T >>  << A >>
I had good luck with an Altera design running at 50Mhz with the following:
1206 ferrite bead isolating a Vcc network with 0.1uF ceramic caps (one per
power pin like George suggests), spread around a power "ring" (.050 trace of
1 oz copper) that fed the device. I felt like, if there was a real hot
circuit that needed special handling, having this isolation would allow me
to do something about it. I could increase the Z of the bead and increase
the capacitance, as necessary. But it wasn't necessary, conducted and
radiated emissions were in spec.
YMMV, IMO, Caveat Emptor, etc.

George Pontis wrote in message ...
>In article <363554C6.DDADB31C@associatedpro.com>, aps@associatedpro.com
>says...
>> I read a XILINX technote that seemed to indicate that .1uf caps were
>> barely adequate for decouple. What value decouple caps are generally
>> reccomended with E, XL, XLA, and Spartan FPGAs for circuits in the 10,
>> 50, 100 MHz ranges.
>
>The amount of misinformation on the use of decoupling capacitors is
>remarkable, and even replying to this question is risking a mild flame
>war. However, I'm willing to engage some well-mannered discussion ...
>
>For every Xilinx chip that you mention, as well as other logic, I assert
>that you will be quite safe with a single, 0.1uF, surface mount ceramic
>capacitor per power pin. You should do your layout such that the VCC and
>GND planes are on adjacent layers. The closely spaced planes maintain a
>low impedance between VCC and GND at all frequencies of interest, and as
>you go down in frequency the capacitors tend to work together as one
>larger value capacitor with exceptionally low ESR. Also, be sure that the
>layout connections between the capacitor pads and the planes are direct.
>The ideal, from a performance standpoint, would be to have vias directly
>under the cap contacts. (The least desireable is to have trace stubs
>connecting the capacitor pads to their vias.)
>
>In some unusual cases it might be beneficial to use more capacitors. For
>example, a PCB containing mostly high current and fast bus buffers, or a
>memory board. But for a typical mix of logic, the above easy-to-follow
>recipe will produce excellent results.
>
>As for the capacitors, I like the 50V X7R capacitors in 1206 case size.
>TDK is a good source; I am sure that there are many others.
>
>--
>George Pontis
>
>(Replies to geo at z9 dot com.)


Article: 12733
Subject: Re: FPGA Decouple Capacitor values
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Mon, 26 Oct 1998 20:19:22 -0500
Links: << >>  << T >>  << A >>
I've had excellent results by routing the power from the via THRU the cap's pad
then to the device.  Doing it this way uses the trace inductance to your
advantage by creating a T filter.  One cap per VCC pin works fine, with 0.047 to
0.1 uf per cap.  As was mentioned, you should have VCC and Ground planes on
adjacent layers to keep supply impedance low.  In most cases, you don't need the
bead this way.

Ken Coffman wrote:

> I had good luck with an Altera design running at 50Mhz with the following:
> 1206 ferrite bead isolating a Vcc network with 0.1uF ceramic caps (one per
> power pin like George suggests), spread around a power "ring" (.050 trace of
> 1 oz copper) that fed the device. I felt like, if there was a real hot
> circuit that needed special handling, having this isolation would allow me
> to do something about it. I could increase the Z of the bead and increase
> the capacitance, as necessary. But it wasn't necessary, conducted and
> radiated emissions were in spec.
> YMMV, IMO, Caveat Emptor, etc.



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 12734
Subject: Re: New Evolutionary Electronics Book
From: Steve Casselman <sc@vcc.com>
Date: Mon, 26 Oct 1998 18:23:07 -0800
Links: << >>  << T >>  << A >>
Mark Zenier wrote:

> >>It's not working as a digital circuit.  There's no clock provided to
> >>the FPGA.  Operation depends on circuit strays, and will only work
> >>in a 10 degree C temperature range.
>   But you can't make any claims about efficiency when you have an
> unanalyzable, and therefore unreliable random hack.  (I'm just going
> by the New Scientist article, maybe their book covers that).
>
> But then it would evolve in a slower, less entertaining way.
>
> Mark Zenier  mzenier@eskimo.com  mzenier@netcom.com  Washington State resident

I have seen two basic types of FPGA based evolvable hardware
strategies (both based on the xc6200).  Number one is the random
method. This method produces a result that works over a small
temperature range and is nearly impossible to reverse engineer.
These circuits are the most life like. They die when they get too
hot or too cold and nobody knows how they really work.  They
do things that you wouldn't think could be done with the
materials at hand kind of like saying "and you got a human
out of that little strand of DNA?".

Yet another method involves selecting a set of primitives (like
switching networks) look for
http://www.genetic-programming.com/jkpubs97.html
then search for 6216.




--
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com


Article: 12735
Subject: (no subject)
From: chenwei <chenwei@iastate.edu>
Date: Mon, 26 Oct 1998 22:07:34 -0600
Links: << >>  << T >>  << A >>
Hi,
I am currently working on using Xilinx FPGA to accelerate 
MPEG motion estimation algorithm. Does anyone here know 
some similiar is undergoing and where?

Thanks a lot.

Chenwei
Article: 12736
Subject: New free FPGA CPU
From: jhallen@world.std.com (Joseph H Allen)
Date: Tue, 27 Oct 1998 04:50:38 GMT
Links: << >>  << T >>  << A >>
Remember the last comp.arch discussion about minimalist CPUs about six months
ago?  It started, as usual, with the discussion about 1-instruction CPUs and
the like, but it ended with a discussion about the best CPU you could fit in
a small FPGA?

Well XACT just finished the first successful place&route of my new small
CPU so I should be ready to put it up on the net in the next few days. I'm
pretty sure that I'm going to release it as copylefted freeware.  Before I
make this first release I thought I'd get one cycle of comments on it,
before the instruction set is cast in stone.

The original goal was to make the best possible CPU in the limited resources
available in the cheapest Xilinx FPGA.  This is what I've come up with:

- Fits in Xilinx XC5202 FPGA.  This is Xilinx's cheapest FPGA: DIGIKEY sells
  them for $10.15 in single quantities or $7.40 in hundreds for the 84-pin
  PLCC version.  It has 64 CLBs, each with four FFs and four 4-input FMAPs.

- The design is in Xilinx XACT in OrCAD schematics.  I'll release the
  OrCAD source, postscript printouts of the schematics and a Xilinx macro
  of the CPU.

- It uses 143 FFs and 192 FMAPs and runs at 9MHz in the -5 part.  I should
  be able to get this a bit faster.  It would almost certainly nearly double
  in speed if I use 40 more FFs for a decode pipeline register, but I think
  the extra space is more valuable for peripherals.  I'll use the remaining
  space for a timer, a serial port and parallel ports.  The minimal computer
  will be this FPGA, a byte-wide ram and rom, and an oscillator.  The FPGA
  loads itself from the ROM, which then also contains the boot code.  I'm
  hoping that it will compete with microcontrollers.  The extra space in the
  FPGA could be used with a huge variety of possible peripherals (PLL, LCD
  interface, IDE-interface, floppy interface, printer interface, keyboard,
  video, who knows what else?).  I want to collect a library of these on
  my ftp site.

- It is not compatible with anything.  I was originally considering making
  a 6502 clone, but this is smaller and better (and I didn't want to
  implement decimal mode).  I'll write an assembler for it, hopefully for
  this first release (I need to write one to test it anyway).

- Unlike the 6502, no operations occur in sequence with memory accesses. 
  I.E., the ALU operation time does not detract from the memory performance.
  However, I do ALU operations on writes, but this is less of a problem than
  reads or address calculation.

- The CPU has the following programmable registers: 16-bit accumulator,
  16-bit program counter, 16-bit stack pointer, and 5-condition flag bits
  (the usual carry, overflow, negative, zero and interrupt enable).

- It can operate on 16-bit words, unsigned bytes and signed bytes.

- It has the following addressing modes: immediate, stack (stack-pointer
  plus 8-bit offset), and indexed (pick one of the first four words on the
  stack and add a 7-bit offset).  Note that it does not have direct
  addressing- you have to put the address on the stack first.  I chose to
  make it powerful enough to use data structures easily above the
  convenience of direct addressing.

- It is by no means a RISC processor; instead it more like a classic 8-bit
  CPU.  Instructions take 2-9 cycles to execute, where one cycle equals one
  memory access.  Yes, the hard-coded schematic instruction sequencer was a
  big pain.

- It has interrupts.  When there's an interrupt, all of the registers are
  pushed on the stack.  To return from the interrupt, pop all of the registers
  off of the stack using the 'pop' instruction.  'pop' is also used for
  subroutine returns.

- Unconditional and conditional jumps take a 16-bit destination address.  I
  would have done the usual pc-relative branches, but this saves space
  instruction sequencer space.

- Instructions are either 2 or 4 bytes and are encoded as follows:

1 m w a a a a r   r d d d d d d d           indexed
0 m w a a a a 1   d d d d d d d d           stack
0 1 w a a a a 0   i i i i i i i i           immediate
0 0 1 c c c c 0   - - - - - - - -           jump on condition (jcc)
0 0 0 1 1 1 1 0   d d d d d d d d           jump to subroutine indirect (jsr)
0 0 0 1 1 1 0 0   d d d d d d d d           jump indirect (address on stack)
0 0 0 1 1 0 1 0   - - - - - - - -           jump to subroutine direct (jsr)
0 0 0 1 1 0 0 0   - - - - - - - -           jump direct (jmp)
0 0 0 1 0 1 1 0   - - - - - a f p           push registers (psh)
0 0 0 1 0 1 0 0   - - - - - a f p           pop registers (pop)
0 0 0 1 0 0 1 0   v v v v v v v 0           software interrupt (brk)
0 0 0 1 0 0 0 0   - - - - - - - -           extra op-code space
0 0 0 0 - - - -   - - - - - - - -           extra op-code space

Where: m=1: register/memory instructions
       m=0: read-modify-write instructions
      cccc: condition code
        rr: base address no. (first four stack words)
   ddddddd: 7-bit offset
  dddddddd: 8-bit offset
  iiiiiiii: 8-bit immediate value.  16-bit immediate values appear in the
            following word.
     a f p: accumulator, flags, program counter: i.e., which regs to push/pop
   vvvvvvv: software interrupt vector no.
      aaaa: op-code
      ----: unused

read-modify-write op codes:
0000     sta		store accumulator word
         stab		store accumulator byte
0001     sts            store stack pointer
0010     lsl            logical shift left word
         lslb           logical shift left byte
0011     rol            rotate left word
         rolb           rotate left byte
0100     lsr            logical shift right word
         lsrb           logical shift right byte
0101     ror            rotate right word
         rorb           rotate right byte
0110     asr            arithmetic shift right word
         asrb           arithmetic shift right byte
0111     com            1's complement word
         comb           1's complement byte
1000     neg            negate word
         negb           negate byte
1001     cng            carry-negate
         cngb           carry-negate byte
1010     dec            decrement word
         decb           decrement byte
1011     csb            subtract carry from word
         csbb           subtract carry from byte
1100     inc            increment word
         incb           increment byte
1101     cad            add carry to word
         cadb           add carry to byte
1110     clr            clear word
         clrb           clear byte
1111     -              extra rmw code

register-memory (and register-immediate) op codes:
0000     nop
0001     tst            test word
         tstbx          test byte sign extended
0010     or             or word
         orb            or byte
0011     xor            xor word
         xorbx          xor byte sign extended
0100     bit            bit-test word
         bitb           bit-test byte
0101     and            and word
         andbx          and byte sign exteneded
0110     add            add word
         addb           add byte
0111     adc            add with carry word
         addbx          add byte sign extend
1000     cmp            compare word
         cmpb           compare byte
1001     cwc            compare word with carry
         cmpbx          compare byte sign extend
1010     sub            subtract word
         subb           subtract byte
1011     sbc            subtract word with carry
         subbx          subtract byte sign extend
1100     lda            load word
         ldab           load byte
1101     lda            load word
         ldabx          load byte sign extend
1110     lds            load stack pointer
         ldsb           load stack pointer from byte
1111     adds           add word to stack pointer
         addsbx         add sign extended byte to stack pointer

- loads, stores and add to stack pointer do not affect the flags, everything
  else does (except that logical instructions do not affect carry or
  overflow).

- I haven't decided where the reset or interrupt vectors or addresses are
  going to be yet.

- It uses a two-phase clock system for controlling the internal tri-state
  ALU B-side bus.  Basically the oscillator needs to be double the clock
  frequency.

Anyway, that's it.  Let me know what you think.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 12737
Subject: FPGA Decouple Capacitor values
From: Richard Schwarz <aps@associatedpro.com>
Date: Tue, 27 Oct 1998 00:06:14 -0500
Links: << >>  << T >>  << A >>
I read a XILINX technote that seemed to indicate that .1uf caps were
barely adequate for decouple. What value decouple caps are generally
reccomended with E, XL, XLA, and Spartan FPGAs for circuits in the 10,
50, 100 MHz ranges.

--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

    Richard Schwarz, President
    Associated Professional Systems Inc. (APS)
    email: richard@associatedpro.com
    web site: http://www.associatedpro.com
    Phone: 410-569-5897
    Fax:   410-661-2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 12738
Subject: Virtex PCI Board.
From: David Braendler <dbraendler@swin.edu.au>
Date: Tue, 27 Oct 1998 16:21:44 +1100
Links: << >>  << T >>  << A >>
I'm after a board for the new Virtex chip from Xilinx. What I would like
to do is get a PCI Board which I can plug the chip into, and start
designing with the Foundation series software.

Can anyone tell me if there is such a beast? And if so how much.

Actually if the cost is to high, I'm toying with the idea of designing
my own board for the task. I'd be really interested to hear from anyone
else out there who is contemplating tackling the the same task.

Cheers.

-
---------------------------------------------------------------------------------------------

David Braendler     http://gene.bsee.swin.edu.au/daveb/
Centre for Intelligent Systems
Swinburne University of Technology
--------------------------------------------------------------------------------------------



Article: 12739
Subject: Architectures for Reed-Solomon coding/decoding
From: Iain Richardson <richardson@4i2i.com>
Date: Tue, 27 Oct 1998 09:27:12 +0000
Links: << >>  << T >>  << A >>
You can find a tutorial page that discusses hardware architectures for
coding and decoding Reed Solomon codes at:
http://www.4i2i.com/reed_solomon_codes.htm

Hope this is of interest.

-----
Iain E G Richardson, Technical Director
4i2i Communications Ltd
Doig Scott Building, Craibstone Estate, Bucksburn,
Aberdeen AB21 9YA, UK
Email richardson@4i2i.com.REMOVE, Web http://www.4i2i.com/
Tel +44 1224 712844, Fax +44 1224 714413
Article: 12740
Subject: Re: New free FPGA CPU
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 27 Oct 1998 05:34:59 -0500
Links: << >>  << T >>  << A >>
hi joe,

read through part of it - how about .pdf or something - it's not easy for us to
read postscript here and we don't have the xilinx tools up and running.  and for
many of our applications, i would be interesting in evaluating it in a different
architecture.

thanks,

rk

--------------------------------

Joseph H Allen wrote:

> Remember the last comp.arch discussion about minimalist CPUs about six months
> ago?  It started, as usual, with the discussion about 1-instruction CPUs and
> the like, but it ended with a discussion about the best CPU you could fit in
> a small FPGA?
>
> Well XACT just finished the first successful place&route of my new small
> CPU so I should be ready to put it up on the net in the next few days. I'm
> pretty sure that I'm going to release it as copylefted freeware.  Before I
> make this first release I thought I'd get one cycle of comments on it,
> before the instruction set is cast in stone.
>
> The original goal was to make the best possible CPU in the limited resources
> available in the cheapest Xilinx FPGA.  This is what I've come up with:
>
> - Fits in Xilinx XC5202 FPGA.  This is Xilinx's cheapest FPGA: DIGIKEY sells
>   them for $10.15 in single quantities or $7.40 in hundreds for the 84-pin
>   PLCC version.  It has 64 CLBs, each with four FFs and four 4-input FMAPs.
>
> - The design is in Xilinx XACT in OrCAD schematics.  I'll release the
>   OrCAD source, postscript printouts of the schematics and a Xilinx macro
>   of the CPU.
>
> - It uses 143 FFs and 192 FMAPs and runs at 9MHz in the -5 part.  I should
>   be able to get this a bit faster.  It would almost certainly nearly double
>   in speed if I use 40 more FFs for a decode pipeline register, but I think
>   the extra space is more valuable for peripherals.  I'll use the remaining
>   space for a timer, a serial port and parallel ports.  The minimal computer
>   will be this FPGA, a byte-wide ram and rom, and an oscillator.  The FPGA
>   loads itself from the ROM, which then also contains the boot code.  I'm
>   hoping that it will compete with microcontrollers.  The extra space in the
>   FPGA could be used with a huge variety of possible peripherals (PLL, LCD
>   interface, IDE-interface, floppy interface, printer interface, keyboard,
>   video, who knows what else?).  I want to collect a library of these on
>   my ftp site.
>
> - It is not compatible with anything.  I was originally considering making
>   a 6502 clone, but this is smaller and better (and I didn't want to
>   implement decimal mode).  I'll write an assembler for it, hopefully for
>   this first release (I need to write one to test it anyway).
>
> - Unlike the 6502, no operations occur in sequence with memory accesses.
>   I.E., the ALU operation time does not detract from the memory performance.
>   However, I do ALU operations on writes, but this is less of a problem than
>   reads or address calculation.
>
> - The CPU has the following programmable registers: 16-bit accumulator,
>   16-bit program counter, 16-bit stack pointer, and 5-condition flag bits
>   (the usual carry, overflow, negative, zero and interrupt enable).
>
> - It can operate on 16-bit words, unsigned bytes and signed bytes.
>
> - It has the following addressing modes: immediate, stack (stack-pointer
>   plus 8-bit offset), and indexed (pick one of the first four words on the
>   stack and add a 7-bit offset).  Note that it does not have direct
>   addressing- you have to put the address on the stack first.  I chose to
>   make it powerful enough to use data structures easily above the
>   convenience of direct addressing.
>
> - It is by no means a RISC processor; instead it more like a classic 8-bit
>   CPU.  Instructions take 2-9 cycles to execute, where one cycle equals one
>   memory access.  Yes, the hard-coded schematic instruction sequencer was a
>   big pain.
>
> - It has interrupts.  When there's an interrupt, all of the registers are
>   pushed on the stack.  To return from the interrupt, pop all of the registers
>   off of the stack using the 'pop' instruction.  'pop' is also used for
>   subroutine returns.
>
> - Unconditional and conditional jumps take a 16-bit destination address.  I
>   would have done the usual pc-relative branches, but this saves space
>   instruction sequencer space.
>
> - Instructions are either 2 or 4 bytes and are encoded as follows:
>
> 1 m w a a a a r   r d d d d d d d           indexed
> 0 m w a a a a 1   d d d d d d d d           stack
> 0 1 w a a a a 0   i i i i i i i i           immediate
> 0 0 1 c c c c 0   - - - - - - - -           jump on condition (jcc)
> 0 0 0 1 1 1 1 0   d d d d d d d d           jump to subroutine indirect (jsr)
> 0 0 0 1 1 1 0 0   d d d d d d d d           jump indirect (address on stack)
> 0 0 0 1 1 0 1 0   - - - - - - - -           jump to subroutine direct (jsr)
> 0 0 0 1 1 0 0 0   - - - - - - - -           jump direct (jmp)
> 0 0 0 1 0 1 1 0   - - - - - a f p           push registers (psh)
> 0 0 0 1 0 1 0 0   - - - - - a f p           pop registers (pop)
> 0 0 0 1 0 0 1 0   v v v v v v v 0           software interrupt (brk)
> 0 0 0 1 0 0 0 0   - - - - - - - -           extra op-code space
> 0 0 0 0 - - - -   - - - - - - - -           extra op-code space
>
> Where: m=1: register/memory instructions
>        m=0: read-modify-write instructions
>       cccc: condition code
>         rr: base address no. (first four stack words)
>    ddddddd: 7-bit offset
>   dddddddd: 8-bit offset
>   iiiiiiii: 8-bit immediate value.  16-bit immediate values appear in the
>             following word.
>      a f p: accumulator, flags, program counter: i.e., which regs to push/pop
>    vvvvvvv: software interrupt vector no.
>       aaaa: op-code
>       ----: unused
>
> read-modify-write op codes:
> 0000     sta            store accumulator word
>          stab           store accumulator byte
> 0001     sts            store stack pointer
> 0010     lsl            logical shift left word
>          lslb           logical shift left byte
> 0011     rol            rotate left word
>          rolb           rotate left byte
> 0100     lsr            logical shift right word
>          lsrb           logical shift right byte
> 0101     ror            rotate right word
>          rorb           rotate right byte
> 0110     asr            arithmetic shift right word
>          asrb           arithmetic shift right byte
> 0111     com            1's complement word
>          comb           1's complement byte
> 1000     neg            negate word
>          negb           negate byte
> 1001     cng            carry-negate
>          cngb           carry-negate byte
> 1010     dec            decrement word
>          decb           decrement byte
> 1011     csb            subtract carry from word
>          csbb           subtract carry from byte
> 1100     inc            increment word
>          incb           increment byte
> 1101     cad            add carry to word
>          cadb           add carry to byte
> 1110     clr            clear word
>          clrb           clear byte
> 1111     -              extra rmw code
>
> register-memory (and register-immediate) op codes:
> 0000     nop
> 0001     tst            test word
>          tstbx          test byte sign extended
> 0010     or             or word
>          orb            or byte
> 0011     xor            xor word
>          xorbx          xor byte sign extended
> 0100     bit            bit-test word
>          bitb           bit-test byte
> 0101     and            and word
>          andbx          and byte sign exteneded
> 0110     add            add word
>          addb           add byte
> 0111     adc            add with carry word
>          addbx          add byte sign extend
> 1000     cmp            compare word
>          cmpb           compare byte
> 1001     cwc            compare word with carry
>          cmpbx          compare byte sign extend
> 1010     sub            subtract word
>          subb           subtract byte
> 1011     sbc            subtract word with carry
>          subbx          subtract byte sign extend
> 1100     lda            load word
>          ldab           load byte
> 1101     lda            load word
>          ldabx          load byte sign extend
> 1110     lds            load stack pointer
>          ldsb           load stack pointer from byte
> 1111     adds           add word to stack pointer
>          addsbx         add sign extended byte to stack pointer
>
> - loads, stores and add to stack pointer do not affect the flags, everything
>   else does (except that logical instructions do not affect carry or
>   overflow).
>
> - I haven't decided where the reset or interrupt vectors or addresses are
>   going to be yet.
>
> - It uses a two-phase clock system for controlling the internal tri-state
>   ALU B-side bus.  Basically the oscillator needs to be double the clock
>   frequency.
>
> Anyway, that's it.  Let me know what you think.
> --
> /*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
> int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
> +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
> ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}



Article: 12741
Subject: Re: Schematic entry?
From: Alain <alain_raynaud@mentorg.com>
Date: Tue, 27 Oct 1998 12:59:51 +0100
Links: << >>  << T >>  << A >>
Steve Bird wrote:
> 
> Your ideas about a mixed schematic/HDL environment hit, what I feel is,
> a very important point. HDL's are very effective for expressing intent
> in terms of isolated bubbles of functionality. They are poor in
> expressing the connectivity between these bubbles. Whilst schematics are
> a way forward the current pin based mechanism does not scale well with
> size. You cannot easily express association between signals and they
> rarely show any form of data flow. Also thought of having to connect up
> 300+ I/O signals at the top level makes me shudder, all that routing,
> moving, parallel lines to follow...

Not trying to put a commercial ad here, but from your description, this
kind of product reminds me very much of Renoir (HDL graphical entry tool
from Mentor). You can draw your top design as a schematic, and you can
edit each sub-block in VHDL if you want to (or with a state machine
editor).

For each level of the hierarchy, you choose the view you prefer:
schematics, VHDL text, state machine, and more.

I think that's the future of VHDL entry.

However, the only issue to take care of is compatibility: how do I
guarantee that if I send my files to another VHDL user, he will see the
same thing? Or at leat that he sees something that is easy enough to
understand. Not everyone is expected to own the exact same tool. And we
still have to work all together.

Alain.
-- 
-----------------------------------------------------------------------
 Alain RAYNAUD                                            META SYSTEMS 
 R&D Logic Design Team                                          LP 853
                                   3 Avenue du Canada - Batiment Sigma
 Tel: (33) 01 64 86 61 69             91975 Courtaboeuf Cedex - FRANCE
 E-Mail: Alain_Raynaud@mentorg.com            Fax: (33) 01 64 86 61 61
-----------------------------------------------------------------------
Article: 12742
Subject: Re: FPGA Decouple Capacitor values
From: ems@riverside-machines.com.NOSPAM
Date: Tue, 27 Oct 1998 12:06:43 GMT
Links: << >>  << T >>  << A >>
On Tue, 27 Oct 1998 00:06:14 -0500, Richard Schwarz
<aps@associatedpro.com> wrote:

>I read a XILINX technote that seemed to indicate that .1uf caps were
>barely adequate for decouple. What value decouple caps are generally
>reccomended with E, XL, XLA, and Spartan FPGAs for circuits in the 10,
>50, 100 MHz ranges.

this is one of those questions where 5 people will give you 6 answers.
here's a few more:

1) 100n caps can be a problem, because their usable frequency range
(reactance less than ~ 1 ohm, assuming 5 nH parasitic inductance for
an MLC cap on a PCB) is low (less than 10MHz). as a rule of thumb, use
47n/100n for 10MHz or less, 22n for 7-40MHz, 10n for 10-50MHz, 500pF
for 100MHz, 100pF for 200MHz.

2) obviously, a lower value cap can store less charge, and so may not
be able to deliver your instantaneous power requirements. in other
words, you need more of the lower-valued caps. you'll need to work out
what your instantaneous power requirements are, and to come up with
some compromise on the number of caps and their values.

3) use pwr/gnd planes if possible, put caps on the same side as the
device, use good (low inductance) caps, ie. multi-layer ceramics, etc.

4) don't be tempted to put vias under the cap's contacts. this could
lead to assembly problems.

5) be careful when paralleling up different value caps, in an attempt
to get a wider frequency response for the pair. the pair will have a
high reactance at intermediate frequencies (a parallel resonant peak),
which may cause problems. this is less pronounced as the two values
converge (a 10n/22n combination, for instance, gives a range of
approx. 5 - 70MHz, with only a small peak at mid-ranges).

6) check the datasheet for the cap - try to match the self-resonant
frequency to your clock rate or expected noise frequency (or see (1)
above for an approximation). you may also find that the manufacturer
specifies how much charge you can get off the cap per unit time, which
could simplify your calculations.

7) some manufacturers do low-inductance packages - in these, you
connect up the long side of the SMD package, rather than the short
side. this'll allow you to use larger value caps.

8) a good layout is as follows (irrespective of whether you've got
pwr/gnd planes or not):

power:
try to put an additional pwr plane, even if only partial, on the
topside under the device. put in one or two vias under the device
(*not* near the caps). route a thick track from the device power pin
directly to the cap (preferably 5mm or less).

gnd:
route a thick track from the cap to the corresponding device gnd pin.
again, try to keep it to 5mm or less. you can put a via in this track.

9) if you can't be bothered to do the calculations, here's another
(possibly dangerous) rule-of-thumb. do a good layout with maybe 4 or 5
caps connected with short topside tracks to pwr/gnd pin pairs on the
device, with one more cap connected to the planes (with vias) a bit
further away. put a 100n cap in this location, and select the others
according to your clock frequency, down to a minimum of 10n. if your
device is clocking at 70MHz or more, parallel up two caps in each of
the 4 or 5 locations, and experiment.

evan

Article: 12743
Subject: Re: New free FPGA CPU
From: z80@ds1.com (Peter)
Date: Tue, 27 Oct 1998 13:18:52 GMT
Links: << >>  << T >>  << A >>

I think this is excellent!

>- Fits in Xilinx XC5202 FPGA.  This is Xilinx's cheapest FPGA: DIGIKEY sells
>  them for $10.15 in single quantities or $7.40 in hundreds for the 84-pin
>  PLCC version.  It has 64 CLBs, each with four FFs and four 4-input FMAPs.

Not to mention the very small area in an *ASIC*.

>- The design is in Xilinx XACT in OrCAD schematics.  I'll release the
>  OrCAD source, postscript printouts of the schematics and a Xilinx macro
>  of the CPU.

Nice one!

>- It uses 143 FFs and 192 FMAPs and runs at 9MHz in the -5 part.  I should
>  be able to get this a bit faster.  It would almost certainly nearly double
>  in speed if I use 40 more FFs for a decode pipeline register, but I think
>  the extra space is more valuable for peripherals. 

I think you are right. This is fast enough for most apps like this.

>- It is not compatible with anything.  I was originally considering making
>  a 6502 clone, but this is smaller and better (and I didn't want to
>  implement decimal mode).  I'll write an assembler for it, hopefully for
>  this first release (I need to write one to test it anyway).

Make sure it runs in the DOS box of NT4 :)  And returns the various
errorlevels, so it can run out of a makefile.

>- It has the following addressing modes: immediate, stack (stack-pointer
>  plus 8-bit offset), and indexed (pick one of the first four words on the
>  stack and add a 7-bit offset).  Note that it does not have direct
>  addressing- you have to put the address on the stack first.  I chose to
>  make it powerful enough to use data structures easily above the
>  convenience of direct addressing.

Interesting. This however seems to favour HLL support, whereas such a
CPU would normally be programmed in asm. Being able to do

 ld hl, (543dh)

is rather useful.

>- It has interrupts.  When there's an interrupt, all of the registers are
>  pushed on the stack.  To return from the interrupt, pop all of the registers
>  off of the stack using the 'pop' instruction.  'pop' is also used for
>  subroutine returns.

Nice. How fast is this pushall/popall?

>- I haven't decided where the reset or interrupt vectors or addresses are
>  going to be yet.

Will you be doing vectored ints, where the device can supply half the
vector? I think that would be overkill, since it needs complex
peripherals and it is far easier to simply encode each of say 8 /IRQ
sources into eight equally spaced addresses.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.
Article: 12744
Subject: Re: ORCAD Compile error
From: "Thomas D. Tessier" <tomt@hdl-design.com>
Date: Tue, 27 Oct 1998 06:40:41 -0700
Links: << >>  << T >>  << A >>
Please include your code so we may better help you!

Tom Tessier

Andrea wrote:
> 
> I have this problem when trying to compile vhdl source with Orcad Express
> 7.01:
> 
> - NO POSSIBLE REGISTER IMPLEMENTATION with clock 'clk'
> 
> What's mean?
> I need to write code in vhdl for a memory (50*24; for a specific
> application) which is synthetizable: i tried several ways ...
> I hope you can help me suggesting the code that i can use. I'm a student and
> this is my first vhdl program!
> Thank you
> 
> <<<AN e-mail: andnas@tin.it>>>

-- 
+------------------------ ---------------------- ----------------------+
: t2design                                                             :
: 249 Lois Drive                                                       :
: Louisville, CO 80027                                                 :
+------------------------ ---------------------- ----------------------+
:  tomt@hdl-design.com   *  (303)665-6402       * Fax: (303)665-6431   :
+------------------------ ---------------------- ----------------------+
Article: 12745
Subject: Re: FPGA Decouple Capacitor values
From: peter299@maroon.tc.umn.edu (Wade D. Peterson)
Date: Tue, 27 Oct 1998 14:17:59 GMT
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM wrote:

<snip>
>gnd:
>route a thick track from the cap to the corresponding device gnd pin.
>again, try to keep it to 5mm or less. you can put a via in this track.

The 'thick track' may not be necessary.  Remember, you want to
minimize the inductance between the capacitor lead and the FPGA power
pin.  That lowers ESR (External Series Reactance).  I've found that a
lot of people want to use thick traces to reduce inductance, but it
really doesn't do that.  The major cause of inductance between the
capacitor and IC power pin is loop area of the signal trace.



Article: 12746
Subject: Re: New free FPGA CPU
From: msimon@tefbbs.com
Date: Tue, 27 Oct 1998 14:20:24 GMT
Links: << >>  << T >>  << A >>
Could you compile this for my Design Your Own Processor(tm) board?

I am using the XC4005 or XC4010. I can send you a .UCF for pin
placement.

I would love to distribute this as part of out tools. (object code
only or ?)

Simon - see my sig to find out what we are up to.
===========================================================
jhallen@world.std.com (Joseph H Allen) wrote:

>Remember the last comp.arch discussion about minimalist CPUs about six months
>ago?  It started, as usual, with the discussion about 1-instruction CPUs and
>the like, but it ended with a discussion about the best CPU you could fit in
>a small FPGA?
>
>Well XACT just finished the first successful place&route of my new small
>CPU so I should be ready to put it up on the net in the next few days. I'm
>pretty sure that I'm going to release it as copylefted freeware.  Before I
>make this first release I thought I'd get one cycle of comments on it,
>before the instruction set is cast in stone.
>
>The original goal was to make the best possible CPU in the limited resources
>available in the cheapest Xilinx FPGA.  This is what I've come up with:
>
>- Fits in Xilinx XC5202 FPGA.  This is Xilinx's cheapest FPGA: DIGIKEY sells
>  them for $10.15 in single quantities or $7.40 in hundreds for the 84-pin
>  PLCC version.  It has 64 CLBs, each with four FFs and four 4-input FMAPs.
>
>- The design is in Xilinx XACT in OrCAD schematics.  I'll release the
>  OrCAD source, postscript printouts of the schematics and a Xilinx macro
>  of the CPU.
>
>- It uses 143 FFs and 192 FMAPs and runs at 9MHz in the -5 part.  I should
>  be able to get this a bit faster.  It would almost certainly nearly double
>  in speed if I use 40 more FFs for a decode pipeline register, but I think
>  the extra space is more valuable for peripherals.  I'll use the remaining
>  space for a timer, a serial port and parallel ports.  The minimal computer
>  will be this FPGA, a byte-wide ram and rom, and an oscillator.  The FPGA
>  loads itself from the ROM, which then also contains the boot code.  I'm
>  hoping that it will compete with microcontrollers.  The extra space in the
>  FPGA could be used with a huge variety of possible peripherals (PLL, LCD
>  interface, IDE-interface, floppy interface, printer interface, keyboard,
>  video, who knows what else?).  I want to collect a library of these on
>  my ftp site.
>
>- It is not compatible with anything.  I was originally considering making
>  a 6502 clone, but this is smaller and better (and I didn't want to
>  implement decimal mode).  I'll write an assembler for it, hopefully for
>  this first release (I need to write one to test it anyway).
>
>- Unlike the 6502, no operations occur in sequence with memory accesses. 
>  I.E., the ALU operation time does not detract from the memory performance.
>  However, I do ALU operations on writes, but this is less of a problem than
>  reads or address calculation.
>
>- The CPU has the following programmable registers: 16-bit accumulator,
>  16-bit program counter, 16-bit stack pointer, and 5-condition flag bits
>  (the usual carry, overflow, negative, zero and interrupt enable).
>
>- It can operate on 16-bit words, unsigned bytes and signed bytes.
>
>- It has the following addressing modes: immediate, stack (stack-pointer
>  plus 8-bit offset), and indexed (pick one of the first four words on the
>  stack and add a 7-bit offset).  Note that it does not have direct
>  addressing- you have to put the address on the stack first.  I chose to
>  make it powerful enough to use data structures easily above the
>  convenience of direct addressing.
>
>- It is by no means a RISC processor; instead it more like a classic 8-bit
>  CPU.  Instructions take 2-9 cycles to execute, where one cycle equals one
>  memory access.  Yes, the hard-coded schematic instruction sequencer was a
>  big pain.
>
>- It has interrupts.  When there's an interrupt, all of the registers are
>  pushed on the stack.  To return from the interrupt, pop all of the registers
>  off of the stack using the 'pop' instruction.  'pop' is also used for
>  subroutine returns.
>
>- Unconditional and conditional jumps take a 16-bit destination address.  I
>  would have done the usual pc-relative branches, but this saves space
>  instruction sequencer space.
>
>- Instructions are either 2 or 4 bytes and are encoded as follows:
>
>1 m w a a a a r   r d d d d d d d           indexed
>0 m w a a a a 1   d d d d d d d d           stack
>0 1 w a a a a 0   i i i i i i i i           immediate
>0 0 1 c c c c 0   - - - - - - - -           jump on condition (jcc)
>0 0 0 1 1 1 1 0   d d d d d d d d           jump to subroutine indirect (jsr)
>0 0 0 1 1 1 0 0   d d d d d d d d           jump indirect (address on stack)
>0 0 0 1 1 0 1 0   - - - - - - - -           jump to subroutine direct (jsr)
>0 0 0 1 1 0 0 0   - - - - - - - -           jump direct (jmp)
>0 0 0 1 0 1 1 0   - - - - - a f p           push registers (psh)
>0 0 0 1 0 1 0 0   - - - - - a f p           pop registers (pop)
>0 0 0 1 0 0 1 0   v v v v v v v 0           software interrupt (brk)
>0 0 0 1 0 0 0 0   - - - - - - - -           extra op-code space
>0 0 0 0 - - - -   - - - - - - - -           extra op-code space
>
>Where: m=1: register/memory instructions
>       m=0: read-modify-write instructions
>      cccc: condition code
>        rr: base address no. (first four stack words)
>   ddddddd: 7-bit offset
>  dddddddd: 8-bit offset
>  iiiiiiii: 8-bit immediate value.  16-bit immediate values appear in the
>            following word.
>     a f p: accumulator, flags, program counter: i.e., which regs to push/pop
>   vvvvvvv: software interrupt vector no.
>      aaaa: op-code
>      ----: unused
>
>read-modify-write op codes:
>0000     sta		store accumulator word
>         stab		store accumulator byte
>0001     sts            store stack pointer
>0010     lsl            logical shift left word
>         lslb           logical shift left byte
>0011     rol            rotate left word
>         rolb           rotate left byte
>0100     lsr            logical shift right word
>         lsrb           logical shift right byte
>0101     ror            rotate right word
>         rorb           rotate right byte
>0110     asr            arithmetic shift right word
>         asrb           arithmetic shift right byte
>0111     com            1's complement word
>         comb           1's complement byte
>1000     neg            negate word
>         negb           negate byte
>1001     cng            carry-negate
>         cngb           carry-negate byte
>1010     dec            decrement word
>         decb           decrement byte
>1011     csb            subtract carry from word
>         csbb           subtract carry from byte
>1100     inc            increment word
>         incb           increment byte
>1101     cad            add carry to word
>         cadb           add carry to byte
>1110     clr            clear word
>         clrb           clear byte
>1111     -              extra rmw code
>
>register-memory (and register-immediate) op codes:
>0000     nop
>0001     tst            test word
>         tstbx          test byte sign extended
>0010     or             or word
>         orb            or byte
>0011     xor            xor word
>         xorbx          xor byte sign extended
>0100     bit            bit-test word
>         bitb           bit-test byte
>0101     and            and word
>         andbx          and byte sign exteneded
>0110     add            add word
>         addb           add byte
>0111     adc            add with carry word
>         addbx          add byte sign extend
>1000     cmp            compare word
>         cmpb           compare byte
>1001     cwc            compare word with carry
>         cmpbx          compare byte sign extend
>1010     sub            subtract word
>         subb           subtract byte
>1011     sbc            subtract word with carry
>         subbx          subtract byte sign extend
>1100     lda            load word
>         ldab           load byte
>1101     lda            load word
>         ldabx          load byte sign extend
>1110     lds            load stack pointer
>         ldsb           load stack pointer from byte
>1111     adds           add word to stack pointer
>         addsbx         add sign extended byte to stack pointer
>
>- loads, stores and add to stack pointer do not affect the flags, everything
>  else does (except that logical instructions do not affect carry or
>  overflow).
>
>- I haven't decided where the reset or interrupt vectors or addresses are
>  going to be yet.
>
>- It uses a two-phase clock system for controlling the internal tri-state
>  ALU B-side bus.  Basically the oscillator needs to be double the clock
>  frequency.
>
>Anyway, that's it.  Let me know what you think.
>-- 
>/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
>int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
>+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
>]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htm
Article: 12747
Subject: Re: Virtex PCI Board.
From: msimon@tefbbs.com
Date: Tue, 27 Oct 1998 14:32:52 GMT
Links: << >>  << T >>  << A >>
It is nothing like what you asked for but check out my sig. It might
be a tool you could use or modify.

I could do a custom for you at a reasonable price. Let me know by
e-mail.

Simon
================================================



David Braendler <dbraendler@swin.edu.au> wrote:

>I'm after a board for the new Virtex chip from Xilinx. What I would like
>to do is get a PCI Board which I can plug the chip into, and start
>designing with the Foundation series software.
>
>Can anyone tell me if there is such a beast? And if so how much.
>
>Actually if the cost is to high, I'm toying with the idea of designing
>my own board for the task. I'd be really interested to hear from anyone
>else out there who is contemplating tackling the the same task.
>
>Cheers.
>
>-
>---------------------------------------------------------------------------------------------
>
>David Braendler     http://gene.bsee.swin.edu.au/daveb/
>Centre for Intelligent Systems
>Swinburne University of Technology
>--------------------------------------------------------------------------------------------
>
>
>

Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htm
Article: 12748
Subject: Re: FPGA Decouple Capacitor values
From: Philip Buchholz <philipb@ods.com>
Date: Tue, 27 Oct 1998 09:23:07 -0600
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------53D1942EC77E12A3AE07EB5E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

One other thing to look at is the number of through hole vias used to
attach the decoupling capacitor to the power layers of the PCB and also
the trace lengths.  

If you use multiple vias (I typically use three for both ground and
power) then the inductance of each via is placed in parallel with the
inductance of the other vias.  The end result yields a reduction in the
total inductance between the capacitor pad and the power or ground
plane.  Three equal inductors of value 'L' placed in parallel yield a
total inductance 'L/3'.  Reducing the inductance helps shift the
resonant frequency of the decoupling network to higher frequencies.  

Inductors work to resist changes in current and the main function of the
decoupling capacitor is to quickly supply current bursts to provide for
the switching going on inside the IC.  The two areas that the engineer
can typically control are the trace lengths and the number of vias.  The
engineer can not control the lead inductance and the bond wire
inductance of the IC.

Notice here that I am talking about decoupling, and I am not talking
about power filtering.  In the case where you need to filter out the
noise from other parts of the board, I would use a ferrite bead and
possibly in extreme cases an isolated power island.  But, I almost never
attempt to use an isolated ground.  I have found that splitting the
ground is just asking for problems.

My typical layout has three traces coming from each capacitor pad. One
trace from the end and one trace from each side of each pad.  These
traces are to vias that are placed as close to the capacitor pad as the
design rules will allow for the board shop I am using.  I also use as
wide of a trace as possible. For a 1206 pad pattern I typically use a 50
to 75 mil trace.  If you can not do this on both power and ground I
recommend at least doing it on ground.  Ground inductance is the first
thing you look at when you have ground noise or EMI problems.

As far as  capacitor values go you can either try and calculate the over
all frequency response of your decoupling network and adjust your
capacitors for resonance at your operating frequency or you can just
approximate your values.  

As a GENERAL (notice I stressed GENERAL) rule of thumb the  higher the
frequency the lower your total "LOCAL" capacitance needs to be for peek
decoupling.  This gets real hard to deal with because you need a certain
amount of capacitance to be able to supply the needed current.  As you
get to higher and higher frequencies you start playing games with using
large bulk capacitors at the power supply (or connector) such as 10uf
tantalum capacitors and medium size caps. (~0.1 uF) in the general area
of the IC in question.  This provides decoupling to the power planes in
the area of the IC.  Finally, something like 0.01 down to 0.0047 could
be attached as close to the power pins as possible.  This all depends on
how sensitive the IC in question is to noise on the power supply and
also, the EMI/EMC requirements of the finished board.  
Of course the biggest dependency of all is how much time you actually
have to analyze the issue.  If you are being pounded on to get boards
done then you could just slap down a bunch of 1206 pad patterns and
figure out the values in the lab.(not recommended) 

If the issue of noise reduction and EMI/EMC requirements interests you,
try book that I have and like by Henry W. Ott called "Noise Reduction
Techniques in Electronic Systems" second edition.  Its ISBN number is
0-471-85068-3.  Also if your company is big enough to bring in guest
speakers I highly recommend Henry Ott I was very impressed by his
lecture.

Regards,
Philip Buchholz

Ray Andraka wrote:
> 
> I've had excellent results by routing the power from the via THRU the cap's pad
> then to the device.  Doing it this way uses the trace inductance to your
> advantage by creating a T filter.  One cap per VCC pin works fine, with 0.047 to
> 0.1 uf per cap.  As was mentioned, you should have VCC and Ground planes on
> adjacent layers to keep supply impedance low.  In most cases, you don't need the
> bead this way.
> 
> Ken Coffman wrote:
> 
> > I had good luck with an Altera design running at 50Mhz with the following:
> > 1206 ferrite bead isolating a Vcc network with 0.1uF ceramic caps (one per
> > power pin like George suggests), spread around a power "ring" (.050 trace of
> > 1 oz copper) that fed the device. I felt like, if there was a real hot
> > circuit that needed special handling, having this isolation would allow me
> > to do something about it. I could increase the Z of the bead and increase
> > the capacitance, as necessary. But it wasn't necessary, conducted and
> > radiated emissions were in spec.
> > YMMV, IMO, Caveat Emptor, etc.
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka
--------------53D1942EC77E12A3AE07EB5E
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Philip Buchholz
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Philip Buchholz
n:              Buchholz;Philip
org:            ODS Networks, Inc.
adr:            1001 East Arapaho Rd;;;Richardson;TX;75081-2327;USA
email;internet: philipb@ods.com
title:          Electrical Design Engineer
tel;work:       (972)234-6400
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------53D1942EC77E12A3AE07EB5E--

Article: 12749
Subject: Re: DynaText **!?!?
From: Jan Martin Wagenaar <beerput@tip.nl>
Date: Tue, 27 Oct 1998 17:36:39 +0100
Links: << >>  << T >>  << A >>
A guillotine for the poor PC who probably hates having this dyna-stuff
on him, or for the Xilinx guy ?
As for Dynatext itself, even when it runs, it don't work.

	Jan Martin Wagenaar
	beerput@tip.nl


Ray Andraka wrote:
> 
> How about a guilotine?  Nothing quite like cluttering the machine up with a
> bunch of non-standard documentation readers!
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka


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

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

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

Custom Search