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

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

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

Custom Search

Messages from 42950

Article: 42950
Subject: FPGA Development Boards for Xilinx Virtex II 2V6000 & HandelC Support
From: "Dr. Andy Nisbet" <Andy.Nisbet@cs.tcd.ie>
Date: Wed, 8 May 2002 13:23:02 +0100
Links: << >>  << T >>  << A >>
Hello,
we are seeking to purchase 3 FPGA development boards, hopefully having >=4
banks of SRAM offering total storage >= 8M. We have had some quotes from
Alpha Data in the UK, but unfortunately they do not currently offer a
HandelC board support package.

We would prefer not to have to write our own support package, as this would
take us a few weeks to design and test, and are interested to learn of the
URLs of companies supplying FPGA development boards supporting HandelC?
Obviously, I already know about Celoxica ...

Thanks,
            Andy
--
Dr. Andy Nisbet, ORI.LG.19, Dept. of Computer Science,
              Trinity College, Dublin 2, Ireland
              Email: Andy.Nisbet@cs.tcd.ie
Phone: +353-(01)-608-3682      FAX: +353-(01)-677-2204




Article: 42951
Subject: Re: JTAG 5V tollerance...?
From: Laurent Gauch <laurent.gauch@amontec.com>
Date: Wed, 08 May 2002 14:29:16 +0200
Links: << >>  << T >>  << A >>
SPARTAN II yes
VIRTEX no (maybe with a 100 serial R)
VIRTEXII no

Laurent Gauch
www.amontec.com

Pawe³ J. Rajda wrote:

> Hallo,
> 
> Are the TAP pins 5V tollerant in SpartanII/Virtex/VirtexII devices?
> 
> --
> Regards,
> Pawel J. Rajda
> 
> 
> 


Article: 42952
Subject: Re: JTAG 5V tollerance...?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 8 May 2002 14:34:11 +0200
Links: << >>  << T >>  << A >>
"Pawe³ J. Rajda" <pjrajda@uci.agh.edu.pl> schrieb im Newsbeitrag
news:3CD8FD3A.C1616C09@uci.agh.edu.pl...
> Hallo,
>
> Are the TAP pins 5V tollerant in SpartanII/Virtex/VirtexII devices?

SpartanII and Virtex are direct 5V tolerant.
Virtex-II needs a >100 OHm series resistor.

--
MfG
Falk





Article: 42953
Subject: PAR warnings and errors
From: "H.L" <alphaboran@yahoo.no-spam.com>
Date: Wed, 8 May 2002 16:25:16 +0300
Links: << >>  << T >>  << A >>
Hello all,
in the ucf file I have some signals LOC constrained, some of them I want to
be of LVDS standard. During PAR I get the following:

WARNING:Place:1866 - The IOB output XXXXX needs an another
   associated output to complete the LVDS pair requirement.

ERROR:Place:1868 - The IOB component YYY has an IO standard
   of LVDS which must be placed with locate constraints to specific IOB
   locations that support this standard. The current location AJ11 is not a
   possible differential signal location.

AJ11 is  a  IO pin in the Virtex-E I use.

ERROR:Place:1869 - The IOB component ZZZZZ has an IO standard
   of LVDS which must be placed with locate constraints to specific IOB
   locations that support this standard. The current location AN23 is not a
   Positive/Master IOB location. Refer to the application note for
differential
   signaling.

AN23 is a IO_VREF_L122N_YY pin

Can someone tell me why these messages appear?

Best Regards,
Harris



Article: 42954
Subject: bug in XST ?
From: Tullio Grassi <tullio@physics.umd.edu>
Date: Wed, 08 May 2002 09:46:29 -0400
Links: << >>  << T >>  << A >>
The following verilog module (for a Virtex-E) contains a inout signal
"LocData".
This is syntesized correctly as a bidirectional port with FPGA-Express
or with Foundation,
while XST (in ISE4.2) synthesizes an output port (just check the pad
report).
The only work-around with XST that I found is to instantiate the IOBUF
primitive. 



////////////////////////////////////////////////////////////////////////////////////

module XLocBusSlave
	(
	clk,			rst,	
	LocAddr,		LocData,
	LocCS_b,		LocWRITE_b,

	DLL_lock,		LastTTCcommand,	// to Status Reg
	VME_Hard_rst,	VME_Soft_rst,		// from CntrReg
	VME_Start,		VME_Stop,
	Fake_Input,
	HTRsubmodN,			PipeLength,
	InSpyFIFO_empty,	InSpyFIFO_full,
	L2OutSpyFIFO_empty,	L2OutSpyFIFO_full,		// to FIFO_StatReg
	DataTrigFIFO_empty,	DataTrigFIFO_full,
	FE_link_ERR, FE_link_DV,					// to FE_StatReg
			
 	InSpyFIFO1_out,		InSpyFIFO2_out,		
	InSpyFIFO3_out,		InSpyFIFO4_out,			
	InSpyFIFO5_out,		InSpyFIFO6_out,			
	InSpyFIFO7_out,		InSpyFIFO8_out,
	L2OutSpyFIFO_out,
	
	DataTrigFIFO_WR,
	InSpyFIFO1_RD,  	InSpyFIFO2_RD,
	InSpyFIFO3_RD,		InSpyFIFO4_RD,
	InSpyFIFO5_RD,		InSpyFIFO6_RD,	
	InSpyFIFO7_RD,		InSpyFIFO8_RD,	
	L2OutSpyFIFO_RD,
	fifo_wr_data,
	LB_STATE
	);

	parameter 
        FPGAversionN            =   1,  // design version Number
readable from VME
 	REG_WIDTH		=  25,	//  was 32
	InSpyFIFO_WIDTH		=  18,
	L2OutSpyFIFO_WIDTH	=  24,	
	Writeble_FIFOs_WIDTH    =  25,   // was 32
	LB_Addr_Size		=  20,	// Size of LocAddr
	
	//  Parameters used for the STATEs of the LocBus FSM
	IDLE		=	0, //  Waiting for the negative transition on LocCS_b
	RD_OR_WR	=	1, //  Wait for DS_b and after check WRITE_b.	
	MASTER_WRITE	=	2, //  If WR mode, then Store data
	MASTER_READ	=	3, //  If RD mode, then Fetch data
	END_OF_READ	=	4, //  Stop RD pulses and wait for posedge of LocCS_b
	END_OF_WRITE    =	5, //  Stop WR pulses and wait for posedge of LocCS_b
	END_CYCLE	=	6; //  Set Data lines to HiZ (has to be after posedge)

// these ports connect to the LocalBus
	input	LocCS_b;	// Chip Select
	input	LocWRITE_b;	// LOW = Write ; HIGH = Read
	input	[LB_Addr_Size-1:0]	LocAddr;	// The Address bus.
	inout	[REG_WIDTH-1:0]	 	LocData;	// The bidir Data bus: was [31:0] 
 
// these ports connect to the rest of the FPGA
	input	clk,	rst;

	input	DLL_lock;												// to Status Reg
	input	[7:2] LastTTCcommand;									// to Status Reg
	output	VME_Hard_rst, VME_Soft_rst, VME_Start, VME_Stop, Fake_Input;   
// from Cntr Reg
	input	[7:0]	InSpyFIFO_empty, InSpyFIFO_full;				// to FIFO_StatReg
	input			L2OutSpyFIFO_empty, L2OutSpyFIFO_full;			// to FIFO_StatReg
	input			DataTrigFIFO_empty, DataTrigFIFO_full;			// to FIFO_StatReg
	input	[8:1]	FE_link_ERR, FE_link_DV;						// to FE_StatReg
	
	output	[REG_WIDTH-1:0]	HTRsubmodN;		 // {GA[4:0],T} T=1 for Top FPGA
	output	[REG_WIDTH-1:0]	PipeLength;

	// Data from the 8 Input Spy FIFOs 
	input 	[InSpyFIFO_WIDTH-1:0]	InSpyFIFO1_out,
					InSpyFIFO2_out,
					InSpyFIFO3_out,
					InSpyFIFO4_out,
					InSpyFIFO5_out,
					InSpyFIFO6_out,
					InSpyFIFO7_out,
					InSpyFIFO8_out;  
	// Data from the L2output Spy FIFOs
	input 	[L2OutSpyFIFO_WIDTH-1:0]	L2OutSpyFIFO_out;  

	// Read and Write commands to FIFOs (synchronous, 1 tick pulses)		
	output	DataTrigFIFO_WR;			   
	output  InSpyFIFO1_RD,	 	InSpyFIFO2_RD,
		InSpyFIFO3_RD,		InSpyFIFO4_RD,
		InSpyFIFO5_RD,		InSpyFIFO6_RD,	
		InSpyFIFO7_RD,		InSpyFIFO8_RD;
	output	L2OutSpyFIFO_RD;

	output	[Writeble_FIFOs_WIDTH-1:0]	fifo_wr_data;	// tied externally to
all FIFOs with write access
	output  [2:0]	LB_STATE;		// for debugging
		
	reg 	LocDir;
	wire	DLL_lock;
	reg	[REG_WIDTH-1:0]	HTRsubmodN;	 
	reg	[REG_WIDTH-1:0]	PipeLength;
	reg	DataTrigFIFO_WR;
	reg	InSpyFIFO1_RD,	InSpyFIFO2_RD,	InSpyFIFO3_RD,	InSpyFIFO4_RD,
		InSpyFIFO5_RD,	InSpyFIFO6_RD,	InSpyFIFO7_RD,	InSpyFIFO8_RD;
	reg	L2OutSpyFIFO_RD;
	
//     INTERNAL SIGNALS
	wire	[REG_WIDTH-1:0]	StatusReg, FIFO_StatReg, FE_StatReg;
	reg	[REG_WIDTH-1:0]	CntrReg;
	wire	VME_Hard_rst, VME_Soft_rst, VME_Start, VME_Stop, Fake_Input; //
from Cntr Reg	
	reg 	LocCS_Del_0, LocCS_Del_1, LocCS_Del_2;    // delayed versions of
CS
	reg	[2:0]	LB_STATE;	
	wire	[REG_WIDTH-1:0]  D_IN;	 //  for registring LocData   ; was [31:0]
	reg	[REG_WIDTH-1:0]	D_OUT;	 //  for sending LocData      ; was [31:0]
	
//	ACTUAL CODE STARTS HERE
  assign  D_IN		                =	LocData;
  assign  fifo_wr_data	                =	D_IN;
  assign  StatusReg[0]	                =	DLL_lock;
  assign  StatusReg[1]	                =	0;
  assign  StatusReg[7:2]                =	LastTTCcommand[7:2];
  assign  StatusReg[REG_WIDTH-1:8]      =	0;	// unused portion of status
reg
  assign  FIFO_StatReg[7:0]             =	InSpyFIFO_empty[7:0];
  assign  FIFO_StatReg[15:8]            =	InSpyFIFO_full[7:0];
  assign  FIFO_StatReg[16]              =	L2OutSpyFIFO_empty;
  assign  FIFO_StatReg[17]              =   L2OutSpyFIFO_full;
  assign  FIFO_StatReg[18]              =	DataTrigFIFO_empty;
  assign  FIFO_StatReg[19]              =	DataTrigFIFO_full;
  assign  FIFO_StatReg[REG_WIDTH-1:20]	=	0;	// unused portion of status
reg
  assign  FE_StatReg[7:0]		=	FE_link_ERR[8:1]; 
  assign  FE_StatReg[15:8]	        =	FE_link_DV[8:1];
  assign  FE_StatReg[REG_WIDTH-1:16]	=	0;	// unused portion of status
reg
  assign  VME_Hard_rst		        =	CntrReg[0];
  assign  VME_Soft_rst		        =	CntrReg[1];
  assign  VME_Start			=	CntrReg[2];
  assign  VME_Stop			=	CntrReg[3];
  assign  Fake_Input			=	CntrReg[8];
	
//	tristate buffer declarations	
//bufif1 [inst name] (output,input,oe);
	bufif1	buf_D_0		(LocData[0],	D_OUT[0],	LocDir);
	bufif1	buf_D_1		(LocData[1],	D_OUT[1],	LocDir);
	bufif1	buf_D_2		(LocData[2],	D_OUT[2],	LocDir);
	bufif1	buf_D_3		(LocData[3],	D_OUT[3],	LocDir);

	bufif1	buf_D_4		(LocData[4],	D_OUT[4],	LocDir);
	bufif1	buf_D_5		(LocData[5],	D_OUT[5],	LocDir);
	bufif1	buf_D_6		(LocData[6],	D_OUT[6],	LocDir);
	bufif1	buf_D_7		(LocData[7],	D_OUT[7],	LocDir);
		
	bufif1	buf_D_8		(LocData[8],	D_OUT[8],	LocDir);
	bufif1	buf_D_9		(LocData[9],	D_OUT[9],	LocDir);
	bufif1	buf_D_10	(LocData[10],	D_OUT[10],	LocDir);
	bufif1	buf_D_11	(LocData[11],	D_OUT[11],	LocDir);
		
	bufif1	buf_D_12	(LocData[12],	D_OUT[12],	LocDir);
	bufif1	buf_D_13	(LocData[13],	D_OUT[13],	LocDir);
	bufif1	buf_D_14	(LocData[14],	D_OUT[14],	LocDir);
	bufif1	buf_D_15	(LocData[15],	D_OUT[15],	LocDir);
		
	bufif1	buf_D_16	(LocData[16],	D_OUT[16],	LocDir);
	bufif1	buf_D_17	(LocData[17],	D_OUT[17],	LocDir);
	bufif1	buf_D_18	(LocData[18],	D_OUT[18],	LocDir);
	bufif1	buf_D_19	(LocData[19],	D_OUT[19],	LocDir);
		
	bufif1	buf_D_20	(LocData[20],	D_OUT[20],	LocDir);
	bufif1	buf_D_21	(LocData[21],	D_OUT[21],	LocDir);
	bufif1	buf_D_22	(LocData[22],	D_OUT[22],	LocDir);
	bufif1	buf_D_23	(LocData[23],	D_OUT[23],	LocDir);
		
	bufif1	buf_D_24	(LocData[24],	D_OUT[24],	LocDir);
/*	bufif1	buf_D_25	(LocData[25],	D_OUT[25],	LocDir);
	bufif1	buf_D_26	(LocData[26],	D_OUT[26],	LocDir);
	bufif1	buf_D_27	(LocData[27],	D_OUT[27],	LocDir);
		
	bufif1	buf_D_28	(LocData[28],	D_OUT[28],	LocDir);
	bufif1	buf_D_29	(LocData[29],	D_OUT[29],	LocDir);
	bufif1	buf_D_30	(LocData[30],	D_OUT[30],	LocDir);
	bufif1	buf_D_31	(LocData[31],	D_OUT[31],	LocDir);    */
	
    //  I prefere a synchronous reset, as VME_res is from the FSM
	always@(posedge clk)
		begin	 //   RESET
		if(rst==1)
			begin
			LB_STATE		<=	IDLE;
			LocDir			<=	0;	//	LocData set as input (HiZ)
			LocCS_Del_2		<=	1;	//	CS is active low			   
			LocCS_Del_1		<=	1;
			LocCS_Del_0		<=	1;
 			
			DataTrigFIFO_WR	<=	0;
			InSpyFIFO1_RD	<=	0;		 	InSpyFIFO2_RD	<=	0;
			InSpyFIFO3_RD	<=	0;			InSpyFIFO4_RD	<=	0;
			InSpyFIFO5_RD	<=	0;			InSpyFIFO6_RD	<=	0;	
			InSpyFIFO7_RD	<=	0;			InSpyFIFO8_RD	<=	0;	
			L2OutSpyFIFO_RD	<=	0;			
			CntrReg			<=	'h0;  // this also self-reset the CmtrReg initial case
of VME reset commands
			HTRsubmodN		<=	'h1;		
			PipeLength		<=	'hA;
			D_OUT	<=	'd0;
			end	//   END of RESET 
		else	// posedge clk
			begin				 
			LocCS_Del_0	<=	LocCS_b;		// FF to avoid metastability
			LocCS_Del_1	<=	LocCS_Del_0;
			LocCS_Del_2	<=	LocCS_Del_1;  // total of 3Tck = 75 ns delay on CS
			
			case(LB_STATE)
				
				IDLE:	// check for a negative edge on LocCS_b (digitally filtered)
					begin
					if(LocCS_Del_2 == 1 && LocCS_Del_1==0)	
						LB_STATE	<=	RD_OR_WR;
					end
						
				RD_OR_WR: //  decide whether it is a READ or a WRITE
					begin
					if(LocWRITE_b==0)
							LB_STATE<=	MASTER_WRITE; //	Write operation (master's point of
view)
					else   //	LocWRITE_b=1
						begin
						LB_STATE<=	MASTER_READ;	//	Read operation (master's point of view)
						LocDir<= 1; 		//	Set Data lines toward LocalBus
						end	//	else
					end					
						
				MASTER_WRITE:	//  ******   WRITE operation  *******
					begin
						case(LocAddr)		// decode which register is addressed
																	
							'h10:	
								begin
								CntrReg		<=	D_IN[REG_WIDTH-1:0];
								end					  									
							'h14: 
								begin
								HTRsubmodN	<=	D_IN[REG_WIDTH-1:0];	   
								end
							'h20:			// WRITE to DataTrig FIFO 
								begin
								DataTrigFIFO_WR	<=1;
								end																								
 							'h32: 
							 	begin
							 	PipeLength	<=	D_IN[REG_WIDTH-1:0];
								end	
																						 
							 default:	  	 ;
									// if there is no such register or is read-only 
									// no action (will go anyway to END_RD_OR_WR)
						endcase		// 	 (LocAddr)
 						LB_STATE	<=	END_OF_WRITE;					
					end				//	end of MASTER_WRITE case

				MASTER_READ:	//	READ OPERATION
					begin
						case(LocAddr)	// decode which register is addressed
							'h11:
								begin
								D_OUT[REG_WIDTH-1:0]		<=	StatusReg;
								end								
							'h12:
								begin
								D_OUT[REG_WIDTH-1:0]		<=	FIFO_StatReg;
								end								
							'h13:
								begin
								D_OUT[REG_WIDTH-1:0]		<=	FE_StatReg;
								end								
							'h14: 
								begin
								D_OUT[REG_WIDTH-1:0]		<=	HTRsubmodN;
								end								
							'h15: 
								begin
								D_OUT[REG_WIDTH-1:0]		<=	FPGAversionN;
								end		
							'h20:	 //  DataTrig FIFO is write-only
								begin
								D_OUT[REG_WIDTH-1:0]	<=	'H C1A0;
								end	
							// FIFO section
							// generate Fifo_RD pulse; the data will be available
							// on the next cycle
							'h21:	 //  Input Spy FIFO1
								begin
								D_OUT[InSpyFIFO_WIDTH-1:0]	<=	InSpyFIFO1_out;
								InSpyFIFO1_RD				<=  1'b1;		  
								end	
							'h22:	 //  Input Spy FIFO2
								begin
								D_OUT[InSpyFIFO_WIDTH-1:0]	<=	InSpyFIFO2_out;
								InSpyFIFO2_RD				<=  1'b1;		  
								end	
							'h23:	 //  Input Spy FIFO3
								begin
								D_OUT[InSpyFIFO_WIDTH-1:0]	<=	InSpyFIFO3_out;
								InSpyFIFO3_RD				<=  1'b1;		  
								end	
							'h24:	 //  Input Spy FIFO4
								begin
								D_OUT[InSpyFIFO_WIDTH-1:0]	<=	InSpyFIFO4_out;
								InSpyFIFO4_RD				<=  1'b1;		  
								end	
							'h25:	 //  Input Spy FIFO5
								begin
								D_OUT[InSpyFIFO_WIDTH-1:0]	<=	InSpyFIFO5_out;
								InSpyFIFO5_RD				<=  1'b1;		  
								end	
							'h26:	 //  Input Spy FIFO6
								begin
								D_OUT[InSpyFIFO_WIDTH-1:0]	<=	InSpyFIFO6_out;
								InSpyFIFO6_RD				<=  1'b1;		  
								end	
							'h27:	 //  Input Spy FIFO7
								begin
								D_OUT[InSpyFIFO_WIDTH-1:0]	<=	InSpyFIFO7_out;
								InSpyFIFO7_RD				<=  1'b1;		  
								end	
							'h28:	 //  Input Spy FIFO8
								begin
								D_OUT[InSpyFIFO_WIDTH-1:0]	<=	InSpyFIFO8_out;
								InSpyFIFO8_RD				<=  1'b1;		  
								end	
							'h31:	 //  L2out Spy FIFO
								begin
								D_OUT[L2OutSpyFIFO_WIDTH-1:0]	<=	L2OutSpyFIFO_out;
								L2OutSpyFIFO_RD				<=  1'b1;		  
								end	
							 //    End of FIFO section

 							'h32: 
							 	begin
								D_OUT[REG_WIDTH-1:0]		<=	PipeLength;
								end																						 
						default:
								 ;
								// if there is no such register or is read-only 
								// no action (will go anyway to END_RD_OR_WR)
						endcase	 //  (LocAddr)
						LB_STATE	<=	END_OF_READ;					
					end	  	//	MASTER_READ  case
						
				END_OF_READ:
					begin									 
					// release Fifo_RD						
					InSpyFIFO1_RD		<=	0;
    				InSpyFIFO2_RD		<=	0;
					InSpyFIFO3_RD		<=	0;
					InSpyFIFO4_RD		<=	0;
					InSpyFIFO5_RD		<=	0;
					InSpyFIFO6_RD		<=	0;	
					InSpyFIFO7_RD		<=	0;
					InSpyFIFO8_RD		<=	0;	
					L2OutSpyFIFO_RD		<=	0;
					if(LocCS_Del_2 == 0 && LocCS_Del_1==1)		// positive edge of
LocCS_b	  
						LB_STATE		<=	END_CYCLE;
					end	 // END_OF_READ case
					
				END_OF_WRITE:
					begin		
					DataTrigFIFO_WR		<=	0;			
					CntrReg[7:0]		<=	0; 			// self-reset of LSBy to generate pulses
					if(LocCS_Del_2 == 0 && LocCS_Del_1==1)		// positive edge of
LocCS_b	  
						LB_STATE		<=	END_CYCLE;
					end
					
				END_CYCLE:	
					begin					
						LocDir		<=	0;	// data lines->HiZ a few ticks after posedge of CS_b
						LB_STATE		<=	IDLE;
					end
			endcase		//  end the case related to the LB_STATE variable
			end			// else posedge clk
		end				// always
endmodule
//////////////////////////////////////////////////////

Article: 42955
Subject: Re: PAR warnings and errors
From: hamish@cloud.net.au
Date: 08 May 2002 13:54:23 GMT
Links: << >>  << T >>  << A >>
H.L <alphaboran@yahoo.no-spam.com> wrote:
> Hello all,
> in the ucf file I have some signals LOC constrained, some of them I want to
> be of LVDS standard. During PAR I get the following:

> WARNING:Place:1866 - The IOB output XXXXX needs an another
>   associated output to complete the LVDS pair requirement.

> ERROR:Place:1868 - The IOB component YYY has an IO standard
>   of LVDS which must be placed with locate constraints to specific IOB
>   locations that support this standard. The current location AJ11 is not a
>   possible differential signal location.

> AJ11 is  a  IO pin in the Virtex-E I use.

Does it have a differential name like IO_VREF_L122N_YY?

> AN23 is a IO_VREF_L122N_YY pin

> Can someone tell me why these messages appear?

Do you have both the P and N pins of the pair location constrained
to the appropriate pins? I think you need to.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 42956
Subject: Re: Xilinx 2GB limit... something has to be done
From: hamish@cloud.net.au
Date: 08 May 2002 14:05:17 GMT
Links: << >>  << T >>  << A >>
David Hawke <dhawke@xilinx.com> wrote:
> Have you tried loading the design without the *.pcf file. The memory limit
> *shouldn't* be hit unless you have a very large number of constraints to
> annotate.

By the way, is there an advantage in having fpga_editor load in the PCF?

I've found it to be a bit of a nuisance on occasion - you can't delete
any location-locked I/Os, so you can't delete pins to replace them with
probes etc.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 42957
Subject: Re: DDR reference design
From: spam_hater_7@email.com (Spam Hater)
Date: Wed, 08 May 2002 14:20:20 GMT
Links: << >>  << T >>  << A >>

Xilinx has two DDR reference designs available for free.

And (almost) worth every penny.



On 8 May 2002 00:45:00 -0700, eyals@hywire.com (Eyal Shachrai) wrote:

>Hi ,
>
>I'm working on a project which involves a xilinx's virtex-ii fpga.
>the core of this fpga will run with a 125 MHz clock and interface with
>a 250 MHz data rate DDR SRAM.
>I would like to know whether xilinx have a reference design of a DDR
>SRAM controller. and if not , would it be smart to use the QDR
>referance design (xapp 262) with some modifications , as a DDR
>controller?
>
>Thanks 
>	Eyal.


Article: 42958
Subject: Re: Xilinx 2GB limit... something has to be done
From: Stephan Neuhold <stephan.neuhold@xilinx.com>
Date: Wed, 08 May 2002 15:20:43 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------E7851447BC413AC0C52278BE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If you want to run TRCE through FPGA Editor then you need to read in the pcf
file.  I can't think of any other real reason to do this

Stephan

hamish@cloud.net.au wrote:

> David Hawke <dhawke@xilinx.com> wrote:
> > Have you tried loading the design without the *.pcf file. The memory limit
> > *shouldn't* be hit unless you have a very large number of constraints to
> > annotate.
>
> By the way, is there an advantage in having fpga_editor load in the PCF?
>
> I've found it to be a bit of a nuisance on occasion - you can't delete
> any location-locked I/Os, so you can't delete pins to replace them with
> probes etc.
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>



Article: 42959
Subject: Re: Opinions on FPGA cores - best for a commercial project?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 08 May 2002 07:39:41 -0700
Links: << >>  << T >>  << A >>
Guy,

A really excellent posting.

Austin

Guy Schlacter wrote:

> Alex -
> Here is some advice from an ex-Altera employee of 10 years.(requested
> disclosure)
> I took a quick browse of your website and realize that you are a small
> company.  It is unclear the extent of your staffing and engineering
> capabilities
> but non the less it appears that you do not have the inhouse expertise
> for the
> customization and chip development.  I base this speculation purely on
> the news releases of your website and open positions.
>
> Anyway - being that you currently lack the true in house expertise and
> that you
> are a startup here below are my suggestions. HOwever here are some of
> the
> facts that I took into consideration for these suggestions...
> a.  you are a startup and no matter how well funded - cash is king
> b.  not every great idea succeeds (lots of competition for wireless
> broadband)
> c.  volumes are not yet truely defined unless you have minimums based on
> a contract with cusotmer
> d.  luckily PCI is a fairly mature spec and many people have experience
>
> recommendations:
> 1.  inficon should create the high level specification for what needs to
> be developed for the whole chip or chip-set
> 2.  implement a stagged solution that will reduce risk and ultimately
> maximize profit
> 3.  for ultimate risk reduction use FPGA technology for prototypes (hash
> out any bugs/spec changes) into initial-mid production
> 4.  rather than spin it yourself, obtain a Fixed Bid from an FPGA
> consultant partner program
>     You will be able to find a consulting firm (my info below) with PCI
> experience with IP from the vendor
> 5.  You should consider the initial project/bid from the consulting firm
> to just include development of the low level spec such that
>     risk is further reduced and better fix-bid can be presented for full
> implementation
> 6.  involve your local FPGA vendor's sales teams
> 7.  once the high level spec and other details have been worked through,
> estimate the size of the
>     actual FPGA device you will need and its embedded resources (ask
> consultant)
> 8.  ask your FPGA vendor to provide you quotes for different volume
> levels - specify the time fram for each volume level too
> 9.  ask your FPGA vendor what other suggestions they could make to
> further reduce solution cost - example Altera Hard Copy
> (non-programmable reduced cost) or
>     or Xilinx Easy Path (reduced cost but still needs configuration)
> 10. ask about IP source code - I know Altera will provide a quote if you
> do need to ultimately go asic
>
> This approach should reduce Inficon's risk yet provide an optimum manner
> to implement your design needs,
> reduce both technical and cost risks, minimize direct personnel
> expenses, and maximize ultimate profits.
>
> Many people jump to the conclusion that an asic would be best here since
> you mentioned Millions of units.
> However, being that it appears that you have unproven technology, your
> specs may change or evolve which
> is much better suited toward FPGAs especially since time to market will
> likely be important too.
>
> I likely forgot to mention something but it is "after hours" :-)
>
> Below is my contact information should you want to discuss further...
> Best of Luck,
> Guy Schlacter
> g.schlact@-nospamm-attbi.com
> http://absoluteconsulting.home.attbi.com
>
> "Alex Rast" <arast@inficom.com> wrote in message
> news:llDB8.174$vz5.79857@news.uswest.net
>
> > OK, I apologize in advance. What I'm asking is virtually guaranteed to start a
> > firestorm. I realize that this is a topic about which people will have both
> > strong biases and vested interests. So, before starting, I beg everybody:
> > Please, let's not turn this question into a battle of opposing polemics.
> >
> > I'm involved in a commercial project with projected volumes into the 100's of
> > thousands if not millions per month. We've got a PCI card, and we've decided
> > to implement the PCI interface in an FPGA, along with multiple other
> > functions.
> >
> > What I would like is opinions as to the best PCI core developers. Let's say
> > for the moment that the FPGA brand isn't particularly important, or is open to
> > change. I don't care if the core in question comes from the FPGA manufacturer,
> > a third-party vendor or consultant, or a freeware download. We'd like people's
> > real-world experiences as to which cores work reliably, efficiently, at high
> > speed, bug-free, and in full compliance with the spec.
> >
> > Also, are there any cores where the source code isn't supplied and/or isn't
> > modifiable? If so, I'd like to get some perspective on the quality/reliability
> > of such "hard-coded" cores as opposed to "soft" cores which the user can
> > modify as needed.
> >
> > I'd also like to know whether the cores that you recommend are 33 MHz, 66 MHz,
> > what version of PCI they're compliant with, and whether they're target,
> > master, or bridge. If the developer supplies various different types, and if
> > you have experience, give me your opinions on each version if possible, so I
> > can see how the relative merits stack up for each implementation.
> >
> > Alex Rast
> > arast@inficom.com
> > arast@qwest.net
>
> --
> Posted via Mailgate.ORG Server - http://www.Mailgate.ORG


Article: 42960
Subject: Problem when simulating post P&R, with SDF
From: zisisj@yahoo.com (gianzi)
Date: 8 May 2002 07:42:03 -0700
Links: << >>  << T >>  << A >>
Hi all,
When I simulate a gate-level model produced by the synthesis or P&R of
my
vhdl source everything works fine. But when I add the SDF file to the
simulator some of my signals get unknown values ('X' es). In detail
these signals such as "enable" that are asserted in  a state machine.
Here is the code. The tool I use for synthesis is FPGA Express and for
P&R is ISE 4.1 SP3. Thanx in advance for any help.

type state_type is (idle, four_ws, six_ws);
signal cs, ns : state_type;
signal go : std_logic;
signal counter : integer range 0 to 255;
signal enable : std_logic;

FF : process(rst, clk, cs, ns, counter)
begin
  if rst = '1' then
    counter <= 0;
    cs <= idle;
  elsif rising_edge(clk) then
    cs <= ns;
    if cs = idle then
      counter <= 0;
    else
      counter <= counter + 1;
    end if;
  end if;
end process; 

COMB : process(cs, counter, go)
begin
  case cs is
  when idle =>
    enable <= '0';
    if go = '1' then
      ns <= four_ws;
    else
      ns <= idle;
    end if;
  when four_ws =>
    case counter is
      when 0 to 3 =>
        enable <= '0';
        ns <= four_ws;
      when 4 =>
        enable <= '1';
        ns <= six_ws;
      when others =>
        null;
    end case;
  when six_ws =>
    case counter is
      when 5 to 10 =>
        enable <= '0';
        ns <= six_ws;
      when 11|12 =>
        enable <= '1';
        ns <= six_ws;
      when 13
        enable <= '0';
        ns <= idle;
      when others =>
        null;
    end case;
end process;

Article: 42961
Subject: Re: JTAG 5V tollerance...?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 08 May 2002 07:42:42 -0700
Links: << >>  << T >>  << A >>
Slight modification:

Anything is tolerant with 100 ohms (ie Virtex E and Virtex II with 100
ohms are 5V tolerant).

There was a "not 5V tolerant" in an early datasheet, but it was pulled,
and replaced with the suggestion to use a 100 ohm resistor when
interfacing to a 5V system, just like what is done with Virtex E.

Austin

Laurent Gauch wrote:

> SPARTAN II yes
> VIRTEX no (maybe with a 100 serial R)
> VIRTEXII no
>
> Laurent Gauch
> www.amontec.com
>
> Pawe³ J. Rajda wrote:
>
> > Hallo,
> >
> > Are the TAP pins 5V tollerant in SpartanII/Virtex/VirtexII devices?
> >
> > --
> > Regards,
> > Pawel J. Rajda
> >
> >
> >


Article: 42962
Subject: Bit file format
From: "michael m" <stuckatone@yahooo.com>
Date: Wed, 8 May 2002 08:16:00 -0800
Links: << >>  << T >>  << A >>
I'm searching for info on the format of bit file specifically the raw data section.  I have located information on header fields but can't find anything on the "raw data" section that programs the FPGA.

Any info on the the "raw data" stucture of a 2 input AND gate and 2 input OR gate would be great.

Mike (stuckatone@yahoo.com)

Article: 42963
Subject: Re: State machine synthesis
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Wed, 08 May 2002 18:26:22 +0200
Links: << >>  << T >>  << A >>
Hi John!


> I've developed a simple state machine targetted at an XC4010 FPGA, which
> writes values to an external SRAM.
... 
> As I said, the design does a behavioural sim perfectly, but when I do a
> post P&R sim it fails completely, with the outputs all going undefined
> very soon after the sim starts.  I downloaded the design to the chip
> and, unsurprisingly, it failedto work there either!

I did not read your code completely ... because it is a litte bit much
for the moment. ;-)
Some hints:

Whats happens, if you synthesize the design and simulate with the
netlist?

Locate as much combinational logic or easy-to-understand-parts as you
can and put it into components. Then synthesize these components (not
P&R) and simulate the synthesized components within the behavior model
of the main block.

Try to redesign as much registers (latches / ffs) as you can to pure
combinational logic.

Are Latches allowed at your target FPGA? (I have worked on a Xilinx
Virtex a year ago, that did not support latches.)
 

>   -- register the state variable
>   state_reg:process(reset,clk)
>   begin
>     if(reset='1') then
>       cur_state <= init;
>     elsif(clk'event and clk='1') then
>       if(en='1') then
>         -- normal state progression
>         cur_state <= next_state;
>       else
>         -- hold in init state if en='0'
>         cur_state <= init;
>       end if;
>     end if;
>   end process;

The signals "en", "next_state" are not in the sensitivity list. This may
result in differences between behavioral simulation an synthesized sim.
Because of the FFs you have inferred, this should not lead to serious
trouble, but I would be careful.
 
>   -- state transition process
>   state_update:process(cur_state,d_in,strobe)
>   begin
...
>         if pointer<32767 then  -- don't wrap past top of RAM
>           pointer <= pointer+1;  -- increment the address for next time
>           next_state <= wait_strobe_low;
>         else
>           next_state <= finished;
>         end if;

1st: pointer is not in the sensitivity list. This will result in errors,
because it is modelled as a latch.
2nd: You assign the output of the latch plus 1 to the input, when the
input is enabled. This is a loop. -> In pseudo-code:
pointer=((((...(pointer+1)...)+1)+1)+1)

 
Ralf

Article: 42964
Subject: trace report
From: sanjay parekh <saparekh@nortelnetworks.com>
Date: Wed, 08 May 2002 10:33:00 -0700
Links: << >>  << T >>  << A >>
Can anyone tell me what is the meaning of these two lines in a trace
report -

Source Clock: clk_c rising at 0.000ns
Destination Clock: clk_c rising at 5.000ns

My guess is that it is just specifying the period.  But if this clock
goes through a buffer does it say otherwise.

Thanks.
-sanjay




Article: 42965
Subject: Re: Xilinx: delete file problem
From: "Børge Strand" <borges@ping.uio.no>
Date: Wed, 8 May 2002 20:39:05 +0200
Links: << >>  << T >>  << A >>

"Dennis McCrohan" <mccrohan@xilinx.com> wrote in message
news:3CD0B0EA.9DC7B32D@xilinx.com...
> "Børge Strand" wrote:
>
> > Come to think of it, I have those files samba mounted too, from a
> > stand-alone linux file server. (So there's no vmware involved here.)
> >
> > A fast ls -ld xst says:
> > drwx------    3 borges   users        4096 May  1 12:39 xst/
> > This is the same permission that all other files in the directory have.
But
> > when I go back to W2K, select xst, and click properties->security, not a
> > single permission is marked.
> >
> > Do you think this could be a Samba problem? It sure makes me curious.
> >
> > Regards,
> > Børge
>
> Suggest that you check out support.xilinx.com. If you can't find anything
> matching in the Answer Database, file a Webcase. Make sure you mention
your
> network setup and the fact that you are using Samba (we use it at Xilinx,
> too!).

I did a little more testing a few days ago. It is only the Samba/W2K
combination that fails. It works both on NTFS and FAT file systems.

I'll file you a case!

Regards,
Børge



Article: 42966
Subject: Re: Xilinx MicroBlaze, Opinion?
From: "jerry1111" <jerry1111@wp.pl>
Date: Wed, 8 May 2002 20:45:00 +0200
Links: << >>  << T >>  << A >>
> BTW: I saw a demo of a NIOS CPLD running Linux a couple weeks ago... 

Right, but uCLinux costs 5k$ in MicroTronix ;(((

In a 'meantime' I must take some uC sources and look how hard is changing them
for Nios...

jerry



Article: 42967
Subject: VHDL: FIFO
From: "Børge Strand" <borges@ping.uio.no>
Date: Wed, 8 May 2002 20:57:21 +0200
Links: << >>  << T >>  << A >>
I could need a FIFO in VHDL, and to avoid re-inventing the wheel all the
time, I wonder if there's some code around that I could have a look at.

This is the case: A DSP core (really only a MAC unit) drives a DAC. The
period of time between each parallel-bit write from the DSP can vary
significantly. The DAC is fed from a serial-to-parallel converter. Latching
data into this converter happens at regular intervals. The converter uses
the DAC bit clock, from which the FPGA clock is derived.

What I need is a FIFO that  buffers parallel data between the DSP and the
serial-to-parallel converter. I guess it needs write_enable,
data_input(bus), read_enable, data_output(bus), underflow_error, and
overflow_error. It currently looks like the whole thing can be syncronized
with a common clock. The error messages are not my primary concern.
Providing a reset is no problem.

I'm planning to implement this with a Spartan II or similar device. The
length of the FIFO is 8 or 16 words. Each word is 24 or 20 bits.

Any input would be highly appreciated! I do analog ASICs, but an really
fresh to VHDL and FPGAs. Is such an FPGA a standard thing in VHDL or Xilinx
Core Generator (which I don't have with WebPack), or are there tutorials
etc. on this?


Regards,
Børge



Article: 42968
Subject: Re: VHDL: FIFO
From: Keith R. Williams <krw@btv.ibm.com>
Date: Wed, 8 May 2002 15:15:23 -0400
Links: << >>  << T >>  << A >>
In article <abbs57$a59$1@maud.ifi.uio.no>, borges@ping.uio.no says...
> I could need a FIFO in VHDL, and to avoid re-inventing the wheel all the
> time, I wonder if there's some code around that I could have a look at.

XIlinx has some decent app notes on this.  If it is going into a 
SPartanII you might want to use CoreGen. 

OTOH, if you can get away with a synchronous FIFO (single clock on both 
interfaces) you might want to look at the SRL16.  You can't get much 
better than one LUT per bit (plus control) for a 16-deep FIFO.

> This is the case: A DSP core (really only a MAC unit) drives a DAC. The
> period of time between each parallel-bit write from the DSP can vary
> significantly. The DAC is fed from a serial-to-parallel converter. Latching
> data into this converter happens at regular intervals. The converter uses
> the DAC bit clock, from which the FPGA clock is derived.

> What I need is a FIFO that  buffers parallel data between the DSP and the
> serial-to-parallel converter. I guess it needs write_enable,
> data_input(bus), read_enable, data_output(bus), underflow_error, and
> overflow_error. It currently looks like the whole thing can be syncronized
> with a common clock. The error messages are not my primary concern.
> Providing a reset is no problem.
> 
> I'm planning to implement this with a Spartan II or similar device. The
> length of the FIFO is 8 or 16 words. Each word is 24 or 20 bits.


Sounds like a SRL16 FIFO is a perfect match. Look at the SRL16 
primitive.  It's a real piece of work!
 
> Any input would be highly appreciated! I do analog ASICs, but an really
> fresh to VHDL and FPGAs. Is such an FPGA a standard thing in VHDL or Xilinx
> Core Generator (which I don't have with WebPack), or are there tutorials
> etc. on this?

FIFOs are in everyone's toolkit. ;-)  Yes, there are several FIFOs in 
CoreGen but it sounds like you can get away with a very simple one.

----
  Keith


Article: 42969
Subject: Re: "free" tools ... ?
From: m0 <>
Date: Wed, 8 May 2002 11:18:58 -0800
Links: << >>  << T >>  << A >>
>But this could
>clearly could be wrong. The future >is rarely certain.

You must have aced philosophy.

Article: 42970
Subject: Re: bug in XST ?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Wed, 08 May 2002 14:23:30 -0500
Links: << >>  << T >>  << A >>
Have you simulated your design after synthesizing it with FPGA Compiler
II?
I feel like it won't function at all because according to Stuart
Sutherland's Verilog HDL Quick Reference Guide
(http://www.sutherland-hdl.com/on-line_ref_guide/vlog_ref_top.html),
bufif1's syntax will be the following.

bufif1 (1_output, 1_input, 1_control)


This is what you got in your code.

bufif1  buf_D_0         (LocData[0],    D_OUT[0],       LocDir);


I think it should be instead,

bufif1  buf_D_0 (D_OUT[0], LocData[0], LocDir);


        If the above suggestion doesn't work, you may want to replace
bufif1 with a tri-state buffer.
Here is an example. (I will assume that LocDir is an active high OE
signal. Swap LocData[0] and 1'bz otherwise.)

assign LocData[0] = LocDir ? LocData[0] : 1'bz;


XST should automatically infer an IOBUF for the above code.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 42971
Subject: Re: VHDL: FIFO
From: Vikram Pasham <Vikram.Pasham@xilinx.com>
Date: Wed, 08 May 2002 14:27:14 -0500
Links: << >>  << T >>  << A >>
Strand,

FIFOs can be efficiently implemented using either  BlockRAMs or SRL16s. Take a
look at Xilinx app. notes on FIFOs at
http://support.xilinx.com/apps/virtexapp.htm#appnotes . These app. notes also
include reference design in VHDL/Verilog.

If you do want to spend time on FIFO implementation, you would be better off
using Core Generator FIFO cores. These cores  are mapped to FPGA architecture
and offer high performance. These cores can be customized as per your
requirements.


-Vikram


"Børge Strand" wrote:

> I could need a FIFO in VHDL, and to avoid re-inventing the wheel all the
> time, I wonder if there's some code around that I could have a look at.
>
> This is the case: A DSP core (really only a MAC unit) drives a DAC. The
> period of time between each parallel-bit write from the DSP can vary
> significantly. The DAC is fed from a serial-to-parallel converter. Latching
> data into this converter happens at regular intervals. The converter uses
> the DAC bit clock, from which the FPGA clock is derived.
>
> What I need is a FIFO that  buffers parallel data between the DSP and the
> serial-to-parallel converter. I guess it needs write_enable,
> data_input(bus), read_enable, data_output(bus), underflow_error, and
> overflow_error. It currently looks like the whole thing can be syncronized
> with a common clock. The error messages are not my primary concern.
> Providing a reset is no problem.
>
> I'm planning to implement this with a Spartan II or similar device. The
> length of the FIFO is 8 or 16 words. Each word is 24 or 20 bits.
>
> Any input would be highly appreciated! I do analog ASICs, but an really
> fresh to VHDL and FPGAs. Is such an FPGA a standard thing in VHDL or Xilinx
> Core Generator (which I don't have with WebPack), or are there tutorials
> etc. on this?
>
> Regards,
> Børge


Article: 42972
Subject: Xilinx Design Language (xdl) documentation?
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Wed, 8 May 2002 19:45:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
does anyone know of documentation on xdl, specifically relating to
slice, blockram, etc config data and naming conventions?

thanks.

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

Article: 42973
Subject: Re: VHDL: FIFO
From: Ray Andraka <ray@andraka.com>
Date: Wed, 08 May 2002 19:53:42 GMT
Links: << >>  << T >>  << A >>
A synchronous FIFO using an SRL16 needs only a lut ber bit plus a 4 bit up-down
counter, 5 bits if you want an empty indication or 6 bits if you want both empty
and full indications.  Push without a Pop increments the count, Pop without a
push decrements, the two other combinations leave the counter as is.  Push also
connects the the SRL16 WE.  Reset should put the counter to all '1's.  The
counter MSB (if more than 4 bits) indicates empty when set, the next bit down
indicates full if set and it is not empty.

"Keith R. Williams" wrote:

> In article <abbs57$a59$1@maud.ifi.uio.no>, borges@ping.uio.no says...
> > I could need a FIFO in VHDL, and to avoid re-inventing the wheel all the
> > time, I wonder if there's some code around that I could have a look at.
>
> XIlinx has some decent app notes on this.  If it is going into a
> SPartanII you might want to use CoreGen.
>
> OTOH, if you can get away with a synchronous FIFO (single clock on both
> interfaces) you might want to look at the SRL16.  You can't get much
> better than one LUT per bit (plus control) for a 16-deep FIFO.
>
> > This is the case: A DSP core (really only a MAC unit) drives a DAC. The
> > period of time between each parallel-bit write from the DSP can vary
> > significantly. The DAC is fed from a serial-to-parallel converter. Latching
> > data into this converter happens at regular intervals. The converter uses
> > the DAC bit clock, from which the FPGA clock is derived.
>
> > What I need is a FIFO that  buffers parallel data between the DSP and the
> > serial-to-parallel converter. I guess it needs write_enable,
> > data_input(bus), read_enable, data_output(bus), underflow_error, and
> > overflow_error. It currently looks like the whole thing can be syncronized
> > with a common clock. The error messages are not my primary concern.
> > Providing a reset is no problem.
> >
> > I'm planning to implement this with a Spartan II or similar device. The
> > length of the FIFO is 8 or 16 words. Each word is 24 or 20 bits.
>
> Sounds like a SRL16 FIFO is a perfect match. Look at the SRL16
> primitive.  It's a real piece of work!
>
> > Any input would be highly appreciated! I do analog ASICs, but an really
> > fresh to VHDL and FPGAs. Is such an FPGA a standard thing in VHDL or Xilinx
> > Core Generator (which I don't have with WebPack), or are there tutorials
> > etc. on this?
>
> FIFOs are in everyone's toolkit. ;-)  Yes, there are several FIFOs in
> CoreGen but it sounds like you can get away with a very simple one.
>
> ----
>   Keith

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 42974
Subject: "easter egg" in FPGA design?
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Wed, 08 May 2002 16:34:35 -0400
Links: << >>  << T >>  << A >>
Hi,
    I am in the process of finalizing an FPGA design and am considering
adding an "easter egg" in the design.  In particular, I need to document
the design as "mine".  The product is an instrumnet and includes a very
simple microcontroller and a UART implemented in the FPGA.  (Thanks to
Ken Chapman for his UART and KCPSM, XAPP213 and XAPP223.)  The product
will be controlled via the serial port of a PC.  I can either have it
echo back the corporate name and the year ("DFTI 2002") at power up, or
as a response to a control string sent via the serial port.  i.e.  send
"who" via the serial port and then echo "DFTI 2002".  Any comments?

Thanks,
Theron Hicks




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

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

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

Custom Search