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
Hi, I am using spartan3 xc3s4000 custom board in my design interfaced with a national PHY DP83865, xilinx 12.3 for synthesis and implementation and i'm facing a strange problem. I run the same RTL on two boards and it behaves differently on both of them. Has anyone faced this issue before ? Does anyone know why it's happening ? Thanks Regards Salimbaba --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151526
On Apr 17, 11:06=A0am, "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: > Hi, > I am using spartan3 xc3s4000 custom board in my design interfaced with a > national PHY DP83865, xilinx 12.3 for synthesis and implementation and i'= m > facing a strange problem. I run the same RTL on two boards and it behaves > differently on both of them. Has anyone faced this issue before ? Does > anyone know why it's happening ? > > Thanks > > Regards > Salimbaba =A0 =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com The most common reason is timing failures in the design due to: - Lack of any timing constraints - Missing IO timing constraints for device-to-device timing - Data transfers between asynchronous clocks without synchronization - Use of asynchronous resets - Latches in the design due to HDL errors I would start with reviewing all of the WARNINGs created by the synthesizer and ISE tools and then move on to the unconstrained paths reported by the timing analyzer. Ed McGettigan -- Xilinx Inc.Article: 151527
On Apr 17, 5:18=A0am, jacko <jackokr...@gmail.com> wrote: > On Saturday, 16 April 2011 21:18:18 UTC+1, rickman =A0wrote: > > <snip> > > > What was you goal in designing this CPU? > > To make a very small system (it includes a video and sound output too), a= fter that the priorities were a high MIPS/MB rating, a high MIPS rating, a = reasonably high code density using a dynamic compression system, and a foun= dation to make larger SMP systems. > > > What were you attempting to > > opimize? > > Mainly area, but the speed technology was used for the last compile as it= fits. > > > Only having a minus instruction for arithmetic seems like it > > might use a dozen or so fewer LUTs, but at what cost? =A0I can only > > assume that means an addition is done by first subtracting one addend > > from 0 and then subtracting it from the other addend. =A0So every add > > requires two instructions. =A0I believe your instruction set is pretty > > minimal from what I've seen. > > Yes, the instruction set is optimized for threaded code, and so it's like= ly + would be a subroutine. > > > How many bits wide are the stacks? =A0Just > > under 1000 LUTs is not bad for a 16 bit processor and is really good > > for a 32 bit machine. > > The stacks (2 of them) are 16 bit wide with auto increment and decrement. > > > Have you seen the ZPU? =A0It is a stack based machine designed to be > > coded in C! =A0What will they think of next... > > I had a look, and the very small version is limited in the number of inst= ructions it offers. Designed for C? Almost as funny a claim as designed for= Haskell... Not sure I follow. What do you mean the instructions are limited? They use emulation to implement some instructions depending on the core used. This is very much the Forth concept of building words. The C claim is not funny, It's real. They are using gcc I believe and people have used the ZPU in real apps. I wasn't impressed because it is not as fast as my design, but it is even smaller and faster versions are not a lot bigger. So I have to give them their due. They met their goal of making the smallest possible (32 bit!) processor supported by a C compiler with variations designed for higher speeds. I don't think there is ANY other soft CPU under several thousand LUTs that has a C compiler. RickArticle: 151528
On Sunday, 17 April 2011 23:00:57 UTC+1, rickman wrote: > On Apr 17, 5:18=A0am, jacko <jacko...@gmail.com> wrote: > > On Saturday, 16 April 2011 21:18:18 UTC+1, rickman =A0wrote: > > > > <snip> > > > > > What was you goal in designing this CPU? > > > > To make a very small system (it includes a video and sound output too),= after that the priorities were a high MIPS/MB rating, a high MIPS rating, = a reasonably high code density using a dynamic compression system, and a fo= undation to make larger SMP systems. > > > > > What were you attempting to > > > opimize? > > > > Mainly area, but the speed technology was used for the last compile as = it fits. > > > > > Only having a minus instruction for arithmetic seems like it > > > might use a dozen or so fewer LUTs, but at what cost? =A0I can only > > > assume that means an addition is done by first subtracting one addend > > > from 0 and then subtracting it from the other addend. =A0So every add > > > requires two instructions. =A0I believe your instruction set is prett= y > > > minimal from what I've seen. > > > > Yes, the instruction set is optimized for threaded code, and so it's li= kely + would be a subroutine. > > > > > How many bits wide are the stacks? =A0Just > > > under 1000 LUTs is not bad for a 16 bit processor and is really good > > > for a 32 bit machine. > > > > The stacks (2 of them) are 16 bit wide with auto increment and decremen= t. > > > > > Have you seen the ZPU? =A0It is a stack based machine designed to be > > > coded in C! =A0What will they think of next... > > > > I had a look, and the very small version is limited in the number of in= structions it offers. Designed for C? Almost as funny a claim as designed f= or Haskell... >=20 > Not sure I follow. What do you mean the instructions are limited? > They use emulation to implement some instructions depending on the > core used. This is very much the Forth concept of building words. Yes the emulation to reduce core size, 'having' instructions but not implem= enting them in hardware is not having them at all, and is marketing speak. > The C claim is not funny, It's real. They are using gcc I believe and > people have used the ZPU in real apps. I wasn't impressed because it > is not as fast as my design, but it is even smaller and faster > versions are not a lot bigger. So I have to give them their due. > They met their goal of making the smallest possible (32 bit!) > processor supported by a C compiler with variations designed for > higher speeds. I don't think there is ANY other soft CPU under > several thousand LUTs that has a C compiler. Supporting C, that's good, but designed for C is more marketing speak. Cons= idering C was designed to work on processors, I'd expect a stack frame link= instruction similar to the 68k at least... with word stride multiplication= for pointer arithmetic... but fair dues, it's not too bad, but suffers fro= m hype. Cheers JackoArticle: 151529
Hello: So I have a separate modules foo (with signals: foo_a, foo_b, foo_c) and have another module foo1 (with signals: foo_x, foo_y, foo_z) which instantiates foo within its module. Now when I run a test on foo1, on ModelSim, the signals I can see to add are the foo_x, foo_y and foo_z only. How do I get to add foo_a, foo_b and foo_c signals to the wave, so that I could see what's going on inside. I'm guessing this has to be with the paths, need help! Thanks!Article: 151530
Hi, i have a very weird behavior on a Veriglog code and i need some help.
Just a fast exaplanation. It is a Wishbone master that should perform N
reads, and the number N is defined by a number that i load on the
r_counter.
The code is the following:
`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,
r_bus_data_in,
data_sent,
DATA_READY,
leds,
MEMORY
);
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] MEMORY;
input [31:0] r_bus_data_in;
output data_sent;
input DATA_READY;
output [3:0] leds;
output counter_loaded;
parameter WB_IDLE = 5'b00001;
parameter WB_WRITING = 5'b00010;
parameter WB_READING = 5'b00100;
parameter WB_INT_ACK = 5'b01000;
parameter WB_W_WAIT = 5'b10000;
reg [31:0] MADR_O = 32'h40000000;
reg [31:0] MDAT_O;
wire [31:0] MDAT_I;
wire [3:0] MSEL_O;
reg MCYC_O;
reg MSTB_O;
wire MWE_O;
reg MCAB_O;
wire MACK_I;
wire MRTY_I;
wire MINT_O;
reg [31:0] r_counter = 0;
reg [4:0] state_machine = WB_IDLE;
reg [4:0] next_state = WB_IDLE;
reg int_ack_done = 0;
reg write_done = 0;
reg r_counter_empty = 1'b1;
wire wb_int_gen;
wire DATA_READY;
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] MEMORY;
wire [31:0] r_bus_data_in;
reg data_sent = 0;
reg [29:0] r_w_addr;
//###########################################################
reg [3:0] MRTY_C = 0;
reg [3:0] MACK_C = 0;
reg [3:0] leds;
//###########################################################
assign MSEL_O = 4'b1111;
assign MINT_O = wb_int_gen;
//assign DATA_READY = 1'b0;
assign wb_int_gen = tx_b_1_int|
tx_b_2_int|
rx_b_1_int|
rx_b_2_int;
/*##################################################################################
############################ state_machine CONTROL
#################################
##################################################################################*/
always@(state_machine or r_counter or tx_b_1_int or tx_b_2_int or
write_done or int_ack_done or DATA_READY)
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;
case (state_machine)
WB_IDLE :
begin
if(r_counter > 32'h00000000)
begin
next_state = WB_READING;
end
end
WB_READING :
begin
if(r_counter == 32'h00000000)
begin
//next_state = WB_INT_ACK;
next_state = WB_IDLE;
rx_b_1_over = 1'b1;
end
end
WB_WRITING :
begin
if(DATA_READY == 1'b0)
next_state = WB_W_WAIT;
end
WB_INT_ACK :
begin
if(int_ack_done)
next_state = WB_IDLE;
end
WB_W_WAIT :
begin
if(write_done)
begin
next_state = WB_INT_ACK;
tx_b_1_over = 1'b1;
end
end
default:begin
next_state = WB_IDLE ;
end
endcase
end
/*##################################################################################
############################ state_machine TIMING
##################################
##################################################################################*/
always@(posedge CLK_I)
begin
state_machine = next_state;
end
/*##################################################################################
############################ int_ack_done CONTROL
##################################
##################################################################################*/
always@(posedge CLK_I)
begin
int_ack_done = 1'b0;
if(state_machine == WB_INT_ACK)
begin
if(MCYC_O && MACK_I)
int_ack_done = 1'b1;
end
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
always@(posedge CLK_I)
begin
case (next_state)
WB_IDLE : begin
if(r_cmnd_flag)
begin
r_counter <= r_cnt_reg;
r_w_addr <= 30'h0;
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
r_w_addr <= r_w_addr + 29'h4;
data_sent = ~data_sent;
end
end
endcase
// end
end
always@(negedge CLK_I)
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_INT_ACK: begin
MADR_O[30:0] <= `ACK_CYC_ADDR;
MADR_O[31] <= 1'b0;
MCAB_O <= 0;
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@(negedge CLK_I)
begin
if(next_state == WB_IDLE)
begin
MSTB_O <= 1'b0;
MCYC_O <= 1'b0;
end
else
begin
MSTB_O <= 1'b1;
MCYC_O <= 1'b1;
end
end
always@(r_counter)
begin
r_counter_empty = (r_counter > 0)? 1'b0 : 1'b1;
end
pulse_gen read_ld_pulse
(
.Trigger (r_counter_empty),
.Pulse_Out (counter_loaded),
.Clock (CLK_I)
);
endmodule
The simulation works ok... but when i implement that on a Spartan III i got
a wird behavior on my FSM. For some reason the state keeps jumping from
IDLE to READING, and from READING to IDLE, but the r_counter is not
moving... so if i write 5 on r_counter.. it stay on 5 but the states keep
moving. Any idea of what could couse that? As i do not have chipscope i am
using 4 seven seg. display and 3 leds to debug. On the display i am looking
to the counter, and at the leds on the first 3 elements of the next_state
array, so i can see if it stay at IDLE or READING, but the result is that i
can see that the the first and third led are ON, but not wih full power...
as it was being driven by a PWM signal, so i could supose that the FSM
keeps jumping between both states...
Any help please?
I will not give any further detail now becouse they are irrelevant as all
teh rest looks ok, and i can see the r_counter value...
Thank you!
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 151531"Symon" <symon_brewer@hotmail.com> wrote in message news:iock9m$j6s$1@dont-email.me... > How would you probe on the input IOBs of the IC's receiver circuit with a > differential probe of a Tek P5700 series or similar? I would route the lvds signal out to a TP basically.. And maybe even to a LVDS TP if needed.. I also often generate redundant testpoints to check for errors in the logic (buffer under/overflows and similar). This is not ment to be used to check SI, but rather test the logic. Unfortunately simulating what I do has to be limited to smaller blocks, cause the complexity is huge!Article: 151532
>Hello: > >So I have a separate modules foo (with signals: foo_a, foo_b, foo_c) >and have another module foo1 (with signals: foo_x, foo_y, foo_z) which >instantiates foo within its module. > >Now when I run a test on foo1, on ModelSim, the signals I can see to >add are the foo_x, foo_y and foo_z only. How do I get to add foo_a, >foo_b and foo_c signals to the wave, so that I could see what's going >on inside. I'm guessing this has to be with the paths, need help! >Thanks! > RTFM. add wave foo_instance_name/foo* Or select the signals from the navigator window that is probably in the top left of the GUI display, by clicking [+] icons to expand the instantiated modules. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151533
>Hi, >I am using spartan3 xc3s4000 custom board in my design interfaced with a >national PHY DP83865, xilinx 12.3 for synthesis and implementation and i'm >facing a strange problem. I run the same RTL on two boards and it behaves >differently on both of them. Has anyone faced this issue before ? Does >anyone know why it's happening ? Do you know that both boards are built correctly? Could it be a board hardware fault? Does either board behave 'correctly'? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151534
On 4/18/2011 8:37 AM, Morten Leikvoll wrote: > "Symon"<symon_brewer@hotmail.com> wrote in message > news:iock9m$j6s$1@dont-email.me... >> How would you probe on the input IOBs of the IC's receiver circuit with a >> differential probe of a Tek P5700 series or similar? > > I would route the lvds signal out to a TP basically.. And maybe even to a > LVDS TP if needed.. > I also often generate redundant testpoints to check for errors in the logic > (buffer under/overflows and similar). > This is not ment to be used to check SI, but rather test the logic. > Unfortunately simulating what I do has to be limited to smaller blocks, > cause the complexity is huge! > > Hi Morten, Have you considered using something like ChipScope or SignalTap? HTH, Syms.Article: 151535
On 18 Apr., 00:00, rickman <gnu...@gmail.com> wrote: >=A0I don't think there is ANY other soft CPU under > several thousand LUTs that has a C compiler. > Please do not forget my ERIC5: About 300 LUTs, about ATMEL AVR performance, with C-compiler. Regards, Thomas www.entner-electronics.comArticle: 151536
"Symon" <symon_brewer@hotmail.com> wrote in message news:ioh0nl$8nq$1@dont-email.me... > On 4/18/2011 8:37 AM, Morten Leikvoll wrote: >> "Symon"<symon_brewer@hotmail.com> wrote in message >> news:iock9m$j6s$1@dont-email.me... >>> How would you probe on the input IOBs of the IC's receiver circuit with >>> a >>> differential probe of a Tek P5700 series or similar? >> >> I would route the lvds signal out to a TP basically.. And maybe even to a >> LVDS TP if needed.. >> I also often generate redundant testpoints to check for errors in the >> logic >> (buffer under/overflows and similar). >> This is not ment to be used to check SI, but rather test the logic. >> Unfortunately simulating what I do has to be limited to smaller blocks, >> cause the complexity is huge! >> >> > Hi Morten, > Have you considered using something like ChipScope or SignalTap? > HTH, Syms. Yes, I have.. They may have their function but what kills it is the limitations. When I used xilinx I was a fan of the FPGA editor and often used it to tap signals and route it to testpoints. Now Im on an Altera project, and I am still looking for a similar simple method to probe, without having to rebuild the entire code. But I'm a bit disappointed that there is no reply to my original Q. Does this mean that not a lot of fpga coders use oscilloscopes any more? (who does?)Article: 151537
On 18 Apr., 12:08, Thomas Entner <thomas.entne...@gmail.com> wrote: > On 18 Apr., 00:00, rickman <gnu...@gmail.com> wrote:>=A0I don't think the= re is ANY other soft CPU under > > several thousand LUTs that has a C compiler. > > Please do not forget my ERIC5: About 300 LUTs, about ATMEL AVR > performance, with C-compiler. > > Regards, > > Thomas > > www.entner-electronics.com P.S.: And it even includes an add-instruction ;-) Not to mention the multiplier...Article: 151538
I think the big problem, unless you are part of a large or well off company is the cost of the scope. I work for myself and would love to have a 10 GHz scope for the odd time I need it but the cost is just ridiculuos. Saying that I have found that the majority of the time with good design and pcb layout I havent really needed a scope as things have worked pretty much ok. If you can't afford something it makes you try harder to find other ways to do the job so you dont need it. Probably ebay would be your best shot of getting a scope but I would think you are still talking quite a few dollars. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151539
You really need to learn how to write verilog code correctly first. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151540
On Apr 16, 2:53=A0pm, "Phil Jessop" <p...@noname.org> wrote: > "Symon" <symon_bre...@hotmail.com> wrote in message > > news:ioc0t1$8h2$1@dont-email.me... > > > > > > > > > > > On 4/16/2011 10:37 AM, Phil Jessop wrote: > >> "Symon"<symon_bre...@hotmail.com> =A0wrote in message > >>news:ioalgd$vho$1@dont-email.me... > >>> On 4/15/2011 9:36 PM, Morten Leikvoll wrote: > >>>> Im looking for an analog oscilloscope in the 2Ghz+ analog bw range a= nd > >>>> wonder if you have any experience to share. Im used to the infiniium > >>>> 54825, > >>>> but want to go faster (but not spend a fortune on a new one). I've s= een > >>>> a > >>>> couple of "old" 54846 on ebay, and one recently went for $2800 wich = is > >>>> a > >>>> price I can handle, but the next price on the list is not that nice. > >>>> I want to probe LVDS@1-2GHz signals, DVI and ddr3 memory buses at > >>>> 533Mhz. > > >>> Hi Morten, > >>> How much is Hyperlynx? > >>> HTH, Syms. > > >> More than the cost of a decent scope - and it's only a simulation so > >> garbage > >> in -> =A0garbage out. > > >> HTH > > >> Phil > > > Hi Phil, > > Perhaps you can explain how you would use a 'scope to measure the OP's > > "LVDS@1-2GHz signals"? > > Thanks, Symon. > > Hi Symon, > > ??? > > Use a 2GHz scope with a differential probe. (Tek P7500 series or similar) > > Are you new to this game? > > Thanks > > Phil A 2 GHz signal has a fundamental frequency of 1GHz and to be worth looking at you need to see the 5th harmonic. Looking at a sine wave with your P7500 or similar is a complete waste of time. Usenet would be a much nicer place if everyone responded to snipes like your "new to this game" in the way that Symon did. We work at the edge, Gigabit ethernet, MGts, screaming DDR3s Virtex 7 and we know what's after 7 and roughly what's after that and we never look at waveforms. Protocol analyzers perhaps but almost entirely simulation. ColinArticle: 151541
On 4/18/2011 11:32 AM, maxascent wrote: > I think the big problem, unless you are part of a large or well off company > is the cost of the scope. I work for myself and would love to have a 10 GHz > scope for the odd time I need it but the cost is just ridiculuos. Saying > that I have found that the majority of the time with good design and pcb > layout I havent really needed a scope as things have worked pretty much ok. > If you can't afford something it makes you try harder to find other ways to > do the job so you dont need it. Probably ebay would be your best shot of > getting a scope but I would think you are still talking quite a few > dollars. > > Jon > > --------------------------------------- > Posted through http://www.FPGARelated.com What he said! ^^^ We have a 10 Gsps 'scope. We rarely use it, and even when we do fire it up, it rarely helps us solve the problem! I really should pack it away somewhere inaccessible. Then we would debug much more quickly. It also makes the office get very warm... Cheers, Syms.Article: 151542
"colin" <colin_toogood@yahoo.com> wrote in message news:0703993f-e992-4700-bc72-b52c978fe4fc@a11g2000pro.googlegroups.com... >We work at the edge, Gigabit ethernet, MGts, screaming DDR3s Virtex 7 >and we know what's after 7 and roughly what's after that and we never >look at waveforms. Protocol analyzers perhaps but almost entirely >simulation. How do you debug very complex systems? By spending months on finding and setting up a failing environment? I work with a video processor having an unknown number of unknown inputs (with uknown clk domains and vertical scan phases) and outputs at configured resolutions and quite a few handfuls of registers. I understand that for some end use scenarios the verification is much more important than in my case, but for video processing where we have lots of "visual probes" in shape of monitors connected, I want to utilize them. The most effective way of capturing bugs is to actually SEE the bug first, and then probe the fpga to see where things didn't go as planned. Trying to make a testbench for all these umlimited combinations is not necessary or possible. Simulation has been very useful to get it up and running in the first place, but scope is priceless to capture the bugs. I could use logic analyzers as well, but that gives me less information and needs more pcb infrastructure to have any use. I can do most tests in 4ch, and just add TP multiplexers.Article: 151543
On Apr 18, 12:12=A0pm, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote: > "colin" <colin_toog...@yahoo.com> wrote in message > > news:0703993f-e992-4700-bc72-b52c978fe4fc@a11g2000pro.googlegroups.com... > > >We work at the edge, Gigabit ethernet, MGts, screaming DDR3s Virtex 7 > >and we know what's after 7 and roughly what's after that and we never > >look at waveforms. Protocol analyzers perhaps but almost entirely > >simulation. > > How do you debug very complex systems? By spending months on finding and > setting up a failing environment? > I work with a video processor having an unknown number of unknown inputs > (with uknown clk domains and vertical scan phases) and outputs at configu= red > resolutions and quite a few handfuls of registers. I understand that for > some end use scenarios the verification is much more important than in my > case, but for video processing where we have lots of "visual probes" in > shape of monitors connected, I want to utilize them. The most effective w= ay > of capturing bugs is to actually SEE the bug first, and then probe the fp= ga > to see where things didn't go as planned. Trying to make a testbench for = all > these umlimited combinations is not necessary or possible. > Simulation has been very useful to get it up and running in the first pla= ce, > but scope is priceless to capture the bugs. I could use logic analyzers a= s > well, but that gives me less information and needs more pcb infrastructur= e > to have any use. I can do most tests in 4ch, and just add TP multiplexers= . I used the term "protocol analyser" in its loosest sense. If you want to look at video use a CRT if that is all you can afford but a video protocol analyser will tell you what is wrong fundamentally quicker than hooking up a scope. I also meant hyperlynx simulation rather than modelsim. You said you wanted to look at DDR3 and gigabit stuff. If you spend less than $2K on a probe the act of looking at the signal will mess it up. I've designed DDR2 96bit wide stuff and never probed it, you can't because the chips are on both sides of the board and the routing is on internal layers. The lousiest design on the planet will work at 25 centigrade so you don't need a scope. Your welcome to hook a scope up in an oven and see why it doesn't work at 55 or -5. Instead make darn sure your at 50 ohms and you have simulated and have chipscope report all the timing parameters that the mig is using. If none of the timings are at an end of their scale you have a design you can build a thousand of. hmm, sorry that was a bit of a rant but I'm not going to reword it :) ColinArticle: 151544
"Morten Leikvoll" <mleikvol@yahoo.nospam> wrote: >"Symon" <symon_brewer@hotmail.com> wrote in message >news:ioh0nl$8nq$1@dont-email.me... >> On 4/18/2011 8:37 AM, Morten Leikvoll wrote: >>> "Symon"<symon_brewer@hotmail.com> wrote in message >>> news:iock9m$j6s$1@dont-email.me... >>>> How would you probe on the input IOBs of the IC's receiver circuit with >>>> a >>>> differential probe of a Tek P5700 series or similar? >>> >>> I would route the lvds signal out to a TP basically.. And maybe even to a >>> LVDS TP if needed.. >>> I also often generate redundant testpoints to check for errors in the >>> logic >>> (buffer under/overflows and similar). >>> This is not ment to be used to check SI, but rather test the logic. >>> Unfortunately simulating what I do has to be limited to smaller blocks, >>> cause the complexity is huge! >>> >>> >> Hi Morten, >> Have you considered using something like ChipScope or SignalTap? >> HTH, Syms. > >Yes, I have.. They may have their function but what kills it is the >limitations. >When I used xilinx I was a fan of the FPGA editor and often used it to tap >signals and route it to testpoints. >Now Im on an Altera project, and I am still looking for a similar simple >method to probe, without having to rebuild the entire code. > >But I'm a bit disappointed that there is no reply to my original Q. Does >this mean that not a lot of fpga coders use oscilloscopes any more? (who >does?) I mostly use a logic analyzer. Still probing can be the killer. An oscilloscope is one thing but beyond 100MHz you'll need special probes which can cost major $$$. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 151545
Hi, I used the ML403 on a couple of projects and no longer have any use for it. It comes with the USB programming pod for $175 which includes shipping. This is only for sale in the USA. Thanks for lookingArticle: 151546
T24gQXByIDE3LCA3OjU3oHBtLCAiU2luazAiIDxzaW5rMDBAbl9vX3NfcF9hX20ubl9vX3NfcF9h X20uZ21haWwuY29tPgp3cm90ZToKPiBIaSwgaSBoYXZlIGEgdmVyeSB3ZWlyZCBiZWhhdmlvciBv biBhIFZlcmlnbG9nIGNvZGUgYW5kIGkgbmVlZCBzb21lIGhlbHAuCj4KPiBKdXN0IGEgZmFzdCBl eGFwbGFuYXRpb24uIEl0IGlzIGEgV2lzaGJvbmUgbWFzdGVyIHRoYXQgc2hvdWxkIHBlcmZvcm0g Tgo+IHJlYWRzLCBhbmQgdGhlIG51bWJlciBOIGlzIGRlZmluZWQgYnkgYSBudW1iZXIgdGhhdCBp IGxvYWQgb24gdGhlCj4gcl9jb3VudGVyLgo+Cj4gVGhlIGNvZGUgaXMgdGhlIGZvbGxvd2luZzoK Pgo+IGBpbmNsdWRlICJuZXR3b3JrX2NvbnRyb2xsZXJfY29uc3RhbnRzLnYiCj4KPiBtb2R1bGUg TkVUV09SS19DT05UUk9MTEVSX1dCX01BU1RFUgo+ICgKPiCgIKAgoCCgIENMS19JLCCgIKAgoCCg IKAgoAo+IKAgoFJTVF9JLAo+Cj4goCCgIKAgoCBNSU5UX08sCj4goCCgIKAgoCBNQURSX08sCj4g oCCgIKAgoCBNREFUX08sCj4goCCgIKAgoCBNREFUX0ksCj4goCCgIKAgoCBNU0VMX08sCj4goCCg IKAgoCBNQ1lDX08sCj4goCCgIKAgoCBNU1RCX08sCj4goCCgIKAgoCBNV0VfTywKPiCgIKAgoCCg IE1DQUJfTywKPiCgIKAgoCCgIE1BQ0tfSSwKPiCgIKAgoCCgIE1SVFlfSSwKPiCgIKBNRVJSX0ks Cj4KPiCgIKAgoCCgIHR4X2IxX29mZnNldCwKPiCgIKAgoCCgIHR4X2IyX29mZnNldCwKPiCgIKAg oCCgIHJ4X2IxX29mZnNldCwKPiCgIKAgoCCgIHJ4X2IyX29mZnNldCwKPgo+IKAgoCCgIKAgcl9j bnRfcmVnLAo+IKAgoCCgIKAgcl9jbW5kX2ZsYWcsCj4KPiCgIKAgoCCgIHR4X2JfMV9pbnQsCj4g oCCgIKAgoCB0eF9iXzJfaW50LAo+IKAgoCCgIKAgcnhfYl8xX2ludCwKPiCgIKAgoCCgIHJ4X2Jf Ml9pbnQsCj4KPiCgIKAgoCCgIHR4X2JfMV9vdmVyLAo+IKAgoCCgIKAgdHhfYl8yX292ZXIsCj4g oCCgIKAgoCByeF9iXzFfb3ZlciwKPiCgIKAgoCCgIHJ4X2JfMl9vdmVyLAo+Cj4goCCgIKAgoCBy X2NvdW50ZXJfZW1wdHksCj4goCCgIKAgoCBjb3VudGVyX2xvYWRlZCwKPgo+IKAgoCCgIKAgcl9i dXNfZGF0YV9pbiwKPiCgIKAgoCCgIGRhdGFfc2VudCwKPiCgIKAgoCCgIERBVEFfUkVBRFksCj4K PiCgIKAgoCCgIGxlZHMsCj4KPiCgIKAgoCCgIE1FTU9SWQo+ICk7Cj4KPiBpbnB1dCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIENMS19JOyCgIKAgoCCgIKAgoAo+IGlucHV0IKAgoCCgIKAgoCCg IFJTVF9JOwo+Cj4gb3V0cHV0IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBNSU5UX087Cj4gb3V0 cHV0IKAgWzMxOjBdIKAgoCCgIKAgTUFEUl9POwo+IGlucHV0IKAgoFszMTowXSCgIKAgoCCgIE1E QVRfSTsKPiBvdXRwdXQgoCBbMzE6MF0goCCgIKAgoCBNREFUX087Cj4gb3V0cHV0IKAgWzM6MF0g oCCgIKAgoCCgTVNFTF9POwo+IG91dHB1dCCgIKAgoCCgIKAgoE1DWUNfTzsKPiBvdXRwdXQgoCCg IKAgoCCgIKBNU1RCX087Cj4gb3V0cHV0IKAgoCCgIKAgoCCgTVdFX087Cj4gb3V0cHV0IKAgoCCg IKAgoCCgTUNBQl9POwo+IGlucHV0IKAgoCCgIKAgoCCgIKAgoCCgIE1BQ0tfSTsKPiBpbnB1dCCg IKAgoCCgIKAgoCCgIKAgoCBNUlRZX0k7Cj4gaW5wdXQgoCCgIKAgoCCgIKAgoCCgIKAgTUVSUl9J Owo+Cj4gaW5wdXQgoCCgIKAgoCCgIFszMTowXSCgdHhfYjFfb2Zmc2V0Owo+IGlucHV0IKAgoCCg IKAgoCBbMzE6MF0goHR4X2IyX29mZnNldDsKPiBpbnB1dCCgIKAgoCCgIKAgWzMxOjBdIKByeF9i MV9vZmZzZXQ7Cj4gaW5wdXQgoCCgIKAgoCCgIFszMTowXSCgcnhfYjJfb2Zmc2V0Owo+Cj4gb3V0 cHV0IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB0eF9iXzFfb3ZlcjsKPiBvdXRwdXQgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoHR4X2JfMl9vdmVyOwo+IG91dHB1dCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgcnhfYl8xX292ZXI7Cj4gb3V0cHV0IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBy eF9iXzJfb3ZlcjsKPgo+IGlucHV0IKAgoCCgIKAgoCBbMzE6MF0goHJfY250X3JlZzsKPiBpbnB1 dCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcl9jbW5kX2ZsYWc7Cj4KPiBpbnB1 dCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgdHhfYl8xX2ludDsKPiBpbnB1dCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgdHhfYl8yX2ludDsKPiBpbnB1dCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcnhfYl8xX2ludDsKPiBpbnB1dCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcnhfYl8yX2ludDsKPgo+IG91dHB1dCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgcl9jb3VudGVyX2VtcHR5Owo+Cj4gb3V0cHV0IKBbMzE6MF0goE1F TU9SWTsKPgo+IGlucHV0IKAgoCCgIKAgoCBbMzE6MF0goHJfYnVzX2RhdGFfaW47Cj4gb3V0cHV0 IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBkYXRhX3NlbnQ7Cj4gaW5wdXQgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIERBVEFfUkVBRFk7Cj4KPiBvdXRwdXQgoFszOjBdIKAgoCCg IKAgoCBsZWRzOwo+Cj4gb3V0cHV0IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBjb3VudGVyX2xv YWRlZDsKPgo+IHBhcmFtZXRlciBXQl9JRExFIKAgoCCgID0goCCgIKAgoCA1J2IwMDAwMTsgoCCg Cj4gcGFyYW1ldGVyIFdCX1dSSVRJTkcgoCCgPSA1J2IwMDAxMDsKPiBwYXJhbWV0ZXIgV0JfUkVB RElORyCgIKA9IDUnYjAwMTAwOwo+IHBhcmFtZXRlciBXQl9JTlRfQUNLIKAgoD0gNSdiMDEwMDA7 Cj4gcGFyYW1ldGVyIFdCX1dfV0FJVCCgIKAgPSA1J2IxMDAwMDsKPgo+IHJlZyCgIKAgoCCgIKAg oCBbMzE6MF0goE1BRFJfTyA9IDMyJ2g0MDAwMDAwMDsKPiByZWcgoCCgIKAgoCCgIKAgWzMxOjBd IKBNREFUX087Cj4gd2lyZSCgIKAgoCCgIKAgoFszMTowXSCgTURBVF9JOwo+IHdpcmUgoCCgIKAg oCCgIKBbMzowXSCgIKAgoCCgIKAgTVNFTF9POwo+IHJlZyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCBNQ1lDX087Cj4gcmVnIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIE1TVEJfTzsKPiB3aXJlIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg TVdFX087Cj4gcmVnIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIE1DQUJfTzsK PiB3aXJlIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgTUFDS19JOwo+IHdpcmUg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBNUlRZX0k7Cj4gd2lyZSCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoE1JTlRfTzsKPgo+IHJlZyCgIKAgoCCgIKAgoCBb MzE6MF0goHJfY291bnRlciA9IDA7Cj4gcmVnIKAgoCCgIKAgoCCgIFs0OjBdIKAgoCCgIKAgoCBz dGF0ZV9tYWNoaW5lID0gV0JfSURMRTsKPiByZWcgoCCgIKAgoCCgIKAgWzQ6MF0goCCgIKAgoCCg IG5leHRfc3RhdGUgPSBXQl9JRExFOwo+IHJlZyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCBpbnRfYWNrX2RvbmUgPSAwOwo+IHJlZyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCB3cml0ZV9kb25lID0gMDsKPiByZWcgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgcl9jb3VudGVyX2VtcHR5ID0gMSdiMTsKPiB3aXJlIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgd2JfaW50X2dlbjsKPiB3aXJlIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgREFUQV9SRUFEWTsKPgo+IHJlZyCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCB0eF9iXzFfb3ZlciA9IDA7Cj4gcmVnIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIHR4X2JfMl9vdmVyID0gMDsKPiByZWcgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgcnhfYl8xX292ZXIgPSAwOwo+IHJlZyCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCByeF9iXzJfb3ZlciA9IDA7Cj4KPiByZWcgoCCgIKAgoCCg IKAgWzMxOjBdIKBNRU1PUlk7Cj4gd2lyZSCgIKAgoCCgIKAgoFszMTowXSCgcl9idXNfZGF0YV9p bjsKPiByZWcgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgZGF0YV9zZW50ID0g MDsKPgo+IHJlZyCgIKAgoCCgIKAgoCBbMjk6MF0goHJfd19hZGRyOwo+Cj4gLy8jIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwo+Cj4gcmVn IKAgoCCgIKAgoCCgIFszOjBdIKAgoCCgIKAgoCBNUlRZX0MgPSAwOwo+IHJlZyCgIKAgoCCgIKAg oCBbMzowXSCgIKAgoCCgIKAgTUFDS19DID0gMDsgoCCgCj4gcmVnIKAgoCCgIKAgoCCgIFszOjBd IKAgoCCgIKAgoCBsZWRzOyCgCj4KPiAvLyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIKAKPgo+IGFzc2lnbiBNU0VMX08gPSA0J2IxMTEx Owo+IGFzc2lnbiBNSU5UX08gPSB3Yl9pbnRfZ2VuOwo+IC8vYXNzaWduIERBVEFfUkVBRFkgPSAx J2IwOwo+Cj4gYXNzaWduIKB3Yl9pbnRfZ2VuID0goCCgdHhfYl8xX2ludHwKPiCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgdHhf Yl8yX2ludHwKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgcnhfYl8xX2ludHwKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcnhfYl8yX2ludDsKPgo+IC8q IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwo+ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMg c3RhdGVfbWFjaGluZSBDT05UUk9MCj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj Cj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyovCj4KPiBhbHdheXNAKHN0YXRlX21hY2hpbmUg b3Igcl9jb3VudGVyIG9yIHR4X2JfMV9pbnQgb3IgdHhfYl8yX2ludCBvcgo+IHdyaXRlX2RvbmUg b3IgaW50X2Fja19kb25lIG9yIERBVEFfUkVBRFkpCj4gYmVnaW4KPiCgIKAgoCCgIHR4X2JfMV9v dmVyID0gMSdiMDsKPiCgIKAgoCCgIHR4X2JfMl9vdmVyID0gMSdiMDsKPiCgIKAgoCCgIHJ4X2Jf MV9vdmVyID0gMSdiMDsKPiCgIKAgoCCgIHJ4X2JfMl9vdmVyID0gMSdiMDsKPiCgIKAgoCCgIGNh c2UgKHN0YXRlX21hY2hpbmUpCj4goCCgIKAgoCCgIKAgoCCgIFdCX0lETEUgOgo+IKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIGJlZ2luCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBp ZihyX2NvdW50ZXIgPiAzMidoMDAwMDAwMDApCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCBiZWdpbgo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIG5leHRfc3RhdGUgPSBXQl9SRUFESU5HOwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgZW5kCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgZW5kCj4goCCgIKAgoCCgIKAgoCCg IFdCX1JFQURJTkcgOgo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGJlZ2luCj4goCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBpZihyX2NvdW50ZXIgPT0gMzInaDAwMDAwMDAwKQo+IKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgYmVnaW4KPiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgLy9uZXh0X3N0YXRlID0gV0JfSU5UX0FDSzsKPiCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgbmV4dF9zdGF0ZSA9IFdCX0lETEU7Cj4g oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHJ4X2JfMV9vdmVyID0gMSdi MTsKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGVuZAo+IKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIGVuZAo+IKAgoCCgIKAgoCCgIKAgoCBXQl9XUklUSU5HIDoKPiCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCBiZWdpbgo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWYo REFUQV9SRUFEWSA9PSAxJ2IwKQo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCBuZXh0X3N0YXRlID0gV0JfV19XQUlUOwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGVu ZAo+IKAgoCCgIKAgoCCgIKAgoCBXQl9JTlRfQUNLIDoKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCBiZWdpbgo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWYoaW50X2Fja19kb25l KQo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBuZXh0X3N0YXRlID0g V0JfSURMRTsKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBlbmQKPiCgIKAgoCCgIKAgoCCgIKAg V0JfV19XQUlUIDoKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBiZWdpbgo+IKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgaWYod3JpdGVfZG9uZSkKPiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIGJlZ2luCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIG5leHRfc3RhdGUgPSBXQl9JTlRfQUNLOwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCB0eF9iXzFfb3ZlciA9IDEnYjE7Cj4goCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCBlbmQKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBlbmQKPiCgIKAgoCCgIKAg oCCgIKAgZGVmYXVsdDpiZWdpbgo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgbmV4 dF9zdGF0ZSA9IFdCX0lETEUgOwo+IKAgoCCgIKAgoCCgIGVuZAo+IKAgoCCgIKAgZW5kY2FzZQo+ IGVuZAo+Cj4gLyojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCj4gIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyBzdGF0ZV9tYWNoaW5lIFRJTUlORwo+ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMKPiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjKi8KPgo+IGFsd2F5c0AocG9z ZWRnZSBDTEtfSSkKPiBiZWdpbgo+IKAgoCCgIKAgoCCgIKAgoCBzdGF0ZV9tYWNoaW5lID0gbmV4 dF9zdGF0ZTsKPiBlbmQKPgo+IC8qIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwo+ICMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMgaW50X2Fja19kb25lIENPTlRST0wKPiAjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjCj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyovCj4KPiBh bHdheXNAKHBvc2VkZ2UgQ0xLX0kpCj4gYmVnaW4KPiCgIKAgoCCgIGludF9hY2tfZG9uZSA9IDEn YjA7Cj4goCCgIKAgoCBpZihzdGF0ZV9tYWNoaW5lID09IFdCX0lOVF9BQ0spCj4goCCgIKAgoCBi ZWdpbgo+IKAgoCCgIKAgoCCgIKAgoCBpZihNQ1lDX08gJiYgTUFDS19JKQo+IKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIGludF9hY2tfZG9uZSA9IDEnYjE7Cj4goCCgIKAgoCBlbmQKPiBlbmQKPgo+ IC8qIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwo+ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIHdyaXRlX2RvbmUgQ09OVFJPTAo+ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjCj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyovCj4KPiBhbHdheXNAKHBvc2VkZ2UgQ0xL X0kpCj4gYmVnaW4KPiCgIKAgoCCgIHdyaXRlX2RvbmUgPSAxJ2IwOwo+IKAgoCCgIKAgaWYoc3Rh dGVfbWFjaGluZSA9PSBXQl9XX1dBSVQpCj4goCCgIKAgoCBiZWdpbgo+IKAgoCCgIKAgoCCgIKAg oCBpZihNQ1lDX08gJiYgTUFDS19JKQo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHdyaXRlX2Rv bmUgPSAxJ2IxOwo+IKAgoCCgIKAgZW5kCj4gZW5kCj4KPiBhbHdheXNAKHBvc2VkZ2UgQ0xLX0kp Cj4gYmVnaW4KPiCgIKAgoCCgIKAgoCCgIKAgY2FzZSAobmV4dF9zdGF0ZSkKPiCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCBXQl9JRExFIDogYmVnaW4KPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIGlmKHJfY21uZF9mbGFnKQo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg YmVnaW4KPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcl9jb3VudGVy IDw9IHJfY250X3JlZzsKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg cl93X2FkZHIgPD0gMzAnaDA7Cj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBlbmQK PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBlbmQKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBX Ql9SRUFESU5HIDogYmVnaW4KPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGlmKE1D WUNfTyAmJiBNQUNLX0kpCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBiZWdpbgo+ IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBpZihyX2NvdW50ZXIgPiAw KQo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBiZWdpbgo+IKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHJfY291bnRlciA8PSBy X2NvdW50ZXIgLSAzMidoMTsKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCByX3dfYWRkciA8PSByX3dfYWRkciArIDMwJ2g0Owo+IKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBlbmQKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIGVuZAo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGVuZAo+IKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIFdCX1dSSVRJTkcgOiBiZWdpbgo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgaWYoTUNZQ19PICYmIE1BQ0tfSSkKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIGJlZ2luCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHJfd19h ZGRyIDw9IHJfd19hZGRyICsgMjknaDQ7Cj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIGRhdGFfc2VudCA9IH5kYXRhX3NlbnQ7Cj4goCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCBlbmQKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBlbmQKPiCgIKAgoCCgIKAg oCCgIKAgZW5kY2FzZQo+IC8vIKAgoCCgZW5kCj4gZW5kCj4KPiBhbHdheXNAKG5lZ2VkZ2UgQ0xL X0kpCj4gYmVnaW4KPiCgIKAgoCCgIGNhc2UobmV4dF9zdGF0ZSkKPiCgIKAgoCCgIKAgoCCgIKAg V0JfSURMRTogYmVnaW4KPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBNQURSX09bMzA6MF0gPD0g cl93X2FkZHIgKyB0eF9iMV9vZmZzZXRbMzA6MF07Cj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg TUFEUl9PWzMxXSA8PSAxJ2IwOwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIE1DQUJfTyA8PSAx Owo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGVuZAo+IKAgoCCgIKAgoCCgIKAgoCBXQl9SRUFE SU5HOiBiZWdpbgo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIE1BRFJfT1szMDowXSA8PSByX3df YWRkciArIHR4X2IxX29mZnNldFszMDowXTsKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBNQURS X09bMzFdIDw9IDEnYjA7Cj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgTUNBQl9PIDw9IDE7Cj4g oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgZW5kCj4goCCgIKAgoCCgIKAgoCCgIFdCX1dSSVRJTkc6 IGJlZ2luCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgTUFEUl9PWzMwOjBdIDw9IHJfd19hZGRy ICsgcnhfYjFfb2Zmc2V0WzMwOjBdOwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIE1BRFJfT1sz MV0gPD0gMSdiMTsKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBNQ0FCX08gPD0gMTsKPiCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCBlbmQKPiCgIKAgoCCgIKAgoCCgIKAgV0JfSU5UX0FDSzogYmVn aW4KPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBNQURSX09bMzA6MF0gPD0gYEFDS19DWUNfQURE UjsKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBNQURSX09bMzFdIDw9IDEnYjA7Cj4goCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgTUNBQl9PIDw9IDA7Cj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg ZW5kCj4goCCgIKAgoCCgIKAgoCCgIFdCX1dfV0FJVDogYmVnaW4KPiCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCBNQURSX09bMzA6MF0gPD0gdHhfYjFfb2Zmc2V0WzMwOjBdICsgYERVTU1ZX1JFQURf QUREUjsKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBNQURSX09bMzFdIDw9IDEnYjA7Cj4goCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgTUNBQl9PIDw9IDA7Cj4goCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgZW5kCj4goCCgIKAgoCCgIKAgoCCgIGRlZmF1bHQ6IGJlZ2luCj4goCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgTUFEUl9PWzMxOjBdIDw9IDA7Cj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgTUNB Ql9PIDw9IDE7Cj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgZW5kCj4goCCgIKAgoCBlbmRjYXNl Cj4gZW5kCj4KPiBhbHdheXNAKG5lZ2VkZ2UgQ0xLX0kpCj4gYmVnaW4KPiCgIKAgoCCgIGlmKG5l eHRfc3RhdGUgPT0gV0JfSURMRSkKPiCgIKAgoCCgIGJlZ2luCj4goCCgIKAgoCCgIKAgoCCgIE1T VEJfTyA8PSAxJ2IwOwo+IKAgoCCgIKAgoCCgIKAgoCBNQ1lDX08gPD0gMSdiMDsKPiCgIKAgoCCg IGVuZAo+IKAgoCCgIKAgZWxzZQo+IKAgoCCgIKAgYmVnaW4KPiCgIKAgoCCgIKAgoCCgIKAgTVNU Ql9PIDw9IDEnYjE7Cj4goCCgIKAgoCCgIKAgoCCgIE1DWUNfTyA8PSAxJ2IxOwo+IKAgoCCgIKAg ZW5kCj4gZW5kCj4KPiBhbHdheXNAKHJfY291bnRlcikKPiBiZWdpbgo+IKAgoCCgIKAgcl9jb3Vu dGVyX2VtcHR5ID0gKHJfY291bnRlciA+IDApPyAxJ2IwIDogMSdiMTsKPiBlbmQKPgo+IHB1bHNl X2dlbiByZWFkX2xkX3B1bHNlCj4gKAo+IKAgoCCgIKAgLlRyaWdnZXIgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoChyX2NvdW50ZXJfZW1wdHkpLAo+IKAgoCCgIKAgLlB1bHNlX091dCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAoY291bnRlcl9sb2FkZWQpLAo+IKAgoCCgIKAgLkNsb2NrIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAoQ0xLX0kpCj4gKTsKPgo+IGVuZG1vZHVsZQo+Cj4gVGhl IHNpbXVsYXRpb24gd29ya3Mgb2suLi4gYnV0IHdoZW4gaSBpbXBsZW1lbnQgdGhhdCBvbiBhIFNw YXJ0YW4gSUlJIGkgZ290Cj4gYSB3aXJkIGJlaGF2aW9yIG9uIG15IEZTTS4gRm9yIHNvbWUgcmVh c29uIHRoZSBzdGF0ZSBrZWVwcyBqdW1waW5nIGZyb20KPiBJRExFIHRvIFJFQURJTkcsIGFuZCBm cm9tIFJFQURJTkcgdG8gSURMRSwgYnV0IHRoZSByX2NvdW50ZXIgaXMgbm90Cj4gbW92aW5nLi4u IHNvIGlmIGkgd3JpdGUgNSBvbiByX2NvdW50ZXIuLiBpdCBzdGF5IG9uIDUgYnV0IHRoZSBzdGF0 ZXMga2VlcAo+IG1vdmluZy4gQW55IGlkZWEgb2Ygd2hhdCBjb3VsZCBjb3VzZSB0aGF0PyBBcyBp IGRvIG5vdCBoYXZlIGNoaXBzY29wZSBpIGFtCj4gdXNpbmcgNCBzZXZlbiBzZWcuIGRpc3BsYXkg YW5kIDMgbGVkcyB0byBkZWJ1Zy4gT24gdGhlIGRpc3BsYXkgaSBhbSBsb29raW5nCj4gdG8gdGhl IGNvdW50ZXIsIGFuZCBhdCB0aGUgbGVkcyBvbiB0aGUgZmlyc3QgMyBlbGVtZW50cyBvZiB0aGUg bmV4dF9zdGF0ZQo+IGFycmF5LCBzbyBpIGNhbiBzZWUgaWYgaXQgc3RheSBhdCBJRExFIG9yIFJF QURJTkcsIGJ1dCB0aGUgcmVzdWx0IGlzIHRoYXQgaQo+IGNhbiBzZWUgdGhhdCB0aGUgdGhlIGZp cnN0IGFuZCB0aGlyZCBsZWQgYXJlIE9OLCBidXQgbm90IHdpaCBmdWxsIHBvd2VyLi4uCj4gYXMg aXQgd2FzIGJlaW5nIGRyaXZlbiBieSBhIFBXTSBzaWduYWwsIHNvIGkgY291bGQgc3Vwb3NlIHRo YXQgdGhlIEZTTQo+IGtlZXBzIGp1bXBpbmcgYmV0d2VlbiBib3RoIHN0YXRlcy4uLgo+Cj4gQW55 IGhlbHAgcGxlYXNlPwo+Cj4gSSB3aWxsIG5vdCBnaXZlIGFueSBmdXJ0aGVyIGRldGFpbCBub3cg YmVjb3VzZSB0aGV5IGFyZSBpcnJlbGV2YW50IGFzIGFsbAo+IHRlaCByZXN0IGxvb2tzIG9rLCBh bmQgaSBjYW4gc2VlIHRoZSByX2NvdW50ZXIgdmFsdWUuLi4KPgo+IFRoYW5rIHlvdSEgoCCgIKAg oAo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIKAgoCCgIKAKPiBQ b3N0ZWQgdGhyb3VnaGh0dHA6Ly93d3cuRlBHQVJlbGF0ZWQuY29tCgpZb3UgbmVlZCB0byBsZWFy biBzb21lIG9mIHRoZSBudWFuY2VzIG9mIFZlcmlsb2cuICBJIGFsc28gZG9uJ3QKYmVsaWV2ZSB0 aGlzCnNpbXVsYXRlcyBwcm9wZXJseS4KCkZpcnN0LCB0aGUgY2FzZSBzdGF0ZW1lbnQgdGhhdCBi ZWdpbnMKICAgIGFsd2F5c0Aoc3RhdGVfbWFjaGluZSBvciByX2NvdW50ZXIgb3IgdHhfYl8xX2lu dCBvciB0eF9iXzJfaW50IG9yCiAgICAgICAgd3JpdGVfZG9uZSBvciBpbnRfYWNrX2RvbmUgb3Ig REFUQV9SRUFEWSkKICAgICAgICBiZWdpbgogICAgICAgIHR4X2JfMV9vdmVyID0gMSdiMDsKICAg ICAgICB0eF9iXzJfb3ZlciA9IDEnYjA7CiAgICAgICAgcnhfYl8xX292ZXIgPSAxJ2IwOwogICAg ICAgIHJ4X2JfMl9vdmVyID0gMSdiMDsKICAgICAgICBjYXNlIChzdGF0ZV9tYWNoaW5lKQogICAg ICAgIFdCX0lETEUgOgogICAgICAgICAgICBiZWdpbgogICAgICAgICAgICBpZihyX2NvdW50ZXIg PiAzMidoMDAwMDAwMDApCiAgICAgICAgICAgICAgICBiZWdpbgogICAgICAgICAgICAgICAgbmV4 dF9zdGF0ZSA9IFdCX1JFQURJTkc7CiAgICAgICAgICAgICAgICBlbmQKICAgICAgICAgICAgZW5k CndpbGwgaW5mZXIgbGF0Y2hlcy4gIFRoaXMgaXMgdXN1YWxseSBiYWQuICBMb29rIGluIHRoZSBz eW50aGVzaXMKcmVwb3J0ICguc3lyKSB0byBzZWUKaWYgbGF0Y2hlcyBhcmUgYmVpbmcgaW5mZXJy ZWQuICAgV2h5IGlzIHRoaXMgaGFwcGVuaW5nPyBXaGF0IGxvZ2ljCmRvZXMgdGhlIGFib3ZlCmZy YWdtZW50IG5lZWQgaWYgcl9jb3VudGVyID09IDA/CgpTZWNvbmQsIGFzayB5b3Vyc2VsZiwgImhv dyBkb2VzIHRoZSBzdGF0ZSBtYWNoaW5lIGV2ZXIgZ2V0IHRvCldCX1dSSVRJTkc/CgpZb3UgbmVl ZCB0byBjb21wbGV0ZWx5IHJldmlldyB5b3VyIGNvZGUgYW5kIHRoaW5rIGFib3V0IHdoYXQgaC93 IGl0CndpbGwgY3JlYXRlLgoKR29vZCBsdWNrIQoKSm9obiBQcm92aWRlbnphCgo=Article: 151547
A core is going to take up more FPGA resources than the embedded TEMAC in the FX12. If you are limited on FPGA resources, why not use the FX12 TEMAC? The Avnet Design Resource Center has examples of working with the TEMAC with the PPC. http://www.em.avnet.com/virtex4mini --> Support Files & Downloads Bryan On Apr 17, 12:49=A0am, "bhatti" <bhatti.uzair@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com> wrote: > Hi > we have an 10/100Mbps ethernet core (from Opencore) and we have run this > core successfully on Spartan 3E kit. Now we need to shift to another > platform i.e. Virtex-4 FX12 mini module (due to small size it offers). > > Is there a way to run this ethernet core on FX12 mini module? although th= is > module has a hard Tri-Mode EMAC integrated into the Virtex-4 FPGA along > with PHY. > > Thanks =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.comArticle: 151548
It looks ok Thomas, haven't seen the ISA. The main reason I dropped the add= instruction (originally there was no minus), was that minus is more primit= ive, in that construction of minus from plus requires xor. In the context o= f threaded code compilation the MI instruction can be used just once. The main features are a 3 in 1 compression mode, so that 3 instructions may= be placed in 16 bits, for a high code density. No opcode is needed to pref= ix a subroutine jump. There are 5 registers and a borrow flag. Pre/post -/+= is applied to all indirect memory access. A hardware loading of RAM via an= SPI EEPROM at boot time is included, via a hardware SPI interface. A simpl= e interrupt method can be used. Code size is 48K * 16 bit when using 16 bit= generic word size and the 3 in 1 compression. Data size is up to 64K * 16 = bit, as addressable memory is 128KB using a 16 bit generic. Video DMA is in= cluded for a sub VGA resolution of 256*256 in 8 colours. A 16 bit delta sig= ma DAC is included. 2 * 8 bit ports (one in, one out) are included. With no= cache a 0.2 MIPS/MB processing from RAM is standard (including operand acc= ess). BSD license. For an further explanation of a preference for MInus, the Z80 explains best= with a DJNZ, explaining count down to borrow is an excellent looping mecha= nism. The saving of a few cells is necessary considering the size of the UF= M-SPI mega function, and the 1270 LE MAX II kit I am targeting. It's all ve= ry logical. After all is considered, the 16 bit memory model with auto +/- saves a lot = of code is a stack based design. Think of all those extra cycles adding or = subtracting 1 which are hidden in Nibz, and the poultry complexity of perfo= rming an add is tiny. The subroutine branch saving alone is major significa= nt, considering factorization into small subroutines is where code density = comes from. Cheers JackoArticle: 151549
On Apr 18, 7:21=A0am, Bryan <bryan.fletc...@avnet.com> wrote:
>
> http://www.em.avnet.com/virtex4mini--> Support Files & Downloads
>
> Bryan
>
That link goes to:
A generic error has occurred.
The store is currently experiencing problems. Try again later.
Cheers,
RK
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