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 153200

Article: 153200
Subject: Re: voltage drop on STRATIX FPGA supply planes
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Fri, 06 Jan 2012 08:51:24 -0800
Links: << >>  << T >>  << A >>
On Fri, 6 Jan 2012 01:55:03 -0800 (PST), "colin_toogood@yahoo.com"
<colin_toogood@yahoo.com> wrote:

>Guys
>
>I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power
>plane. It is showing a 30mV voltage drop across the BGA itself, let
>alone getting the power to the BGA which is dropping another 50mV.
>
>Surely the 30mV cannot be true as there is a power plane in the BGA
>package itself.
>
>Historically I would look at the size of the plane and assume that
>everything is fine and I can't help wondering whether this worst case
>analysis is a bit pointless.
>
>Any opinions?
>
>BTW I'm already just beyond the PCB thickness I'm allowed so I can't
>just use thicker copper.
>
>Colin
>
>PS. sorry about using Google, I'm sitting in the UK behind a firewall
>controlled by an Indian call centre.

How much current are you expecting in the core?

What do mean by "30mV voltage drop across the BGA itself" ? Does that
mean PCB plane drop, or rather BGA balls to chip internal voltage?

The chip vendors should give us one remote-sense feedback/measurement
ball.

John



Article: 153201
Subject: Re: voltage drop on STRATIX FPGA supply planes
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Fri, 06 Jan 2012 08:56:03 -0800
Links: << >>  << T >>  << A >>
On 06 Jan 2012 15:07:31 GMT, Allan Herriman
<allanherriman@hotmail.com> wrote:

>On Fri, 06 Jan 2012 13:53:05 +0000, Allan Herriman wrote:
>
>> On Fri, 06 Jan 2012 01:55:03 -0800, colin_toogood@yahoo.com wrote:
>> 
>>> Guys
>>> 
>>> I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power
>>> plane. It is showing a 30mV voltage drop across the BGA itself, let
>>> alone getting the power to the BGA which is dropping another 50mV.
>>> 
>>> Surely the 30mV cannot be true as there is a power plane in the BGA
>>> package itself.
>>> 
>>> Historically I would look at the size of the plane and assume that
>>> everything is fine and I can't help wondering whether this worst case
>>> analysis is a bit pointless.
>>> 
>>> Any opinions?
>>> 
>>> BTW I'm already just beyond the PCB thickness I'm allowed so I can't
>>> just use thicker copper.
>> 
>> 
>> I've had this issue in recent designs too.  Currents are higher,
>> voltages are lower (1.0, 0.9V, etc), supply tolerances are tighter (3%
>> instead of 5% now for some parts) but copper doesn't seem conduct any
>> better :(
>> 
>> About the only thing that's improving is the DC/DC converter; some parts
>> have a reference precision better than 1% now.  Transient response is
>> also better due to faster switching frequencies and cheap, large, low
>> ESR caps.
>> 
>> 
>> The Cu in the BGA is thin.  I don't know its sheet resistance, but it's
>> probably greater than the (roughly) 1mohm / square of the inner layers
>> of your PCB.  At 20 or 30 amperes, you don't need many squares to get a
>> voltage drop that puts you outside the supply voltage tolerance of the
>> FPGA.
>> 
>> In my last "high power" FPGA design, we ended up with a plane on an
>> inner (1/2 oz) layer in parallel with a fill on an outer (1oz) layer for
>> the core supply.  The layout guy hated doing it, but it gave adequate
>> results.
>> 
>> It might also be possible to use smaller vias in your BGA fanout to
>> reduce the "swiss cheese" effect on your planes, but I haven't tried
>> that in an actual design.
>> 
>> I've noticed that some PC motherboard manufacturers are advertising 2oz
>> copper as a feature, so it's not just FPGA folk that are feeling the
>> pain.
>
>
>Another thing I've been doing is to boost the nominal voltage slightly.


I do that, namely go 50 mV or so high out of my switchers,
anticipating copper losses.

I think the tight voltage specs on these FPGAs is part of the overall
speed budget. If you're not pushing the clock rate/timing/temperature
margins, it's not as critical. I also like to power-supply margin test
working units, just to see how much wiggle room we have. Usually it's
a lot.

John



Article: 153202
Subject: Re: Handling overflow in a self-repeating frequency counter
From: Tim Wescott <tim@seemywebsite.com>
Date: Fri, 06 Jan 2012 12:18:50 -0600
Links: << >>  << T >>  << A >>
On Fri, 06 Jan 2012 03:18:38 +0000, glen herrmannsfeldt wrote:

> Philip Pemberton <philpem@philpem.me.uk> wrote:
> 
>> I'm currently working on the HDL code for an open-source project which
>> images 'strange and unusual' magnetic media (mainly floppy discs but
>> also MFM and RLL hard disc drives).
> 
>> To do this, I measure the time between incoming pulses on the RD_DATA
>> line. One pulse indicates a magnetic transition. The time between a
>> given pair of pulses encodes (in a roundabout way) a data bit. This is
>> a gross oversimplification, but serves the purpose for this
>> explanation.
> 
>> After measuring the time between two pulses, it re-arms and measures
>> between the second pulse and the one following it. Rinse, repeat.
> 
>> The captured timing values are stored in an on-FPGA FIFO buffer, then
>> passed onto an off-chip Cypress 100MHz 512K*8bit high speed static RAM
>> (this thing needs A LOT of storage). The period counter's reference
>> clock is 100MHz. 10 nanoseconds per count. The most significant bit is
>> reserved for a 'flag' bit (it's used by other parts of the design),
>> leaving a range of 0 to 127 for the counter.
> 
> The bit rate for floppies is 125000b/s at the low end, and, as far as I
> know, 1000000b/s at the high end.  To decode FM or MFM data, you don't
> need a hugh amount of resolution.  There are only two different times
> between transitions, at least ideally.
> 
> The GCR code used by older Apple formats has more different times, but
> not all that many, and the bit rate is on the low side.
> 
> To write a floppy from data, you need to consider precompensation, which
> needs a little finer timing.  Note that writing a floppy from your data
> stream, you will also need to consider precompensation.
> 
> Anyway, my suggestion is to use a slower clock.  Then it should only
> overflow at splice points, or other places where the data doesn't
> matter.
> 
>> The problem is, a lot of the timing values are about 800 counts long.
>> To work around this, I implemented logic to store a 'special' value in
>> the stream if the counter overflows from 127 to 0. This value is "8'd0"
>> -- 8 bits, all zeroes.
> 
> The design of codes that can be uniquely decoded is well known. One
> answer is to store one more than the overflow value. That is, a 128
> count should be X'0001', so X'00' always means overflow, and never data.
>  X'007f' then will be 254, and X'000001' will be 255.
> 
> The logic is a little more complicated, but shouldn't be hard to fit
> into an FPGA.
> 
> -- glen

If you want the data to fit neatly into seven bits, give your counter a 
period of 127, and assign X'00' to overflow, with X'01' through X'7f' 
denoting a bit hit at that count.  That'll insure unique data, without 
blowing out your bit-count budget.

You'll complicate the decoding a bit, but that's an easy task for a 
computer to carry out.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 153203
Subject: Re: voltage drop on STRATIX FPGA supply planes
From: Robert Macy <robert.a.macy@gmail.com>
Date: Fri, 6 Jan 2012 10:28:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 6, 6:53=A0am, Allan Herriman <allanherri...@hotmail.com> wrote:
> On Fri, 06 Jan 2012 01:55:03 -0800, colin_toog...@yahoo.com wrote:
> > Guys
>
> > I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power
> > plane. It is showing a 30mV voltage drop across the BGA itself, let
> > alone getting the power to the BGA which is dropping another 50mV.
>
> > Surely the 30mV cannot be true as there is a power plane in the BGA
> > package itself.
>
> > Historically I would look at the size of the plane and assume that
> > everything is fine and I can't help wondering whether this worst case
> > analysis is a bit pointless.
>
> > Any opinions?
>
> > BTW I'm already just beyond the PCB thickness I'm allowed so I can't
> > just use thicker copper.
>
> I've had this issue in recent designs too. =A0Currents are higher, voltag=
es
> are lower (1.0, 0.9V, etc), supply tolerances are tighter (3% instead of
> 5% now for some parts) but copper doesn't seem conduct any better :(
>
> About the only thing that's improving is the DC/DC converter; some parts
> have a reference precision better than 1% now. =A0Transient response is
> also better due to faster switching frequencies and cheap, large, low ESR
> caps.
>
> The Cu in the BGA is thin. =A0I don't know its sheet resistance, but it's
> probably greater than the (roughly) 1mohm / square of the inner layers of
> your PCB. =A0At 20 or 30 amperes, you don't need many squares to get a
> voltage drop that puts you outside the supply voltage tolerance of the
> FPGA.
>
> In my last "high power" FPGA design, we ended up with a plane on an inner
> (1/2 oz) layer in parallel with a fill on an outer (1oz) layer for the
> core supply. =A0The layout guy hated doing it, but it gave adequate resul=
ts.
>
> It might also be possible to use smaller vias in your BGA fanout to
> reduce the "swiss cheese" effect on your planes, but I haven't tried that
> in an actual design.
>
> I've noticed that some PC motherboard manufacturers are advertising 2oz
> copper as a feature, so it's not just FPGA folk that are feeling the pain=
.
>
> Regards,
> Allan

If you have an old version .dxf file [with scale] of your PCB plane
and identify current magnitudes and injection points, tell me the two
cutout diameters to test; I could compare the effect of the 'swiss
cheese' on the voltage drop across the plane. Actually do 3D voltage
plots showing NO HOLES, Small Holes, Large Holes, and Delta Voltage
comparisons.

I created a PCB Layout Tool that quantifies the Ground Plane Noise
distributed across a PCB caused by currents from digital logic.

Provide an email address that accepts .zip and I can send small
example images of results in .zip attachment. approx 72kB

[The purpose for creating the tool was to confirm parts placement and
efficacy of plane cuts to keep GND noise below 1/4 LSB of the 24 bit
ADC on the same PCB as the microcontroller. I simply got tired of
'shooting from the hip', worrying if the cut(s) is enough, and
answering questions with, "In my opinion,..." Plus, wanted this PCB
layout 'right' the first time.]


Article: 153204
Subject: Re: Handling overflow in a self-repeating frequency counter
From: Philip Pemberton <philpem@philpem.me.uk>
Date: 06 Jan 2012 20:49:01 GMT
Links: << >>  << T >>  << A >>
On Fri, 06 Jan 2012 12:18:50 -0600, Tim Wescott wrote:

> If you want the data to fit neatly into seven bits, give your counter a
> period of 127, and assign X'00' to overflow, with X'01' through X'7f'
> denoting a bit hit at that count.  That'll insure unique data, without
> blowing out your bit-count budget.
> 
> You'll complicate the decoding a bit, but that's an easy task for a
> computer to carry out.

That's more or less what I'm doing now.

The problem is, there's a race condition -- if there's an overflow at the 
same time as an incoming data pulse, then the overflow is stored, but the 
transition is ignored. In the example you gave, that's when the count is 
*exactly* 127, or a modulo thereof.

What I need to do is eliminate this race condition...


Here's my code --

module DiscReader(CLOCK, CLKEN, RUN, FD_RDDATA_IN, FD_INDEX_IN, RESET, 
DATA, WRITE);
	parameter BITS = 8;		// data bits

	input					
CLOCK;				// counter clock
	input					
CLKEN;				// counter clock enable
	input					
RUN;				// enable input -- 1 to acquire
	input					FD_RDDATA_IN;		// 
read data
	input					FD_INDEX_IN;		// 
index pulse
	input					
RESET;				// asynchronous reset

	output reg	[BITS-1:0]	DATA;				// 
data output to RAM
	output reg				
WRITE;				// write output to RAM


/////////////////////////////////////////////////////////////////////////////
// Input synchronisation
	wire FD_RDDATA_IN_tcysync, FD_INDEX_IN_tcysync;
	Flag_Delay1tcy_OneCycle _fcd_rddata	(CLOCK,	FD_RDDATA_IN,	
FD_RDDATA_IN_tcysync);
	Flag_Delay1tcy_OneCycle _fcd_index	(CLOCK,	FD_INDEX_IN,	
FD_INDEX_IN_tcysync);

/////////////////////////////////////////////////////////////////////////////
// Free-running counter for frequency measurement
	reg [BITS-2:0] counter, last_count;
	always @(posedge CLOCK) begin
		if (RESET) begin
			// reset active -- clear counter
			counter <= 'd0;
		end else if (CLKEN) begin
			// otherwise increment
			counter <= counter + 'd1;
		end
	end

/////////////////////////////////////////////////////////////////////////////
// Frequency counter

	// current counter value
	wire [BITS-2:0] cur_count = (last_count <= counter) ?
		counter - last_count :					// 
last count <= counter
		('b1 << BITS) - last_count + counter;	// last count >  
counter

	always @(posedge CLOCK) begin
		// don't write to memory!
		WRITE <= 1'b0;

		if (RESET) begin
			// reset active -- clear last-count
			last_count <= 'd0;
		end else begin
			if (FD_RDDATA_IN_tcysync | FD_INDEX_IN_tcysync | 
(cur_count == (('d1 << BITS-1)-1))) begin
				// Index hit, flux transition or overflow
				DATA <= {FD_INDEX_IN_tcysync ? 1'b1 : 
1'b0, cur_count};

				// write to memory
				WRITE <= 1'b1;

				// Update 'previous count value' register
				last_count <= counter;
			end
		end
	end

endmodule


module Flag_Delay1tcy_OneCycle(clk, in, out);
	input		clk, in;
	output	out;

	reg[1:0] in_Delayed;
	always @(posedge clk) in_Delayed <= {in_Delayed[0], in};
	assign out = (in_Delayed[0] && !in_Delayed[1]);
endmodule


// Testbench -- provokes race condition in DiscReader module

// 5ns time reference with 1ns precision
`timescale 1 ns / 1 ns

module DiscReaderTB;
	reg clock, run, rddata, index, reset;
	wire clock_enable = 1'b1;

	parameter N = 8;

	wire [N-1:0] data_r;
	wire ram_write;

	// instantiate the disc reader
	DiscReader U0 (
		.CLOCK			(clock),
		.CLKEN			(clock_enable),
		.RUN			(run),
		.FD_RDDATA_IN	(rddata),
		.FD_INDEX_IN	(index),
		.RESET			(reset),

		.DATA			(data_r),
		.WRITE			(ram_write)
	);

	// set initial state
	initial begin
		clock = 0;
		run = 0;
		rddata = 0;
		index = 0;
		reset = 0;
	end

	// generate a 100MHz clock
	always
		#1 clock = !clock;

	// set up for variable dumping
	initial  begin
		$dumpfile ("counter.vcd"); 
		$dumpvars; 
	end

	integer k;
	// main loop
	initial begin
		#10
			reset = 1;
		#10
			reset = 0;
			run = 1;

		for (k=0; k<=16; k=k+1) begin
				rddata = 1;
			#2
				rddata = 0;
			#252
				;
		end

		#1000 $finish;
	end

endmodule

Thanks.
-- 
Phil.
philpem@philpem.me.uk
http://www.philpem.me.uk/

Article: 153205
Subject: Re: Handling overflow in a self-repeating frequency counter
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 6 Jan 2012 22:13:37 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tim Wescott <tim@seemywebsite.com> wrote:

(snip)
>>> The problem is, a lot of the timing values are about 800 counts long.
>>> To work around this, I implemented logic to store a 'special' value in
>>> the stream if the counter overflows from 127 to 0. This value is "8'd0"
>>> -- 8 bits, all zeroes.
 
>> The design of codes that can be uniquely decoded is well known. One
>> answer is to store one more than the overflow value. That is, a 128
>> count should be X'0001', so X'00' always means overflow, and never data.
>>  X'007f' then will be 254, and X'000001' will be 255.
 
>> The logic is a little more complicated, but shouldn't be hard to fit
>> into an FPGA.

> If you want the data to fit neatly into seven bits, give your counter a 
> period of 127, and assign X'00' to overflow, with X'01' through X'7f' 
> denoting a bit hit at that count.  That'll insure unique data, without 
> blowing out your bit-count budget.

That is what I was thinking, but probably didn't get quite right.

> You'll complicate the decoding a bit, but that's an easy task for a 
> computer to carry out.

Well, easy for a computer, slightly harder to write as a state
machine in verilog, but not that much harder.

-- glen

Article: 153206
Subject: Re: Handling overflow in a self-repeating frequency counter
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 6 Jan 2012 22:46:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
Philip Pemberton <philpem@philpem.me.uk> wrote:
> On Fri, 06 Jan 2012 12:18:50 -0600, Tim Wescott wrote:

>> If you want the data to fit neatly into seven bits, give your counter a
>> period of 127, and assign X'00' to overflow, with X'01' through X'7f'
>> denoting a bit hit at that count.  That'll insure unique data, without
>> blowing out your bit-count budget.
 
>> You'll complicate the decoding a bit, but that's an easy task for a
>> computer to carry out.

> That's more or less what I'm doing now.

> The problem is, there's a race condition -- if there's an overflow at the 
> same time as an incoming data pulse, then the overflow is stored, but the 
> transition is ignored. In the example you gave, that's when the count is 
> *exactly* 127, or a modulo thereof.

> What I need to do is eliminate this race condition...

No, it is worse than a race condition, you have one state that
has two meanings.  

OK, the easy way is to do it modulo 64, and use the 64 value to mean 64,
and 0 to mean 0.  (It is easier to write modulo 64 than 127.)

For 5.25in FM, the data rate is 125000b/s, the transitions are either
at 8us or 4us, so there will be a lot of 80s.  Not so good.

For 5.25in MFM, the data rate is 250000b/s, there is no clock pulse
if either the cell before or after has a data pulse.  I believe that
means either 4us or 6us, except for an address mark where it
would be 8us.  (I haven't thought about this for a while.
Find a reference to the IBM standard.)

OK, do it modulo 127 with 127 as the overflow code which allows
for a zero code to mean zero.  (Most likely only after a 127.)
It isn't that hard to test for 127, and you have plenty of
time to do it.

-- glen

Article: 153207
Subject: Re: Trying to select a development board, can somebody help me make
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Fri, 6 Jan 2012 16:22:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On 4 Jan., 19:52, chthon <jurgen.defu...@gmail.com> wrote:
> Hello,
>
> I am trying to decide what board to order for a project I want to do betw=
een April and June in school,
> I have currently staked out the following boards, based upon the features=
 I need and the price.
>
> Digilent =A0 | Atlys =A0 =A0 =A0 =A0 =A0|
> Xilinx     | 3A Starter kit |

> However, also delivery time and ease of ordering are somewhat necessary, =
and three of the five boards come from the US, while 2 come from the UK, an=
d I live in Belgium.

Atlys boards are in stock at trenz electronic in Germany:
http://shop.trenz-electronic.de/catalog/product_info.php?cPath=3D1_114_119&=
products_id=3D829&language=3Den

and so is the 3A starter kit:
http://shop.trenz-electronic.de/catalog/product_info.php?cPath=3D1_47&produ=
cts_id=3D130&language=3Den

Regards,

Kolja

Article: 153208
Subject: Re: Handling overflow in a self-repeating frequency counter
From: Steven Hirsch <snhirsch@gmail.com>
Date: Fri, 06 Jan 2012 21:30:44 -0500
Links: << >>  << T >>  << A >>
On 01/05/2012 10:18 PM, glen herrmannsfeldt wrote:

> The bit rate for floppies is 125000b/s at the low end, and, as far as
> I know, 1000000b/s at the high end.  To decode FM or MFM data, you
> don't need a hugh amount of resolution.  There are only two different
> times between transitions, at least ideally.
>
> The GCR code used by older Apple formats has more different times, but
> not all that many, and the bit rate is on the low side.
>
> To write a floppy from data, you need to consider precompensation,
> which needs a little finer timing.  Note that writing a floppy from
> your data stream, you will also need to consider precompensation.
>
> Anyway, my suggestion is to use a slower clock.  Then it should only
> overflow at splice points, or other places where the data doesn't
> matter.

What Philip failed to mention was that the product in question is also 
intended to read data streams from MFM hard drives.  A slower clock may not be 
an option.

Article: 153209
Subject: Re: Handling overflow in a self-repeating frequency counter
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 7 Jan 2012 04:43:22 +0000 (UTC)
Links: << >>  << T >>  << A >>
Steven Hirsch <snhirsch@gmail.com> wrote:

(snip, I wrote)
>> To write a floppy from data, you need to consider precompensation,
>> which needs a little finer timing.  Note that writing a floppy from
>> your data stream, you will also need to consider precompensation.

>> Anyway, my suggestion is to use a slower clock.  Then it should only
>> overflow at splice points, or other places where the data doesn't
>> matter.

> What Philip failed to mention was that the product in question is also 
> intended to read data streams from MFM hard drives.  A slower clock may not be 
> an option.

I was assuming that you knew which type of drive you were working
with and could select accordingly.  

Interestingly, though, the IBM PC/AT disk controller uses a 24MHz
crystal for the floppy drive, and, if I remember right, 10MHz 
for the MFM hard drive.

-- glen

Article: 153210
Subject: Re: Handling overflow in a self-repeating frequency counter
From: Tim Wescott <tim@seemywebsite.please>
Date: Sat, 07 Jan 2012 02:14:14 -0600
Links: << >>  << T >>  << A >>
On Fri, 06 Jan 2012 20:49:01 +0000, Philip Pemberton wrote:

> On Fri, 06 Jan 2012 12:18:50 -0600, Tim Wescott wrote:
> 
>> If you want the data to fit neatly into seven bits, give your counter a
>> period of 127, and assign X'00' to overflow, with X'01' through X'7f'
>> denoting a bit hit at that count.  That'll insure unique data, without
>> blowing out your bit-count budget.
>> 
>> You'll complicate the decoding a bit, but that's an easy task for a
>> computer to carry out.
> 
> That's more or less what I'm doing now.
> 
> The problem is, there's a race condition -- if there's an overflow at
> the same time as an incoming data pulse, then the overflow is stored,
> but the transition is ignored. In the example you gave, that's when the
> count is *exactly* 127, or a modulo thereof.
> 
> What I need to do is eliminate this race condition...
> 
(lots of headache-inducing code snipped)

It shouldn't.  A number between 1 and 127 means that you got an event at 
that time.  A zero means that your counter went from 127 to _1_ (because 
0 is forbidden).

// Note that my Verilog is very rusty: hopefully you'll get the idea

// This should cause a count between 1 and 127 to be emitted when an
// event occurs, and a 'count' of 0 to be emitted _only_ when an
// overflow occurs.
if (event)
  begin
    out <= count;
    emit <= 1;
  end
else if (count == 127)
  begin
    out <= 0;
    emit <= 1;
  end

// The counter update is independent to the above:
if (count == 127)
  count <= 1;
else
  count <= count + 1;

Like Glen said, the above is somewhat logic-intensive because you're 
counting modulo 127 -- but it can be done.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Article: 153211
Subject: Re: voltage drop on STRATIX FPGA supply planes
From: John Adair <g1@enterpoint.co.uk>
Date: Sun, 8 Jan 2012 07:52:16 -0800 (PST)
Links: << >>  << T >>  << A >>
Colin

I'm not surprised at the numbers you are quoting. Personnally I would
be more worried by the dynamic current variation and the effects that
that the resistance and the parasitic inductance can have. If your
decoupling isn't good enough ,and your power plane forms part of that,
the effect of getting it wrong is far harder to debug than a static
voltage issue.

Going back to the static losses using parallel planes is a good option
as mentioned elsewhere. You can also go for heavier weights of
copperin your power planes but that tends to restrict you track and
gap you can use. This also related to the abilities of the
manufacturer of your PCB and sometimes the price you pay for a PCB.
There are also speciality PCB techniques like bonding busbars to the
PCB to reduce the resistive loss but usually it's better to use a
point of load technique and localise the high current areas. You can
see examples of that technique in our extrene Merrick family of boards
which are aimed at the HPC marketplace. Our recently annouced Merrick3
http://enterpoint.co.uk/products/asic-development-high-performance-computin=
g/merrick-3/
uses 6 12A circuits just in PCIe card format for the core voltage.
Internal distribution is by 12V rail in this case. Our new revision of
our Merrick1 board will take this further and there are 20 POL
regulators just for the core voltage.

One easy thing to do is to set you power supply on the higher end of
the input specification at light load. Tolerance of your power supply
is important if you use this method. Then even after losses hopefully
your FPGA die is still receiving voltage within spec.

Many FPGAs will still operate out of spec although may not meet timing
spec. Sometimes this can be used to solve a particular power issue but
use with care.

John Adair
Enterpoint Ltd. - Home of FPGA HPC solutions.

On Jan 6, 9:55=A0am, "colin_toog...@yahoo.com" <colin_toog...@yahoo.com>
wrote:
> Guys
>
> I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power
> plane. It is showing a 30mV voltage drop across the BGA itself, let
> alone getting the power to the BGA which is dropping another 50mV.
>
> Surely the 30mV cannot be true as there is a power plane in the BGA
> package itself.
>
> Historically I would look at the size of the plane and assume that
> everything is fine and I can't help wondering whether this worst case
> analysis is a bit pointless.
>
> Any opinions?
>
> BTW I'm already just beyond the PCB thickness I'm allowed so I can't
> just use thicker copper.
>
> Colin
>
> PS. sorry about using Google, I'm sitting in the UK behind a firewall
> controlled by an Indian call centre.


Article: 153212
Subject: Re: voltage drop on STRATIX FPGA supply planes
From: legg <legg@nospam.magma.ca>
Date: Sun, 08 Jan 2012 10:53:56 -0500
Links: << >>  << T >>  << A >>
On Fri, 06 Jan 2012 08:51:24 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

>On Fri, 6 Jan 2012 01:55:03 -0800 (PST), "colin_toogood@yahoo.com"
><colin_toogood@yahoo.com> wrote:
>
>>Guys
>>
>>I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power
>>plane. It is showing a 30mV voltage drop across the BGA itself, let
>>alone getting the power to the BGA which is dropping another 50mV.
>>
>>Surely the 30mV cannot be true as there is a power plane in the BGA
>>package itself.
>>
>>Historically I would look at the size of the plane and assume that
>>everything is fine and I can't help wondering whether this worst case
>>analysis is a bit pointless.
>>
>>Any opinions?
>>
>>BTW I'm already just beyond the PCB thickness I'm allowed so I can't
>>just use thicker copper.
>>
>>Colin
>>
>>PS. sorry about using Google, I'm sitting in the UK behind a firewall
>>controlled by an Indian call centre.
>
>How much current are you expecting in the core?
>
>What do mean by "30mV voltage drop across the BGA itself" ? Does that
>mean PCB plane drop, or rather BGA balls to chip internal voltage?
>
>The chip vendors should give us one remote-sense feedback/measurement
>ball.
>
>John
>
You can probably already take your pick.....if you sacrifice the
immediate local signal functions.

RL

Article: 153213
Subject: Re: Trying to select a development board, can somebody help me make
From: John Adair <g1@enterpoint.co.uk>
Date: Sun, 8 Jan 2012 10:03:18 -0800 (PST)
Links: << >>  << T >>  << A >>
Jurgen

Have you seen our ADV7202 module http://www.enterpoint.co.uk/moelbryn/modul=
es/adv7202.html?
and does that cover what you want to do? We also have a HDMI solution
on the way that might of interest to some people.

John Adair
Enterpoint Ltd.


On Jan 4, 6:52=A0pm, chthon <jurgen.defu...@gmail.com> wrote:
> Hello,
>
> I am trying to decide what board to order for a project I want to do betw=
een April and June in school, and for other projects, mainly to exercise VH=
DL and design interesting projects. The school project itself is the design=
 of a general purpose DSP data path.
>
> I have currently staked out the following boards, based upon the features=
 I need and the price.
>
> Digilent =A0 | Atlys =A0 =A0 =A0 =A0 =A0|
> Enterpoint | Drigmorn-3 =A0 =A0 |
> Xilinx =A0 =A0 | 3A Starter kit |
> Enterpoint | Drigmorn-2 =A0 =A0 |
> Xilinx =A0 =A0 | 3E Starter kit |
>
> However, also delivery time and ease of ordering are somewhat necessary, =
and three of the five boards come from the US, while 2 come from the UK, an=
d I live in Belgium.
>
> On the other hand, the Drigmorn boards do not feature a video output (wha=
tever type), which is also something I would like to have.
>
> And then there is the choice of FPGA:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LX16 =A0 XC3S700A
> Logic cells: =A0 =A0 14579 =A013248
> Slices =A0 =A0 : =A0 =A0 2278 =A0 5888
> Block RAM =A0: =A0 =A0 576 =A0 =A0360
> Distributed RAM: 136 =A0 =A092
>
> Since a LX16 seems to have less slices than a XC3S700A, does that mean th=
at the LX16 will reach its maximum earlier than the XC3S700A? Conversely, d=
oes the lesser amount of distributed RAM on the XC3S700A mean that it could=
 be that in a pipelined design it has less possibilities than the LX16?
>
> I must say, that if I have to select purely on price, this would certainl=
y favor the Drigmorn-2, but does the choice of the XC3S700A FPGA in that ca=
se limit me in my design choices?
>
> And another point, I only own a MacBook Air anymore, with Linux on Virtua=
lbox and ISE inside it, but how does this translate in my choices for progr=
amming the selected board?
>
> Regards,
>
> Jurgen Defurne


Article: 153214
Subject: Re: voltage drop on STRATIX FPGA supply planes
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sun, 08 Jan 2012 10:48:37 -0800
Links: << >>  << T >>  << A >>
On Sun, 08 Jan 2012 10:53:56 -0500, legg <legg@nospam.magma.ca> wrote:

>On Fri, 06 Jan 2012 08:51:24 -0800, John Larkin
><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>
>>On Fri, 6 Jan 2012 01:55:03 -0800 (PST), "colin_toogood@yahoo.com"
>><colin_toogood@yahoo.com> wrote:
>>
>>>Guys
>>>
>>>I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power
>>>plane. It is showing a 30mV voltage drop across the BGA itself, let
>>>alone getting the power to the BGA which is dropping another 50mV.
>>>
>>>Surely the 30mV cannot be true as there is a power plane in the BGA
>>>package itself.
>>>
>>>Historically I would look at the size of the plane and assume that
>>>everything is fine and I can't help wondering whether this worst case
>>>analysis is a bit pointless.
>>>
>>>Any opinions?
>>>
>>>BTW I'm already just beyond the PCB thickness I'm allowed so I can't
>>>just use thicker copper.
>>>
>>>Colin
>>>
>>>PS. sorry about using Google, I'm sitting in the UK behind a firewall
>>>controlled by an Indian call centre.
>>
>>How much current are you expecting in the core?
>>
>>What do mean by "30mV voltage drop across the BGA itself" ? Does that
>>mean PCB plane drop, or rather BGA balls to chip internal voltage?
>>
>>The chip vendors should give us one remote-sense feedback/measurement
>>ball.
>>
>>John
>>
>You can probably already take your pick.....if you sacrifice the
>immediate local signal functions.
>
>RL

I can sense an I/O bank supply voltage by just pulling an output up,
but core voltage is harder to get at. I could swipe one ball out of,
say, ten paralleled ones, I guess, if I were sure they were really
paralleled.

Are core voltages segmented on most FPGAs, or are all the Vcc_core
balls connected to one power net? 

John



Article: 153215
Subject: Re: voltage drop on STRATIX FPGA supply planes
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 8 Jan 2012 21:46:10 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga John Larkin <jjlarkin@highnotlandthistechnologypart.com> wrote:

(snip, someone wrote)
>>>What do mean by "30mV voltage drop across the BGA itself" ? Does that
>>>mean PCB plane drop, or rather BGA balls to chip internal voltage?

(snip)
> I can sense an I/O bank supply voltage by just pulling an output up,
> but core voltage is harder to get at. I could swipe one ball out of,
> say, ten paralleled ones, I guess, if I were sure they were really
> paralleled.

As far as I know, you aren't supposed to do that. Even if they are
paralleled internally, there might be enough voltage drop across the
internal connection to cause problems.

> Are core voltages segmented on most FPGAs, or are all the Vcc_core
> balls connected to one power net? 

My choice would be to run a wire out from one of the power balls and
measure the voltage on that wire. You could even use a power supply with
a remote sense, such that it would adjust its output to get the right
voltage on the sense line. Maybe even sense lines for both Vcc and
ground.

If you don't have remote sense on the power supply, just use them as
a remote voltage measurment.

-- glen

Article: 153216
Subject: Re: voltage drop on STRATIX FPGA supply planes
From: "krw@att.bizzzzzzzzzzzz" <krw@att.bizzzzzzzzzzzz>
Date: Sun, 08 Jan 2012 17:14:01 -0500
Links: << >>  << T >>  << A >>
On Sun, 08 Jan 2012 10:48:37 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

>On Sun, 08 Jan 2012 10:53:56 -0500, legg <legg@nospam.magma.ca> wrote:
>
>>On Fri, 06 Jan 2012 08:51:24 -0800, John Larkin
>><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>>
>>>On Fri, 6 Jan 2012 01:55:03 -0800 (PST), "colin_toogood@yahoo.com"
>>><colin_toogood@yahoo.com> wrote:
>>>
>>>>Guys
>>>>
>>>>I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power
>>>>plane. It is showing a 30mV voltage drop across the BGA itself, let
>>>>alone getting the power to the BGA which is dropping another 50mV.
>>>>
>>>>Surely the 30mV cannot be true as there is a power plane in the BGA
>>>>package itself.
>>>>
>>>>Historically I would look at the size of the plane and assume that
>>>>everything is fine and I can't help wondering whether this worst case
>>>>analysis is a bit pointless.
>>>>
>>>>Any opinions?
>>>>
>>>>BTW I'm already just beyond the PCB thickness I'm allowed so I can't
>>>>just use thicker copper.
>>>>
>>>>Colin
>>>>
>>>>PS. sorry about using Google, I'm sitting in the UK behind a firewall
>>>>controlled by an Indian call centre.
>>>
>>>How much current are you expecting in the core?
>>>
>>>What do mean by "30mV voltage drop across the BGA itself" ? Does that
>>>mean PCB plane drop, or rather BGA balls to chip internal voltage?
>>>
>>>The chip vendors should give us one remote-sense feedback/measurement
>>>ball.
>>>
>>>John
>>>
>>You can probably already take your pick.....if you sacrifice the
>>immediate local signal functions.
>>
>>RL
>
>I can sense an I/O bank supply voltage by just pulling an output up,
>but core voltage is harder to get at. I could swipe one ball out of,
>say, ten paralleled ones, I guess, if I were sure they were really
>paralleled.

Probably not a good idea.  You'll be leaving one corner of the power mesh
sagging.  A sense to the pad might not be a bad idea, though.  ...if you can
control the regulator.

>Are core voltages segmented on most FPGAs, or are all the Vcc_core
>balls connected to one power net? 

Paralleled.  

Article: 153217
Subject: Re: voltage drop on STRATIX FPGA supply planes
From: John Adair <g1@enterpoint.co.uk>
Date: Mon, 9 Jan 2012 00:18:18 -0800 (PST)
Links: << >>  << T >>  << A >>
I should have probably have clarified the POL approach for a single
FPGA. Some of the regulators we use are capable of being used in
tandem so you might use 2 or 4 of them together. They do need to be
tied together to avoid issues caused by large differences. This does
avoid all of the current being delivered in a small contact area which
can reduce losses and is sort of similar to the approach taken by most
FPGAs themselves. It's also worth pointing out that there are always
differences between individual FPGA power balls but they are small and
FPGAs do cope with that. Sometimes part of the effect is more current
gets dragged through an individual "good" ball causing more volts drop
and crudely self regulating.

If we are looking at losses don't forget the vias. We recently did a
50A circuit on our Broaddown3 board and to keep losses reasonable we
put something like 30 vias between the regulators arms and the
internal plane. This is more extreme than most people will need to
think about and you can argue about which size of via to use as there
are some trades here in numbner of vias versus size. In some boards
like our Merrick1 where we used a brick dc/dc, instead of an on-board
regulator approach, we can have 50A going though a single hole / leg.
It does help a lot having the leg to carry current but still means a
lot of current in a local board area to handle.

Something to consider are copper filled vias when dc loss is
important. They are a specalist technique also used to reduce via
losses but do come at a cost and tend to limit the number of PCB
manufacturers you can use.

John Adair
Enterpoint Ltd.

On Jan 8, 10:14=A0pm, "k...@att.bizzzzzzzzzzzz"
<k...@att.bizzzzzzzzzzzz> wrote:
> On Sun, 08 Jan 2012 10:48:37 -0800, John Larkin
>
>
>
>
>
>
>
>
>
> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> >On Sun, 08 Jan 2012 10:53:56 -0500, legg <l...@nospam.magma.ca> wrote:
>
> >>On Fri, 06 Jan 2012 08:51:24 -0800, John Larkin
> >><jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>
> >>>On Fri, 6 Jan 2012 01:55:03 -0800 (PST), "colin_toog...@yahoo.com"
> >>><colin_toog...@yahoo.com> wrote:
>
> >>>>Guys
>
> >>>>I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power
> >>>>plane. It is showing a 30mV voltage drop across the BGA itself, let
> >>>>alone getting the power to the BGA which is dropping another 50mV.
>
> >>>>Surely the 30mV cannot be true as there is a power plane in the BGA
> >>>>package itself.
>
> >>>>Historically I would look at the size of the plane and assume that
> >>>>everything is fine and I can't help wondering whether this worst case
> >>>>analysis is a bit pointless.
>
> >>>>Any opinions?
>
> >>>>BTW I'm already just beyond the PCB thickness I'm allowed so I can't
> >>>>just use thicker copper.
>
> >>>>Colin
>
> >>>>PS. sorry about using Google, I'm sitting in the UK behind a firewall
> >>>>controlled by an Indian call centre.
>
> >>>How much current are you expecting in the core?
>
> >>>What do mean by "30mV voltage drop across the BGA itself" ? Does that
> >>>mean PCB plane drop, or rather BGA balls to chip internal voltage?
>
> >>>The chip vendors should give us one remote-sense feedback/measurement
> >>>ball.
>
> >>>John
>
> >>You can probably already take your pick.....if you sacrifice the
> >>immediate local signal functions.
>
> >>RL
>
> >I can sense an I/O bank supply voltage by just pulling an output up,
> >but core voltage is harder to get at. I could swipe one ball out of,
> >say, ten paralleled ones, I guess, if I were sure they were really
> >paralleled.
>
> Probably not a good idea. =A0You'll be leaving one corner of the power me=
sh
> sagging. =A0A sense to the pad might not be a bad idea, though. =A0...if =
you can
> control the regulator.
>
> >Are core voltages segmented on most FPGAs, or are all the Vcc_core
> >balls connected to one power net?
>
> Paralleled.


Article: 153218
Subject: Re: Beginner question on FIFO in
From: Andy <jonesandy@comcast.net>
Date: Mon, 9 Jan 2012 06:23:14 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 5, 11:30=A0am, Tim Wescott <t...@seemywebsite.com> wrote:
> Yes. =A0When you write software you should be thinking in the back of you=
r
> mind what the processor will be doing (and possibly what the compiler's
> optimizer will do, first). =A0When you write Verilog or VHDL you should b=
e
> thinking in the back of your mind what logic will be generated. =A0I have
> to admit that when I do this most of the blocks have "74HCxx" on them,
> but you still want to devote part of your brain to thinking what actual
> hardware will get used: it keeps you from doing really stupid things.

I write vhdl a lot more than 2% of the time, and I share your anti-
wizard approach for almost everything unless it is built-in HW that
can only be accessed by primitives, like PLL/DLL, some two-clock FIFOs
or that use two different data widths, etc. More often than not, I
need some little special behavior for my specific application that
precludes using the built-in stuff anyway, so I infer the RAM and roll
my own control. Dealing with data in arrays is so much easier anyway.

I found out a long time ago that thinking about and then coding
function and cycle-based behavior, rather than flops and gates, is
more productive for me. When I need the utmost in performance
(rarely), I normally use retiming, and it doesn't matter where/how I
coded the registers anyway. If I need to speed it up, I normally
approach it to see "what can I do ahead of time (in a previous clock
cycle)?", or "what can I delay (into the next clock cycle)?", while I
look for areas that I'm doing too much in one clock cycle.  Unlike SW,
where you generally don't want to do something until and unless you
really need to, in HW it is almost the opposite. Do it just in case,
then use the results when you need them. This generally results in
less logic in the function, and therefore faster performance.

Andy

Article: 153219
Subject: Xilinx SRAM clock-to-out and input constraint with forwarded clock
From: "Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com>
Date: Wed, 11 Jan 2012 01:26:27 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

I have SRAM connected to a FPGA.
The clock is forwarded to the SRAM by the FPGA (using ODDR trick).
The input clock to the system is of another frequency and is
internally multiplied by a DCM.
Lets call the input clock (on the pad) clk_in  and the internal DCM
generated clock clk_1x

Now, I'd like to constraint :

 - The clock to out from my internal clk_1x to pad for the various
outputs
 - The skew between all the pins. (Since I use IOB registers, it
should be constraint by design but I'd like at least a report ...)
 - The valid window for capturing the incoming signals.

And somehow I can't figure out how to do these because I don't have a
"pad" that reflects my internal clock.
If I just try to put an OFFSET relative to my clk_in, then it outputs
mostly garbage because the clk_in and clk_1x have different
frequencies and so it tries to consider intemediate edges and stuff
but I don't care about that, all the design is clocked on clk_1x and
not clk_in ...

I looked at the Xilinx example but couldn't find one that fits. Each
time they have the external clock directly feed the internal logic and
not a DCM modifying the frequency in the middle.

Cheers,

    Sylvain

Article: 153220
Subject: opendous-jtag support for independent USB drivers for JTAG/Impact/Chipscope?
From: wzab <wzab01@gmail.com>
Date: Wed, 11 Jan 2012 08:11:21 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

Probably most Linux users working with Xilinx tools use the excellent
drivers written by Michael Gernoth and available at http://rmdir.de/~michael/xilinx/

I'm looking for a way to embed the whole USB<->JTAG converter into
device, so design should cheap and efficient.

Last time I started to use them with FT2232H chip connected directly
to the JTAG pins of FPGA.
The result were acceptable, but speed was quite low.
I think, that significant improvement could be achieved by using CPU
driven JTAG hardware instead of FT2232H - e.g. the opendous-jtag
http://code.google.com/p/opendous-jtag/

As the drivers are open source, it should be possible to add support
to opendous-jtag (maybe with slightly modified firmware). Before I
start to do it myself - has anybody tried to do it before? Any hints,
pitfalls?
--
TIA & Regards,
Wojtek Zabolotny

Article: 153221
Subject: Re: Xilinx SRAM clock-to-out and input constraint with forwarded clock
From: nico@puntnl.niks (Nico Coesel)
Date: Wed, 11 Jan 2012 17:17:58 GMT
Links: << >>  << T >>  << A >>
"Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com> wrote:

>Hi,
>
>I have SRAM connected to a FPGA.
>The clock is forwarded to the SRAM by the FPGA (using ODDR trick).
>The input clock to the system is of another frequency and is
>internally multiplied by a DCM.
>Lets call the input clock (on the pad) clk_in  and the internal DCM
>generated clock clk_1x
>
>Now, I'd like to constraint :
>
> - The clock to out from my internal clk_1x to pad for the various
>outputs

You can't. You must specify FF to PAD. The path between a flipflop and
an output isn't covered by a clock domain.


TIMEGRP	"all_ff" = ffs("*");
TIMEGRP	"trigger_analog_pad" = pads("trigger_analog_out");
TIMESPEC "TStrigger_analog_out" = FROM "all_ff" TO
"trigger_analog_pad" 7;


> - The skew between all the pins. (Since I use IOB registers, it
>should be constraint by design but I'd like at least a report ...)

See above. The path between an input and a flipflip isn't covered by a
clock domain.

> - The valid window for capturing the incoming signals.

You have to calculate this by hand. 


-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 153222
Subject: XLNX efuse anyone?
From: SysTom <mr.thomas.c.jones@gmail.com>
Date: Wed, 11 Jan 2012 13:45:17 -0800 (PST)
Links: << >>  << T >>  << A >>
(repost from XLNX forum)

Has anyone succesfully managed to program the eFuses? On the Virtex-6
in particular but any device would be good...

There seems to be many restrictions and I am unclear if I am violating
one of them.  If you have managed to program eFuse please respond
with:

Device
Impact Version
JTAG scan chain

Anything else that might help.

Thanks, Tom

Article: 153223
Subject: Re: Can't get the Xilinx cable drivers installed on SL6.1 (RHEL 6.1)
From: "ngill" <nat.gill@n_o_s_p_a_m.gmail.com>
Date: Thu, 12 Jan 2012 06:45:42 -0600
Links: << >>  << T >>  << A >>
>Is there any particular reason to compile your own libusb instead of
>using the distribution packages?
>
>To make the Xilinx JTAG cable working in the RHEL/CentOS/SL 6.x do the
>following stops. There is detailed description on my website
>http://www.sensor-to-image.cz/doku.php?id=3Deda:xilinx but unfortunately
>it is in Czech language only. Sorry.
>
>1. Install and "fix" libusb:
>
>yum install libusb libusb1 fxload
>cd /usr/lib64 (or /usr/lib if you are running 32b system)
>ln -s libusb-1.0.so.0.0.0 libusb.so
>
>2. "Fix" the Xilinx cable setup script
><xilinx_install_dir>/ISE_DS/ISE/bin/lin64/setup_pcusb (or the same path
>with lin instead of lin64) which does not detect udev correctly:
>
># Use udev always
>#TP_USE_UDEV=3D"0"
>#TP_UDEV_ENABLED=3D`ps -e | grep -c udevd`
>TP_USE_UDEV=3D"1"
>TP_UDEV_ENABLED=3D"1"
>
>3. Run the script from its directory:
>
>cd <xilinx_install_dir>/ISE_DS/ISE/bin/lin64/setup_pcusb (or lin instead
>of lin64)
>./setup_pcusb
>
>4. Generated udev rule uses wrong syntax. The rule for current version
>of udev /etc/udev/rules.d/xusbdfwu.rules must look like this (long lines
>must be retained, see my website for proper formatting):
>
># version 0003
>ATTR{idVendor}=3D=3D"03fd", ATTR{idProduct}=3D=3D"0008", MODE=3D"666"
>SUBSYSTEM=3D=3D"usb", ACTION=3D=3D"add", ATTR{idVendor}=3D=3D"03fd",
ATTR{i=
>dProduct}=3D=3D"0007", RUN+=3D"/sbin/fxload -v -t fx2 -I
/usr/share/xusbdfw=
>u.hex -D $tempnode"
>SUBSYSTEM=3D=3D"usb", ACTION=3D=3D"add", ATTR{idVendor}=3D=3D"03fd",
ATTR{i=
>dProduct}=3D=3D"0009", RUN+=3D"/sbin/fxload -v -t fx2 -I
/usr/share/xusb_xu=
>p.hex -D $tempnode"
>SUBSYSTEM=3D=3D"usb", ACTION=3D=3D"add", ATTR{idVendor}=3D=3D"03fd",
ATTR{i=
>dProduct}=3D=3D"000d", RUN+=3D"/sbin/fxload -v -t fx2 -I
/usr/share/xusb_em=
>b.hex -D $tempnode"
>SUBSYSTEM=3D=3D"usb", ACTION=3D=3D"add", ATTR{idVendor}=3D=3D"03fd",
ATTR{i=
>dProduct}=3D=3D"000f", RUN+=3D"/sbin/fxload -v -t fx2 -I
/usr/share/xusb_xl=
>p.hex -D $tempnode"
>SUBSYSTEM=3D=3D"usb", ACTION=3D=3D"add", ATTR{idVendor}=3D=3D"03fd",
ATTR{i=
>dProduct}=3D=3D"0013", RUN+=3D"/sbin/fxload -v -t fx2 -I
/usr/share/xusb_xp=
>2.hex -D $tempnode"
>SUBSYSTEM=3D=3D"usb", ACTION=3D=3D"add", ATTR{idVendor}=3D=3D"03fd",
ATTR{i=
>dProduct}=3D=3D"0015", RUN+=3D"/sbin/fxload -v -t fx2 -I
/usr/share/xusb_xs=
>e.hex -D $tempnode"
>
>5. Connect/reconnect your cable, check dmesg, test iMPACT/ChipScope.
>
>Regards,
>Jan
>
>
>Sorry if the post appears twice. I had some problems posting the
>message.
>
>
>


Jan,

Thanks for the tutorial.  Im attempting to do the same thing with
SL6.1/CentOS6/RHEL6 and the Xilinx 10.1.03 tools with no success.  After I
configure everything as you prescribe when I run impact and try to read the
jtag chain it bombs and says "Module windrvr6 is not loaded. Please
reinstall the cable drivers".  Your solution should bypass the windrvr6
module correct?  Any idea why it would still be looking for it?

Thanks,
Nat

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

Article: 153224
Subject: Re: Trying to select a development board, can somebody help me make an informed choice?
From: "jpendlum" <jpendlum@n_o_s_p_a_m.gmail.com>
Date: Thu, 12 Jan 2012 06:49:36 -0600
Links: << >>  << T >>  << A >>
It looks like you have a Xilinx preference, but if you willing to try other
FPGA vendors, Terasic.com has some surprisingly low-cost Altera FPGA
development boards.

I bought their DE2-70 board and really like it. It is in your price range
and has some of the features you want, such as video out. It has a Cyclone
IV FPGA that is much larger than the Spartan FPGAs you mentioned. Also,
Altera's free version of Quartus II (their synthesis/place&route tools)
supports the device on the DE2-70.

As far as delivery time, they are based in Taiwan. Mine took a few weeks
for delivery to the US.

Good luck!

>Hello,
>
>I am trying to decide what board to order for a project I want to do
betwee=
>n April and June in school, and for other projects, mainly to exercise
VHDL=
> and design interesting projects. The school project itself is the design
o=
>f a general purpose DSP data path.
>
>I have currently staked out the following boards, based upon the features
I=
> need and the price.
>
>Digilent   | Atlys          |
>Enterpoint | Drigmorn-3     |
>Xilinx     | 3A Starter kit |
>Enterpoint | Drigmorn-2     |
>Xilinx     | 3E Starter kit |
>
>However, also delivery time and ease of ordering are somewhat necessary,
an=
>d three of the five boards come from the US, while 2 come from the UK, and
=
>I live in Belgium.
>
>On the other hand, the Drigmorn boards do not feature a video output
(whate=
>ver type), which is also something I would like to have.
>
>And then there is the choice of FPGA:
>
>                 LX16   XC3S700A
>Logic cells:     14579  13248
>Slices     :     2278   5888
>Block RAM  :     576    360
>Distributed RAM: 136    92
>
>Since a LX16 seems to have less slices than a XC3S700A, does that mean
that=
> the LX16 will reach its maximum earlier than the XC3S700A? Conversely,
doe=
>s the lesser amount of distributed RAM on the XC3S700A mean that it could
b=
>e that in a pipelined design it has less possibilities than the LX16?
>
>I must say, that if I have to select purely on price, this would certainly
=
>favor the Drigmorn-2, but does the choice of the XC3S700A FPGA in that
case=
> limit me in my design choices?
>
>And another point, I only own a MacBook Air anymore, with Linux on
Virtualb=
>ox and ISE inside it, but how does this translate in my choices for
program=
>ming the selected board?
>
>Regards,
>
>Jurgen Defurne
>

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



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

Threads starting:
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