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 96350

Article: 96350
Subject: Re: xilinx linux source?
From: Paul Hartke <phartke@Stanford.EDU>
Date: Thu, 02 Feb 2006 07:17:16 -0800
Links: << >>  << T >>  << A >>
Haven't had any problems using Crosstool: http://kegel.com/crosstool/
Very easy to setup as well.  

Paul

"tony.p.lee@gmail.com" wrote:
> 
> You can rsync the ppc linux source from
> rsync://source.mvista.com/linuxppc-2.4
> 
> But setting up the ppc gcc cross compiler correctly for linux kernel is
> not a trivial task.
> 
> -Tony

Article: 96351
Subject: Re: How will synthesizers handle these statements?
From: Jason Zheng <xin.zheng@jpl.nasa.gov>
Date: Thu, 02 Feb 2006 08:05:06 -0800
Links: << >>  << T >>  << A >>
Frank wrote:
> I put these conditions in different always and if-else-if statements, will
> design compiler & ISE be smart enough to recognise them and reduce
> hardware cost accordingly?
> 
There's an option in many synthesizers called "resource sharing" that 
will optimize for space if logic like these are found, but I think the 
default is to treat them as seperate blocks. Why bother with 
optimizations like this? IMO these should be the least to worry about.

> but if synthesizers handles these, then it will save me some thinking.

Do save yourself some thinking like this, let the synthesis tools worry 
about optimization.

Article: 96352
Subject: Re: Die Area
From: "johnp" <johnp3+nospam@probo.com>
Date: 2 Feb 2006 08:24:44 -0800
Links: << >>  << T >>  << A >>
Actually, someone needs to find an old 1702 (??) eprom, one of the
original
Intel 1 Kbit parts that was UV erasable.  How big was the die on that
"mega-part"?  Which current Xilinx die takes the same area.

One Xilinx BRAM has more capacity than the entire 1702.  Of course, I'm
comparing ram vs rom here.

As I recall, the programming voltages were amazing.  Pull
this to 70V, pull that to minus something.  Pray that the power
transistors
on the programmer don't blow out again.  Gasp, I'm dating myself!

John Providenza


Article: 96353
Subject: Re: high input to CPLD
From: "Peter Alfke" <peter@xilinx.com>
Date: 2 Feb 2006 09:04:07 -0800
Links: << >>  << T >>  << A >>
Pradnya, you must learn to read a data sheet.
For 9536 it says:
recommended Operating Conditions
VIH High Level Input Voltage max Vccint + 0.5 V
where Vccint = 4.75 to 5.25 V.

That tells you that you can connect the input to Vccint.
If you like to put a resistor in series, that resistor does not add to
the power consumption.
Peter Alfke


Article: 96354
Subject: Re: Die Area
From: "Peter Alfke" <peter@xilinx.com>
Date: 2 Feb 2006 09:11:00 -0800
Links: << >>  << T >>  << A >>
Yes, and the first computers used two triode vaccuum tubes to store a
bit, with a supply voltage around 150 V.
60 years of Progress !
Peter Alfke


Article: 96355
Subject: Re: xilinx linux source?
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Thu, 02 Feb 2006 09:14:55 -0800
Links: << >>  << T >>  << A >>
Have a look at XAPP765 
(http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf). It is written for 
an older EDK version but the principles of operation are still the same.

- Peter


Anonymous wrote:
> I have an evm on order, but is there a place I can download the PPC linux
> for Virtex-4? I want to make sure I can build it okay.
> 
> Thanks,
> Clark
> 
> 


Article: 96356
Subject: Re: Die Area
From: Ray Andraka <ray@andraka.com>
Date: Thu, 02 Feb 2006 12:20:12 -0500
Links: << >>  << T >>  << A >>
johnp wrote:
> Actually, someone needs to find an old 1702 (??) eprom, one of the
> original
> Intel 1 Kbit parts that was UV erasable.  How big was the die on that
> "mega-part"?  Which current Xilinx die takes the same area.
> 
> One Xilinx BRAM has more capacity than the entire 1702.  Of course, I'm
> comparing ram vs rom here.
> 
> As I recall, the programming voltages were amazing.  Pull
> this to 70V, pull that to minus something.  Pray that the power
> transistors
> on the programmer don't blow out again.  Gasp, I'm dating myself!
> 
> John Providenza
> 

I was just admiring the pretty white and gold package on a 1702A I came 
across in one of my old project junk boxes last week.  Those were pretty 
parts.  I don't miss the programming though.  I don't recall 70v, I 
think it was more like -48v and that needed to switch from 0 to -48 for 
the programming pulse, and there was also a substrate voltage of 
something like -40v, that also had to be pulsed.  The data and address 
also had big voltages on them, I don't recall if they were -40 or -48v. 
  Even reading this was a bit of a pain because it needed a bias voltage 
of --9v.  Still, they were very pretty chips to look at.

BTW, the die looks to be about 3/8" square.

Article: 96357
Subject: Re: xilinx linux source?
From: "Anonymous" <someone@microsoft.com>
Date: Thu, 02 Feb 2006 17:51:48 GMT
Links: << >>  << T >>  << A >>
I'm confused. I thought the xilinx linux was open source? Is monte vista the
only place to get the source?

"Peter Ryser" <peter.ryser@xilinx.com> wrote in message
news:drteng$8a31@cliff.xsj.xilinx.com...
> Have a look at XAPP765
> (http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf). It is written for
> an older EDK version but the principles of operation are still the same.
>
> - Peter
>
>
> Anonymous wrote:
> > I have an evm on order, but is there a place I can download the PPC
linux
> > for Virtex-4? I want to make sure I can build it okay.
> >
> > Thanks,
> > Clark
> >
> >
>



Article: 96358
Subject: Re: xilinx linux source?
From: "tony.p.lee@gmail.com" <tony.p.lee@gmail.com>
Date: 2 Feb 2006 10:14:48 -0800
Links: << >>  << T >>  << A >>

mvista is rsync site is just mirror of the public linux kernel site.
You don't need to pay monte vista to use it.

It is not the only place to get it.  

-Tony


Article: 96359
Subject: Re: don't care condition
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 02 Feb 2006 10:21:47 -0800
Links: << >>  << T >>  << A >>
sandi wrote:
> Please let me know - what is the advantage of fully specifying don't
> care conditions?

Your code will be easier to modify and test.


       -- Mike Treseler

Article: 96360
Subject: Re: Die Area
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 03 Feb 2006 07:49:17 +1300
Links: << >>  << T >>  << A >>
johnp wrote:

> Actually, someone needs to find an old 1702 (??) eprom, one of the
> original
<snip> Gasp, I'm dating myself!

So, is that 1702 the part number, or the date code ? ;)

-jg


Article: 96361
Subject: Re: Die Area
From: "Antti Lukats" <antti@openchip.org>
Date: Thu, 2 Feb 2006 20:01:25 +0100
Links: << >>  << T >>  << A >>
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag 
news:43e25419$1@clear.net.nz...
> johnp wrote:
>
>> Actually, someone needs to find an old 1702 (??) eprom, one of the
>> original
> <snip> Gasp, I'm dating myself!
>
> So, is that 1702 the part number, or the date code ? ;)
>
> -jg
>

Jim,

1702 is a part number, but I would think you know that?
or are you really younger than I ?

Antti 



Article: 96362
Subject: Re: xilinx linux source?
From: "Anonymous" <someone@microsoft.com>
Date: Thu, 02 Feb 2006 19:44:42 GMT
Links: << >>  << T >>  << A >>
So the process is really:

1. get PPC cross compiler
2. get kernel source from kernel.org
3. generate board support packages from fpga design
4. build kernel
5. build ace file and boot

So the magic is all in the BSP stuff which I assume is basically the BIOS
code in a regular PC and the libraries/memory spaces for the various
peripherals? Monte Vista is just making it easier for folks by packaging
everything in one place?

How does the kernel source know that I'm building for a PPC target?

Thanks,
Clark

<tony.p.lee@gmail.com> wrote in message
news:1138904088.604673.26180@g47g2000cwa.googlegroups.com...
>
> mvista is rsync site is just mirror of the public linux kernel site.
> You don't need to pay monte vista to use it.
>
> It is not the only place to get it.
>
> -Tony
>



Article: 96363
Subject: Re: BGA central ground matrix
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 02 Feb 2006 11:48:10 -0800
Links: << >>  << T >>  << A >>
Colin,

You are making a classic mistake:  not much DC current flows either.

The static magnetic field will force the static electric field to be 
confined to the area adjacent to the current flow in the opposite direction.

This is not skin effect (where current flows on the surface at high 
frequencies), but a very simple EM rule, that is completely ignored!

Use of any 2&1/2 D or 3D (Ansoft) modeling tool shows this.

The most famous (and true) story of this was with the SF Bay Area Rapid 
Transit System (BART), in ~1974 or was it 1975?:

The design had a third rail, on the left of the train (from front of 
train point of view) carrying 1000V DC for the train.

The return was the two rails.

Obviously(?) the Westinghouse engineers reasoned that the return current 
would be equally divided among the two rails.  1/2 on right rail, 1/2 on 
left rail.

They designed a "train in block" detector to show where they had trains 
that detected when the two currents were balanced.

Day 1, they turn it on, and everywhere there is NO train, the light is 
ON (giant status board in Richmond, Ca).  Everywhere there !is! a train, 
the light is OFF!

Westinghouse, Xerox (who did the computers?), and a host of consultants 
descend on UC Berkeley to ask the E&M Professors "what the h***?"

As they (professors) laughed and laughed, they asked the grad and senior 
students to figure it out with (for) the commercial engineers.

So, we all sat down, sharpened our pencils, got out our sliderules and 
textbooks, solved it, and voila!  2/3 in the left rail (nearest to the 
supply) and 1/3 on the right rail (furthest).

Austin

colin wrote:

> Austin
> 
> This all suggests that I can have an outer ring of vias in the center
> of a device (next to every "outer" gnd ball) and a copper pour on the
> top layer connecting the rest of the gnd balls with a few vias. I can
> then easily put some bulk decoupling right in the center of the bga as
> it is no longer peppered with vias. If this is the case then you have
> my thanks for pointing this out.
> 
> By the way, you say no current flows on the inner balls but surely they
> carry their share of the DC current?
> 
> Regards
> 
> Colin
> 

Article: 96364
Subject: Re: Die Area
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 02 Feb 2006 11:55:19 -0800
Links: << >>  << T >>  << A >>
johnp wrote:
> Actually, someone needs to find an old 1702 (??) eprom, one of the
> original
> Intel 1 Kbit parts that was UV erasable.  

here's a few:
http://www.virtualaltair.com/virtualaltair.com/vac_altair_turnkey_module.asp

        -- Mike Treseler

Article: 96365
Subject: Re: high input to CPLD
From: "ernie" <ernielin@gmail.com>
Date: 2 Feb 2006 12:27:56 -0800
Links: << >>  << T >>  << A >>
You should probably connect it through a pull-up resistor for safety.
What happens if you accidentally drive that pin to '0'?  You would blow
up the output transistor!  Of course if you say that it is an input pin
then it shouldn't matter, but it's still safer to go through a
resistor.

Just make sure you choose the resistor value according to how much
current that pin can handle.


Cheers
Ernie


Article: 96366
Subject: Re: Die Area
From: Ray Andraka <ray@andraka.com>
Date: Thu, 02 Feb 2006 16:08:03 -0500
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> johnp wrote:
> 
>> Actually, someone needs to find an old 1702 (??) eprom, one of the
>> original
>> Intel 1 Kbit parts that was UV erasable.  
> 
> 
> here's a few:
> http://www.virtualaltair.com/virtualaltair.com/vac_altair_turnkey_module.asp 
> 
> 
>        -- Mike Treseler

Actually, the 1702A was a 2K bit part, organized as a 256x8.  Here's a 
data sheet http://www.jmargolin.com/patents/1702a.pdf

Mike, the ones in your pictures sure aren't as pretty as the one I was 
looking at the other day.  Mine is in the white cermic package with the 
gold pins and gold around the window.  There is one like it on the board 
in your first picture in the middle of the 3 PROMs there.

Article: 96367
Subject: Re: Die Area
From: "Jerry Coffin" <jerry.coffin@gmail.com>
Date: 2 Feb 2006 13:13:49 -0800
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> johnp wrote:
> > Actually, someone needs to find an old 1702 (??) eprom, one of the
> > original
> > Intel 1 Kbit parts that was UV erasable.
>
> here's a few:
> http://www.virtualaltair.com/virtualaltair.com/vac_altair_turnkey_module.asp

That shows RAMs and ROMs, but I didn't see any shots of EPROMs, at
least with the window uncovered to allow us to dimension the die.

There are a few shots of some 1702s here though:

http://web.archive.org/web/20050309071426/http://www.vintagemicrochips.com/1702.pdf

Using the 100 mill pin pitch for scaling, I'm getting a die size of
about .14 x .11 inches, which gives an area just under 10 square
millimeters.

-- 
    Later,
    Jerry.


Article: 96368
Subject: Re: Parallel Cable IV does not work with parallel to usb cable
From: antonio bergnoli <bergnoli@pd.infn.it>
Date: 2 Feb 2006 22:24:55 +0100
Links: << >>  << T >>  << A >>
Ray Andraka ha scritto:
> Sean Durkin wrote:
> 
>> Marco T. wrote on 01.02.2006 09:56:
>>
>>> Do you know a all-in-one port replicator with usb, serial and ps/2 
>>> connectors that works with Parallel Cable IV?
>>
>>
>> Haven't been able to find one of those either... The problem seems to be
>> that iMPACT/Chipscope don't recognize the "virtual" LPT-ports those port
>> replicators usually provide...
>> There are parallel-port-controllers for Cardbus/PCMCIA you can plug in
>> to get a "real" parallel port on your laptop, but I haven't tried any of
>> those, so I can't comment on how good they are.
>> The problem is the chipset: to get decent programming speeds, the
>> parallel port should support 2MHz or 5MHz operation. All
>> PCI-plugin-cards I've seen in stores lately use the same cheap
>> controller-chip that doesn't support operation above 1MHz, so the cable
>> will work in compatibility mode and drop down to 200kHz.
>>
>> Instead, I suggest buying a Platform USB cable. Gives you much less
>> trouble in the long run, and works well on every modern machine.
>> ... if you can afford it, that is. I think it's $150, so about double
>> what the parallel cable costs. Plus, I'm not sure if it works under
>> Linux, but there have been discussions about that here lately.
>>
>> cu,
>> Sean
> 
> 
> If you are programming through the JTAG interface, you could try the 
> Diligent USB-JTAG cable which is under $40.

is Diligent USB-JTAG cable compatible  with Impact? or it is necessary 
to use another software?

Article: 96369
Subject: Re: Spartan3 pullups
From: "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com>
Date: 2 Feb 2006 13:27:43 -0800
Links: << >>  << T >>  << A >>

Allan Herriman wrote:
> On Wed, 01 Feb 2006 11:27:40 -0800, John Larkin
> <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

[... snip ...]

> I don't have the datasheet in front of me, but I believe that Xilinx
> do not guarantee a minimum pullup current, merely that the pin will be
> pulled up if it has no external load.

Beginning with the Spartan-3 FPGA family, Xilinx started specifying the
pull-up and pull-down currents in the data sheet.  For Spartan-3 FPGAs,
take a look at Table 6 on PDF page 55 in the Spartan-3 Data Sheet link
shown below.
http://www.xilinx.com/bvdocs/publications/ds312.pdf

The pull-up and pull-down resistors in Spartan-3 are quite a bit
stronger than in previous families.  For 3.3V standards, the pull-up
resistor ranges from 1.2K to 4.1K and the pull-down resistor ranges
from 1.75K to 9.35K.  Spartan-3E toned down the resistance a bit.

---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.


Article: 96370
Subject: Microblaze question
From: spammersarevermin <spammersarevermin@krumpli.com>
Date: Thu, 02 Feb 2006 17:21:15 -0500
Links: << >>  << T >>  << A >>
Is there any way for a hobbyist to obtain the EDK in order to work w/
Microblaze? Or is there any other way to obtain Microblaze? I don't
have the experience to be able to go to opencores and dive into one of
the processors there.

Thanks, Tom
Spamming this account signifies 
your unqualified consent to a free security audit

Article: 96371
Subject: Sharing BRAM between Xilinx PowerPC's (on data-OCM ports)
From: "Jeff Shafer" <shafer@delete-to-reply.aquaweb.pair.com>
Date: Thu, 2 Feb 2006 16:31:12 -0600
Links: << >>  << T >>  << A >>
Hi,



Question summary:  Can I successfully share a Xilinx dual-port BRAM between 
two PowerPC data-OCM's where it is possible to write and read the same 
location at the same time without corrupting the data? (by different 
processors from different ports of the BRAM)   I don't care if the read 
returns the old data or the new data from the write, but I want the read 
results to be deterministic and repeatable without corrupting the write.



The (lengthy) details:



I have an XC2VP30 FPGA with two PPC 405 processors.  In an EDK project, I am 
trying to use the data-side OCM port on each processor to connect to a 
dual-port BRAM.  This BRAM will be used as a common scratchpad that is 
accessible from both processors.



The problem I experience is best demonstrated in a simple producer/consumer 
software program.  PowerPC #1 is the producer and writes each BRAM location 
with 1 of 13 pre-determined 32-bit values.  It runs in a tight loop and 
repeatedly fills the memory.



PowerPC #2 is the consumer and repeatedly reads each BRAM location in a 
tight loop. If the value it reads is not one of the 13 pre-determined values 
that could be written, an error has occurred.



**Because each processor loops forever and runs different code of different 
lengths, it is possible for PowerPC #1 to be writing the same address at the 
same time that PowerPC #2 is attempting to read it from the opposite memory 
port.**



The BRAM is 8kB in size.  Out of 1 million BRAM reads, approximately 10-20 
have invalid results that should not appear anywhere in memory. These errors 
are randomly distributed through the entire test length and do not cluster 
at the beginning or end. Immediately re-reading that error location a second 
time will typically read a correct value, but not always. (Sometimes we can 
read for a hundred times without getting a legit value, at least until PPC 
#1 loops around and re-writes that location again).  I interpret this to 
mean that *most* of the time, just the read is corrupted, but that 
*sometimes* the write itself failed to fully update the memory.



In the VII-Pro Users Guide, I see there are specifications regarding writing 
and reading to the same address in a dual-port BRAM at the same time.  Our 
PowerPCs (300 MHz) and data-OCM interfaces (100MHz) are all rising-edge 
aligned and would seem to be vulnerable to this situation.



I tried changing the BRAM write mode from "WRITE_FIRST" to "READ_FIRST" via 
a UCF constraint in hopes of getting legitimate reads out of the second 
port.  The error behavior improved slightly but was still present. I 
verified that the constraint was successfully applied in the FPGA Editor.



I also tried running both OCM ports (or both Power PC's) on inverted clocks 
so they were out of phase.  Unfortunately, we want both processors to share 
the same PLB bus, so this technique is also not possible.



** In the error tests, both the instruction and data caches are on in both 
processors and are set to only cache the PLB-based BRAM, not the scratchpad 
in question.  However, if I turn the data cache completely *OFF* for both 
processors (but leave the I-cache on), then no errors are reported.  We can 
run the test for hours.  Too bad we need that cache for a real system, 
although there's not really much data to cache in the test program. We have 
played for hours with different PPC instructions to make the memory guarded, 
enforce in-order execution, flush the cache (even though the OCM is 
supposedly not cached), and have had zero luck. **



In the FPGA editor, the scratchpad BRAM blocks (4 of them) are perfectly 
placed in between the two processors, not shoved to a far-off corner of the 
chip or anything like that.



I guess my question is: Has anyone ever successfully shared a BRAM between 
two PowerPC data-OCM's where it is possible to write and read the same 
location at the same time?  I would be perfectly happy if the read produced 
the old value at that location and not the new value. (Which is what I 
thought changing the write mode to READ_FIRST would produce).



Thanks,



Jeff



Article: 96372
Subject: Source address in IPIC
From: "agou" <agou.win@gmail.com>
Date: 2 Feb 2006 14:36:11 -0800
Links: << >>  << T >>  << A >>
Hi, group

I generated a IPIC interface by the Create and Import Peripheral Wizard
to access the memory ports on the PLB bus.

I chose the DMA, user logic Master Support mode. And then try to
develop my own logic based on the generated files. Here, I have one
problem:

To write to an address on PLB bus, I need to provide two addresses:
local address which stores the source data and the destination address
to which writes the data. So I think I need to instantiate a BRAM in
the FPGA to provide the source address. What I am not clear is whether
the BRAM is compatible the IPIC logic. Here I only local address signal
to be connected to BRAM, and how to do with the left input/output ports
on the BRAM.

Are there any other ways to offer an address which could serve as the
source for the IPIC?

Thank you for the help.
Roger


Article: 96373
Subject: Re: BPSK modulation on Xilinx FPGA
From: Benjamin Marpe <Benjamin.Marpe@rwth-aachen.de>
Date: Thu, 02 Feb 2006 23:39:08 +0100
Links: << >>  << T >>  << A >>
Hi everybody,

thank you all for your answers and informations !
I'll give it a try !

Bye, BEN



news.verizon.net wrote:
> Ben,
> 
>     I used a DDS LogiCORE to generate the sine (and cosine) and then a pair 
> of two-complementor LogiCORE to handle the BPSK; you wire the data value to 
> the BYPASS pin. Works like a champ.
> 
> Marty
> 
> martin dot ryba (at) verizon dot net
> 
> "Ben Marpe" <Ben.Marpe@gmx.de> wrote in message 
> news:1138801274.996807.307800@g49g2000cwa.googlegroups.com...
> Hi everybody,
> 
> I'm trying to implement a BPSK modulation.
> A sin waveform has to be generated at a given frequency (1MHz) with
> phase offset (binary PSK i.e. 180) when transition occures on a data
> wire.
> 
> Is there any "simple" LogiCORE with BPSK functionality available for my
> Xilinx Spartan-3 - Board ?
> 
> My attempt would be a LUT in BRAM - but do I have to fill its content
> manualy ? The LUT content (e.g. 16bit) could drive a DAC.
> 
> On the other hand, If I'm forced to use a external DAC, I might use a
> DDS (e.g. AD9834) with all BPSK functionality on chip...  ?!?
> 
> I'm interested in your ideas and suggestions !
> 
> Bye, BEN
> 
> 

Article: 96374
Subject: Re: Microblaze question
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Thu, 2 Feb 2006 22:48:08 -0000
Links: << >>  << T >>  << A >>
You need to buy EDK to get MicroBlaze. Not cheap for a hobby engineer at 
US$495. You can buy from a Xilinx distributor or from the Xilinx website.

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


"spammersarevermin" <spammersarevermin@krumpli.com> wrote in message 
news:nb15u15q05dbjelg8u17oqac3fi75gm6ga@4ax.com...
> Is there any way for a hobbyist to obtain the EDK in order to work w/
> Microblaze? Or is there any other way to obtain Microblaze? I don't
> have the experience to be able to go to opencores and dive into one of
> the processors there.
>
> Thanks, Tom
> Spamming this account signifies
> your unqualified consent to a free security audit 





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