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

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

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

Custom Search

Messages from 151525

Article: 151525
Subject: same RTL on two same boards giving different behaviour
From: "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com>
Date: Sun, 17 Apr 2011 13:06:43 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 151526
Subject: Re: same RTL on two same boards giving different behaviour
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Sun, 17 Apr 2011 11:36:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: NibzX7 processor
From: rickman <gnuarm@gmail.com>
Date: Sun, 17 Apr 2011 15:00:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 151528
Subject: Re: NibzX7 processor
From: jacko <jackokring@gmail.com>
Date: Sun, 17 Apr 2011 16:03:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Jacko

Article: 151529
Subject: [MODELSIM] How to add signals to wave which is a child of the module
From: John Smith <redditorred@gmail.com>
Date: Sun, 17 Apr 2011 18:40:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Help with Verilog Code
From: "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sun, 17 Apr 2011 21:57:31 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: Oscilloscope recommendations Ghz range?
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Mon, 18 Apr 2011 09:37:24 +0200
Links: << >>  << T >>  << A >>

"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
Subject: Re: [MODELSIM] How to add signals to wave which is a child of the module being tested?
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 18 Apr 2011 03:25:49 -0500
Links: << >>  << T >>  << A >>
>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.com

Article: 151533
Subject: Re: same RTL on two same boards giving different behaviour
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 18 Apr 2011 03:28:19 -0500
Links: << >>  << T >>  << A >>
>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.com

Article: 151534
Subject: Re: Oscilloscope recommendations Ghz range?
From: Symon <symon_brewer@hotmail.com>
Date: Mon, 18 Apr 2011 10:36:39 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: NibzX7 processor
From: Thomas Entner <thomas.entner99@gmail.com>
Date: Mon, 18 Apr 2011 03:08:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.com

Article: 151536
Subject: Re: Oscilloscope recommendations Ghz range?
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Mon, 18 Apr 2011 12:09:29 +0200
Links: << >>  << T >>  << A >>
"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
Subject: Re: NibzX7 processor
From: Thomas Entner <thomas.entner99@gmail.com>
Date: Mon, 18 Apr 2011 03:09:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Oscilloscope recommendations Ghz range?
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Mon, 18 Apr 2011 05:32:04 -0500
Links: << >>  << T >>  << A >>
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

Article: 151539
Subject: Re: Help with Verilog Code
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Mon, 18 Apr 2011 05:34:26 -0500
Links: << >>  << T >>  << A >>
You really need to learn how to write verilog code correctly first. 

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 151540
Subject: Re: Oscilloscope recommendations Ghz range?
From: colin <colin_toogood@yahoo.com>
Date: Mon, 18 Apr 2011 03:45:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Colin

Article: 151541
Subject: Re: Oscilloscope recommendations Ghz range?
From: Symon <symon_brewer@hotmail.com>
Date: Mon, 18 Apr 2011 11:51:11 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: Oscilloscope recommendations Ghz range?
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Mon, 18 Apr 2011 13:12:15 +0200
Links: << >>  << T >>  << A >>

"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
Subject: Re: Oscilloscope recommendations Ghz range?
From: colin <colin_toogood@yahoo.com>
Date: Mon, 18 Apr 2011 06:00:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 :)

Colin

Article: 151544
Subject: Re: Oscilloscope recommendations Ghz range?
From: nico@puntnl.niks (Nico Coesel)
Date: Mon, 18 Apr 2011 13:11:10 GMT
Links: << >>  << T >>  << A >>
"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
Subject: F.S. Xilinx ML403 evaluation board
From: mstricker <mstricker@embarqmail.com>
Date: Mon, 18 Apr 2011 06:14:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 looking

Article: 151546
Subject: Re: Help with Verilog Code
From: johnp <jprovidenza@yahoo.com>
Date: Mon, 18 Apr 2011 07:05:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: ethernet core on FX12 mini module
From: Bryan <bryan.fletcher@avnet.com>
Date: Mon, 18 Apr 2011 07:21:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.com


Article: 151548
Subject: Re: NibzX7 processor
From: jacko <jackokring@gmail.com>
Date: Mon, 18 Apr 2011 09:16:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Jacko

Article: 151549
Subject: Re: ethernet core on FX12 mini module
From: NeedCleverHandle <d_s_klein@yahoo.com>
Date: Mon, 18 Apr 2011 13:14:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search