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 12650

Article: 12650
Subject: Re: Xilinx may not support schematics for Virtex?????
From: "Austin Franklin" <dark8room@ix.netcom.com>
Date: 21 Oct 1998 22:54:34 GMT
Links: << >>  << T >>  << A >>
> >> >> > Try doing a functional simulation....I believe the underlying
> >> >simulation
> >> >> > libraries are not there....
> >> >> 
> >> >> >>I believe that is because the Virtex timing files were not in
place
> >> >when they
> >> >> shipped F1.5 however, the timing models are coming.
> >> >
> >> >That was the point.  The FAEs said that Xilinx has NO plans on
providing
> >> >these, or supporting ANY schematic tools for Virtex.
> >> 
> >> I do not understand how anyone would make a big deal about this.
> >> Mentor Graphics uses vhdl models to simulate their schematic
> >> capture tool and it works great.
> >
> >Then you don't understand what the problem is.  If you did, then you'd
> 
> I remember you.  You are the guy who claims viewsim supports concurrency
> because you can generate a clock signal right?

Something tells me you 1) don't understand what you really mean by
concurency, and 2) how one can easily do what it is you were claiming one
can't do in Viewsim.

> You are also the guy who does not know what a vhdl testbench is, probably
the
> only person n this newsgroup.

Funny, I guess for all the designs I've done, and used 'test benches' for,
I just blindly poked at the keys (and nudged my mouse), and by magic, my
designs work (er, once simulated, debugged and timed), are shipping in
thousands upon thousands, without any problems....and I did ALL that by
dumb luck!

Gee, Rita, how many designs do YOU have shipping in REAL products?  Hum?

Austin

Article: 12651
Subject: Re: Schematic entry?
From: "ram" <rmcbain@istar.ca>
Date: Wed, 21 Oct 1998 21:04:20 -0700
Links: << >>  << T >>  << A >>
Interesting thread you guys have going here.

My $0.02 worth (Wow! I finally realized there is no "cents" character on my
keyboard - that only took 15 years of keyboard pecking... :)

1. The better FPGA HDL tools are just recently getting to the point where
you can wring out a decent, medium performance design entirely in HDL.
Witness a statement in EE Times by Stephen Wasson at Highgate Design (guys
who did Xilinx PCI core - we used them before for other stuff) who said he
might actually start using the VHDL  tools once Synplicity got their next
release of tools out (it allows you to guide the architectural mapping in
some ways I don't recall).

2. It's interesting to see (at times) that the software guys think pictures
will be their saviors (e.g. Labview, Rational Rose, Software through
Pictures, some DSP tools, etc.) and the hardware guys think that languages
will be their saviors (various HDLs).
To me, I think that a picture is worth a thousand words, AND vice versa,
depending on the context it's used in.

Having spent a fair bit of time in system design (radar systems and such), I
prefer the top level in pictures with some words around it. As I go down
through the heirarchy, pictures or text are used as appropriate.  For
instance, a state machine is easier for me to comprehend as a diagram.  But
there are times when an HDL (or pseudocode)  conveys the meaning better (in
an algorithm description, for example). Or maybe a schematic gives a higher
performance result.

The bottom line is that, if you view the choice of HDL vs. schematics vs.
state diagrams vs ... as a religious choice one must make, then sooner or
later there will be a downside.  Hopefully we can convince the tool vendors
that we'd like to slide back and forth between all these modes of
description as seemlessly as possible, and WE decide what's appropriate.

Regards, Rick

ps. as to somebody's comment in a later thread about just making the
algorithm more efficient (instead of it's implementation).  If you do "hard"
stuff, you typically have to do both.  I'm very good at efficient algorithms
(you try and figure out how to resample 3 billion 1 bit data elements per
second on a 300 Mhz. Alpha...), yet I still seem to end up looking at CLBs
and checking prop delays and doing the low level mapping so I can get this 1
critical piece of the design to work.



Article: 12652
Subject: 6th Reconfigurable Architectures Workshop (RAW '99)
From: Kiran Bond <kiran@usc.edu>
Date: Wed, 21 Oct 1998 23:41:57 -0700
Links: << >>  << T >>  << A >>
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 
            C A L L   F O R   P A R T I C I P A T I O N
 
         6th Reconfigurable Architectures Workshop (RAW '99) 
                April 12, 1999, San Juan, Puerto Rico
                     http://maarc.usc.edu/~raw99
 
                    to be held in conjunction with 
     13th International Parallel Processing Symposium (IPPS '99) 
 and 10th Symposium on Parallel and Distributed Processing (SPDP '99) 
    (Sponsored by IEEE Technical Committee on Parallel Processing)
                        http://www.ippsxx.org/
 
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 
The 6th Reconfigurable Architectures Workshop (RAW '99) will be held 
in San Juan, Puerto Rico on April 12, 1999. RAW '99 is associated with
the Second Merged Symposium of the 13th International Parallel
Processing
Symposium and the 10th Symposium on Parallel and Distributed Processing 
(IPPS/SPDP 1999). RAW '99 is one of the major meetings for
researchers to present ideas, results, and on-going research on both
theoretical and industrial/practical advances in Reconfigurable
Computing.
 
Goal of the Workshop: Bridging Theory and Practice
 
Advances in semiconductor and networking technologies have created
opportunities for new and effective computing paradigms. Reconfigurable 
computing is one paradigm that has been the focus of both theoretical
analysis and industrial development over the last decade. 
 
On the theoretical side, the use of configurable communication media
(e.g., a reconfigurable bus system) allowed the development of
solutions for several classes of problems with running times that
are superior to those achieved by traditional parallel models using
similar resources. A large body of knowledge has been generated as a
result of this research. 
 
On the industrial/practical side, devices and systems that support
various modes of reconfiguration (e.g., custom, dynamic, and
self-configurable) have been developed. Several compute intensive,
critical applications have been demonstrated on such systems. 
System design, application mapping and development of generic techniques
and tools are also currently active areas of research.
 
The need for interaction and exchange between the theoretical and the 
practical sides, which is the focus of the 6th Reconfigurable
Architectures Workshop, is more important than ever at this junction
in the development of both areas. 
 
Submitting Papers
 
Authors are invited to submit manuscripts of original unpublished 
research in all areas of reconfigurable computing (devices, systems,
algorithms, software tools and applications). The topics of
interest include, but are not limited to:
 
+ Reconfigurable Computing
  - Models
  - Algorithms and Complexity
  - Fault Tolerance Issues
+ Programmable Logic Devices and Systems
  - Architectures of Reconfigurable Systems
  - Implementations
  - Adaptable Systems
  - Evolvable Hardware 
+ Development Tools and Methods
  - High-level Development Support
  - Compilation Techniques
  - CAD Tools
+ Applications
  - Mapping of Parallel Algorithms
  - Image Processing, Arithmetic/Geometric/Graph/Randomized Algorithms
  - Industrial Applications and Experiences
 
A panel on "The Future of Reconfigurable Computing: Issues and
Non-Issues"
will be chaired by Ranga R. Vemuri, University of Cincinnati (USA).
 
Submission Guidelines
 
Authors should submit an electronic version of their work for
review to "hossam@cs.newcastle.edu.au". All manuscripts will be
reviewed. Submissions may be a  summary of the work or a complete
manuscript (not to exceed 10 pages of single spaced text, including
figures and tables). Submissions should be in Postscript (level 2)
format. Authors should make sure that  the submission can be viewed
using ghostscript and will print on a Postscript printer that uses
standard letter size paper(8.5" x 11"). Submissions must be received
by October 30, 1998. 
 
The workshop proceedings will be published by Springer Verlag as part
of their Lecture Notes in Computer Science Series, and they will also
appear in the CD-ROM version of the IPPS/SPDP '99 Proceedings. 
 
Important Dates
 
- Manuscript due October 30, 1998.
- Notification of acceptance or rejection due December 15, 1998.
- Final version due January 31, 1999.
 
Workshop Chair: Viktor K. Prasanna, University of Southern California
(USA)
                                    prasanna@ganges.usc.edu
 
Program Chair: Hossam ElGindy, University of Newcastle (Australia)
                                   hossam@cs.newcastle.edu.au  
 
Hossam ElGindy
Dept. of Electrical and Computer Engineering
The University of Newcastle
Callaghan, NSW 2308
Australia
 
Program Committee
 
- Jeff Arnold, Independent Consultant (USA)
- Michael Butts, Quickturn Design Systems, Inc. (USA)
- Bernard Courtois, Laboratory TIMA, Grenoble (France)
- Carl Ebeling, Univ. of Washington (USA)
- Reiner Hartenstein, Univ. of Kaiserslautern (Germany)
- Brad Hutchings, Brigham Young Univ. (USA)
- Hyoung Joong Kim, Kangwon National Univ. (Korea)
- Fabrizio Lombardi, Northeastern University (USA)
- Wayne Luk, Imperial College  (UK)
- Patrick Lysaght, Univ. of Strathclyde (Scotland)
- William H. Mangione-Smith, Univ. of California, Los Angeles (USA)
- Malgorzata Marek-Sadowska, Univ. of California, Santa Barbara (USA)
- Margaret Martonosi, Princeton Univ. (USA)
- John T. McHenry, National Security Agency (USA)
- Alessandro Mei, Univ. of Trento (Italy)
- Martin Middendorf, Univ. of Karlsruhe (TH) (Germany)
- George Milne, Univ. of South Australia (Australia)
- Koji Nakano, Nagoya Institute of Technology (Japan)
- Stephan Olariu, Old Dominion Univ. (USA)
- Robert Parker, Information Sciences Institute East/USC (USA)
- Jonathan Rose, Univ. of Toronto (Canada)
- Hartmut Schmeck, Univ. of Karlsruhe (TH) (Germany)
- Herman Schmit, Carnegie Mellon Univ. (USA)
- Mark Shand, Compaq Systems Research Center. (USA)
- Jerry L. Trahan, Louisiana State Univ. (USA)
- Ramachandran Vaidyanathan, Louisiana State Univ. (USA)
 
Publicity Chair: Kiran Bondalapati, University of Southern California
(USA)
                                    kiran@usc.edu
Article: 12653
Subject: state assignment & fpgas
From: "Ma. Jose Avedillo de Juan" <avedillo@imse.cnm.es>
Date: Thu, 22 Oct 1998 10:07:30 +0200
Links: << >>  << T >>  << A >>
Does anybudy know references on state assignment of FSMs for FPGA-based
implementations?. In particular, I am aware of a paper proposing a
symbol encoding with reduced dependencies for LUT FPGAs but I can not
find it.

Tnak you

Maria Jose
Article: 12654
Subject: Evaluation
From: Yves Vandervennet <yves@elmitel.ulb.ac.be>
Date: Thu, 22 Oct 1998 10:08:09 +0200
Links: << >>  << T >>  << A >>
Hi,

	I'm now exploring a sine generator based on Taylor-Mac Laurin
polynomial development of the sin(x) function. I try, of course, to
have the best coefficients for the smallest degree of the polynom. 
Does anybody know how to evaluate the size of a circuit that computes
this function ? I guess it's a problem linked to FIR filters but
the powers of x.

Thank you in advance and have the best day as possible,

Yves.
Article: 12655
Subject: Re: State machines in VHDL/Verilog
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 22 Oct 1998 10:42:15 +0100
Links: << >>  << T >>  << A >>
mench@mench.com wrote:

> It's not part of the language--it may be part of the standard
> synthesis package.  It will no doubt be part of the standard synthesis
> subset.

I also (cf Rick Collins) found that it worked with the Metamor compiler  but it
doesn't work with the Synopsis compiler supplied as part of  Xilinx Foundation
Express. Specifically if I use the code
sequence

type sm_type is (IDLE, ST1, ST2, ST3);
attribute enum_encoding : string;
attribute enum_encoding of sm_type : type is "one hot"

the FExp compiler complains of a enum_encoding mismatch . Looking at the manual I
found that it expects a string of N  space separated binary values where N = number
of states in sm_type. In this case N=4 and "one hot" has only 2 values.  [93 vs 87
difference ?]

Looking further I found that the State definitions had to be of the form xxxx where
each x could be one of:

0,1 : obvious
D    : Don't care
X    : Unknown.

with the proviso that any value with an `X' in it will compare FALSE to any vector.
Great I thought I'll just define my state encoding as "1DDD D1DD DD1D DDD1".  I ran
the compiler again and this time I got a warning that comparisons with `D's' in them
are ALSO taken as always FALSE. This is WRONG.

After a lot of searching I finally found they'd hidden the correct one-hot
optimisation on the  'options' menu of the $&^%"! GUI - even less portable than the
enum_encoding trick above. In fact its worse since the GUI flag is global so you have
to use the enum stuff anyway for those SMs you want binary encoded.

Anybody familiar with FPGA/Foundation Express care to comment. I suspect I could find
some answers to this on the Synopsis web site but, as an indirect customer, I'm not
allowed into the help section but have to go via Xilinx.





Article: 12656
Subject: Re: State machines in VHDL/Verilog
From: ems@riverside-machines.com.NOSPAM
Date: Thu, 22 Oct 1998 10:34:15 GMT
Links: << >>  << T >>  << A >>
On 21 Oct 1998 16:17:12 GMT, mench@mench.com wrote:

>Rickman <spamgoeshere4@yahoo.com> wrote:
>> Rick Filipkiewicz wrote:
>>> Rickman wrote:
>>> > > >     attribute enum_encoding : string;
>>> > > >     attribute enum_encoding of StateType : type is "one hot";
<snipped>
>>> What I was asking is what can you do WITHIN the
>>> language spec. if the  ``one hot'' attribute statements are rejected or ignored
>>> by the compiler/synthesiser. Maybe all known synthesisers DO accept this
>>> construction ?  I'll try it with Metamor (VHDL-93) & Synopsis (VHDL-87).
>> I don't know if the attribute "one hot" is part of the standard or not.
>> Maybe Paul could help us here. 
>
>It's not part of the language--it may be part of the standard
>synthesis package.  It will no doubt be part of the standard synthesis
>subset.

it's not actually in 1076.6 either (i presume this is what you mean by
the standard synthesis subset). 1076.6 does allow enum_encoding, but
you can't explicitly specify "one hot"; you have to manually specify
your state codings.

i imagine that almost all synthesisers allow some way to specify a
one-hot encoding, but the syntax does vary. exemplar's version is:

-- declarations not needed if exemplar_1164 package is used
type encoding_style is (BINARY, ONEHOT, GRAY, RANDOM);
attribute TYPE_ENCODING_STYLE: encoding_style;

type my_state_type is (...);
attribute TYPE_ENCODING_STYLE of my_state_type:type is ONEHOT;

however, there *is* one mechanism that doesn't rely on a user-defined
attribute. if the synthesiser is clever enough, it will look through
your state encodings, and realise that you're trying to generate a
one-hot machine, and so will automatically do this for you (ie. it
needs nothing more than the line:
attribute ENUM_ENCODING of MY_TYPE:type is "100 010 001", or
whatever).

i believe than synplicity does this, but i don't know of anyone else
who does.

evan

Article: 12657
Subject: Re: Schematic entry?
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Thu, 22 Oct 1998 06:47:45 -0400
Links: << >>  << T >>  << A >>
Well said.  I too have been monitoring synthesis with an eye toward whether it
will let me do the job.  So, far it still doesn't really give me the control I
need in many of my designs.  It has however improved a bunch over the past year
or so, with Leonardo Spectrum and Synplicity both becoming almost good enough.
Now as far as choice goes once I have the control I want in an HDL...it depends
on what I am doing.  I find data path stuff easier to do and to follow in
schematic form provided the schematics are done in such a way that changing
widths is relatively painless, at least in the upper levels of the heirarchy.
There are other things like controls and lower level sections of data path logic
that are often better expressed in an HDL.

ram wrote:

--
-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: 12658
Subject: Re: Evaluation
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Thu, 22 Oct 1998 06:57:51 -0400
Links: << >>  << T >>  << A >>
A different approach, that I believe will reduce the gate count is to use
a direct digital synthesizer and a CORDIC rotator.  The DDS generates
phase angle information at the frequency set by the phase increment.
That phase information is fed to the phase input of a CORDIC rotator in
the rotation mode.  The CORDIC magnitude input is set at the desired
amplitude (reduced by the CORDIC gain).  As outputs, you get a quadrature
(sin & cos) sinusoid, whose amplitude can be modulated by changing the
magnitude input (ie no extra hardware), and whose phase/frequency is
easily modulated by changing the DDS pahse increment.  The vector
magnitude at the output is exact, less an accumulated truncation error of
approx (log(i)) where i is the number of iterations, and with a phase
accuracy dependent on the number of iterations.  I've built CORDIC based
NCOs in FPGAs that run in the 70M samples range in a -1 xilinx.  For an
introduction to CORDIC and some hints at implementation in an FPGA you
might obtain a copy of my CORDIC survey paper from my website.  If you
look under the DSP/CORDIC page, you will also find a link to an on-line
CORDIC bibliography.

Yves Vandervennet wrote:

> Hi,
>
>         I'm now exploring a sine generator based on Taylor-Mac Laurin
> polynomial development of the sin(x) function. I try, of course, to
> have the best coefficients for the smallest degree of the polynom.
> Does anybody know how to evaluate the size of a circuit that computes
> this function ? I guess it's a problem linked to FIR filters but
> the powers of x.
>
> Thank you in advance and have the best day as possible,
>
> Yves.



--
-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: 12659
Subject: Re: Schematic entry?
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Thu, 22 Oct 1998 13:19:58 +0100
Links: << >>  << T >>  << A >>
Richard Cant wrote:

> but are the current generation of HDL's genuinely High level in the
> sense that software HLL s are?
No, as I myself said later; but....

> Speaking as a S/w person primarily
> (but with a strong h/w interest and
> involvement) current so-called highlevel HDL s are only high level in
> places; elsewhere (particularly when timing/synchronisation is
> involved)
> they seem toi me to be more comparable to assembly language  - maybe
> even microcode!

Hah! That's what softies always say when they are confronted
with explicit parallelism! :-)

yours deadlocked

Jonathan Bromley
Article: 12660
Subject: Re: state assignment & fpgas
From: "Snesarev, Victor (BNR:BNRTP:3H55)" <hw4@americasm01.nt.com>
Date: Thu, 22 Oct 1998 09:17:19 -0400
Links: << >>  << T >>  << A >>
Altera has an Application Brief (AB 131) "State Machine Encoding"

http://www.altera.com/html/literature/lf10k.html

It basically says that for architectures with lots of flip-flops use
one-hot encoding (000, 001, 010, 100) because it's register intensive,
but requires less decoding logic. For devices with lots of logic (isn't
that what LUTs are?) use binary coding state machine (sequential: 000,
001, 010, 011, 100 etc, or Gray 000, 001, 011, 0010, 0110 etc.) that
require less flip-flops, but more decode logic.

Hope this helps.

Victor

Ma. Jose Avedillo de Juan wrote:
> 
> Does anybudy know references on state assignment of FSMs for FPGA-based
> implementations?. In particular, I am aware of a paper proposing a
> symbol encoding with reduced dependencies for LUT FPGAs but I can not
> find it.
> 
> Tnak you
> 
> Maria Jose
Article: 12661
Subject: Re: State machines in VHDL/Verilog
From: mench@mench.com
Date: 22 Oct 1998 14:11:34 GMT
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM wrote:
> On 21 Oct 1998 16:17:12 GMT, mench@mench.com wrote:
>>Rickman <spamgoeshere4@yahoo.com> wrote:
>>> Rick Filipkiewicz wrote:
>>>> Rickman wrote:
>>>> > > >     attribute enum_encoding : string;
>>>> > > >     attribute enum_encoding of StateType : type is "one hot";
> <snipped>
>>>> What I was asking is what can you do WITHIN the
>>>> language spec. if the  ``one hot'' attribute statements are rejected or ignored
>>>> by the compiler/synthesiser. Maybe all known synthesisers DO accept this
>>>> construction ?  I'll try it with Metamor (VHDL-93) & Synopsis (VHDL-87).
>>> I don't know if the attribute "one hot" is part of the standard or not.
>>> Maybe Paul could help us here. 
>>
>>It's not part of the language--it may be part of the standard
>>synthesis package.  It will no doubt be part of the standard synthesis
>>subset.

> it's not actually in 1076.6 either (i presume this is what you mean by
> the standard synthesis subset). 1076.6 does allow enum_encoding, but
> you can't explicitly specify "one hot"; you have to manually specify
> your state codings.

I was actually trying to fuzz.  I didn't necessarily mean 1076.6, Level 0.
I was trying to include the (upcoming) Levels 1 and 2.

Paul

-- 
Paul Menchini          | mench@mench.com | "Se tu sarai solo,
Menchini & Associates  | www.mench.com   |  tu sarai tutto tuo."
P.O. Box 71767         | 919-479-1670[v] |   -- Leonardo Da Vinci
Durham, NC  27722-1767 | 919-479-1671[f] |
Article: 12662
Subject: Re: Schematic entry?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 22 Oct 1998 10:40:28 -0400
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> Well said.  I too have been monitoring synthesis with an eye toward whether it
> will let me do the job.  So, far it still doesn't really give me the control I
> need in many of my designs.  It has however improved a bunch over the past year
> or so, with Leonardo Spectrum and Synplicity both becoming almost good enough.
> Now as far as choice goes once I have the control I want in an HDL...it depends
> on what I am doing.  I find data path stuff easier to do and to follow in
> schematic form provided the schematics are done in such a way that changing
> widths is relatively painless, at least in the upper levels of the heirarchy.
> There are other things like controls and lower level sections of data path logic
> that are often better expressed in an HDL.
> 
> ram wrote:

I have been sitting on the sidelines watching most of this debate and
thinking about my recent experience with VHDL. I found that I agreed a
lot with both sides, but couldn't quite agree totally with anyone. Then
I realized why.

VHDL (as any other HDL) does remove you from having complete control
over which gate is used where. Schematic seems to give you that control.
But that is an illusion in both cases. 

In VHDL I completely control where FFs are generated because I know
exactly the code that creates them. I choose to create a FF consciously
by writing the VHDL code to produce it (or a whole bunch of them as in a
register). 

The random logic (combinatorial) is then specified by various high level
forms which allow me to think about the problem at hand and not the
implementation. However, I am never completly sure how this will be
implemented. So I dig into the implementation a few times until I learn
the personality of my tool. Then I have learned a few rules about how my
tools work and I can be quite expressive in my coding without being
unsure about my implementation. 

So now I have a tool that allow me to concentrate mainly on the higher
level constructs of my design while still having ENOUGH control over
implementation for MOST purposes. 

On the other hand the perfect design control from schematics is somewhat
illusory. If you are designing a Xilinx FPGA for example, you can place
all the gates you wish. But these gates have to be mapped into 4 input
function generators. The Xilinx backend tools will "optimize" your
design and then partition it into LUTs so that what you end up with will
only resemble your schematic in a functional way. You still can't
control the mapping and optimization without a great deal of work using
F-MAP elements and KEEP attibutes. In all but the MOST speed or space
critical designs this is not warrented or practical. 

I remember when I started using Xilinx tools I was very frustrated with
the poor job the tools did mapping my design to LUTs. So I made a logic
block which was a 4 input LUT with a parameter to define the logic
inside. Then I could acutally design my logic with 4 input LUTs. No one
else thought this was a good idea and Viewlogic even dropped the feature
which made this possible. It may have made for a great deal of control
over my design implementation, but it also required a lot of work to do
my own mapping. 

So I currently design with a combination of schematic and VHDL using
each where I feel it will allow me to do the best and fasted job of
optimal design. But I feel it would be a rare case where I would need to
use strictly schematic. It would also be unusual for me to do the entire
design in VHDL. 

Sorry for the long post.


-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 12663
Subject: Re: State machines in VHDL/Verilog
From: ems@riverside-machines.com.NOSPAM
Date: Thu, 22 Oct 1998 18:25:49 GMT
Links: << >>  << T >>  << A >>
On Thu, 22 Oct 1998 10:42:15 +0100, Rick Filipkiewicz
<rick@algor.co.uk> wrote:

>mench@mench.com wrote:
>
>> It's not part of the language--it may be part of the standard
>> synthesis package.  It will no doubt be part of the standard synthesis
>> subset.
>
>I also (cf Rick Collins) found that it worked with the Metamor compiler  but it
>doesn't work with the Synopsis compiler supplied as part of  Xilinx Foundation
>Express. Specifically if I use the code
>sequence
>
>type sm_type is (IDLE, ST1, ST2, ST3);
>attribute enum_encoding : string;
>attribute enum_encoding of sm_type : type is "one hot"

FPGA express doesn't seem to be particularly good at this. it does
have a one-hot attribute, but you have to specify a *list* of signals,
when you know that only one of the signals will be active at a given
time (you can also specify one-cold, when you know that only one
signal is 0 at a given time). example:

use synopsys.attributes.all;
-- attribute one_hot: string;   -- in package 'attributes'

attribute one_hot of red, green, blue: signal is "true";

this will allow combinatorial logic on red, green, and blue to be
simplified appropriately. there doesn't seem to be any way to specify
one hot on a *single* signal of an enumerated type. in principle, you
could explicitly list all the signals in your state register, instead
of using an enumerated type, but i haven't tried this (and i suspect
that it won't work - it should be in the documentation if it does
work).

> the FExp compiler complains of a enum_encoding mismatch . Looking at the manual I
> found that it expects a string of N  space separated binary values where N = number
> of states in sm_type. In this case N=4 and "one hot" has only 2 values.  [93 vs 87
> difference ?]

this isn't an 87/93 issue - enum_encoding and one_hot, if they exist,
are user-defined attributes, and it just happens that synopsys doesn't
recognise "one hot" as part of its enum_encoding scheme.

evan

Article: 12664
Subject: Re: State machines in VHDL/Verilog
From: "Steve Kerman" <nospam@nospam.com>
Date: Thu, 22 Oct 1998 18:42:50 GMT
Links: << >>  << T >>  << A >>
There is a portable way to do one-hot encoding.  It sounds ugly, but
actually works out really well--just declare a single flop for each state.

Here's an example.  (Note that the starting state, State1, is coded active
LOW, the others are coded active high.  I do this because FPGAs tend to
prefer that flops be zero at startup.)


architecture rtl of StateMachine is
   signal State1, State2, State3  : std_logic;
begin

   process (reset, clk)
   begin

      -- Sequential part

      if State1 = '0' then
         -- Outputs in state 1
      end if;

      if State2 = '1' then
         -- Outputs in state 2
      end if;

      if State3 = '1' then
         -- Outputs in state 3
      end if;

      -- Clocked part

      if Reset = '1' then
         State1 <= '0';
         State2 <= '0';
         State3 <= '0';
      elsif clk'event and clk = '1' then

         if (Expression describing transition to State1)
            or (State1 = '0' and not (Expression describing exit from
State1))
         then
            State1 <= '0'
         else
            State1 <= '1';
         end if;

         if (Expression describing transition to State2)
            or (State2 = '1' and not (Expression describing exit from
State2))
         then
            State2 <= '1'
         else
            State2 <= '0';
         end if;

         if (Expression describing transition to State3)
            or (State3 = '1' and not (Expression describing exit from
State3))
         then
            State3 <= '1'
         else
            State3 <= '0';
         end if;
      end if;
   end process;
end;


In practice, the state transition expressions tend to be much simpler than
in the general example.  For instance, in most of my state machines, most
of the states happen sequentially -- i.e., State1 is the idle state, State2
is entered by a "Start" signal, and State3 immediately follows State2.  In
this case, the transition code is simply:

         State1 <= not (State3 or (not State1 and Start));
         State2 <= not State1 and Start;
         State3 <= State2;

I hope that this helps.



> >It's not part of the language--it may be part of the standard
> >synthesis package.  It will no doubt be part of the standard synthesis
> >subset.
> 
> it's not actually in 1076.6 either (i presume this is what you mean by
> the standard synthesis subset). 1076.6 does allow enum_encoding, but
> you can't explicitly specify "one hot"; you have to manually specify
> your state codings.
> 
> i imagine that almost all synthesisers allow some way to specify a
> one-hot encoding, but the syntax does vary. exemplar's version is:

Article: 12665
Subject: Re: Digital Sine Generator
From: Hagen Ploog <hp@e-technik.uni-rostock.de>
Date: Thu, 22 Oct 1998 21:24:07 +0200
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

> Depends on the desired phase resolution and magnitude accuracy.  For
> small numbers of phase angles (<32) when only sin or cos (not both) are
> needed, use the LUT approach.  Otherwise, use a CORDIC rotator.   You
> will want to read my FPGA'98 paper entitled "A survey of CORDIC
> algorithms for FPGA based computers", which you can obtain from my
> website.  One of the designs discussed in the paper simultaneously
> generates 12 bit sines and cosines at 50M samples/sec in a 4013E-2.  The
> CORDIC design also gives you the capability to amplitude modulate the
> sin/cos outputs for free.  The size of a CORDIC rotator is about the
> same as a multiplier with as many bits.  I've done numerous CORDIC
> designs in Xilinx, Altera and Atmel FPGAs.
>
> The newest paper on my web-site, "An FPGA based processor yields a real
> time high fidelity radar environment  simulator", shows a CORDIC rotator
> used as a complex NCO with amplitude and phase modulation.
>

Some of my students build a sine-wave generator design that uses LUT's (256
points, 8b width) , it's run with about 160 MHz (4010XL-3).
The problem we got so far is pad-speed-limitation. So my guess is, LUT-based

solutions are the fastes around. If you do have enough CLBs, why bother with
slow-mode designs?
Hagen


Article: 12666
Subject: Re: I2C Core
From: Hagen Ploog <hp@e-technik.uni-rostock.de>
Date: Thu, 22 Oct 1998 21:37:21 +0200
Links: << >>  << T >>  << A >>


madaan@my-dejanews.com wrote:

> Hi,
> I am working on a I2C synthesizable core, simulation models and bus monitor in
> verilog. Anyone aware of any shareware/freeware source (preferably in verilog)
> or other related stuff at any site then please let me know.
>
> --
> Ashok Madaan
>

I2C is very easy (about 20 CLBs) to implement as long as you don't care about
possible erros (spike, glitches..., timeouts).
Things getting worser if you start detecting erros.
Some things to remind:
 - oversampling
 - synchronizing
 - edge-detection
 - low-pass-filtering (if you dont't want glitches)
 - 3-state output vs. 3 outputs
 - interrupt generation
 - ....

Implementing these options makes the design more complex, so if
one is given away his i2c-model for free, look what you realy got!!
We have (of course) build a i2c-model which detect nearby the most of the
thinkable erros. You can enable most of the feature, depending on if you want a
small (but insecure) or a bigger design.

Hagen

Article: 12667
Subject: Re: Processor Cores
From: Hagen Ploog <hp@e-technik.uni-rostock.de>
Date: Thu, 22 Oct 1998 21:43:10 +0200
Links: << >>  << T >>  << A >>
*Very small* 4bit controller at:

http://www-md.e-technik.uni-rostock.de/forschung/run4/index.html

Hagen

Article: 12668
Subject: Re: DES in FPGA
From: Hagen Ploog <hp@e-technik.uni-rostock.de>
Date: Thu, 22 Oct 1998 22:03:47 +0200
Links: << >>  << T >>  << A >>

Christof Paar wrote:

<snip>

>
> Check also Jens-Peter Kaps' MS thesis which is on the web too.

Hmmm, just a abstract mayby you can mail me the thesis..
Hagen

Article: 12669
Subject: Need VHDL tools for Win NT/ Win 95
From: "ovilup" <ovilup@hotmail.com>
Date: 22 Oct 1998 20:58:25 GMT
Links: << >>  << T >>  << A >>
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: 12670
Subject: Re: Schematic entry?
From: Richard Cant <richard@timezznospamzzhigh.demon.co.uk>
Date: Thu, 22 Oct 1998 22:50:33 +0100
Links: << >>  << T >>  << A >>
In article <362F22EE.4856D7D6@brookes.ac.uk>, Jonathan Bromley
<jsebromley@brookes.ac.uk> writes
>No, as I myself said later; but....
>
>> Speaking as a S/w person primarily
>> (but with a strong h/w interest and
>> involvement) current so-called highlevel HDL s are only high level in
>> places; elsewhere (particularly when timing/synchronisation is
>> involved)
>> they seem toi me to be more comparable to assembly language  - maybe
>> even microcode!
>
>Hah! That's what softies always say when they are confronted
>with explicit parallelism! :-)

Explicit parallelism is inherently low level - what we need is Implicit
parallelism!? :-)

Seriously though it is not the parallelism which makes it low level  -
but rather the way in which timing is handled.
-- 
Richard Cant
Article: 12671
Subject: Re: Schematic entry?
From: msimon@tefbbs.com
Date: Thu, 22 Oct 1998 22:13:26 GMT
Links: << >>  << T >>  << A >>
People have been doing source control of dwgs for at least a hundred
years (that I know of). No reason we can't do it with schematic files.

Do it all the time for PC Boards. (No paper changes hands except for
the check).

Simon
===================================================================================
Rick Filipkiewicz <rick@algor.co.uk> wrote:

>Watching this seemingly eternal schematics vs. HDL argument I find myself,
>typically, agreeing with both sides. Schematics for their intuitive  nature,
>at least for datapath stuff - state machines are more problematic. HDL for
>speed of  writing & modifying  random logic. What wins it for me is that the
>text nature of HDLs make them amenable to source code revision control,
>difficult or impossible with schematics [Correct me if I'm wrong here]. Also
>, using lots of instantiation, you can treat HDLs as text based schematics
>but the reverse process is awkward.
>
>

Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htm
Article: 12672
Subject: Re: Schematic entry?
From: msimon@tefbbs.com
Date: Thu, 22 Oct 1998 22:29:19 GMT
Links: << >>  << T >>  << A >>
I think if you design a chip optimised to a specific language (I am a
stack machine/FORTH fan) you can get compiler gains. (You allude to
this).

I think that the future of computing is chips optimised for languages.

This is somewhat true now. With FPGAs to experiment with it will
become very true in the future(2-3 years).

Lisp chips, FORTH chips, Java chips, C chips, etc. With RAM based
FPGAs its a new chip every second (more or less).

Simon - see my sig at the bottom for processor design tools
===========================================================

Richard Cant <richard@timezznospamzzhigh.demon.co.uk> wrote:

>In article <362DB291.164EDD5@brookes.ac.uk>, Jonathan Bromley
><jsebromley@brookes.ac.uk> writes
>>John L. Smith wrote:
>>> Even SMs can be drawn clearly and in an easy to follow mannerwith a schematic,
>>> at least one-hots.
>><snip interesting stuff about making schematics look like state
>>diagrams>
>>> 
>>> Portability --> HDL
>>> Performance --> Schematic
>>
>>Whilst I generally agree with most of what has been said, I can't fully 
>>accept the "performance->schematic" axiom.  People used to say much the
>>same about high-level languages and compilers.  But then two things
>>happened:
>>(1) compilers got better at optimisation (much better!)
>
>>(2) folk began to recognise that the freedom of expression inherent in
>>    a high level language allowed them to implement sophisticated but 
>>    hard-to-understand optimisations at a much higher level of
>>abstraction
>
>That is a commonly held belief but IMHO  it is an over simplification,
>what actually happened was - 
>
>1) The underlying processors had facilities added to aid the efficiency
>of high level languages - things like h/w stacks, frame pointers etc
>etc
>
>2) Language design itself got better making good compilers easier to
>write and (more especially) easier to use. This is what made your (2)
>possible. Fortran 1 is actually little better than assembler for coding
>complex algorithms.
>
>Actually compilers still aren't that good at optimisation as such, but
>the task has been made easier (or maybe less necessary) by changes in
>their "operating environment". Many so called optimisations made by
>current compilers are essentially get arounds for architectural features
>like delayed branches that have themselves been added in the knowledge
>that the compiler could handle them!
>
>
>>For example:  If you are searching a table and the only way you know how
>>is
>>to do a linear search, then assembler will win over a high-level
>>language
>>any day.  But have you ever tried doing a hash table in assembler?  Or
>>a balanced binary tree?  OK, it's possible, but using a HLL you get all
>>the
>>inherent performance improvement (some orders of magnitude, in some
>>cases)
>>of the more sophisticated technique, **with minimal risk of erroneous
>>code**,
>>whilst suffering only the ???20% performance hit of HLL-vs-assembler for
>>the comparable algorithm.
>
>Only if you use a suitable HLL and most early HLL s weren't much good at
>those kinds of task.
>>
>>Bottom line:
>>The performance gain from using the right algorithm is often hugely
>>greater
>>than the performance gain from using an optimal implementation method.
>
>True
>>If the right algorithm is hard to understand or difficult to implement,
>>you
>>are more likely to get it right by using the highest-level tools at your
>>disposal.  The performance cost of using such tools will be
>>insignificant.
>
>but are the current generation of HDL's genuinely High level in the
>sense that software HLL s are?
>
>Speaking as a S/w person primarily  (but with a strong h/w interest and
>involvement) current so-called highlevel HDL s are only high level in
>places elsewhere (particularly when timing/synchronisation is involved)
>they seem toi me to be more comparable to assembly language  - maybe
>even microcode!
>
>>
>>Improvement (1) is just about beginning to happen (slowly) with HDLs.
>
>but does the FPGA cell design need to be bent to the requirements of
>HDL's? (I'm working by analogy here - but I would be interested to know
>if anyone has a "hard" answer to this question)
>>Improvement (2) is really waiting for mainstream acceptance of higher
>>levels of abstraction than RTL, so that we can code useful algorithms
>>in our hardware. 
>
>Yes!
>
>> Meanwhile, we are still fiddling around just like the
>>early compiler users:  the good designers will exploit HDL for its
>>portability and parameterisability, whilst learning how to write HDL
>>code
>>that's synthesis-friendly so the performance stays OK.  Mediocre
>>designers will go on getting sub-optimal results as usual.  And no, I
>>don't know with any precision where I fall on that spectrum of 
>>design competence:-)
>
>Same as programmers! :)
>
>-- 
>Richard Cant

Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htm
Article: 12673
Subject: Re: Schematic entry?
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Thu, 22 Oct 1998 19:24:23 -0400
Links: << >>  << T >>  << A >>


Rickman wrote:

> The random logic (combinatorial) is then specified by various high level
> forms which allow me to think about the problem at hand and not the
> implementation. However, I am never completly sure how this will be
> implemented. So I dig into the implementation a few times until I learn
> the personality of my tool. Then I have learned a few rules about how my
> tools work and I can be quite expressive in my coding without being
> unsure about my implementation.

Until the next version is introduced and has subtle differences in the way it compiles
the design.

>
>
> On the other hand the perfect design control from schematics is somewhat
> illusory. If you are designing a Xilinx FPGA for example, you can place
> all the gates you wish. But these gates have to be mapped into 4 input
> function generators. The Xilinx backend tools will "optimize" your
> design and then partition it into LUTs so that what you end up with will
> only resemble your schematic in a functional way. You still can't
> control the mapping and optimization without a great deal of work using
> F-MAP elements and KEEP attibutes. In all but the MOST speed or space
> critical designs this is not warrented or practical.

My schematics are highly hierarchical, with the lowest level of many arithmetic
elements being either one or two bit slices.  Those slices are where the fmaps are.
Since I already have a library of those parts, I rarely need to add fmaps to the
design (I do need RLOCs, but that's a no-brainer).  This gives me a hierarchical
design consisting of relatively placed macros which are optimized at the low levels.
I know when I plunk these down that the logic will be implemented the way I intended
without having to go in again and place fmaps.  Even in cases where I don't already
have a 1 or 2bit slice, it is trivial to create the slice and fmap it (usually no more
than two fmaps).  I rather suspect that I am getting more design reuse than many of
the HDL proponents out there.

-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: 12674
Subject: Re: State machines in VHDL/Verilog
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 22 Oct 1998 21:45:38 -0400
Links: << >>  << T >>  << A >>
Steve Kerman wrote:
> 
> There is a portable way to do one-hot encoding.  It sounds ugly, but
> actually works out really well--just declare a single flop for each state.
> 
> Here's an example.  (Note that the starting state, State1, is coded active
> LOW, the others are coded active high.  I do this because FPGAs tend to
> prefer that flops be zero at startup.)
> 
> architecture rtl of StateMachine is
>    signal State1, State2, State3  : std_logic;
> begin
> 
>    process (reset, clk)
>    begin
> 
>       -- Sequential part
> 
>       if State1 = '0' then
>          -- Outputs in state 1
>       end if;
> 
>       if State2 = '1' then
>          -- Outputs in state 2
>       end if;
> 
>       if State3 = '1' then
>          -- Outputs in state 3
>       end if;
> 
>       -- Clocked part
> 
>       if Reset = '1' then
>          State1 <= '0';
>          State2 <= '0';
>          State3 <= '0';
>       elsif clk'event and clk = '1' then
> 
>          if (Expression describing transition to State1)
>             or (State1 = '0' and not (Expression describing exit from
> State1))
...snip...
>          then
>             State3 <= '1'
>          else
>             State3 <= '0';
>          end if;
>       end if;
>    end process;
> end;
> 
> In practice, the state transition expressions tend to be much simpler than
> in the general example.  For instance, in most of my state machines, most
> of the states happen sequentially -- i.e., State1 is the idle state, State2
> is entered by a "Start" signal, and State3 immediately follows State2.  In
> this case, the transition code is simply:
> 
>          State1 <= not (State3 or (not State1 and Start));
>          State2 <= not State1 and Start;
>          State3 <= State2;
> 
> I hope that this helps.

I thought of this, but never tried it. This is indeed hard coded and is
not easy to modify if you change your mind about your encoding method.
The case statement method with an atribute defining the encoding type is
much more flexible. A couple of my state machines in the design I just
built could have gone over to being better in binary encoding if they
had changed just a little more than they did during debug. Or it may be
more likely that you would change from binary to onehot encoding in many
cases where a state machine grows during debug. 

The amount of logic in a onehot machine depends on the number of states
and inputs feeding into each state. Also each state has separate logic
feeding it. In a binary encoded machine, the amount of logic depends on
the number of bits in the encoded state and the number of inputs total.
But there are fewer state bits than there are states in the onehot
machine. So if you have a state like an IDLE state which many states
feed into, plus many control inputs governing the output transistions,
you can end up with a very complex set of logic that may well be bigger
and slower than that of a binary state machine. So if the design changes
during debug, you may want to change your encoding style. 

Of course there may be alternatives to changing your encoding style. For
example the above worst case situation happened to me and I fixed it by
adding a final dummy state which all of the previous end states fed.
This dummy end state contained the complexity of the many states feeding
it. The true IDLE state then only had a single state feeding it and
could deal more easily with the complexity of the control inputs. Some
of these inputs were from IO pins and had very long delays. So the speed
of this circuit was critical. This worked out very well. But I am glad I
did it in VHDL. Making all the changes in schematic would have been much
slower than the typing I did, but then that is another discussion. ;^)


-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.


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