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 96025

Article: 96025
Subject: Re: Lattice high end FPGAs to be announced soon
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 28 Jan 2006 10:09:11 +0100
Links: << >>  << T >>  << A >>
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag 
news:43dab9ea$1@clear.net.nz...
> Antti Lukats wrote:
>
>> Hi all
>>
> <snip>
>> also coming are are sub 3 (and even sub 2) USD low cost small package 
>> versions
>> of the power supply monitor and supervisory circuits
>
>  These needed to come down in price - at the silly prices they were,
> they were never going to hit mass support - just the odd VHDL designer who 
> was unable to get a small uC and a couple of FETs to do the same thing.
>  The newest tiny system uC, like the Tiny2313, newest ST7 lite, and
> Atmel LP216, are all in the 80c region, and you keep getting more for
> your 80-90c....
>
>  All Lattice needs now, is to work out how to turn a profit :)
>
> -jg
>

yes you right, the power managers (PawerManager II - 7USD) are too 
expeensive
so thats why they have planned products priced below 2 USD for that market. 
well
lets see if they actually come, hum but I dont think the lattice 
powermanaers will drop
below 1 USD in price so they can miss the bottom high volume market again,

Antti 



Article: 96026
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: Sean Durkin <smd@despammed.com>
Date: Sat, 28 Jan 2006 10:17:30 +0100
Links: << >>  << T >>  << A >>
Brian Davis wrote:
>  I've sucessfully done this sort of thing in V2-ish parts using one
> of the nifty _DIFF_OUT buffers ( or hand built equivalent) to create
> complementary local clocks to the DDR IOB registers (XAPP609),
> with the next CLB register stage constrained only by a MAX_DELAY,
> and the DCM clocks only used for the half rate logic.
First of all, typo in the original posting: it's 840MBps, not 480Mbps I
have to deal with.

Then on to your suggestion:
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 :)

The thing is that the ADC sends out a 420MHz clock and a 70Mhz clock
along with the data. So obviously this is designed so that you run some
deserializing circuit with the 420MHz, and clock out the parallel data
with the 70MHz clock. Plus, you'd do the rest of the processing in the
FPGA with the 70MHz, which is easily handled.

>   This makes it fairly easy to hit IOB DDR timing without needing
> any funky DCM phase shift delay calibration logic, only LOC's on
> the I/Os to the proper local clocking region.
The latter is the biggst constraint. In the first board we did, the clocks
weren't connected to the local clocking pins. But even if they were, at
840Mbps (sorry, typo in the original posting, it's 840, not 480!), I
still needed to do some calibration in every case. At these speeds
you're already getting problems if the traces on the board aren't
closely matched. I could never get it to work reliably (i.e. considering
temperature drift etc.) without phase-shifting and re-calibration from
time to time.

>  At 480 Mbps, I'd advise sticking with LVDS & DT terminators.
That's what I thought.

cu,
Sean

Article: 96027
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: Sean Durkin <smd@despammed.com>
Date: Sat, 28 Jan 2006 10:42:43 +0100
Links: << >>  << T >>  << A >>
Erik Widding wrote:
> Use the ISERDES setup you describe here to get 6 bits at a time.
> Really quick pseudo code for a solution:
> 
>    signal left : std_logic_vector ( 5 downto 0);
>    signal sample : std_logic_vector ( 11 downto 0);
> 
>    if ( falling_edge( sample_clock ) ) then
>       left <= ISERDES_out(5 downto 0);
>    end if;
> 
>    if ( rising_edge( sample_clock ) ) then
>       sample <= left && ISERDES_out(5 downto 0);
>    end if;
> 
> Sample clock needs to be properly phased to the ISERDES output, and a
> timing constraint with 1/2 the period of sample_clock is placed between
> ISERDES_out and the two destination registers.  The tools will take it
> from here.
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.

cu,
Sean

Article: 96028
Subject: Re: open source fpga programmer programs
From: "Jerry Coffin" <jerry.coffin@gmail.com>
Date: 28 Jan 2006 01:45:21 -0800
Links: << >>  << T >>  << A >>
dp wrote:

[ ... ]

> The number of things which can be done is probably infinite. However,
> programmability is a major feature of programmable devices - or at
> least I naively thought so until today :-).

Oh, it certainly is.

His point (and I agree that it's valid) is that sometimes things that
need changing aren't in the FPGA itself. Just for example, if you
decide to add some sort of extra I/O to some hardware, you're typically
going to need some sort of physical connection. Putting an Ethernet MAC
into your FPGA is pretty straightforward, but won't do much good
without the physical hardware to allow the user to connect his Ethernet
cable.

That particular change would really be in design scope rather than
indicating a defect in the implementation though. Perhaps a more
reasonable example would be that the design had Ethernet all along,
with the MAC on the FPGA, but the PHY as a separate chip. A problem in
the PHY chip might be curable by changes in the FPGA.

At the same time, a lot of ancillary chips like this tend to have
relatively simple requirements, reducing the likelihood of subtle
problems in their designs -- and sometimes even if there is a problem
in such an ancillary chip, you can assure against putting it into the
situation where the error arises.

-- 
    Later,
    Jerry.


Article: 96029
Subject: Re: Debugging Spartan3 slave serial configuration
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 28 Jan 2006 11:01:43 +0100
Links: << >>  << T >>  << A >>

"Yaju Nagaonkar" <yaj_n@hotmail.com> schrieb im Newsbeitrag 
news:1138412013.300497.46010@o13g2000cwo.googlegroups.com...
>I am not yet done with my debugging yet, but thought would find out if
> anyone out has experimented with slave serial configuraiton of
> Spartan3.
>
> Here is the setup on my PCB board.

1) you can use impact to query the configuraton status after your config 
attempt, as example you can see if there was CRC error, etc. but my bet it 
only say init ok, done = 0

2) make sure you have startupclock set CCLK

3) if in doubt reverse bit order in bytes

4) send some more dummy bits after end

I am using mega8 to load Spartan3 and virtex4 over JTAG from SD-Card and I 
have no problems. slave serial is even simpler to implement, just send the 
.BIT file into DIN and that should do it

note that INIT will not flag error if the proper signature is never seen

Antti 



Article: 96030
Subject: Re: [OT]Re: encryption
From: Allan Herriman <allanherriman@hotmail.com>
Date: Sat, 28 Jan 2006 21:40:38 +1100
Links: << >>  << T >>  << A >>
On Fri, 27 Jan 2006 11:20:42 +1000, John Williams
<jwilliams@itee.uq.edu.au> wrote:

>You know, there's just not enough talk about cricket on comp.arch.fpga.
>
>Perhaps a new group - comp.arch.fpga.cricket?
>
>John (who travels past the 'Gabba every day on the way to work...)

I walk out my front door and I look at the MCG.

Regards,
Allan

Article: 96031
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: Kolja Sulimma <news@sulimma.de>
Date: Sat, 28 Jan 2006 11:45:54 +0100
Links: << >>  << T >>  << A >>
Sean Durkin schrieb:
The whole point of using
> the ISERDES is to save on clock nets, DCMs etc., and simply use what I'm
> supplied with.

The point of the ISERDES is to meet timing that you would not with a LUT
 based SERDES.

The point of the IO delay lines is to save DCMs and clock nets. Without
them you would need a DCM per ADC anyway to do the phase alignement,
even if you could use the frequency 1:1.

Kolja Sulimma

Article: 96032
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: Kolja Sulimma <news@sulimma.de>
Date: Sat, 28 Jan 2006 11:47:54 +0100
Links: << >>  << T >>  << A >>
Sean Durkin schrieb:

> The thing is that the ADC sends out, along with the data, a fast clock
> and a 6x slower clock. If you run the ADC at 70MHz, it sends back a
> 420MHz clock and a 70MHz clock. The whole thing is designed so you use
> the 420MHz to clock some sort of deserializing-circuit and the 70MHz to
> clock out the parallel data and do your processing. So that's the
> "intended" way to handle this, and of course you'd first look for a way
> to do it with what you're provided with.
>
> Now, since one single ISERDES doesn't handle DDR, it would have to be
> run at 840MHz, plus I'd need to waste a DCM to double the clock (can
> they even get up to 840MHz?) I get from the ADC. No way. Alternatively,
> I could use two ISERDES in Master-/Slave-Mode (then they can handle DDR)
> to output two 6bit-nibbles, as you suggested. But to get these out, I'd
> have to have a 140MHz clock, which I don't have. Again, waste a DCM to
> generate it. And since I normally have 4 of those ADCs hooked up to one
> FPGA, that's 4 DCMs gone already, in addition to the 4 I need to do
> phase-shifting anyway. That's 8 total, which is probably every single
> one available in the devices I have available. Again, no way.
>
> The whole point of using the ISERDES in the first place is to save on
> DCMs, clock nets and hand-placed components, to make do with what is
> readily available.
>
> I still don't see where the ISERDES would make anything easier.

For those ADCs it is not necessary to route both the full clock and the
1/6 clock to the FPGA.

You have a phase shift in every pin of virtex-4, use that to do your
phase alignement.
If a DCM can go to 840 MHz with clock FX you can get the 840MHz, 70MHz
and 140MHz for all ADCs out of a single DCM.

If it can not you can use an ISERDES in master slave mode to get 2x3=6
bits still using only one DCM total for an unlimited number of ADCs.

Kolja Sulimma

Article: 96033
Subject: Re: open source fpga programmer programs
From: fpga_toys@yahoo.com
Date: 28 Jan 2006 03:05:43 -0800
Links: << >>  << T >>  << A >>

Jerry Coffin wrote:
> His point (and I agree that it's valid) is that sometimes things that
> need changing aren't in the FPGA itself. Just for example, if you
> decide to add some sort of extra I/O to some hardware, you're typically
> going to need some sort of physical connection. Putting an Ethernet MAC
> into your FPGA is pretty straightforward, but won't do much good
> without the physical hardware to allow the user to connect his Ethernet
> cable.

Actually, I tend to run unused I/O's to a header very close to the Fpga
that can take a daughter card. This does allow for easy external
additions after the project is "done".


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

Simon Peacock wrote:
> I think you are taking the wrong approach.  I'm sure you can get the C code
> running.  But in reality if you have to implement sin/cos & sqrts, then the
> C code will be far from optimal, and you might need a vertex to do the job
> of a Spartan

Actually, I find it not that different in many cases from similar
VHDL/Verilog
and have the advantage of being able to tweek the output in FpgaC when
I don't like it. Especially when I do a boolean design, it goes right
thru FpgaC
as boolean logic equations to the LUT. The C may look a bit ugly that
way, but
you certainly have nearly exact control over the output. For example:

[jbass@fastbox tests]$ cat example1.c
int a:1,b:1,c:1;
#pragma inputport (a,a9)
#pragma inputport (b,a10)

int sum_of_products:1;
#pragma outputport (sum_of_products,a11)

main()
{

        c = (sum_of_products = (a&b) + c);
}


produces:

[jbass@fastbox tests]$ fpgac -target cnf example1.c
[jbass@fastbox tests]$ cat example1.cnf
_example1_Running^CLK = VCC;
_a^CLK = port(_a,"a9");
_b^CLK = port(_b,"a10");
_c^(CLK*_example1_main__state_C1) = (~_c*_b*_a)+(_c*~_a)+(_c*~_b);
port(_sum_of_products,"a11")^(CLK*_example1_main__state_C1) =
(~_c*_b*_a)+(_c*~_a)+(_c*~_b);
_example1_main__state_C1 = ~_example1_Running;


which in xnf/edif is a bit more verbose (so I'll just take the meat of
it):

SYM, _sum_of_products-OBUF, OBUF
PIN, I, I, _sum_of_products
PIN, O, O, sum_of_products
END
EXT, sum_of_products, O,, LOC=_a11
SYM, FFin-_sum_of_products, EQN, EQN=((~I0*I1*I2)+(I0*~I2)+(I0*~I1))
PIN, I2, I, _a
PIN, I1, I, _b
PIN, I0, I, _c
PIN, O, O, FFin-_sum_of_products
END
SYM, _sum_of_products, DFF
PIN, D, I, FFin-_sum_of_products
PIN, C, I, CLK
PIN, CE, I, _example1_main__state_C1
PIN, Q, O, _sum_of_products
END


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

Larry Doolittle wrote:
> Second concern: can open source software be published that
> works with XDL?  IANAL (honest), but we have to look at this
> from a lawyer's perspective.  On the open source side, we
> have "The Open Source Definition"

The answer unfortunately is that the EULA NDA restrictions and
open source are mutually exclusive. The EULA NDA is so resrictive
that you can not even talk to anyone about your "performance" with
the experience as benchmarking includes everything from bugs, to
comparitive results, to non-comparitive objective results.

Because the EULA is a contract between you and Xilinx, it even
prempts the normal rights you would have if the same information
was in a book that you could purchase in a public book store.

This is made obvously clear when the EULA prohibts benchmarking,
and goes right to the core of even being able to talk about the product
in specific details.

Any expectations about fair use, or rights under copyright law just
vanish.


Article: 96036
Subject: Re: So Xilinx, is XDL and related libraries an available open source interface?
From: fpga_toys@yahoo.com
Date: 28 Jan 2006 03:50:46 -0800
Links: << >>  << T >>  << A >>

Larry Doolittle wrote:
> That will generate a legal flap akin to deCSS, and
> unfortunately will cause Xilinx to reconsider its public
> XDL support.

In another thread I pressed Austin for an answer which he said his
reading (as does yours and mine) is that the EULA prohibts open source.

I've updated the FpgaC users manual to include this, and asked Austin
for his input, which he declined ... not a suprise as it gets too close
to
legal, which is where probably where he forwarded my request.

Given the obvious conflict this creates in the Xilinx developers
community
with open source, the company legal department really needs to make a
clear an definative statement that is given to rank and file Xilinx
Staff so
that they may avoid miss-representing the current legal state, and have
the guidance to communicate that clearly to customers.

Another Xilinx employee, Ed McGettigan saying that copyright law
protects
you from the EULA, there clearly is a unified message problem from
Xiinx
that could very unfairly trap open source developers in a legal fight
with
Xilinx.

John

> From jbass Fri Jan 27 14:59:57 2006
> To: austin.lesea@xilinx.com, jbass
> Subject: Need your review and suggestions

Hi Austin,

The following text has been added to the FpgaC user manual, to call
attention to the Licensing restrictions involved. I hope this fairly
and accurately documents the challenges we currently face working
with the Xilinx EULA.

Please feel free to make or suggest any changes that you feel would
better describe the current problems, and better support Xilinx and
your customers. FpgaC would like this to go well for both our project
and Xilinx.

Thanks,
John Bass

-------------------------------------------------------------------

Interfaces to newer FPGA's

The current vendor interfaces are ones we picked up from TMCC, so
that project did the footwork for vendor acceptable interface points.
In the 10 years since, the vendor tool chains have significantly
changed. Xilinx no longer supports XNF as a netlist format, and has
not provided a publicly documented replacement for it which interfaces
to the newest FPGAs.

While we can use EDIF to some extent as a netlist input source, what
we don't have access to is a legal description of all the library
system blocks and macros to instantiate in the EDIF netlist for newer
devices.  Those library interfaces are documented inside ISE and
subject to the ISE End User License Agreement which contains a strict
Non-Disclosure agreement blocking open source use of the library
information. We can blindly use the older known library blocks to the
exent they are mapped to EDIF, but we do not have access to any of the
newer library blocks and macros as implemented for Virtex-II Pro and
Virtex-4 parts.

There is a new XDL interface which is a very attractive interface point
for FpgaC, which Xilinx now would like 3rd parties to use. However, the
documentation for XDL and the device libraries is restricted with an
NDA
which is incompatable with open source licenses. Implementing those
interfaces in open source C code, would in fact publish them to the
world
in violation of NDA restrictions, so they are currently off limits for
FpgaC.

When asking Xilinx staff what public interfaces are currently legal for
FpgaC to use to import netlists into the ISE tool chain, this question:

    "But that aside, the question remains, just what, if any,
     legal interfaces may open source software use to augment
     the ISE tool chain?  The strictest reading of the license
     and NDA is clear ... NONE."

Gets this reply from Austin Lesea of Xilinx:

    "I am not a lawyer.

    "But it seems clear to me, when I read it: the answer is "none."

    "To imply otherwise is clearly misleading, and could be interpreted
as
     intentionally causing harm (to Xilinx, or its partners, or its
customers)."

So, we need to lobby Xilinx to provide a usable open source entry point
into their ISE and ISE WebPack tool chains that does not violate open
source restrictions or the NDA's in the Xilinx Licenses.  Needed is a
publicly documented netlist format, such as XDL, and a set of publicly
documented library interfaces that we can call out to instantiate all
library blocks and macros for each device family, including the device
geometries for LUT's, CLB's, and other on chip objects to faciltate
FpgaC guided placement decisions or externally providing placement and
some routing information to the backend ISE tools for bit stream
generation.

Anyone providing Xilinx specific code for FpgaC needs to explore these
license issues, and make sure that we do not violate either the Xilinx
Intellectual Property (IP) rights, or the open source license(s).
Written
releases, or documented public interfaces, are required, not just for
Xilinx, but all FPGA vendor's IP.

I have been told, but have not personally explored, that we face very
similar problems with Altera. If someone could provide similar details
for their product lines and tool chains it would be greatly
appreciated,
as I do not hold a license for all the required Altera tools.

It has been suggested that some of the smaller FPGA companies are much
more eager to get open source support for the product lines, and we
will
actively support each of those that we can.  If your favorite vendor
doesn't have a support path included in this release, let the FpgaC
project team know, and we will set up a project to get them supported
as soon as possible.


Article: 96037
Subject: Re: [OT]Re: encryption
From: p.kootsookos@remove.ieee.org (Peter K.)
Date: 28 Jan 2006 09:31:31 -0500
Links: << >>  << T >>  << A >>
Allan Herriman <allanherriman@hotmail.com> writes:

> 
> I walk out my front door and I look at the MCG.
> 

When the rain doesn't obscure it.... :-)



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

Larry Doolittle wrote:
> [*] No, I don't think the ISE license is, or should be, OSD-compliant.
> The discussion here is whether code that I write, based on the
> documentation given in ISE, can be released under an OSD-compliant
> license, like BSD or GPL.

The question goes far past that. Consider the BYU JHDL has XDL
interfaces in
it. As does the University of Massachusetts VPR for Virtex + JBits
Interface
project built on top of the University of Toronto work. Besides the VPR
work
at UofT, several other projects like EVE have XDL interfaces as well.
As
does the UC Berkeley work for Post-Placement C-slow Retiming.  As does
Peter Sutton's work JPG - A Partial Bitstream Generation Tool  to
Support
Partial Reconfiguration in Virtex FPGAs" at UQ Australia. As does the
DAGGER work done at universities in Greece. The MIT team doing 3-D Fpga
architecture research was using it. The French researchers at IRIAS are
doing FPGA array layouts with it. As is research and thesis work at
Lund Institute of Technology, Sweden in dynamic reconfiguration. As is
research and thesis work at Virginia Polytechnic Institute. As is
research
and thesis work at Seoul National University, Korea. As is research
work
at Pennsylvania State University. As is research and thesis work at
UCLA.
As is research and thesis work at Stanford. ... and the list goes on,
and on.

Many of these projects have released source and documentation which
has XDL formats and xilinx device interfaces embedded.

In searching, we also find that XDL is discussed in class room
lectures, and
is the subject of class exercises.

Many of these projects describe XDL as an open interface, and treat if
freely
as such. That is clearly stated in many places including the Xilinx/BYU
work
for Los Alamos SEU project. Some of these projects include Xilinx
co-authors.

So, clearly the cat is out of the bag, and Xilinx should either
properly protect
it's IP, 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.


Article: 96039
Subject: Digilent FPGA & Handel-C
From: "Roberto" <gioeroby@NOSPAMlibero.it>
Date: Sat, 28 Jan 2006 16:02:19 GMT
Links: << >>  << T >>  << A >>
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: 96040
Subject: Re: So Xilinx, is XDL and related libraries an available open source interface?
From: Larry Doolittle <ldoolitt@localhost.localdomain>
Date: 28 Jan 2006 08:25:14 -0800
Links: << >>  << T >>  << A >>
[Pardon me while I partially mix threads, I blame it on an erratic
news server.  So I'm using one article as a surrogate to paste in
comments I retreived via Google.  So while the author attributions
are correct, the text doesn't come from the articles listed in the
header.]

On 2006-01-28, fpga_toys@yahoo.com <fpga_toys@yahoo.com> wrote:
>
> Larry Doolittle wrote:
>> Second concern: can open source software be published that
>> works with XDL?  IANAL (honest), but we have to look at this
>> from a lawyer's perspective.  [chop]
>
> The answer unfortunately is that the EULA NDA restrictions and
> open source are mutually exclusive. The EULA NDA is so resrictive
> that you can not even talk to anyone about your "performance" with
> the experience as benchmarking includes everything from bugs, to
> comparitive results, to non-comparitive objective results.

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.

> Consider the BYU JHDL, [chop] University of Massachusetts VPR, [chop]
> UC Berkeley['s] Post-Placement C-slow Retiming, [chop]  Peter Sutton's
> JPG, [chop] Greek universities [unspecified] DAGGER, [chop] IRIAS
> FPGA array layouts, [chop, plus] research and thesis work [in
> Sweden, VPI, Seul, Pennsylvania State, UCLA, Stanford, all of which
> use XDL].

That's a long list.  I should spend more time with Google.

> Xilinx should either properly protect it's IP,

By pulling its head out of the sand, sending C&D letters to all
of the above projects, and posting a FAQ (oops, "answer record")
saying "No, you can't publish code that speaks XDL because of the
terms of the ISE EULA".

> 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.

>> One way to [resolve the confusion is for] Xilinx to post the
>> XDL documentation on-line.  Why isn't it already in the "Xilinx
>> ISE 8 Software Manuals and Help"?  Or maybe it is, and I'm just
>> too blind to see it?

I searched more fully, it's not there.  And posting the material
(obviously NDA-free, unlike the ambiguous stuff in the ISE download)
would quickly end this discussion.  I have to assume Xilinx would
like that result.

           - Larry

Article: 96041
Subject: Re: HOW CAN I USE OPB EMC
From: Duane Clark <dclark@junkmail.com>
Date: Sat, 28 Jan 2006 17:22:30 GMT
Links: << >>  << T >>  << A >>
shane wrote:
> hi
> 
> Thanks for replying
> 
> iam using microblaze for first time so please bear with my questions
> 
> iam using data width for flash device as 8 but does opb emc support
> data width matching for flash devices?

There is a section in the opb_emc document entitled "Data-Width Matching 
for Flash Memories".

> 
> if it does support, updating the settings of system.mhs file takes
> care of it or do i need to change any other settings

If you are using the GUI tools, them I don't know whether changes made 
in the system.mhs file will get overwritten. I don't use the GUI, so I 
make all changes by editing that file, and that is the only place 
changes need to be made.

> 
> wat values should i use for these parameters C_THZCE_PS_MEM_0,
> C_TWP_PS_MEM_0 ,C_TCEDV_PS_MEM_0, C_TAVDV_PS_MEM_0, C_TWC_PS_MEM_0

You need to look at the data sheet for the flash you are using, and 
compare that to the definitions in the opb_emc data sheet. The values I 
gave as an example are only good for that particular flash.

Article: 96042
Subject: Serial flash configuration with "Xilinx platform cable USB"
From: "Alexander Werger" <awerger@web.de>
Date: Sat, 28 Jan 2006 18:59:02 +0100
Links: << >>  << T >>  << A >>
Hi,
sorry for a newbe question:
Is there any description how to progam the configuration memory (Atmel 
AT45DB161B) on a Memec Virtex4 LC development board using the Xilinx 
platform cable USB.
On the board's description there is how to program the serial flash by a PC4 
cable, simlar to Xilinx xapp800.
Is there any description how to do the same with the "Xilinx platform cable 
USB"?

Many thanks,
Alex






Article: 96043
Subject: Re: Serial flash configuration with "Xilinx platform cable USB"
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 28 Jan 2006 19:50:54 +0100
Links: << >>  << T >>  << A >>
"Alexander Werger" <awerger@web.de> schrieb im Newsbeitrag 
news:drgbd7$utt$03$1@news.t-online.com...
> Hi,
> sorry for a newbe question:
> Is there any description how to progam the configuration memory (Atmel 
> AT45DB161B) on a Memec Virtex4 LC development board using the Xilinx 
> platform cable USB.
> On the board's description there is how to program the serial flash by a 
> PC4 cable, simlar to Xilinx xapp800.
> Is there any description how to do the same with the "Xilinx platform 
> cable USB"?
>
> Many thanks,
> Alex
>
no there is not, and you can not do this - unless you rewrite the firmware 
and drivers for platform usb cable.

Antti 



Article: 96044
Subject: Re: [OT]Re: encryption
From: Philip Freidin <philip@fliptronics.com>
Date: Sat, 28 Jan 2006 20:57:01 GMT
Links: << >>  << T >>  << A >>
On Fri, 27 Jan 2006 11:47:52 -0000, "Symon" <symon_brewer@hotmail.com> wrote:
>I'm not sure I'd get to work too often if I had that route to travel. Is the 
>Gabba WiFi'd?
>As for comp.arch.fpga.cricket , I notice a lot of discussion on here about 
>stuff like metastability in asynchronous fifos, running Linux on FPGA 
>processors, EULAs/IP litigation. If we can't grasp simple concepts like 
>that, I'm not sure we're ready to step up to the complexity of the LBW laws 
>just yet.
>Cheers mate, Syms. 

All you need is "Bluff your way in Cricket" ISBN 1-85304-045-2

Philip LBW Freidin


Article: 96045
Subject: Re: So Xilinx, is XDL and related libraries an available open source
From: Jan Coombs <2005.08@murray-microft.co.uk>
Date: Sat, 28 Jan 2006 23:23:24 +0000
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> "Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag 
> news:drbp92$nh99@cliff.xsj.xilinx.com...
> 
>>fpga_toys@yahoo.com wrote:
>>
>>> I've actually told
>>>everyone who I am, and it's not that difficult to figure it out,
>>
>>I can't find any reference to you, so who are you then.
>>
>>Ed
> 
> 
> Ed,
> 
> you are right he hasnt told that, he actually told to me that I should get 
> used to people (like he) hiding its identify.

Earlier today in this thread, 11:50 uk time.

> 
> but if I am not mistaken then his name is: John Bass
> 

Handles are good deflectors of casual interest. I found the discussion very 
interesting, and had noticed Johns name and interest before today.

Jan Coombs

Article: 96046
Subject: Re: C to FPGA Tools (Impulse C and others) and necessary trig IP
From: "Simon Peacock" <simon$actrix.co.nz>
Date: Sun, 29 Jan 2006 13:26:37 +1300
Links: << >>  << T >>  << A >>
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 :-)



<fpga_toys@yahoo.com> wrote in message
news:1138447086.027054.208520@o13g2000cwo.googlegroups.com...
>
> Simon Peacock wrote:
> > I think you are taking the wrong approach.  I'm sure you can get the C
code
> > running.  But in reality if you have to implement sin/cos & sqrts, then
the
> > C code will be far from optimal, and you might need a vertex to do the
job
> > of a Spartan
>
> Actually, I find it not that different in many cases from similar
> VHDL/Verilog
> and have the advantage of being able to tweek the output in FpgaC when
> I don't like it. Especially when I do a boolean design, it goes right
> thru FpgaC
> as boolean logic equations to the LUT. The C may look a bit ugly that
> way, but
> you certainly have nearly exact control over the output. For example:
>
> [jbass@fastbox tests]$ cat example1.c
> int a:1,b:1,c:1;
> #pragma inputport (a,a9)
> #pragma inputport (b,a10)
>
> int sum_of_products:1;
> #pragma outputport (sum_of_products,a11)
>
> main()
> {
>
>         c = (sum_of_products = (a&b) + c);
> }
>
>
> produces:
>
> [jbass@fastbox tests]$ fpgac -target cnf example1.c
> [jbass@fastbox tests]$ cat example1.cnf
> _example1_Running^CLK = VCC;
> _a^CLK = port(_a,"a9");
> _b^CLK = port(_b,"a10");
> _c^(CLK*_example1_main__state_C1) = (~_c*_b*_a)+(_c*~_a)+(_c*~_b);
> port(_sum_of_products,"a11")^(CLK*_example1_main__state_C1) =
> (~_c*_b*_a)+(_c*~_a)+(_c*~_b);
> _example1_main__state_C1 = ~_example1_Running;
>
>
> which in xnf/edif is a bit more verbose (so I'll just take the meat of
> it):
>
> SYM, _sum_of_products-OBUF, OBUF
> PIN, I, I, _sum_of_products
> PIN, O, O, sum_of_products
> END
> EXT, sum_of_products, O,, LOC=_a11
> SYM, FFin-_sum_of_products, EQN, EQN=((~I0*I1*I2)+(I0*~I2)+(I0*~I1))
> PIN, I2, I, _a
> PIN, I1, I, _b
> PIN, I0, I, _c
> PIN, O, O, FFin-_sum_of_products
> END
> SYM, _sum_of_products, DFF
> PIN, D, I, FFin-_sum_of_products
> PIN, C, I, CLK
> PIN, CE, I, _example1_main__state_C1
> PIN, Q, O, _sum_of_products
> END
>



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

Jan Coombs wrote:
> Antti Lukats wrote:
> > you are right he hasnt told that, he actually told to me that I should get
> > used to people (like he) hiding its identify.

> Handles are good deflectors of casual interest. I found the discussion very
> interesting, and had noticed Johns name and interest before today.

It's actually been interesting to watch the petty bickering over this.

The sad part is that they also told several hundred thousand other
people
that use handles they are not welcome to participate in this forum, as
the
"self appointed owners of the list" will riddicule and do everything to
expose
their true identiies at the slightest difference of opinion. ...
totally sad as long
standing usenet guidelines embrace handles.


Article: 96048
Subject: XDL Tools wiki site
From: ptkwt@aracnet.com (Phil Tomson)
Date: 29 Jan 2006 03:37:49 GMT
Links: << >>  << T >>  << A >>

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/

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.

No code has yet been written.  The idea here is to try to collect some 
ideas to see what people would want to use XDL for and then, since time is 
limited, determine what would give us the most 'bang for the buck' (ie. what 
might be the most useful features that can be achieved with a reasonable amount of 
programming effort).

Oh, and I've also setup a page there for discussion of LegalIssues for those 
who are legally inclined ;-)

Phil

Article: 96049
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: "Erik Widding" <widding@birger.com>
Date: 28 Jan 2006 20:24:39 -0800
Links: << >>  << T >>  << A >>
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.

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).

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.  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.  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.

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.


Regards,
Erik.


---
Erik Widding
President
Birger Engineering, Inc.


 (mail) 100 Boylston St #1070; Boston, MA 02116
(voice) 617.695.9233
  (fax) 617.695.9234 
  (web) http://www.birger.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