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 12500

Article: 12500
Subject: Re: books
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Tue, 13 Oct 1998 19:53:47 -0700
Links: << >>  << T >>  << A >>
The Programmable Logic Jump Station maintains a list of books on
programmable logic and associated design tools.  Check out
http://www.optimagic.com/books.html for more information.  By the way, there
is also one book listed in German.

-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------

Arthur Agababyan wrote in message <362303E9.62B3@sun52a.desy.de>...
>Hello,
>
>I want to start to design my own digital systems usind FPGA.
>So far I have been mostly engaged in software design. So,
>which books you could advise me to read. I have no experience
>of either PLD or FPGA. I shall be very thankful if you mention
>a few good books on digital design too.
>
>Thank you. Arthur.
>
>Arthur Agababyan
>DESY
>Notkestrasse 85
>22607 Hamburg
>Germany
>
>arthura@sun52a.desy.de


Article: 12501
Subject: Re: FPGA info..
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Tue, 13 Oct 1998 20:05:13 -0700
Links: << >>  << T >>  << A >>
You might be interested in The Programmable Logic Jump Station at
http://www.optimagic.com.  Also, you may find some of the information on
Michael Smith's ASIC: The Book web site at:

http://www-ee.eng.hawaii.edu/~msmith/ASICs/HTML/ASICs.htm#anchor749424

-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------


S . Vadlamani wrote in message <36225AB3.BA6FEEA6@lucent.com>...
>Can anyone point me to a nice literature about FPGA's. I've a lot
>questions
>about programmable logic, like:
>How's an FPGA different from an ASIC?
>How's an FPGA different from LPGA wrt cost, time-to-market, etc..
>
>The literature should be easy to understand, like a text book and not a
>reference guide.
>
>
>--Lal
>
>
>


Article: 12502
Subject: Re: gray code counter in a Xilinx fpga???
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 13 Oct 1998 23:29:25 -0400
Links: << >>  << T >>  << A >>
hi,

you might want to try a fast binary counter and then convert that output to a
gray code.  you can do that as follows:

    g(i) := b(i) Xor b(i+1)       i := 0 to n-1

    g(i) := b(i)                         i = n

g is the gray code

b is the binary number

for an exercise, i quickly coded it up in vhdl and mapped into a SX16, T=70C,
Vcc=3V, process=worst-case, automagic place and route, not timing driven.

here's what i got for the 24-bit counter:

    -2 speed grade ==> 161 MHz

    standard speed ==> 120 MHz

prob could do a bunch better with schematics + macro generator, used cheapie
(free) vhdl compiler, if i get time, i'll re-run w/ synplicity to compare.

rk

=========================================================

Dan Kuechle wrote:

> Anybody know if its possible to do a gray code counter in a Xilinx 4000xl
> fpga using the fast carry?
>
> I would like a 100mhz, 24 bit free running counter, but might be able to
> live with 50mhz.
> Maybe at 50mhz I wouldn't need fast carry???
>
> Thanks
>    Dan



Article: 12503
Subject: Re: VHDL Editor
From: "Pak Khong" <pak.khong@fujitsu.com.au>
Date: 14 Oct 1998 06:16:21 GMT
Links: << >>  << T >>  << A >>
Check out www.silicon-systems.com

Pacem <pacem@hotmail.com> wrote in article
<36236375.0@news.internex.net.au>...
> Hi,
> 
> I am looking for suggest or recommendation for a VHDL editor. Some of the
> features that I would like to have are the following:
> 
> 1) Color coded keywords
> 2) Test bench generation
> 3) Built-in hierarchy browser
> 4) Auto completion by typing only a few characters
> 5) Independent of any Synthesis or Simulation tool
> 
> Thank you in advance.
> 
> 
> 
Article: 12504
Subject: 100 MHz FPGA
From: yves@px.uk.com (Yves Tchapda)
Date: Wed, 14 Oct 1998 11:46:25 GMT
Links: << >>  << T >>  << A >>
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
Article: 12505
Subject: Re: Viewsim bashing 101
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Wed, 14 Oct 1998 14:01:45 +0100
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
[ all about comparison between HDL and Viewsim for setting-up 
simulations, provoked by Evan ]

> > if i've made a mistake with viewsim's
> > capabilities, then please correct me.
> I believe you're mistaken.

< big snip - I'm just trying to give the flavour here... >

... on using testbench to automate checking of the DUT's outputs...
> OK, how else do you do it, if you don't use your eyes to look to 
> see if the simulation is working correctly?  The Force?

C'mon, that's not what he meant and you know it!  If you have a
programming
language available in the test bench, you can automate checking for
all kinds of responses from the DUT - including quite complex sequencing
things.  Beats eyeballing waveforms any day.  But of course you need
to hand-check the waveforms in early stages of functional simulation.

< snip misc incendiary stuff>

> > 2) you can interact with your design; there's two-way communication
> > between the testbench and the DUT. if your DUT writes data X to
> > address Y in a SRAM device, then it can later read back data X from
> > address Y.
> And why can't I do that with Viewsim?  In fact I can.  What do you think,
> you can only do write cycles from Viewsim, and not read cycles?  Your point
> here is funny, and I don't think what you wrote (or what I understood you
> wrote) is what you meant.
<snip other similar stuff....>
> If your designs do something different with
> the same inputs, there is something wrong with the design.

Hey, this is simply not true!!!!!  Suppose I build a DRAM controller
and set up a simulation test bench.  It runs just fine.  Now I modify
the design so that the refresh interval is sumewhat different, or
perhaps I get smart and do pre-emptive refreshing whilst the bus isn't
busy, or something.  When the DUT does do a refresh, the CPU 
(=testbench) has to be stalled waiting for the DRAM controller to 
come ready. Can I arrange this kind of thing in Viewsim?  In every
waveform simulator I've ever used, the answer is 'no': you have
to watch the simulation, see the simulation get screwed-up by
the wait states or whatever, modify the stimulus so it hangs around
just the right length of time at just the right moment....
I'd really love to know how to do this in Viewsim now that I have
access to it at work here.
But in a real HDL, such a thing is a breeze - just model the CPU
(since when are modelling and design different???) and hook it
up to the DUT.  DUT tells the modelled CPU to wait, and it waits.  
Change the internals of the DUT without affecting its primary
functionality, and the simulation automatically follows suit.
Simulation can then be parameterised at a useful level of
abstraction instead of the "machine-code level" of setting
edge timings.

So, come clean and tell me how you sort this out in Viewsim
and I'll respond with a full retraction.  But until then, I'll
stay a HDL bigot for testbenches even when I'm doing schematic
design.

Jonathan Bromley
Article: 12506
Subject: Re: VHDL Editor
From: Edwin Naroska <edwin@mira.e-technik.uni-dortmund.de>
Date: Wed, 14 Oct 1998 14:03:47 +0100
Links: << >>  << T >>  << A >>
Hi,

Pacem wrote:

> Hi,
>
> I am looking for suggest or recommendation for a VHDL editor. Some of the
> features that I would like to have are the following:
>
> 1) Color coded keywords
> 2) Test bench generation
> 3) Built-in hierarchy browser
> 4) Auto completion by typing only a few characters
> 5) Independent of any Synthesis or Simulation tool
>

Check out Part 3, Section 1.3 of the FAQ at

    http://www.vhdl.org/comp.lang.vhdl/

It lists a few editors which should have at least
some of the features.

Bye,...
Edwin


Article: 12507
Subject: Re: FOCUS FOCUS FOCUS
From: bob@nospam.thanks (Bob Perlman)
Date: Wed, 14 Oct 1998 13:36:56 GMT
Links: << >>  << T >>  << A >>
Evan - 

Thanks for the follow-up post.  But please answer this: what's the
point?  It's clear that you like VHDL simulators a lot better than
Viewsim.  Fine.  But how can you "prove" that Viewsim can't be used to
verify large designs when there are people who do it every day?

It's one thing to prove that you can't do it, and quite another to
prove that others can't.

Bob Perlman
Cambrian Design Works

Article: 12508
Subject: Re: Viewsim bashing 101
From: "Austin Franklin" <darkroo3m@ix.netcom.com>
Date: 14 Oct 1998 14:13:51 GMT
Links: << >>  << T >>  << A >>

> ... on using testbench to automate checking of the DUT's outputs...
> > OK, how else do you do it, if you don't use your eyes to look to 
> > see if the simulation is working correctly?  The Force?
> 
> C'mon, that's not what he meant and you know it!  If you have a
> programming
> language available in the test bench, you can automate checking for
> all kinds of responses from the DUT - including quite complex sequencing
> things.  Beats eyeballing waveforms any day.  But of course you need
> to hand-check the waveforms in early stages of functional simulation.

No, he implied you can't automate simulation checking with Viewsim, and you
can!  With Viewsim  you visually check the results the first (and possibly
subsequent, as you also have to do with VHDL) time(s) and then write the
vectors out, and use the check command.
 
> < snip misc incendiary stuff>
> 
> > > 2) you can interact with your design; there's two-way communication
> > > between the testbench and the DUT. if your DUT writes data X to
> > > address Y in a SRAM device, then it can later read back data X from
> > > address Y.
> > And why can't I do that with Viewsim?  In fact I can.  What do you
think,
> > you can only do write cycles from Viewsim, and not read cycles?  Your
point
> > here is funny, and I don't think what you wrote (or what I understood
you
> > wrote) is what you meant.
> <snip other similar stuff....>
> > If your designs do something different with
> > the same inputs, there is something wrong with the design.
> 
> Hey, this is simply not true!!!!!  Suppose I build a DRAM controller
> and set up a simulation test bench.  It runs just fine.  Now I modify
> the design

And you changed something....  Of course if you change something, something
else CAN change.  If you read what was said (write X to Y, then read back X
from Y) you CAN do that with Viewsim....

.....
> I'd really love to know how to do this in Viewsim now that I have
> access to it at work here.

If you use VHDL models (irrelevant what the original design is done in) you
can write it to do anything you want.  My point is there is a BIG
difference between USING VHDL for simulation modeling and DESIGNING using
VHDL or schematics.

> But in a real HDL, such a thing is a breeze - just model the CPU

(shouting loudly) AND THIS HAS NOTHING TO DO WITH SCHEMATIC OR VHDL AS YOUR
DESIGN ENTRY TOOL which is what this thread is SUPPOSED to be about!

> (since when are modelling and design different???)

You REALLY don't understand that?  Come on.  With Viewsim you can write
VHDL models to interact with your DUT, and (I'll say it again for CLARITY)
it DOESN'T MATTER WHETHER YOUR ORIGINAL DESIGN WAS DONE IN SCHEMATICS OR
VHDL.

>.....  But until then, I'll
> stay a HDL bigot for testbenches even when I'm doing schematic
> design.

So what are you arguing about here?  No one has ever said that VHDL
testbenches were 'bad' or that they aren't VERY useful for simulation.  The
poster said that Viewsim was a 'Mickey mouse' tool for doing simulation,
and VHDL testbenches were the only way to go, and you HAVE to do timed
simulations.  He was very misinformed on what Viewsim is, and how to use
it.

Why is it we can't seem to talk about the matter at hand, and that is there
are people who WANT schematic entry for their FPGA designs.  For some
reason, some people want to tell me I (and others) should be doing
something differently.  I've said this before, If you like VHDL, and are
proficient in it, good for you.  Use it.  But don't belittle (or prohibit)
someone else's
testing/design methodology because you don't know how to use it, or don't
approve of it.  There are MANY very very high end engineers who prefer this
methodology (Viewdraw/Viewsim/static timing analysis/unit delay
simulation).

How about if Xilinx said 'No more HDLs OR schematics, you have to use ONLY
C now (or what ever)'  see how it would feel if the shoe was on the other
foot.  They want to eliminate a tool that many people are very proficient
at, and gives excellent performance and design ability with their products.
 Irrespective of the tool.

Austin


Article: 12509
Subject: Gray Code counter in ORCA FPGA (4 methods) vp_gray.vhd
From: John McCluskey <jqm@cam.org>
Date: Wed, 14 Oct 1998 10:38:51 -0400
Links: << >>  << T >>  << A >>
The recent discussion on Gray code counters has inspired me to post the following
VHDL
code, to instruct and illustrate how it can be done.    This code module is not
complete,
since it uses other packages not included in this posting.   The complete source
code is
available, just drop me a line if interested.  I created this in order to
complete my FIFO
generation module.

Johh McCluskey
J.McCluskey@nospam.ieee.org
(Is it safe yet to post real Email addresses?)

source code follows:

--***************************************************************************
--
-- Title:               VP Gray Code Counter package
--
-- File:                VP_GRAY.VHD
-- Revision:            1.0
-- Created:             Mon Jul 13 16:00 1998
-- Author:              John McCluskey <JMcCluskey@lucent.com>

-- Keywords:   Gray Code, Gray Sequence, FIFO
--
-- LRM_version:         IEEE Std. P1076-1993
--
-- Logic System:        IEEE-1164, Std_Logic, Std_Logic_Vector
--
-- Package
-- Requirements:        ieee.std_logic_1164, ieee.numeric_std, vp.vp_def,
--                      vp.vp_ff, vp.vp_rip, vp.vp_equ, vp.vp_gate
--
--
-- Usage:               See the website  http://www.lucent.ca/fpga
--
-- References:          ORCA Macro Library Reference Manual "macrolib.pdf"
--                      Field-Programmable Gate Arrays Data Book
--                      Jan 1998.
--
-- Bugs:         Preloading illegal values will produce illegal states.
--                      Maximum counter length is integer'high - 1 = 2147483646
--
-- History:             Version 1.0 Created 7-13-98 by John McCluskey
--
-- Notes:
--
-- Gray code counter with synchronous load and preset inputs
-- This counter generates Gray code sequences of any even length.  Minimum
-- count length is 2, maximum is integer'high-1 = 2147483646 (31 bits)
--
-- It uses 4 different methods for building a gray counter.  The first method
-- is brute force.  A lookup table with 2**log2(count_length) entries is
-- constructed as a constant array, and a finite state machine is created
-- that finds the next state by looking it up in the table.  This works great
-- for small counters (1024 states and fewer), but takes too long to compile
-- for larger counters.  The preload function is supported.  A 12 bit counter
-- in a 3T30-6 can hit 100 MHz.  Area and speed tradeoff can be done in the
-- synthesis tool.  Recommended maximum value for LUT_MAX is 64 to 128.
--
-- The second method specifies the count logic in terms of cascaded LUT's and
-- SLIC's, and also supports a preload function.  Will be slow for big counters,
-- but compiles easily for any size.  It uses behavioral VHDL, so the area/speed
-- switches will work in the synthesis tool.   A 16 bit counter in a 3T20-6
-- runs at 57 MHz when compiled for maximum speed, and 37 MHz at minimum area.
-- The maximum size counter (2147483646 states) runs at about 33 MHz.
-- Your mileage may vary.
--
-- The third method is for counters that have no preload function and the
-- number of states is an exact power of 2.  This is a binary up counter
-- followed by an XOR network to convert to gray code.  It is small & runs
-- *very* fast, but only supports a synchronous preset to a static value.
-- 16 bit counters will be well above 100 MHz.  A counter of 30 bits runs at
-- 90 MHz. This version is insensitive to area/speed tradeoff switches.
--
-- Fourth method is for bigger counters where the sequence length is not a
-- power of 2.  This uses an up/down binary counter with SLIC state decoders
-- and an XOR gray code conversion pipeline.  Runs fast, but has no preload
-- capability.  16 bit counters in a 3T30-6 will run in the 100 MHz region.
-- The maximum size counter (see above), runs at 75 MHz.
-- Also insensitive to area/speed tradeoff switches.
--
-- Which method is used depends on the LUT_MAX generic parameter and whether
-- or not the user connects the WD preload port.  If count_length > LUT_MAX,
-- then it will not use the brute force lookup method.  If the WD port is not
-- connected, it will use the binary counters with gray code converters, since
-- these run faster.   Optimization is automatic for the case when the count
-- length is an exact power of 2.
--
-- The synchronous preset input can be used to set the counter to an arbitrary
-- value via the gsr_value generic ( which defaults to zero).  This is the
-- value taken by the counter when either a global reset or local preset occurs.
-- The lsr_flag when set to LSR_OVER_CE permits the "preset" input to have
-- priority over the clock enable.  This is needed for fifo designs.
--
-- The synchronous load input should be in GRAY CODE, and requires that the
-- clock enable be at a logic TRUE (high) level.  If the counter is not
-- enabled, the preload won't work.  You can provide an external OR gate on the
-- enable input to perform this function if you wish.
--
-- BUGS: There is no testing to check for illegal values loaded outside the
-- selected range.  There is no danger of lockup if this happens, and the counter

-- will either immediately jump to zero (in the case of a LUT), or count to the
-- end of a binary range (binary counter mode).  Illegal states may result.
--
--***************************************************************************


LIBRARY ieee,vp;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use vp.vp_def.all;  -- include vp_def package
package vp_gray is

component gray_counter
     generic (   -- count_length must be an even number
          count_length : natural;  -- maximum value is 2**(Q'length)
          gsr_value : natural := 0;  -- value set when clr or GSR occurs
          lsr_flag : lsr_flag_type := lsr_over_ce; -- either "sync_ff" or
"lsr_over_ce"
          lut_max : natural := 32   -- maximum size for counters using LUT's
     );
     port (
           clk    : IN std_logic;    -- Q output changes on rising_edge
           enable : IN std_logic := '1';   -- default is always enabled
           preset    : IN std_logic := '0';   -- synchronous preset (active high)

           load   : IN std_logic := '0';   -- active high synchronous load
           WD     : IN std_logic_vector := B"0";   -- GRAY CODE Preload input
           Q      : OUT std_logic_vector  -- GRAY CODE OUTPUT
        );
end component;

function gray_code( X : std_logic_vector) return std_logic_vector;

function calc_gvec( N : natural; len : integer; clen : natural )
                   return std_logic_vector;

end vp_gray;

package body vp_gray is

-- conversion function from binary to gray code when power of 2 elements
function gray_code( X : std_logic_vector) return std_logic_vector is
  variable Y, result: std_logic_vector(0 to X'length - 1);
begin
  Y := X; -- create alias of X
  result(0) := Y(0);
  for i in 1 to X'length-1 loop
    result(i) := Y(i) xor Y(i-1);
  end loop;
  return result;
end gray_code;

-- calculate gray code equivalent when not a power of 2
function calc_gvec( N : natural; len : integer; clen : natural )
                       return std_logic_vector is
 variable result : std_logic_vector(len-1 downto 0);
 variable tmp : natural := N;
begin
 if 2**log2(clen/2) = clen/2 then
    return gray_code( std_logic_vector( to_unsigned(N,len)));
 end if;
 if N >= clen/2 then
    tmp := clen - N - 1;
 end if;
 result := gray_code( std_logic_vector( to_unsigned(tmp,len) ) );
 if N >= clen/2 then
   result(len-1) := '1';  -- '1' means "count down"
 end if;
 return result;
end calc_gvec;

end vp_gray;
--*****************************************************************************

LIBRARY ieee,vp;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use vp.vp_def.all;  -- include vp_def package
use vp.vp_ff.all;
use vp.vp_rip.all;
use vp.vp_equ.all;
use vp.vp_gray.all;

entity gray_counter is
     generic (   -- count_length must be an even number
          count_length : natural;  -- maximum value is 2**(Q'length)
          gsr_value : natural := 0;  -- value set when preset or GSR occurs
          lsr_flag : lsr_flag_type := sync_ff; -- either "sync_ff" or
"lsr_over_ce"
          lut_max : natural := 64   -- maximum size for counters using LUT's
     );
     port (
           clk    : IN std_logic;    -- Q output changes on rising_edge
           enable : IN std_logic := '1';   -- default is always enabled
           preset    : IN std_logic := '0';   -- synchronous preset (active high)

           load   : IN std_logic := '0';   -- active high synchronous load
           WD     : IN std_logic_vector := B"0"; -- GRAY code preload input
           Q      : OUT std_logic_vector  -- OUTPUT in GRAY code
        );
end gray_counter;

architecture ssv of gray_counter is


-- define an array of array type for building a lookup table
constant lsize : natural := log2( count_length );
constant csize : natural := lsize-1;

-- calculate binary code equivalent when not a power of 2
function calc_bvec( N : natural; len : integer ) return std_logic_vector is
 variable result : std_logic_vector(len-1 downto 0);
 variable tmp : natural := N;
begin
 if 2**log2(count_length/2) = count_length/2 then
    return std_logic_vector( to_unsigned(N,len));
 end if;
 if N >= count_length/2 then
    tmp := count_length - N - 1;
 end if;
 result := std_logic_vector( to_unsigned(tmp,len) );
 if N >= count_length/2 then
   result(len-1) := '1';  -- '1' means "count down"
 end if;
 return result;
end calc_bvec;


function set_preload_flag( N : natural ) return enable_flag_type is
begin
if N < 2 then return use_enable;
else return use_select;  end if;
end set_preload_flag;

-- This enables preload functions if WD'length is greater than 1
constant preload_flag : enable_flag_type := set_preload_flag( WD'length );

begin

assert 2**(Q'length - 1) >= count_length/2
  report "GRAY_COUNTER: Error, count_length exceeds range possible with Q vector"

  severity error;

assert count_length > gsr_value
  report "GRAY_COUNTER: Error, gsr_value exceeds count_length specified."
  severity error;

assert lsr_flag = sync_ff or lsr_flag = lsr_over_ce
  report "GRAY_COUNTER: Error, lsr_flag must be 'sync_ff' or 'lsr_over_ce'."
  severity error;

assert count_length mod 2 = 0
  report "GRAY_COUNTER: Error, count_length must be even!"
  severity error;

assert WD'length=1 or WD'length = Q'length
  report "GRAY_COUNTER: WD Preload port length is not the same as Q port length."

  severity error;

-- first method, use LUT's for small counters, based on LUT_MAX criterion
-- This is brute force FSM generation, using a array of constants to generate
-- the next state value.  Becomes difficult to compile above 1024 states.
-- This is the best architecture for 128 states and below.  Supports preload.
g1: if count_length < LUT_MAX+1 generate
  b: block  -- needed to avoid Model Tech bug in 4.7f
  -- use a constant lookup table to generate counter states
  subtype gray_word_type is std_logic_vector(0 to lsize - 1);
  type gray_table_type is array(0 to 2**lsize-1) of gray_word_type;

  -- this constructs a FSM lookup table where the next state is
  -- found directly by an indexed lookup.
  function make_gray_table( N : natural ) return gray_table_type is
    variable r1 : gray_table_type := (others => (others => '0'));
    variable tmp : gray_word_type;
    variable index : natural := 0;
  begin
  l: for i in 0 to N/2 - 2 loop
    tmp := gray_code(std_logic_vector(to_unsigned(i+1,lsize)));
    r1( index ) := tmp;
    index := to_integer( unsigned(tmp) );
  end loop l;
  r1( index ) := '1' & tmp(1 to lsize-1);
  index := to_integer( unsigned( r1(index) ) );
  t: for i in N/2 - 1 downto 1 loop
    tmp := gray_code(std_logic_vector(to_unsigned(i-1,lsize)));
    r1( index ) := '1' & tmp(1 to lsize-1);
    index := to_integer( unsigned( r1(index) ));
  end loop t;
  r1( index ) := tmp;
  return r1;
  end make_gray_table;

  constant gray_table : gray_table_type := make_gray_table(count_length);
  constant gsr_vec : std_logic_vector(lsize-1 downto 0) :=
               calc_gvec(gsr_value mod count_length,lsize, count_length);

  signal cnt, qt, wdt : std_logic_vector(lsize-1 downto 0);
  for all: dff_std use entity vp.dff_std(ssv);
  begin

   cnt <= gray_table( to_integer( unsigned( qt) ) );

   wdt <= std_logic_vector( resize( unsigned(WD), lsize ));

   f1: dff_std
             generic map(gsr_val => gsr_vec, enable_flag => preload_flag,
                          lsr_flag => lsr_flag )
             port map(D => cnt, clk => clk, enable => enable, lsr => preset,
                      sel => load, WD => wdt, Q => qt );
   Q <= std_logic_vector( resize( unsigned(qt), Q'length) );
   end block b;
end generate g1;

-- second method, using logic and SLIC's with a preload capability
-- This supports any count length, and has a preload.  Counter speed
-- will get sluggish for very long counter lengths.
g2: if count_length > LUT_MAX and  WD'length /= 1 generate
  signal qt, par : std_logic_vector(lsize-1 downto 0);
  signal cnt, wdt, cr : std_logic_vector(lsize-1 downto 0);
  constant gsr_vec : std_logic_vector(lsize-1 downto 0) :=
               calc_gvec(gsr_value mod count_length,lsize, count_length);

  for all: dff_std use entity vp.dff_std(ssv);
begin
  -- generate combinatorial logic for gray code
  -- If count_length is a power of 2, simplify the circuit
  p2: if 2**log2(count_length/2) = count_length/2 generate
    cnt(0) <= not (qt(1) xor par(1));
    cr(0) <= '0';
    par(lsize-1) <= '0';
    cnt(lsize-1) <= ( qt(lsize-2) and not cr(lsize-2) ) or
                  ( qt(lsize-1) and (qt(lsize-2) or cr(lsize-2)));
    cr(lsize-1 ) <= '0';
    l: for i in 1 to lsize-2 generate
      par(i) <= qt(i+1) xor par(i+1);
      cnt(i) <=  ( (not cr(i-1)) and qt(i-1) and not par(i)) or
                 (qt(i) and not(qt(i-1) and par(i) and not cr(i-1)) );
      cr(i)  <= qt(i-1) or cr(i-1);
    end generate l;
  end generate p2;
  n2: if 2**log2(count_length/2) /= count_length/2 generate
    constant evec : std_logic_vector(csize downto 0) :=
                    calc_gvec( count_length/2 - 1, csize+1 , count_length );
    for all: const_eq_std use entity vp.const_eq_std(ssv);
    begin
    cnt(0) <= (qt(0) and cr(0)) or not(qt(1) xor par(1));
    -- cr(0) <= '0';
    c0: const_eq_std generic map (Y=> evec, gate_flag => use_slics)
         port map( X => qt, Q => cr(0) );
    par(csize) <= '0';
    cnt(csize) <= cr(0) or
                  ( qt(csize) and (qt(csize-1) or cr(csize-1)));
    l: for i in 1 to csize-1 generate
      par(i) <= qt(i+1) xor par(i+1);
     cnt(i) <=  ( (not cr(i-1)) and qt(i-1) and not par(i)) or
                (qt(i) and not(qt(i-1) and par(i) and not cr(i-1)) );
      cr(i)  <= qt(i-1) or cr(i-1);
    end generate l;
  end generate n2;

  f1: dff_std
      generic map( gsr_val => gsr_vec,
                   enable_flag => preload_flag,
                   lsr_flag => lsr_flag )
      port map(D => cnt, clk => clk, enable => enable,
              lsr => preset, sel => load,
              WD => wdt, Q => qt );

  wdt <= std_logic_vector( resize( unsigned(WD), lsize ));
  Q <= std_logic_vector( resize( unsigned(qt), Q'length ) );
end generate g2;

-- third method, a binary up counter followed by gray code conversion.
-- this is only suitable for count lengths that are a power of 2 and
-- with no preload function.  Runs the fastest of all.
g3: if count_length > LUT_MAX and 2**log2(count_length/2) = count_length/2 and
       WD'length = 1  generate
  signal cnt, qt, qn, qd : std_logic_vector(lsize-1 downto 0);
  constant gsr_vec : std_logic_vector(lsize-1 downto 0) :=
                     std_logic_vector(to_signed((gsr_value+1) mod
count_length,lsize));
  constant gray_vec: std_logic_vector(lsize-1 downto 0) :=
          gray_code( std_logic_vector(to_signed(gsr_value,lsize)) );
  for all: rip_std use entity vp.rip_std(ssv);
  for all: dff_std use entity vp.dff_std(ssv);
begin
  r1: rip_std
     generic map( rip_mode => cntup ) -- count logic
     port map(Cin => '1',  A => qt, F => cnt );
  -- create register for binary counter
  f1: dff_std
             generic map( gsr_val => gsr_vec,
                          lsr_flag => lsr_flag )
      port map(D => cnt, clk => clk, enable => enable,
              lsr => preset, sel => load,
              Q => qt );
  -- generate combinatorial logic to convert binary to gray code
  l: for i in 0 to qt'length-2 generate
    qn(i) <= qt(i) xor qt(i+1);
  end generate l;
  qn(lsize-1) <= qt(lsize-1);
  -- create output register for gray code
  f2: dff_std
        generic map( lsr_flag => lsr_flag, gsr_val => gray_vec)
        port map( D => qn, sel => load,  clk => clk,
                  enable => enable, lsr => preset, Q => qd);
  Q <= std_logic_vector( resize( unsigned(qd), Q'length ) );
end generate g3;

-- 4th method, a binary up/down counter followed by gray code conversion
-- This handles any even count sequence length and uses slightly more
-- logic than a counter with a count length that is a power of 2.
-- This uses fast carry logic (ripple mode), SLICS, and a few LUT's.
-- It runs fast, but has no preload capability, only an LSR preset.
g4: if count_length > LUT_MAX and WD'length = 1 and
            2**log2(count_length/2) /= count_length/2  generate
  signal cnt, qt : std_logic_vector(csize-1 downto 0);
  signal qn, qd : std_logic_vector(csize downto 0);  -- final output vector
  signal dir, fin1, fin2, cnt_c, cnt_en: std_logic;
  constant gsr_vec : std_logic_vector(csize downto 0) :=
        calc_gvec( (gsr_value+1) mod count_length, csize + 1 , count_length );
  constant gsr_vec0 : std_logic_vector(csize downto 0) :=
        calc_gvec( (gsr_value+2) mod count_length, csize + 1 , count_length );
  constant dval : std_logic := not gsr_vec(csize);
  constant dval0: std_logic := not gsr_vec0(csize);

  constant gray_vec: std_logic_vector(csize downto 0) :=
        calc_gvec( gsr_value mod count_length, csize+1 , count_length) ;
  constant end_vec1 : std_logic_vector(csize-1 downto 0)
       := std_logic_vector( to_unsigned( 1 , csize ) );
  constant end_vec2 : std_logic_vector(csize-1 downto 0)
       := std_logic_vector(to_unsigned( count_length/2-2, csize));

  for all: const_eq_std use entity vp.const_eq_std(ssv);
  for all: dff_uni use entity vp.dff_uni(ssv);
  for all: dff_std use entity vp.dff_std(ssv);
  for all: rip_std use entity vp.rip_std(ssv);
begin

  c1: const_eq_std generic map( Y => end_vec1, gate_flag => use_slics)
          port map( X => qt, Q => fin1 );
  c2: const_eq_std generic map( Y => end_vec2, gate_flag => use_slics)
          port map( X => qt, Q => fin2 );
         -- port map( X => qd(csize-1 downto 0), Q => fin2 );

  cnt_c <= '1' when fin1='1' and dir='0' else
           '0' when fin2='1' and dir='1' else
            cnt_en;
  d0: dff_uni generic map(gsr_val => dval0, lsr_flag => lsr_flag)
              port map( D => cnt_c, clk => clk,
                        enable => enable, lsr => preset, Q => cnt_en);
  d1: dff_uni generic map(gsr_val => dval, lsr_flag => lsr_flag)
              port map( D => cnt_en, clk => clk,
                        enable => enable, lsr => preset, Q => dir);

  r1: rip_std generic map( rip_mode => cntupdn ) -- up/down count logic
     port map(Cin => cnt_en,  addsub_updn => dir, A => qt, F => cnt );
  -- create register for binary counter
  f1: dff_std generic map(gsr_val => gsr_vec(csize-1 downto 0), lsr_flag =>
lsr_flag )
     port map(D => cnt, clk => clk, enable => enable, lsr => preset, Q => qt );
  -- generate combinatorial logic to convert binary to gray code
  l: for i in 0 to qt'length-2 generate
    qn(i) <= qt(i) xor qt(i+1);
  end generate l;
  qn(csize-1) <= qt(csize-1);
  qn(csize) <= not dir;  -- MSB is inverted direction bit (matches LUT counter)
  -- create output register for gray code
  f2: dff_std generic map( lsr_flag => lsr_flag, gsr_val => gray_vec )
        port map( D => qn, clk => clk, enable => enable, lsr => preset, Q => qd);

  Q <= std_logic_vector( resize( unsigned( qd ), Q'length) );
end generate g4;
end ssv;

-----------end of gray_counter architecture-------------



Article: 12510
Subject: Re: Schematic entry?
From: milostnik@my-dejanews.com
Date: Wed, 14 Oct 1998 15:46:30 GMT
Links: << >>  << T >>  << A >>
In article <6vvfoc$e1v@su102w.ess.harris.com>,
  DaveP <dpears01@*nospam*harris.com> wrote:
> IMO, schematic entry is still the way to get gate level control of a
> design if you need to wring that last nanosecond out of the path, but it
> is definitely not a transportable design in that form.

This is the reason why mixed mode entry is still the top priority for
every tool that we have inhouse.

To portability:

This would not be a problem if the industry would settle on a
standard library: LPM (Library of parametrized modules)
To shame that the big player (like Xilinx with Logiblock or
the old X-blocks ) insist on using thier proprietary solution.

For interchange we alredy standardized on EDIF. EDIF 2 0 0 is widely
used, but the more powerfull EDIF 3 0 0 and EDIF 4 0 0 seem to have
lost the race.

This has always been the dark side of schematics. Using HDL has his
cavetas too. What if the design has used librareis that your tool
doesnt have? Portability is gone too.

Bye

> Dave P.

Matija

In chaos all things are possible.
Matija Milostnik, RDHW, IskraTEL, Ljubljanska 24a, SI-4000 Kranj, Slovenia
Tel: +386 64 27 2125, Fax: +386 64 221 552, Email: milostnik@iskratel.si
www.IskraTEL.si: Building the world of telecommunications


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 12511
Subject: Re: Altera MAXPLUS2 V9 slow.
From: Jamie Lokier <spamfilter.sep1998@tantalophile.demon.co.uk>
Date: 14 Oct 1998 17:45:35 +0100
Links: << >>  << T >>  << A >>
> On 8 Oct 1998 13:07:26 GMT, "Eric Pearson"
> <ecp@focus-systems.nospam.on.ca> wrote:
> >Has anyone noticed problems in re-compiling designs that worked in v8.0 of
> >maxplus2 under v9.01 and found comilation times went throught the roof even
> >to the point excess ( I aborted after 100 hours v9 vs 1 hour under v8 ).

x@xxx.x writes:
> I have a design that will recompile on 8.3 in about 15 minutes.  When
> I tried 9.01, I gave up after about 10 hours. I never figured it out,
> so I currently use 8.3.  (The design is for a 6024A chip).

Interesting that the release notes for 9.01 say something like
"significant improvements in timing driven compilation speed" :-)

Perhaps I won't upgrade after all.  I haven't heard any good reports
yet.

-- Jamie
Article: 12512
Subject: Re: 100 MHz FPGA
From: Jamie Lokier <spamfilter.sep1998@tantalophile.demon.co.uk>
Date: 14 Oct 1998 18:21:38 +0100
Links: << >>  << T >>  << A >>
yves@px.uk.com (Yves Tchapda) writes:
>  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?

You probably do want to use a 32-bit interface to move the data internal
to the FPGA.  But multiplexing to/from 8-bit at 100MHz should work quite
reliably on say an Altera Flex10K50-1 or -2 part.  Even I/O flow control
is just about possible.  With a proper heatsink.

I've been working towards a very similar goal, though currently I'm
nowhere near the 100MHz speed.

The async. FIFO's I'm building are getting 70MHz at 8 bits on a 10K50-3
according to timing analysis, though I haven't done any actual I/O at
that rate.

I find that accidentelly misconfiguring a pin so it has logic contention
(with some unrelated external device) is enough to make 10MHz
unreliable, even for about 5 minutes after reprogramming the chip
correctly :-)

My general dataflow and control logic tends to work up to 20-25MHz or so
on the 10K50-3 (33MHz with real careful design, but that's more effort
than it's worth IMO).

So if I were doing what you're trying to do (as I will be), I'd use
32-bit internal data paths and 32 or 16 or 8 bit external data paths
according to whatever the external device requires.

-- Jamie
Article: 12513
Subject: Re: VHDL Editor
From: Lasse Langwadt Christensen <fuz@kom.auc.dk>
Date: Wed, 14 Oct 1998 19:28:10 GMT
Links: << >>  << T >>  << A >>
Pacem wrote:
> 
> Hi,
> 
> I am looking for suggest or recommendation for a VHDL editor. Some of the
> features that I would like to have are the following:
> 
> 1) Color coded keywords
> 2) Test bench generation
> 3) Built-in hierarchy browser
> 4) Auto completion by typing only a few characters
> 5) Independent of any Synthesis or Simulation tool
> 
> Thank you in advance.

How about emacs with vhdl-mode ?

-- Lasse
----------------------------------------------------------
Lasse Langwadt Christensen, M.Sc. EE (to be in 1999)
Aalborg University, Department of communication technology 
Applied Signal Processing and Implementation (ASPI)      
http://www.kom.auc.dk/~fuz , ICQ# 13068090
Article: 12514
Subject: Re: Schematic entry?
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: Wed, 14 Oct 1998 13:00:34 -0700
Links: << >>  << T >>  << A >>
milostnik@my-dejanews.com wrote in message
<702h0n$db2$1@nnrp1.dejanews.com>...

>This has always been the dark side of schematics. Using HDL has his
>cavetas too. What if the design has used librareis that your tool
>doesnt have? Portability is gone too.

If you have a good synthesizer, you shouldn't have to instantiate
vendor/device specific components in your HDL code.  Admittedly, there are
things that you'd have to instantiate as black-boxes (Xilinx RAMs come to
mind), but that's not the HDL's fault, is it?

-a
--
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
520-318-8191
apeters@noao.edu



Article: 12515
Subject: Re: Viewsim bashing 101
From: madarass@cats.ucsc.edu (Rita Madarassy)
Date: 14 Oct 1998 20:21:10 GMT
Links: << >>  << T >>  << A >>
In article <01bdf71a$5bcffe50$72625ecf@drt1>,
Austin Franklin <darkroo3m@ix.netcom.com> wrote:
>
> 
>> 3) there's no decision-and-branch capability. viewsim is *not* a
>> programming language; it mandates a linear execution of statements,
>> with the maximum complexity being the
>> brackets-and-fixed-number-of-repeats construct.
>
>That's not exactly true.  It supports VHDL modeling, and any time I need a
>bus functional model, I do it in VHDL, which VHDL is a great simulation

I don't think you understood what he said.  He said there is not easy
way to do branching in a cmd file which is absolutely true.



>language.
> 
>> 2) you can interact with your design; there's two-way communication
>> between the testbench and the DUT. if your DUT writes data X to
>> address Y in a SRAM device, then it can later read back data X from
>> address Y.
>
>And why can't I do that with Viewsim?  In fact I can.  What do you think,
>you can only do write cycles from Viewsim, and not read cycles?  Your point
>here is funny, and I don't think what you wrote (or what I understood you
>wrote) is what you meant.

It is a definite pain in the ass to interact with memory components
in viewsim. It took me quite a bit to find out how to use dumpm
and how to find the actual instance names of the memory components.
I learnt it but I hated it for waisting so much time in a tool.




>
>> 5) vhdl is a programming language. you can make decisions, change
>> control flows, whatever. you can read and write arbitrary files. you
>> could read a file containing processor opcodes, for example, parse
>> them in your testbench, and do something to your DUT as a result.
>
>What's the point?  Somewhere something has to change for the simulation to
>change?  You have to change the inputs/sequence of inputs to change the
>outputs/sequence of outputs.  If your designs do something different with
>the same inputs, there is something wrong with the design.
> 

Duhhhh!!!!!
If there wasn't anything wrong with the design you would probably not
need a  verification tool.


>> 6) vhdl is concurrent. you can start clocks running, and have lots of
>> things going on at once, independently. you're not restricted to the
>> linear assign-cycle-check sequence of viewsim.
>
>And I can do that in Viewsim too.  I run many clocks concurrently.  Yes,
>only one can be the main cycle based clock, but I have yet to have any
>problem with that.

Give me a break!!!
How can you compare the concurrent nature of vhdl simulators
with the dinky "clock" feature of viewsim?
It is absolutely incorrect to minimize the importance of concurrency.

Like it or not the nature of viewsim is sequential not concurrent.
Granted, viewsim is  a decent simulator, probably the best (not counting
modelsim) in the PC environment.
However,  vhdl simulators offers you a standard method of simulation
(and I emphasize on the word standard) with a natural support for concurrency.
I know you are trying to convince yourself that it was worth to spend all those
engineering hours learning a tool that is doomed to fade away or be
killed by vhdl simulations. But if I were you, I would start taking
vhdl courses and stop your viewsim self hipnosys.




> 
>> 7) vhdl is stable, more or less. tools may change, as you point out,
>> but that's not relevant. there have been minor syntax changes over the
>> last decade, but i bet people will be using vhdl long after viewsim is
>> deservedly buried.
>
>This is quite arguable.  But I'm tired of these groping points.  If you
>like VHDL, and are proficient in it, good for you.  But don't belittle
>someone else's testing methodology because you don't know how to use it.
> 
>> 8) you can write self-checking testbenches. the testbench could, for
>> example, read stimulus from a file, apply it the DUT, check the
>> results against a different file, and report a pass/fail on
>> completion, together with appropriate error messages.
>
>As you can with Viewsim......
>
>> and what do the asic vendors think? is viewsim a sign-off simulator?
>
>In fact, yes.
>
>> hardly.
>
>Funny, I've done about a half of a dozen ASICs with Viewdraw/Viewsim.  I
>know a lot of other people who have too.
>
>> i use modelsim, among others, and it is. even if i ignore the
>> issue of test vector coverage when writing my testbench, there's still
>> a good chance that i'll 70%+, even without trying. i can then modify
>> my testbench to get close to 100%. what sort of coverage could a
>> viewsim script achieve? i don't know - maybe 'minimal' is the answer.
>
>Wrong.  If you write your simulations correctly, whether VHDL or Viewsim,
>you will get as much coverage as you get, and it won't be different because
>you used VHDL or Viewsim.
> 
>> in short, if you've got a small-ish design, and you think that you're
>> good enough that you don't need a comprehensive simulation, then you
>> may be ok with viewsim.
>
>You have yet to clarify what more comprehensively you can do with VHDL. 
>The answer is NOTHING!  If you know what you're doing with Viewsim, you
>will get as good a simulation as you can with ANY other methodology.
>
>> if, on the other hand, your designs are starting to look like asics,
>> then perhaps you should be using asic methodologies.
>
>And that's not the point either........  You just don't get it.  I'll
>restate it here for clarity.  If you like VHDL, and are proficient in it,
>good for you.  Use it.  But don't belittle (or prohibit) someone else's
>testing methodology because you don't know how to use it.
>
>Austin Franklin
>darkroom@ix.netcom.com
>
>


Article: 12516
Subject: Re: Schematic entry?
From: stanng@C449967-A.frmt1.sfba.home.com (Stan Ng)
Date: Wed, 14 Oct 1998 22:08:13 GMT
Links: << >>  << T >>  << A >>
On Wed, 14 Oct 1998 13:00:34 -0700, Andy Peters <apeters@noao.edu.NOSPAM> wrote:
>
>If you have a good synthesizer, you shouldn't have to instantiate
>vendor/device specific components in your HDL code.  Admittedly, there are
>things that you'd have to instantiate as black-boxes (Xilinx RAMs come to
>mind), but that's not the HDL's fault, is it?

Actually, good synthesis tools are even inferring RAM's (you write the RAM
as a behavioral model, and the synthesis tool inserts as many FPGA primitive
rams as it takes to implement the RAM).  Exemplar has done this for years, 
and I understand Synplicity has added this capability.

Article: 12517
Subject: Re: Schematic entry?
From: Erik de Castro Lopo <please@see.sig>
Date: Thu, 15 Oct 1998 08:23:06 +1000
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> 
> milostnik@my-dejanews.com wrote in message
> <702h0n$db2$1@nnrp1.dejanews.com>...
> 
> >This has always been the dark side of schematics. Using HDL has his
> >cavetas too. What if the design has used librareis that your tool
> >doesnt have? Portability is gone too.
> 
> If you have a good synthesizer, you shouldn't have to instantiate
> vendor/device specific components in your HDL code.  Admittedly, there are
> things that you'd have to instantiate as black-boxes (Xilinx RAMs come to
> mind), but that's not the HDL's fault, is it?

There are some things that no synthesizer can do as well as a clueful designer
with schematic entry. 

What about a 32 bit wide counter running at high clock rates wrt the speed
grade of the FPGA? There is no way that counter implemented in straitforward 
VHDL would run at as high a clock speed as one done in a schematic with 
a pipelined carry (ie split the counter into four sections and register the 
carry from block to block) used to reduce the maximum width of the carry 
chains.  This is just one VERY trivial example.

What's the price difference between a Xilinx 4kXL in -1 and -3 speed
grade? If there is a price difference at all (there is), doing the extra 
work in schematic is worth the reduced cost in final production. I work
for a company which makes a low volume (30 per month) high cost product. We 
consider it worthwhile to get stuff working in the lowest possible speed grade. 
What about companies using FPGAs for medium volume, medium cost products?
In that situation cost is even more important.

VHDL is great for simulation, it works resonsably well for state machines
(better than schematics) but there are other areas where it fails miserably
because there is no way for the synthesizer to read the mind of the designer.

Erik
-- 
-------------------------------
Erik de Castro Lopo
Fairlight ESP Pty Ltd
e.de.castro AT fairlightesp.com.au
Article: 12518
Subject: Re: Viewsim bashing 101
From: "Austin Franklin" <darkroo3m@ix.netcom.com>
Date: 14 Oct 1998 22:31:40 GMT
Links: << >>  << T >>  << A >>
Rita   Madarassy <madarass@cats.ucsc.edu> wrote in article
<70313m$3r6@darkstar.ucsc.edu>...
> In article <01bdf71a$5bcffe50$72625ecf@drt1>,
> Austin Franklin <darkroo3m@ix.netcom.com> wrote:
> >
> > 
> >> 3) there's no decision-and-branch capability. viewsim is *not* a
> >> programming language; it mandates a linear execution of statements,
> >> with the maximum complexity being the
> >> brackets-and-fixed-number-of-repeats construct.
> >
> >That's not exactly true.  It supports VHDL modeling, and any time I need
a
> >bus functional model, I do it in VHDL, which VHDL is a great simulation
> 
> I don't think you understood what he said.  He said there is not easy
> way to do branching in a cmd file which is absolutely true.

I understood EXACTLY what he said.  And what I said is EXACTLY true.  His
point is a 'so what'.  You can use VHDL modeling in Viewsim.  In a VHDL
model you CAN do branching. 
 
<snip 'stuff'>

> I know you are trying to convince yourself that it was worth to spend all
those
> engineering hours learning a tool that is doomed to fade away or be
> killed by vhdl simulations. But if I were you, I would start taking
> vhdl courses and stop your viewsim self hipnosys.

Your comments are quite misinformed.  I know VHDL quite well, thank you.  I
don't appreciate your condescending and arrogant nature.  As I have said
MANY TIMES BEFORE, but, for some reason, you fail to grasp:  THIS IS NOT
ABOUT VHDL VS SCHEMATICS.  For some reason, you feel the need to tell
others what THEY should be doing.

I am doing quite well using schematics for my front end tool for high
speed, low cost, high density FPGA design.  I have a methodology that works
perfectly well, and VHDL gives me NO advantages.  You believe it does FOR
YOU, I KNOW it doesn't FOR ME.  Been there, done that.  I have many clients
that I have 'fixed' their panaceic VHDL experience for.  And they are quite
happy, thank you.

If you like VHDL, and are proficient in it, good for you.  Use it.  But
don't belittle (or prohibit) someone else's testing/design methodology
because you don't know how to use it, or don't
approve of it.  There are MANY very very high end engineers who prefer this
methodology (Viewdraw/Viewsim/static timing analysis/unit delay
simulation).

Austin Franklin
darkroom@ix.netcom.com


Article: 12519
Subject: Re: Digital Sine Generator
From: z80@ds2.com (Peter)
Date: Wed, 14 Oct 1998 22:40:36 GMT
Links: << >>  << T >>  << A >>

I have some old appnotes from Thomson-CSF from ~ 15 yrs ago when they
used to make the 9365/9367 CRT controller chip.

This implemented line drawing with the standard Bresenham algorithm,
and the appnotes contained details of what they called the Horn
algorithm  for drawing circles; the alg. actually generated the y
value for incrementing x, for an octant, and then one swapped x/y
values round in the obvious way to draw the complete circle. One could
always tell if some (slow!) graphics system used this algorithm
because circles were drawn starting in 8 places at once.

I could probably dig this stuff up, if pushed :)

I also did designs with the famous NEC 7220 graphics chip. All this
way back before the IBM PC killed all demand for graphics-capable dumb
terminals.

>I am not sure about the Horn algorithm,  but I would be very interested
>in what
>it is.  There is Horner's algorithm and also another one by an author's
>last name Horna, but more info on Horn would be very interesting.  


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.
Article: 12520
Subject: Re: Schematic entry?
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: Wed, 14 Oct 1998 16:10:54 -0700
Links: << >>  << T >>  << A >>
Erik de Castro Lopo wrote in message <3625244A.6D09@see.sig>...

>VHDL is great for simulation, it works resonsably well for state machines
>(better than schematics) but there are other areas where it fails miserably
>because there is no way for the synthesizer to read the mind of the
designer.


Constraints help it understand the designers intent.  And if the synthesis
tool is smart enough, it is able to see what the timing constraints are and
choose its topology (say, for your counter example) that'll meet that
constraint.

--
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
520-318-8191
apeters@noao.edu



Article: 12521
Subject: Re: Viewsim bashing 101
From: ems@nospam.riverside-machines.com
Date: Wed, 14 Oct 1998 23:23:47 GMT
Links: << >>  << T >>  << A >>
there's no need to shout. i said in my original post, in another
thread, that i wasn't a viewsim expert. if you want to correct some of
the fine details of my understanding, then i'm grateful for it.
however, it seems to me that the only difference between my scripts
and yours is that you call other scripts from your script. however,
without parameter passing, this is of little use.

> (shouting loudly) AND THIS HAS NOTHING TO DO WITH SCHEMATIC OR VHDL AS YOUR
> DESIGN ENTRY TOOL which is what this thread is SUPPOSED to be about!

i said *nothing* in my post about the relative merits of vhdl entry
and schematic entry. in fact, what i actually said was:

> note that i'm not going
> to pontificate about the relative merits of schematics and vhdl - the
> problem here is only in the simulation part of the cycle. there's no
> reason why you can't simulate a schematic-only design in vhdl.

and philip originally said:

> This has NOTHING to do with the VHDL vs Schematic debate,
> which is as pointless big endian vs small endian.

the issue is simulation. you've mis-quoted me, more than once, and
you're going off topic. the web site says nothing about not being able
to *design* virtexes with schematics; philip also specifically states,
or implies, that you can do it.

by the way, i don't give a toss about how anybody else simulates their
designs; they can do what they want. i didn't (and dont) belittle
anybody, and i didn't 'prohibit' anything. if you read the first para
of my post, you'll see that i was giving my opinion that you couldn't
do a good job of simulating a large design with viewsim, and that you
could do a much better job with vhdl. this is, in my opinion,
self-evident.

evan

oh - a couple of quick points:

i said:
>>the only significant complication on top of this basic structure is
>>that you can read sequences of numbers from a file, to use in your
>>'assign' and 'check' statements, but only in a very limited manner.
you replied to jonathan:
>No, he implied you can't automate simulation checking with Viewsim, and
>you can!
????

and:

> OK, how else do you do it, if you don't use your eyes to look to see if the
> simulation is working correctly?  The Force?

no. The Language. what do you need your eyes for?

Article: 12522
Subject: Re: FOCUS FOCUS FOCUS
From: ems@nospam.riverside-machines.com
Date: Wed, 14 Oct 1998 23:24:46 GMT
Links: << >>  << T >>  << A >>
On Wed, 14 Oct 1998 13:36:56 GMT, bob@nospam.thanks (Bob Perlman)
wrote:

>Evan - 
>
>Thanks for the follow-up post.  But please answer this: what's the
>point?  It's clear that you like VHDL simulators a lot better than
>Viewsim.  Fine.  But how can you "prove" that Viewsim can't be used to
>verify large designs when there are people who do it every day?
>
>It's one thing to prove that you can't do it, and quite another to
>prove that others can't.
>
>Bob Perlman
>Cambrian Design Works
>

bob - i didn't say it wasn't possible. as you say, i'm sure that
people do it all the time. it would be presumptious of me to say that
it can't be done, it shouldn't be done, or that anyone else should do
it in the way that i prefer to do it. what i actually said was:

> why
> do i think that you *can't* do a good job of simulating a large
> design, such as a virtex, with viewsim, or aldec's look-a-like, and
> why *can* you do a much better job with vhdl?

the word 'you' here is a general term (as you can see from the second
'you'). in fact, i would be very interested to hear from the viewsim
people why they think that viewsim can cope with large designs
(preferably without lots of capital letters). 

evan

Article: 12523
Subject: Re: Schematic entry?
From: ems@nospam.riverside-machines.com
Date: Wed, 14 Oct 1998 23:25:25 GMT
Links: << >>  << T >>  << A >>
On 10 Oct 1998 21:00:58 +0200, Magnus Homann
<d0asta@mis.dtek.chalmers.se> wrote:

> ...<snipped>

well, at least *i* thought this was relatively amusing, even if nobody
else did...  :)

evan

Article: 12524
Subject: Re: FOCUS FOCUS FOCUS
From: "Austin Franklin" <darkroo3m@ix.netcom.com>
Date: 14 Oct 1998 23:45:05 GMT
Links: << >>  << T >>  << A >>
> i would be very interested to hear from the viewsim
> people why they think that viewsim can cope with large designs
> (preferably without lots of capital letters). 

Because it can, and I have done quite a few 25k-100k designs in both ASICs
and FPGAs, using strictly ViewDraw and ViewSim.

Austin



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