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

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

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

Custom Search

Messages from 12600

Article: 12600
Subject: Re: Schematic entry?
From: "Gareth Baron" <Gareth.Baron@eng.efi.com>
Date: Mon, 19 Oct 1998 13:40:31 -0700
Links: << >>  << T >>  << A >>
I think you have hit the nail on the head with this comment.

If you have a lot of resources free then HDL is the way to go as you get
fast turnaround.

If you want optimum density/speed Schematics are the way to go.


I would suspect that Xilinx and the other FPGA companies are basing thier
decisions on the "must get it out quick" attitude, as who could possibly
hand craft a 2 Million Gate FPGA (Virtex in the future) ?

IMO, this should not be their decision but should be their customers'.  This
is the only way I see a good balance of designs.  On one hand it's the quick
and dirty approach (fast turnaround and market presence) and on the other
it's the long and windy approach (hand craft and optimize until you use
95-100% of the device).

HDL's can be good at algorithmic stuff when you want to check whether a
principle works or you have a load of resources available on the FPGA (you
can get fair speeds out of this) but if you really need to hand-craft to get
high-speed and efficient density, then Schematics is probably a favourable
solution.


Another reason for FPGA's Vendors using HDL is that traditionally HDLs are
used for ASIC design and as far as the FPGA vendors are concerned, they are
in the ASIC market with large density FPGAs (which is probably quite true
now).  With this in mind, getting a product to market in a timely fashion is
a bigger requirement than optimizing a design by hand-crafting.


-------------------
Gareth Baron




Article: 12601
Subject: Re: Library of boards
From: Richard Cant <richard@timezznospamzzhigh.demon.co.uk>
Date: Mon, 19 Oct 1998 23:45:34 +0100
Links: << >>  << T >>  << A >>
In article <705c56$ba3@masters0.InterNex.Net>, Gareth Baron
<Gareth.Baron@eng.efi.com> writes
>For fairly low tech. apps Programmable hardware is definitely a viable
>solution.  The problem is that if the quantities are large then ASIC is
>difintely worth it as FPGAs (especially large densities) are quite
>expensive.
>
>When prices come down on the FPGA front (>1M gates) this is definitely one
>of my "want's".  Again this may be, as you say, a pipedream as the ASIC
>densities will go up as well.

As things get bigger the FPGA will begin to look relatively better
because the ASIC has to go through a design cycle whereas the FPGA will
just need programming(?!) once the base chip is available.

The other advantage the FPGA has is that it can be reprogrammed in the
field for several different functions.
-- 
Richard Cant
Article: 12602
Subject: Re: optimized fpga
From: "Austin Franklin" <darkroo3m@ix.netcom.com>
Date: 20 Oct 1998 00:17:21 GMT
Links: << >>  << T >>  << A >>
..... you need to massage the (VHDL) code so
> that it generates the logic you already know would be an efficient
> implementation.  

Don't you mean 'guess at what implementation would generate...'?

Austin 

P.S.  Ray, you responded so well....I was tempted, but I just wouldn't have
said it like you did...

Article: 12603
Subject: Re: More: What's wrong at this Address decoder?
From: leslie.yip@asmpt.com
Date: Tue, 20 Oct 1998 01:09:05 GMT
Links: << >>  << T >>  << A >>
Dear William

Yes. it actually uses address bits [19:11]. They are enough to decode such
values. I found Cypress Synthsizer Warp can do it. (See the book "VHDL for
Programmable Logic" by Kevin Skahill of Cypress Semiconductor, pp.181) It
also can be done in very old PAL/GAL devices' compiler like CUPL. I used to
do this in designing the ISA AT bus cards to decode the bus address I/O read,
write and memory read/write.


-----------------------------------------------------------------------
In article <362B7475.2D475875@hti.com>,
  William <wlhunterjr@hti.com> wrote:
> Could it be that ADDR is defined to be only 9 bits and you are comparing it
against
> 20 bits.
>
> leslie.yip@asmpt.com wrote:
>
> > Hello Everybody
> >
> > I think that this is technology-declining that ViewLogic can't know how to
> > synthesize the code. In the past time, (ten or more years ago) the CUPL can
> > synthesize it into P22V10 or 16V8 PAL/GAL devices. I can't understand how
> > ViewLogic can't know that.
> >
> > The synthesized result should be similar to that as follows:
> >
> > -- Mem_dec.vhd
> >
> > library ieee;
> > use ieee.std_logic_1164.all;
> > use ieee.std_logic_unsigned.all;
> >
> > Entity MEM_DEC is
> >   port( ADDR:                   in              std_logic_vector(19 downto
11);
> >         NMEMR,NMEMW:            in              std_logic;
> > --        NRST:                 in              std_logic;
> >         RAMCE:                  out             std_logic;
> >         DPRA,DPRB:              out             std_logic);
> > end MEM_DEC;
> >
> > architecture MEM_DEC_ARCH of MEM_DEC is
> > -- signal dint,ddint: std_logic;
> > -- signal rint,fint: std_logic;
> >
> > begin
> >
> > process(ADDR, NMEMR, NMEMW)
> > begin
> >   DPRA <= '0';
> >   DPRB <= '0';
> >   RAMCE <= '0';
> >  if NMEMR='0' or NMEMW='0' then
> >    if ADDR = "110101000" then
> >      DPRA <= '1';
> >    elsif ADDR = "110101001" then
> >      RAMCE <= '1';
> >    elsif ADDR = "110110110" then
> >      DPRB <= '1';
> >    end if;
> >  end if;
> > end process;
> >
> > end MEM_DEC_ARCH;
> >
> > ----------------------------------------------------------------
> > In article <70abgn$d38$1@news.inter.net.il>,
> >   "Ido Kleinman" <kleinn@REMOVETHIS.mail.biu.ac.il> wrote:
> > > Your VHDL code is alright and would compile nicely under Active-VHDL (from
> > > Aldec).
> > > I am pretty sure that Aurora doesn't know to interpret constant
bit_vectors
> > > in the format x"D400". I've already encountered some
compiliers/synthesizers
> > > which can only accept binary based constant vectors such as
> > > "1101010000000000".. Try removing that x prefix and changing the radix of
> > > the comparison.
> > >
> > > --
> > >
> > > Yours,
> > >
> > >   - Ido Kleinman.
> > >   kleinn@REMOVETHIS.mail.biu.ac.il
> > >
> > >  ** Please delete the "REMOVETHIS."
> > >  ** substring to EMail me.
> > >
> > > leslie.yip@asmpt.com wrote in message <706oci$9uo$1@nnrp1.dejanews.com>...
> > > >Hello Everybody,
> > > >
> > > >I would like to know what is worng with the ViewLogic's Synthesizer
> > > "Aurora"
> > > >to interpret the following code.
> > > >
> > > >The error message is as follows:
> > > >
> > > >The following is a list of the navigable error/warning messages in the
> > > >preceding run. Double clicking on a message will bring up the Viewer with
> > > the
> > > >cursor positioned at the offending line of code. VHDL: Error:
> > > >d:\vhdl_mfb3\mem_dec\mem_dec.vhd, line 28:   impossible to determine the
> > > type
> > > >of this parameter VHDL: Error: d:\vhdl_mfb3\mem_dec\mem_dec.vhd, line 30:
> > > > impossible to determine the type of this parameter VHDL: Error:
> > > >d:\vhdl_mfb3\mem_dec\mem_dec.vhd, line 32: impossible to determine the
> > > >type of this parameter End navigable error/warning messages.
> > > >
> > >
> > >
> >
> > The code:
> > --------
> >
> > -- Leslie Yip, ASM;     Jun, 8, 1998
> > -- Mem_dec.vhd
> >
> > library ieee;
> > use ieee.std_logic_1164.all;
> > use ieee.std_logic_unsigned.all;
> >
> > Entity MEM_DEC is
> >   port( ADDR:                   in              std_logic_vector(19 downto
11);
> >         NMEMR,NMEMW:            in              std_logic;
> > --        NRST:                 in              std_logic;
> >         RAMCE:                  out             std_logic;
> >         DPRA,DPRB:              out             std_logic);
> > end MEM_DEC;
> >
> > architecture MEM_DEC_ARCH of MEM_DEC is
> > -- signal dint,ddint: std_logic;
> > -- signal rint,fint: std_logic;
> >
> > begin
> >
> > process(ADDR, NMEMR, NMEMW)
> > begin
> >   DPRA <= '0';
> >   DPRB <= '0';
> >   RAMCE <= '0';
> >  if NMEMR='0' or NMEMW='0' then
> >    if ADDR >= x"D4000" and ADDR <= x"D47FF" then
> >      DPRA <= '1';
> >    elsif ADDR >= x"D4800" and ADDR <= x"D4FFF" then
> >      RAMCE <= '1';
> >    elsif ADDR >= x"DB000" and ADDR <= x"DB7FF" then
> >      DPRB <= '1';
> >    end if;
> >  end if;
> > end process;
> >
> > end MEM_DEC_ARCH;
> >
> > -----------== Posted via Deja News, The Discussion Network ==----------
> > http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
>
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 12604
Subject: Re: Schematic entry?
From: rk <stellare@NOSPAMerols.com>
Date: Mon, 19 Oct 1998 21:23:32 -0400
Links: << >>  << T >>  << A >>
Geir Harris Hedemark wrote:

> rk <stellare@NOSPAMerols.com> writes:
> > many cases HDL's are a better design option.  for pushing speed,
> > density, or power, it is simply, with today's technology, easier to
> > draw a schematic.
>
> I don't know about density or speed, but I am absolutely certain that
> doing things like clock gating with schematics is enormously (sp?)
> inefficient. Power Compiler is smart enough to do this for me.

er, clock gating in an fpga should be done very carefully and, no offense
to your power compiler, but a humanoid should be involved in that
decision.

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

> > while constraints help guide a tool, they can not replace circuit
> > architectural decisions, currently still a domain where the humans
> > have the edge over the synthesizer.
>
> If you have not put your architectural decisions into your VHDL code,
> it probably won't be synthesizable. If it is, then you have not
> written it right.
>
> If you mean what kinds of adders to use to minimize power, Synopsys
> has something called Designware. You can put your low-power carry save
> adders in there. Power Compiler will then help choose the
> implementation with the lowest power usage that still meets timing.

yes, i do mean things like adder architecture.  i'm sure i can spend a lot
of time and a lot of $ and get all of the options into the DW libraries.
do the fpga-vendor supplied libraries for synopsys dw have all of the
options in it and can out do a human?  does the engineer have to put it
in?  let's assume yes, the human has to add designware libraries.  i think
that you will find for these critical circuits the time spent messing with
the tool, the cost of the tools (er, synopsys and it's options are exactly
freeware) is rather expensive and, as the original poster pointed out, the
goals could be met easier and quicker with a schematic.  for example, i've
done some very high performance multipliers well tuned to the architecture
i was implementing them - haven't seen an architecture in the design ware
libraries to meet my requirements.  once figured out, easy to draw with a
schematic and easy to read.

please add up the cost of the software you mentioned here or implied:

    design compiler
    fpga compiler
    power compiler
    designware stuff
    training classes (just went through some at day job, not cheap, didn't
give out donuts, either).

not cheap.  and if i can do the critical sections quicker w/ a cheap
schematic too and the non-critical sections in a cheap vhdl compiler
that's a win for me.  buying all of that expensive software would, well,
push me right out of my house.

of course, there are the nice HDL tools which insist that they are smarter
than the human and disregard the instructions they are given until you:

    a) figure out what they did

    b) figure out how to over-ride the tool's decision.

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

> Better yet: Just say which adders you prefer to Design Compiler. Works
> as a charm.

easier to just write it down in a schematic.  works like a charm.  every
time.

rk

Article: 12605
Subject: Re: 100 MHz FPGA
From: Hans Christian Lonstad <Hans.Christian.Lonstad@datarespons.no>
Date: Tue, 20 Oct 1998 08:35:06 +0200
Links: << >>  << T >>  << A >>
Yves Tchapda wrote:

> Hi,
>  We are developing a high bandwidth switch architecture and we need to
> test each switch interface at maximum speed of 100MB/s, which with an
> 8-bit interface requires a clock of 100MHz. Is there any FPGA out
> there that would be able to sustain pumping data at this rate? I
> thought of using a slower clock and a 32-bit interface from the FPGA
> and then probably use a CPLD to multiplex the data to the switch 8-bit
> interface. But there are problems associated with this. Any
> suggestions?
>
> Dr Yves Tchapda
> e-mail yves@px.uk.com

The Altera FLEX10KB100 (-2,-1 speed grade) clocks comfortably in at 100
MHz, both internally and between similar devices. Note that this is a 2.5=
V
part (I/O is 2.5, 3.3 or 5V).


--
Hans Christian L=F8nstad  ^     ^              Data Respons AS
                        |   /  \__.----      Sandviksveien 26
Real Time               |  /                 1322 H=F8vik
Professionals            -------------->     Norway
mailto:Hans.Christian.Lonstad@datarespons.no
http://www.datarespons.no


Article: 12606
Subject: Re: gray code counter in a Xilinx fpga???
From: Le mer Michel <michel.lemer@ago.fr>
Date: Tue, 20 Oct 1998 10:20:52 +0200
Links: << >>  << T >>  << A >>
Ken Coffman wrote:

> The conversion from binary to Gray code is not too bad. The best solution
> might be to implement a fast binary counter, then convert the binary to
> Gray.
>
> I can post the algorithm to convert binary to Gray if necessary.
>
> If the output code is not important, and high speed with low EMI is the
> goal, perhaps a LFSR counter is the answer.
>
> What's the design goal?

What is the meaning of LFSR?

Article: 12607
Subject: Re: Where to find comp.arch.fpga newsgroup archive
From: Markus Wannemacher <markus.wannemacher@fernuni-hagen.de>
Date: Tue, 20 Oct 1998 09:44:21 +0100
Links: << >>  << T >>  << A >>
vic@alpha.podol.khmelnitskiy.ua wrote:
> 

http://www.fernuni-hagen.de/IT/FPGA/news

Archiv starting February 1997

Markus


Article: 12608
Subject: Re: Schematic entry?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 20 Oct 1998 11:09:31 +0100
Links: << >>  << T >>  << A >>
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.


Article: 12609
Subject: FS: CAD & SW DEV
From: rbrooks1@my-dejanews.com
Date: Tue, 20 Oct 1998 11:48:40 GMT
Links: << >>  << T >>  << A >>
For Sell by individual:

Aldec's ActiveCAD 2.2 with Altera FPGAs, PLD,
TTL, etc. libraries/models, VHDL model compiler,
Schematic Entry, System (board level)
simulation, Graphical State Machine Entry.
Keylock, and license transfer.
$1800.00 or best reasonable offer.

MINC's Synario Board Designer Version 4.11
(latest) with aprx one years maintenance
(Renewed maintenance 9-8-98), keylock
and license transfer.
$1150.00 or best reasonable offer.

Borland's Delphi Version 2.0 Professional and
C++ Version 4.5 Professional, with loads
of documentation.
$100.00 or best reasonable offer.

CUPL Multi-vender, multi-chip FPGA Designer
Software (complete FPGA, PAL, and PLD/EPLD design)
$350.00 or best reasonable offer.

TANGO Schematic entry for DOS.
$50.00.

Buyer pays shipping.

contact:  rbrooks4@gte.net

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 12610
Subject: GUI GRINDERs vs SLICK SCRIPTOs
From: Nick Gent <nickg@sqf.hp.com>
Date: Tue, 20 Oct 1998 13:38:16 +0100
Links: << >>  << T >>  << A >>
So, for design capture, simulation, and place/route do you swear by that
button-infested GUI with it's 'at-a-glance' 'ease-of-use' 
'fully-integrated-look-&-feel'..., or, do you go for the
'rocket-science' 
'light-the-blue-touch-paper-and-retire' script approach, and amaze your 
friends?

My preferences are probably obvious from the title :-)

I run everything from XEmacs (with electric-vhdl etc) and use the 
'M-x compile' feature to run scripts and quickly fix my bug-ridden
designs.
Everything is scripted, and the scripts are source-code controlled and
available for anyone to re-create/modify my design flow.

I get hot under the collar when I hear of CAE vendors 'adding value'
(increasing cost to me) by tarting up the GUI and ignoring the wishes of
us script-writers.

My message to the vendors would be: less GUIs, cheaper tools with
powerful 
scripting and plenty of script-based app notes etc.

Lets take a vote on it!

Nick.
============================================================================
Nick Gent

Telecommunications Network Test Division         
Hewlett-Packard                                  Telephone: +44 131 331
7644
South Queensferry EH30 9TG                       Fax:       +44 131 331
7488
Scotland                                         mailto:nick_gent@hp.com
============================================================================
Article: 12611
Subject: Re: Xilinx F1.5/FPGA Express wackiness
From: "Thomas D. Tessier" <tomt@hdl-design.com>
Date: Tue, 20 Oct 1998 07:03:00 -0600
Links: << >>  << T >>  << A >>
Rick wrote:
> 
> Graeme Durant wrote:
> 
> > Under Known Issues it says that the revision control mechanism only
> > handles implementation data, and that you have to manually handle
> > your source code/netlists if you want to keep them.
> 
> I think that the general theory among  FPGA EDA vendors is that source code
> revision control is for wussy s/w engineers not us hairy chested h/w types. If
> this wasn't so why haven't they included one of the free or shareware
> implementations of Unix's RCS - which   has been around for years. And while
> they're at it why don't they throw in Emacs 19 + verilog/vhdl-mode + make and
> hey presto the GUI's disappeared altogether.
> 
> Does anybody actually like the idea of having 3 GUIs to implement a Xilinx
> design via Foundation Express - the F.E. one, Project manager, Design manager ?

I love it ;-(  For my company I have developed a flow for each project
NOT using the GUI!  Why you ask, to give me flexibility to
add/remove/modify any tool in the flow.

The GUIs are a pain, but look nice at a DAC demo or for someone who only
does designs once in a "blue moon."  But herein lies the problem the
once in the "blue moon" designer has to learn a new tools set every time
because there have been so many changes.

I am thankful that the FPGA vendors have still left us the command line
back door because without that we would all have "Repetitive Stress
Syndrome" from all the mousing around the GUI requires.

Tom Tessier
-- 
+------------------------ ---------------------- ----------------------+
: t2design                                                             :
: 249 Lois Drive                                                       :
: Louisville, CO 80027                                                 :
+------------------------ ---------------------- ----------------------+
:  tomt@hdl-design.com   *  (303)665-6402       * Fax: (303)665-6431   :
+------------------------ ---------------------- ----------------------+
Article: 12612
Subject: output file format
From: Le mer Michel <michel.lemer@ago.fr>
Date: Tue, 20 Oct 1998 15:47:59 +0200
Links: << >>  << T >>  << A >>
Has anybody try to use different output file format (x.edf or x.xnf)
with Galileo? When I use them with
the xilinx M1.4, it seems to me that the result is 10% slower for the
x.xnf file. The problem is that I use
macro-function from Coregen (from xilinx) in a xnf format. So all the
files must be in xnf format.
Thank you.

Michel.




Article: 12613
Subject: Re: Schematic entry?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Tue, 20 Oct 1998 09:49:02 -0400
Links: << >>  << T >>  << A >>
Gareth Baron wrote:
> I would suspect that Xilinx and the other FPGA companies are basing thier
> decisions on the "must get it out quick" attitude, as who could possibly
> hand craft a 2 Million Gate FPGA (Virtex in the future) ?
> 
> IMO, this should not be their decision but should be their customers'.  

That would be great if Xilinx had unlimited resources. But in the real
world they have limited dollars to spend on developing tools. One would
assume that they have decided that supporting the use of schematic tools
with the Virtex chips has reached the point of diminishing returns in
terms of how many customers would use them.

Xilinx can't always give everyone everything they want. This may just be
getting too expensive for them. So I am sure that if people call Xilinx
and tell them that these tools are still "required", they will spend the
time and money to support them.

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 12614
Subject: Re: State machines in VHDL/Verilog
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 20 Oct 1998 18:51:32 +0100
Links: << >>  << T >>  << A >>
Rickman wrote:

> VHDL synthesizer I am using that is done with an attribute statement.
>
>     --                   1         2         4         8
>     type StateType is (IDLE,     MEMREQ,   MEMXFER,  CNTLREQ,  -- 1
>                        CNTLXFER, STATREQ,  STATXFER, FREQREQ,  -- 10
>                        FREQHOLD, FREQXFER, TESTREQ,  TESTRD,   -- 100
>                        TESTWR,   PREIDLE);                     -- 1000
>
>     attribute enum_encoding : string;
>     attribute enum_encoding of StateType : type is "one hot";
>
> Once the synthesizer sees this it should not only synthesize your FFs as
> one-hot, but should understand to only look at one FF to decode each
> state. For example this is the code I use to assign a name to the IDLE
> state output signal.
>
>   signal   CurState        : StateType;
>   signal   NxtState        : StateType;
>   signal   IdleSt          : std_logic;
>
>   IdleSt      <= '1' when CurState = IDLE     else '0';
>
> I don't know how portable the above code is. You might try a simple test
> case on your tools. I do know that this is recommended in many VHDL
> books.
>
> --
>

This is fine if the compiler/synthesiser can handle it but is there any way
if doing it within the IEEE language definition(s) [as there is in Verilog
with  the casex construct]  without using 1 `if' statement per state ?

Article: 12615
Subject: Re: gray code counter in a Xilinx fpga???
From: "Paul Taylor" <p.leaveitout.taylor@ukonline.leaveitoutagain.co.uk>
Date: Tue, 20 Oct 1998 19:55:40 +0100
Links: << >>  << T >>  << A >>

Le mer Michel wrote in message <362C47E3.69E9FBD8@ago.fr>...
>Ken Coffman wrote:
>
>> The conversion from binary to Gray code is not too bad. The best solution
>> might be to implement a fast binary counter, then convert the binary to
>> Gray.
>>
>> I can post the algorithm to convert binary to Gray if necessary.
>>
>> If the output code is not important, and high speed with low EMI is the
>> goal, perhaps a LFSR counter is the answer.
>>
>> What's the design goal?
>
>What is the meaning of LFSR?
>

Linear Feedback Shift Register.

TI have an app-note called "What's an LFSR?".

http://www.ti.com/sc/docs/psheets/abstract/apps/scta036a.htm





Article: 12616
Subject: Re: Schematic entry?
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 20 Oct 1998 15:05:57 -0400
Links: << >>  << T >>  << A >>
hi rick,

well, a few days ago, i received the hdl for a chip that i am supposed to review
and troubleshoot [day job].  now, the original design was done in schematics by
one company who passed it to a sub who passed it to a sub who passed it to a
sub.  well, the final sub entered the schematics into vhdl so i received over a
dozen ascii files all consisting of mostly structural vhdl.  i would say that
this awkward since to understand the design at all, i must make a drawing [as an
old human i'm not very good at reading netlists].  plus one must also understand
what the synthesizer did to the code.

in my opinion, this was the worst possible choice.  the design was not pushing
performance limits with the highest clock rate at 500 kHz nor was it obviously
density limited since i doubt the synthesizer would do nearly as well as a human
there.  i did run some of their "code" through a synthesizer and it just didn't
get it optimized to the architecture at hand.

in this case either rtl vhdl or schematics would have been superior.

my $0.02,

rk

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

Rick Filipkiewicz 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.



Article: 12617
Subject: Re: State machines in VHDL/Verilog
From: Rickman <spamgoeshere4@yahoo.com>
Date: Tue, 20 Oct 1998 15:56:15 -0400
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> Rickman wrote:
> 
> > VHDL synthesizer I am using that is done with an attribute statement.
> >
> >     --                   1         2         4         8
> >     type StateType is (IDLE,     MEMREQ,   MEMXFER,  CNTLREQ,  -- 1
> >                        CNTLXFER, STATREQ,  STATXFER, FREQREQ,  -- 10
> >                        FREQHOLD, FREQXFER, TESTREQ,  TESTRD,   -- 100
> >                        TESTWR,   PREIDLE);                     -- 1000
> >
> >     attribute enum_encoding : string;
> >     attribute enum_encoding of StateType : type is "one hot";
> >
> > Once the synthesizer sees this it should not only synthesize your FFs as
> > one-hot, but should understand to only look at one FF to decode each
> > state. For example this is the code I use to assign a name to the IDLE
> > state output signal.
> >
> >   signal   CurState        : StateType;
> >   signal   NxtState        : StateType;
> >   signal   IdleSt          : std_logic;
> >
> >   IdleSt      <= '1' when CurState = IDLE     else '0';
> >
> > I don't know how portable the above code is. You might try a simple test
> > case on your tools. I do know that this is recommended in many VHDL
> > books.
> >
> > --
> >
> 
> This is fine if the compiler/synthesiser can handle it but is there any way
> if doing it within the IEEE language definition(s) [as there is in Verilog
> with  the casex construct]  without using 1 `if' statement per state ?

Sorry, I left out the case statement since I thought that was "obvious" 
;^(

You would not want to use nested IF statements since they give the
resultant logic a priority oriented structure. A case statement will
have equal priority to each of the cases.

Here is most of my state machine to handle address decoding and timing
of the various internal interfaces.

  -- Bus Interface Machine Logic
  StateLogic:  process (AdsN, LADIn, LWR, StartXfer, LastWordN, BlastN, 
                             CurState) begin
    case CurState is
      when IDLE =>
        if (AdsN = '1') then 
          NxtState <= IDLE;
        else -- Address valid, check it
          if (LADIn (26) = '0') then 
            NxtState <= MEMREQ; -- Memory read
          elsif (LADIn (7) = '0') then 
            NxtState <= IDLE;
          else -- Access to Registers
            case LADIn (3 downto 2) is
              when "00" => 
                NxtState <= CNTLREQ;
              when "01" =>
                NxtState <= STATREQ;
              when "10" =>
                NxtState <= FREQREQ;
              when "11" =>
                NxtState <= TESTREQ;
            end case;
          end if;  -- elsif LADIn 7
        end if;  -- if AdsN
        
      when MEMREQ =>
        if (StartXfer = '1') then
          NxtState <= MEMXFER;
        else
          NxtState <= MEMREQ; 
        end if;
      when MEMXFER =>
        if (LastWordN = '0' or BlastN = '0') then
          NxtState <= PREIDLE;
        else
          NxtState <= MEMXFER;
        end if;
...sniped many cases...
      when TESTREQ =>
        if (LWR = '0') then 
          NxtState <= TESTRD;
        else
          NxtState <= TESTWR;
        end if;
      when PREIDLE =>
        NxtState <= IDLE;
    end case;
  end process;


I hope this helps.

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 12618
Subject: Re: Schematic entry?
From: "John L. Smith" <jsmith@visicom.com>
Date: Tue, 20 Oct 1998 15:57:52 -0400
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------48F2F213E8EFF132AE74780E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Rick Filipkiewicz 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.

Even SMs can be drawn clearly and in an easy to follow mannerwith a schematic,
at least one-hots. If you want to get fancy, the FF
carrying the state can be wrapped in a symbol with one or two
(or more) inputs: enter (for a transitional state active for only
one cycle), enter and exit, enter and hold, choose your own combo's.
The transition logic is usually a simple sum of products applied
to either of the two state control inputs. Almost as easy to read
as a state diagram. Also, you know what it will compile into, as
opposed to one SM -> HDL -> netlist tool I've looked at,
which ended up producing circuits 50% to 100% larger than the
schematic. And a 100% larger circuit is likely to run half-fast.

Portability --> HDL
Performance --> Schematic


--------------48F2F213E8EFF132AE74780E
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John L. Smith
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             John L. Smith
n:              Smith;John L.
org:            Visicom Imaging Products
adr:            1 Burlington Woods;;;Burlington;MA;01803;USA
email;internet: jsmith@visicom.com
title:          Principal Engineer
tel;work:       781-221-6700
tel;fax:        781-221-6777
note:           http://www.visicom.com/products/Vigra/index.html
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard


--------------48F2F213E8EFF132AE74780E--

Article: 12619
Subject: Altera BGA packages
From: Bryn Wolfe <b.wolfe@ieee.org>
Date: Tue, 20 Oct 1998 15:42:57 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------39153669E1DCF15E842D4D8B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Does anybody have footprints for Altera's BGA packages? I'm using Protel
98 for PCB layout, and they don't provide any support for any BGA
packages. Actually, all I really need is a recommended land pad size for
the standard BGA ball, which is 30mils diameter with 50mils between
centers. Protel has a component wizard that can do the grid layout for
me.

Sorry if this is a little off-subject, but I can't seem to get the info
anywhere else.

--------------39153669E1DCF15E842D4D8B
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Bryn Wolfe at IEEE
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Bryn Wolfe at IEEE
n:              Wolfe at IEEE;Bryn
org:            Metrica TRACLabs
adr:            1012 Hercules Drive;;;Houston;TX;77058-2722;USA
email;internet: b.wolfe@ieee.org
title:          Robotics Engineer
tel;work:       281-461-7886
tel;fax:        281-461-9550
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard


--------------39153669E1DCF15E842D4D8B--

Article: 12620
Subject: isp downnload cable
From: ememka@my-dejanews.com
Date: Tue, 20 Oct 1998 21:01:12 GMT
Links: << >>  << T >>  << A >>
Hello,

Does somebody know where to find Lattice ispDOWNLOAD cable schematics ?

thanks for any help.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
Article: 12621
Subject: isp download cable ?
From: ememka@my-dejanews.com
Date: Tue, 20 Oct 1998 21:04:07 GMT
Links: << >>  << T >>  << A >>
Hello,

Does somebody know where to find schematics for Lattice
isp DOWNLOAD cable ?

Thanks for any help.
Marko.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 12622
Subject: Re: Schematic entry?
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 20 Oct 1998 18:13:16 -0400
Links: << >>  << T >>  << A >>
i've seen the synthesizers do things that you wouldn't expect; extra flip-flops
that aren't needed and a complete disregard for the users instructions, be default
ignoring the designers specification for the 'others' case.  some tools may wind
up designing poor circuits that a human would not design and that he specifies not
to be designed.  but the tool, probably to make better "quality of results,"
ignores.  so, some circuits are poor, more resources than necessary.  others may
be bad circuits, don't meet spec.

while i like the hdl's, sometimes it's just plain "faster, cheaper, and better" to
use a schematic.

rk

QFED - the 'f' is for emphasis.

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

John L. Smith wrote:

> Rick Filipkiewicz 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.
>
> Even SMs can be drawn clearly and in an easy to follow mannerwith a schematic,
> at least one-hots. If you want to get fancy, the FF
> carrying the state can be wrapped in a symbol with one or two
> (or more) inputs: enter (for a transitional state active for only
> one cycle), enter and exit, enter and hold, choose your own combo's.
> The transition logic is usually a simple sum of products applied
> to either of the two state control inputs. Almost as easy to read
> as a state diagram. Also, you know what it will compile into, as
> opposed to one SM -> HDL -> netlist tool I've looked at,
> which ended up producing circuits 50% to 100% larger than the
> schematic. And a 100% larger circuit is likely to run half-fast.
>
> Portability --> HDL
> Performance --> Schematic
>
>   ------------------------------------------------------------------------
>
>   John L. Smith <jsmith@visicom.com>
>   Principal Engineer
>   Visicom Imaging Products
>
>   John L. Smith
>   Principal Engineer        <jsmith@visicom.com>
>   Visicom Imaging Products  HTML Mail
>   1 Burlington Woods        Work: 781-221-6700
>   Burlington                Fax: 781-221-6777
>   MA                        Netscape Conference Address
>   01803                     Netscape Conference DLS Server
>   USA
>   http://www.visicom.com/products/Vigra/index.html
>   Additional Information:
>   Last Name     Smith
>   First Name    John L.
>   Version       2.1



Article: 12623
Subject: Re: Schematic entry?
From: muzok@nospam.pacbell.net (muzo)
Date: 20 Oct 1998 15:48:47 PDT
Links: << >>  << T >>  << A >>
To me this argument is similar to C vs assembly debate. People argued that you
couldn't write a decent/efficient OS in C; now we have real time embedded kernels
which are mostly done in C. Time to market and cost of development (vs cost of
square mm of silicon) will make sure that synthesis tools are good enough to be
used by vast majority of designer.

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.
>

muzo

WDM & NT Kernel Driver Development Consulting <muzok@pacbell.net>
Article: 12624
Subject: Re: Synthesis with Altera RAM instances
From: "SFCFM Volunteer" <stahr@andix.com>
Date: 20 Oct 1998 18:36:06 -0500
Links: << >>  << T >>  << A >>
Thank you!  This "update_lib" command is exactly what I needed.
Later I found it in an Altera app note.


doron nisenbaum wrote in message <362B484A.A7F66F39@chipx.co.il>...
>Hi.
>
>I have no experience with Altera rams, but from question i can guess
>that the command you should try in order to read the ram is:
>
>update_lib <altera library name> syn_ram_8x14_irou.lib
>
>You can find out the library name using 'list -libraries' command.
>
>Doron.
>
>SFCFM Volunteer wrote:
>
>> Help!
>>
>> I have used Altera's "genmem" to create a RAM.
>> The output files were:
>>
>> 1. syn_ram_8x14_irou.v which contains the Verilog
>>    simulation model and the RAM instantiation for
>>    Synopsys synthesis.
>>
>> 2. syn_ram_8x14_irou.lib which is to be (somehow)
>>    inserted to the flex10k-2.db library.
>>
>> I tried doing a read_lib syn_ram_8x14_irou.lib
>> unsuccesfully. Aparently it needs a library header
>> to be able to load.  I could not find an app-note for
>> this in the Altera web site.
>>
>> Thanks in advance for your help...
>
>
>
>--
>
>---------------------------------------------------------------------------
--
>                                           Doron Nisenbaum
>        _/_/_/   _/_/_/_/  _/
>      _/        _/        _/
>     _/        _/_/_/    _/                Chip Express (Israel) LTD.
>    _/        _/        _/                 P.O.Box 2401
>     _/_/_/  _/_/_/_/  _/_/_/_/            Advanced Technology Center
>                                           Haifa , Israel 31024
>   Chip Express Israel                     Tel: +972-4855-0011 Ext. 240
>   --------------------------------        Fax: +972-4855-1122
>   The ASIC Time-to-Market Solution        E-Mail: doron@chipx.co.il
>                                           http://www.chipexpress.com
>
>
>---------------------------------------------------------------------------
--
>
>
>




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

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

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

Custom Search