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
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: 42951SPARTAN 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
"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 FalkArticle: 42953
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, HarrisArticle: 42954
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: 42955H.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
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
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
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
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.ORGArticle: 42960
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: 42961Slight 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
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
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) RalfArticle: 42964
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. -sanjayArticle: 42965
"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ørgeArticle: 42966
> 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... jerryArticle: 42967
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ørgeArticle: 42968
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. ---- KeithArticle: 42969
>But this could >clearly could be wrong. The future >is rarely certain. You must have aced philosophy.Article: 42970
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: 42971Strand, 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ørgeArticle: 42972
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.eduArticle: 42973
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
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:
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