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
"poet_neel@yahoo." <poet_neel@n_o_s_p_a_m.yahoo.com> wrote in message news:Gpydncogtam15yrQnZ2dnUVZ_o6dnZ2d@giganews.com... > Me and some engineers run an FPGA prototyping company. The recent > unfortunate disaster in Japan has thrown off our immediate forecasts, we > have some left over inventory of SIV 230GX and SIV parts. This happens > with > us occasionally where we might have a few pieces here and there of parts. > > Would someone be interested in acquiring these? These are brand new and in > unopened hermetically sealed tray and hence guaranteed to work. The price > ofcourse will be way cheaper that buying single units elsewhere(even if > you > are able to buy small units to begin with). Tell us the prices.Article: 151626
Manusha <manusha1980@gmail.com> wrote: >Thanks all for the valuable advices. > >It seems like there are good alternatives to a vertex/powerPC based >system. > >@AMDyer: I am pretty impressed with the TI Davinci DSP's. Did not go >to details, but seems like it has pretty much i am looking for. I will >evaluate this option seriously. > >@John: I agree, The vertex devices cost pretty much. For example, the >one i am planning to use costs around $120 and it has a powerPC core. >But my question is, are there any alternatives at a lesser cost? Would >a low cost device give me the computing power i need? (I am sure i >need significant amount of computing power for real time video >processing). If you don't specify what kind of processing you want (algorithm, resolution, frame rate, etc), it is impossible to tell what you would need. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 151627
>Hassoo, > >If you are new to the world of FPGAs, please be aware that it is not a >trivial task to drop in complicated IP such as an Ethernet MAC. >Hopefully you have a board with a fully tested and proven Ethernet >interface on it..? There are plenty of development boards out there >with a Virtex-4 and Ethernet present. > >You mentioned alternatives... did you mean alternatives to Ethernet? >Depends of course on what you are trying to do, but perhaps a good >first step for you (as a beginner) is a serial interface. If you just >want to communicate with the FPGA and are not worried about sending / >receiving data very quickly, this is orders of magnitude simpler. > >-- >Mike Shogren >Director of FPGA Development >Epiq Solutions >http://www.epiq-solutions.com I have a Virtex4 MB board. It doesn't have an embedded MAC, that is why I have to use soft IP core. What is my best option then? Can it be done without using microblaze processor? By alternatives I meant, alternative to TEMAC IP core if I need to have the ethernet connectivity... Regards, > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151628
>I suggest perusing the Xilinx web site looking for application notes >that are close to what you want to do. > >There's Xapp807 - the TEMAC on a Virtex 4. > >PS: It's spelled "please" - typing the three additional key-strokes >will show that you're not lazy. > The document you mentioned is using embedded MAC, however my board doesn't have one. I have to use TEMAC soft IP core. Can you please tell me any helpful tutorial or document which explains how to use the core step by step. Thank you. Regards, --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151629
Hi, i have written the following verilog code. Its basically a WB
master to read and write from OC PCI bridge core.
Can you guys point me what is "ugly" on my code, or what is a bad
practice? I just want to learn what is a good practice programming
with verilog, and why.
`include "network_controller_constants.v"
module NETWORK_CONTROLLER_WB_MASTER
(
CLK_I,
RST_I,
MINT_O,
MADR_O,
MDAT_O,
MDAT_I,
MSEL_O,
MCYC_O,
MSTB_O,
MWE_O,
MCAB_O,
MACK_I,
MRTY_I,
MERR_I,
tx_b1_offset,
tx_b2_offset,
rx_b1_offset,
rx_b2_offset,
r_cnt_reg,
r_cmnd_flag,
tx_b_1_int,
tx_b_2_int,
rx_b_1_int,
rx_b_2_int,
tx_b_1_over,
tx_b_2_over,
rx_b_1_over,
rx_b_2_over,
r_counter_empty,
counter_loaded,
w_cmnd_flag,
w_counter_loaded,
w_cnt_reg,
leds,
wb_reading,
wb_r_data
);
input CLK_I;
input RST_I;
output MINT_O;
output [31:0] MADR_O;
input [31:0] MDAT_I;
output [31:0] MDAT_O;
output [3:0] MSEL_O;
output MCYC_O;
output MSTB_O;
output MWE_O;
output MCAB_O;
input MACK_I;
input MRTY_I;
input MERR_I;
input [31:0] tx_b1_offset;
input [31:0] tx_b2_offset;
input [31:0] rx_b1_offset;
input [31:0] rx_b2_offset;
output tx_b_1_over;
output tx_b_2_over;
output rx_b_1_over;
output rx_b_2_over;
input [31:0] r_cnt_reg;
input r_cmnd_flag;
input tx_b_1_int;
input tx_b_2_int;
input rx_b_1_int;
input rx_b_2_int;
output r_counter_empty;
output [31:0] wb_r_data;
output wb_reading;
input w_cmnd_flag;
output w_counter_loaded;
input [31:0] w_cnt_reg;
output [3:0] leds;
output counter_loaded;
parameter WB_IDLE = 4'b0001;
parameter WB_WRITING = 4'b0010;
parameter WB_READING = 4'b0100;
parameter WB_W_WAIT = 4'b1000;
reg [31:0] MADR_O = 32'h00000000;
wire [31:0] MDAT_O;
wire [31:0] MDAT_I;
wire [3:0] MSEL_O;
reg MCYC_O = 0;
reg MSTB_O = 0;
wire MWE_O;
reg MCAB_O;
wire MACK_I;
wire MRTY_I;
wire MINT_O;
reg [31:0] r_counter = 0;
reg [3:0] state_machine = WB_IDLE;
reg [3:0] next_state = WB_IDLE;
reg write_done = 0;
wire r_counter_empty;
wire wb_int_gen;
reg tx_b_1_over = 0;
reg tx_b_2_over = 0;
reg rx_b_1_over = 0;
reg rx_b_2_over = 0;
reg [31:0] w_counter = 0;
wire w_counter_empty;
wire [31:0] wb_r_data;
wire wb_reading;
reg [30:0] r_w_addr = 0;
//###########################################################
// DEBUG VARIABLES
reg [3:0] MRTY_C = 0;
reg [3:0] MACK_C = 0;
reg [3:0] MINT_C = 0;
reg [3:0] WRITE_C = 0;
reg [3:0] leds;
//###########################################################
assign MSEL_O = 4'b1111;
assign MINT_O = wb_int_gen;
assign wb_int_gen = tx_b_1_int||
tx_b_2_int||
rx_b_1_int||
rx_b_2_int;
/
*##################################################################################
############################ state_machine CONTROL
#################################
##################################################################################*/
always@(*)
begin
tx_b_1_over = 1'b0;
tx_b_2_over = 1'b0;
rx_b_1_over = 1'b0;
rx_b_2_over = 1'b0;
next_state = state_machine;
case (state_machine)
WB_IDLE :
begin
if(r_counter > 32'h0)
begin
next_state = WB_READING;
end
else
begin
if(w_counter > 32'h0)
begin
next_state = WB_WRITING;
end
end
end
WB_READING :
begin
if(r_counter == 32'h0)
begin
next_state = WB_IDLE;
rx_b_1_over = 1'b1;
end
end
WB_WRITING :
begin
if(w_counter == 32'h0)
next_state = WB_W_WAIT;
end
WB_W_WAIT :
begin
if(write_done)
begin
next_state = WB_IDLE;
tx_b_1_over = 1'b1;
end
end
default:begin
next_state = WB_IDLE ;
end
endcase
end
/
*##################################################################################
############################# write_done CONTROL
###################################
##################################################################################*/
always@(posedge CLK_I)
begin
write_done = 1'b0;
if(state_machine == WB_W_WAIT)
begin
if(MCYC_O && MACK_I)
write_done = 1'b1;
end
end
/
*##################################################################################
############################ state_machine TIMING
##################################
##################################################################################*/
always@(posedge CLK_I)
begin
state_machine <= next_state;
end
always@(posedge CLK_I)
begin
case (state_machine)
WB_IDLE : begin
if(r_cmnd_flag)
begin
r_counter <= r_cnt_reg;
r_w_addr <= 30'h0;
end
else
begin
if(w_cmnd_flag && (~tx_b_1_int || ~tx_b_2_int))
begin
w_counter <= w_cnt_reg;
r_w_addr <= 30'h0;
end
end
end
WB_READING : begin
if(MCYC_O && MACK_I)
begin
if(r_counter > 0)
begin
r_counter <= r_counter - 32'h1;
r_w_addr <= r_w_addr + 30'h4;
end
end
end
WB_WRITING : begin
if(MCYC_O && MACK_I)
begin
if(w_counter > 0)
begin
w_counter <= w_counter - 32'h1;
r_w_addr <= r_w_addr + 30'h4;
end
end
end
endcase
end
assign MDAT_O = w_counter;
assign MWE_O = (next_state == WB_WRITING)? 1'b1 : 1'b0;
assign wb_r_data = MDAT_I;
always@(*)
begin
case(next_state)
WB_IDLE: begin
MADR_O[30:0] <= r_w_addr + tx_b1_offset[30:0];
MADR_O[31] <= 1'b0;
MCAB_O <= 1;
end
WB_READING: begin
MADR_O[30:0] <= r_w_addr + tx_b1_offset[30:0];
MADR_O[31] <= 1'b0;
MCAB_O <= 1;
end
WB_WRITING: begin
MADR_O[30:0] <= r_w_addr + rx_b1_offset[30:0];
MADR_O[31] <= 1'b1;
MCAB_O <= 1;
end
WB_W_WAIT: begin
MADR_O[30:0] <= tx_b1_offset[30:0] + `DUMMY_READ_ADDR;
MADR_O[31] <= 1'b0;
MCAB_O <= 0;
end
default: begin
MADR_O[31:0] <= 0;
MCAB_O <= 1;
end
endcase
end
always@(*)
begin
leds[0] <= state_machine[0];
leds[1] <= state_machine[1];
leds[2] <= MINT_O;
if(next_state == WB_IDLE || next_state != state_machine)
begin
MSTB_O <= 1'b0;
MCYC_O <= 1'b0;
end
else
begin
MSTB_O <= 1'b1;
MCYC_O <= 1'b1;
end
end
assign wb_reading = (state_machine == WB_READING) ? 1'b1 : 1'b0;
assign r_counter_empty = (r_counter > 0)? 1'b0 : 1'b1;
assign w_counter_empty = (w_counter > 0)? 1'b0 : 1'b1;
pulse_gen read_ld_pulse
(
.Trigger (r_counter_empty),
.Pulse_Out (counter_loaded),
.Clock (CLK_I)
);
pulse_gen write_ld_pulse
(
.Trigger (w_counter_empty),
.Pulse_Out (w_counter_loaded),
.Clock (CLK_I)
);
endmodule
Thank you!
Article: 151630On Apr 26, 8:40=A0pm, rickman <gnu...@gmail.com> wrote: > On Apr 26, 10:07=A0pm, "mary" <marysowji.99@n_o_s_p_a_m.gmail.com> > wrote: > > > > > hi all, > > > i have a doubt regarding no.of slices in xlinx > > > what are slices? > > what are LUT? in xilinx > > > 1)the no.of slice constant in every version or does it vary? > > > 2)can the area of an architecture be decreased if we say no.of slices a= re > > decreased. > > is this type of approach is correct? > > or > > 3) how can we say a area of architecture is decreased? > > > 4)i am implementing project which is having the no.of slices in order o= f > > hundreds. > > where as the previous technique implemented have the no.of slices in or= der > > of thousands from =A0this can we conclude that the area is decreased. > > A LUT is a "look up table" and are how an FPGA implements > combinatorial logic. =A0For all practical purposes it is a block of > memory with the logic inputs used as the address and the data output > used as the logic output. =A0The memory contents defines that logic > function implemented. =A0Is that what you are asking? > > For a long time all LUTs in Xilinx parts had four inputs although they > did some funky things with multiplexers to allow two or even four of > the four input LUTS to be combined into five and even six input LUTS. > In some of the newer parts in the high end logic families they provide > six input LUTS. =A0This is partly because the parts are getting so large > that, like the CPUs in PCs they are having trouble finding ways to use > the larger number of transistors. =A0So they are making the LUTs > larger. > > A slice is just a grouping of LUTs and FFs and some connective > structure into the repeated unit of the FPGA. =A0The number of LUTs and > FFs vary with family. =A0Originally LUTs had two LUTs and two FFs. > According to the manual "Each Virtex-6 FPGA slice contains four LUTs > and eight flip-flops", but they also use the term "Logic Cells" which > is not a countable entity in a part, it is a marketing number like > "gates". > > Using the number of slices used is not a good metric for the size of a > design because if one LUT is used, the slice is counted as used. > Better to count the number of LUTs and FF used. =A0You can have 100% > slice utilization and still fit more into a chip. =A0But when 100% of > the LUTs and FFs are used, you will be hard pressed to add anything to > that design! > > Rick The OP should thank you for doing their (class) homework for them. RKArticle: 151631
On 27 abr, 07:00, "scrts" <hid...@email.com> wrote: > "poet_neel@yahoo." <poet_neel@n_o_s_p_a_m.yahoo.com> wrote in message > > news:Gpydncogtam15yrQnZ2dnUVZ_o6dnZ2d@giganews.com... > > > Me and some engineers run an FPGA prototyping company. The recent > > unfortunate disaster in Japan has thrown off our immediate forecasts, we > > have some left over inventory of SIV 230GX and SIV parts. This happens > > with > > us occasionally where we might have a few pieces here and there of parts. > > > Would someone be interested in acquiring these? These are brand new and in > > unopened hermetically sealed tray and hence guaranteed to work. The price > > ofcourse will be way cheaper that buying single units elsewhere(even if > > you > > are able to buy small units to begin with). > > Tell us the prices. Could you provide further information like the part numbers? Is it SIV(text) or SIII(title)? i am interested anyway luisf D.T rossi A.T gmail D.T comArticle: 151632
> >It could be due to PPM differences between the clock sources on your >boards where the two that are exhibiting a problem are either faster >or slower than the one that works well generating overruns or >underruns. If your code isn't sending idles or recognizing idles and >removing them this could be a problem. > >Or it could be due to two other issues that I described earlier that >you haven't mentioned addressing: > >- Data transfers between asynchronous clocks without synchronization >- Latches in the design due to HDL errors > >Ed McGettigan >-- >Xilinx Inc. > Hey, data transfers between asynchronous clocks are synced and there are no latches in the design. The behavior of the RTL is a little weird on the boards on which it is not working, let me explain if i may, i program a fresh FPGA (FPGA that hasn't been turned on for a while), packets seem to go smoothly, but after few seconds, packets start to drop, and eventually within a minute from start, packets stop going altogether =\ Since i have 2 interfaces on the board (interface A and interface B), and whatever i receive on A, i transmit it on B, this thing works fine. But the packets i receive on B and transmit on A, that's where the problem exists. kindly, give me some pointers so that i can debug the problem asap as it has started to get on my nerves =\ Thanks a lot regards, --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151633
> I have a Virtex4 MB board. It doesn't have an embedded MAC, that is > why I have to use soft IP core. What is my best option then? Can it > be done without using microblaze processor? > > By alternatives I meant, alternative to TEMAC IP core if I need to > have the ethernet connectivity... Whether or not you can get away with not using a processor depends on the nature of the data you're sending. If you're just transmitting a continuous stream of data, for example, a simple state machine is ample. You're welcome to have a look at a state machine implementation of a UDP packet generator and soft gigabit MAC I've put together: http://tristesse.org/DigilentAtlysResources This example doesn't use the Xilinx TEMAC, but it would be reasonably straightforward to convert, and the Xilinx core should be a lot simpler to use that than the core I employed. > The document you mentioned is using embedded MAC, however my board > doesn't have one. I have to use TEMAC soft IP core. Can you please > tell me any helpful tutorial or document which explains how to use > the core step by step. Thank you. DS537 should be all you need. There aren't really any introductory tutorials since everyone will want to use the core differently. You really ought to read it from beginning to end and study the timing diagrams to ensure that you understand how it works, and make notes about details that seem relevant to your application as you go. JoelArticle: 151634
On Apr 27, 11:59=A0am, "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: > >It could be due to PPM differences between the clock sources on your > >boards where the two that are exhibiting a problem are either faster > >or slower than the one that works well generating overruns or > >underruns. =A0If your code isn't sending idles or recognizing idles and > >removing them this could be a problem. > > >Or it could be due to two other issues that I described earlier that > >you haven't mentioned addressing: > > >- Data transfers between asynchronous clocks without synchronization > >- Latches in the design due to HDL errors > > >Ed McGettigan > >-- > >Xilinx Inc. > > Hey, data transfers between asynchronous clocks are synced and there are = no > latches in the design. The behavior of the RTL is a little weird on the > boards on which it is not working, let me explain if i may, i program a > fresh FPGA (FPGA that hasn't been turned on for a while), packets seem to > go smoothly, but after few seconds, packets start to drop, and eventually > within a minute from start, packets stop going altogether =3D\ > > Since i have 2 interfaces on the board (interface A and interface B), and > whatever i receive on A, i transmit it on B, this thing works fine. But t= he > packets i receive on B and transmit on A, that's where the problem exists= . > > kindly, give me some pointers so that i can debug the problem asap as it > has started to get on my nerves =3D\ > > Thanks a lot > > regards, =A0 =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com- Hide quoted text - > > - Show quoted text - How many levels of register synchronization did you use for the asynchronous signals? Please post the Device Utilization Summary portion of the PAR report file. How many WARNING messages are present in your synthesis report file? You said that a "fresh FPGA" works at the beginning and then starts to fail. Does this mean that if you reprogram the part after it has been running for a while it fails immediately? Ed McGettigan -- Xilinx Inc.Article: 151635
On Apr 27, 2:59=A0pm, "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: > > Hey, data transfers between asynchronous clocks are synced and there are = no > latches in the design. - Are the clocks all directly from either the input pin receiving an oscillator or the output of an internal PLL/DLL? (The only correct answer is 'yes') - Are any clocks generated internally to the design using either logic of flip flops? (The only correct answer is 'no') If your design does not have the correct answers as indicated above, then that is the source of your timing problem, you must find and fix it. > The behavior of the RTL is a little weird on the > boards on which it is not working, let me explain if i may, i program a > fresh FPGA (FPGA that hasn't been turned on for a while), packets seem to > go smoothly, but after few seconds, packets start to drop, and eventually > within a minute from start, packets stop going altogether =3D\ > When the story begins 'It works for a while and then stops working' or 'When I spray cold spray (or maybe a heat gun) it starts (or stops) working' then the story will always end the same...you have a timing problem, end of story. If you want to prolong the drama, try spraying your FPGA with cold spray to cool it off and watch it start working again...for the same few seconds (maybe longer)...then watch it stop working again. If you don't believe me, try it. At that point, you can continue the curiousity, or simply accept that the root cause is indeed a timing problem. > Since i have 2 interfaces on the board (interface A and interface B), and > whatever i receive on A, i transmit it on B, this thing works fine. But t= he > packets i receive on B and transmit on A, that's where the problem exists= . > Nothing that you've described will give anyone enough information to debug your problem for you so only general guidelines can be suggested...here are mine - Say to yourself, there is a timing problem with the design. - Say it again...and again if necessary until you fully accept that the problem is timing and you have to find it. - You have not correctly performed static timing analysis - Look at the timing report for the list of clock signals. Get rid of any internally generated clocks if there are any. Do not proceed any further until you have completed this task. - Look at the report for signals that asynchronously reset a flip flop. For each such signal, verify that the reset signal is the output of a flip flop that is clocked by the same clock signal that clocks the flip flop that is getting asynchronously reset. Repeat this until you have rid the design of all such reset signals. Note: This is not to say that you cannot use async reset signals, what it says is that the reset signal must first be synchronized to the clock that is used with the flop. That also implies that you cannot have an async reset signal that is used to clear flip flops in more than one clock domain. - Verify that the static timing analysis *is* analyzing signals that cross clock domains. If not enabled, it can't report such errors. Verify that each and every clock domain transfer is handled correctly. Do these transfers happen through a dual clock fifo part that you did *not* write the code for and is widely used? Or do some (all?) transfers happen through code that you wrote? If there are any that happen through code that you wrote...that is a likely source of the design error. - Verify that there are no signals that cross clock domains and end up at two different flip flops. The outputs of those flip flops will at some point be different even though you think they are both sampling the 'same' signal (which they're not). Rid your design of any such signals. > kindly, give me some pointers so that i can debug the problem asap as it > has started to get on my nerves =3D\ > Good luck on your search. Doggedly follow the guidelines posted above and you'll find the error. Kevin JenningsArticle: 151636
>On Apr 27, 2:59=A0pm, "salimbaba" ><a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: >> >> Hey, data transfers between asynchronous clocks are synced and there are = >no >> latches in the design. > >- Are the clocks all directly from either the input pin receiving an >oscillator or the output of an internal PLL/DLL? (The only correct >answer is 'yes') >- Are any clocks generated internally to the design using either logic >of flip flops? (The only correct answer is 'no') > >If your design does not have the correct answers as indicated above, >then that is the source of your timing problem, you must find and fix >it. > >> The behavior of the RTL is a little weird on the >> boards on which it is not working, let me explain if i may, i program a >> fresh FPGA (FPGA that hasn't been turned on for a while), packets seem to >> go smoothly, but after few seconds, packets start to drop, and eventually >> within a minute from start, packets stop going altogether =3D\ >> > >When the story begins 'It works for a while and then stops working' or >'When I spray cold spray (or maybe a heat gun) it starts (or stops) >working' then the story will always end the same...you have a timing >problem, end of story. > >If you want to prolong the drama, try spraying your FPGA with cold >spray to cool it off and watch it start working again...for the same >few seconds (maybe longer)...then watch it stop working again. If you >don't believe me, try it. At that point, you can continue the >curiousity, or simply accept that the root cause is indeed a timing >problem. > >> Since i have 2 interfaces on the board (interface A and interface B), and >> whatever i receive on A, i transmit it on B, this thing works fine. But t= >he >> packets i receive on B and transmit on A, that's where the problem exists= >. >> > >Nothing that you've described will give anyone enough information to >debug your problem for you so only general guidelines can be >suggested...here are mine > >- Say to yourself, there is a timing problem with the design. >- Say it again...and again if necessary until you fully accept that >the problem is timing and you have to find it. >- You have not correctly performed static timing analysis >- Look at the timing report for the list of clock signals. Get rid of >any internally generated clocks if there are any. Do not proceed any >further until you have completed this task. >- Look at the report for signals that asynchronously reset a flip >flop. For each such signal, verify that the reset signal is the >output of a flip flop that is clocked by the same clock signal that >clocks the flip flop that is getting asynchronously reset. Repeat >this until you have rid the design of all such reset signals. Note: >This is not to say that you cannot use async reset signals, what it >says is that the reset signal must first be synchronized to the clock >that is used with the flop. That also implies that you cannot have an >async reset signal that is used to clear flip flops in more than one >clock domain. >- Verify that the static timing analysis *is* analyzing signals that >cross clock domains. If not enabled, it can't report such errors. >Verify that each and every clock domain transfer is handled >correctly. Do these transfers happen through a dual clock fifo part >that you did *not* write the code for and is widely used? Or do some >(all?) transfers happen through code that you wrote? If there are any >that happen through code that you wrote...that is a likely source of >the design error. >- Verify that there are no signals that cross clock domains and end up >at two different flip flops. The outputs of those flip flops will at >some point be different even though you think they are both sampling >the 'same' signal (which they're not). Rid your design of any such >signals. > >> kindly, give me some pointers so that i can debug the problem asap as it >> has started to get on my nerves =3D\ >> > >Good luck on your search. Doggedly follow the guidelines posted above >and you'll find the error. > >Kevin Jennings > Hi Kevin, That's exactly what's happening, when the FPGA cools down, it again starts to transmit packets for a while and then eventually stops when the FPGA is hot. One thing i forgot to mention was that the packets that are sent out of the interface, when i capture them on wireshark, it shows some of them in CRC errors, some in receive errors and the rest nowhere. I tried to capture the packets on CHIPSCOPE, like on the transmitting end just before the packets exits the FPGA, the packet is fine till that point. So i placed another FPGA to capture it and it showed me a garbage packet, like data_valid signal going low right after SFD. Anyway that's just some information. I will follow the guidelines as there were NO in them. Thanks a lot --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151637
On Apr 28, 12:03=A0am, "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: > > I tried to capture the > packets on CHIPSCOPE, like on the transmitting end just before the packet= s > exits the FPGA, the packet is fine till that point. So i placed another > FPGA to capture it and it showed me a garbage packet, like data_valid > signal going low right after SFD. > Chipscope will not find the problem, it is not the right tool. Your best bet is to turn off the board, walk away from it, lock it up, do something to get it out of the picture but do not attempt to debug this problem on the bench with the board. You have a timing problem, and you'll never be able to find it via debug of the hardware so any time you spend trying to solve this problem by looking at the physical board is wasted time. The correct tool to use is static timing analysis which, if you follow the guidelines I suggested, will solve the problem if you apply them correctly. KJArticle: 151638
>On Apr 28, 12:03=A0am, "salimbaba" ><a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: >> >> I tried to capture the >> packets on CHIPSCOPE, like on the transmitting end just before the packet= >s >> exits the FPGA, the packet is fine till that point. So i placed another >> FPGA to capture it and it showed me a garbage packet, like data_valid >> signal going low right after SFD. >> > >Chipscope will not find the problem, it is not the right tool. Your >best bet is to turn off the board, walk away from it, lock it up, do >something to get it out of the picture but do not attempt to debug >this problem on the bench with the board. You have a timing problem, >and you'll never be able to find it via debug of the hardware so any >time you spend trying to solve this problem by looking at the physical >board is wasted time. > >The correct tool to use is static timing analysis which, if you follow >the guidelines I suggested, will solve the problem if you apply them >correctly. > >KJ > ok thanks a lot =) --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151639
On Apr 25, 7:44=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Apr 25, 12:39=A0pm, Pete Fraser <pfra...@covad.net> wrote: > > > > > > > Ed McGettigan wrote: > > > > Did you buy the EK-V6-ML605-G (base) or the DK-V6-EMBD-G-XP1 (embedde= d > > > processing) kit? > > > Embedded processing kit. > > > > Most of the reference designs can be found at: > > >http://www.xilinx.com/ml605 > > > That's where I had been looking. > > I can't find the video demo that's referenced > > in the printed documentation though... > > > The printed docs talk about ISE 12.1, so I assumed > > the video demo would at least be in the 12.1 archive, > > but it's not there. > > > The "Hardware and Demo Setup Guide" points me > > towww.xilinx.com/v6embkitformore information, > > but that seems to be a dead link. > > > Thanks > > > Pete > > Ok, so the CF card image matches the kit that you bought, but maybe > the printed documentation was wrong. > > There are several broken links with the xilinx.com site wide update > last week. =A0I will try to get this one fixed. =A0In the mean while you > can use this link:http://www.xilinx.com/products/boards-and-kits/DK-V6-EM= BD-G.htm > > Ed McGettigan > -- > Xilinx Inc.- Hide quoted text - > > - Show quoted text - The web team fixed the broken link that is used in all of board documentation: http://www.xilinx.com/v6embkit will now redirect to the correct location. Ed McGettigan -- Xilinx Inc.Article: 151640
In article <8c640be7-ed31-4ebe-901d-2f7aedd67fce@d28g2000yqc.googlegroups.com>, KJ <kkjennings@sbcglobal.net> writes: >The correct tool to use is static timing analysis which, if you follow >the guidelines I suggested, will solve the problem if you apply them >correctly. It might be a logic bug. He said packets coming in one side and going out the other. For that to work without a common clock, you have to have occasional idle time on the fast links so the slow links can keep up. Maybe it's something like he isn't discarding the idle markers on the way info the FIFO and recreating them as needed on the output side. That would break if the input side is faster. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 151641
I don't disagree with combing the STA reports, the synth/map/route warnings, and the async hand-offs for clues or even smoking guns. That needs to be done. But using chipscope could be fruitful if you are able to isolate where errors are first identified, such as where the first packet gets dropped. I imagine that would be an easy condition to trigger on, and your appropriate choice of signals to monitor might tell you exactly where the faulty hand-off occurs. Won't hurt to monitor all appropriate FIFO flags along with any other error detection logic. Of course, be careful not to create new problems. Use the correct (sync) clock for the signals you are monitoring. Also, hopefully your performance margins have enough headroom to absorb the added chipscope logic. It would be especially wasteful if you had to jump through hoops just to meet timing with the chipscope logic. - JohnArticle: 151642
On Apr 29, 7:29=A0am, jc <jcappe...@optimal-design.com> wrote: <snip> > added chipscope logic. It would be especially wasteful if you had to > jump through hoops just to meet timing with the chipscope logic. > - John I find that it frequently helps to use SmartGuide when adding ChipScope to a design. Start with the design that is meeting timing and is already fully implemented. Then add ChipScope to the design. Then turn on SmartGuide and finish the build. To turn on SmartGuide, in the Hierarchy window with the implementation view selected, right click on the top level of your design and select SmartGuide from the pop up menu. Do the same to turn it back off latter. This will both reduce the impact on timing of adding ChipScope, and when I use this on my designs it reduces the implementation times to about 1/3 of what they normally are. That said, this does sound like a timing problem. Regards, John McCaskill www.FasterTechnology.comArticle: 151643
Hi salimbaba ... That's exactly what's happening, when the FPGA cools down, it again starts to transmit packets for a while and then eventually stops when the FPGA is hot. ... Assuming your timings constraints are correctly defined, the implementation reports don't show errors and the silicon it's Ok, this sound like an asynchronism in the design. WalterArticle: 151644
We've now published the spring 2011 edition of Xcell Journal (issue 75), which a cover story on Xilinx's new Zynq-7000 EPP family (boots from an ARM Cortex A9 MPU core) and several great features including one on a new state-of-the-art radio astronomy system in Australia. The issue is available in "issuu" online magazine format as well as pdf: http://www.xilinx.com/publications/xcellonline/index.htm Also, if you would like to contribute an article for the next issue of Xcell, look me up: Mike.santarini(at)Xilinx.com Cheers, Mike Santarini Publisher, Xcell Journal, Xilinx Inc.Article: 151645
Philippe <philippe.faes@gmail.com> sent on March 8th, 2011: |---------------------------------------------------------------------| |"It was interesting to read some synthesis benchmarking results on | |comp.lang.vhdl last week. I feel it's high time that EDA vendors drop| |the anti-benchmarking clauses from their license agreements: | | | |[..]" | |---------------------------------------------------------------------| Who could feel confident about products which are not subjected to as much scrutiny as benchmarks from the Standard Performance Evaluation Corporation?Article: 151646
Hey, Thanks a lot everyone for the help, it surely taught me a lot of new things in the domain of debugging. The problem wasn't with the RTL or anything, it was a problem with the PHY. It was getting very hot, still in the operating range according to the datasheet but i don't know why it was transmitting any packets. So now i have attached a heat sink n a fan with it and everything is back to normal =) . Thanks a lot for your help guys. Regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151647
http://replay.web.archive.org/20080517153242/http://www.asm.ro/fpga/Article: 151648
dear all, I want to run scripts in "vtr_relase/reg_test/script". but I could not run them, I don not know how I can pass parameter. is there any one to help me ? thanks,Article: 151649
Hi all, For some reason synplify is resynthesizing my compile points even though the compile points' rtl have not changed and compile points' sdc files are the same as the initial compile. Synplify is saying "mapper or mapping options have changed" for all compile points in the design. I have not changed the mapping/synthesis options in the project file. Because I was doing some copying (I am working on a copy of the initial compile database and simply updating the rtl file list), the time stamp of the sdc files and compile point implementation folders have changed. Would this cause a resynthesis? Thanks, NuLL --------------------------------------- Posted through http://www.FPGARelated.com
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