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 101700

Article: 101700
Subject: Re: LVDS inputs on Cyclone II
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 04 May 2006 18:13:44 -0700
Links: << >>  << T >>  << A >>
jg,

If the part is hot socket capable (can plug in with power ON all IOs), 
then the IO structure can't use the foundry self protecting IOs, and has 
to use other tricks to meet ESD spec, and work.  Back to back diodes are 
pretty common.

As for seeing this sort of data in the spec sheet:  I already said it 
will not appear, as it is not a supported "use" (there is no standard 
that requires it, and full support of any swing and common mode voltage 
is crazy -- there would be a delay table for every Vcm and every swing).

If all you want is a reasonable comparator (which is basically faster 
than any off the shelf comparator by a factor of hundreds to thousands), 
it is there.

Austin

Jim Granville wrote:
> nospam wrote:
> 
>> Some time ago I did some experimentation (for a very cost sensitive
>> application) with a Spartan 3 part using an LVDS differential input as a
>> voltage comparator for a crude delta sigma ADC.
>> The I/O bank Vcco was 3.3v the common mode on the LVDS inputs was half 
>> the
>> 3.3v supply and the differential input voltage was (obviously) limited to
>> whatever it took drive the LVDS input one way or the other.
>> It worked fine.
>> Now the customer says he wants to use Cyclone II.
>> I want to run the I/O bank on 3.3v and for Cyclone II I don't want to 
>> have
>> to provide a 2.5v supply just for this one input.
>> So I ask an Altera FAE can I run an LVDS (as a crude voltage comparator)
>> input on 3.3v biased at 1.65v.
>> After an age I get the answer no, but I could use an LVPECL standard
>> <sigh>. Even from the very skimpy Altera data I can tell that 1.65v is
>> outside the LVPECL standard common mode range and LVPECL is only 
>> available
>> on dedicated clock input pins anyway.
>> So I ask the question again and after another age get told no, LVDS 
>> has to
>> run on 2.5v and no more than 650mV differential input with no further
>> explanation. 
> 
> 
>  When someone says that, it starts to sniff of a back-back clamp diode 
> structure - some opamps do use this to protect sensistive 1st stage 
> devices. Would be surprising on a FPGA tho.
> 
>  This is the sort of thing you could test on a bench very easily ?
> 
> -jg
> 

Article: 101701
Subject: Re: Quartus and source control
From: "Subroto Datta" <sdatta@altera.com>
Date: Fri, 05 May 2006 01:26:40 GMT
Links: << >>  << T >>  << A >>
Quartus provides a way to generate one compressed archived with all the 
required files. To archive, go to your project directory type:
quartus_sh --archive <revision name>

This command will  generate a <revision name>.qar file. To unarchive type

quartus_sh --restore <revision_name>
As part of the --archive, a <revision name>.qarlog which lists all archived 
files. You can parse this list to determine which files are most important, 
but note the list will also contain reports and other important output files 
(which many times are also put under revision control). To capture the 
sopc_builder files, add all files which end with the ptf extension to this 
file list. This may already be there in the qarlog file but do verify it for 
completeness.

As mentioned in my earlier post you can access the "Source Files Read" or 
any other report panel via Tcl. Use "quartus_sh --qhelp" to get details. 
Look for the "report" package. Here is  the script that you will need (run 
it after you have compiled your project so that the report is available):



"myscript.tcl"
load_package report
set revision name [lindex $quartus(args) 0]
project_open $revision_name
load_report

# Set panel name and id
set panel "*Source Files Read"
set id    [get_report_panel_id $panel]

# Get the number of rows
set row_cnt [get_number_of_rows -id $id]for {set i 0} {$i < $row_cnt} {incr 
i} {
    puts [get_report_panel_data -row $i -col_name "*Absolute Path" -id $id]
}

unload_report
project_close

To execute this script type
 quartus_sh -t myscript.tcl <revision name>
You should be in your project directory when you execute this.

Hope this helps,
Subroto Datta
Altera Corp.



"avishay" <avishorp@yahoo.com> wrote in message 
news:1146742752.281482.145790@y43g2000cwc.googlegroups.com...
>I see that this thread creates lots of interest, but it has gone a
> little off topic.
>
> I will try to describe the problem I face in more details. The grup I
> work in is composed of several hardware (FPGA) engineers. Some of them
> use VHDL, and some use graphic methods. Currently, no source control of
> any kind is used, making tracking design sources and sharing them among
> the group very difficult. In order to solve some of these problems, I
> want to install and start use Subversion as a source control system.
> What I look for is a way to automatically include in the source control
> components that are normally added in the graphic editor or using the
> MegaWizard interface. Another, related problem is taking an existing
> Quartus project, and putting it under source control without losing
> files and without including files that are not necessary. The best way
> to accomplish both tasks, in my opinion, is writing a script that wolud
> go through the project hierarchy (after synthesis), pick up all the
> source files used and add them to the source control system (if theyr'e
> not already there).
> Subroto Datta suggested to use the "Source Files Read" section of the
> analysis report, which seem to be a good direction, but I need to know
> if there is a way to get this information*programatically*, rather than
> text processing the report. This report also seem to lack memory
> initialization files (maybe more kind of files I don't know of?).
>
> Another type of problem is the SOPC builder. The SOPC builder takes the
> system specification from PTF files (as KJ mentioned) and copies HDL
> files from the relevant library into the project directory. These
> copied files are not strictly sources, but rather intermediate
> products, and as such they should not be under the soruce control (they
> should, in fact, but they should be controlled by the one that wrote
> the component, not the one using them). After SOPC builder has finished
> its run, there is no way (to my understanding) to distinguish between
> true source files and those who were copied. They will both show up the
> same in the said report. A possible solution might be to instruct SOPC
> builder to copy its files to a directory other than the project root (I
> think it would be much easier to manage also), but I don't know how to
> do that.
>
> Thanks for everyone who has replied (and will)
> Avishay
> 



Article: 101702
Subject: Re: RFID chip has battary in it or not
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 4 May 2006 18:51:43 -0700
Links: << >>  << T >>  << A >>
Hi Ray,
It is really a marvelous invention!!!

Who is the inventor?

Weng


Article: 101703
Subject: Re: LVDS inputs on Cyclone II
From: nospam <nospam@please.invalid>
Date: Fri, 05 May 2006 03:05:16 +0100
Links: << >>  << T >>  << A >>
Austin Lesea <austin@xilinx.com> wrote:

>It is powered from Vccaux, not Vcco!

Thanks for the insight. On the Spartan 3 initially I just ran the I/O bank
on 3.3v without worrying about it and it seemed to work. If the Spartan 3
data sheets says what the differential inputs are powered from I must have
missed it. The I/O pin schematic does show what Vcco is used for. I kinda
guessed the inputs ran from Vccaux although needing a Vccaux supply is a
minus point for the Spartan. 

>Since Vccaux is 2.5 volts in Spartan 3, that means that an input voltage 
>has to be in the range of 0 to 2.5 volts just to work at all (common 
>mode range).  

From memory the Cyclone II LVDS inputs have a similar common mode range so
if they really run from a 1.2v Vccint they must have a different
configuration and probably worse performance as a general purpose
comparator. Guess I'm going to have to experiment. 
--

Article: 101704
Subject: Re: LVDS inputs on Cyclone II
From: nospam <nospam@please.invalid>
Date: Fri, 05 May 2006 03:25:51 +0100
Links: << >>  << T >>  << A >>
Jim Granville <no.spam@designtools.co.nz> wrote:

>> So I ask the question again and after another age get told no, LVDS has to
>> run on 2.5v and no more than 650mV differential input with no further
>> explanation. 

>  When someone says that, it starts to sniff of a back-back clamp diode 
>structure - some opamps do use this to protect sensistive 1st stage 
>devices. Would be surprising on a FPGA tho.

>  This is the sort of thing you could test on a bench very easily ?

It wouldn't matter to me the converter keeps the comparator 1 'bit' either
side of it's switching point anyway. 

Input offset and hysteresis will mess up the converter some, but I only
need 'crude'. When I was experimenting it was digitising an ac signal so I
couldn't easily make measurements. When I get back to it I will do some dc
testing and discover more about the comparator. 

--

Article: 101705
Subject: Re: LVDS inputs on Cyclone II
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 05 May 2006 14:26:56 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> jg,
> 
> If the part is hot socket capable (can plug in with power ON all IOs), 
> then the IO structure can't use the foundry self protecting IOs, and has 
> to use other tricks to meet ESD spec, and work.  Back to back diodes are 
> pretty common.

In FPGAs ?  Can you give an example ?

> 
> As for seeing this sort of data in the spec sheet:  I already said it 
> will not appear, as it is not a supported "use" (there is no standard 
> that requires it, and full support of any swing and common mode voltage 
> is crazy -- there would be a delay table for every Vcm and every swing).
> 
> If all you want is a reasonable comparator (which is basically faster 
> than any off the shelf comparator by a factor of hundreds to thousands), 
> it is there.

  Other vendors data sheets have items called 'Guaranteed by design' and 
'not tested' - it tells designers what the limits of the device are.

  This proves one _can_ publish usefull design info, and not have to add
any testing load to your flows. (which seems to be your aversion ? )

  A LVDS cell is either rail-rail by design, or it is not. ( the good 
ones are... )

-jg


Article: 101706
Subject: OPB clocking question
From: "motty" <mottoblatto@yahoo.com>
Date: 4 May 2006 19:36:53 -0700
Links: << >>  << T >>  << A >>
Is there information on how to use a user IP that is attached to the
OPB with different clock speeds?  I currently have the IP core wrapped
in the default Import Peripheral Wizard files.  The user_logic is
Verilog.  The custom IP is instantiated in the user_logic.  Different
bits of several slave registers are conected to the core.  MicroBlaze
code "talks" to the slave registers by using the customary addressing
is C code.

There is one trigger bit that starts the user IP.  Once the
functionlaity of the IP is done, it asserts a flag that is routed back
to the user_logic level.  I added an "else if" statement to the default
slave register model implementation in the user_logic.  The default
implemetation has two states.  The first is "if  ( Bus2IP_Reset == 1
)", the other is the "else" and assigns the slave registers based on
the "slv_reg_write_select" signal.  I inserted an "else if" before the
aforementioned "else".  It goes: "else if (done_flag_i)", and assigns
to slave register 2.  It "clears" the bit that initially triggered the
module.  The embedded code waits in a while loop until the bit is
cleared.

This has worked GREAT (no problems!) while the exact same clock is
connected to both the OPB clock and the user IP's clock.  We are trying
some things with clocking.  If we connect the OPB clock of this core to
the common clock that attaches to all other OPB clocks and the uBlaze,
and then we connect another DCM-derived clock to the user IP core
clock, the behavior is hit or miss.  We have tried different clock
speeds.  One experiment was to use the two different clocks, but at the
same speed.  Again, this doesn't work consistently.  There are
definitely the facts that the two clocks are not EXACTLY the same
speed, and there is no phase certainty between the two clocks.

I am thinking that we either need to implement clock domain crossing
sync logic on each signal that passes between the user_logic and the IP
core we instantiate or that we need to take advantage of the
handshaking signals of the OPB...like the ack signal.  However, I can't
seem to find any examples of how to do this -- the handshaking that is.
 I know how to implement the sync flops.  The opb_ipif_pdf vs 3.04a
document has info, but appears to not have any figures (timing
diagrams) where it is supposed to.  Maybe mine is screwed up!

Any advice would be appreciated!!


Article: 101707
Subject: Re: LVDS inputs on Cyclone II
From: "Rob" <robnstef@frontiernet.net>
Date: Fri, 05 May 2006 03:21:29 GMT
Links: << >>  << T >>  << A >>
> You should let the customer know who is likely to provide you with more 
> timely and useful information.  They might change their mind....

It depends where you are.  Both companies have good and not so good FAE's. 
But I believe it to be very important for a company to have good FAE's; 
because sometimes it is the deciding factor as to which device an engineer 
will pick.



"Austin Lesea" <austin@xilinx.com> wrote in message 
news:e3dudj$cvm12@xco-news.xilinx.com...
> nospam,
>
> The LVDS input buffer in VII, II Pro, V4, Spartan 3, and 3E is a full CMOS 
> differential comparator, than will 'function' from rail to rail.
>
> Basically, each input ties to both a nmos differential pair, AND a pmos 
> differential pair, so that even when one, or the other is cutoff (out of 
> its range), its complement is still in range, and will operate to sense 
> the difference properly.
>
> Why did we go tothis extra trouble?  Well, these are tiny devices, and it 
> basically costs nothing to do it right the first time, so that you could 
> meet or beat any standard that anyone dreams up without redesigning it.
>
> It is powered from Vccaux, not Vcco!
>
> Since Vccaux is 2.5 volts in Spartan 3, that means that an input voltage 
> has to be in the range of 0 to 2.5 volts just to work at all (common mode 
> range).  We don't specify it use at the rails, because we can't 
> cahracterize all the possible uses of the circuit.  For low speeds, as I 
> said, it will function.  Don't complain if it doesn't switch as fast as it 
> is specified for the LVDS specification (you are not using it there).
>
> Since every IO pin also has a giant nmos and pmos stack for the single 
> ended driver attached to it, you also have a diode from ground to the 
> pins, and a diode to Vcco for the bank.  That means if the pin voltage 
> tries to go below ground (negative ~ 0.5V or greater) or above Vcco 
> (~Vcco+~0.5V) you will clamp the pin to that one diode above or below 
> ground.
>
> You should let the customer know who is likely to provide you with more 
> timely and useful information.  They might change their mind....
>
> Austin
>
> nospam wrote:
>
>> Some time ago I did some experimentation (for a very cost sensitive
>> application) with a Spartan 3 part using an LVDS differential input as a
>> voltage comparator for a crude delta sigma ADC. The I/O bank Vcco was 
>> 3.3v the common mode on the LVDS inputs was half the
>> 3.3v supply and the differential input voltage was (obviously) limited to
>> whatever it took drive the LVDS input one way or the other. It worked 
>> fine. Now the customer says he wants to use Cyclone II. I want to run the 
>> I/O bank on 3.3v and for Cyclone II I don't want to have
>> to provide a 2.5v supply just for this one input. So I ask an Altera FAE 
>> can I run an LVDS (as a crude voltage comparator)
>> input on 3.3v biased at 1.65v. After an age I get the answer no, but I 
>> could use an LVPECL standard
>> <sigh>. Even from the very skimpy Altera data I can tell that 1.65v is
>> outside the LVPECL standard common mode range and LVPECL is only 
>> available
>> on dedicated clock input pins anyway. So I ask the question again and 
>> after another age get told no, LVDS has to
>> run on 2.5v and no more than 650mV differential input with no further
>> explanation. I just read through the Cyclone II Device Handbook again and 
>> find it says "Cyclone II devices have one set of VCC pins (VCCINT) that 
>> power the
>> internal device logic array and input buffers that use the LVPECL, LVDS,
>> HSTL, or SSTL I/O standards."
>>
>> So if I believe this the Vccio supply is irrelevant for LVDS receivers 
>> and
>> the FAE was talking crap again. Can anyone confirm this and has anyone 
>> experience of using LVDS inputs as
>> voltage comparators on Cyclone II (or Spartan 3/3e for that matter). -- 



Article: 101708
Subject: Re: LVDS inputs on Cyclone II
From: "Rob" <robnstef@frontiernet.net>
Date: Fri, 05 May 2006 03:27:36 GMT
Links: << >>  << T >>  << A >>
I did a design with a Cyclone (not CycloneII) where I received LVDS at 
267Mbps while Vccio was powered with 3.3V.  It wasn't clear in the data 
sheet but I surmised it was possible from one of the Quartus reports.  So I 
checked with my FAE and he said it is possible to run the receivers at 3.3V, 
but not the transmitters.

I've never used the CycloneII, but perhaps it is similar in this regard???



"nospam" <nospam@please.invalid> wrote in message 
news:b5ok52dufbephvq2d8l6396gr2tqo8vjda@4ax.com...
>
> Some time ago I did some experimentation (for a very cost sensitive
> application) with a Spartan 3 part using an LVDS differential input as a
> voltage comparator for a crude delta sigma ADC.
>
> The I/O bank Vcco was 3.3v the common mode on the LVDS inputs was half the
> 3.3v supply and the differential input voltage was (obviously) limited to
> whatever it took drive the LVDS input one way or the other.
>
> It worked fine.
>
> Now the customer says he wants to use Cyclone II.
>
> I want to run the I/O bank on 3.3v and for Cyclone II I don't want to have
> to provide a 2.5v supply just for this one input.
>
> So I ask an Altera FAE can I run an LVDS (as a crude voltage comparator)
> input on 3.3v biased at 1.65v.
>
> After an age I get the answer no, but I could use an LVPECL standard
> <sigh>. Even from the very skimpy Altera data I can tell that 1.65v is
> outside the LVPECL standard common mode range and LVPECL is only available
> on dedicated clock input pins anyway.
>
> So I ask the question again and after another age get told no, LVDS has to
> run on 2.5v and no more than 650mV differential input with no further
> explanation.
>
> I just read through the Cyclone II Device Handbook again and find it says
>
> "Cyclone II devices have one set of VCC pins (VCCINT) that power the
> internal device logic array and input buffers that use the LVPECL, LVDS,
> HSTL, or SSTL I/O standards."
>
> So if I believe this the Vccio supply is irrelevant for LVDS receivers and
> the FAE was talking crap again.
>
> Can anyone confirm this and has anyone experience of using LVDS inputs as
> voltage comparators on Cyclone II (or Spartan 3/3e for that matter).
>
> -- 



Article: 101709
Subject: Re: LVDS inputs on Cyclone II
From: "Bob" <nimby1_NEEDSPAM@earthlink.net>
Date: Fri, 05 May 2006 05:54:45 GMT
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin@xilinx.com> wrote in message 
news:e3dudj$cvm12@xco-news.xilinx.com...
> nospam,
>
> The LVDS input buffer in VII, II Pro, V4, Spartan 3, and 3E is a full CMOS 
> differential comparator, than will 'function' from rail to rail.
>
> Basically, each input ties to both a nmos differential pair, AND a pmos 
> differential pair, so that even when one, or the other is cutoff (out of 
> its range), its complement is still in range, and will operate to sense 
> the difference properly.
>
> Why did we go tothis extra trouble?  Well, these are tiny devices, and it 
> basically costs nothing to do it right the first time, so that you could 
> meet or beat any standard that anyone dreams up without redesigning it.
>
> It is powered from Vccaux, not Vcco!
>
> Since Vccaux is 2.5 volts in Spartan 3, that means that an input voltage 
> has to be in the range of 0 to 2.5 volts just to work at all (common mode 
> range).  We don't specify it use at the rails, because we can't 
> cahracterize all the possible uses of the circuit.  For low speeds, as I 
> said, it will function.  Don't complain if it doesn't switch as fast as it 
> is specified for the LVDS specification (you are not using it there).
>

[snip]

Austin,

Are you saying that, since in V2-V4 the LVDS input buffer is driven from 
VCCAUX, even if a bank's VCCO is not 2.5V you may instantiate an LVDS25 
input? What about an LVDS output in a non-2.5V VCCO bank?

Thanks much,
Bob



Article: 101710
Subject: Re: RFID chip has battary in it or not
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Fri, 05 May 2006 07:59:55 +0200
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote:

> It is really a marvelous invention!!!
> 
> Who is the inventor?

No telling.

The idea might be uncovered just by observation. When in Berlin the big 
TV Tower was opened a lot of small gardens where nearby. All of them did 
not have electric power supply - but at night one could see light bulbs 
there. They drew energy from the field with a cable - a "long antenna".

Nicola Tesla wanted to transport energy by via a radio field. He 
constructed his famous "Tesla Coil" witch transformed AC to ultra-high 
voltage (with almost no current). I have seen a Tesla coil producing 
light strike of over 50cm length - more than 50kV. I touched this strike 
(with a screw driver to avoid to burn my hand) and felt a small prickle 
in my lower arm. With this Tesla Coil it was possible to carry a Neon 
Lamp that was glowing (no wires). And this was the idea of Tesla: He 
wanted to transport the energy by air.

13,5MHz RFID tags operate with inductive coupling. Therefore the 
observer of the inductivity could be named as the inventor. -> Joseph 
Henry, Michael Faraday.

900MHz RFID operate with resonant coupling - the idea of a radio. 
Marconi could be named as inventor.

Ok - this was the direction from the interrogator to the tag. Backward 
communication is done by drawing more or less energy from the field 
(switching on/off a load). Who could be named here? - I don't know.


Ralf

Article: 101711
Subject: Re: DRC has announced its newest FPGA that drops into AMD's Socket 940
From: rpw3@rpw3.org (Rob Warnock)
Date: Fri, 05 May 2006 01:48:38 -0500
Links: << >>  << T >>  << A >>
<tomstdenis@gmail.com> wrote:
+---------------
| What this does open the door for though is for mixed architecture
| systems.  E.g. synthesize a MIPS core in the FPGA and map the DDR
| controller on to it.
| 
| Then you have x86 and MIPS in the same system.  
+---------------

But *not* necessarily running ccNUMA with each other!! See my recent
post on "comp.lang.lisp" [yeah, they were talking about the prospects
for using the same DRC FPGA for an update on the Lisp Machine]:

    http://groups.google.com/group/comp.lang.lisp/msg/ac1488796602931d

especially the bits about the difference between "non-coherent HT",
used for ordinary I/O (PIOs & DMA), and the "coherent HT" used for
the inter-Opteron ccNUMA cache-coherency. I *strongly* suspect the
DRC FPGA[1] only does non-coherent HT, which, while just fine for
a DMA-style crypto co-processor, wouldn't let your FPGA-based MIPS 
CPU participate in the Opteron cache-coherency protocol.


-Rob

[1] Well, the *chip* could probably do either; I'm actually referring
    to whatever libraries of HT protocol support that come with it.

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607


Article: 101712
Subject: Xilinx-XUPV2P- AC97 Audio BSP
From: "Prakash" <prakash.na@gmail.com>
Date: 4 May 2006 23:51:55 -0700
Links: << >>  << T >>  << A >>
Hi all,
I'm using XUPV2P xilinx board. In that audio codec chip for AC97
support is avaliable. I plan to use linux-2.4.26 as RTOS. Now there are
linux BSP availble from xilinx for ps/2, ethernet, systemACE Flash etc.
But there is no linux BSP available for AC97 Audio codec chip LM4550.
But general AC97 codec drivers, I could see in linux distributions. How
can I modify the general driver to be xilinx board specific BSP. so
that after libgen I'll copy this drivers into kernel and cross compile
it.
Regards
Prakash


Article: 101713
Subject: Re: Phase alignment of DCMs on different boards/devices
From: "Dave" <doomeddave@yahoo.co.uk>
Date: 5 May 2006 00:03:18 -0700
Links: << >>  << T >>  << A >>
> You must distinguish between the relatively long time that th DLL takes
> to achieve lock (many microseconds) and the very small phase error on
> the outputs (picoseconds, which is  million times shorter) once the DLL
> is locked
>
> So, the different DLL will most likely achieve lock at different times,
> but once in lock, they will each perform to data sheet specs, which
> means picoseconds of difference on the outputs

Hi Peter,

I would have thought that if all DCMs start attempting lock at exactly
the same time then they would achieve it at the same time.  What causes
them to achieve lock at differnt times assuming the input to each is
exactly in phase and they start working at the same time?  Is it down
to differences between the silicon or some other inherent property of
the DCMs loop structures?

Many thanks,

Dave


Article: 101714
Subject: Re: Phase alignment of DCMs on different boards/devices
From: Rene Tschaggelar <none@none.net>
Date: Fri, 05 May 2006 10:05:49 +0200
Links: << >>  << T >>  << A >>
Dave wrote:

>>You must distinguish between the relatively long time that th DLL takes
>>to achieve lock (many microseconds) and the very small phase error on
>>the outputs (picoseconds, which is  million times shorter) once the DLL
>>is locked
>>
>>So, the different DLL will most likely achieve lock at different times,
>>but once in lock, they will each perform to data sheet specs, which
>>means picoseconds of difference on the outputs
> 
> 
> Hi Peter,
> 
> I would have thought that if all DCMs start attempting lock at exactly
> the same time then they would achieve it at the same time.  What causes
> them to achieve lock at differnt times assuming the input to each is
> exactly in phase and they start working at the same time?  Is it down
> to differences between the silicon or some other inherent property of
> the DCMs loop structures?

Even if the silicon was identical to the Angstroem,
you couldn't guarantee they have the same temperature
nor that they see the same supply voltage with the
same impedance.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Article: 101715
Subject: Xilinx SelectMAP Question
From: Peter Mendham <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk>
Date: Fri, 05 May 2006 09:31:16 +0100
Links: << >>  << T >>  << A >>
Dear all,

I am configuring a Xilinx Spartan 3 using SelectMap (the parallel 
interface), although the simple details of this interface that I am 
interested apply to a number of other chips.  Having looked at as many 
datasheets, application notes and examples as I can find, I cannot 
answer a simple question: in what order are the bytes of a SelectMap 
configuration stream sent?

Ignoring bit-swapping within a byte, are the bytes forming the beginning 
of the stream (dummy word/sync word) sent as: 0xFF 0xFF 0xFF 0xFF 0xAA 
0x99 0x55 0x66 i.e. big-endian, or are they sent as 0xFF 0xFF 0xFF 0xFF 
0x66 0x55 0x99 0xAA i.e. little-endian?

Any help would be greatly appreciated.

TIA,

Peter

Article: 101716
Subject: Re: Xilinx SelectMAP Question
From: "Antti" <Antti.Lukats@xilant.com>
Date: 5 May 2006 01:47:57 -0700
Links: << >>  << T >>  << A >>
sent as aa 55 66 99

Antti


Article: 101717
Subject: Re: Xilinx SelectMAP Question
From: Peter Mendham <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk>
Date: Fri, 05 May 2006 10:00:40 +0100
Links: << >>  << T >>  << A >>
Antti wrote:
> sent as aa 55 66 99
> 
> Antti
> 
Thanks for your response, but I'm a little confused.  The data sheet 
specifies the sync dword as 0xAA995566, does that *really* get sent as 
AA 55 66 99?  i.e. byte0 byte2 byte3 byte1?  Or did you just mean to 
point out that the 0xAA is sent first, i.e. AA 99 55 66?

If the AA is sent first this makes things a little more tricky for me, 
as part of a reconfiguration stream passes through my device and I must 
calculate a CRC.  The CRC is calculated least significant bit first 
which means I must wait for a whole dword before being able to update my 
current CRC, rather than being able to update it on every byte.  This 
seems most inefficient.

Best,

Peter

Article: 101718
Subject: Re: Xilinx SelectMAP Question
From: Aurelian Lazarut <aurash@xilinx.com>
Date: Fri, 05 May 2006 10:30:35 +0100
Links: << >>  << T >>  << A >>
Peter,
the spartan3 select map IF is 8 bit wide, as Antti said before, just 
send the bytes as they are coming from the *.bit file, 0xFF 0xFF 0xaa 
0x55 0x66 0x99 and so on...
about the CRC I'm not sure why you would want to calculate the CRC 
yourself, bitgen does this for you

Aurash

Peter Mendham wrote:
> Antti wrote:
> 
>> sent as aa 55 66 99
>>
>> Antti
>>
> Thanks for your response, but I'm a little confused.  The data sheet 
> specifies the sync dword as 0xAA995566, does that *really* get sent as 
> AA 55 66 99?  i.e. byte0 byte2 byte3 byte1?  Or did you just mean to 
> point out that the 0xAA is sent first, i.e. AA 99 55 66?
> 
> If the AA is sent first this makes things a little more tricky for me, 
> as part of a reconfiguration stream passes through my device and I must 
> calculate a CRC.  The CRC is calculated least significant bit first 
> which means I must wait for a whole dword before being able to update my 
> current CRC, rather than being able to update it on every byte.  This 
> seems most inefficient.
> 
> Best,
> 
> Peter

Article: 101719
Subject: Re: detailed description on the archetecture of FPGA's/CPLD's
From: pbdelete@spamnuke.ludd.luthdelete.se.invalid
Date: 05 May 2006 09:38:13 GMT
Links: << >>  << T >>  << A >>
Guru Prasad <guruprasad@rassit.com> wrote:
>Hello,

>I am verry new to this Field and i would be verry happy if anybody would sujjest me a link or any document which gives me an idea on what an FPGA/CPLD is and its arcitecture,how a vhdl code is actually implmented in these... Regards, Guru Prasad

http://en.wikipedia.org/wiki/FPGA
http://www.fpga4fun.com/

Other than that (simplified) it's a chip that can react to any digital input
and send any digital output according to your programming.

FPGA - Programming loaded at every startup. Fast & Big.
CPLD - Retains programming but have less capacity.

(hope I got it right :)


Article: 101720
Subject: Re: Xilinx SelectMAP Question
From: Aurelian Lazarut <aurash@xilinx.com>
Date: Fri, 05 May 2006 10:43:57 +0100
Links: << >>  << T >>  << A >>
Peter,
One more thing, can you please point me to the document and page # where 
you find 0xAA995566 as sync word?
thanks,
Aurash


Aurelian Lazarut wrote:
> Peter,
> the spartan3 select map IF is 8 bit wide, as Antti said before, just 
> send the bytes as they are coming from the *.bit file, 0xFF 0xFF 0xaa 
> 0x55 0x66 0x99 and so on...
> about the CRC I'm not sure why you would want to calculate the CRC 
> yourself, bitgen does this for you
> 
> Aurash
> 
> Peter Mendham wrote:
> 
>> Antti wrote:
>>
>>> sent as aa 55 66 99
>>>
>>> Antti
>>>
>> Thanks for your response, but I'm a little confused.  The data sheet 
>> specifies the sync dword as 0xAA995566, does that *really* get sent as 
>> AA 55 66 99?  i.e. byte0 byte2 byte3 byte1?  Or did you just mean to 
>> point out that the 0xAA is sent first, i.e. AA 99 55 66?
>>
>> If the AA is sent first this makes things a little more tricky for me, 
>> as part of a reconfiguration stream passes through my device and I 
>> must calculate a CRC.  The CRC is calculated least significant bit 
>> first which means I must wait for a whole dword before being able to 
>> update my current CRC, rather than being able to update it on every 
>> byte.  This seems most inefficient.
>>
>> Best,
>>
>> Peter

Article: 101721
Subject: Re: Cordic-based Sine Computer in MyHDL
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Fri, 05 May 2006 11:50:42 +0200
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> Jan Decaluwe wrote:
> 
>> I have added a page about a Cordic-based Sine Computer to
>> the MyHDL CookBook:
>>
>>   http://myhdl.jandecaluwe.com/doku.php/cookbook:sinecomp
> 
> 
> Wow. A non-trivial example that works.
> Beautiful generated code.
> (Ignore the synthesis warnings, I think Jan has it right.)

Does Quartus issue warnings also?

No doubt the warnings are related to the use of blocking
assignments in a clocked always block. You know :-)

At least XST doesn't declare this an error. My worst nightmare
would be that half-baked synthesis tools or Verilog gurus
would prevent me from writing code like this. It's a realistic
possibility that explains my occasional angry outbursts.

What I think happens is that XST creates a FF for any reg
in the code. When it detects that the Q output is not used,
it issues a warning. Fine with me, as long as it uses
the D input wire properly :-)

An interesting side effect is that no warnings are issued
in the more "advanced" case when a reg is potentially
used immediately but also stored for later usage,
like the 'counting' flag in this example:

   http://myhdl.jandecaluwe.com/doku.php/cookbook:stopwatch

Best regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Article: 101722
Subject: Re: Xilinx SelectMAP Question
From: "jenze" <jenze@et.upb.de>
Date: 5 May 2006 02:56:14 -0700
Links: << >>  << T >>  << A >>
Hi Peter,

AFSIK the syncword is not included in the bitstream CRC calculation.
Only the commands and  data sections are included in calculation.

Regards

Jens

Aurelian Lazarut schrieb:

> Peter,
> the spartan3 select map IF is 8 bit wide, as Antti said before, just
> send the bytes as they are coming from the *.bit file, 0xFF 0xFF 0xaa
> 0x55 0x66 0x99 and so on...
> about the CRC I'm not sure why you would want to calculate the CRC
> yourself, bitgen does this for you
>
> Aurash
>
> Peter Mendham wrote:
> > Antti wrote:
> >
> >> sent as aa 55 66 99
> >>
> >> Antti
> >>
> > Thanks for your response, but I'm a little confused.  The data sheet
> > specifies the sync dword as 0xAA995566, does that *really* get sent as
> > AA 55 66 99?  i.e. byte0 byte2 byte3 byte1?  Or did you just mean to
> > point out that the 0xAA is sent first, i.e. AA 99 55 66?
> >
> > If the AA is sent first this makes things a little more tricky for me,
> > as part of a reconfiguration stream passes through my device and I must
> > calculate a CRC.  The CRC is calculated least significant bit first
> > which means I must wait for a whole dword before being able to update my
> > current CRC, rather than being able to update it on every byte.  This
> > seems most inefficient.
> > 
> > Best,
> > 
> > Peter


Article: 101723
Subject: Re: LVDS inputs on Cyclone II
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 5 May 2006 10:59:14 +0100
Links: << >>  << T >>  << A >>
"Austin Lesea" <austin@xilinx.com> wrote in message 
news:e3e8sb$cuh15@xco-news.xilinx.com...
>
> As for seeing this sort of data in the spec sheet:  I already said it will 
> not appear, as it is not a supported "use" (there is no standard that 
> requires it, and full support of any swing and common mode voltage is 
> crazy -- there would be a delay table for every Vcm and every swing).
>
> If all you want is a reasonable comparator (which is basically faster than 
> any off the shelf comparator by a factor of hundreds to thousands), it is 
> there.
>
> Austin
>
Hi Austin,
I agree. It's also clear why this behaviour isn't published. I for one am 
impressed with the performance and flexibility of the LVDS inputs, they've 
eased my design problems considerably over the past few years. Good job.
Cheers, Syms.


p.s. Note I didn't even moan about how they're compromised at high 
frequencies by the input capacitance. Oh bugger, I just did. ;-)



Article: 101724
Subject: Re: Xilinx SelectMAP Question
From: "Antti" <Antti.Lukats@xilant.com>
Date: 5 May 2006 03:08:15 -0700
Links: << >>  << T >>  << A >>
its an active document, called HEX viewer.
on my PC it is the "F4" - I am using winXP mainly as a way to start
multiply copies of FAR (clone of norton commander)
so on my PC I select any xilinx .BIT file, press F4, and I see the 0xAA
... :)

Antti
PS sure the sync and all other details of the xilinx bitstream are
documented in xilinx datasheets as well.




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