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 134750

Article: 134750
Subject: Re: need fast FPGA suggestions
From: Antonio Pasini <removethis_antonio.pasini@alice.it>
Date: Thu, 28 Aug 2008 22:00:05 +0200
Links: << >>  << T >>  << A >>
Il 25/08/2008 21.08, Jon Elson ha scritto:

> Somebody asked, "Gee, couldn't you do that with an FPGA?"  Well, a few 
> years ago, maybe not.  So, could anyone suggest some fast FPGAs that can 
> handle clocks in the 500+ MHz range?  I normally work with Xilinx, but 

I agree the SERDES solution is more elegant and powerful.

But, just for a comparison of what can be done with cheap parts...

In the summer I had some spare time... just for fun, I (almost) did a 
simple logic analyzer using a Spartan3E500, -4 (slower), using a Nexys2 
board. A 32 channel, 400 Mhz, 16 Mbytes buffer, RLE compressed, high 
speed USB 2.0 logic analizer at $99. Not bad!

Never had time to do the PC software part and finish some pieces... 
maybe next holidays if it's raining...

Using the tecnique shown in XAPP225 (4 "parallel" phase shifted 
acquisition, and combinatorial stage to "find" the edge), the design can 
easily reach 400 Mhz sampling (100 Mhz clock, 4 phases) on each of 32 
input channels. I didn't even try to manually floorplan anything, it was 
more than enough for me. Besides, it's for fun!

A single acquisition module uses a 100 Mhz clock and a 90° copy.

For each input channel, you get 4 bits in parallel in output, with the 4 
last samples at 400 Mhz effective sampling frequency.

There's still space for RLE compression, triggering unit, external ram 
controller, USB slave fifo interface, and a bunch of internal I2C 
registers. Should be no problem fitting "just" a delay line made with 
counters.

With the last 4 samples available "in parallel" at a much slower clock 
(100 Mhz), you can use a mux to "choose" the phase delay you want with 
the two least significant bits of the choosen delay.

 From there on, it's easy since frequencies are "normal".

How to *output* those.... ehm...

Here is the front-end code (sorry for comments in italian):


`timescale 1ns / 1ps

/*
Cfr. XAPP225.
*/

module sampler_4x #(parameter integer WIDTH = 32)
(
     input [WIDTH-1:0] din,
	input clk,
	input clk_90, 		
	// output
	output [(4*WIDTH)-1:0] q
);

wire [WIDTH-1:0] az0, az1, az2;
wire [WIDTH-1:0] bz0, bz1, bz2;
wire [WIDTH-1:0] cz0, cz1, cz2;
wire [WIDTH-1:0] dz0, dz1, dz2;

// sequenze di FF organizzati in modo tale da non aver mai campionamenti 
piu' vicini di 0.75*Tclk
// FD:   DFF synchronous reset
// FD_1: DFF with Negative-Edge Clock and Synchronous Reset
genvar i;
generate
	for (i = 0; i < WIDTH; i = i +1)
	begin: gen_ifddr
		// fase 0
		FD ff_az0(.D(din[i]), .C(clk), 	    .Q(az0[i]));
		FD ff_az1(.D(az0[i]), .C(clk), 	    .Q(az1[i]));
		FD ff_az2(.D(az1[i]), .C(clk), 	    .Q(az2[i]));
		FD ff_az3(.D(az2[i]), .C(clk), 	    .Q(q[i]));	
		// fase 90
		FD ff_bz0(.D(din[i]), .C(clk_90),  	.Q(bz0[i]));	// 0.75T
		FD ff_bz1(.D(bz0[i]), .C(clk), 	    .Q(bz1[i]));
		FD ff_bz2(.D(bz1[i]), .C(clk), 	    .Q(bz2[i]));
		FD ff_bz3(.D(bz2[i]), .C(clk), 	    .Q(q[WIDTH + i]));	
		// fase 180
		FD_1 ff_cz0(.D(din[i]), .C(clk), 	.Q(cz0[i]));	// 0.75T
		FD ff_cz1(.D(cz0[i]), .C(clk_90), 	.Q(cz1[i]));    // 0.75T
		FD ff_cz2(.D(cz1[i]), .C(clk), 	    .Q(cz2[i]));
		FD ff_cz3(.D(cz2[i]), .C(clk), 	    .Q(q[2*WIDTH + i]));	
		// fase 270
		FD_1 ff_dz0(.D(din[i]), .C(clk_90), .Q(dz0[i]));	// 0.75T
		FD_1 ff_dz1(.D(dz0[i]), .C(clk), 	.Q(dz1[i]));    // 0.75T
		FD ff_dz2(.D(dz1[i]), .C(clk_90), 	.Q(dz2[i]));    // 0.75T
		FD ff_dz3(.D(dz2[i]), .C(clk), 	    .Q(q[3*WIDTH + i]));	
	end
endgenerate

endmodule









Article: 134751
Subject: Re: Genode FPGA graphics project launched
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Thu, 28 Aug 2008 13:37:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 28 Aug., 12:37, David Brown <da...@westcontrol.removethisbit.com>
wrote:

> The LGPL is a little lighter - it allows you to link the LGPL'ed code
> with non-GPL'ed code as long as anyone with the binary is able to get
> the source code to the LGPL part, modify it, re-link it, and use the new
> version. =A0This is fine for things like dynamically linked libraries on =
a
> desktop OS (that's what it was designed for), but hardly practical for
> FPGA IP!

Why not? There is no need to be able to do this dynamically. If you
can do it with the usual FPGA toolflow everything is in order.

In the software world there has been a long discussion about what
linking
means. For the hardware world this is completely in the open. When
using
GPLed IP, must other FPGA IP in the same project be under GPL? (Very
likely.)
But how about the board layout? (Maybe) How about software running on
a GPLed
processor (following the dynamic linking debate this probably is a yes
for software
stored in the bitstream and a no for software loaded later).

I think that anyone who uses a software license for hardware should
clarify what
this means when applied to hardware. Just write an appendix to the
license.
After all the creator of the work is free to license under any terms
he likes, he is
not bound by the FSFs view of the world.

And yes, if you want to use it together with EDK, the LGPL is the
better starting point
than the GPL.




Article: 134752
Subject: Re: need fast FPGA suggestions
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 29 Aug 2008 08:44:52 +1200
Links: << >>  << T >>  << A >>
Jon Elson wrote:
> Well, given the serdes function of the Virtex, maybe we can go 1 ns 
> input and output resolution, with only 125 MHz clock on the 
> counter/comparator.  My boss would really love that.  The smaller Virtex 
> seem to come in a 1mm-pitch BGA, maybe I can even learn how to do that 
> myself.  Since the balls are only around the perimiter, it might be 
> visibly inspectable.  I'll have to do more research to find out what is 
> practical.

You could add some pin-redundancy as this seem to have a (relatively) 
low number of inputs ?
-jg


Article: 134753
Subject: Re: Genode FPGA graphics project launched
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Thu, 28 Aug 2008 13:49:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 28 Aug., 18:24, "MikeWhy" <boat042-nos...@yahoo.com> wrote:

> > If MicroBlaze was a hard-core, then maybe I'd agree. However, as a
> > soft-core, to me, it's the same as linking with a library.
>
> If that were so, Genode would be required to GPL Microblaze, and our
> troubles would already be solved. We would just refer everyone else to
> Genode for the Microblaze code.

No. GPL prohibits linking with non GPL code, that is a fact. Compiling
an
FPGA bitstream that contains both Genode and non GPL Xilinx Cores is
therefore a violation of Genodes GPL license.
This does not mean that the Xilinx Cores suddenly fall under the GPL.
It only means that the creators of Genode do not allow you to create
such a
bitstream. (Violators face multiple years in prison in most
countries.)

Norman writes that this is not what he intended, so he probably
should
change the license.
As I interpret the LPGL it provides exactly the desired effects:
Modifications
to Genode must be made publicly available, but all other cores in the
system can have any license including the Vendor license.

Kolja Sulimma





Article: 134754
Subject: Re: need fast FPGA suggestions
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 29 Aug 2008 09:48:28 +1200
Links: << >>  << T >>  << A >>
Jon Elson wrote:

> Jim Granville wrote:
>>
>> Analog is a candidate, but the OP mentioned a 100:1 dynamic range.
>> Maybe some range-sw caps ?
>>
> Well, it is all designed and the board is layed out.  I used the AD 
> CMP603 single fast comparator.  A bear to mount, but a very fine chip 
> for the purpose.  It DOES use 2 range switching caps, plus stray 
> capacitance as the lowest cap value, plus 2 selections of 
> current-programming resistor.
> 
> THEN, my boss said -- "Hey, couldn't you do that with an FPGA?"

One nice feature of Analog-retrigger, is the lack of sampling jitter.
A minus is the calibration and drifts

How important is jitter ?

Another hybrid analog approach is to use multiple Gateable Osc, and 
Dividers.
The Osc is DAC controlled over just over 2:1 in Freq, and the divider
takes care of the rest.
This is also easy to calibrate, as you can flip from monostable to 
re-trigger, and use a longer timebase to get fractional ns values.

What is the smallest setting, and desired Step Size ?

>> Anyone seen Vos vs Common Mode voltage plots for LVDS channels
>> in FPGAs ? Cross talk figures ?
> 
> I guess you could measure it yourself.

Would take a while to get cross talk numbers :)

-jg


Article: 134755
Subject: How many mux input on a Xilinx V4 are pratical
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Thu, 28 Aug 2008 15:47:44 -0700
Links: << >>  << T >>  << A >>
Currently I have a design that processes
video data with a number of adjustable
parameters (like window borders) and
process results (like pixel counters).
I seen to have about 28 of them so far,
ranging from binary on/off to 10 bit BCD
counters.
These are displayed on a VGA port or an
NTSC overlay. All these parameters exist
on the fabric and are Muxed into a overlay
module that displays them in real time.

My question is how many of these parameters
and counters can I add before I run into
some real serious routing issues? Is there
anything I can do to minimize this potential
problem?

Brad Smallridge
AiVision



Article: 134756
Subject: Re: Virtex 5 bitstream encryption
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Thu, 28 Aug 2008 16:16:06 -0700
Links: << >>  << T >>  << A >>
bamboutcha9999@hotmail.com wrote:
> On 27 août, 18:29, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>> bamboutcha9...@hotmail.com wrote:
>>> Hello !
>>>  I would like to know the frequency used by Xilinx (Virtex 5) to
>>> decrypt bitstream before configuration .
>>>  The decrypter is it slow with small area ? fast with big area ?
>>> unfortunately it's not documented by xilinx .
>>> Thank u for help
>> It decrypts at the same rate as the configuration clock.  This could be
>> anywhere from KHz to the maximum of 100 MHz as specified in the data sheet.
>>
>> Ed McGettigan
>> --
>> Xilinx Inc.
> 
> 
> Ed ,
> thank for you answer .
> The rate of config clk is fixed by the user ( from 2Mhz to 60Mhz ) so
> i did not understand by "anywhere from KHz to the maximum of 100
> MHz" , 

2 MHz to 60 MHz falls within the window that I stated of KHz to 100 MHz.

> moreover with my
> encrypted bitstream (Eprom =>  FPGA) i couldn't run over 42 Mhz .
> why ?

Likely because of the timing relationships created by the EPROM. You 
should review the data sheet for the EPROM to verify the maximum 
frequency of operation in the mode that you are using it.

> What i want to know is the throughput of the decrypter (AES 256 CBC) ,
> how many cycles takes this architecture used by Xilinx ? 

The decrypter input-to-output is 1:1, so there are no stalls required 
for the input bitstream.  I don't know what the latency is of the actual 
block as it has no impact on the configuration sequence.

> is it Safe
> at  100% against attacks ( timing , fault attack , side channel
> attack ....) ?

Austin Lesea has said once or twice in this newsgroup that the NSA has 
approved it as secure and we know of no one that has broken it.

Ed McGettigan
--
Xilinx Inc.

Article: 134757
Subject: crazy patent
From: "langwadt@fonz.dk" <langwadt@fonz.dk>
Date: Thu, 28 Aug 2008 17:57:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
found in other group:

http://www.eetimes.com/showArticle.jhtml?articleID=210201176&cid=NL_eet

http://www.patentstorm.us/patents/7391237/description.html

-Lasse

Article: 134758
Subject: Re: Genode FPGA graphics project launched
From: Eric Smith <eric@brouhaha.com>
Date: Thu, 28 Aug 2008 18:08:12 -0700
Links: << >>  << T >>  << A >>
Kolja Sulimma <ksulimma@googlemail.com> writes:
> No. GPL prohibits linking with non GPL code, that is a fact. Compiling
> an
> FPGA bitstream that contains both Genode and non GPL Xilinx Cores is
> therefore a violation of Genodes GPL license.

Only if the resulting bitstream is distributed.  You can do it in the
privacy of your own home all you want.

Article: 134759
Subject: Re: crazy patent
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 29 Aug 2008 14:09:43 +1200
Links: << >>  << T >>  << A >>
langwadt@fonz.dk wrote:
> found in other group:
> 
> http://www.eetimes.com/showArticle.jhtml?articleID=210201176&cid=NL_eet
> 
> http://www.patentstorm.us/patents/7391237/description.html
> 
> -Lasse

Patents often clearly fail many of the thresholds they are supposed to 
pass, in part because the filing lawyers are motivated by the payment
and act of creating a patent. It is not helped either, that most
lawyers have no idea, or experience, of the item-field.
A patent is merely a license to litigate,

-jg


Article: 134760
Subject: Re: Hardware in Loop
From: Nirav <snirav@gmail.com>
Date: Thu, 28 Aug 2008 19:16:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dear  Eilert,
Thanks very much for reply.

I just saw reply today. .



On Aug 14, 2:36=A0am, backhus <n...@nirgends.xyz> wrote:
> Hi Nirav,
> you said your focus is on high speed data transfer.
> How about the EFM-01 Board fromwww.cesys.de/index_en.html
>
> The easyfpga-board has a maximum transfer rate of 8 Mbit (FTDI to FPGA)
> because it's just anusbto RS232 converter. (Sufficient?)
>
> Cesys and opalkelly both use the Cypress FX2 chip which provides a
> parallel bus interface to the FPGA with nearly full USB2 transfer rate.
>
> Now you have to compare how the vendors support the FX2 interface and
> the software development on the host side. And of course what size of
> FPGA you need (500Kgates vs 4000KGates+SDRAM), which depends on the
> application you have in mind.
>
> Have a nice synthesis
> =A0 =A0Eilert
>
> Nirav schrieb:
>
> > I am looking for a development board withUSBInterface for hardware-
> > in-loop.
> > I don't think I want to mess withUSB.
> > I just want to use some easy to use board which will allow me to
> > transfer data (at high speed) to-fro the board.
>
> > I saw board fromwww.easyfpga.com
> > andwww.opalkelly.com
>
> > But I wasn't sure..
> > Anyone has soem first hand experience with these boards?
> > How good are they for new-bie?
>
> > Any recommendations?


Article: 134761
Subject: Re: need fast FPGA suggestions
From: Antonio Pasini <removethis_antonio.pasini@alice.it>
Date: Fri, 29 Aug 2008 07:45:30 +0200
Links: << >>  << T >>  << A >>
Il 28/08/2008 22.00, Antonio Pasini ha scritto:

>         // fase 180
>         FD_1 ff_cz0(.D(din[i]), .C(clk),     .Q(cz0[i]));    // 0.75T
>         FD ff_cz1(.D(cz0[i]), .C(clk_90),     .Q(cz1[i]));    // 0.75T
>         FD ff_cz2(.D(cz1[i]), .C(clk),         .Q(cz2[i]));
>         FD ff_cz3(.D(cz2[i]), .C(clk),         .Q(q[2*WIDTH + i]));   


Argh! I stand corrected...

I don't remember exactly what I was drinking last summer when I wrote 
this :-), but it's just plain wrong!

At 180 and 270 degrees obviously one should use inverted clocks or 
properly phase shifted clocks... and then arrange the later stages..

The XAPP225 trick still apply... basically, "distributing" the total 
period budget among a pipeline of four or more FF, to finally align the 
data to the same 1/4 clock.

I "improved" the design starting from the back, and came backwards 
trying not to have more than 0.75T between FF...  wonderful, but wrong.

The line between cleverness and stupidity is so thin :-)

It's amazing how it's easy to find errors when you try to explain your 
work to others!




Article: 134762
Subject: Re: How many mux input on a Xilinx V4 are pratical
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 28 Aug 2008 22:54:19 -0700
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:
> Currently I have a design that processes
> video data with a number of adjustable
> parameters (like window borders) and
> process results (like pixel counters).
> I seen to have about 28 of them so far,
> ranging from binary on/off to 10 bit BCD
> counters.
> These are displayed on a VGA port or an
> NTSC overlay. All these parameters exist
> on the fabric and are Muxed into a overlay
> module that displays them in real time.
> 
> My question is how many of these parameters
> and counters can I add before I run into
> some real serious routing issues? Is there
> anything I can do to minimize this potential
> problem?
> 
> Brad Smallridge
> AiVision

Since modern FPGAs are significantly routing resources, I'd suggest you 
won't run into a routing problem.  Have you seen something that suggests 
you'll have a problem?

Consider that the mux can be implemented as a binary tree with 2-input 
muxes (or 4-input for some families).  A binary tree is much simpler to 
implement and distribute than a priority encoder style of multiplexer 
(using cascade logic).

If your timing is ample, the binary tree is great.  If you need better 
timing, coding to force more than one level of priority encoder style 
mux (10:1 mux structures, for instance) can provide a good balance 
between more, longer lines and speed.

I seriously think that if you don't concern yourself with it, it won't 
be an issue.  Unless timing is a problem.  Even then, pipelining of the 
large mux will help as well.  There are too many ways to make it work 
cleanly.

Just my humble opinion,
- John_H

Article: 134763
Subject: Re: How many mux input on a Xilinx V4 are pratical
From: Peter Alfke <alfke@sbcglobal.net>
Date: Thu, 28 Aug 2008 23:09:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 28, 3:47=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> Currently I have a design that processes
> video data with a number of adjustable
> parameters (like window borders) and
> process results (like pixel counters).
> I seen to have about 28 of them so far,
> ranging from binary on/off to 10 bit BCD
> counters.
> These are displayed on a VGA port or an
> NTSC overlay. All these parameters exist
> on the fabric and are Muxed into a overlay
> module that displays them in real time.
>
> My question is how many of these parameters
> and counters can I add before I run into
> some real serious routing issues? Is there
> anything I can do to minimize this potential
> problem?
>
> Brad Smallridge
> AiVision

You might think of using a BlockRAM as a big multiplexer.
You can use one port to enter variable data, and the other port to
output them for display.
Speed will not be an issue.
Just a thought....
Peter Alfke, from home

Article: 134764
Subject: Re: Genode FPGA graphics project launched
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 29 Aug 2008 09:21:43 +0200
Links: << >>  << T >>  << A >>
Jon Beniston wrote:
>> The GPL says (roughly) that any code that is directly linked to the
>> GPL'ed code must also be GPL'ed.  You can't use GPL'ed IP and non-GPL'ed
>> IP in the same FPGA.
> 
> Ok, I think we agree here.
> 
>> The LGPL is a little lighter - it allows you to link the LGPL'ed code
>> with non-GPL'ed code as long as anyone with the binary is able to get
>> the source code to the LGPL part, modify it, re-link it, and use the new
>> version.  This is fine for things like dynamically linked libraries on a
>> desktop OS (that's what it was designed for), but hardly practical for
>> FPGA IP!
> 
> You don't have to supply the modified code with the FPGA though. I'm
> sure a web download would be suitable.
> 

Technically, according to the letter of the GPL 2, a web download alone 
is not enough (it was considered too unreliable at the time the GPL2 was 
written), but the GPL 3 allows it.  It's a minor quibble, of course.

But what is important for using the LGPL is that the user (or anyone who 
legally acquires the binary) must have access to everything they need to 
modify the LGPL'ed code and produce a new binary, or exactly the same 
binary as the original.  In the software world, this means that the rest 
of the program must be available as a linkable object - easy if you have 
an OS and the LGPL'ed code is a dynamic library.  It must also be 
possible for the user to download their binary into the system.  It's 
okay if the tools to do this cost money, as long as the user is free to 
buy them - I don't think you'd have to provide any Microblaize IP, as 
that's a standard library with the tools.  But you'd have to include 
compiled versions of all your own IP, possibly also third party IP, and 
things like pin layout files.  And if the bitstream is to be encrypted, 
you have a new set of issues...

All in all, the LGPL is very impractical for embedded systems.

>> A better choice of license would be what is known as a "modified GPL" or
>> "GPL with exception" license (or the very similar Mozilla Public
>> License).  Here the GPL is explicitly modified to apply only to the
>> source files provided
> 
> What happens if someone modifies a file to use a function that is in a
> new file though? Do they have to provide this?
> 

I don't think so - there is no requirement that your modified m-GPL'ed 
code can work without the rest of your system.  The aim is to codify the 
idea that the package you got under the m-GPL is a community effort - 
you can use it as you want, but can't claim you wrote it, and if you 
extend or improve it, these changes must be available to others.  It has 
always struck me as a very fair license giving the best of both worlds 
(it can be used freely even in commercial systems, but enforces more 
"freeness" than BSD-style licenses).


Article: 134765
Subject: Weekend DSP + DIP +VLSI front end training starting from 6th
From: "arithos.designs2008@gmail.com" <arithos.designs2008@gmail.com>
Date: Fri, 29 Aug 2008 00:58:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
Arithos Designs is starting a new weekend batch on "Fundamentals of
Digital Signal Processing" and "Fundamentals of Digital Image
Processing" and "Front end VLSI design and simulation" from 6th
September.

For rough outline of the course, please check in our website. The
duration of the Course runs for a month.

It is an good opportunity for the people in industry to freshup their
basics and upgrade their skillset.

Also for the students to get prepared for their dream jobs and build
up their confidence level.

Anyone who are intrested to take up the course please send an
confirmation email or call at our office for furthur enquiries or drop
an email for furthur enquiry @ veena@arithos.com.

**Course completion certificate, and job assistance will be provided
at the end of the training.

**Projects for Btech/Mtech final year students are also provided.

Also we request you to join the Arithos Designs community at Orkut.

Regards,
Arithos Designs
www.arithos.com

A Premier DSP Design Consultancy and Corporate Training Company.

Article: 134766
Subject: Re: Genode FPGA graphics project launched
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 29 Aug 2008 09:59:47 +0200
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:
> On 28 Aug., 12:37, David Brown <da...@westcontrol.removethisbit.com> 
> wrote:
> 
>> The LGPL is a little lighter - it allows you to link the LGPL'ed
>> code with non-GPL'ed code as long as anyone with the binary is able
>> to get the source code to the LGPL part, modify it, re-link it, and
>> use the new version.  This is fine for things like dynamically
>> linked libraries on a desktop OS (that's what it was designed for),
>> but hardly practical for FPGA IP!
> 
> Why not? There is no need to be able to do this dynamically. If you 
> can do it with the usual FPGA toolflow everything is in order.
> 
> In the software world there has been a long discussion about what 
> linking means. For the hardware world this is completely in the open.
> When using GPLed IP, must other FPGA IP in the same project be under
> GPL? (Very likely.) But how about the board layout? (Maybe) How about
> software running on a GPLed processor (following the dynamic linking
> debate this probably is a yes for software stored in the bitstream
> and a no for software loaded later).
> 
> I think that anyone who uses a software license for hardware should 
> clarify what this means when applied to hardware. Just write an
> appendix to the license. After all the creator of the work is free to
> license under any terms he likes, he is not bound by the FSFs view of
> the world.
> 

This is very important - publishers should always give a statement of 
the aim or "spirit" of their license, as well as the legal stuff. 
Sometimes these are contradictory (I've seen software given out with the 
GPL "so that anyone can use it in their code"), but mostly it helps.  In 
particular, especially in the FPGA field, a clear indication of what the 
author means by "linking" and "derivative works" is vital.

> And yes, if you want to use it together with EDK, the LGPL is the 
> better starting point than the GPL.
> 

As you say, there have been plenty of discussions and debates around 
linking and derivative works regarding the GPL/LGPL, and there are 
plenty of opinions when it comes to the grey areas (such as binary 
modules in the Linux kernel) and use outside "ordinary" software (such 
as for FPGA IP).  The LGPL is certainly a better starting point than the 
GPL - but it is still not a good choice of license.  With a clear enough 
statement of the intent of the license, it might be okay - but otherwise 
it's better to pick a license that is clearer to start with.

Of course, the author is free to pick whatever license they want.  In 
this particular case, the author has chosen a dual license - GPL (which 
basically allows free academic, testing and evaluation usage), and a 
commercial license with no issues about linking or distribution.

Article: 134767
Subject: Re: crazy patent
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 29 Aug 2008 10:05:09 +0200
Links: << >>  << T >>  << A >>
langwadt@fonz.dk wrote:
> found in other group:
> 
> http://www.eetimes.com/showArticle.jhtml?articleID=210201176&cid=NL_eet
> 
> http://www.patentstorm.us/patents/7391237/description.html
> 

That is almost an exact description of the system used on Altera's NIOS 
development kits - and probably thousands of other designs.

Article: 134768
Subject: Re: How many mux input on a Xilinx V4 are pratical
From: Gabor <gabor@alacron.com>
Date: Fri, 29 Aug 2008 05:23:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 29, 2:09 am, Peter Alfke <al...@sbcglobal.net> wrote:
> On Aug 28, 3:47 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
> wrote:
>
>
>
> > Currently I have a design that processes
> > video data with a number of adjustable
> > parameters (like window borders) and
> > process results (like pixel counters).
> > I seen to have about 28 of them so far,
> > ranging from binary on/off to 10 bit BCD
> > counters.
> > These are displayed on a VGA port or an
> > NTSC overlay. All these parameters exist
> > on the fabric and are Muxed into a overlay
> > module that displays them in real time.
>
> > My question is how many of these parameters
> > and counters can I add before I run into
> > some real serious routing issues? Is there
> > anything I can do to minimize this potential
> > problem?
>
> > Brad Smallridge
> > AiVision
>
> You might think of using a BlockRAM as a big multiplexer.
> You can use one port to enter variable data, and the other port to
> output them for display.
> Speed will not be an issue.
> Just a thought....
> Peter Alfke, from home

I typically use block or distributed RAM for such muxes.  Many of
my designs contain parameters set by I2C bus (very slow).  I use
RAM as the readback port for all read/write registers / bits.  For
other read-only bits there is a mux in the fabric.  So now you have
a mux with many fewer inputs, specifically adding more parameters
to the mix makes no impact on the mux size.  Obviously adding
more dynamic inputs like counters will increase the mux unless
those are slow enough to add to the RAM instead.

Regards,
Gabor

Article: 134769
Subject: Format of Actel's SVF files
From: johannes.jansen@gmx.de
Date: Fri, 29 Aug 2008 05:37:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi everyone,
I have a PA3 device on a board where I want to make a quick blank
check to decide if it's neccesary to program or not to program. I use
a JTAG system from Goepel that uses SVF files generated by Actel. The
guy who designed the FPGA can't get me a 'blank check' SVF or a
shortened verify.
What I try now is to delete as much as possible from the verify SVF I
have to keep the time short but I'm a bit lost how to do the
manipulations right. My idea is to use just 1-5 of the 2300 rows for
the verify the fpga has.
Any ideas?
Thanks,
Johannes

Article: 134770
Subject: Re: need fast FPGA suggestions
From: Gabor <gabor@alacron.com>
Date: Fri, 29 Aug 2008 05:37:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 28, 3:11 pm, John_H <newsgr...@johnhandwork.com> wrote:
> On Aug 28, 8:30 am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > You don't have to use Virtex to get SERDES.  The low cost Lattice
> > family has SERDES and should be able to do what you are looking for at
> > a *much* lower price.
>
> While it's true the 3+Gb/s high speed serial channels are available in
> the Lattice parts (my first Lattice design has started in the ECP2M -
> yay!) the SERDES referred to in the Virtex parts for these posts are -
> unless I'm sincerely mistaken - the serializer/deserializer elements
> built into the general IOBs.  The standard I/Os end up with 800Mb/
> s-1Gb/s data rates (pulling these numbers from memory) with a simpler
> interface than the MGTs or similar RocketIO that can far exceed the
> general I/O data rates.
>
> Even in the lattice part, 32 channels of receive and 32 channels of
> transmit is costly in the 3Gb/s SERDES channels.
>
> - John_H

While the Lattice ECP does not have the SERDES blocks in the I/O,
you can run fairly high data rates with their DDR input flops using
the IDDRX2B "2x geared" primitive.  Only the edge clock has to
run at 1/2 the bit rate (DDR) and the internal clock runs at 1/2
of that speed (1/4 the bit rate) getting 4 bits on every rising edge.

You can see this in the 7:1 serdes reference design (I use this
for Channel-Link at 85 MHz = 595 Mbps).  I should also add
that I use LVDS for these data rates.

Regards,
Gabor

Article: 134771
Subject: Re: Format of Actel's SVF files
From: Antti <Antti.Lukats@googlemail.com>
Date: Fri, 29 Aug 2008 06:40:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 29 aug, 15:37, johannes.jan...@gmx.de wrote:
> Hi everyone,
> I have a PA3 device on a board where I want to make a quick blank
> check to decide if it's neccesary to program or not to program. I use
> a JTAG system from Goepel that uses SVF files generated by Actel. The
> guy who designed the FPGA can't get me a 'blank check' SVF or a
> shortened verify.
> What I try now is to delete as much as possible from the verify SVF I
> have to keep the time short but I'm a bit lost how to do the
> manipulations right. My idea is to use just 1-5 of the 2300 rows for
> the verify the fpga has.
> Any ideas?
> Thanks,
> Johannes

use USERCODE
and verify only that
Antti

Article: 134772
Subject: Re: Future architectures [was Re: Intel details future Larrabee ...]
From: already5chosen@yahoo.com
Date: Fri, 29 Aug 2008 06:41:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 29, 2:58 pm, MooseFET <kensm...@rahul.net> wrote:
> On Aug 28, 9:50 pm, already5cho...@yahoo.com wrote:
>
>
>
> > On Aug 28, 3:58 pm, MooseFET <kensm...@rahul.net> wrote:
>
> > > On Aug 27, 11:11 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
>
> > > > MooseFET wrote:
> > > > > On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> > > > >> Even with FPGAs the code can be quite portable. Usually quite small
> > > > >>...
> > > > > I have never seen a case of FPGA code going between Xilinx's tools and
> > > > > Altera's without some very serious rewriting.
>
> > > > Then you have something wrong in your coding style. Normally if some
> > > > portability is taken into consideration during design, porting takes
> > > > few days to get first impressions.
>
> > > I wasn't referring to just my code when I said "seen".
>
> > > Do you use the assignment of the "Z" value to cause a tri-state?
> > > Quartus doesn't compile them.
>
> > When you assign "Z" to external pin - Quartus compiles it very well,
> > thank you.
>
> Have you done it?

Of course.

> I am surprised if they have fixed it.  I had to
> recode to use the tri() to get the tri-state pins to work.  I had
> defined a component with the tristate pins that I connected directly
> to the pins of the chip.  The compiler would choke on it.  The same
> code compiled on Cypress's "warp" and produced exactly the tristated
> pin I expected.
>

Did your component had tristate pins defined as out or inout?
The later, indeed, had problems until relatively recently but the
former always worked as expected.
I, personally, always prefer to have separate in and out ports in
internal components, so I wasn't hit by earlier bugs.

Why they fixed it at the end? I think, the main reason was SOPC
builder. They wanted the same SOPC builder output to work both as a
top level project and as a component so they had little choise.
Hopefully, by now, they realized that except for the toy problems no
sane developer will use SOPC builder output as a top level but the
inout fix is done already and there are no reason to go back.

> > On the other hand, internal tristate nodes are not supported by Altera
> > architecture - how would you expect Quartus to synthesize them in this
> > case? Infer muxes?
>
> I didn't do this but yes a compiler could easily turn it into
> something like this to send to the fitter:
>
>  Y  = X1 & EN1 # X2 & EN2 # X3 & EN3;
>
> There is no need to make a full mux because there should only be one
> assignment of a non-Z value at a time and thus only one EN# would be
> true.

As I said in another post, nobody here codes this way so I have no
idea whether the compiler does the right thing.

P.S.
I added comp.arch.fpga to the list. Let's see the opinion of real
experts.

Article: 134773
Subject: Re: need fast FPGA suggestions
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 29 Aug 2008 06:44:01 -0700
Links: << >>  << T >>  << A >>
Gabor wrote:
> 
> While the Lattice ECP does not have the SERDES blocks in the I/O,
> you can run fairly high data rates with their DDR input flops using
> the IDDRX2B "2x geared" primitive.  Only the edge clock has to
> run at 1/2 the bit rate (DDR) and the internal clock runs at 1/2
> of that speed (1/4 the bit rate) getting 4 bits on every rising edge.
> 
> You can see this in the 7:1 serdes reference design (I use this
> for Channel-Link at 85 MHz = 595 Mbps).  I should also add
> that I use LVDS for these data rates.
> 
> Regards,
> Gabor

Thanks for that info!  I managed to miss that capability when I went 
through the data sheet.  It may be time for me to reread the info on the 
part I'm now designing with: an ECP2M.

The Lattice I/Os (faster speed grade, of course) are rated at 840 Mb/s 
which would need a clock of only 210 MHz for the IDDR2XB which should be 
quite capable in those devices.

The ECP2 family even has 144 pin tqfp and 208 pin pqfp packages.

That would really be a superb device for this problem.

- John_H

Article: 134774
Subject: Re: Xilinx Virtex 4 Newbie
From: Sepideh Miller <baghaii@gmail.com>
Date: Fri, 29 Aug 2008 07:02:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 26, 5:17=A0pm, "MM" <mb...@yahoo.com> wrote:
> "Sepideh Miller" <bagh...@gmail.com> wrote
>
>
>
> > How can I tell if I have the EDK?
>
> Type xps in Start/Run and click OK. See waht happens...
>
> /Mikhail

Thanks!



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