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 111300

Article: 111300
Subject: Interface standards (was Re: Dual Port RAM)
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Wed, 1 Nov 2006 11:44:38 -0000
Links: << >>  << T >>  << A >>

"KJ" <Kevin.Jennings@Unisys.com> wrote in message 
news:1162320665.907686.101530@h48g2000cwc.googlegroups.com...
>
> Ben Jones wrote:
>
>> There are many problems
>> with wizards and core generators for things like RAMs and arithmetic
>> elements - mostly, they are the wrong level of abstraction for most 
>> designs.
>
> Maybe.  I find there lack of a standard on the 'internal' side to be
> the bigger issue.

For the smaller "building block" components, I'd say that's not much of an 
issue at all. After all, how many different interfaces can you think of for 
an accumulator or shift register? Most of the differences between vendors 
seem to be superficial (e.g. naming) at that level. The problem I have with 
these low-level blocks is that they go against the basic principle of 
abstraction; instead of hiding complex functions behind simple interfaces, 
they do the exact opposite. And they hold back designers by perpetuating the 
"TTL 7400" design mentality.

>> they help designers get the most out of the silicon in those cases where
>> synthesis tools are not sophisticated enough to produce optimal results.
>
> I don't believe that a unique entity
> is required in order to produce the optimal silicon.  Once the
> synthesis hits a standardized entity name it would know to stop and
> pick up the targetted device's implementation.

I think that would be great. Of course, vendors' in-house synthesis tools 
are unlikely to support that kind of system except for portability between 
their own device families.

> Tell me what prevents everyone from standardizing on an interface to
> their components in a manner similar to what LPM attempts to do?  The
> chip guys do it for their parts, the FPGA vendors don't seem to want to
> do anything similar on the IP core side.

I don't think anything prevents it, other than whatever all-pervading force 
there is in the universe which prevents people from agreeing about things. 
:-)

The OpenFPGA initiative have a working group on core interfacing. There's 
LPM (obsolete IMHO). There's OCP. There's no shortage of people proposing 
ideas for standard interfaces, but there is a shortage of time, money and 
energy to do anything about it. I think you'll find most engineers in favour 
of standardization to some extent, but there's no one single driving force 
for adoption. Some people also see it as a barrier to innovation. (It isn't, 
but still, some people see it that way.)

> Can you list any 'standard' function IP where the code can be portable
> and in fact is portable across FPGA vendors without touching the code?

No. But I'm willing to bet that any engineer worth their salt would be able 
to write the appropriate glue logic to convert one to the other without 
working up a sweat.

In some cases, for example if a customer is using a processor-based system 
design environment such as Platform Studio (X) or SOPC builder (A), the 
"proprietary" interface to (say) a DDR SDRAM controller is hidden away, to a 
great extent, because the tools provide a system-level abstraction.

One thing that greater standardization would do is make it much easier for 
third-party IP core developers to create and sell vendor-agnostic IP. If 
that really is a viable business model nowadays...

Here's another thought - in many industries (e.g. consumer electronics and 
eletricals) the quality of the interface is a big differentiating factor for 
the purchaser. Why shouldn't this be true for digital interfacing standards 
too? A customer might have a preference for a CoreConnect-based system over 
an AMBA-based system, or vice versa, based on which of the interface's 
features are relevant to their needs.

BTW I'm not sure how much of this I really fervently believe in, just trying 
to illuminate the issue a bit.

>> I'm not denying that there is a risk of vendor lock-in, but I'd dispute 
>> that
>> it's the motivating factor for vendors to develop IP.
>
> I was only suggesting that it was an incentive...which you seem to
> agree with.

I would only say it's a question inertia, rather than malice. On a related 
note, what do engineers hate more - risk of vendor lock-in, or breaking of 
backwards compatibility?

It's certainly an interesting issue!

         -Ben- 



Article: 111301
Subject: Re: Spectre of Metastability Update
From: "Brian Davis" <brimdavis@aol.com>
Date: 1 Nov 2006 04:24:58 -0800
Links: << >>  << T >>  << A >>
Bob Perlman wrote:
>
> on Halloween night, not a single person dressed as metastability
> showed up at my door for candy
>

 We had four houses' worth of candy-filled bowls lined up on
one long table, which caused many of the evening's spectres
to exhibit distinct signs of metastability during the confectionary
selection process.

 Unlike FPGA's, the resolution time seemed inversely proportional
to the calendar age of the synchronizer :)

 Also, I don't recall anyone mentioning it, but Bob's handy dandy
guide to planetary landing FSM's seems quite topical of late:

  http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html

Brian


Article: 111302
Subject: Re: Need just a few 5V Spartan
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Wed, 1 Nov 2006 13:34:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
Jon Elson <elson@pico-systems.com> wrote:
> Spartan XL is not the 5 V Spartan, it is 3.3 V, and not pin compatible 
> with 5 V Spartan.  These chips will not work without major changes to 
> the board.  I am doing that, but going to XCS2E.  It is a complete 
> from-scratch redesign.

Consider using XC3S...E.
Why stick with XCS2E? 
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

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

Article: 111303
Subject: Re: SPDIF receiver
From: "rickman" <gnuarm@gmail.com>
Date: 1 Nov 2006 05:59:47 -0800
Links: << >>  << T >>  << A >>
aravind wrote:
> Jeff Cunningham wrote:
> > rickman wrote:
> > > aravind wrote:
> > >
> > >>Hi
> > >>     Im planning to design an SPDIF receiver for implementation on
> > >>Spartan 3 FPGA , But im not sure how to go about the design,Does any
> > >>one have ideas ?
> > >>Thank u
> > >
> > >
> > > I did a quick Google search and found some very informative entries at
> > > Wikipedia.  To get the low level format description I had to click
> > > through to the AES/EBU description and even more detail is available at
> > > one of the references given.
> > >
> > > This should not be a difficult design to figure out, but there are
> > > details that require attention depending on your application.
> >
> > One big detail is are you just receiving the data, or are you also
> > recovering a clock to feed to downstream codecs?
>
> I want to receive the data from spdif and convert it to I2S format to
> shift out the audio data to a dac such as cs4334.How do i sample the
> spdif signal ,synchronize it and convert the biphase mark code to
> normal 16 bit audio data in a register.
>    I've done all the basic stuff in vhdl like multiplexed 7 segment
> display drivers,simple programs on picoblaze processor,etc.

The data stream is BMC which is very easy to decode.  You just need to
consult some references and it should be very obvious.  You need to
sync your data recovery to the transitions between the bit cells.  Get
the value of the input following the rising or falling edge.  Wait 3/4
bit time and sample the input again.  If they match, you have a zero
bit, if they are different you have a 1 bit.  Then wait for the next
edge on the input.  You will be bit cell synchronized after sampling a
zero bit.

The SPDIF data stream is simply the data with some framing around it.
If you read a few references the structure is also very simple and easy
to parse.  A simple counter with a synchronization circuit should
suffice.

It may not be obvious, but you need to use the data stream clock to
generate the clock for your DAC.  If you don't, you will either drop
data or have to live with a lot of jitter in the sample clock which
causes much audio distortion.

The digital aspects of this design are very straightforward, the analog
aspects are not.


Article: 111304
Subject: Re: Nios 2 application running from external ram
From: Frank van Eijkelenburg <someone@work.com.invalid>
Date: Wed, 01 Nov 2006 15:29:40 +0100
Links: << >>  << T >>  << A >>
Frank van Eijkelenburg wrote:
> Hi,
> 
> I have a bootloader running from internal ram (m4k blocks). I also build 
> a standalone application to run from external ram. The application is a 
> .bin file which is sent to the bootloader through a serial interface 
> (RS232). The bootloader copies the application to external ram and 
> executes it. My application is built to run from address 0x00200000. If 
> I make a .bin file from the generated .elf file I get a file of about 2 
> MB. This is because the alt_exception and alt_irq_handler is laid at 
> address 0x20 and 0xEC. AFAIK this is not necessary. Do I have to make a 
> linker file to fix this? Or should I use another startup assembly file? 
> In case of a linker file, does anyone have an example for this situation?
> 
> So the bootloader runs from internal ram (with base address 0) and the 
> application runs from external ram (with base address 0x00200000).
> 
> TIA,
> Frank

I have to use a custom linker script and I found an easy way to make it (at the 
nios forum):

- take the file generated.x in the system library directory;
- copy the file to a location which is not deleted with a "clean project" action;
- search for the sections .entry and .exceptions and map them to external ram;

  .entry :
    {
        KEEP (*(.entry))
    } > sram

    .exceptions :
    {
        . = ALIGN(0x20);
        *(.irq)
        KEEP (*(.exceptions));
    } > sram

- in the system library properties tell the IDE you want to use a custom linker 
script.

Article: 111305
Subject: Re: Problema when upgrading from Xilinx 8.1 to Xilinx 8.2
From: "Guru" <ales.gorkic@email.si>
Date: 1 Nov 2006 06:42:49 -0800
Links: << >>  << T >>  << A >>
Using Virtex4FX12, laptop P4M 1.7GHz and ISE 8.1 SP3 and EDK 8.2 SP1.
Strange, because I rebuld one MB project in 8.2 for S3ESK and it worked
fine. I think this are some bugs that emerge from time to time. Lets
pray that EDK SP2 will solve the problem.

Cheers,

Guru


Zara wrote:
> On 29 Oct 2006 09:43:10 -0800, "Guru" <ales.gorkic@email.si> wrote:
>
> >I am having about the same experience.
> >I upgraded my computer to EDK/ISE 8.2
> >
> >1. I upgraded my GSRD2 (PPC, MPMC2, TEMAC) design to v8.2. There were
> >actually no problems detected until I used the flashwriter.tcl script.
> >I does not work at all. OK, minor thing to remedy.
> >
> >2. I upgraded my PPC CoreConnect project to 8.2. First the XMD connect
> >failure (wrong processor version 0x00000000). Then I connected
> >secesfully using "connect ppc hw", but the design does not work at all
> >- probably some hw error. The sw crashes when setting interrupt
> >controller (working nice in 8.1).
> >
> >Fu.. that 8.2 and hope for the SP2  to remedy the problems.
> >
> >Cheers,
> >
> >Guru
>
> I am jus wondering if ther problem lies:
> 1. Either in the target selected (some problem with Syn/Xlat/Map/Par):
> I am using an Spartan 3: 3S400
> 2. Or in the Computer: I am using an AthlonX2, both in the dual
> 8.1/8.2 installation, and in a clean 8.2 installation on a bran new
> laptop, that also fails.
> 
> Antti? Guru? Do you see any recurrence here?
> 
> Zara


Article: 111306
Subject: Re: SPDIF receiver
From: "aravind" <aramosfet@gmail.com>
Date: 1 Nov 2006 07:02:50 -0800
Links: << >>  << T >>  << A >>

Ian wrote:
> On 2006-10-31, aravind <aramosfet@gmail.com> wrote:
> >      Im planning to design an SPDIF receiver for implementation on
> > Spartan 3 FPGA , But im not sure how to go about the design,Does any
> > one have ideas ?
>
> How *not* to do it:
>
>   http://projects.jusme.com/project/spdifdac
>
> (That's my design so I can say that :)
>
> HTH,
> --
> Ian
>
> "Tamahome!!!" - "Miaka!!!"
does your design support only 44.1khz ?if yes what modifications have
to be done to support 48khz


Article: 111307
Subject: Re: filter design for low-pass
From: will.parks@gmail.com
Date: 1 Nov 2006 07:04:02 -0800
Links: << >>  << T >>  << A >>
Thanks for all the feedback! I'm going to chew on this for a few hours!

But just to clarify, the source of the noise is primarily, but not
soley, from the system itself. It's a bead in a viscous fluid. It is
being driven by brownian motion, which has a power spectrum (amplitude
versus frequency) that goes as 1/f^2. The bead is a sphere, and it has
viscous drag, so the power spectrum is flat until 10kHz and then it
rolls off.

Following the bead at all frequencies is not yet practical. But we
certainly don't want to alias the 2 kHz motions down to our 200 Hz
control loop. The flat region of the power spectrum is 0.1mV per root
hertz, so the whole idea is to filter down to the time response of the
the instrument (200 Hz) and at the same time get improved resolution.
I.e. at 10 kHz, the signal peak-to-peak fluctuations should be 10 mV,
but at 200 Hz, it should be 1.4 mV (providing I don't alias anything!)
So I think in this case, decimation doesn't help?

These questions about bandwidth and noise- are there any good books
that address this. I've actually been picking it up as I go, as I am a
scientist and not an engineer, so just the first step of quantifying
the resolution of our instrument in nm per root hertz (taking the lead
from electrical engineers) was a big step forward in my understanding.
For example, another quesiton I've had in my mind is how to deal with
an attenuated signal, ie, what if I sampled at 50 kHz  where the signal
is rolling off due to viscous drag, and tried to compare it to the rest
of my signal. I'm sure this is a really basic concept in electrical
engineering, so maybe someone knows of a book that speaks about
bandwidth and noise and even the fundamental concept of listing noise
in nm per root hertz, and how that works, ie does the distribution of
noise have to be normal or gaussian, does it have to be flat, etc.

Or maybe there isn't such a book and you could write one?

Will

On Oct 31, 10:37 pm, Ray Andraka <r...@andraka.com> wrote:
> will.pa...@gmail.com wrote:
> > I think you are right that sampling and then filtering does not buy you
> > more S/N ratio.

Depends on the source of the noise.  It isn't going to help if you have
> wideband noise in the signal.  However, if the noise is due to
> quantization in the ADC, then by decimating you gain effective ADC bits.
>   This is sort of like averaging the error on many samples to get a
> better estimate of one sample assuming the input hasn't changed
> significantly over the many samples.  You can also shape the noise
> induced within the system by employing feedback to push the system noise
> into the stopband of your filter.   This is the principle behind
> delta-sigma converters.
>
> The classic advantage to oversampling, as I mentioned before is that it
> relaxes the specification for your anti-alias filters, making them much
> cheaper to implement.


Article: 111308
Subject: Re: SPDIF receiver
From: Jeff Cunningham <jcc@sover.net>
Date: Wed, 01 Nov 2006 10:52:25 -0500
Links: << >>  << T >>  << A >>
>>>>Hi
>>>>    Im planning to design an SPDIF receiver for implementation on
>>>>Spartan 3 FPGA , But im not sure how to go about the design,Does any
>>>>one have ideas ?
>>>>Thank u
>>>
>>>
>>>I did a quick Google search and found some very informative entries at
>>>Wikipedia.  To get the low level format description I had to click
>>>through to the AES/EBU description and even more detail is available at
>>>one of the references given.
>>>
>>>This should not be a difficult design to figure out, but there are
>>>details that require attention depending on your application.
>>
>>One big detail is are you just receiving the data, or are you also
>>recovering a clock to feed to downstream codecs?
> 
> 
> I want to receive the data from spdif and convert it to I2S format to
> shift out the audio data to a dac such as cs4334.How do i sample the
> spdif signal ,synchronize it and convert the biphase mark code to
> normal 16 bit audio data in a register.
>    I've done all the basic stuff in vhdl like multiplexed 7 segment
> display drivers,simple programs on picoblaze processor,etc.


The downstream DAC will need something like a 128 or 256 FS clock. You 
will need some sort of state machine to recognize when a flag character 
is being received. Then you can enable some combinatorial logic such 
that the trailing edge of the flag generates a FS reference edge for an 
external PLL such as a 74HC4046. Then use the PLL to multiply the 
frequency to generate the (typically) 256FS DAC clock reference.

You can then use the 256FS signal to clock your SPDIF receiver logic. 
Because the clock is locked to the data stream, you already implicitly 
know where the beginning middle and end of the bit cells are, so 
demodulating the FM data is just recognizing if there was a transition 
in the middle of the bit cell. You can then shift the data into a shift 
register, etc., all under control of the state machine.

Alternatively, if you have a local clock several times greater than the 
SPDIF bit rate, you can make a fancier state machine that recognizes 
edges, counts states to figure out where the bit cell boundaries would 
be and so on. This all digital approach removes the need for an external 
analog PLL, but can't provide a low jitter clock reference for your DAC.

You might also consider using an external SPDIF receiver from Cirrus or 
AKM or others, though that may take the fun out of it.

Article: 111309
Subject: Yet Another Survey: What are code generators worth?(was: Re: Survey: simulator usage)
From: "Thomas" <dtsi.india@gmail.com>
Date: 1 Nov 2006 08:10:07 -0800
Links: << >>  << T >>  << A >>
Generalising the question of this discussion I would like to know what
does the group here think that code generators are worth?

Say Someone comes out with a code generator which requires some  input
data say, D_in and generates a bunch of output code say, C_out.

 Given that C_out is something that you already write for your design
wether the code generator exists or not, when will the code generator
look like a fesible option?

Given the following man days(Including coding, verfying and debugging
time) for writing  D_in and generating C_out VS manual writing of
C_out, what is the price you will be willing to pay for the code
generator in each case?
---------------------------------------------
Development time in Mandays
---------------------------------------------
D_in :      Manual C_out
---------------------------------------------
1     :      10
1     :      100
1     :      1000

If such a code generator appears on the market will your management
wait until a bigname EDA comes out with a me too product or will they
buy it from a noname developer?
Regards
Thomas

Andy wrote:
> Evan Lavelle wrote:
> > Ok, is it worth any more than $0 now? :)
>
> In a word, no.
>
> Why go to the trouble of learning a new language to try to do things
> like macros, loops, random stimulus, etc. when you have the power of
> the VHDL language at your disposal in a VHDL testbench?  Now, if you
> have vectors from an external model/simulation, those can be applied
> with text-io relatively easily from within a vhdl testbench that will
> run on any vhdl simulator.
>
> My "unit level tests" are usually at a high enough level that I need a
> lot more capability than is available in any vector based scripting
> language.
> 
> Andy


Article: 111310
Subject: Re: filter design for low-pass
From: Tim Wescott <tim@seemywebsite.com>
Date: Wed, 01 Nov 2006 08:24:26 -0800
Links: << >>  << T >>  << A >>
will.parks@gmail.com wrote:
(top posting fixed)
> On Oct 31, 10:37 pm, Ray Andraka <r...@andraka.com> wrote:
> 
>>will.pa...@gmail.com wrote:
>>
>>>I think you are right that sampling and then filtering does not buy you
>>>more S/N ratio.
> 
> 
>> Depends on the source of the noise.  It isn't going to help if you have
>>wideband noise in the signal.  However, if the noise is due to
>>quantization in the ADC, then by decimating you gain effective ADC bits.
>>  This is sort of like averaging the error on many samples to get a
>>better estimate of one sample assuming the input hasn't changed
>>significantly over the many samples.  You can also shape the noise
>>induced within the system by employing feedback to push the system noise
>>into the stopband of your filter.   This is the principle behind
>>delta-sigma converters.
>>
>>The classic advantage to oversampling, as I mentioned before is that it
>>relaxes the specification for your anti-alias filters, making them much
>>cheaper to implement.
 >
> Thanks for all the feedback! I'm going to chew on this for a few hours!
> 
> But just to clarify, the source of the noise is primarily, but not
> soley, from the system itself. It's a bead in a viscous fluid. It is
> being driven by brownian motion, which has a power spectrum (amplitude
> versus frequency) that goes as 1/f^2. The bead is a sphere, and it has
> viscous drag, so the power spectrum is flat until 10kHz and then it
> rolls off.

Then the advantage to sampling fast and filtering is that you insure 
that your ADC noise _isn't_ part of your system noise.  If you cut out 
noise at all you'll be cutting out noise that you can't do anything 
with, anyway.
> 
> Following the bead at all frequencies is not yet practical. But we
> certainly don't want to alias the 2 kHz motions down to our 200 Hz
> control loop. The flat region of the power spectrum is 0.1mV per root
> hertz, so the whole idea is to filter down to the time response of the
> the instrument (200 Hz) and at the same time get improved resolution.
> I.e. at 10 kHz, the signal peak-to-peak fluctuations should be 10 mV,
> but at 200 Hz, it should be 1.4 mV (providing I don't alias anything!)
> So I think in this case, decimation doesn't help?

I'm not clear on where your control loop is, but if your instrument is 
inherently low-pass you should be able to control it with the full 
bandwidth signal, noise and all, and let it follow as best as it can. 
Assuming that this doesn't overload your actuators, and that you aren't 
limited to a 200Hz sampling rate, you'll get pretty close to an optimal 
control.

If it _does_ saturate or overload your actuators, of course, then 
low-pass filtering is indicated.
> 
> These questions about bandwidth and noise- are there any good books
> that address this.

The three books that I have, in ascending order of difficulty are:

"Information Transmission, Modulation and Noise" by Schwartz,
"Probability, Random Variables, and Stochastic Processes" by Papoulis,
and
"Detection, Estimation, and Modulation Theory" by Van Trees.

But the one that I hear recommended most often is "Signals and Noise" by 
Proakis (or something like that).  I think if you searched a book site 
on "signals" and "noise" you'd do well.  Stay away from the Van Trees 
book unless you can take a class and have _lots_ of time.  It's very 
useful, but extremely challenging.  It's one of the few books that I 
have to refer back to constantly, because the material is difficult 
enough that I just can't remember all of it all the time.

> I've actually been picking it up as I go, as I am a
> scientist and not an engineer, so just the first step of quantifying
> the resolution of our instrument in nm per root hertz (taking the lead
> from electrical engineers) was a big step forward in my understanding.
> For example, another quesiton I've had in my mind is how to deal with
> an attenuated signal, ie, what if I sampled at 50 kHz  where the signal
> is rolling off due to viscous drag, and tried to compare it to the rest
> of my signal. I'm sure this is a really basic concept in electrical
> engineering, so maybe someone knows of a book that speaks about
> bandwidth and noise and even the fundamental concept of listing noise
> in nm per root hertz, and how that works, ie does the distribution of
> noise have to be normal or gaussian, does it have to be flat, etc.
> 
> Or maybe there isn't such a book and you could write one?
> 
> Will
> 
> 
> 


-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 111311
Subject: Re: Xilinx ISE, where do the pins go?
From: "Matthew Hicks" <mdhicks2@uiuc.edu>
Date: Wed, 1 Nov 2006 10:25:39 -0600
Links: << >>  << T >>  << A >>
No, if a pin is pulled up, it will have a pullup circuit in the schematic, 
which you can add.  The schematic is saying that the pin isn't connected 
which what that means may well be device dependent.


---Matthew Hicks


"scott moore" <nospam@nowhere.com> wrote in message 
news:SIqdnXM8K7yro9XYnZ2dnUVZ_vSdnZ2d@comcast.com...
> Hi, it seems obvious, but I'll ask the question anyways to be sure.
>
> My dual port ram on a Spartan 3 does not use the rst or ena inputs, nor
> have but one clock (clka). On the schematic view, it shows these pins
> going nowhere. Can I assume this is "shorthand" for "goes to pullup"?
> The documentation on the embedded rams says that pullup of unused inputs
> is recommended, because "it takes no routed resources", vs. zero driven
> inputs. This implies there is a special bit to pull up right at the
> input. Does the unconnected pin on the schematic represent this?
>
> Thanks,
>
> Scott Moore 



Article: 111312
Subject: Re: Dual Port RAM
From: "Andy" <jonesandy@comcast.net>
Date: 1 Nov 2006 08:40:45 -0800
Links: << >>  << T >>  << A >>
The main reason I don't instantiate memory primitives is because of the
restrictions on address and data types (to SLV). I usually have an
integer subtype for the address (the array index when inferring
memory), and store anything from integer to enumerated (i.e. state
variables) to whole records in them. You can't do that with the
primitives, without putting a wrapper around it, and then when you try
to examine the contents of the memory during simulation, they're all
just bits, and you have to manually convert back to your record, enum,
etc. Inferring memory from arrays, especially in applications where the
memory is not tied to some sort of pre-existing data and address bus,
also allows a more functional descriptive style, rather than an
implementation-specific style. I focus on the behavior first, then
tweak the implementation to get the performance I need (if any tweaking
is needed).

The syntesis tools have started recognizing sub-word write enables in
inferred memories, which allows inferring memories with wider data
paths on the output than the input, now they just need to recognize
muxing on the output to allow inferring memories with wider inptuts
than outputs.

Andy


Ray Andraka wrote:
> KJ,
>
> This is actually a fairly common usage  model for the Xilinx dual port
> RAMs. It lets you, for example store two words per clock on one port and
> read them one word per clock on the opposite port at perhaps a faster
> clock rate. The data width and address width vary inversely so that
> there are always 18k or 16K bits in the memory (18K for the widths that
> support the parity bit).  For example, if you set one port for 36 bit
> width, that port has a depth of 512 words.  If you then set the other
> port for 18 bit width, it has a 1K depth, and the extra address bit (the
>   extra bits are added at the lsbs) essentially selects the low or high
> half of the 36 bit width for access through the 18 bit port.  Similarly,
> a 9 bit wide port is 2K deep and accesses a 9 bit slice of that 36 bit
> word for each access, with the slice selected with the 2 lsbs of the 9
> bit wide port's address.
>
> I've found the easiest way to deal with the dual port memories is to
> instantiate the primitives.  Xilinx has made it far easier with the
> virtex 4 which has a common BRAM element for all aspect ratios with
> generics on it to define the width.  Previously, you needed to
> instantiate the specific primitive with the right aspect ratios on each
> port.  I found it easiest to develop a wrapper for the memory that uses
> the width of the address and data to select the BRAM aspect ratio and
> instantiate as many as are needed to obtain the data width, that way the
> hard work is done just once.  This is especially true with the older
> style primitives.


Article: 111313
Subject: De-serializer using Xilinx DCM
From: "fp" <fpga002006@yahoo.com>
Date: 1 Nov 2006 08:43:41 -0800
Links: << >>  << T >>  << A >>
I am working on a 'de-serializer' with Xilinx DCM.  The single-bit
input stream is sampled by an 8X clock.  After 8 bits are stored the
register, it activates a single-clock 'done' signal to inform the
1X system to retrieve the data.  The data, of course, should only be
read once.

I am thinking using a flag register to interface the two systems.  The
register is controlled by the 8X clock.  The done signal sets the flag
and the 1X system resets the flag after read. Since DCM is used,
presumably there is no meta-stability issue.

Please comment whether this approach is feasible or provide pointer to
some reference designs.

Thanks in advance.

S. C.


Article: 111314
Subject: Re: A spectre is haunting this newsgroup, the spectre of metastability
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Nov 2006 08:55:22 -0800
Links: << >>  << T >>  << A >>
Just make sure you NEVER duplicate the one flip-flop that is supposed
to synchronize the asynchronous input. Then a 1 ps input delay or
set-up time difference can spell disaster.
Peter Alfke

On Nov 1, 2:32 am, "Ben Jones" <ben.jo...@xilinx.com> wrote:
> "Andreas Ehliar" <ehl...@lysator.liu.se> wrote in messagenews:ei8e0q$avt$1@news.lysator.liu.se...
>
>
>
> > On 2006-10-31, Ben Jones <ben.jo...@xilinx.com> wrote:
> >> In fact, register duplication rarely makes timing better; in fact in many
> >> high-performance pipelined designs, it can make it much worse
> >> (explanation
> >> available on demand).
>
> > I guess I'll bite and see if my understanding is close to what you have
> > in mind:
>
> > My feeling is that register duplication could worsen a design with
> > combinatorial logic followed by a flip flop. This means either that
> > the combinatorial logic has to be duplicated (which would enlarge the
> > design and perhaps slow down the circuit due to extra routing, or
> > by only duplicating the flip flop which will certainly demand extra
> > routing since it is normally possible to place a FF directly after a LUT
> > using only high speed dedicated routing.Got it in one. The "enlargement" problem isn't much of a problem, since in
> FPGA technology if you need to allocate a new register then you basically
> get the preceding LUT for free. However, it's the "extra routing" problem
> that's the killer.
>
> > On the other hand, I can't really see that register duplication will make
> > the performance much worse (unless the synthesizer makes very bad choices)Say your design is supposed to run at 400MHz (2.5ns clock period). The extra
> route from the combinatorial output of the LUT to the input of the "extra"
> register added by the replication process may be 500ps. That's 20% of your
> cycle budget! Often, it's more like 800ps... of course if your clock speed
> is only 100MHz, this is much less of an issue.
>
> There may be a few scenarios in which register duplication really is a good
> thing, but in my experience synthesis tools don't always find them. So I
> tend to just leave this "feature" turned off.
> 
> Cheers,
> 
>          -Ben-
> 
> (Whoops, off topic...)


Article: 111315
Subject: Re: Spectre of Metastability Update
From: "Andy" <jonesandy@comcast.net>
Date: 1 Nov 2006 09:13:16 -0800
Links: << >>  << T >>  << A >>
In my younger days designing state machines in PALs, we did not have
the luxury of pre-synchronizing every asyncrhonous input in its own
flop.

So we handled asynchronous inputs slightly differently.

We constrained the state machine and state mapping such that there was
only, ever two destination states based on an asynchronous input at any
given time, and both of those destinations had to be adjacent on a K
map (for those of you too young to know, that means the two states
differed in only one bit, and that one bit becomes the "syncrhonizer").
Sometimes it was in a loop/branch scenario, where one destination was
the current state, and one the adjacent next state, or sometimes it was
two new destination states, both adjacent to each other. Oddly enough,
those two destination states (so long as they are the only possible
destinations) don't have to be adjacent to the current state.

The primary benefit of this was that the syncrhonizer register could
pull extra duty in other parts of the state machine as just another
state bit, or even as a syncrhonizer for another input. AND-OR arrays
have their advantages when it comes to overcoming glitches due to
simultaneous input changes that kill LUT based logic.

For example in the Mongo Lander FSM, if Idle and Fire_Retro_Rockets are
adjacent states on the Kmap, then the one register that differs between
them is the synchronizer, and so long as sufficient timing slack is
reserved for MS settling, no separate synchronizer is needed. Note that
because other transitions in the state machine are not based on async
inputs, they need not be adjacent on the Kmap.

In an environment where we had to manually assign state encodings
anyway, and registers were at a premium, this technique worked very
reliably, so long as there was sufficient slack to allow for MS to
settle out (i.e. we did not have the equivalent of a second flop
behind the syncrhonizing flop) for a reasonable MTBF.

In today's design environment, we rarely manually assign states, and
registers are plentiful, so this technique is rarely employed. Also,
separately synchronizing asynchronous inputs is more easily auditable
in code reviews than the old adjacent-state approach.

Andy


Brian Davis wrote:
> Bob Perlman wrote:
> >
> > on Halloween night, not a single person dressed as metastability
> > showed up at my door for candy
> >
>
>  We had four houses' worth of candy-filled bowls lined up on
> one long table, which caused many of the evening's spectres
> to exhibit distinct signs of metastability during the confectionary
> selection process.
>
>  Unlike FPGA's, the resolution time seemed inversely proportional
> to the calendar age of the synchronizer :)
>
>  Also, I don't recall anyone mentioning it, but Bob's handy dandy
> guide to planetary landing FSM's seems quite topical of late:
>
>   http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html
> 
> Brian


Article: 111316
Subject: Re: De-serializer using Xilinx DCM
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Nov 2006 09:14:51 -0800
Links: << >>  << T >>  << A >>
Are you re-inventing the receive portion of a UART?
Peter Alfke

On Nov 1, 8:43 am, "fp" <fpga002...@yahoo.com> wrote:
> I am working on a 'de-serializer' with Xilinx DCM.  The single-bit
> input stream is sampled by an 8X clock.  After 8 bits are stored the
> register, it activates a single-clock 'done' signal to inform the
> 1X system to retrieve the data.  The data, of course, should only be
> read once.
>
> I am thinking using a flag register to interface the two systems.  The
> register is controlled by the 8X clock.  The done signal sets the flag
> and the 1X system resets the flag after read. Since DCM is used,
> presumably there is no meta-stability issue.
>
> Please comment whether this approach is feasible or provide pointer to
> some reference designs.
> 
> Thanks in advance.
> 
> S. C.


Article: 111317
Subject: Re: Dual Port RAM
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 1 Nov 2006 09:22:21 -0800
Links: << >>  << T >>  << A >>
KJ wrote:

> And just exactly which standard interfaces are we talking about?  DDRs
> have a JEDEC standard but the 'user' side of that DDR controller
> doesn't have a standard interface.

EXACTLY.

The few times I needed an SDRAM interface, I had to write it myself.
Everyone has example interface cores and such, but mostly they're
tailored to talk to a generic microprocessor bus.  If your logic
doesn't work that way, then you spend more time fighting the generic
back-end interface and it ends up being faster to write the whole
module yourself.

-a


Article: 111318
Subject: Re: Spectre of Metastability Update
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Nov 2006 09:24:04 -0800
Links: << >>  << T >>  << A >>
Andy, neat idea...
Gray-coded counters are popular for the same reason.
Peter Alfke

On Nov 1, 9:13 am, "Andy" <jonesa...@comcast.net> wrote:
> In my younger days designing state machines in PALs, we did not have
> the luxury of pre-synchronizing every asyncrhonous input in its own
> flop.
>
> So we handled asynchronous inputs slightly differently.
>
> We constrained the state machine and state mapping such that there was
> only, ever two destination states based on an asynchronous input at any
> given time, and both of those destinations had to be adjacent on a K
> map (for those of you too young to know, that means the two states
> differed in only one bit, and that one bit becomes the "syncrhonizer").
> Sometimes it was in a loop/branch scenario, where one destination was
> the current state, and one the adjacent next state, or sometimes it was
> two new destination states, both adjacent to each other. Oddly enough,
> those two destination states (so long as they are the only possible
> destinations) don't have to be adjacent to the current state.
>
> The primary benefit of this was that the syncrhonizer register could
> pull extra duty in other parts of the state machine as just another
> state bit, or even as a syncrhonizer for another input. AND-OR arrays
> have their advantages when it comes to overcoming glitches due to
> simultaneous input changes that kill LUT based logic.
>
> For example in the Mongo Lander FSM, if Idle and Fire_Retro_Rockets are
> adjacent states on the Kmap, then the one register that differs between
> them is the synchronizer, and so long as sufficient timing slack is
> reserved for MS settling, no separate synchronizer is needed. Note that
> because other transitions in the state machine are not based on async
> inputs, they need not be adjacent on the Kmap.
>
> In an environment where we had to manually assign state encodings
> anyway, and registers were at a premium, this technique worked very
> reliably, so long as there was sufficient slack to allow for MS to
> settle out (i.e. we did not have the equivalent of a second flop
> behind the syncrhonizing flop) for a reasonable MTBF.
>
> In today's design environment, we rarely manually assign states, and
> registers are plentiful, so this technique is rarely employed. Also,
> separately synchronizing asynchronous inputs is more easily auditable
> in code reviews than the old adjacent-state approach.
>
> Andy
>
> Brian Davis wrote:
> > Bob Perlman wrote:
>
> > > on Halloween night, not a single person dressed as metastability
> > > showed up at my door for candy
>
> >  We had four houses' worth of candy-filled bowls lined up on
> > one long table, which caused many of the evening's spectres
> > to exhibit distinct signs of metastability during the confectionary
> > selection process.
>
> >  Unlike FPGA's, the resolution time seemed inversely proportional
> > to the calendar age of the synchronizer :)
>
> >  Also, I don't recall anyone mentioning it, but Bob's handy dandy
> > guide to planetary landing FSM's seems quite topical of late:
>
> >  http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html
> 
> > Brian


Article: 111319
Subject: Re: Dual Port RAM
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 1 Nov 2006 09:29:02 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> KJ, You like standards.
> We just finished implementing PCIexpress. When I look at the complexity
> of that standard, I just cringe. I cannot fathom why one needs so much
> stuff to communicate data. But then I am old frugal and basic guy who
> believes in simplicity.

It's designed to ease the job of the person writing the host driver,
and, more important, the end user stuffing the card into his no-name
PC.  Making an interface generic enough to be usable over a wide range
of disparate uses isn't trivial.  USB and FireWire are the same way:
complexity for the engineers allows simplicity for the users.

You'd rather we go back to jumpers or DIP switches for I/O card base
address select?   Why should the end user care about where the card
lives in the address space?

-a


Article: 111320
Subject: Re: De-serializer using Xilinx DCM
From: "fp" <fpga002006@yahoo.com>
Date: 1 Nov 2006 09:40:38 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Are you re-inventing the receive portion of a UART?
> Peter Alfke
>
> On Nov 1, 8:43 am, "fp" <fpga002...@yahoo.com> wrote:
> > I am working on a 'de-serializer' with Xilinx DCM.  The single-bit
> > input stream is sampled by an 8X clock.  After 8 bits are stored the
> > register, it activates a single-clock 'done' signal to inform the
> > 1X system to retrieve the data.  The data, of course, should only be
> > read once.
> >
> > I am thinking using a flag register to interface the two systems.  The
> > register is controlled by the 8X clock.  The done signal sets the flag
> > and the 1X system resets the flag after read. Since DCM is used,
> > presumably there is no meta-stability issue.
> >
> > Please comment whether this approach is feasible or provide pointer to
> > some reference designs.
> >
> > Thanks in advance.
> >
> > S. C.

In UART, the system clock rate is much higher than the serial input and
the system can do 'oversampling'.  The situation is reverse in my
application, in which the serial input rate is much higher (and
that's why a DFS and 8X clock is used).


Article: 111321
Subject: Re: SPDIF receiver
From: Ian <${send-direct-email-to-news1021-at-jusme-dot-com-if-you-must}@jusme.com>
Date: Wed, 01 Nov 2006 17:51:37 GMT
Links: << >>  << T >>  << A >>
On 2006-11-01, aravind <aramosfet@gmail.com> wrote:
> does your design support only 44.1khz ?if yes what modifications have
> to be done to support 48khz

Yes, it's hard-wired (is that the right term for a CPLD?) to 44.1KHz timing.
To do other rates would require changes to the biphase decoder thresholds at
least, the rest should just follow the signal timing.

-- 
Ian

"Tamahome!!!" - "Miaka!!!"

Article: 111322
Subject: Re: Spectre of Metastability Update
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Wed, 01 Nov 2006 09:58:32 -0800
Links: << >>  << T >>  << A >>
On 1 Nov 2006 09:13:16 -0800, "Andy" <jonesandy@comcast.net> wrote:

>In my younger days designing state machines in PALs, we did not have
>the luxury of pre-synchronizing every asyncrhonous input in its own
>flop.
>
>So we handled asynchronous inputs slightly differently.
>
>We constrained the state machine and state mapping such that there was
>only, ever two destination states based on an asynchronous input at any
>given time, and both of those destinations had to be adjacent on a K
>map (for those of you too young to know, that means the two states
>differed in only one bit, and that one bit becomes the "syncrhonizer").

I mentioned alternate coding techniques in the Q and A.  

One of the problems with devising examples to illustrate a principle
is that they have to be simple enough for the newcomer to comprehend,
which means that they're likely to be amenable to alternate techniques
that you might not want to use generally.

<good stuff snipped>

>In today's design environment, we rarely manually assign states, and
>registers are plentiful, so this technique is rarely employed. Also,
>separately synchronizing asynchronous inputs is more easily auditable
>in code reviews than the old adjacent-state approach.

Agreed.  And making the code more easily auditable (or just more
comprehensible to the person who takes it over years from now) is a
valuable safety tip.  To paraphrase something Peter said a while back,
flip-flops and gates are cheap, but problems are expensive.

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com

Article: 111323
Subject: Re: Need just a few 5V Spartan
From: Jon Elson <elson@pico-systems.com>
Date: Wed, 01 Nov 2006 12:39:45 -0600
Links: << >>  << T >>  << A >>
Uwe Bonnes wrote:
> Jon Elson <elson@pico-systems.com> wrote:
> 
>>Spartan XL is not the 5 V Spartan, it is 3.3 V, and not pin compatible 
>>with 5 V Spartan.  These chips will not work without major changes to 
>>the board.  I am doing that, but going to XCS2E.  It is a complete 
>>from-scratch redesign.
> 
> 
> Consider using XC3S...E.
> Why stick with XCS2E? 

My reasoning, at the time this redesign started was based partly on 
price, the I/O voltages supported, and the size of the ROM needed to
download the FPGA.  This product has no CPU or other ROM on board.
I finally figured out how to use an SST serial flash memory that is
incredibly cheap.  1 Mbit for $1.85, and it takes 2 little CMOS
chips to get the ROM to start dumping its contents.

Maybe I made a mistake, but this product uses a pretty small FPGA
by today's standards.  I can get the XC2S50-something-TQ144C for
$12, I know how to mount it to a board myself, etc.  A number of the
newer stuff is in packages I at least am not so sure I can handle.

Jon

Article: 111324
Subject: Re: Need just a few 5V Spartan
From: Jon Elson <elson@pico-systems.com>
Date: Wed, 01 Nov 2006 12:46:48 -0600
Links: << >>  << T >>  << A >>
Mike Harrison wrote:
> On Wed, 01 Nov 2006 00:20:36 GMT, "John_H" <newsgroup@johnhandwork.com> wrote:
> 
> 
>>"Uwe Bonnes" <bon@hertz.ikp.physik.tu-darmstadt.de> wrote in message 
>>news:ei8iuu$elg$1@lnx107.hrz.tu-darmstadt.de...
>>
>>>Peter Alfke <peter@xilinx.com> wrote:
>>>
>>>>Have you tried the distributors, including DigiKey?
>>>>Peter Alfke
>>>
>>>For the 5 Volt Xilinx series, none of the part is on stock at Digi,
>>>and all have quite high minimum order
>>>
>>>-- 
>>>Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>>>
>>>Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
>>>--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>>
>>
>>
>>XCS30XL-4TQG144I (or C) are both in stock at Digikey but the -3 speed grades 
>>have the 60pc minimum order.  Can you get by with the different speed grade? 
>>
> 
> Have you tried www.findchips.com ? plenty of hits on a search for XC2S -is this the correct family?
> 

No. The part is XCS30-3TQ144C, and findchips says - go to Digi-Key, 
where this thread started.
I have no problem obtaining Spartan 2E, I need the original Spartan 5V 
chips.  You have to be careful of these "web hits".  I had another 
oddball part, a TI DAC chip that was on 50-week backorder.  I did a web
search, and outfits like USBid showed tens of thousands of parts in
stock at their partner's warehouses.  When I actually called them, they
told me the ONLY parts available in the entire world were in a warehouse
in Russia, and the guy wanted $60 a piece, minimum quantity 100 pieces!
I had to take salvaged parts in that case.  So, just because these 
outfits LIST a part on the web does not really mean they actually even
have access to that part!

Jon



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