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

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

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

Custom Search

Messages from 37950

Article: 37950
Subject: Re: vector reversed in netlist of XC9572XL
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 27 Dec 2001 11:12:33 +0000
Links: << >>  << T >>  << A >>


Utku Ozcan wrote:

> Design entry: Verilog
> Synthesis: Synplify v6.24
> P&R: Xilinx M3.1i SP8 IP4
> OS: Sun Solaris 2.6
> Technology: Xilinx XC9572XL-5TQ100C
>
> Xilinx tools reverse vectors in netlists generated by themselves.
>
> I have vectors like:
>
> output [1:2] add_ck_a;
> output [1:4] dck;
> input [4:5] drp_mux_c;
>
> I synthesize my code in Synplify and run Design Manager and
> Design Manager generates Verilog netlist in which the vectors
> above are reversed:
>
> input [5:4] drp_mux_c;
> output [2:1] add_ck_a;
> output [4:1] dck;
>
> I know this can be compensated by instantiation.
> But is it possible to keep the vector direction during implementation?
>
> Utku

Utku,

If Design Manager is calling NGD2VER to produce the netlist then this is a
known ``feature''. Have a look at the ``Bus order in Verilog files''
subsection of the NGD2VER chapter of the Development System Reference
Guide.

It means that either:

o All top level ports have to be written ``littleendian'', or,

o The bit order in the testbench instantiation has to be reversed between
HDL & post route simulations.

irritating!


Article: 37951
Subject: Re: vector reversed in netlist of XC9572XL
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Thu, 27 Dec 2001 11:51:07 GMT
Links: << >>  << T >>  << A >>
On Thu, 27 Dec 2001 11:12:33 +0000, Rick Filipkiewicz
<rick@algor.co.uk> wrote:

>
>
>Utku Ozcan wrote:
>
>> Design entry: Verilog
>> Synthesis: Synplify v6.24
>> P&R: Xilinx M3.1i SP8 IP4
>> OS: Sun Solaris 2.6
>> Technology: Xilinx XC9572XL-5TQ100C
>>
>> Xilinx tools reverse vectors in netlists generated by themselves.
>>
>> I have vectors like:
>>
>> output [1:2] add_ck_a;
>> output [1:4] dck;
>> input [4:5] drp_mux_c;
>>
>> I synthesize my code in Synplify and run Design Manager and
>> Design Manager generates Verilog netlist in which the vectors
>> above are reversed:
>>
>> input [5:4] drp_mux_c;
>> output [2:1] add_ck_a;
>> output [4:1] dck;
>>
>> I know this can be compensated by instantiation.
>> But is it possible to keep the vector direction during implementation?
>>
>> Utku
>
>Utku,
>
>If Design Manager is calling NGD2VER to produce the netlist then this is a
>known ``feature''. Have a look at the ``Bus order in Verilog files''
>subsection of the NGD2VER chapter of the Development System Reference
>Guide.
>
>It means that either:
>
>o All top level ports have to be written ``littleendian'', or,
>
>o The bit order in the testbench instantiation has to be reversed between
>HDL & post route simulations.
>
>irritating!

The same applies to NGD2VHDL.  One gets into the habit of always
defining top level ports as "downto".

The NGD2xxx programs don't have the information about the original
"direction" so they pick one.  Most of the time it's ok...

Another gotcha is that the post route code won't have any of the ports
that were "optimised" away.

E.g. if your RTL has a port such as 
  input [31:0] address;
and your design ignores the least significant bit, the post route code
will have a port
  input [31:1] address;
which may cause problems in your test bench.

Regards,
Allan.

Article: 37952
Subject: Re: vector reversed in netlist of XC9572XL
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Thu, 27 Dec 2001 14:00:21 +0200
Links: << >>  << T >>  << A >>
> [snip]
>
> Utku,
> 
> If Design Manager is calling NGD2VER to produce the netlist then this is a
> known ``feature''. Have a look at the ``Bus order in Verilog files''
> subsection of the NGD2VER chapter of the Development System Reference
> Guide.
> 
> It means that either:
> 
> o All top level ports have to be written ``littleendian'', or,
> 
> o The bit order in the testbench instantiation has to be reversed between
> HDL & post route simulations.
> 
> irritating!

  Rick,

  thank your very much that you have pointed me the document.
  I have never used big-endian bus order before, so it is good
  to know the ``feature'' from now on. Yes, irritating!

  Have a nice Xmas and Happy New Year!

  Utku

Article: 37953
Subject: Re: Look for FPGA Starterkit
From: Roberto Waltman <rwaltman@verizon.net>
Date: Thu, 27 Dec 2001 10:34:29 -0500
Links: << >>  << T >>  << A >>
<dgeerinck@yahoo.com> wrote:
>I saw this year some basics of vhdl at school.
>I'm now looking for some kind of FPGA-starterkit who allows me
>to experiment on simple I/O like leds, LCD screens, com-ports,
>...

Digilent also sells FPGA kits:

  http://www.digilentinc.com/Products/digilab_xla.html
  http://www.digilentinc.com/Products/digilab_2.html
  http://www.digilentinc.com/Products/digital_i_o.html

RW.

Article: 37954
Subject: Signal Spy feature available for NC VHDL - Thanks to Martyn, Cadence
From: "Srinivasan Venkataramanan" <srinivasan@siliconsystems.co.in>
Date: Thu, 27 Dec 2001 22:23:55 +0530
Links: << >>  << T >>  << A >>
Hello VHDL Users,
        It was one of my long pending wishes to provide the VHDL
community (atleast a part of them who use NC tools) to provide a
"feature" to be able to "probe" internals signals of your DUT in
Testbenches in a cleaner fashion (than using Global Signals etc.). As
you may all know Modelsim has this so called "Signal Spy" available
for quite some time. Thanks to Martyn Pollard of Cadence I got a small
piece of C-code for a similar functionality with Cadence's NC-VHDL
tool and I have just made a quick sample run and made minor
improvements (nothing major yet) and have uploaded to
http://www.vlsisrini.com/ Please feel free to download it and suggest
(or bombard ?) any improvements that you would like to see.

Have a Great New Year!

Kind Regards,
Srinivasan

P.S. The direct link to the actual page is:
http://in.geocities.com/srinivasan_v2001/technical/nc_signal_spy.htm)

--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt. Ltd. (An Intel company)
Bangalore, India, Visit: http://www.simputer.org)
"I don't Speak for Intel"





Article: 37955
Subject: Atmel FPSLIC - Problem with concurrent statements
From: jetmarc@hotmail.com (jetmarc)
Date: 27 Dec 2001 08:54:54 -0800
Links: << >>  << T >>  << A >>
Hi.

I'm doing my first steps with VHDL and I face a problem with
concurrent
statements.

My design targets the Atmel FPSLIC, and I actually run it on the
silicon for testing.  It implements a variable rotate (for RC5
encryption).  32 bits of data are given to the FPGA into "val_in"
together with a shift count ("shift").  Concurrent statements
evaluate val_out = val_in >>> shift, so that "val_out" can be
read back later by the microcontroller portion of the FPSLIC.

This works fine when the last line of the source (below) is

   val_out <= val_in;

or

   val_out <= val0;        -- rotated by 0 or 1 bit positions

so that the input value is used directly or rotated only once.
As soon as I use the other rotation-taps val1..3 or the final tap
val4, the result is garbled.  There are one or several bits wrong,
usually "0"-bits turn into "1"-bits.  The majority of bits is
correct however.

The idea behind my design is that the result is evaluated in
several stages.  Each stage operates on the result of the
previous stage.  Maybe this is the problem.  I think in terms
of hardware and expect the states of the higher stages to
settle later than the first stages.  Much like the higher
bits of a ripple counter.

There is enough time available for this, the microcontroller
pauses 1 ms before reading back val_out. Reading back several
times does not change anything either.  There is no race
condition.


Here is the VHDL source, please help:


library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_bit.all;

ENTITY rotate IS

	PORT (
			SEL		: in	std_logic;

			RD		: in	std_logic;
			WR		: in	std_logic;
			XTAL		: in	std_logic;
			DIN		: in	std_logic_vector (7 downto 0);
			DOUT		: out	std_logic_vector (7 downto 0)
	);

END rotate;

ARCHITECTURE rotate_b OF rotate IS

	SIGNAL rd_state  : integer RANGE 0 TO 3 := 0;
	SIGNAL wr_state  : integer RANGE 0 TO 4 := 0;

	SIGNAL shift     : STD_LOGIC_VECTOR ( 4 downto 0);
	SIGNAL val_in    : STD_LOGIC_VECTOR (31 downto 0);
	SIGNAL val_out   : STD_LOGIC_VECTOR (31 downto 0);

	signal val0      : STD_LOGIC_VECTOR (31 downto 0);
	signal val1      : STD_LOGIC_VECTOR (31 downto 0);
	signal val2      : STD_LOGIC_VECTOR (31 downto 0);
	signal val3      : STD_LOGIC_VECTOR (31 downto 0);
	signal val4      : STD_LOGIC_VECTOR (31 downto 0);

	signal rd_qual   : std_logic;
	signal wr_qual   : std_logic;

begin	--- support signals

	rd_qual <= (SEL and RD);					--- qualified read
	wr_qual <= (SEL and WR);					--- qualified write

	--- state machine to control reads and writes

	statemachine : PROCESS (rd_qual,wr_qual,XTAL)

		variable rd_qual_int : std_logic;
		variable wr_qual_int : std_logic;

	begin

		if (falling_edge(XTAL)) then

			rd_qual_int := rd_qual;
			wr_qual_int := wr_qual;

		end if;

		if (rising_edge(XTAL)) then

			if (rd_qual_int='1') then			--- advance rd_state, reset wr_state
				rd_state <= rd_state +1;
				wr_state <= 0;
			end if;

			if (wr_qual_int='1') then			--- advance wr_state, reset rd_state
				wr_state <= wr_state +1;
				rd_state <= 0;
			end if;

		end if;

	end process statemachine;

	--- microcontroller writes 32 bit "val_in" and 5 bit "shift" value in
5 consecutive writes

	input : PROCESS (wr_qual,wr_state,XTAL)
	begin

		if (falling_edge(XTAL)) then
		  if wr_qual='1' then

			case wr_state is
				when 0 =>	val_in ( 7 downto  0) <= DIN (7 downto 0);
				when 1 =>	val_in (15 downto  8) <= DIN (7 downto 0);
				when 2 =>	val_in (23 downto 16) <= DIN (7 downto 0);
				when 3 =>	val_in (31 downto 24) <= DIN (7 downto 0);

				when 4 =>	shift   (4 downto  0) <= DIN (4 downto 0);
			end case;

		  end if;
		end if;

	end process input;

	--- microcontroller reads 32 bit "val_out" in 4 consecutive reads

	output : PROCESS (rd_qual,rd_state,val_out)
	begin

		if rd_qual='1' then

			case rd_state is
				when 0 =>	DOUT (7 downto 0) <= val_out ( 7 downto  0);
				when 1 =>	DOUT (7 downto 0) <= val_out (15 downto  8);
				when 2 =>	DOUT (7 downto 0) <= val_out (23 downto 16);
				when 3 =>	DOUT (7 downto 0) <= val_out (31 downto 24);
			end case;

		else
			DOUT <= "ZZZZZZZZ";
		end if;

	end process output;

	--- the rotate function

	sh0 : PROCESS (XTAL,shift,val_in)
		variable val0_int: STD_LOGIC_VECTOR (31 downto 0);
	begin
		if shift(0)='1' then
		  val0_int (31 downto  0) := val_in(0)           & val_in(31 downto 
1);
		else
		  val0_int (31 downto  0) := val_in(31 downto 0);
		end if;

		val0 <= val0_int;
	end process sh0;

	sh1 : PROCESS (shift,val0,xtal)
		variable val1_int: STD_LOGIC_VECTOR (31 downto 0);
	begin
		if shift(1)='1' then
		  val1_int (31 downto  0) := val0( 1 downto 0) & val0(31 downto  2);
		else
		  val1_int (31 downto  0) := val0(31 downto 0);
		end if;

		val1 <= val1_int;
	end process sh1;

	sh2 : PROCESS (shift,val1)
		variable val2_int: STD_LOGIC_VECTOR (31 downto 0);
	begin
		if shift(2)='1' then
		  val2_int (31 downto  0) := val1( 3 downto 0) & val1(31 downto  4);
		else
		  val2_int (31 downto  0) := val1(31 downto 0);
		end if;

		val2 <= val2_int;
	end process sh2;

	sh3 : PROCESS (shift,val2)
		variable val3_int: STD_LOGIC_VECTOR (31 downto 0);
	begin
		if shift(3)='1' then
		  val3_int (31 downto  0) := val2( 7 downto 0) & val2(31 downto  8);
		else
		  val3_int (31 downto  0) := val2(31 downto 0);
		end if;

		val3 <= val3_int;
	end process sh3;

	sh4 : PROCESS (shift,val3)
		variable val4_int: STD_LOGIC_VECTOR (31 downto 0);
	begin
		if shift(4)='1' then
		  val4_int (31 downto  0) := val3(15 downto 0) & val3(31 downto 16);
		else
		  val4_int (31 downto  0) := val3(31 downto 0);
		end if;

		val4 <= val4_int;
	end process sh4;

	val_out <= val4;

END rotate_b;

Article: 37956
Subject: Re: Where could I get a signal waveform editor?
From: d2fabrizio@aol.com (Dan Fabrizio)
Date: 27 Dec 2001 10:25:57 -0800
Links: << >>  << T >>  << A >>
Hi,

The TimingAnalyzer can be used to draw timing diagrams of
digital interfaces and check for timing problems in
digital systems. Signals, clocks, buses, delays, 
constraints, and states are easily added from the gui. 
The diagrams can be saved as JPG or GIF images. 

Scripts can written in a Java like scripting language to
generate test vectors, input stimulus for simulators, 
test benches, the timing diagram itself, or new features. 

Minimum, typical, and worst case analysis can be performed to check 
for timing problems in the design. Delays and constraints can be user 
defined or specified from part libraries in text files. All files are 
text formatted so the user can easily add, modify, or create new 
libraries.

Changing clock frequencies, signal parameters, or library parts 
allows the user to quickly check functionality with slower parts or higher 
frequencies. 

Written in Java, it runs on any platform that supports the
java runtime enviroment JRE1.3. It is being tested on Windows and Linux. 

FREE to everyone while in Beta Testing 

Regards,
Dan Fabrizio
d2fabrizio@aol.com
http://members.aol.com/d2fabrizio



"Srinivasan Venkataramanan" <srinivasan@siliconsystems.co.in> wrote in message news:<a0bv5m$a00@news.or.intel.com>...
> Hi,
>   Try
> 
> 1.> http://members.aol.com/d2fabrizio/
> 2.> http://www.timingtool.com/
> 
> HTH,
> Srinivasan
> 
> 
> "Kevin Brace"
> <nospamtomyaddresskevinbraceusenet@hotmail.comnospamtomyaddress> wrote
> in message news:3C281960.DB85C679@hotmail.comnospamtomyaddress...
> > I am wondering if there is kind of software which I can easily draw
>  and
> > edit bus signal waveforms with a mouse and a keyboard, and print it
>  out
> > from a printer.
> > I can think of Altera MAX+PLUS II-BASELINE's waveform editor, but
>  does
> > anyone else know something better?
> > I will like to improve my productivity, and one thing that took
>  forever
> > during a design I worked on was drawing sample waveforms of a design
>  I
> > am working on sheets of paper with a pencil and a ruler.
> > From these sample waveforms I think about how I will design state
> > machines and when I should change a value of a FF.
> > After the state machine design is done, I go into HDL coding.
> > So, does anyone know such a tool I am talking about?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Kevin Brace (don't respond to me directly, respond within the
> newsgroup)

Article: 37957
Subject: Re: Look for FPGA Starterkit
From: hegde@datacube.com (Uday Hegde)
Date: 27 Dec 2001 11:17:59 -0800
Links: << >>  << T >>  << A >>
"David G." <dgeerinck@yahoo.com> wrote in message news:<3c27e328$0$10318$ba620e4c@news.skynet.be>...
> Hi,
> I saw this year some basics of vhdl at school.
> I'm now looking for some kind of FPGA-starterkit who allows me
> to experiment on simple I/O like leds, LCD screens, com-ports,
> RAM, ETHERNET,etc that are accesible through a simple electronic board.
> 
> I heard of a Xilinx starterkit but found it a bit expesive
> for the pour student I am :-(
> 
> 
> Thanks.
> 
> David.

More links:
xess.com
vcc.com

Article: 37958
Subject: Re: Atmel FPSLIC - Problem with concurrent statements
From: Andy Peters <andy@exponentmedia.nospam.com>
Date: Thu, 27 Dec 2001 20:41:39 GMT
Links: << >>  << T >>  << A >>
Comments embedded in the code:

jetmarc wrote:

> I'm doing my first steps with VHDL and I face a problem with
> concurrent
> statements.
> 
> My design targets the Atmel FPSLIC, and I actually run it on the
> silicon for testing.  It implements a variable rotate (for RC5
> encryption).  32 bits of data are given to the FPGA into "val_in"
> together with a shift count ("shift").  Concurrent statements
> evaluate val_out = val_in >>> shift, so that "val_out" can be
> read back later by the microcontroller portion of the FPSLIC.

> Here is the VHDL source, please help:


What synthesis tool are you using??  And are you simulating?  Burn-and-crash debugging is little more than a time-waster, especially when you are new to a design tool.

> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_arith.all;
> use ieee.std_logic_unsigned.all;
> use ieee.numeric_bit.all;


Why not numeric_std?


> ENTITY rotate IS
> 
> 	PORT (
> 			SEL		: in	std_logic;
> 
> 			RD		: in	std_logic;
> 			WR		: in	std_logic;
> 			XTAL		: in	std_logic;
> 			DIN		: in	std_logic_vector (7 downto 0);
> 			DOUT		: out	std_logic_vector (7 downto 0)
> 	);
> 
> END rotate;
> 
> ARCHITECTURE rotate_b OF rotate IS
> 
> 	SIGNAL rd_state  : integer RANGE 0 TO 3 := 0;
> 	SIGNAL wr_state  : integer RANGE 0 TO 4 := 0;
> 
> 	SIGNAL shift     : STD_LOGIC_VECTOR ( 4 downto 0);
> 	SIGNAL val_in    : STD_LOGIC_VECTOR (31 downto 0);
> 	SIGNAL val_out   : STD_LOGIC_VECTOR (31 downto 0);
> 
> 	signal val0      : STD_LOGIC_VECTOR (31 downto 0);
> 	signal val1      : STD_LOGIC_VECTOR (31 downto 0);
> 	signal val2      : STD_LOGIC_VECTOR (31 downto 0);
> 	signal val3      : STD_LOGIC_VECTOR (31 downto 0);
> 	signal val4      : STD_LOGIC_VECTOR (31 downto 0);
> 
> 	signal rd_qual   : std_logic;
> 	signal wr_qual   : std_logic;
> 
> begin	--- support signals
> 
> 	rd_qual <= (SEL and RD);					--- qualified read
> 	wr_qual <= (SEL and WR);					--- qualified write
> 
> 	--- state machine to control reads and writes
> 
> 	statemachine : PROCESS (rd_qual,wr_qual,XTAL)
> 
> 		variable rd_qual_int : std_logic;
> 		variable wr_qual_int : std_logic;
> 
> 	begin
> 
> 		if (falling_edge(XTAL)) then
> 
> 			rd_qual_int := rd_qual;
> 			wr_qual_int := wr_qual;
> 
> 		end if;
> 
> 		if (rising_edge(XTAL)) then
> 
> 			if (rd_qual_int='1') then			--- advance rd_state, reset wr_state
> 				rd_state <= rd_state +1;
> 				wr_state <= 0;
> 			end if;
> 
> 			if (wr_qual_int='1') then			--- advance wr_state, reset rd_state
> 				wr_state <= wr_state +1;
> 				rd_state <= 0;
> 			end if;
> 
> 		end if;
> 
> 	end process statemachine;


Three comments here:

1) If you want your statemachine process to be combinatorial, the ONLY 
things you should have on your sensitivity list are the clock and 
asyncrhonous reset.
2) Your architecture does not have flops that are sensitive to both 
edges of the clock, so using both falling_edge() and rising_edge() in 
the same process should've resulted in some sort of compiler error.
3) If you're looking for the edge of a non-clock signal, you'll need to 
write edge-detector code.  You might think that rising_edge() and 
falling_edge() do that, but you'd be wrong.  And it's not obvious.


> 	sh0 : PROCESS (XTAL,shift,val_in)
> 		variable val0_int: STD_LOGIC_VECTOR (31 downto 0);
> 	begin
> 		if shift(0)='1' then
> 		  val0_int (31 downto  0) := val_in(0)           & val_in(31 downto 
> 1);
> 		else
> 		  val0_int (31 downto  0) := val_in(31 downto 0);
> 		end if;
> 
> 		val0 <= val0_int;
> 	end process sh0;


What's happening here is that you're trying to build a shift register 
out of purely combinatorial logic.  You have XTAL (assuming that's your 
clock) on the sensitivity list, yet you don't use it in the process. 
Oversight?  Again, the only thing you want in the sensitivity list for 
your flops are the clock and reset.  You should read your synth tool's 
manual.

You might also want to spend some quality time with a VHDL simulator. 
You'll find it much easier to spot errors looking at the computer 
screen, rather than with a 'scope probe.

---a


Article: 37959
Subject: Re: vector reversed in netlist of XC9572XL
From: Andy Peters <andy@exponentmedia.nospam.com>
Date: Thu, 27 Dec 2001 21:07:06 GMT
Links: << >>  << T >>  << A >>
Allan Herriman wrote:


> Another gotcha is that the post route code won't have any of the ports
> that were "optimised" away.
> 
> E.g. if your RTL has a port such as 
>   input [31:0] address;
> and your design ignores the least significant bit, the post route code
> will have a port
>   input [31:1] address;
> which may cause problems in your test bench.


Another, similar, gotcha is when you have a 32-bit bidirectional data 
bus coming into your chip, and you drive all 32 as outputs but only 
actually use, say, 20 as inputs.  The tools helpfully optimize away the 
unused 12 input paths, and the simulation model the tool spits out 
changes those ports to outputs, so of course your test bench complains.

That's why I take care of the unused inputs by ANDing (or ORing, or 
whatever) them all together and driving the result out an unused pin on 
the chip.  Unused outputs are grounded inside the chip.  While this is 
purely brute force and uses chip resources, it's obvious (perhaps adding 
a comment helps) and you don't have to remember any 
dont_touch/no_optimize/leave_me_alone pragmas that are highly 
tool-dependent.

--a




Article: 37960
Subject: Re: Lattice Filter Schematic?
From: Andy Peters <andy@exponentmedia.nospam.com>
Date: Thu, 27 Dec 2001 21:10:53 GMT
Links: << >>  << T >>  << A >>
Daniel Yap wrote:

> Hi,
> I am looking for a schematic diagram on Lattice Filter. Anyone can provide
> me some diagram on it? Coz  I am doing a FPGA project on this filter and I
> need to understand the algorithm.


You might do well to pick up a DSP book: Oppenheim and Shafer, perhaps.

--a


Article: 37961
Subject: Re: THE SIGNAL LIST IS NOT AVAILABLE TO SIMULATE
From: Andy Peters <andy@exponentmedia.nospam.com>
Date: Thu, 27 Dec 2001 21:16:49 GMT
Links: << >>  << T >>  << A >>
freny wrote:

> I am using xilinx fs-2.1. In simulation I need to select the signals from the 
> signal menu. I am unable to add the signals as no signals are shown in the ADD 
> SIGNALS menu.
> Can anyone help me in this respect


What simulator are you using?  Have you initialized it by loading the 
design?

--a




Article: 37962
Subject: Re: The speedest FPGA
From: mostuus@yahoo.com (Stuart Moses)
Date: 27 Dec 2001 15:55:20 -0800
Links: << >>  << T >>  << A >>
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<9vtr81$hs8un$5@ID-84877.news.dfncis.de>...
> "Antonio" <dottavio@ised.it> schrieb im Newsbeitrag
> news:fb35ea96.0112132356.7f43b3fe@posting.google.com...
> > I'm preparing a QPSK modulator,
> > until now I arrange it for a VIRTEX 1000 -4 , but it seem that could
> > be impossible to use it at a maximum clock speed of 165MHz especially
> 
> Virtex-E is faster (and cheaper).
> Virtex-II is even more faster.

Have you looked at Altera's Mercury devices?  They're an all-copper
performance-optimized architecture.  Altera claims ~40% performance
increase over Virtex-II and 150MHz non-pipelined 16x16 multipliers.  I
think the largest part in this family is slightly smaller than the
XCV1000, but would be worth looking at.

Article: 37963
Subject: Re: Choice of Processor Cores in FPGAs - Both Embedded & Soft
From: mostuus@yahoo.com (Stuart Moses)
Date: 27 Dec 2001 16:25:38 -0800
Links: << >>  << T >>  << A >>
The biggest criteria is performance.   What performance do you need? 
A soft-core processor implemented in programmable logic will be slower
than a hard-core processor.  There are several soft-cores available on
the market, some of these are synthesizable Verilog and VHDL verions
of 6502, 8051, etc. or architecture-specific soft-cores such as
Altera's Nios. If you are replacing a 68000 micro in you system, a
Nios will have more horsepower than you would need.

Hard-Core processors in FPGAs include Altera's ARM9 implementation
(@200MHz) and Triscend's ARM7 (@50MHz.)  In this case, the Altera and
Triscend implementations have hard-wired processor bus interfaces,
guaranteeing fast external memory bus speeds & allowing the processor
to power-up and operate before the FPGA is configured (this allows the
processor to configure the device.)  Xilinx had announced something in
a hard-core processor, but I don't believe they're shipping these
parts.

Another important criteria is the S/W development tools and OS support
(if you require an OS.)  Make certain that there are compilers and
debug tools available.  On an ARM or MIPs, OS and tools support will
not be a problem at all.  The Nios includes S/W tools and a debugger
and has two RTOSes and a Linux port.

Hope this helps.

Article: 37964
Subject: Re: ALTERA's Mercury CDR
From: mostuus@yahoo.com (Stuart Moses)
Date: 27 Dec 2001 16:46:29 -0800
Links: << >>  << T >>  << A >>
FYI,

Th Xilinx FAE who blasted Altera's Mercury CDR later realized his
mistake and apologized, but with a new posting, not as a response to
any posting in this thread.  See below:

"I am sorry to have made a basic mistake, and I apologize if I have
mislead
anybody. The question was about Mercury, and I answered it as if it
were about
APEX-II."

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

So for the real scoop:

1. Mercury CDR DOES NOT require a training pattern.  This is a true
Clock-Data recovery circuit.

2. At 1.25Gbps the clock granularity is 14 ps, not the ridiculous
300ps Peter claims.

3. As for driver power consumption, Altera's Quartus provides a
simulation-based power estimator.  Try it youself & see the output
power consumption for 1 bit at 1.25Gbps LVDS.

Note: While APEX and Mercury provide true LVDS drivers and receivers,
Xilinx uses an external resistor network (in addition to the
termination resistor) to generate LVDS levels and a voltage-referenced
input with the LVDS -channel tied to the reference pin for receivers.

Article: 37965
Subject: Re: Choice of Processor Cores in FPGAs - Both Embedded & Soft
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Fri, 28 Dec 2001 01:03:00 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <99d0603.0112271625.5b56fdd1@posting.google.com>,
Stuart Moses <mostuus@yahoo.com> wrote:
>The biggest criteria is performance.   What performance do you need? 
>A soft-core processor implemented in programmable logic will be slower
>than a hard-core processor.  There are several soft-cores available on
>the market, some of these are synthesizable Verilog and VHDL verions
>of 6502, 8051, etc. or architecture-specific soft-cores such as
>Altera's Nios. If you are replacing a 68000 micro in you system, a
>Nios will have more horsepower than you would need.

Also, synthesizeabel cores aren't too big these days.   LEON (a Sparc
V8 clone) supposidly fits in a Virtex 300 at 30-40 MHz.

Also, if you are going with a soft core and need more throughput, you
could always go with a multithreaded core.  4 threads of execution can
buy a significant jump in clock rate (and therefore throughput) at the
cost of greater latency for each individual thread.


-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 37966
Subject: CRC-32 verilog source code
From: Mardin <chens_w@yahoo.com.cn>
Date: Thu, 27 Dec 2001 17:51:40 -0800
Links: << >>  << T >>  << A >>
who can post it?

Article: 37967
Subject: Re: Where could I get a signal waveform editor?
From: "SynaptiCAD Sales" <sales@syncad.com>
Date: Thu, 27 Dec 2001 20:55:17 -0500
Links: << >>  << T >>  << A >>
Hi Kevin,

As someone else already mentioned we have a timing diagram editor
called WaveFormer that sounds like what you're looking for. It also has the
capability of simulating state machine equations, so you can test out your
design in the early stages and use it to automatically generate Verilog or
VHDL stimulus for your design. You can download it from
http://www.syncad.com/syn_down.htm.


best regards,

Dan Notestein
SynaptiCAD Inc



Article: 37968
Subject: How to generate .edn in Webpack ?
From: "Rob Finch" <robfinch@sympatico.ca>
Date: Thu, 27 Dec 2001 21:05:08 -0500
Links: << >>  << T >>  << A >>
How do I generate a .edn file in Webpack ?

Thanks
Rob




Article: 37969
Subject: How to set block ram contents ?
From: "Rob Finch" <robfinch@sympatico.ca>
Date: Thu, 27 Dec 2001 21:06:40 -0500
Links: << >>  << T >>  << A >>
How do I set block ram contents without going through the PAR process ? Can
someone point me to more info ?

Thanks
Rob




Article: 37970
Subject: Re: CRC-32 verilog source code
From: Mardin <chens_w@yahoo.com.cn>
Date: Thu, 27 Dec 2001 18:11:38 -0800
Links: << >>  << T >>  << A >>
it should conform IEEE802.3

Article: 37971
Subject: Re: Innoveda Speedwave vs. Modelsim?
From: Andy Hall <dont_spam_andy@dont_spam_gordian_either.com>
Date: Thu, 27 Dec 2001 19:46:44 -0800
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> Andy Hall wrote:
> 
> >   Hello,
> >
> 
> <snip>
> 
> I've been using ModelSim for a long time now.  As far as I can see its now
> about as bullet-proof, at least for Verilog, as an EDA tool ever gets. The
> only caveat I can see from your point of view is that most of the bugs that
> are turning up these days (you are right about their near-Xilinx level of
> openness) seem to be in Verilog/VHDL mixed simulation or VHDL alone.

  Hi Rick and Newman,

Thanks for the perspective. Everything I'm hearing indicates I'm making
the 
right decision, that makes me feel a lot more comfortable. And the Model
Tech
sales guys haven't made me cringe either, they've been very helpful.
Similar
experience to when I had to buy the Synplify seat a few years ago. 

> > The modelsim unix version has been working fine (tutorials only as
> > yet, I'm sure I'll need to recode something before attacking my main
> > project). Their port of tools written for PCs to the unix platform
> > feels a lot more solid and complete than Innoveda's, which uses a
> > package which translates Windoze calls to unix.
> >
> 
> We have the PC version (aka the -PE) but I was told by a support guy that,
> in fact, all the development work has always been done on Unix/Linux and
> then ported to the PC platform. They had Linux versions running in house a
> long time before they were released.

That explains it! Going in the right direction apparently. :-) That
said, 
I'll also start off with the Windoze version, and see where that goes.

> Surely it wouldn't be too hard with a bit of Perl to make a VHDL netlist
> from the schematic portion of your flow ? Its what we do for board level
> simulation (except, of course, its Verilog).

I agree, that's what we'll have to do; it was just more convenient with
the 
Innoveda tools that we already had.

Thanks again, all! Vacation calls ...

  Andy

Article: 37972
Subject: IPDS 2002 Deadline extended to January 10, 2002
From: sgarg@avaya.com (Sachin Garg)
Date: 27 Dec 2001 19:56:44 -0800
Links: << >>  << T >>  << A >>
******************************************************************

                          CALL FOR PAPERS
International Performance and Dependability Symposium (IPDS) 2002
             June 23 - 26, 2002, Washington DC, U.S.

	          http://www.dsn.org/ipds.html

******************************************************************

******************************************************************
In the year 2002, IPDS will be organized under umbrella of DSN
(Dependable Systems and Networks) Conference, which will take 
place in Washington DC, U.S., June 23 - 26, 2002.
==================================================================

                               OBJECTIVES
With growing strategic importance of large scale networked applications
executing on high-performance computers and broadband communication 
networks, the performance and dependability of computer systems and 
networks have become closely related. Designers and analysts must 
consider the relationships between the occurrence of errors/failures 
and their impact on performance, both in computer systems themselves
and in the interconnections between the system's components.

The International Performance and Dependability Symposium aims to bring
together academic and industrial researchers in these two areas, with 
emphasis on integrating theory and practice. Relating analytical 
techniques to simulations, actual measurements, and experiments will 
be the broad theme of IPDS. Research relating to hardware and software
issues in parallel and distributed systems and networks will be 
emphasized. The topics include but are not restricted to:

            Analytical/Simulation/Measurement Techniques for
            Performance/Dependability applied to:
            Software/Hardware Systems
            Real-Time Systems
            Communication Systems
            Distributed Systems
            Parallel and Clustered Systems
            Multiprocessing Systems
            Systems for Fault-tolerance

===========================================================================
                        INFORMATION FOR AUTHORS
Regular papers describing original research, practical experience
reports, tool descriptions/demonstrations, and panel proposals will 
be refereed and considered for publication in the Proceedings of the
2002 International Conference on Dependable Systems and Networks.

Excessively long submissions, unoriginal work, or work that is 
submitted to multiple venues, will be disregarded. The title page 
should include the title of the paper, author name(s), affiliations,
mailing address, phone number, fax number, and e-mail address, a maximum
150-word abstract, five keywords, the submission category (see above),
an approximate word count, and a declaration that the material has been
cleared through author affiliations. For multi-authored submissions, the
contact author should be indicated.

The format of submissions for review should be single-column, Times 
11-point size, double spacing and no more than:
     20 pages for Regular Papers,
     10 pages for Practical Experience Reports and Tool Descriptions &
        Demonstrations,
      2 pages for Panel proposals.

The format for final, camera-ready submissions that have been accepted
for publication should be in accordance with IEEE standard conference 
format. The paper should be submitted in electronic form: PostScript 
(.ps) or Portable Document Format (.pdf) to:
               http://www.dsn.org/ipds.html#Authors

***************************************************************************

Selected papers submitted under the regular paper category will be 
considered for publication in a special issue of the Performance
Evaluation Journal
 
************************************************************************
                          IMPORTANT DATES
                     Submission:      January 10, 2002
                     Notification:    March 11, 2002

************************************************************************

Program Co-Chairs

Sachin Garg
<sgarg@avaya.com>
Avaya Labs, Avaya, Inc.
233 Mount Airy Road
Basking Ridge, NJ 07920 — USA
Phone: (+1) 908 582 3912
Fax: (+1) 908 582 5809

Zbigniew Kalbarczyk
<kalbar@crhc.uiuc.edu>
Center for Reliable and High Performance Computing
University of Illinois at Urbana-Champaign
1308 W. Main Street
Urbana, IL 61801 — USA
Phone: (+1) 217 244 7110
Fax: (+1) 217 244 5686

Tools Demonstration Chair
M. Kaâniche (LAAS-CNRS, France)
kaaniche@laas.fr

Industry Liaison
L. Votta (Motorola Inc., USA)
lvotta1@email.mot.com


COMMITTEES

Steering Committee
Chair: R. Iyer (U. of Illinois, Urbana, USA)
Co-Chair: K. Trivedi (Duke University, USA)
J. Abraham (U. of Texas, Austin, USA)
A. Avizienis (UCLA, USA)
G. Balbo (U. of Torino, Italy)
R. Chillarege (Opus360 Corp., USA)
R. Geist (Clemson University, USA)
G. Haring (U. of Vienna, Austria)
R. Harper (IBM Research, USA)
J.-C. Laprie (LAAS-CNRS, France)
R. Marie (U. of Rennes, France)
E.J. McCluskey (Stanford U., USA)
W. Sanders (U. of Illinois, Urbana, USA)
M. Woodside (Carleton U., Canada) 

Program Committee
P. Barford (U. of Wisconsin, Madison, USA)
S. Chau (NASA-JPL, USA)
R. Chillarege (Opus360 Corp., USA)
G. Ciardo (College of William & Mary, USA)
J. Dugan (U. of Virginia, USA)
G. Haring (U of Vienna, Austria)
R. Harper (IBM Research, USA)
B. Haverkort (RWTH Aachen, Germany)
L. John (U. of Texas, Austin, USA)
K. Kanoun (LAAS-CNRS, France)
K. Keeton (HP Laboratories, USA)
Y. Levendel (Motorola Inc., USA)
C. Lindemann (U. of Dortmund, Germany)
S. Lumetta (U. of Illinois, Urbana, USA)
H. Madeira (U. of Coimbra, Portugal)
R. Marie (U. of Rennes, France)
P. Mehra (Compaq, USA)
W. Sanders (U. of Illinois, Urbana, USA)
M. Singhal (Ohio State U., USA)
J. Smith (U. of Wisconsin, Madison, USA)
A. Tai (I.A. Tech, Inc., USA)
M. Telek (Tech. U. of Budapest, Hungary)
T. Tsai (Avaya Inc., USA)
N. Vaidya (U. of Illinois, Urbana, USA)
A. van Moorsel (HP, USA)
M. Vouk (North Carolina State U., USA)

Ex Officio: R. Iyer and K. Trivedi

Article: 37973
Subject: memory arbiter
From: "H.L" <alphaboran@yahoo.com>
Date: Fri, 28 Dec 2001 10:09:34 +0200
Links: << >>  << T >>  << A >>
Hello all and Happy New Year,
I have 3 modules that read and write in three different RAMs, these modules
can't access the same RAM in the same time so I am now worried about any
conflicts. So far, I have made a big combinatorial module that is
responsible for the memories arbitration but during PAR I get many timing
errors (230). I am going now to use 3 bus MUX (unregistered) from CORE
GENERATOR, do you think that this is better solution to my problem? Finally,
do you think that I 'd rather use registered MUX instead?

Best Regards,
Harris Linardakis



Article: 37974
Subject: Re: CRC-32 verilog source code
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 28 Dec 2001 09:36:21 GMT
Links: << >>  << T >>  << A >>
Mardin <chens_w@yahoo.com.cn> writes:

>who can post it?

What conditions does it have to run under?

Bit serial?  8 bit parallel?  32 bit parallel?  

Each is faster, but much more complicated than the previous one.

Ethernet runs bit serial using a 32 bit shift register and a bunch
of XOR gates.  Simple enough to build 20 or so years ago.

"Numerical Recipes" has a pretty good description of CRC, 
a little theory and some practical code.  

When is the homework assignment due?

-- glen



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

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

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

Custom Search