Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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.deArticle: 12501
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
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: 12503Check 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
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.comArticle: 12505
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 BromleyArticle: 12506
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: 12507Evan - 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 WorksArticle: 12508
> ... 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. AustinArticle: 12509
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: 12510In 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 OwnArticle: 12511
> 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. -- JamieArticle: 12512
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. -- JamieArticle: 12513
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# 13068090Article: 12514
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.eduArticle: 12515
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
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
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.auArticle: 12518
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.comArticle: 12519
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
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.eduArticle: 12521
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
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). evanArticle: 12523
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... :) evanArticle: 12524
> 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:
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