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 96050

Article: 96050
Subject: Re: Digilent FPGA & Handel-C
From: "Mahmoud" <mahmoud.kassem@gmail.com>
Date: 28 Jan 2006 20:37:00 -0800
Links: << >>  << T >>  << A >>
What are you trying to do (design)?
Why did you choose Handel-C? why not VHDL or Verilog?
Roberto wrote:
> Hi all.
> I must develop a software for a Digilent 2-SB (with chip Xilinx Spartan 2E)
> coupled with a Digilent Digital I/O 4
> I decided to use Handel-C for development , but i don't know what i must
> study to start
> I downloaded manuals for both digilent devices (only 14 pages).
> Could you counsil me any books or links for beginners?
> Thanks very much


Article: 96051
Subject: XPower- Advanced power report
From: "priya" <priya.sundararajan@gmail.com>
Date: 28 Jan 2006 20:55:15 -0800
Links: << >>  << T >>  << A >>
Hi,
 I am using XPower to do some power estimation on a design . When I
look at the advanced report I notice that the power estimation for
logic bels always turn out to be 0.1mW.
 I am doing probabilistic estimation and when I change my clock
frequency ,the total power consumed does change but this does not
change the numbers on the power consumed by the bels.

Is this an issue with xpower or do I need to do anything to get the
right numbers for power consumed by logic bels? I am using ISE 8.1i and
implemented my design on Virtex4 (4vsx25).

Thanks for all your help,
priya


Article: 96052
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: "Bob" <nimby1_notspamm_@earthlink.net>
Date: Sun, 29 Jan 2006 05:21:08 GMT
Links: << >>  << T >>  << A >>

"Erik Widding" <widding@birger.com> wrote in message 
news:1138508679.802556.42560@g14g2000cwa.googlegroups.com...
> Sean Durkin wrote:
>> I see what you're getting at. But I'd still need to supply the ISERDES
>> with a 1/3-divided clock to get a 6bit-output (this is the clock the
>> ISERDES output is registered with). That clock I don't have, I'd need to
>> use a DCM or something to generate it. The sample clock on the other
>> hand I get from the ADCs along with the data. The whole point of using
>> the ISERDES is to save on clock nets, DCMs etc., and simply use what I'm
>> supplied with.
>
> No need for 1/3 divide.  No need to use more than one clock coming back
> from the ADCs either, the sample clock.  There are two issues with
> clocking, frequency and phase.
>

You still need the /12 clock, from the ADC, in order to locate each sample 
boundary, right?

Bob

-snipped the rest-




Article: 96053
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: Sean Durkin <smd@despammed.com>
Date: Sun, 29 Jan 2006 10:20:45 +0100
Links: << >>  << T >>  << A >>
Kolja Sulimma schrieb:
> For those ADCs it is not necessary to route both the full clock and the
> 1/6 clock to the FPGA.
Of course it's not neccessary, but if that's what you're provided with,
naturally you look for ways to make it work with that, that's all I'm
saying.
At first glance, all you need to do is feed the data into two ISERDES in
master/slave mode, clock them with the fast clock, hook up the slow
clock to the CLKDV-inputs and that's it. And since the clocks you get
from the ADCs are perfectly edge-aligned, and the data is perfectly
phase-aligned, and you can use the Virtex4-IO-Clocks for everything,
theoretically there should be no need whatsoever for any phase-shifting.
Instantiate two ISERDES per channel and you're done, no need for
anything else, the perfect solution!

Now if you start looking more closely it turns out it doesn't work that
way. The whole point of the original posting was to find out if I've
missed something and you could still do it like that.

Of course there's dozens of other ways to do it, and I appreciate all of
your suggestions.

cu,
Sean


Article: 96054
Subject: 32 bit processor ? Open IP-Core
From: mmiodzio <labmm2006@yahoo.co.uk>
Date: Sun, 29 Jan 2006 11:28:12 +0100
Links: << >>  << T >>  << A >>
I want to develop driver (support for rtos system) for platform xilinx
sparten3e. I don't know which can choose 32 bit processor Open IP-Core.

Article: 96055
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: Sean Durkin <smd@despammed.com>
Date: Sun, 29 Jan 2006 11:41:25 +0100
Links: << >>  << T >>  << A >>
Erik Widding schrieb:
> No need for 1/3 divide.  No need to use more than one clock coming
> back from the ADCs either, the sample clock.
Ah, OK. I thought the ISERDES outputs were always registered with CLKDV.
I just "found" the combinatorial output. :)

> There are two issues with clocking, frequency and phase.
> 
> The frequency is not an issue because all of your ADCs and all FPGA 
> resources are receiving from the same clock source (I would hope).
Yes, but not all ADCs neccessarily run with the same sampling frequency.
At the moment I have one clock source on the board feeding the FPGA. In
the FPGA I generate the sample clocks for the ADCs. Those clocks can be
different for each ADC (meaning, it's possible I'll have one ADC running
at 70MHz, another one at 40MHz and so on; but of course the system has
to be designed for the "worst case" of 70MHz). So yes, theoretically
everything's coming from the same clock source, but it's going through
DCMs and PLLs inside the FPGA and the ADCs, and then I'm not sure about
anything anymore.

> The phase issue can be broken into two parts, one of global phase,
> and a second of bit to bit skew across the channels.  The global
> phase can be taken care of by using the sample clock output of one of
> the ADCs to feed the FPGA. 
See above, usually it has to be the other way around. OK, I can still
use the sample clocks I get back from the ADCs to run the receiving
parts in the FPGA, but that's 4 more clock nets, which I admit I have a
lot more of in Virtex-4. I've been looking at external programmable
clock sources, but up to now using the FPGA was the easiest way to do it.

> As temperature changes in the system, and
> delays on ADC and FPGA buffers change, they will change together. 
> This of course assumes that the ADCs in different discrete packages
> are subject to the same thermal conditions.
... and the FPGA is as well, which is highly unlikely. In some cases
they're not even on the same board. Or the FPGA runs hotter because it
has some other stuff to do as well.

> The issue of bit skew across all channels can be accounted for
> without the ISERDES and the delay element in the IO pin.  Your ADC
> ouputs all of the necessary test patterns to null the channel to
> channel skew.  This calibration step would be performed at power up.
Yes, that's what I'm doing at the moment, but using DCMs in Virtex2 Pro
to shift the fast clock from the ADCs.

> You will only need one DCM in the FPGA to multiply up to your bit
> clock from the single ADC sample clock, to drive the ISERDES.  This
> will also get you the proper duty cycle and phasing of the sample
> clock in the FPGA to make the suggestion in my previous post work.
> 
> You should need one DCM and two clock nets to get this working 
> regardless of the number of channels.
Well, considering the fact that I potentially have 4 different sample
clocks, I'm back at 4 DCMs and 8 clock nets, which is exactly what is
needed in the current solution. And potentially I'll have to hook up 8
or even more ADCs to one FPGA, so you see where this is going.

As I said in another post: When I first read about the ISERDES, it
seemed like the perfect thing: run it with the fast clock from the ADCs,
hook up the sample clock to the CLKDV-input, and you're done. No DCMs
neccessary, maybe a little delay-tuning here and there, that's it. And
with the IO- and regional clocks available in Virtex-4, this would've
worked for lots and lots of ADCs running at whatever frequencies.

The whole point of my original posting was to find out if there isn't
still a way to do it like that. Obviously there are lots of more elegant
ways to do it than xapp774, now that Virtex-4 is available.

But I do see that your way is probably the most elegant if all the
clocks are the same. And there are cases when I need exactly that, so
I'll probably be implementing it like that at least in some cases.

So, thanks a lot for your insight and this suggestion, it's really helpful!

cu,
Sean

Article: 96056
Subject: Re: Impact 8.1 problems with non xilinx device in chain
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 29 Jan 2006 11:44:08 +0100
Links: << >>  << T >>  << A >>
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag 
news:43dab83f@clear.net.nz...
> Antti Lukats wrote:
>> my guess about  the 3 IR bits not supported was based on fact that as 
>> soon as reverted
>> the ARM into ICE mode with longer IR register everything started to work 
>> again.
>
> .. perhaps the Atmel device itself has Bypass problems in the other mode ?
>
> -jg
>
the mode that has problems is the boundary scan mode not ICE mode
so I do not want to belive that the bypass instruction in boundary scan
mode is not implemented properly. Atmel is sure know to have weird
silicon bugs, but this time I am relatilvly sure there is no issue with
bypass instruction.

-- 
Antti Lukats
http://www.xilant.com



Article: 96057
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: Sean Durkin <smd@despammed.com>
Date: Sun, 29 Jan 2006 11:44:35 +0100
Links: << >>  << T >>  << A >>
Bob wrote:
> You still need the /12 clock, from the ADC, in order to locate each sample 
> boundary, right?
Yupp, that you would have to generate using a DCM. But the clever thing
about this is that since you're running the FPGA with the sample clock
from the ADC, and the DCM generates a perfectly edge-aligned /12 clock,
you have perfect phase relationship between all clocks and data
channels, it all fits together perfectly, regardless of the number of
channels (assuming that the sample clock is the same for all channels).

cu,
Sean

Article: 96058
Subject: Re: Digilent FPGA & Handel-C
From: "Roberto" <gioeroby@NOSPAMlibero.it>
Date: Sun, 29 Jan 2006 12:16:35 GMT
Links: << >>  << T >>  << A >>

"Mahmoud" <mahmoud.kassem@gmail.com> ha scritto nel messaggio

> What are you trying to do (design)?
> Why did you choose Handel-C? why not VHDL or Verilog?

i yet studied VHDL and i would like to study a new language as Handel-C.
Do you counsil me VHDL? why? 



Article: 96059
Subject: Re: Digilent FPGA & Handel-C
From: "Hans" <hans64@ht-lab.com>
Date: Sun, 29 Jan 2006 13:16:58 GMT
Links: << >>  << T >>  << A >>
If you have to choose a C language I would recommend you check out SystemC 
which might be better on your CV than Handel-C :-) You can download a free 
event based simulator from OSCI. The userguide contains some examples for 
VHDL/Verilog designers. I would also check out Opencores's sc2v SystemC to 
Verilog converter,

http://www.systemc.org/web/sitedocs/library_2_1.html
http://www.opencores.org/projects.cgi/web/sc2v/overview

Hans.
www.ht-lab.com

"Roberto" <gioeroby@NOSPAMlibero.it> wrote in message 
news:Dm2Df.150825$65.4246679@twister1.libero.it...
>
> "Mahmoud" <mahmoud.kassem@gmail.com> ha scritto nel messaggio
>
>> What are you trying to do (design)?
>> Why did you choose Handel-C? why not VHDL or Verilog?
>
> i yet studied VHDL and i would like to study a new language as Handel-C.
> Do you counsil me VHDL? why?
> 



Article: 96060
Subject: Re: XDL Tools wiki site
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 29 Jan 2006 13:37:21 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 29 Jan 2006 03:37:49 GMT, ptkwt@aracnet.com (Phil Tomson) wrote:

>
>I've set up a wiki space for discussion of ideas for an open source XDL tool 
>suite.  For those not familiar with wikis, they are collaborative web spaces 
>that can be edited by anyone (for now it is editable by anyone; if there are 
>problems we can restrict edit access to approved authors) or by a 
>select set of individuals.  They're used quite commonly for software projects 
>now as they are great for discussion of features, todo lists, idea boards, etc.
>
>If you had tools that could parse and programatically generate XDL how would 
>you use them?  Some suggestions have been made in other recent threads here on 
>comp.arch.fpga, now let's collect those ideas in the wikispace that I've setup 
>here:
>http://thoughtfiz.stikipad.com/XDL_Tools/

Thanks Phil...

ummm...

is there any way to access it?

it keeps asking me to login (which I don't mind, except that I don't
have an account, and there's no "register" button :-)

>There is a Feature Request page you'll see on the home page.  You can go to 
>that page and edit it or you can add comments to any page by clicking on the 
>'Discuss' link at the right hand side of the page.

well that's one "feature request" but you'll forgive me for not posting
it in the right place :-)

- Brian
(who is almost sorry for "pushing" XDL having seen what the discussion
degenerated into)

Article: 96061
Subject: Re: XDL Tools wiki site
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 29 Jan 2006 15:02:32 +0100
Links: << >>  << T >>  << A >>
"Brian Drummond" <brian_drummond@btconnect.com> schrieb im Newsbeitrag 
news:bihpt1t46dm7afskbo72gqe1qb9fi5j3c2@4ax.com...
> On 29 Jan 2006 03:37:49 GMT, ptkwt@aracnet.com (Phil Tomson) wrote:
>
>>
>>I've set up a wiki space for discussion of ideas for an open source XDL 
>>tool
>>suite.  For those not familiar with wikis, they are collaborative web 
>>spaces
>>that can be edited by anyone (for now it is editable by anyone; if there 
>>are
>>problems we can restrict edit access to approved authors) or by a
>>select set of individuals.  They're used quite commonly for software 
>>projects
>>now as they are great for discussion of features, todo lists, idea boards, 
>>etc.
>>
>>If you had tools that could parse and programatically generate XDL how 
>>would
>>you use them?  Some suggestions have been made in other recent threads 
>>here on
>>comp.arch.fpga, now let's collect those ideas in the wikispace that I've 
>>setup
>>here:
>>http://thoughtfiz.stikipad.com/XDL_Tools/
>
> Thanks Phil...
>
> ummm...
>
> is there any way to access it?
>
> it keeps asking me to login (which I don't mind, except that I don't
> have an account, and there's no "register" button :-)
>
>>There is a Feature Request page you'll see on the home page.  You can go 
>>to
>>that page and edit it or you can add comments to any page by clicking on 
>>the
>>'Discuss' link at the right hand side of the page.
>
> well that's one "feature request" but you'll forgive me for not posting
> it in the right place :-)
>
> - Brian
> (who is almost sorry for "pushing" XDL having seen what the discussion
> degenerated into)

Hi Brian,

agree 'degenerated' is a mild word for whats happened - XDL has been around 
for pretty long time and if those interested in the use of XDL have not done 
so far, well that is not the fault of Xilinx (and its license policy).

hum, as of the Phil's setup thing, it looked weird that someone is password 
login authorization protecting websites about some Open-Source discussion. 
At first I did not want to register at all, then did come back determined to 
register, but failed to register completly as there seems to be no way to 
access the pages at all :(


Antti Lukats
http://help.xilant.com/XDL:Tools






Article: 96062
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: Kolja Sulimma <news@sulimma.de>
Date: Sun, 29 Jan 2006 15:32:46 +0100
Links: << >>  << T >>  << A >>
Sean Durkin schrieb:
> And since the clocks you get
> from the ADCs are perfectly edge-aligned,
They are not.
They are out of phase between 330ps and 860ps at the ADC (according to
the datasheet). They will be more out of phase once they arrive inside
your FPGA.
You will not get away without delay buffers at these data rates.

Kolja Sulimma

Article: 96063
Subject: Re: So Xilinx, is XDL and related libraries an available open source interface?
From: fpga_toys@yahoo.com
Date: 29 Jan 2006 07:09:01 -0800
Links: << >>  << T >>  << A >>

Larry Doolittle wrote:
> > or just sit down and release the XDL formats and library
> > interfaces, along with the exposed chip architectures and
> > routing that all of the above listed projects have already
> > fully disclosed.
>
> Whoa, where did "library interfaces" come from?  Now you're talking
> software, not just documentation.  Drop that item from your wish
> list.  You'll raise fewer hackles.
>
> The "exposed chip architectures" are very sensitive to Xilinx, but
> I think they would listen to a reasoned argument that information
> of that type can not be put back in the bottle.  Too much of it is
> already out there in the patent literature, for example.

I know it's a huge mouthfull for Xilinx to swallow. But let's face it,
that just publishing the file format for XDL isn't enough. An project
that then publishes an XDL output file which would instantiate a
design, is then releasing the library interfaces and chip geometry
information. Any project that posts a synthesis tool that generates
library calls with placement/routing information would be publishing
the library interfaces and chip geometry/routing details of the device.
While some of this is in the data sheets, most of it is not.

Just documenting the XDL file format would leave nearly all the
university projects listed in violation of the EULA because of the
IP inside the XDL files themselves, and the programs which
generate/manipulate them.


Article: 96064
Subject: Re: So Xilinx, is XDL and related libraries an available open source interface?
From: fpga_toys@yahoo.com
Date: 29 Jan 2006 07:48:08 -0800
Links: << >>  << T >>  << A >>

Larry Doolittle wrote:
> While I despise terms like this in an EULA, they almost make sense
> when discussing the running software itself.  The most egregious
> consequences come from trying to apply them to documentation, as
> Xilinx's license does.

It's not just the documentation, but the intermediate files themselves,
such as the wealth of IP that can be extracted from an XDL file from
an instantiated design of any significant size. Much of that IP becomes
obscured in the bitstream, especially without the source and
intermediate
files to correlate the bitstream to.

Any project that release intermediate files which use a significant
part
of the libraries, and other IP cores, does in fact disclose IP which is
either directly usable in other non-xilinx designs, or is very easily
converted/reverse engineered, rendering the reasons behind the strict
EULA terms moot. Files which contain fully routed designs, with back
annotated timing information disclose a wealth of internal IP about
Xilinx product ... if not nearly all.

The younger generation has played fast and loose with IP now for about
a decade. Many do not take the time to read the EULA's or employment
contracts they sign, or any other legal document for that matter. I've
sat
on both sides of the table over the last 35 years, doing faculty
sponsored
security research (AKA hacking), reverse engineering, and defending my
employer/company after others breaches and claims.  This whole series
of threads has a common theme in that people do not know what the
legal requirements are that they are commited to, and frequently assume
completely contrary to the exact terms they are bound.

We see this in the vast theft of music and other IP on the internet,
and
the huge number of P2P proponents claiming it was legal to ignore
copyright restrictions against illegal "broadcasting" and
"distribution" of
music, videos, movies, and computer programs/data because there was
no profit involved, or that P2P downloading servers are different from
other
forms of pay-per-view content on demand broadcasting services. We see
in retrospect that the high court rules against P2P using the standard
that
if it looks like theft, it is theft.

We see the same theme in handling other industries IP, such as Xilinx
restricted IP. While I took a lot of heat over the JHDLBits disclosure
that
after a year, the project was held up in negotiation with Xilinx for IP
release,
is exactly an example of not negotiating the exact terms of the
licenses and
disclosure at the begining of a project rather than wading thru all the
ramifications
in difficult discussions about just what can and can not be released at
the end.

That it apparently was resolved to everyones satisfaction, which is
great, but
the lesson is to take note that these issues need to be resolved before
your
project gets a C&D letter along with a huge claim for damages from the
release
of another companies IP.

Many years ago the universities got up in arms when AT&T tried to
enforce
the proprietary interests in UNIX that were being violated by teaching
the
source code in class rooms. The issue of educational sites handling NDA
restricted material, particularly in the form of EULA's needs to be
carefully
addressed by our schools.

Here we have a long list of schools treating the IP in Xilinx's ISE
software
with the same degree of care they would a software title like Norton
Utilities.
And we have Xilinx employees advocating the same, dispite the very very
strict EULA terms. We also have the most respected posters in this
forum
doing the same.

I'm just tring to be open, honest and ethical in FpgaC's handling of
this
Xilinx IP - which in order to get equal access as all these other
projects
means confronting the issues and hopefully getting Xilinx to realize
the
cat is way out of the bag, isn't likely to be going back in, so we
should
look at the defacto state of their IP and adjust the licenses to
reflect
actual use -- or do the very nasty thing of sending everyone C&D
letters
and forcing all these schools to treat the Xilinx IP with the degree of
care the EULA requires.

The kill the messenger reality is a bit tough sometimes ...


Article: 96065
Subject: Re: C to FPGA Tools (Impulse C and others) and necessary trig IP
From: fpga_toys@yahoo.com
Date: 29 Jan 2006 07:54:18 -0800
Links: << >>  << T >>  << A >>

Simon Peacock wrote:
> This is also true.. but that is NOT what a C programmer calls C code ;-)
> If you are going to write Boolean equations in C then you might as well use
> one of the "official" languages as others can help.
> my two cents :-)
>
> Simon
>
> P.S. I didn't see any sin functions :-)

Sorry ... but the arithmetic functions in every synthesis tool are
reduced to
the boolean equations too ... FpgaC included. My point is that C based
HLL's, or even the HLL versions of them, can do just as good a job at
both
the boolean's and the arithmetics, as you will see in VHDL doing
arithmetics.

Nope .... but didn't you get the point that better arithmetics are on
the list
of development projects for FpgaC?  And that working with someone to
implement them in a useful way would just add to the value of FpgaC?


Article: 96066
Subject: Re: EDK 8.1 ... delay
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Sun, 29 Jan 2006 16:26:22 -0000
Links: << >>  << T >>  << A >>
Well I just started the download so I think it is really there. I'll know 
for definate in about 2 hours. I got the notification on the 20th Jan and I 
don't think we are on the advanced list for distribution. As with any of the 
major vendor software releases I would ideally wait for a service pack or 
two to be released before use on a really critical project. However if it 
has features you need today then go ahead and hope that the internal 
distribution that goes on Xilinx, before release, has picked up the major 
bugs.

John Adair
Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development 
Board.
http://www.enterpoint.co.uk

"Eric Smith" <eric@brouhaha.com> wrote in message 
news:qhy811jiqo.fsf@ruckus.brouhaha.com...
> John Adair wrote:
>> EDK 8.1 is available from late last week to existing customers by the
>> download mechanism.
>
> I just spoke to someone in Xilinx Customer Service, and she said that
> although they had expected the official release of EDK 8.1 to occur this
> past Monday, that apparently it did not, and she's not sure when it will
> be.
>
> The same thing happened with ISE 8.1; some customers were able to
> download it before the official release, but others were not.
>
> It seems reasonable to expect that the official release will occur
> soon.
>
> Eric 



Article: 96067
Subject: Competition to win Raggedstone1 RS1-1500 Spartan-3 FPGA Board
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Sun, 29 Jan 2006 17:13:16 -0000
Links: << >>  << T >>  << A >>
For all of those that have asked me "can you make us one" here is your 
chance to win one. The Raggedstone1 RS1-1500 special is only available under 
certain circumstances and not normally sold as a one off product so we're 
not selling it but giving it away it.

Competition details are here 
http://www.enterpoint.co.uk/competition/comp1_7_3_2006.html . Entries by 5th 
March 2006.

John Adair
Enterpoint Ltd. - Home of Raggedstone1. The $90 Spartan3 Development Board.
http://www.enterpoint.co.uk



Article: 96068
Subject: Re: So Xilinx, is XDL and related libraries an available open source interface?
From: fpga_toys@yahoo.com
Date: 29 Jan 2006 09:47:23 -0800
Links: << >>  << T >>  << A >>

Larry Doolittle wrote:
> That's a long list.  I should spend more time with Google.

Yep ... it's almost temping to spend a few days in Google, print out
all the projects, highlite all the infringements, and send them to
Xilinx legal.

I understand that any trade secret or proprietary interests that Xilinx
then chooses to leave in the public, by not acting with due diligence
to protect, would fall into the public domain (if it hasn't already).
They would still have copyright on all the materials, but fair use
under copyright would allow full access to "interfaces" and just being
able to use, discuss, and program in support of the product without the
very restrictive EULA interference. This would allow public
documentation of the interfaces for all objects viewable from the
intermediate ISE files, in addition to what was already openly
documented in the ISE manuals.

That would certainly greatly open the field for open source development
to augment the Xilinx tool chain.

E.I. duPont deNemours & Co., Inc. v Christopher, 431 F.2d 1012 (5th
Cir. 1970), cert. denied, 400 U.S. 1024 (1971). is the citation
normally used to describe this. The bottom line is that if they do not
take every step to protect their rights in trade secrets, that right
will be denied, and all claimed rights will be forfeited. Thus it would
be fair game for open source development to fully use any and all
information found both in ISE and all the university projects that
contain this information as well, as the foundation in the ISE EULA
would be completely breached.


Article: 96069
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: "Bob" <nimby1_notspamm_@earthlink.net>
Date: Sun, 29 Jan 2006 18:24:32 GMT
Links: << >>  << T >>  << A >>

"Sean Durkin" <smd@despammed.com> wrote in message 
news:443kkjF6j7sU1@individual.net...
> Bob wrote:

>> You still need the /12 clock, from the ADC, in order to locate each 
>> sample
>> boundary, right?

> Yupp, that you would have to generate using a DCM. But the clever thing
> about this is that since you're running the FPGA with the sample clock
> from the ADC, and the DCM generates a perfectly edge-aligned /12 clock,
> you have perfect phase relationship between all clocks and data
> channels, it all fits together perfectly, regardless of the number of
> channels (assuming that the sample clock is the same for all channels).
>
> cu,
> Sean

Simply dividing the sample clock by 12 (using a DCM) doesn't give you the 
boundary of the 12bit sample. You only have a one-in-twelve chance of 
getting it right. There is no way to deduce the sample boundary by 
inspecting the serial data stream.

Bob 



Article: 96070
Subject: Re: tristate to logic conversion
From: wtxwtx@gmail.com
Date: 29 Jan 2006 10:46:54 -0800
Links: << >>  << T >>  << A >>
Hi John,
"But it's never good design practice to have tristates with multiple
sources; "

I disagree with your opinion.

Tristate gates are used everywhere in an ASIC chip with no exception of
FPGA. BLOCK RAM in Xilinx chip has to use tristate to get the selected
data to output.

In my opinion, there are two types of tristate buses:
1. Passive. It works well for interrupt system. If one of sources is to
assert, it pulls down the bus. If it is to deassert, tristate the
output and leave the bus to return high state by a pullup. It cannot be
used for fast data transactions.

2. Active. It works well for any multiple mutually exclusive sources to
drive a data bus. The example is BLOCK RAM in Xilinx FPGA. In a normal
FPGA design, the tristate bus can be safely used for the last stage of
data output. This type of tristate buses is active because only one
source drives the data bus at each clock, either high or low, there is
no limit on its driving data.
In my many designs, tristate data bus for the last stage of data
outputs is much better than combinational logic.
I will do a comparison between a tristate bus and its logic equilance
for Xilinx chip to see if there is any impact on the performance. I
have been always using tristate bus for my last stage of data outputs.

By the way, there is an patent from Xilinx: 5,677,638 "High Speed
Tristate Bus with Multiplexers for Selecting Bus Driver". It deals with
what you want to know. One trick is you always can find the most secret
or core technology of Xilinx by reading their patents. All patents must
meet a requirement that can be implemented by people in the art. We
always belong to the people in the art.

In my opinion, there are many smart and brand new ideas imbedded in the
1100 patents of Xilinx that give you many lessons, teaching and
experiences that couldn't get from college or textbooks, but they also
expose many points that can be further improved.

Altela seems to adopt another type of strategies and tries to keep its
secrets as  commercial ones. Recently Alterla has gotten few patents. I
don't know why. 

Weng


Article: 96071
Subject: Re: tristate to logic conversion
From: John_H <johnhandwork@mail.com>
Date: Sun, 29 Jan 2006 19:17:03 GMT
Links: << >>  << T >>  << A >>
wtxwtx@gmail.com wrote:
> Hi John,
> "But it's never good design practice to have tristates with multiple
> sources; "
> 
> I disagree with your opinion.

If an unseasoned engineer is developing code or if the code can be 
targeted by engineers months later into an architecture where the 
tristates are no longer "equivalent" tristate functionality, problems 
may arise.  The tools will not exclude two drivers active at once.  The 
new architecture with the real internal tristate might go pfffft.  To 
Dominik's credit (the original poster) he's trying to find out about the 
less-than-clear practice of synthesis providing tristate emulation.


Careless use of tristates is especially bad if a later retargeted 
architecture is an ASIC.

If you know everything you're getting into, tristates with multiple 
*simultaneous* sources is fine but the code can't be moved to an 
architecture where the internal tristate bus contention will fry the 
device (any implementation with one source active at a time is fine, but 
multiple active drivers is not - perhaps this nuance wasn't communicated 
well before).

As I stated in the original reply, I indeed designed a 
multiple-simultaneous-source tristate bus in the FPGA architecture where 
the behavior of the tristate emulation was very clear.  It would not be 
good design practice to do this willy-nilly but only to do it when it's 
guaranteed there will be no disasterous side effects now or for other 
engineers later.

And as you pointed out, it is just my opinion.

- John_H

Article: 96072
Subject: Acquiring video frames and processing pixels in Xilinx
From: nitul.das@gmail.com
Date: 29 Jan 2006 11:50:01 -0800
Links: << >>  << T >>  << A >>
Dear Friends.

Well i am quite new to this FPGA thing...My project is on Video
Compression and i want it to implement in Xilinx platform.

I am finding really difficult in acquiring the video frames and is it
possible to do it in simulator mode( AND NOT REAL TIME......!)??. It
would be really helpful if anybody could guide me.

I have the latest Xilinx ISE 8.1i..is this platform sufficient or do i
need something else?? please guide someone..it is really important.


Article: 96073
Subject: Re: Connection between FSL and XCL
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Mon, 30 Jan 2006 08:41:10 +1000
Links: << >>  << T >>  << A >>
Marco T. wrote:

> Hallo,
> Is it possible to connect a FSL peripheral to a XCL channel of Xilinx 
> Multi-Channel Sdram Controller?
> 
> I would read data from memory and send it out the fpga.

Yes, this should be fine.  The signal interface is identical, you just
need to make your FSL peripheral talk the XCL protocol.  See pp 51-54 of
the MicroBlaze refernce guide.

Regards,

John



Article: 96074
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: "Brian Davis" <brimdavis@aol.com>
Date: 29 Jan 2006 15:51:30 -0800
Links: << >>  << T >>  << A >>
Sean Durkin wrote:
>
> Sounds good, but the half-rate logic would still be running at 210MHz
> in my case. I need more deserializing, need to make it slower :)
>
 Once you have the DDR data reclocked successfully off the local
clock domain onto your global clock, you can use a straightforward
demux to lower the data rate as much as you'd like, generating the
lower rate clock with a DCM; those V4 phase-matched-divider widgets
could probably be used in place of a DCM for the sub-rate clock.

 Your original post seemed to be looking for a method of obtaining
complementary internal output signals from only one LVDS input pin.

 I was trying to point out that that capability already exists in the
V2 derived parts, and most likely in V4 as well (esp. with the V4
differential clock tree, I'd expect one to get inverted clocks for free
with no local inversion skew penalty, but I haven't checked this yet).

DDR clocking notes:

  One tricky bit on V2, getting that same local clock on a global
clock network, is made easier in S3E by provision for local clock
pins to drive the global clock network; I'd expect that something
similar exists in V4.

 Another DDR clock alternative in V2 is to use an IBUFGDS_DIFF_OUT
to directly drive your 0/180 DDR clocks without getting a DCM involved.

A/D Clocking notes:

 You seem to be saying in another post that you source variable rate
A/D sample clocks directly from the FPGA; perhaps I misunderstood
that post.

  Clocking high speed A/D's with an FPGA generated clock is a very
bad idea, as the inherent DCM & SSO jitter will quickly render the
sub-ps RMS A/D aperture jitter specs useless, giving you maybe
a handful of effective bits worth of data at the rated A/D input
bandwidth.
 
Brian




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