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
Colin, True. The lawyers require that we never accept any risk of this type. In this case, for something that is "soft" and leaves no record, we can not accept any liability for something that can never be proven absolutely. We can only do our best, and ask our customers to do their best, and show them results from all the testing, and other missions and working systems. If a part 'fails', all we can do is issue an RMA, test it, and replace it if found bad. That is the complete and total extent of our liability, unless otherwise agreed upon with our legal department. If you recall the alphas in solder bumps fiasco ($10M loss for Xilinx), it is our goodwill and honesty that we negotiate the return and replacement of every lot of the affected parts once we were aware of the problem. In that very real sense, we are the ONLY company to have corrected the situation up front, and in public. Many other alpha contamination situations are buried, and only become legends, or appear in papers 10 years later as "stories" from previous generations of products. http://www.xilinx.com/support/documentation/white_papers/wp208.pdf Austin Colin Paul Gloster wrote: > Jon Elson posted: > |-------------------------------------------------------------------| > |"[..] | > | | > |[..] Proving you can | > |correct corruption from a hit anywhere on a chip, while running ANY| > |program, at any time, seems like fantasy." | > |-------------------------------------------------------------------| > > Correct. Xilinx did (and probably still does) have an admission on > its website that a level of risk must always be accepted, no matter > what is done to combat single-event effects. > > Regards, > Colin Paul Gloster, > unemployed and hungryArticle: 131101
Habib Bouaziz-Viallet <habib@rigel.systems> writes: > I'm working with WebPack ISE and i guess that the programming tools > (ImpACT) is a native MS-Windows tool and did not work under GNU/Linux. WebPACK ISE for Linux comes with Impact that runs file on Linux.Article: 131102
Peter Alfke wrote: > Thats the way when you cannot use the simplest method, called 8B10B, > where 10 bits are used to transmit the content of 8 data bits. > Transceivers often include the necessary encoder/decoder, and DC > balancing is automatically included. The penalty is a 25% loss in > throughput ( e.g. only 2.5 Gbps from a 3,125 Gbps channel. > Scrambling is populat with the telephone people. 8b/10b and similar coding can always guarantee that the run length constraint is met. Scrambling is probabilistic. If your data is effectively random, once in a great while you'll get a violation of the run length constraint. If the data is packetized, retransmission will work as long as the start of the retransmission doesn't happen to occur at the same phase of the scrambler as the original transmission. For a new design, I would use 8b/10b or similar coding rather than a scrambler, unless I had to interoperate with an existing system that uses a scrambler.Article: 131103
Fei Liu wrote:
> Hello gentle readers,
>
> I started playing with FPGA and verilog about a month ago. As a fun
> starting project, my goal is to allow interaction between host linux pc
> and fpga lcd display. The connection is made through serial RS323
> interface. Here is my lcd controller module that accomplished my goal. I
> am looking for your advice and suggestions and in what ways I can
> improve this module. I am hoping to learn from this process.
Update was made after studying the source code from opencores.org, feel
free to comment.
module lcd_controller (clk, data_ready, rx_data, lcd_rs, lcd_rw, lcd_e,
lcd_4, lcd_5, lcd_6, lcd_7);
parameter k = 18;
// in register_input mode, the input doesn't have to stay valid
// while the character is been transmitted
parameter register_input = 1;
parameter clr = 8'h0A;
input clk;
input data_ready;
input [7:0] rx_data;
output lcd_rs;
output lcd_rw;
output lcd_e;
output lcd_7;
output lcd_6;
output lcd_5;
output lcd_4;
reg lcd_e, lcd_rs, lcd_rw, lcd_7, lcd_6, lcd_5, lcd_4;
reg [k+8:0] count=0;
reg [6:0] lcd_code = 0;
reg [2:0] state=3'b000;
reg [2:0] next_state=3'b000;
wire lcd_ready = (state==1);
// store rx_data locally
reg [7:0] lcd_dataReg;
always @(posedge clk)
if(data_ready & lcd_ready)
lcd_dataReg <= rx_data;
wire [7:0] lcd_dataD = register_input ? lcd_dataReg : rx_data;
// continuous assignment by default of wire type, clr key clears display
wire clear = (rx_data == clr)? 1:0;
//assign {lcd_e,lcd_rs,lcd_rw,lcd_7,lcd_6,lcd_5,lcd_4} = lcd_code;
// sequential logic
always @ (posedge clk)
state <= next_state;
always @ (posedge clk)
begin
if(state != 3'b001)
begin
count <= count + 1;
if(count[4] && state == 3'b010)
count <= 0;
if(count[4] && state == 3'b100)
count <= 0;
if(count[5] && state == 3'b011)
count <= 0;
if(count[10] && state == 3'b101)
count <= 0;
end
else
count <= 0;
{lcd_e,lcd_rs,lcd_rw,lcd_7,lcd_6,lcd_5,lcd_4} <= lcd_code;
if(state == 0 || state == 6) lcd_e <= ^count[k+1:k];
end // sequential logic
// combinatorial logic
always @ (state or count or data_ready or clear) begin
case(state)
3'b000:
begin
if(count[k+5:k+2] == 12)
next_state <= 3'b1; // idle_data/1
else
next_state <= 0;
end
3'b001:
begin
if(data_ready) begin
if(clear)
next_state <= 3'b110; // clear/6
else
next_state <= 3'b10; // disp_hn/2
end
else
next_state <= 3'b1; // idle_data/1
end
3'b010:
begin
if(count[4])
next_state <= 3'b11; // idle_high/3
else
next_state <= 3'b10; // disp_hn/3
end
3'b011:
begin
if(count[5])
next_state <= 3'b100; // disp_ln/4
else
next_state <= 3'b11; // idle_high/3
end
3'b100:
begin
if(count[4])
next_state <= 3'b101; // wait/5
else
next_state <= 3'b100; // disp_ln/4
end
3'b101:
begin
if(count[10])
next_state <= 3'b1; // idle_data/1
else
next_state <= 3'b101; // wait/5
end
3'b110:
begin
if(count[k+3:k+2] == 2)
next_state <= 3'h1; // idle_data/1
else
next_state <= 3'h6; // clear/6
end
endcase
end // combinatorial logic
// output logic
always @(state or count or lcd_dataD) begin
lcd_code <= 7'h00;
case(state)
3'b000:
begin
case (count[k+5:k+2])
0: lcd_code <= 7'h43; // power-on initialization
1: lcd_code <= 7'h43;
2: lcd_code <= 7'h43;
3: lcd_code <= 7'h42;
4: lcd_code <= 7'h42; // function set
5: lcd_code <= 7'h48;
6: lcd_code <= 7'h40; // entry mode set
7: lcd_code <= 7'h46;
8: lcd_code <= 7'h40; // display on/off control
9: lcd_code <= 7'h4C;
10: lcd_code <= 7'h40; // display clear
11: lcd_code <= 7'h41;
endcase
end
3'b001:
lcd_code <= 7'h00;
3'b010:
lcd_code <= {3'b110, lcd_dataD[7:4]};
3'b011:
lcd_code <= 7'b0110000;
3'b100:
lcd_code <= {3'b110, lcd_dataD[3:0]};
3'b101:
lcd_code <= 7'b0110000;
3'b110:
begin
case(count[k+3:k+2])
0: lcd_code <= 7'h40; // display clear
1: lcd_code <= 7'h41;
endcase
end
endcase
end // output logic
endmodule
Article: 131104My PCIE device is a Gigabit NIC. The lnx ifconfig command can show the tx/rx packet count from this NIC. after loading lnx driver,it will be triggered a NMI error only if ths rx packet count reaches 35.The system isn't be halt,however the NIC doesn't work. it is regardless of the packet size.eg:i send the ping cmd with -s 1422 switch. still,it is be triggered NMI after 35 count. why?Article: 131105
Hello,
I am using Xilinx 9.1i and Modelsim 5.7g. I instantiated a coregen
module for FFT ver 3.2. After successfully synthesizing the module
with the generated xco, I am now trying to simulate the module. The
hierarchy is as follows:
fft_tb => fft_top => fft.v (generated by coregen)
I am using a custom script as follows:
#############################################
vlib work
vlog fft.v "../fft_top.v" fft_tb.v
vsim -t 1ps -L xilinxcorelib_ver -L unisims_ver -L simprims_ver -lib
work fft_tb_v glbl
view wave
add wave *
add wave /glbl/GSR
do {fft_tb_v.udo}
view structure
view signals
run 1000ns
##############################################
I have compiled simprims, xilinxcorelib and unisim libraries (verilog
versions) and added them to Modelsim. When I select Simulate
Behavioral Model from Xilinx, it opens modelsim and finds all the
xilinx primitives, which fft module calls, except for these:
# ** Error: (vsim-3033) fft.v(10097): Instantiation of
'fft_r22_cnt_ctrl_6' failed. The design unit was not found.
# Region: /fft_tb_v/uut/U1
# Searched libraries:
# C:/Xilinx91i/verilog/mti_se/XilinxCoreLib_ver
# C:/Xilinx91i/verilog/mti_se/unisims_ver
# C:/Xilinx91i/verilog/mti_se/simprims_ver
# work
# ** Error: (vsim-3033) fft.v(10111): Instantiation of
'fft_r22_cnt_ctrl_7' failed. The design unit was not found.
# Region: /fft_tb_v/uut/U1
# Searched libraries:
# C:/Xilinx91i/verilog/mti_se/XilinxCoreLib_ver
# C:/Xilinx91i/verilog/mti_se/unisims_ver
# C:/Xilinx91i/verilog/mti_se/simprims_ver
# work
# ** Error: (vsim-3033) fft.v(10183): Instantiation of
'fft_r22_cnt_ctrl_8' failed. The design unit was not found.
# Region: /fft_tb_v/uut/U1
# Searched libraries:
# C:/Xilinx91i/verilog/mti_se/XilinxCoreLib_ver
# C:/Xilinx91i/verilog/mti_se/unisims_ver
# C:/Xilinx91i/verilog/mti_se/simprims_ver
# work
So I dont understand why these primitives are present in the core and
why are they not subdivided into modules which are present in simprims
library or any xilinx library for that matter.
Is it a problem of using older Modelsim version with new xilinx
version? Do I need to upgrade ips for 9.1, I am currently working with
the ip set provided in xilinx installation?
Any ideas how I can fix the problem?
Thanks in advance
Mansoor
Article: 131106
On Fri, 11 Apr 2008 10:44:12 +0100, Michael Meeuwisse
<mickeymeeuw@g_something> wrote:
>parameter width = 32; /* Must be multiple of 8 */
>input [width - 1: 0] iData;
>
>/* number of characters to send for each piece of data - 1 */
>parameter chars = width / 8 - 1;
>
>The iData first goes in a fifo for buffering and is then read back in as
>oData:
>
>wire [width - 1: 0] oData;
>
>Since this is an UART I want to send (always, regardless of width) 8
>bits at a time, so I wrote down:
>
>reg [7: 0] xData [chars: 0];
>
>And then try to assign oData to this:
>
>xData <= oData;
Yup, you can't do that! xData is a "memory" in Verilog-speak,
an array of (chars+1) distinct 8-bit variables; you can't
assign a single vector to that, any more than you could assign
an integer to a complete array in C.
The direct (but, in practice, wrong) answer is:
integer i;
...
for (i=0; i<=chars; i=i+1)
xData[i] <= oData[8*i +: 8];
The strange [a +: b] is an "indexed part select",
choosing the 8 bits of oData whose lowest-numbered
subscript is 8*i. You might expect to do...
xData[i] <= oData[8*i + 7: 8*i];
but you're not allowed to do that, because a part-select
can't have variable bounds.
However, there is probably a better way.
Copy "oData" into a wide register:
reg [width-1 : 0] byteShifter;
...
byteShifter <= oData;
and then allow it to shift down 8 bits at a time
as you pull bytes out of it:
reg [7:0] txByte;
...
// send one byte
txByte <= byteShifter[7:0];
byteShifter <= byteShifter >> 8;
The shift operation obviously puts the *next* 8 bits
of "byteShifter" into the right place for the next
txByte<=byteShifter[7:0] copy.
Armed with this idea you'll probably come up with
something a bit simpler. For example, you may
prefer to do this byte-shifting at the input end
of your FIFO, so that the FIFO is invariably
byte-wide - that would be my preference.
Generally, if you want sequential access to the
pieces of a big vector, it is much cheaper (in hardware)
to shift them into place rather than selecting them
from their original position.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 131107Try posting to an appropriate newsgroup.Article: 131108
Hello,
when trying to synthesize a VHDL file (part of a design) that has
already been compiled and simulated by Modelsim,
ISE gives the following error:
" ERROR:HDLParsers:3524 - "G:/des1/chsam_struct.vhd" Line 132.
Unexpected end of line. "
It refers to the last line of the following code, any idea what this
is..? It is a rather simple code I can't understand what is the
problem :
-----------------------------------------------------------------------------------------
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;
ENTITY DgChSamplRep IS
PORT(
MClk : IN std_logic;
R : IN std_logic_vector (1 DOWNTO 0);
Rst : IN std_logic;
SerIn : IN std_logic;
Shift_En : IN std_logic;
DO : OUT std_logic_vector (7 DOWNTO 0) BUS;
DgChVal : OUT std_logic_vector (15 DOWNTO 0)
);
-- Declarations
END DgChSamplRep ;
--
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;
ARCHITECTURE struct OF DgChSamplRep IS
-- Architecture declarations
-- Internal signal declarations
SIGNAL ClkInv : std_logic;
SIGNAL ClkInv_En : std_logic;
-- Implicit buffer signal declarations
SIGNAL DgChVal_internal : std_logic_vector (15 DOWNTO 0);
-- Component Declarations
COMPONENT ShiftReg16b
PORT (
Clk : IN std_logic ;
Rst : IN std_logic ;
SerIn : IN std_logic ;
Q : OUT std_logic_vector (15 DOWNTO 0)
);
END COMPONENT;
COMPONENT Tristate8b_exp
PORT (
I0 : IN std_logic ;
I1 : IN std_logic ;
I2 : IN std_logic ;
I3 : IN std_logic ;
I4 : IN std_logic ;
I5 : IN std_logic ;
I6 : IN std_logic ;
I7 : IN std_logic ;
R : IN std_logic ;
O : OUT std_logic_vector (7 DOWNTO 0)
);
END COMPONENT;
BEGIN
ClkInv_En <= ClkInv AND Shift_En;
ClkInv <= NOT(MClk);
-- Instance port mappings.
U_0 : ShiftReg16b
PORT MAP (
Clk => ClkInv_En,
Rst => Rst,
SerIn => SerIn,
Q => DgChVal_internal
);
U_2 : Tristate8b_exp
PORT MAP (
I0 => DgChVal_internal(7),
I1 => DgChVal_internal(6),
I2 => DgChVal_internal(5),
I3 => DgChVal_internal(4),
I4 => DgChVal_internal(3),
I5 => DgChVal_internal(2),
I6 => DgChVal_internal(1),
I7 => DgChVal_internal(0),
R => R(0),
O => DO
);
U_3 : Tristate8b_exp
PORT MAP (
I0 => DgChVal_internal(15),
I1 => DgChVal_internal(14),
I2 => DgChVal_internal(13),
I3 => DgChVal_internal(12),
I4 => DgChVal_internal(11),
I5 => DgChVal_internal(10),
I6 => DgChVal_internal(9),
I7 => DgChVal_internal(8),
R => R(1),
O => DO
);
DgChVal <= DgChVal_internal;
END struct;
----------------------------------------------------------------------
Thank you in advance!
Regards,
George
Article: 131109
Hi,
I'm working on a little UART to get more familiar with verilog, and
right now I have the following input:
parameter width = 32; /* Must be multiple of 8 */
input [width - 1: 0] iData;
/* number of characters to send for each piece of data - 1 */
parameter chars = width / 8 - 1;
The iData first goes in a fifo for buffering and is then read back in as
oData:
wire [width - 1: 0] oData;
Since this is an UART I want to send (always, regardless of width) 8
bits at a time, so I wrote down:
reg [7: 0] xData [chars: 0];
And then try to assign oData to this:
xData <= oData;
I hope a few are now crying "You can't do that!" because that would mean
you'd know how to do this instead. Xilinx webpack gives me on that line;
Illegal left hand side of nonblocking assignment
The error is general enough for google to not find anything relevant
afaik. I don't want to do something like:
{xData[0], xData[1], ..} = oData;
Because I don't know how wide oData will be at this point. I also really
don't want to rewrite the fifo to support an other output width than
what it's input is. Even if I had to rewrite it, I'll end up with the
same problem as above at some point.
Hints & Tips are very welcome.
Thanks,
Michael
www.projectvga.org
Article: 131110On Fri, 11 Apr 2008 11:43:06 +0100, Michael Meeuwisse wrote: >> The direct (but, in practice, wrong) answer is: >> >> integer i; >> ... >> for (i=0; i<=chars; i=i+1) >> xData[i] <= oData[8*i +: 8]; >> >> The strange [a +: b] is an "indexed part select", >> choosing the 8 bits of oData whose lowest-numbered >> subscript is 8*i. You might expect to do... >> >> xData[i] <= oData[8*i + 7: 8*i]; >Ok.. but why is this a wrong answer? uh, which answer? oData[8*i+7:8*i] is illegal because it's a part select with variable bounds; in Verilog all expressions must have a statically-determined bit width, and although you and I can do the algebra and see that the slice is evidently 8 bits wide, it's safer for the language to outlaw that sort of thing. The indexed part-select oData[8*i+:8] is legal, at least in Verilog-2001, but creates a big multiplexer to choose the bits - hence my comment later about using a shifter instead. >> Generally, if you want sequential access to the >> pieces of a big vector, it is much cheaper (in hardware) >> to shift them into place rather than selecting them >> from their original position. > >Odd. I thought a wire from the original register would be cheaper than >logic to get the bits in place. Don't take my word for it - try synthesising both versions and see what the tool shows you. For a word of only 2 or 4 bytes the difference is likely to be marginal. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 131111
Jonathan Bromley wrote: > Yup, you can't do that! xData is a "memory" in Verilog-speak, > an array of (chars+1) distinct 8-bit variables; you can't > assign a single vector to that, any more than you could assign > an integer to a complete array in C. I figured it was something like that. But since it'd translate to hardware at some point I hoped the compiler was intelligent enough to understand this "re-definition". > The direct (but, in practice, wrong) answer is: > > integer i; > ... > for (i=0; i<=chars; i=i+1) > xData[i] <= oData[8*i +: 8]; > > The strange [a +: b] is an "indexed part select", > choosing the 8 bits of oData whose lowest-numbered > subscript is 8*i. You might expect to do... > > xData[i] <= oData[8*i + 7: 8*i]; > Ok.. but why is this a wrong answer? > However, there is probably a better way. > ... > // send one byte > txByte <= byteShifter[7:0]; > byteShifter <= byteShifter >> 8; > That all makes sense. I think I can pull this off without changing too much. I was already doing something similar for transmitting the actual bits anyway. :) > Armed with this idea you'll probably come up with > something a bit simpler. For example, you may > prefer to do this byte-shifting at the input end > of your FIFO, so that the FIFO is invariably > byte-wide - that would be my preference. > It would simplify the UART somewhat, but then I'd have to shift a number of bytes into the fifo in one clock cycle. I'll stick to what I have for now. > Generally, if you want sequential access to the > pieces of a big vector, it is much cheaper (in hardware) > to shift them into place rather than selecting them > from their original position. Odd. I thought a wire from the original register would be cheaper than logic to get the bits in place. Thanks, Michael www.projectvga.orgArticle: 131112
On Fri, 11 Apr 2008 12:35:16 +0100, Michael Meeuwisse wrote: > >Jonathan Bromley wrote: >> On Fri, 11 Apr 2008 11:43:06 +0100, Michael Meeuwisse wrote: >>>Ok.. but why is this a wrong answer? >> >> uh, which answer? > >I meant the for loop. If the compiler unrolls it I don't see how this >could be a wrong. Maybe size. ummm, sorry, I wasn't being sufficiently precise. The 'for' loop, with indexed part select, is completely legal Verilog; it will simulate just fine, and as you say it will be unrolled in synthesis because the loop has static bounds. I still say that the logic will be bigger than the shift solution, though, at least if you assume (a) it's an FPGA target, and (b) the word is >=4 bytes. The reason is that a 4:1 or wider multiplexer won't fit into a single lookup table (LUT) in typical FPGAs (there are some exceptions) whereas the 2:1 mux required to implement a conditional shift most certainly will. Since each bit of storage in an FPGA comes with a free LUT, the shifter solution is almost free - the necessary logic comes along for the ride with the registers that you need in any case - but the mux solution is likely to use a few extra LUTs whose registers would be wasted. The argument in favour of shifting over selecting is likely to get stronger as the word gets wider, up to some limit where the shift register becomes implausibly wide and then you switch over to using a full-dress memory block instead - and, of course, accept that you can access only one element of it at a time. In truth, I'm probably nit-picking. Do whatever works and gives you clean, maintainable code. I just wanted to flag up the possibility of an alternative approach. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 131113
What happend to the tech Xclusive articles that used to be on the Xilinx home page? I was trying to find one of Austins excellent articles on synchronous digital design but where unable to locate it...Article: 131114
Jonathan Bromley wrote: > On Fri, 11 Apr 2008 11:43:06 +0100, Michael Meeuwisse wrote: >>Ok.. but why is this a wrong answer? > > uh, which answer? I meant the for loop. If the compiler unrolls it I don't see how this could be a wrong. Maybe size. >>Odd. I thought a wire from the original register would be cheaper than >>logic to get the bits in place. > > > Don't take my word for it - try synthesising both versions and > see what the tool shows you. For a word of only 2 or 4 bytes > the difference is likely to be marginal. I'll give it a try soon. The solution of using a shift turned out to be 1 extra line and about 4 minor changes, so I'm currently working out the bugs which showed up in the simulation. :) Thanks again, Michael www.projectvga.orgArticle: 131115
I found a workaround, if the FFT core is generated with bit revered order instead of Natural Order, then the errors are removed and simulation runs smoothly. MakArticle: 131116
makhan wrote:
> the FFT core is generated with bit revered order
^^^^^^^^^^^
Nuff respect?
Article: 131117"Lars" <noreply.larthe@gmail.com> wrote in message news:285fdaae-86c9-449c-a60e-4c9e5ef9844e@a1g2000hsb.googlegroups.com... > What happend to the tech Xclusive articles that used to be on the > Xilinx home page? I was trying to find one of Austins excellent > articles on synchronous digital design but where unable to locate it... Hi Lars, They enhanced their site. I assume those TechXclusives were rubbish, so they got binned. Some of them got recycled into white papers. I found this by guessing the url... http://www.xilinx.com/support/documentation/white_papers.htm If you insist on reading the old versions, try here... http://web.archive.org/web/20050305013744/www.xilinx.com/xlnx/xweb/xil_tx_home.jsp HTH., Syms. p.s. For those whose sarcasm detection is limited, the TechXclusives aren't rubbish. As for the decision to ditch them...Article: 131118
> http://www.xilinx.com/support/documentation/white_papers.htm > > If you insist on reading the old versions, try here... > > http://web.archive.org/web/20050305013744/www.xilinx.com/xlnx/xweb/xi... > > HTH., Syms. Ge thanks! Saved a lot of looking around! > p.s. For those whose sarcasm detection is limited, the TechXclusives aren't > rubbish. As for the decision to ditch them... Well, my opinion is easy to guess... Lots of gems in there! /LarsArticle: 131119
Will there be a 64 bit WebPack version of ISE in the near future? Rog.Article: 131120
Aaaaarg!!! I was after "Six Easy Pieces (Non-Synchronous Circuit Tricks)" and it seems that didn't make it to the White Papers. And the web archive link lacks the images :( I guess I will have to ruffle through my stack of old "useful printouts" for that one, if it is there... Not high-tec stuff but useful to explain basic priciples to beginners. Thanks anyway, and Austin and Peter; if you read this, please use your influence to correct some of the obvious mistakes made by the web- people at Xilinx! /LarsArticle: 131121
On Apr 11, 8:27=A0am, Lars <noreply.lar...@gmail.com> wrote: > Aaaaarg!!! I was after "Six Easy Pieces (Non-Synchronous Circuit > Tricks)" and it seems that didn't make it to the White Papers. And the > web archive link lacks the images :( > I guess I will have to ruffle through my stack of old "useful > printouts" for that one, if it is there... Not high-tec stuff but > useful to explain basic priciples to beginners. > > Thanks anyway, and Austin and Peter; if you read this, please use your > influence to correct some of the obvious mistakes made by the web- > people at Xilinx! > > /Lars What a sad ending :(Article: 131122
jjlindula@hotmail.com a écrit : > Hello, I need a PCI Express application and I could find a vendor that > sells PCI Express cards and add in my design to the FPGA or I could > design my own PCI Express card from the ground up. I decided to buy an > evaluation card from PLDA and see if I could get things going from > their design. I am new to the PCI Express bus protocol and wanted to > find a vendor that would make working with PCIe very easy. Does anyone > have experience with PLDA? Or, perhaps could recommend another company > that is Altera based. I visited Altera's web site and they have a PCIe > evaluation card and have thought about using their product because of > their excellent support. > > If anyone would like to share their comments please do. > > thanks, > joe Hi, I use plda PCI express solution for Altera (StratixII) and Xilinx (Virtex5 LXT), and it's work fine, it's very simple with a demo board. Best regards Bernard Esteban Electronic Design Engineer MAF AgroboticArticle: 131123
On 9 avr, 16:19, Pete <petersen.c...@gmail.com> wrote: > I've noticed that the Xilinx FFT bit-accurate c simulation calls are > very very slow. Anyone else notice this? I'm using the Matlab mex file function and noticed the slowness as well. Not only that, my input data is real only and the function issues a warning in the Matlab console in that case. It's really annoying because it can't be turned off. As for the speed issue, maybe you could consider using a non bit- accurate model that you would build yourself and use the bit-accurate model only when really needed. That's what I did. PatrickArticle: 131124
Yes, TechX is gone, and Peter, Ken, and I now have.....Blogs! Each "good" TechX is polished and updated and republished as a white paper (or on its way to being republished). I won't say anything more about the web folks except that we have a good understanding now. http://forums.xilinx.com/blog?blog.id=pld It isn't the same as TechX, but it allows you to "interact" and comment directly with us, on topics of interest. So, read my second blog post for the "story." http://forums.xilinx.com/xlnx/blog/article?message.uid=7994 Peter's first post is actually of technical interest! http://forums.xilinx.com/xlnx/blog/article?message.uid=7996 And, thank you to everyone who commented: we used your emails to get the TechX's on the fast track to be converted to white papers, and to get the Blogo-sphere created (as of yet still not officially out, as they still have a few minor bugs -- like our pictures are not displayed as they should be -- not that I care, but the web folks felt pictures were required). We do appreciate the (constructive) criticism, and your comments. Let us know if the blogs are a good thing, or not. As I have posted before, we do read your emails that you send to us directly, and I always reply, Austin
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z