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 80000

Article: 80000
Subject: Re: livedesign or ise
From: "Benjamin Menküc" <benjamin@menkuec.de>
Date: Mon, 28 Feb 2005 10:06:39 +0100
Links: << >>  << T >>  << A >>
Hi,

thank You for that estimation. I think ISE will be the right choice for me. 
From the web presentation of altium it looked like livedesign's virtual 
tools are more powerfull than ChipScope, but that seems to be a mistake.

regards,
Benjamin 



Article: 80001
Subject: Re: Problems with a 4-MicroBlaze Multiprocessor Architecture
From: =?ISO-8859-15?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Mon, 28 Feb 2005 10:07:21 +0100
Links: << >>  << T >>  << A >>
Hi Sergio,

You need to define what you mean with "live"?

MicroBlaze will start executing at 0x0 after reset.
When accessing memory where there is no code, the bus usually returns with 0x0.
This is add r0,r0,r0 on the MicroBlaze and it will then continue with the next 
address.
So it will run through all memory addresses.
You need to have code that loops the MicroBlaze or you can use the FSL for 
creating a sleep mode on MicroBlaze.
If you have a FSL input to MicroBlaze where the FSL_Exists signal is low and you 
execute a blocking FSL read instruction, MicroBlaze will halt until that signal 
is '1'. This allows you to create a simple sleep mode.

Göran

sergio.tota wrote:
> Dear Goran,
> 
> you told me that not uploading the firmware does not mean that
> MicroBlaze doesn't "work".
> 
> Do you mean that even if with no code to execute they make access to
> the OPB bus?
> If so, why?
> 
> And, there is a way to keep a MicroBlaze processor "live" without
> making it access to the OPB bus?
> 
> I think that I'll use FSL, but in the next months.
> 
> Cheers.
> 
> Sergio
> 

Article: 80002
Subject: Re: livedesign or ise
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 28 Feb 2005 10:15:24 +0100
Links: << >>  << T >>  << A >>
"Benjamin Menküc" <benjamin@menkuec.de> schrieb im Newsbeitrag
news:cvumpu$h13$01$1@news.t-online.com...
> Hi,
>
> thank You for that estimation. I think ISE will be the right choice for
me.
> From the web presentation of altium it looked like livedesign's virtual
> tools are more powerfull than ChipScope, but that seems to be a mistake.
>
> regards,
> Benjamin
>

it can not be said what is mistake or not

livedesign demos are probably cool, and some of the ChipScope features
are available in LiveDesign also, but generically ChipScope is better
doing deep FPGA scoping, and defenetly better choice if you are
doing mainly Xilinx designs, another thing is that Altium charges 9000 USD
for the tools, and ChipScope cost a less than that :)

Antti




Article: 80003
Subject: Re: Maximum Current utilized by Spartan-3
From: Mike Harrison <mike@whitewing.co.uk>
Date: Mon, 28 Feb 2005 10:18:38 GMT
Links: << >>  << T >>  << A >>
On Sun, 27 Feb 2005 22:07:24 -0600, hmurray@suespammers.org (Hal Murray) wrote:

>>If this is just a one-off or very low volume device that doesn't require
>>  a high-efficiency power source, why wouldn't you use an LDO?  They're
>>easy!  Although switchers, etc, are getting easier and more reliable,
>>they're more complicated -- just in component count alone.
>
>Beware.  Modern LDO regulators have restrictions on the ESR of the
>filter caps.  Too low or too high and they oscillate.
>
>I'm far from a wizard on this topic.  But I got burned several years
>ago so it's on my hot-list of things to check carefully and then still
>be suspicious.
>
>I think older non-LDO type linear regulators are easier to work with.
>But they often don't go down to 1.2V.

Also, bear in mind that older devices may not have the load-transient response performance that
modern high-speed logic may need.  

Article: 80004
Subject: SystemC to Verilog Translator v0.4
From: Javier Castillo <jcastillo@opensocdesign.com>
Date: Mon, 28 Feb 2005 10:25:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
OpenSoc has released a new version of his free SystemC to Verilog 
Synthesizable Subset Translator with new features like function translation 
support. 

You can download it from www.opensocdesign.com

Best Regards

Javier Castillo
jcastillo@opensocdesign.com
www.opensocdesign.com

Article: 80005
Subject: Re: Prescalable counter
From: Preben Holm <64bitNOnoNOSPAM@mailme.dk>
Date: Mon, 28 Feb 2005 11:31:50 +0100
Links: << >>  << T >>  << A >>
>> The whole idea is to build the sampling part of an digital 
>> oscilloscope. This should include sampling, triggering as in an 
>> digital storage oscilloscope.
> 
> 
>  For that, you need 1:2:5:10:20:50:100 for the best human friendly 
> timebase (rather than a long binary counter).

I agree with you on that!


>  You can code as above, with taps, and a single MUX, or you could have
> a first stage that can select a choice of divide by /1/2/5/10, as a 
> clock enable into following cascaded /10 stages that select 
> 10/100/1000/10000 etc.

I dont't what you mean by that!
What are taps? I only know taps from the DCM's (and I can't see that I 
can use that for this)

How will you use the MUX? Please sketch some VHDL or components for me 
so I can see the idea?


>  If you were being 'register frugal', (eg using a CPLD),
> then the first stage of
> /1/2/5/10/20/50 is 6 bits wide, and follow that with a number
> of /100 cascades [7 bits]

The idea is to make the smallest "die", so using only the FPGA and maybe 
some external RAM.


>  The output of this divider chain would be conditioned to be one clock 
> wide, and feed as ClkEnable into the simple binary-memory 
> scanning/loading counter - the scanner counter needs a trigger state 
> engine to Start on Signal trigger, and stop at MAX (or sooner if set).

Article: 80006
Subject: Re: Prescalable counter
From: Preben Holm <64bitNOnoNOSPAM@mailme.dk>
Date: Mon, 28 Feb 2005 11:32:44 +0100
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Preben, your English is ok, better than my limited Danish.
> You want to build a sampling scope (so do I).
> You must start with the A/D vonverter, for that's where most of you
> money goes.

I already got the A/D converter. It's 8 bit conversion and min. sampling 
rate is 1MHz and maximum of 100MHz. So I use the highest clock that 
gives me no problems at the Starter Kit (Spartan 3).

> That determines the sampling rate = clock, and you must have low
> jitter!
> The rest is not too complicated. You can use on-chip BlockRAM, but you
> need an interface to external DRAM ( cheap and easily available). I
> suppose you move all the display and human interface problems onto the
> PC (that's what I would do). Saves you a lot of work and assures good
> looks.

Well, the time planning I made for my project is to last until the end 
of june where I hope to have build the sampling circuitry with 
triggering (and pre-triggering).

> Now, designig a counter should be the least of your problems...

Yes, it's not the counter, but the prescaling that irritates me.

I read your note xl33_30 about the "unusual clock dividers". The problem 
for me is, that I need to build a configurable clock-divider and not a 
"fixed" division.

I could use clock-division since this a nice idea, but also I need the 
min. sampling rate of 1MHz. The idea could also be to use a FIFO-buffer 
that just samples at the rate of fx. 50MHz (and prescale the 
FIFO-counting) and read from the FIFO (dual-port) at a faster or slower 
rate when the fifo is full!

Article: 80007
Subject: Re: Update EDK 6.1 to EDK 6.3
From: "Chinix" <qinxi@mail.csdn.net>
Date: 28 Feb 2005 03:30:27 -0800
Links: << >>  << T >>  << A >>
I don not think it is possible
there seems to be too much different
maybe you can call xilinx or visit www.xilinx.com to get a resolution


Article: 80008
Subject: synthesis tool for systemc
From: "Chinix" <qinxi@mail.csdn.net>
Date: 28 Feb 2005 03:39:18 -0800
Links: << >>  << T >>  << A >>
hello
I wish you could recommend a synthsis tool for systemC.
It will be really wonderful if the tool is free for download.
I know "Colexica" and "cocentric" ,but never use them.
Who can give me some tips of these tools.
Thanks


Article: 80009
Subject: Re: I2C protocol to communicate between FPGAs
From: "Anthony Fremont" <spam@anywhere.com>
Date: Mon, 28 Feb 2005 12:34:05 GMT
Links: << >>  << T >>  << A >>

"Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote in message
news:IevUd.2761$Qd1.1132@newsfe2-gui.ntli.net...
> "Anthony Fremont" <spam@anywhere.com> wrote in message
> news:aQtUd.66873$cW2.23375@fe2.texas.rr.com...
> >
> >> I see "TWI" in data sheets
> > I see this done also but, according to Philips, it doesn't alleviate
the
> > end user of the responsibility of acquiring a license.  Here let me
> > quote them, I hope they don't sue me for copyright violations:
>
> > "It is Philips's position that all chips that can talk
> > to the I˛C bus must be licensed."
>
> Any microcontroller with two I/O pins that can be
> switched from 0V to hi-z can talk to the I2C bus.

I agree, but I think they mean chips that are actually programmed.

> I heard that they didn't mind you making an I2C master that can talk
to I2C
> slaves, since most of their I2C-ready chips were slaves for TV innards
etc.
> and they could not really demand a licence from potential customers.
>
> However I heard they did not want to allow people free rein to make
> competing slave chips, so they did demand a licence fee on that.

Well, that could be I suppose, but my qoute was directly from Philip's
web site.

> > Well, how do you like that?   They see no end to their patent's
reach.
> > I maintain, however, that many of their patents have likely expired.
> > I've sure never seen Philips defending their patent on I2C as
vehemently
> > as the above quote would indicate.  Me thinks they don't want to
make to
> > many waves about their "obvious" technique lest they lose out on all
the
> > companies that currently pay them.
>
> When I was in the consumer electronics arena, word was that Philips
> developed stuff like the I2C chips for TVs and RC5 / RC6 for their own
TVs
> etc, and their chip making branch was their to serve their consumer
goods
> making branch. They would sell their chips to others to spread the NRE
but
> they would not make much effort to support them. After all you might
be a
> competing TV maker.
>
> They made the RC5 standard public but it was not a very tight spec and
some
> manufacturers used unassigned codes for their own purposes. So when
they
> came up with RC6 they didn't bother publicising standards at all.
>
> > As long as you need to send data in both directions simultaneously,
> > I suppose it is.
>
> Well, just ignore the stuff you don't want.
>
> > It does require 50% more wires though
> > (2-wire I2C vs. 3-wire SPI)
>
> One more wire is not a huge burden.
>
> > Isn't it amazing how no-one needs a ground to
> > communicate?
>
> > You kinda make SPI sound like a panacea compared to I2C
>
> Not my intention.
>
> The OP sounded like he just needed a point to point link,
> thus the SPI would be good enough.
>
> > Real SPI requires chip select pins for each slave device
>
> I know.
>
> But if he only has the one slave, that's only one pin.
>
> > the total number of wires to 3 +
> > number_of_slave_devices (not counting the ground),
>
> True, and I2C tackles that issue.
>
> > inconvenient and wasteful IMO.
>
>
>
>
> > There are also I2C devices that have a
> > maximum speed of 2 MHz.
>
> That is beyond the I2C spec, which is 100 kbps or 400 kbps in the
faster
> version.
> I2C slaves are not obliged to run that fast, so you cannot rely on an
I2C
> slave being that fast.
>
>
> > AFAIK, SPI is not that much faster than that
>
> But the SPI spec insists on a higher speed, thus if a slave say it
uses SPI
> then the guaranteed speed is higher.
>
> > There does seem to be some discrepancy out there as to what
constitutes
> > a START condition.  Some vendors think you have to bring the clock
low
> > after bringing the data low before considering it a START.
> > That's not how Philip's describes it though
> > as they say nothing about bringing the
> > clock low to complete the start condition.
>
> If Philips own the spec, then what they say _is_ the spec.
> If other vendors wish to diverge, then they should look out.
>
> Maybe Philips should tighten up the spec.
>
> I have noticed that I2C slave interface on Microchip's PIC is a crock
of
> shit.
> It locks up if it gets confused, then doesn't allow you to escape from
it by
> software.
>
> >> I2C master behaviour is easily implemented by
> >> bit-bashing a pair of open-collector pins.
> >
> > I agree.  I've just been doing this for the first time ever with
some
> > serial EEPROMs and a DS1307 real-time clock chip.  I like it, it's a
> > cake walk compared to Dallas 1-wire i/o.  ;-)
>
> It is nice eh?
>
> Though I did find there were some quirks in various I2C slave chips.
> My LM75 thermometer isn't talking to me yet!
> I think it wants a 100 nF decoupler.

Hard telling.  I had real good luck when I recently implemented my bit
bang I2C stuff.  It worked the first time out.  However, I can easily
imagine how frustrating solving a problem could potentially be.  I don't
own a DSO or logic analyzer so I rely allot on fully understanding the
protocol before writing that first line of code.  The exception to this
was when I wrote a Dallas 1-wire search routine.  I didn't really
understand it all until I was done writing the code.  I blindly
implemented a flow chart that Dallas provides.  I did this in PIC
assembler, but the problem cries out for a recursive solution.

In my current project, I have a PIC talking to various serial eeproms
and a Dallas 1307 real time clock.  I2C may not be perfect, but it's
doing a nice job for me.

I've never used an LM75, but I have used an LM34 and various Dallas
1-wire temp sensors.  I really like the 1-wire temp sensors, but they
only come in Centigrade outputs.


Article: 80010
Subject: Re: I2C protocol to communicate between FPGAs
From: "Anthony Fremont" <spam@anywhere.com>
Date: Mon, 28 Feb 2005 12:51:07 GMT
Links: << >>  << T >>  << A >>

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:42228d04$1@clear.net.nz...
> Anthony Fremont wrote:
> > "Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote in message
> > news:sjkUd.840$AB1.557@newsfe4-gui.ntli.net...
> >
> >>>;-)  Also, if he's looking to sell these, he will need to obtain a
> >>>license from Phillips.
> >>
> >>IIRC you do if you want to market it with "I2C" mentioned anywhere,
> >>but if you call it something else (e.g. Two-Wire Interface or TWI)
> > then you do not.
> >>I see "TWI" in data sheets that look remarkably like I2C at first
> > glance and may be identical.
>
> You can also call it AccessBUS, which is a PC variant.

Or even SMBus?

> > I see this done also but, according to Philips, it doesn't alleviate
the
> > end user of the responsibility of acquiring a license.  Here let me
> > quote them, I hope they don't sue me for copyright violations:
> >
> > ==============================
> >
> > "A license is required for implementing an I˛C interface on a chip
(IC,
> > ASIC, FPGA, etc). It is Philips's position that all chips that can
talk
> > to the I˛C bus must be licensed. It doesn't matter how this
interface is
> > implemented. The licensed manufacturer may use its own know how,
> > purchased IP cores, or whatever.
> >
> > This also applies to FPGAs. However, since the FPGAs are programmed
by
> > the user, the user is considered a company that builds an I˛C -IC
and
> > would need to obtain the license from Philips. "
> >
> > ==============================
> >
> > Well, how do you like that?   They see no end to their patent's
reach.
> > I maintain, however, that many of their patents have likely expired.
> > I've sure never seen Philips defending their patent on I2C as
vehemently
> > as the above quote would indicate.  Me thinks they don't want to
make to
> > many waves about their "obvious" technique lest they lose out on all
the
> > companies that currently pay them.
>
> Maybe, but I have a Philips data book IC12 that states :
> " i2c BUS based system designs require no special license, and the i2c
> bus protocol is easily implemented by virtually any microcontroller on
> the market"
>
> i2c IS a trademark, and so if you want to get the perceived marketing
> of that trademark, and use it in your DOCs, Philips have to give the
OK.

Interesting.  My quote was straight from Philip's site in the licensing
area.  Perhaps the patents are finally expired?  Here is a link to a
document dated as 2H 2003:
http://www.semiconductors.philips.com/acrobat_download/various/i2c_overview_2h_2003.pdf

> <snip>
>  > There are also I2C devices that have a
> > maximum speed of 2Mhz.  AFAIK, SPI is not that much faster than that
> > even with being able to transfer data full duplex.
>
> i2c has Speed nodes at 100Khz, 400KHz, 1MHz, and 3.4MHz, but few
> devices can be found at 3.4MHz....
> SPI is now commonly spec'd to 25MHz, and some devices are 50MHz.

That's pretty fast.  I'm guessing you don't get 100M of bus length very
easily.  ;-)

> Some SPI designs use a RING scheme, which removes the multiple
> chip-select issues. With most SPI HW ports in uC, they fully support
> this RING alternative.
>
> Using as FPGA-FPGA there is no strict need to stick to anyt of the i2c
> speeds, and if you deployed it using CAN BUS buffers (or wired-OR
> configured RS422 devices) you could probably get i2c over 20MHz
>
>
> -jg
>


Article: 80011
Subject: Re: I2C protocol to communicate between FPGAs
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Mon, 28 Feb 2005 12:58:30 GMT
Links: << >>  << T >>  << A >>

"Jim Granville" <no.spam@designtools.co.nz> wrote in message 
news:42228d04$1@clear.net.nz...

> You can also call it AccessBUS, which is a PC variant.

I believe it is not a variant but a desk-top bus that uses I2C as the 
signalling protocol as a foundation. It then goes on to specify the contents 
of the messages sent across I2C.

> Using as FPGA-FPGA there is no strict need to stick to any of the i2c 
> speeds, and if you deployed it using CAN BUS buffers (or wired-OR 
> configured RS422 devices) you could probably get i2c over 20 MHz

If he is just using it for point-to-point comms there is no need to stick to 
any spec at all.

With only one bus master there is no need for wire-oring of any sort, so no 
need for CANbus buffers either.




Article: 80012
Subject: Re: I2C protocol to communicate between FPGAs
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Mon, 28 Feb 2005 13:21:08 GMT
Links: << >>  << T >>  << A >>
"Anthony Fremont" <spam@anywhere.com> wrote in message 
news:1dEUd.68226$cW2.61773@fe2.texas.rr.com...
>
>> Any microcontroller with two I/O pins that can be
>> switched from 0V to hi-z can talk to the I2C bus.
>
> I agree, but I think they mean chips that are actually programmed.

I think they mean any hardware implementation that handles much of the low 
level stuff.

I've written software to bit-bang I2C without paying a licence.

It would be pretty hard to enforce licence fees there,
unlike chips that you have to make in millions.

> I can easily imagine how frustrating solving a problem could potentially 
> be.

Most problems I hear are due to people not following the I2C spec 
faithfully.

> I rely a lot on fully understanding the protocol
> before writing that first line of code.

Yep, helps a lot. :-)

> I2C may not be perfect, but it's
> doing a nice job for me.

I don't have any complaints about I2C at all.
It is very cunning yet masters require only a couple of I/O bits to use it.

> I've never used an LM75, but I have used an LM34 and various Dallas
> 1-wire temp sensors.

> I really like the 1-wire temp sensors,
> but they only come in Centigrade outputs.

Hmm, I only see the F-word <grin> used in weather reports where they 
translate the temperature for the benefit of people who couldn't/wouldn't 
get a grip on modern units. Typically old people. If you are making a 
weather station type thing then the rounding errors of the C to F conversion 
shouldn't be a big problem.





Article: 80013
Subject: Re: synthesis tool for systemc
From: Javier Castillo <jcastillo@opensocdesign.com>
Date: Mon, 28 Feb 2005 14:45:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
You can use sc2v to translate your SystemC code to a Verilog equivalent 
one and then synthesize it with a commercial Verilog synthesis tool.
Sc2v is freely available at www.opensocdesign.com

Regards

Javier Castillo
jcastillo@opensocdesign.com


"Chinix" <qinxi@mail.csdn.net> wrote in news:1109590758.827243.293030
@f14g2000cwb.googlegroups.com:

> hello
> I wish you could recommend a synthsis tool for systemC.
> It will be really wonderful if the tool is free for download.
> I know "Colexica" and "cocentric" ,but never use them.
> Who can give me some tips of these tools.
> Thanks
> 
> 


Article: 80014
Subject: Re: publishing IP
From: Michel Billaud <billaud@labri.u-bordeaux.fr>
Date: 28 Feb 2005 16:10:06 +0100
Links: << >>  << T >>  << A >>
Jeremy Stringer <jeremy@_NOSPAM_endace.com> writes:

> One thing I guess you could consider is that the GPL can make things
> difficult for companies that want to integrate your IP block into a
> commercial product, because of the requirement to redistribute source
> code.

Well, not a big problem. Such companies are free to contact the author
for a different licensing of the same source if they have different
needs.

MB
-- 
Michel BILLAUD                  billaud@labri.fr
LABRI-Université Bordeaux I     tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération     http://www.labri.fr/~billaud
33405 Talence  (FRANCE)     

Article: 80015
Subject: Re: spartan 3 vs virtex 2
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 28 Feb 2005 07:29:08 -0800
Links: << >>  << T >>  << A >>
Read my lips:
I saird: "Virtex-II is faster".
Peter Alfke

digari@dacafe.com wrote:
> So does it mean that if my design size is less than 5M (xilinx gates
> ;-)) and i am not using the specific features of virtex-II then  will
I
> get the same performance in both spartenIII and virtex2???


Article: 80016
Subject: Re: Prescalable counter
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 28 Feb 2005 07:45:43 -0800
Links: << >>  << T >>  << A >>
Preben, I would run the A/D continuously at the fastest rate possible
with a "jitter-free" clock.
Then, in the digital domain, you can always average or throw away
samples to fit your time scale.
At the frequencies you are mentioning, you just build a synchronous
binary counter and either decode a specific value, and reset, or (my
favorite) you detect overflow and synchronously preset to a certain
value.
I wish you success.
Peter Alfke


Article: 80017
Subject: Re: block adder for Altera!
From: nisheethg@gmail.com (Nisheeth)
Date: 28 Feb 2005 07:56:50 -0800
Links: << >>  << T >>  << A >>
hi
     even i was struggling with floating point calculation in vhdl...a
simple search on google landed me on the following website.

www.perso.ens-lyon.fr/jeremie.detrey/FPLibrary/ 

i tried the routines in xilnx ise + modelsim...it worked fine.

nisheeth

Article: 80018
Subject: Re: spartan 3 vs virtex 2
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 28 Feb 2005 16:22:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
Peter Alfke <alfke@sbcglobal.net> wrote:
> Read my lips:
> I saird: "Virtex-II is faster".
> Peter Alfke

But I guess Spartan III has "more bang for the buck"  :-)

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 80019
Subject: Missing Virtex4 Speedfile
From: "Kevin Brown" <kbrown_home@hotmail.com>
Date: 28 Feb 2005 08:53:06 -0800
Links: << >>  << T >>  << A >>
Has anyone found the -12 Virtex4 speedfile that are mentioned in the
latest Xilinx press release? I haven't seen them anywhere on their
website.


-Kevin


Article: 80020
Subject: Re: block adder for Altera!
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 28 Feb 2005 09:24:52 -0800
Links: << >>  << T >>  << A >>
cecilia annovi wrote:

> my name is Cecilia and I'm a student in engineering at the university of 
> Modena & Reggio Emilia. For my disseration I must work with Altera's FPGA. 
> I must analize signals from an EEG with multipliers and adders. the signal's 
> type is real, (float precision) so I'm working, to get my pourpuse, with 
> floating point. Well, I found the multiplier for floating point in the mega 
> wizard plug in manager (altfpmult) and it works well, but I can't find an 
> adder/subtracter for floating point! I' ve tried to built one with VHDL, but 
> I'm far from the target (it's not so easy..).

First, do you really need floating point, and, if so, how big an 
exponent range do you need?   Floating point multiply isn't much 
harder than fixed point, especially if you have multiply 
hardware like many FPGAs now do.  Floating point add requires a 
barrel shifter which is pretty big.  If you want full IEEE 
standard there is a lot more logic required.

On many processors floating point is easy and just about as fast 
as fixed point, so much scientific and engineering programming 
is done that way.  That doesn't mean that it needs to be done 
that way.  Reducing the exponent range will simplify floating 
point addition somewhat, though you will have to learn something 
about floating point hardware to do that, and most likely you 
will anyway.

Though the usual reason for using FPGAs for computation is 
speed, and I don't believe that EEGs are so fast as to require 
that speed.  You might be able to do what you need in software 
on an FPGA based processor.

-- glen


Article: 80021
Subject: packages(2)
From: "cecilia annovi" <shaula82@tiscali.it>
Date: Mon, 28 Feb 2005 19:01:05 +0100
Links: << >>  << T >>  << A >>
I know I had made a big mess in my previos message..
I try to explain better and shortly...

I've received some precious advices in this newsgroup
about an unavailable block adder for floating point, and some of you adviced 
me to use libraries for floating point found in the web..

I have already included a foreign library in a project with
Xilinx Project Navigator, without any problems...but I can't do the same in 
the Quartus II of Altera !! When I compile the foreign library I find a lot 
of  errors without sense!!  (e.g. the compiler can't find the top level 
entity of the project ..)

in short:
how can I include a library in a project compiled with the quartus II 
?someone has been able to do this???

thank you...Cecilia 



Article: 80022
Subject: Re: difficult to build counter, some help please : (
From: jaxato@gmail.com
Date: 28 Feb 2005 10:20:02 -0800
Links: << >>  << T >>  << A >>
Hello, some feedback about the counter we discussed sometime back. I
did test my counter with the clock selector circuit from Peter. It
works in rtl simulation and hence, I went directly to FPGA testing,
with a chipscope core to give me feedback on the actual implementation.
It actually failed, as I was thinking, in hardware.

It sound reasonable to say that in order for this circuit to be
actually usable, we either need to put constrains on the clock
netlists, or to manually route the clock selector circuit so that it
minimizes the delay to the counters it is driving, or, as I did, to use
a bufg component so as to use the FPGA chip's clock plane.

cheers
Jacques


Peter Alfke wrote:
> I do not want to sound obnoxious, but "my" clock multiplexer is safe.
> It does not create a glitch nor a runt pulse, provided metastability
> settles within one half period. And that is practically guaranteed:
at
> the quoted clock rates, MTBF is many billion times longer than the
> expected life of the universe...
> And as I wrote before, no matter how you design with two clocks of
> unknown phase relationship, you have to deal with metastability, and
> everything becomes probabilistic...
> Peter Alfke


Article: 80023
Subject: Re: packages(2)
From: DerekSimmons@FrontierNet.net
Date: 28 Feb 2005 11:13:53 -0800
Links: << >>  << T >>  << A >>
It sounds like you are having the same frustrations I had when I first
started out. If I remember right it has do with the order the files are
compiled.

If you go into QuartusII, open your project, goto the assignments menu,
select the settings menu item the settings dialog window should open.
>From the list on the left hand side select files. You should see a list
of your source files.

First thing you should check for is if all your files are there and if
they are not then you need to add them. Second are they in the right
order? Many compiles will perform a pass to build a dependencies list.
Quartus doesn't, it expects you to put your files in the order they
need to be built.

Hope this helps.

Derek


Article: 80024
Subject: Re: Prescalable counter
From: Preben Holm <64bitNOnospamNO@mailme.dk>
Date: Mon, 28 Feb 2005 20:16:44 +0100
Links: << >>  << T >>  << A >>
> Preben, I would run the A/D continuously at the fastest rate possible
> with a "jitter-free" clock.
> Then, in the digital domain, you can always average or throw away
> samples to fit your time scale.

That's the idea I've had.

> At the frequencies you are mentioning, you just build a synchronous
> binary counter and either decode a specific value, and reset, or (my
> favorite) you detect overflow and synchronously preset to a certain
> value.

Thanks.. I never thought about a preset value and then detecting 
overflow - that's a fine idea!


Thanks for helping

Preben



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