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 71775

Article: 71775
Subject: Re: 1GHz FPGA counters
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 30 Jul 2004 08:30:38 GMT
Links: << >>  << T >>  << A >>
(previously snipped question about high speed time measurements)

Peter Alfke wrote:

> Here are my thoughts for a fairly simple implementation. If I recall, the
> original post asked for a report of the arrival time of input pulses (let's
> assume rising edges) with a resolution of 1 ns.

(snip)

If I understand the way it is done in some experiments requiring
sub nanosecond timing, they call it a TDC, time to digital converter,
and it seems to work by generating a ramp signal, and digitizing
it with a flash A/D converter at the trigger point.  Maybe a 100MHz
counter, and the sawtooth/ADC to get the low order bits.  It might
take some calibration, but numbers in the 100ps range seem to be
easily obtained.   100MHz and a 6 bit ADC would give
10ns/64 or 156.25ps.

-- glen




Article: 71776
Subject: Re: Problems with device
From: ALuPin@web.de (ALuPin)
Date: 30 Jul 2004 02:09:08 -0700
Links: << >>  << T >>  << A >>
> This code should work as far as I can tell.  The statements where you
> assign the count and trigger to themselves are not needed.  I think you
> may have included them for concern about generating latches if all cases
> are not covered.  But this only applies to combinatorial logic.  You are
> trying to infer sequential logic and so it is ok to have undefined
> cases.  The default is that the values are held if the conditions are
> not defined (such as the else in the l_count=0 test).  
> 
> I suggest that you bring out all the signals to pins, including the
> clock.  Then probe it all with a scope to see if anything is working. 
> Also make sure that the pins you want are really being used.  If nothing
> seems to work, check back to the synthesis equations to make sure your
> design is not being optimized away.  
> 

Hi Rick,

thank you for your answer.

I have looked at the synthesis equations and the RTL viewer to check
the synthesis result. It seems everything to be OK.
The PLL is running that is PLL input is running and PLL output clock
is running as well. I have routet the PLL output clock (which feeds my
small test design) to a debug pin.
But the counter is not running. I have routet the bits of the 4bit counter
to debug pins but there is nothing happening on those pins.

My functional RESET is routet into the FPGA from a debug pin. It comes out
from a watchdog.

My counter is not resettet by that RESET. Could it be that the reset
signal destroys configuration? But on the other hand that would mean that
the PLL does not run. Or is a PLL handled separately?

I do not know where to search.

Maybe you have some idea.

p.s. I am using Altera QuartusII software and Cyclone device.

Kind regards
André

Article: 71777
Subject: Foundation evaluation on linux
From: Simon <news@gornall.net>
Date: Fri, 30 Jul 2004 09:50:59 GMT
Links: << >>  << T >>  << A >>
Ok, So I'm trying to convince myself that spending the $3000 on 
Foundation will be a good move, with one of the main reasons being that 
I won't have to constantly switch back and forth from Windows (to run 
Foundation, or WebPack currently) and Linux (to run everything else).

I ordered (and eventually obtained - Xilinx *please* don't use DHL in 
the UK, it took 3 *hours* on the phone to re-arrange a missed delivery!) 
the evaluation pack, but this appears to only run on Windows, so it's 
essentially useless to me anyway - to be fair it did say it was Windows 
only, but I was hoping it would be the same package with a temporary 
licence.

So, I'll consult the collective wisdom of the group - which is probably 
what I ought to have done in the first place :-) Can I ask if there's 
anyone who's used Foundation on both architectures...

  o If there are any differences between the two ?
  o Is there anything you can't do from the Linux environment ?
  o Is Linux a completely self-contained environment for development ?
  o How stable is it ?
  o What version of Linux are you running it on ?
  o Have you tried it on an AMD64 processor ?
  o Anything else I've missed ?

(These being the main reasons I wanted to evaluate first...)

Cheers,

Simon.

Article: 71778
Subject: Re: XILINX RocketIO / MGT signal quality problems
From: Michael Mustermann <mgt_problem@gmx.de>
Date: Fri, 30 Jul 2004 11:54:27 +0200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

Hi again (I confused the names Allan und Austin in my previous posting),

> Michael,
>
> I apologize if I seemed to imply that you were new at this.
>
> Series capacitors?  Why?  When you AC couple, now you have the 
> impedance bump due to the layout from the caps, and their own ESL/ESR.

We had to manage different bias voltages for transmitter and receiver.
Thus we separated both by AC-coupling capacitors.

>
> Has anyone extracted the pcb layout and simulated the pcb traces using 
> a 3D field solver?  Have you looked at the impedance mismatch created 
> by the series caps?

No, we didn't exctract and simulate pcb traces. But TDR measurement 
showed an
impedance bump from 100 Ohms down to 80 Ohms diff. And behind the 
AC-coupling
we saw app. 115 Ohms which represented the MGT receiver.

>
> Again, I strongly suggest getting to a RocektLab which is equipped to 
> handle this.  A quick call to a disti FAE (or even a Xilinx FAE) that 
> has no real knowledge of your situation is not really going to get you 
> the help you need.

We are in steady contact with Xilinx representative and FAEs. They have 
been to our lab.
But there has not been any progress for a few weeks and no solution to 
our problem !
That's why I turned to this forum and asked for assistance.

>
> Is there a case on this?  Who is the CAE?

What means "case on this" and what is a CAE?

>
> Working with our Hotline is the best, fastest, and most effective way 
> to  solve any issue.  This forum here is probably the worst from a 
> time/accuracy/solution point of view for a specific customer issue.  
> It is very useful to ping others in the community.
>
I'm sorry for the bad public relation. Xilinx claims to have thousands 
of customers who
have boards at 3.125Gig working fine. But until this very moment, nobody 
(even in this
forum) could tell me: "I truly measured a beautiful eye at my board's 
MGT receiver! Here
is the screen shot..." Actually, can _SOMEONE_ give me such a 
confirmation? Please!

The whole thing is weird and for my personal feeling quite nebulous!

_Austin_, sorry for my honesty! I hope you don't feel offended!

Regards.

Michael

> Austin
>
> Michael Mustermann wrote:
>
>> Hi Allan, hi Austin,
>>
>> thank you for you reply, but it won't help.
>> Of course, at MGT's speeds everything becomes just esoteric.
>> But we know this, we've designed serial gigabit board for several
>> years. We are familiar to single ended and differential impedance
>> and know how to lay out a board for these signals.
>>
>> We've carried out _true_ TDR measurement with Tek CSA8000
>> series scope which is able to send a positive and a negative pulse
>> exactly at the same time. Both the board and the MGT receiver
>> don't seem to be the issue, as I wrote earlier (see below).
>>
>> When I cut off the signal path by lifting the AC-coupling capacitors
>> 100mil before the MGT receiver and short the differential pair by
>> a simple 100 Ohms termination resistor, then I get wonderful waveform
>> and eye diagram!!! So it is proven, that I do not have a problem
>> along the traces, but together with MGT receiver.
>>
>> We use such links in the opposite direction as well, with the MGT as
>> the transmitter and a competitor's chip as the receiver. All other 
>> details
>> are absolutely identical - same trace geometry, same connectors, same
>> distances - just different direction. Those links work _excellent_ 
>> and the
>> eyes look as pretty as in a schoolbook!!! So what do you thing?
>> Do I have a problem with my pcb???
>>
>> We have contacted the local FAE and he had no idea except the noise
>> at the MGT supply voltage. We were advised to measure at the
>> regulator and found app. 70mVpp noise. But even a lower noise supply
>> with 30mV hardly provided signal improvement.
>>
>> After 15" FR4 and two special high speed connector (AMP HM-Zd)
>> we get an 65mV eye opening at the MGT receiver package pin, but an
>> 650mV overall signal swing! App. 90% is degraded by reflections!
>> I could double the transmitter voltage swing, but I wonder, if this 
>> is the
>> right approch...
>>
>> I'm out of ideas now.
>> Thank you for your assistance!
>>
>> Regards.
>>
>> Michael
>>
>>
>>
>>
>> Allan Herriman wrote:
>>
>>> On Fri, 23 Jul 2004 08:03:05 -0700, Austin Lesea <austin@xilinx.com>
>>> wrote:
>>>
>>>  
>>>
>>>> Michael,
>>>>
>>>> At the speeds of the MGT signals, just about anything can be a 
>>>> 'bump in the road', and cause reflections.
>>>>
>>>> No, the termination in the receiver is not perfect, (nothing is 
>>>> perfect), but it is just fine regardless.  Thousands of customers 
>>>> have pcb's working at 3.125 Gbs error free, so it is more likely 
>>>> that you have a pcb issue in your board.
>>>>
>>>> I suggest you immediately contact your local FAE, and arrange to go 
>>>> visit one of our RocketLabs locations, where we have all of the 
>>>> equipment to troubleshoot just such an issue, and the FAEs 
>>>> associated with the RocketLab are all trained and familiar with the 
>>>> equipment, and how to address the issues.
>>>>
>>>> One of the most common mistakes made in measuring the input 
>>>> impedance, or return loss of the 100 ohm differential receiver, is 
>>>> that they measure it single ended (50 ohm) and fail to take into 
>>>> account that a differential return loss measurement is not a 
>>>> trivial or simple thing to characterize accurately.  For example, 
>>>> two single ended 50 ohm traces are NOT 100 ohms differential (they 
>>>> are less if they are routed together as they should be to be 
>>>> differential).  Bad mismatch right there!
>>>>
>>>> This goes for TDR as well.  Unless it is a true differential TDR 
>>>> measurement, you are not measuring what you need to measure (eg the 
>>>> Tek CSA8000 is the only true differential TDR scope that I know of, 
>>>> although I think Agilent now has one as well -- check!  does it 
>>>> send two impulses (or steps) at the same time of opposite 
>>>> voltages?  If not it isn't differential).
>>>>   
>>>
>>>
>>>
>>> I've used an Agilent 54754A dual 18.4GHz TDR plugin in an 86100A scope
>>> for testing 10Gbps connections.  I *think* it does a true differential
>>> measurement.  [ I don't have the documentation handy. ]
>>>
>>>  
>>>
>>>> As well, the time resolution fo the TDR may be much faster than the 
>>>> rise time of the MGT signal, and may be showing issues that do not 
>>>> affect the MGT operation (ie a mis-match at 20 GHz is not an issue, 
>>>> as the signal has no energy at 20 GHz).
>>>>   
>>>
>>>
>>>
>>> Yes, but better time resolution means better spatial resolution,
>>> allowing you to work out what went wrong with your board design.
>>>
>>> (I found this out the hard way.)
>>>
>>> Regards,
>>> Allan.
>>>  
>>>
>>  > > Hi anyone out there,
>>  > >
>>  > > we have designed a board with XILINX Virtex II Pro using the
>>  > > RocketIO / MGT serial high speed transceivers.
>>  > > Recently we experienced a problem with bit error rate (BER) and
>>  > > measured the signal quality of the MGT serial links with a 
>> 20Gsample
>>  > > scope and 5GHz differential probe. We found a very poor signal
>>  > > waveform and got an almost closed eye diagram.
>>  > > We analyzed this phenomenon and now we assume, that the signal
>>  > > degradation is caused by high reflections on the line. The 
>> overshoot
>>  > > and undershoot amounts to 50% of the singal swing. It seemed, that
>>  > > the MGT receiver's input termination does not work properly.
>>  > > Then we tried a TDR ("time domain reflectometer") measurement
>>  > > to check the impedance characteristics of our board even into
>>  > > the MGT's termination. The board traces are fine. Some impedance
>>  > > mismatches are to be seen at vias, AC-coupling capacitors and the
>>  > > Virtex II Pro package. But we think, these are not too bad, the
>>  > > mismatch is in the range of 20%.
>>  > >
>>  > > Does anyone have experience with Virtex II Pro RocketIO?
>>  > > Did anyone measure signal quality or eye diagrams on such a link?
>>  > > May the impedance mismatches cause the high ringing we found?
>>  > > Can anyone imagine the reason for the reflections though the signal
>>  > > path's impedance seems to be not so bad?
>>  > >
>>  > > At the moment I don't have a clue.
>>  > > Thank you for any hint!
>>  > >
>>  > > Michael
>>  > >
>

Article: 71779
Subject: Re: XST vhdl adder with carry out : broken carry chain
From: zeeman_be@yahoo.com (Bart De Zwaef)
Date: 30 Jul 2004 03:17:08 -0700
Links: << >>  << T >>  << A >>
Thanks for the help guys.

I agree with Symon : it's a timing issue, functionality is 100% ok.
And yes, it only happens when the carry out is the odd bit, not even.
I also believe that the problem is MAP related, not XST (although I
can not prove this).
I tried with the "KEEP" attribute (which is XST equivalent of the
synplify "syn_keep") : unfortunately this does not change anything.
Also USE_CARRY_CHAIN and some other attributes I tried didnt do the
trick.
I was hoping there would be a clean and simple workaround, because I
have a design with some 120 - 140 adders in it, I would hate to give
up on readable code. But right now I would be happy with something
that would work at all.

If I do find some solution I will surely post it here.

Bart.

"Symon" <symon_brewer@hotmail.com> wrote in message news:<2mt4u2FqmqabU1@uni-berlin.de>...
> Yeah, sorry Rick, I should clarify that when I said 'bad' I meant from a
> timing point of view, not logic. I find that the tools rarely, if ever, make
> logical errors these days. Maybe I'm just lucky? ;-)
> cheers, Syms.
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:41095A10.6B315BF7@yahoo.com...
> >
> > That would be the problem the OP had.  But the problem Symon described
> > is a coding issue.  But then he replied to my post and I may not have
> > understood what he meant.

Article: 71780
Subject: Re: Suggestions for programming flash RAM for SoC via FPGA
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Fri, 30 Jul 2004 10:38:45 GMT
Links: << >>  << T >>  << A >>
I would go with the serial line. However, keep it simple and don't use
xmodem, write your own program. I do this also to download data to the
FPGA for Flash programming. A very simple handshake with character echo
from the FPGA relieves you from struggling with handshake and buffers in
the FPGA (A PC can send up to 15 characters after you heave released
CTS!)
The donwload program is a 5 liner, you can find examples for the download
program and flash programming on my website.

Martin
--
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/


"Edmond Cote" <edmond_cote@yahoo.ca> schrieb im Newsbeitrag
news:4109c1df_4@aeinews....
>
> Hi,
>
> I'm currently trying to store non-voltatile data (32Mbits) in the flash
> memory connected to an FPGA on a protoboard (Nuhorizon's spartan3 to be
> specific), unfortunately I am not sure how to proceed.
>
> I'm thinking perhaps I could program the FPGA to pass the data from the
> JTAG pins to the memory in either a serial or parallel manner, but for
> the moment this is simply a hunch and wouldn't know how to go about
> that. Can I simply send data via JTAG using Xilinx's iMPACT software?,
I
> suppose I could also xmodem the data via RS-232, what seems to be the
> best method?
>
> If you've encountered this problem before, know of a better solution OR
> (most importantly) could point me to relevent documentation, it would
be
> appreciated.
>
> Thanks,
>
> Ed
>
>
>
>
>
>
>
>



Article: 71781
Subject: Re: XST vhdl adder with carry out : broken carry chain
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Fri, 30 Jul 2004 20:56:04 +1000
Links: << >>  << T >>  << A >>
On 30 Jul 2004 03:17:08 -0700, zeeman_be@yahoo.com (Bart De Zwaef)
wrote:

>Thanks for the help guys.
>
>I agree with Symon : it's a timing issue, functionality is 100% ok.
>And yes, it only happens when the carry out is the odd bit, not even.
>I also believe that the problem is MAP related, not XST (although I
>can not prove this).
>I tried with the "KEEP" attribute (which is XST equivalent of the
>synplify "syn_keep") : unfortunately this does not change anything.
>Also USE_CARRY_CHAIN and some other attributes I tried didnt do the
>trick.
>I was hoping there would be a clean and simple workaround, because I
>have a design with some 120 - 140 adders in it, I would hate to give
>up on readable code. But right now I would be happy with something
>that would work at all.

You don't need to change a line of your HDL source.

Write a (e.g. Perl) script to read the EDIF and locate the carry
chains.  From that you can generate a UCF which has an RPM for each
carry chain.  This will force MAP to do the right thing.

Regards,
Allan.

Article: 71782
Subject: Re: FPGA vs CPLD
From: Mario Trams <Mario.Trams@informatik.tu-chemnitz.de>
Date: Fri, 30 Jul 2004 13:50:31 +0200
Links: << >>  << T >>  << A >>
Rajeev wrote:

> Lets take an example and see what the concensus is:
> 
> Gate Count: 40K ASIC gates
> Speed: 50 MHz
> PinOut: 100 pins
> Other: ???
> 
> 
> One Configuration: Spartan-III would be a suitable fit with $20
> price tag (scaling to $10 with volume) + $3 prom.
> 
> Altenatives from Altera? Actel (may be anti fuse?)
> 
> Could some one fill in...


Where is the relation with my posting?

Mario

Article: 71783
Subject: Re: NCD difference
From: gerd?NO?SPAM@rzaix530.rz.uni-leipzig.de (Gerd)
Date: 30 Jul 2004 12:07:59 GMT
Links: << >>  << T >>  << A >>
Thomas Reinemann <thomas.reinemann@masch-bau.uni-magdeburg.de> wrote:
> against the background of partial reconfiguration, I would like to 
> determine the difference between two initial configurations (NCDs). Does 
> any Xilinx tool support this?

You are probably looking for
$ bitgen version1.ncd version1.bit
$ bitgen -r version1.bit version2.ncd diff1to2.bit


Gerd


Article: 71784
Subject: Static Timing Analysis
From: emailharvester999@yahoo.com (Chris)
Date: 30 Jul 2004 07:40:47 -0700
Links: << >>  << T >>  << A >>
I'm hoping someone out there can help me. 

We've been having lots of trouble closing the timing on our FPGAs with
our bespoke vendor supplied static timing analysis tool.

Is anyone out there using a stand alone static timing analysis tool
(other than Primetime from Synopsys, or anything supplied by the FPGA
vendors)?

What is it? How do you find using it? What was the learning curve
like?

Article: 71785
Subject: uLinux for Memec-Insight VP20 board ?
From: Rudolf Usselmann <russelmann@hotmail.com>
Date: Fri, 30 Jul 2004 21:48:57 +0700
Links: << >>  << T >>  << A >>

Just wondering if anybody has a uLinux port for the Memec-Insight
Virtex 2 pro 20 board ?

Regards,
rudi              
=============================================================
Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis

Article: 71786
Subject: Re: XILINX RocketIO / MGT signal quality problems
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 30 Jul 2004 08:02:58 -0700
Links: << >>  << T >>  << A >>
Michael,

Please email me directly with your contact information, FAE name, 
distribution FAE, etc. so I may escalate your case.  By entering a case 
in the hotline, and communicating your expectations, we know how to 
address the issue, and we can track it.  It is is not resolved quickly, 
we can escalate the issue to a team of experts.  Not dealing with a 
customer case is a serious issue for the support staff, and is dealt 
with accordingly.  Without a case number, and a contact, no one is 
taking the issue seriously, as it is not in the system as a "problem."

FAEs may just consider this something that you may be 'playing' around 
with, and does not require their attention.

I will personnaly find out why the field organization has not provided 
you with the answer, but without a case open, I can tell you right now 
that is a major factor!

Visiting a RocketLab(tm), you could see many eye patterns on real boards.

http://www.support.xilinx.com/products/xaw/hsd/simulator.htm

Is the on line tool that has been checked to show that the simulated eye 
patterns are accurate, and represent the actual eye patterns on the 
thousands of combinations.

I would suppose that others could send you their eye patterns, but that 
is up to them to decide to take the time and effort to do that.  As 
well, posting graphics on this newsgroup is highly discouraged (as the 
graphics will be removed -- text only) so they would have to respond to 
you directly, and we do not know if the email address that appears in 
your posting is valid (many are not due to spam problems).

My direct email is  austin @ xilinx . com (without the spaces).

One last comment, if the driver is also not 100 ohms matched, then any 
discontinuities upon reflection will re-reflect back to the receiver. 
There are some devices out there with very low, or very high transmit 
impedances (not ours) that have this problem.  In any system or 
standard, the SI engineering makes assumptions.  The assumption here is 
that both the Transmitter and the Receiver are to be as good a match as 
possible, so as to minimize the distortion to the eye pattern from 
'normal' (that is, unavoidable)impedance discontinuities from vias, 
connectors, series AC blocking capacitors, package, and die variations.

A simulation of an improper impedance transmitter will demonstrate this 
issue.

(rant on)

For all those who are reading this:  do not let this happen to you!  If 
you have an issue, get a case number!  Follow the case progress on-line 
through our on-line tracking system.  If at any poinht you feel progress 
is not satisfactory, ask to escalate the case (bumps it up the system to 
the next level of technical expertise).  You are the customer:  you are 
always right (by definition).  We do not have a choice.  If you ask, we 
must respond.  And we do.

(rant off)

Austin


Article: 71787
Subject: Re: 1GHz FPGA counters
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 30 Jul 2004 15:59:47 GMT
Links: << >>  << T >>  << A >>
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:OGnOc.50391$8_6.25426@attbi_s04...
> If I understand the way it is done in some experiments requiring
> sub nanosecond timing, they call it a TDC, time to digital converter,
> and it seems to work by generating a ramp signal, and digitizing
> it with a flash A/D converter at the trigger point.  Maybe a 100MHz
> counter, and the sawtooth/ADC to get the low order bits.  It might
> take some calibration, but numbers in the 100ps range seem to be
> easily obtained.   100MHz and a 6 bit ADC would give
> 10ns/64 or 156.25ps.
>
> -- glen

In some TDCs, the ramp is generated by trigger signal and sampled by the
steady clock.  If the ramp came from the clock, you'd have large
uncertainties near the corners; the harmonics to get a "nice" corner are
also huge and outside the range of affordable A/D converters.  By designing
to guarantee a (reasonably) linear ramp, the trigger-signal's start ramp can
be sampled in 2 spots on the ramp far from the "corner" giving the precise
delta voltage for one sampling clock period.  The stop ramp can also be
sampled in 2 spots on the ramp and should have the same delta voltage.  The
voltage difference between these two ramp sample pairs relative to the
voltage difference for one clock cycle will give you the offset in time
relative to one clock cycle.  But I hate precision analog beyond a few 10s
of MHz.

I prefer sinusoids.  Generating a reference sine and cosine pair at a high
frequency (say 200 MHz so nice A/Ds can be used), the two sinusoids can be
sampled with a dual-channel A/D using the incoming signal as the trigger to
get a sine/cos voltage pair.  As long as the maximum amplitudes are measured
or otherwise calibrated and the phase offset is close enough to 90 degrees
(which can be calibrated downstream), the phase of the incoming signal comes
straight from the arctan( sin/cos ) without ambiguity since the signs of the
sine and cosine dictate the quadrant.  The components to produce the clean
sin/cos pair are widely available since many RF systems use I/Q
modulation/demodulation or other "quadrature" techniques.  With 10 bit A/D
converters, the phase resolution is about 11 bits or about 2.5 ps resolution
at 200 MHz; at this point the reference jitter and A/D aperture uncertainty
will be major factors in the error budget.  The incoming signal can
transition as fast as the A/Ds can sample.

It's a pretty system and FPGAs can do a great job with cartesian to polar
conversion.



Article: 71788
Subject: What has happened to www.free-ip.com?
From: Derek_SImmons@msn.com (Derek Simmons)
Date: 30 Jul 2004 09:20:53 -0700
Links: << >>  << T >>  << A >>
Over the last couple of weeks I have tried accessing the web site
www.free-ip.com and gotten an error message. Am I the only one having
this problem or are other people having this problem?

Did something happen to this website? 

Is it mirrored someplace else on the web?

Thanks,
Derek Simmons

Article: 71789
Subject: Altera Bidi ports, Tristate Buffers & Prop. Delay?
From: pinod01@sympatico.ca (Pino)
Date: 30 Jul 2004 09:52:18 -0700
Links: << >>  << T >>  << A >>
To all,

   I've discovered that there is some significant propagation delay
between the input and bidirectional pin & bidirectional pin to output
pin in my simulation.  I've compared the function LPM_BUSTRI within
Quartus, a construction made up from Tri-state buffers within Quartus
both within a BDF graph and also made my own configuration developed
using VHDL.  They all work similarily but the concern is the
propagation delay which seems to be large (~ 7-10 ns).  This limits
the total operation of the chip that I have to 100 MHz, which is a bit
strange?  The chipset to which I synthesized too in Quartus is
EP1S10F780C6ES.

Can anyone tell me if this propagation delay is EXPECTED???  If so,
what is causing this FPGA speed limit?  Can I reduce this somehow?   I
anticipate to use this with my memory controller for PC100 SDRAM.

The configuration coded is as follows:
             (not)OE
             |
             |
            |\
            | \  
IN   -------| /-------
            |/       |
                     |----------Bidi-pin
             /|      |
OUT  -------/ |-------
            \ |
             \|
             |
             |
             OE

The functional VHDL code that I have implemented and simulated is as
follows:

LIBRARY ieee;
USE ieee.std_logic_1164.all;

ENTITY Tristate_Buffer IS

	PORT
	(
		OE	 : IN	STD_LOGIC;
		DATA_IN	 : IN	STD_LOGIC;
		DATA_OUT : OUT	STD_LOGIC;
		BUS_INOUT : INOUT STD_LOGIC
	);
	
END Tristate_Buffer;

ARCHITECTURE mainRTL OF Tristate_Buffer IS
signal bus_wire1, bus_wire2 	:STD_LOGIC;

BEGIN


	op_assign_process: PROCESS (OE, DATA_IN, BUS_INOUT)
	BEGIN
	
		IF OE = '1' THEN
			bus_wire1 <= DATA_IN;
			bus_wire2 <= 'Z';
		ELSE
			bus_wire1 <= 'Z';
			bus_wire2 <= BUS_INOUT;
		END IF;
		
		DATA_OUT <= bus_wire2;
		
	END PROCESS op_assign_process;

	bus_assign_process: PROCESS (bus_wire1)
	BEGIN
		
		BUS_INOUT <= bus_wire1;
		
	END PROCESS bus_assign_process;

END mainRTL;

Article: 71790
Subject: [VHDL] Personnal type as port
From: Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com>
Date: Fri, 30 Jul 2004 18:54:45 +0200
Links: << >>  << T >>  << A >>
Hi

I know how to define a personal type to use as a signal but how to use one as a port ?


Sylvain Munaut

Article: 71791
Subject: Re: What has happened to www.free-ip.com?
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 30 Jul 2004 13:03:18 -0400
Links: << >>  << T >>  << A >>
Derek Simmons wrote:
> 
> Over the last couple of weeks I have tried accessing the web site
> www.free-ip.com and gotten an error message. Am I the only one having
> this problem or are other people having this problem?
> 
> Did something happen to this website?
> 
> Is it mirrored someplace else on the web?

I am not able to connect either.  The domain name is still registered. 

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 71792
Subject: Re: Altera Bidi ports, Tristate Buffers & Prop. Delay?
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 30 Jul 2004 13:05:19 -0400
Links: << >>  << T >>  << A >>
Pino wrote:
> 
> To all,
> 
>    I've discovered that there is some significant propagation delay
> between the input and bidirectional pin & bidirectional pin to output
> pin in my simulation.  I've compared the function LPM_BUSTRI within
> Quartus, a construction made up from Tri-state buffers within Quartus
> both within a BDF graph and also made my own configuration developed
> using VHDL.  They all work similarily but the concern is the
> propagation delay which seems to be large (~ 7-10 ns).  This limits
> the total operation of the chip that I have to 100 MHz, which is a bit
> strange?  The chipset to which I synthesized too in Quartus is
> EP1S10F780C6ES.
> 
> Can anyone tell me if this propagation delay is EXPECTED???  If so,
> what is causing this FPGA speed limit?  Can I reduce this somehow?   I
> anticipate to use this with my memory controller for PC100 SDRAM.
> 
> The configuration coded is as follows:
>              (not)OE
>              |
>              |
>             |\
>             | \
> IN   -------| /-------
>             |/       |
>                      |----------Bidi-pin
>              /|      |
> OUT  -------/ |-------
>             \ |
>              \|
>              |
>              |
>              OE

Altera supplies timing information in their data sheets, no?  Why not
look up the delays there?  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 71793
Subject: Re: Altera Bidi ports, Tristate Buffers & Prop. Delay?
From: mikeandmax@aol.com (Mikeandmax)
Date: 30 Jul 2004 17:15:48 GMT
Links: << >>  << T >>  << A >>
>
>   I've discovered that there is some significant propagation delay
>between the input and bidirectional pin & bidirectional pin to output
>pin in my simulation.  I've compared the function LPM_BUSTRI within
>Quartus, a construction made up from Tri-state buffers within Quartus

often prop delays in a tristate pin are due to OE performance - have you looked
at the OE timinng numbers, or are you indeed looking at the prop delay of the
in or out buffer.  Most modern FPGAs now have syncronous OE and data registers
at the pin, which can give you much better timing through the I/O.

Mike Thomas
Lattice fae

Article: 71794
Subject: Active modular implementation of modules created with the generate statement
From: jedibub2003@yahoo.co.uk (Nicky)
Date: 30 Jul 2004 10:33:51 -0700
Links: << >>  << T >>  << A >>
Hello,

I have created a modular design in VHDL which required 200 instances
of the same module using the generate statement.

I am designing for a Xilinx II FPGA and am trying to use the modular
design flow.

When I come to the Active Modular Implementation phase for the module
that I implement 200 times I get NGDBuild error 560 saying that there
are 200 active blocks (I assume that it is only expecting 1 active
block).

The options that I use with the NGDBuil command are -u, -uc and
-modular module -active

If anyone knows of any addition options I need to specify or even that
I can't use the generate statement and have to create 200 separate
modules then I would be very greatful for their help.

Thanks very much,
Nicky

Article: 71795
Subject: Fpga eval. board with spdif receiver?
From: gretzteam@hotmail.com (David)
Date: 30 Jul 2004 10:34:05 -0700
Links: << >>  << T >>  << A >>
Does anybody know of an fpga eval. board (preferably with a xilinx
part) that has a spdif receiver on board(like the cirrus cs8414 or
cs8416)? The higher fpga board seem to have stuff for video, but
nothing for digital audio.

Thanks,
Dave

Article: 71796
Subject: Re: XST vhdl adder with carry out : broken carry chain
From: Bret Wade <bret.wade@xilinx.com>
Date: Fri, 30 Jul 2004 11:43:00 -0600
Links: << >>  << T >>  << A >>
Bart De Zwaef wrote:
> Hi all, 
> 
> I need some help here for implementing an efficient adder with carry
> out.
> Target : V2Pro 
> System : WinXP, ISE 6.2.03 sp3 
> 
> I am trying to implement a 16 bit adder with carry out. I use the vhdl
> description for this as stated in the XST user guide (see src code
> added at the bottom of this post):
> 
> q <= ('0'&a) + ('0'&b); 
> where a and b are 16 bits, q is 17 bits. 
> 
> After PAR I see that the MSB of q (which is the carry out) is not
> using the carry chain, but uses local routing. SO : functionally it is
> OK, but timing is sub-optimal (about 250MHz in -5 V2Pro).

Hello Bart,

We've run your code and there is indeed a map packing problem. The MSB 
is simply a FF driven by COUT of the previous slice. I see two related 
problems with the packing:

1. FF "tmp1_16" should be packed into a slice utilizing the CIN pin 
through the XORCY BEL as an extension of the carry chain but is not.

2. Instead, FF "tmp1_16" is being packed into the FFY BEL of the carry 
chain slice that is driving it, displacing "tmp1_15" from its correct 
packing location.

I've logged CR 192265 for these issues. Meanwhile, I don't see a work 
around for first issue except to extend the carry chain by one bit as 
you mentioned or possibly by instantiating an XORCY and FF to terminate 
the carry chain. The second issue can be controlled with a map packing 
constraint such as:

INST "tmp1_16" XBLKNM = XLNX_WA ;

I'll post again when we have a fix date scheduled.

Regards,
Bret Wade
Xilinx Product Applications


> 
> When I implement a 17 bit adder with carry out (so 1 bit larger) :
> carry chain is OK, and we can get better timing (up to 290 MHz).
> 
> I also tried the adder from CoreGen but the result is the same. 
> Is there anyone who managed to make an adder with carry-out that uses
> the carry chain all the way, regardless of the width?
> 
> Your help is much appreciated, 
> Bart 
> 
> ---------------------------------------------------------------
> --
> --  File       tstAdderCy.vhd
> --  Author     BADZ
> --
> --  Target     XC2VP20-5ff896 / XST ISE6.2.03i
> --
> --  Function : 16 bit adder with carry out
> --    
> 
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_arith.all;
> use IEEE.std_logic_unsigned.all;
> 
> -- synopsys translate_off
> library unisim;
> use unisim.vcomponents.all;
> -- synopsys translate_on
> 
> 
> entity tstAdderCy is
>   port (
>   sClk  : in std_logic;
>   a      : in std_logic_vector(15 downto 0);
>   b      : in std_logic_vector(15 downto 0);
>   out1  : out std_logic_vector(16 downto 0)
>   );
> end tstAdderCy;
> 
> architecture arch of tstAdderCy is
> 
> signal areg, breg       : std_logic_vector(15 downto 0);
> signal areg2, breg2      : std_logic_vector(15 downto 0);
> signal tmp1              : std_logic_vector(16 downto 0);
> 
> begin
> 
>   process(sClk)
>   begin
>     if rising_edge(sClk) then
>       -- tck 1
>       areg  <= a;
>       breg  <= b;
>       -- tck 2
>       areg2  <= areg;
>       breg2  <= breg;
>       -- tck 3
>       tmp1  <= ("0"&areg2) + ("0"&breg2);  -- MSB of adder = last
> carry out bit, but MAP does NOT use dedicated carry-nets => not OK for
> timing
>       -- tck4
>       out1  <= tmp1;
>     end if;
>   end process;
> end arch;
> --------------------------------------------------------------


Article: 71797
Subject: Re: RISCWatch w/ Linux running on ppc405D: Virtual/Physical mem issues
From: njoroge@stanford.edu (Nju Njoroge)
Date: 30 Jul 2004 10:46:18 -0700
Links: << >>  << T >>  << A >>
Wolfgang Denk <wd@denx.muc.de> wrote in message news:<I1Mv9s.953.3.diddl.denx@denx.muc.de>...
> njoroge@stanford.edu (Nju Njoroge) writes:
> 
> >I have been using the Riscwatch box w/ RISCwatch ver. 5.1 software. I
> >am running Linux on our embedded PPC405D. The trace captures the
>  ...
> >How can configure RISCwatch to access those interrupt address
> >locations that need physical address? Anyone encountered this problem
> >and found a way around it? I e-mailed IBM about it, but haven't gotten
> >a response yet...
> 
> The most common solution to this problem is to use an Abatron BDI2000
> instead...
Thanks. I looked into this solution. While it does handle the
translation while debugging, I'm looking to capture a trace output on
file so I can do post-processing statistical analysis on it w/ gprof
(i.e convert the trace output files into a gmon.out file). What I
would like to know is if there is a command/mechanism within RISCWatch
that could tell it for a certain address range not to access the TLB
or turn off the TLB...This would help in the case of interrupts since
Linux uses their physical addresses. RISCWatch seems to be passing
these physical addresses to the TLB for translation, which is causing
the errors I'm seeing. Perhaps I am asking too much from the tools :)
> Best regards,
> 
> Wolfgang Denk

Article: 71798
Subject: Re: On-Chip Oscillator
From: dhruvish@gmail.com (Drew)
Date: 30 Jul 2004 10:52:21 -0700
Links: << >>  << T >>  << A >>
jg,

My output is a clock which eventually will control A/D converter. Now,
the clock for converter needs to have < 2ns Rise Time (For faster
sampling rate, in my case 10MSamples/s) by the spec of it.

Nobody really replied to my other question, can we generate clock on
the Programmable Device (Max3032)? I want to generate 20MHz clock on
the EPLD.

Thanks,
Drew

Article: 71799
Subject: Altera Configuration Device
From: george.martin@att.net (George)
Date: 30 Jul 2004 11:21:27 -0700
Links: << >>  << T >>  << A >>
Hello:

I'm looking for the the data sheet on an Altera EPC2LC20.
Can't find in on Altera web site. And a google search didn't uncover anything.
It did direct me fo web pages but no data sheets for this device.
Anyone got a copy?

Thanks
George



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