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 25475

Article: 25475
Subject: Re: computing difference between Gray values?
From: "Dan Kuechle" <dan_kuechle@i-tech.com>
Date: Tue, 12 Sep 2000 15:30:54 GMT
Links: << >>  << T >>  << A >>
using the fast clock, I sampled the two address counters (clk #1),
converted
to binary (clk #2), and did the binary subtraction (clk #3).  Nothing
elegent
here, but it worked, and not too expensive if your address counters are
small.
Now that the design is all working, I question whether I REALLY needed Gray
code address counters in the first place.

wzjohn@my-deja.com wrote in article <8pkn1p$n8c$1@nnrp1.deja.com>...
> Hi,
> 
> I've searched on deja for help but have to resort to posting:
> 
> What is the cheapest way to determine the difference between two gray-
> coded values?  My application is a FIFO with different input and output
> clocks.  I would like to know approximately how full the FIFO is at any
> time:  this information is needed in the faster clock domain.
> 
> Or am I on the wrong track?
> 
> TIA,
> 
> wzjohn
> 
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.
> 
Article: 25476
Subject: Virtex 1800 series ISP proms
From: Tom Leacock <tom@pavcal.com>
Date: Tue, 12 Sep 2000 11:47:08 -0400
Links: << >>  << T >>  << A >>
Has anyone had any success programming the XC1804 ISP proms for Xilnx
virtex parts with the JTAG download? I am using the  XC1804-pc44 proms
and multi-linx downloader, but the JTAG interface does not even
recognize the proms.
-- Thanks,
--Tom
----------------------------------------------
Thomas Leacock
Panasonic AVC American Laboratories (PAVCAL)
311 Main Street
Westampton NJ 08060
Phone: 609-518-3700 ext. 3218   
Fax:   609-518-3720
email: toml@pavcal.com
----------------------------------------------
Article: 25477
Subject: Re: Clock skew in XILINX CPLD
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Tue, 12 Sep 2000 15:50:59 GMT
Links: << >>  << T >>  << A >>
Thomas,
     This is a long shot, but I had very similar symptoms happen to me a
while back -- a long while back!  It had to do with my design, not with the
FPGA or CPLD.  I have read the other responses and am assuming several
things such as the clock is being fed through a global buffer.
     Now here is what happened to me.  I set up a "parallel synchronizer,"
which is now considered bad design practice by myself as well as some
clients that I have worked for.  A parallel synchronizer is a set of 2 or
more flip flops that synchronize asynchronous signals coming into the
design.  The problem with the parallel synchronizer is that all of the
signals may not get to the D inputs of the flip flops at the same time.
Then your assumption that they did will cause you to believe that you should
go to a certain state or set some registers in a certain way.  Because the
signals all didn't get there at the same time, you may go to a bad state or
set registers wrong.  For example, assume that the input is 00 and you will
jump to state BLAH3 when the input goes to 11.  As the inputs change they
may change as follows at the inputs of the synchronizers:
          00 --> 01 --> 11
The synchronizers may clock in 01 instead of 11, thus making you go to state
BLAH1 instead of BLAH3, because the parallel synchronizers actually went to
01 for a whole clock cycle.
     By the way, the asynchronous signals may actually be synchronous
signals that are skewed, i.e., generated by an opposite edge clock, too much
delay to the synchronizers, etc.
     Like I said, it's a long shot, but check to see if you have parallel
synchronizers or if the input signals aren't really synchronous or are being
delayed too much.
-Simon Ramirez, Consultant
-Synchronous Design, Inc.



"Thomas Falk " <falk@iee.et.tu-dresden.de> wrote in message
news:8pgf7q$kea$1@rks1.urz.tu-dresden.de...
> Hi Everyone!
>
> I'm having a problem in a fully synchronous design in a XILINX XC95108-10
> CPLD using the schematic entry. All Registers in the design are driven by
> one clock over GCK1.
>
> The problems are spurious errors which depended on the existence of test
> connections from the inner circuit connections to a pad. With the
> connections it workes, without not.
>
> Using the timing simulation I have narrowed down the problem to a hold
> violation on some of the D-FF. The simulation shows that in a simple shift
> register structure containing two D-FF, the second one will not take the
> right value, if the second one changes its output. It seems, the clock of
> second D-FF is too late regarding the change of the data at the output of
> the first D-FF, even if both D-FF are clocked by the same single via
> GCK1. From my point of view the same situation is given in each
> synchronous counter, ands that makes me a bit scary.
>
> I'm not sure how to handle this situation and have the following
questions:
> - In the beginning this design was not completely synchronous. After the
>   first appearance of these problems I changed it to a complete
>   synchronous one, but as it seems, the situation got worse. Is it better
>   to do such a design not completely in synchronous logic?
> - Is it possible to split up the clock net? One reason for the problems
>   may be a high load on the clock net GCK1.
>
> Generally I would also like to know if there is a systematic way to deal
> with such problems or to prevent their appearance.
>
> Thanks for any answer,
>
> Thomas Falk
>
>


Article: 25478
Subject: Re: Anybody receiving Spartan II?
From: "Gary Watson" <gary2@nexsan.com>
Date: Tue, 12 Sep 2000 17:08:00 +0100
Links: << >>  << T >>  << A >>
We haven't received our XC2S150-5FG456's yet.  We were told 6 to 8 weeks
from when we placed the order, about 2 weeks ago.  The part was supposed to
be "available" from Sept 5, 2000, but the leadtime clock starts at the
"available" date.

In my case I can happily use engineering samples, so I've ordered a bunch of
them for my first pre-production units.  The bigger problem is finding
somebody who can solder FG456's without ruining any.

--

Gary Watson
gary2@nexsan.com
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
http://www.nexsan.com


"Jerry English" <jenglish@planetc.com> wrote in message
news:39BE207E.8FE6EEC8@planetc.com...
> We are looking at using a spartan II xc2s150 in a new design. Our
> distributor is telling us Xilinx says 17 weeks delivery. Has anybody
> received these parts in large quantities (1000 pc) and if so what was
> your lead time? When I ask the distributor if the lead time can be
> improved the response is "Place the order then we will work the problem"
>
> Well why can't they tell me what the delivery time is for other orders?
>
> Oh yes, I did search deja for this question and it was asked. I
> followed
> the thread but nobody mentioned actually receiving these parts.
>
> I must say the new 3.1 release is fast. The verilog compiler is pretty
> good also. Did find a construct it couldn't handle but that's a subject
> for another thread.
>
> regards
> Jerry
>
>
>


Article: 25479
Subject: Re: xilinx web site access
From: "Gary Watson" <gary2@nexsan.com>
Date: Tue, 12 Sep 2000 17:10:13 +0100
Links: << >>  << T >>  << A >>
You may have noticed that you can't use the on-line tech support function,
though.

--

Gary Watson
gary2@nexsan.com
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
http://www.nexsan.com


"mok" <mok_3001@yahoo.com> wrote in message
news:8pjsv2$lv6$1@news.qub.ac.uk...
>
> > There's a www.xilinx.dk  you could try that
> >
> > wonder why www.xilinx.co.uk is only a redirect ?
> >
>
> The link to www.xilinx.com is a lot faster from, here in the UK, than any
> other european mirror.
> In fact, in all aspects of life, the UK is much closer to the States than
to
> mainland Europe, except the geography :-)
>
>


Article: 25480
Subject: Re: Is this practical?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 12 Sep 2000 16:23:39 GMT
Links: << >>  << T >>  << A >>
If you can use a multiplied clock, then you can use 1 adder per N channels plus
two CLB RAMs  (one for the adder feedback to make it an N timeslot accumulator
and one for your increment values for each channel).  If you have a 16x clock,
which if this is for something with sample rates below around 10 MHz is quite
doable, you get your 64 channels into 32 Virtex/spartanII CLBs (with one lut
open in each).  Even better, if you use the Block RAM, you can squeeze it down
into 8 CLBs plus 2 block rams (plus a few CLBs for the control and processor
interface logic) by using one block ram for the feedback registers for 4 16
channel generators and the other for the increments for 4 generators.  To do
this, set the block ram up as a dual port 16 bit wide component to get
simultaneous access to 32 bits.  Set the msb address bit on one port to a '1'
and the msb address on the other to '0' and run the rest of the address off a
common 4 bit counter.   Depending on your requirements, there may be some mods
needed to make it work for you.   Anyway, if you can do a 16x clock, it'll fit
into an XC2S15, provided you have enough pins to get your I/O

kolja@prowokulta.org wrote:
> 
> For many applications where a PWM is used a Delta-Sigma DAC gets even
> better results. There is a Xilinx applications note XAPP154 on how to do
> a 8-Bit S-D DAC in 10 LUTs plus 17 Registers => 9 Slices
> This would result in 567+epsilon Slices and would fit in a XC2S50.
> 
> If all the PWMs are synchronous (They use the same PWM cycle)
> one counter and 64 comparators with 8-Bit input register and
> one bit output register should be sufficient.
> This would reduce the hardware cost to one LUT per Bit or 5 Slices per
> channel or 320+epsilon Slices total. (A loose fit in a XC2S30)
> 
> CU,
>         Kolja Sulimma
> 
> In article <39BE1A34.92D42A47@andraka.com>,
>   Ray Andraka <ray@andraka.com> wrote:
> > what is the available clock and required sample rate?  If you can
> supply a
> > multiplied clock, you can reduce the size of the logic substantially.
> That
> > said, the brute force design will need 2 luts per bit plus the control
> logic, so
> > with careful layout you could get it into a 4013/XCS30.  If you go
> with Virtex,
> > you'll ned an XCV50 or larger device to fit the brute force design.
> >
> > Michael Warner wrote:
> > >
> > > Hi folks,
> > >
> > > I've never used an FPGA, but I have a problem to which they may
> > > provide the answer: I need to generate 64 simultaneous high-speed
> > > 8-bit PWM signals under micro control; space is at a premium.
> > >
> > > Imagining it in plain logic, I'd have 64 8-bit latches loaded by
> data
> > > & address buses. Each latch would pre-load an 8-bit counter on each
> > > PWM cycle. The counters would count down, latching themselves at
> zero
> > > - these latch signals would be the PWM outputs.
> > >
> > > Is this practical to attempt in a single device? If so, any
> > > recommendations of families suited to such a task would be
> > > appreciated.
> > >
> > > Thanks!
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com  or http://www.fpga-guru.com
> >
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 25481
Subject: Re: computing difference between Gray values?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 12 Sep 2000 16:29:42 GMT
Links: << >>  << T >>  << A >>
By oversampling the counts for your comparison you are essentially turning the
compare into a synchronous system.  I think you still need the gray, at least as
you've described it, to avoid sampling a transient state.  It would seem
however, that you could have gone to a totally synchronous fifo design with a
oversampled rate match register on the slower side to accomplish the same thing.




Dan Kuechle wrote:
> 
> using the fast clock, I sampled the two address counters (clk #1),
> converted
> to binary (clk #2), and did the binary subtraction (clk #3).  Nothing
> elegent
> here, but it worked, and not too expensive if your address counters are
> small.
> Now that the design is all working, I question whether I REALLY needed Gray
> code address counters in the first place.
> 
> wzjohn@my-deja.com wrote in article <8pkn1p$n8c$1@nnrp1.deja.com>...
> > Hi,
> >
> > I've searched on deja for help but have to resort to posting:
> >
> > What is the cheapest way to determine the difference between two gray-
> > coded values?  My application is a FIFO with different input and output
> > clocks.  I would like to know approximately how full the FIFO is at any
> > time:  this information is needed in the faster clock domain.
> >
> > Or am I on the wrong track?
> >
> > TIA,
> >
> > wzjohn
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 25482
Subject: Re: hardware compatibility and patent infringement
From: David Kessner <davidk@free-ip.com>
Date: Tue, 12 Sep 2000 10:44:32 -0600
Links: << >>  << T >>  << A >>
ABP wrote:

> 1. Is Transmeta's SOFTWARE approach to the manipulation of x86
> instructions set what avoids the violation of patents' rights? If that's
> right, I understand that patent infringement is only possible when there
> is a hardware implementation.

This is not correct...  At least not according to MIPS's lawyers.  MIPS is
currently suing Lexra for doing software emulation of some patented
instructions (LWL, LWR, SWL, and SWR to be exact).  Of course
Lexra's lawyers would disagree.


> 2. In general (for any kind of processor), What's the way to design a
> hardware device compatible with the instruction set of another processor
> without infringement of patents?

If an instruction is patented, and that is possible, then as long as you do
that instruction you are a target for a lawsuit.  There is no way around
that,
other than waiting for the patent to expire or licensing the patent.


> 3. If someone implements a processor compatible with the instruction set
> of another processor but without copying anyting else from that original
> processor a part from the original instruction set, will that be patent
> infringement?

If you do what is described in the patent then you're infringing.  If it is
possible
to emulate an instruction without doing what is described in the patent then
you're
OK.

In the case of MIPS vs. Lexra it is impossible emulate the instruction
without
doing what's in the patent since the patent describes the instructions
themselves.
What is at issue in MIPS vs. Lexra is the software emulation of the
hardware.

A possible workaround for the MIPS vs Lexra dispute is for Lexra to modify
the C/C++ compiler to never generate the instructions in dispute and emulate
it
"in a typical fashion that's been done for 20+  years".  By never doing
those
instructions they cannot be infringing.  Of course, this limits the
"compatibility"
of their CPU.


David Kessner
davidk@free-ip.com


Article: 25483
Subject: Re: Numerically-Controlled Crystal Oscillator (NCXO) or
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 12 Sep 2000 09:59:55 -0700
Links: << >>  << T >>  << A >>
DDFS users,

I stand corrected.

If a sine wave lookup table is used, and a D/A with a sufficient number of bits,
followed by a low pass filter, all jitter can be removed.  The advantages of
such an arrangement is the ability to synthesize any frequency from near 0 Hz up
to <1/2 the clock in, and not require different filters, and use a low pass
filter, rather than a band pass filter.

The low pass filter may be quite simple if the Fout << Fclock.  For information
on phase noise/jitter in relation to number of bits of resolution, please see
the Analog Devices web site, and search on jitter or phase noise.  They have
some good papers and formulas for such things.

My comment on D/A noise, filter noise, and comparator noise still stands, and
systems using the lookup table method need to pay special attention to other
sources of phase noise that will cause jitter.

Systems which operate over a narrow(er) range of frequencies can benefit from a
simpler arrangement, and remove all jitter without risking adding it back in.

I appreciate the personal emails to me which helped me realize I might have
misled some people out there,

Thank you,

Austin

rickman wrote:

> You are not totally correct Austin. If you want a square wave without a
> lot of jitter, then you do need the sine wave which can be filtered to
> produce a wave of just the fundamental. This is then compared to a fixed
> voltage to produce a square wave with no jitter.
>
> If you don't do this, you will have a time jitter equal to your master
> clock period as you noted. This is often not acceptable and the sine
> wave lookup, DAC and filter can be less circuitry than the VCXO, phase
> comparator and filter. In fact you can get the whole shebang in one chip
> less the filter.
>
> Austin Lesea wrote:
> >
> > Nestor,
> >
> > A DDFS (direct digital frequency synthesizer) is an adder/accumulator.
> > They have been around for perhaps 30 years now.  I have used them for
> > years in FPGAs.  The sine look up table is only used if you want a sine
> > wave.  I have seen people use a sine look up table, a D/A, and then follow
> > that mess with a comparator -- TO GET A SQUARE WAVE!  Think about it.  The
> > MSB of the DDFS was already the signal they wanted!
> >
> > So, if you don't want a sine wave, don't add all that junk.
> >
> > The p-p jitter is the clock period used, and the Fout < 1/2 Fclock.
> >
> > I would use the highest frequency I could get away with.  If you require
> > even less jitter, the output can be passed through a single simple VCXO
> > used in a PLL loop with an XOR phase detector and an external RC to remove
> > practically all of the jitter if the frequency output range is narrow
> > enough.
> >
> > Placing the DDFS in a locked loop, results in a complete digital locked
> > loop (Patented -- look it up, under my name).
> >
> > There are many nice parts out there that package the whole thing, and are
> > inexpensive, so you need to evaluate what it is going to be used for, and
> > decide if you want to build it in, or not.
> >
> > Also look at:
> >
> >  http://www.xilinx.com/xcell/xl31/xl31_32.pdf
> >
> > for fractional synthesis,and other NCO's.
> >
> > Austin Lesea
> >
> > Nestor wrote:
> >
> > > Hi.
> > >
> > > Does anyone know any manufacturer who fabricates
> > > numerically-controlled crystal oscillators (NCXO), also known as
> > > digitally-controlled crystal oscillators (DCXO) which are suitable for
> > > digital phase-locked loop designs in VHDL and FPGAs?
> > >
> > > Although these blocks resemble a numerically-controlled oscillator
> > > (NCO), they differ in that the NCXO is not oversampled to generate the
> > > required output signal (an NCO needs to be oversampled by at least
> > > 8-times in order to have an acceptable low jitter output).  Rather, a
> > > digital input word is fed to the NCXO and it synthesizes the required
> > > output frequency using a standard, low-cost crystal oscillator.  The
> > > output is also a square wave, just like the standard crystal.  In
> > > general, the NCXO has a narrow tuning range similar to a
> > > voltage-controlled crystal oscillator (VCXO), e.g. +/-150ppm relative
> > > to a frequency in the MHz range.
> > >
> > > The NCXO technology is fairly recent from what I understand, but
> > > allows one to replace a circuit composed of a digital-to-analog
> > > converter (DAC) and a VCXO by one chip that performs the exact same
> > > task will less design hassles.  The DCXO is ideal for custom-made
> > > phase-locked loop (PLL) circuits using digital sections that can be
> > > implemented in VHDL and FPGAs.
> > >
> > > Since I haven't been able to find any NCXO manufacturers over the web,
> > > I am now looking to the knowledgeable engineers, designers and friends
> > > that frequent these newsgroups for some potential referrals and/or
> > > links.
> > >
> > > Thanks in advance for your help.
> > >
> > > Nestor
>
> --
>
> Rick 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
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com

Article: 25484
Subject: IEC1131-3 PLC Programming Standard
From: barrytedstone@my-deja.com
Date: Tue, 12 Sep 2000 17:34:12 GMT
Links: << >>  << T >>  << A >>
To find out more about the IEC(6)1131-3 Standard
check out the www.searcheng.co.uk web site with a
detailed technical description by R.W. Lewis a UK
expert on two IEC working groups defining the PLC
programming language standard (IEC 61131-3) and
developing a new standard for Function Blocks for
modelling distributed control systems.



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25485
Subject: IEC1131-3 PLC Programming Standard
From: barrytedstone@my-deja.com
Date: Tue, 12 Sep 2000 17:41:08 GMT
Links: << >>  << T >>  << A >>
To find out more about the PLC Programming Standard check out the
article at www.searcheng.co.uk.  A description of the standard, the
programming languages and simple examples are given by Robert Lewis, a
UK expert on two IEC working groups defining the PLC programming
language standard (IEC 61131-3) and developing a new standard for
Function Blocks for modelling distributed control systems.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25486
Subject: Re: More than 4 clocks in virtex
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Tue, 12 Sep 2000 20:02:16 +0200
Links: << >>  << T >>  << A >>
Hi Kate,

By the way, can you say anything about clocking strategy in the Virtex2
family?
There will be more clock trees, right? Will all of them be global clock
trees
or will some of them be 'local' in some sense??

/Johan :)


Kate Meilicke wrote:
> 
> Some more hints for using  more than 4 clocks in Virtex parts...
> 
> Define which 4 clocks get to use the global buffers by using attributes (see your
> synthesis vendors docs) to force the usage of IBUFG/BUFG or IBUFG/DLL/BUFG
> combination.  You want the clocks with the highest fanout to use the global buffers.
> 
> For the rest of the clocks, use pins on the top or bottom of the chip, near the center
> or near the logic it will be clocking if the clock is coming from a pad.
> 
> Use the USELOWSKEWLINES constraint in the ucf or use the Constraints Editor under the
> Advanced tab.  This should work without the MAXDELAY constraints.
> 
> Kate
> Xilinx Software Technical Marketing
> 
> Johan Petersson wrote:
> 
> > Hi Hannah,
> >
> > There is a USELOWSKEWLINES command that you put in the .ucf . There is
> > also
> > some way (i don't remember what it is called) to constrain the skew on a
> > wire - it might be set maxskew = xxx :)
> >
> > I have used that stuff with Leonardo Spectrum without problem.n The thing
> > is that
> > the par router will take MUCH longer time to complete if you use the set
> > maxskew
> > constraint, but maybe you can live with that.
> >
> > What I would do myself is to put
> > 'par ... -i 200 ..."
> > as a background job with those constraints and see how far you can get
> > with
> > your favourite placement :)
> >
> > Good luck,
> > Johan P,
> > WDI ltd Sweden
> >
> > email vhdl_ninja@yahoo.com
> >
> > Hanna Bruno wrote:
> > >
> > > The problem faced here, was that the non global clock net was being split into 4
> > > groups. The synthesis tool must have done this and the resulting routing seemed
> > > to have skew between the 4 clock groups. The FAE said that there is a constraint
> > > that can be added in 3.1i to use low skewlines, I have to try that yet and
> > > prevent the synthesis tool from splitting the net.
> > >
> > > Thank you for your comments Jamie.
> > >
> > > Hannah

-- 
APZ FOR MEN BECAUSE FIRST IMPRESSIONS LASTS

Article: 25487
Subject: Re: OUTs after synthesis?
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Tue, 12 Sep 2000 20:14:13 +0200
Links: << >>  << T >>  << A >>
Hi Tomek,

> I have a synthesizable model. What are initialized outputs of model after
> synthesis?

In my experience, that's depending on what synthesis tool you use and
what 
architecture you are synthesizing your model for. The "standard"
solution would
be to put all outputs tristate at power up I guess. For example, I
believe that's
what happens to a Xilinx fpga between power up and system reset.

But my advise to you would be to start the dumping of output signals
AFTER you
have done reset of the model - if you are not particularly interested in
what
happens before the reset.

Good luck,
Johan P :)


Tomasz Brychcy wrote:
> 
> Hello,
> 
> I have a synthesizable model. What are initialized outputs of model after
> synthesis?
> 
> My model consists a three outputs OUT0 OUT1 OUT2. When i simulate model
> before synthesis outputs go to known state in right time (outputs are
> initialized unknown state) and when i simulate model after synthesis outputs
> go to known state from beginning of simulation. Results of simulation of
> model before synthesis i write in to file (it's a pattern file). So file
> with results of model after synthesis never will be the same as pattern file
> before synthesis because outputs are different initialized before and after
> synthesis (in simulation), it's truth?
> 
> With regards
> 
> Tomek
> 
> --
> Department of Electrical Metrology
> Technical University of Zielona Gora
> 
> T.Brychcy@ime.pz.zgora.pl

-- 
APZ FOR MEN BECAUSE FIRST IMPRESSIONS LASTS
Article: 25488
Subject: Re: Accessing internal signals and ports for writing to a file using testbench
From: "Nestor" <nestor@ece.concordia.ca>
Date: Tue, 12 Sep 2000 19:08:44 GMT
Links: << >>  << T >>  << A >>
Thanks to everyone for the replies.  The declaration of a package with probe
signals seems to be good enough for my purposes.  I will need to try it out,
most likely tomorrow.

Nestor


Charles Gardiner <charles.gardiner@mchr2.siemens.de> wrote in message
news:39BDFB85.30AEB205@mchr2.siemens.de...
> You can also do it in VHDL using an intermediate Package.
>
> Library  IEEE;
> Use IEEE.std_ logic_1164.all;
> Package TracePkg
> signal test_point_1 : std_logic;
> End TracePkg;
>
> -- -- -- --
>
> Library  IEEE;
> Use IEEE.std_ logic_1164.all;
> Use WORK.TracePkg;
> Architecture Bhv of DUT
>    signal signal_name_1 : std_logic;
> begin
>    TracePkg.test_point_1 <= signal_name_1;
> end Bhv;
>
> -- -- -- --
>
> Library  IEEE;
> Use IEEE.std_ logic_1164.all;
> Use WORK.TracePkg;
> Architecture Bhv of DUT_Testbench
>   signal test_point_1 : std_logic;
> begin
>   test_point_1 <= TracePkg.test_point_1;
>
>   I_DUT : DUT
>       Port Map (
>    etc....
> End Bhv;
>
> --
> Charles Gardiner, B.E.
> Program Manager, Silicon IP
> Siemens AG
> Dept: ATD IT PS 8 Mch
> Otto-Hahn-Ring 6
> D-81730 Muenchen
>
> Email: mailto:charles.gardiner@mchr2.siemens.de
> Phone: Office +49 89/636 42969, Mobile (0)171/867 2732
> Fax  : Office +49 89/636 44595
>
> Homepage    : http://eda-services.atd.siemens.de/gardiner (Siemens
> Intranet only)
> ATD Homepage: http://www.atd.siemens.de/it-dl/eda


Article: 25489
Subject: Re: Numerically-Controlled Crystal Oscillator (NCXO) or Digitally-Controlled Crystal Oscillator (DCXO) Designs
From: "Nestor" <nestor@ece.concordia.ca>
Date: Tue, 12 Sep 2000 19:18:16 GMT
Links: << >>  << T >>  << A >>
The frequency range of the analog frequency clock output is in the
12MHz-40MHz range, but the resolution of the digital input control has not
been determined yet.  I don't think I will need more than 8 bits though.



Rolie Baldock <berd_kalamunda@techemail.com> wrote in message
news:39b96e51.6796199@news.m.iinet.net.au...
> What frequency range are you interested in and what resolution do you
> require?
>
> --Rolie Baldock.  email:  <berd_kalamunda@'nospam'techemail.com>


Article: 25490
Subject: Re: Numerically-Controlled Crystal Oscillator (NCXO) or Digitally-Controlled Crystal Oscillator (DCXO) Designs
From: "Nestor" <nestor@ece.concordia.ca>
Date: Tue, 12 Sep 2000 19:26:05 GMT
Links: << >>  << T >>  << A >>
Because my design is relatively high speed (say about 40MHz), I fear that
using a combination of a DAC and a VCXO might not adapt fast enough to the
input control change.  However, my purpose is to actually find a circuit
that could emulate the DAC/VCXO idea so that the frequency is controlled
digitally.

I have seen a VLSI design making use of the Pierce topology to create a DCXO
using an external crystal oscillator (12MHz-30MHz) for the reference
frequency.  The DCXO has a digital control, but from the figure I have it is
not clear how the digital section interfaces with the oscillator section (it
has been omitted from the figure).  It's possible an internal DAC is
included.

Nestor


rickman <spamgoeshere4@yahoo.com> wrote in message
news:39B9CA44.BC7CAF17@yahoo.com...
> I believe the VCXO circuit you are describing is a standard crystal
> oscillator with a variactor diode to control the frequency. All crystal
> circuits can be tuned slightly by varying the capacitance in the
> circuit. The variactor diode allows you to use a DC voltage to adjust
> this capacitance.
>
> I am not familiar with the NCXO or DCXO, but I would be willing to bet
> that this is just a DAC combined with a VCXO. No magic here, just a
> matter of combining mulitple devices in one package.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com


Article: 25491
Subject: flipflops/statemachine/fifos and timing
From: Richard Meester <rme@quest-innovations.com>
Date: Tue, 12 Sep 2000 21:36:43 +0200
Links: << >>  << T >>  << A >>
Hi all,

i have a general question regarding some timing issues. I am doing a
project connecting an fpga to an extern synchronous dpram. This dpram
has 1 cycle delay in pipelined operation.

the problem i am having has to do with timing and enabling of flipflops
etc.
Currently i have a state diagram as follows.
s1 : output address on bus.
s2 : enable writeenable of internal fifo.
s3: -- at this point the data is clocked in from the external address
bus into the internal fifo.

When i do a functional simulation i see indeed that the enable of the
internal fifo goes high at state2 (excactly at the positife clock edge).
But does it now start clocking in the data at this point, or on the next
clock cycle (and thus the time when we are in state 3.) In simulation is
see that at the clock pulse of S2 the enable goes high, but i don't know
if the data is now clocked in or not. I presume that the data is clocked
in on the next clock cycle, since the enable signal is set in state 2,
and state 2 is relative to a pos_edge clock, and thus at the rising edge
of the clock the wr_enable line was not high, and thus the data should
not be clocked in at S2, but at the next cycle.

Thanks in advance,

Richard

--
Quest Innovations
tel: +31 (0) 227 604046
http://www.quest-innovations.com


Article: 25492
Subject: Re: virtex shape
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Tue, 12 Sep 2000 21:49:22 +0200
Links: << >>  << T >>  << A >>
Hmm,

No idea, but it isn't the only non square chip around. Not that I'm an
expert
on chip squareness :) I think the terrible hole-mounted 5000 pld's from
Altera
were squre, and some memory chips are square, aren't they??

Maybe it's a question of bonding the signals out from the chip to the
pins - or
maybe internal routing efficiency...

Who knows,
Tell me if you get the answer somehow!

--JOHAN :)

erika_uk@my-deja.com wrote:
> 
> hey,
> 
> why virtex chips are rectangular and not square
> 
> --ERIKA
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Article: 25493
Subject: Re: Code distribution without loss of IP?
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Tue, 12 Sep 2000 22:00:09 +0200
Links: << >>  << T >>  << A >>
Hi Chris,

Good question, I have been considering it myself. I think there are
VHDL scramblers around. Let me know if you find one!

Otherwize I'm planning to get someone to write one for me (rather simple
script hack using perl i think) - but it'll probably be some time before 
I get that arranged :)

Good luck,
Johan :)


Chris Anderson wrote:
> 
> Hi,
> I have a design for a device written using Renoir and ModelSim in VHDL.
> Initially it's targeted at a Xilinx Virtex. I need to generate an image
> of this VHDL in a form that is as flexible as VHDL (in terms of the
> ability to retarget) but is not in a human readable form so that it
> can't be reverse engineered.
> 
> Any suggestions?
> 
> Thanks
> 
> Chris Anderson
Article: 25494
Subject: Re: CPLD: Basic informations
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Tue, 12 Sep 2000 22:04:23 +0200
Links: << >>  << T >>  << A >>
Hi there,

why don't you give it a try at 

www.xilinx.com

or

www.altera.com ???

Xilinx stuff is good for most cpld designs I think. Ericsson have good
experience
from using them in a couple of projects. 
If you are a cpld-fetishist and need something HUGE, you should turn to 
Altera. I guess they have the largest cpld's around - but they are VERY 
expencive, like $100 or so for their largest - beware!

Good luck,
Johan


Mostafa Halas wrote:
> 
> Hi,i want to know the number of registers and system gates for various CPLD products.
Article: 25495
Subject: Re: flipflops/statemachine/fifos and timing
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 12 Sep 2000 16:05:35 -0400
Links: << >>  << T >>  << A >>
I think I understand your question. You are not sure which positive edge
of the clock registers the data, S2 or S3. The problem is that the
simulator does not show any delay (other than perhaps the minimum timing
resolution) and makes the outputs of the FFs look like they change at
the same time as the clock edge. Really they are slightly delayed.

Let me draw a picture that is how the signals really are. 

         |  S1   |  S2   |  S3  |
          ___     ___     ___  
CLK   ___|   |___|   |___|   |___
      ____  ______  ______  _____
Data  ____><__1___><__2___><_____
      ____  ______  ______  _____
FIFO  ____><______><______><__2__
      _____________         _____
WREN               \_______/

Here it shows that the data from the RAM changes just after the rising
edge of the clock. So the data that is latched into the FIFO is the data
that was stable before the clock edge and not the new data that comes
*after* the clock edge. 

Is that more clear?



Richard Meester wrote:
> 
> Hi all,
> 
> i have a general question regarding some timing issues. I am doing a
> project connecting an fpga to an extern synchronous dpram. This dpram
> has 1 cycle delay in pipelined operation.
> 
> the problem i am having has to do with timing and enabling of flipflops
> etc.
> Currently i have a state diagram as follows.
> s1 : output address on bus.
> s2 : enable writeenable of internal fifo.
> s3: -- at this point the data is clocked in from the external address
> bus into the internal fifo.
> 
> When i do a functional simulation i see indeed that the enable of the
> internal fifo goes high at state2 (excactly at the positife clock edge).
> But does it now start clocking in the data at this point, or on the next
> clock cycle (and thus the time when we are in state 3.) In simulation is
> see that at the clock pulse of S2 the enable goes high, but i don't know
> if the data is now clocked in or not. I presume that the data is clocked
> in on the next clock cycle, since the enable signal is set in state 2,
> and state 2 is relative to a pos_edge clock, and thus at the rising edge
> of the clock the wr_enable line was not high, and thus the data should
> not be clocked in at S2, but at the next cycle.
> 
> Thanks in advance,
> 
> Richard
> 
> --
> Quest Innovations
> tel: +31 (0) 227 604046
> http://www.quest-innovations.com

-- 

Rick 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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 25496
Subject: Re: computing difference between Gray values?
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 12 Sep 2000 16:09:46 -0400
Links: << >>  << T >>  << A >>
That depends on the rate and timing of data transfer. Although
oversampling may work for a FIFO count calculation, this is not the same
thing as clocking the data. The FIFO count will be off by one at any
given point in time depending on your luck in sampling, without ill
effect. But the data needs more care to not drop, change or overwrite
it. 


Ray Andraka wrote:
> 
> By oversampling the counts for your comparison you are essentially turning the
> compare into a synchronous system.  I think you still need the gray, at least as
> you've described it, to avoid sampling a transient state.  It would seem
> however, that you could have gone to a totally synchronous fifo design with a
> oversampled rate match register on the slower side to accomplish the same thing.
> 
> Dan Kuechle wrote:
> >
> > using the fast clock, I sampled the two address counters (clk #1),
> > converted
> > to binary (clk #2), and did the binary subtraction (clk #3).  Nothing
> > elegent
> > here, but it worked, and not too expensive if your address counters are
> > small.
> > Now that the design is all working, I question whether I REALLY needed Gray
> > code address counters in the first place.
> >
> > wzjohn@my-deja.com wrote in article <8pkn1p$n8c$1@nnrp1.deja.com>...
> > > Hi,
> > >
> > > I've searched on deja for help but have to resort to posting:
> > >
> > > What is the cheapest way to determine the difference between two gray-
> > > coded values?  My application is a FIFO with different input and output
> > > clocks.  I would like to know approximately how full the FIFO is at any
> > > time:  this information is needed in the faster clock domain.
> > >
> > > Or am I on the wrong track?
> > >
> > > TIA,
> > >
> > > wzjohn
> > >
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> > >
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com  or http://www.fpga-guru.com

-- 

Rick 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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 25497
Subject: Re: flipflops/statemachine/fifos and timing
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Tue, 12 Sep 2000 22:14:24 +0200
Links: << >>  << T >>  << A >>
Hi Richard,

Why don't you try and synthesize your design, do a preliminary backend
implementation
in your favourite architecture and finally generate a back annotated
vhdl-netlist?

That should be feasible in any gate array with any normal tools these
days.

If you are working with Xilinx fpga's i could send you a makefile that
shows,
among other things, how the back annotated netlist is generated.

Good luck,
Johan :)

ps It will be very difficult for anyone to give you a good answer to
your 
question unless you include the source code for your state-machine and a
detailed
timing diagram of your memories. Further - I guess you would like to
have some
kind of information about the pcb/pcbs that you will put your stuff on. 

Is your fifo in the FPGA by the way? To answer your fifo question i
would have
to know something more about the fifo as well...


Richard Meester wrote:
> 
> Hi all,
> 
> i have a general question regarding some timing issues. I am doing a
> project connecting an fpga to an extern synchronous dpram. This dpram
> has 1 cycle delay in pipelined operation.
> 
> the problem i am having has to do with timing and enabling of flipflops
> etc.
> Currently i have a state diagram as follows.
> s1 : output address on bus.
> s2 : enable writeenable of internal fifo.
> s3: -- at this point the data is clocked in from the external address
> bus into the internal fifo.
> 
> When i do a functional simulation i see indeed that the enable of the
> internal fifo goes high at state2 (excactly at the positife clock edge).
> But does it now start clocking in the data at this point, or on the next
> clock cycle (and thus the time when we are in state 3.) In simulation is
> see that at the clock pulse of S2 the enable goes high, but i don't know
> if the data is now clocked in or not. I presume that the data is clocked
> in on the next clock cycle, since the enable signal is set in state 2,
> and state 2 is relative to a pos_edge clock, and thus at the rising edge
> of the clock the wr_enable line was not high, and thus the data should
> not be clocked in at S2, but at the next cycle.
> 
> Thanks in advance,
> 
> Richard
> 
> --
> Quest Innovations
> tel: +31 (0) 227 604046
> http://www.quest-innovations.com

-- 
APZ FOR MEN BECAUSE FIRST IMPRESSIONS LASTS
Article: 25498
Subject: Re: Numerically-Controlled Crystal Oscillator (NCXO) or
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 12 Sep 2000 16:17:27 -0400
Links: << >>  << T >>  << A >>
If you need a 12 to 30 MHz range, you are in a totally different
technology. I am pretty sure you can only bend a VCXO by about 200 ppm
or so. What you need is called an NCO, numerically controlled
oscillator. This is a clocked adder followed by a sine lookup table and
a DAC. The analog signal then looks like a stepped sine wave. A filter
changes this to a pure sine wave which is then squared up with a
comparator. 

At 30 MHz this will work well and can be found in a single chip less the
filter. Try Analog Devices. This is also called Direct Digital Frequency
Synthesis, DDFS or just DDS. There have been several messages in this
thread about this already. 

You will need a much faster clock to run this, the minimum will be 2x
your max rate. I sugest you try 100 MHz for better results and better
and simpler filtering. 



Nestor wrote:
> 
> Because my design is relatively high speed (say about 40MHz), I fear that
> using a combination of a DAC and a VCXO might not adapt fast enough to the
> input control change.  However, my purpose is to actually find a circuit
> that could emulate the DAC/VCXO idea so that the frequency is controlled
> digitally.
> 
> I have seen a VLSI design making use of the Pierce topology to create a DCXO
> using an external crystal oscillator (12MHz-30MHz) for the reference
> frequency.  The DCXO has a digital control, but from the figure I have it is
> not clear how the digital section interfaces with the oscillator section (it
> has been omitted from the figure).  It's possible an internal DAC is
> included.
> 
> Nestor
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message
> news:39B9CA44.BC7CAF17@yahoo.com...
> > I believe the VCXO circuit you are describing is a standard crystal
> > oscillator with a variactor diode to control the frequency. All crystal
> > circuits can be tuned slightly by varying the capacitance in the
> > circuit. The variactor diode allows you to use a DC voltage to adjust
> > this capacitance.
> >
> > I am not familiar with the NCXO or DCXO, but I would be willing to bet
> > that this is just a DAC combined with a VCXO. No magic here, just a
> > matter of combining mulitple devices in one package.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design
> >
> > Arius
> > 4 King Ave
> > Frederick, MD 21701-3110
> > 301-682-7772 Voice
> > 301-682-7666 FAX
> >
> > Internet URL http://www.arius.com

-- 

Rick 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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 25499
Subject: Re: virtex shape
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 12 Sep 2000 16:21:30 -0400
Links: << >>  << T >>  << A >>
I think he is asking why the rows and columns are not the same count in
contrast to many of the other Xilinx families. I don't know that anyone
would care that the die itself is not square. In fact many memory chips
are made rectangular just so they will fit in the packages. 

I can't say why Xilinx chose non square arrangements of the CLBs. Some
of their chips are square and some aren't. Maybe the CLBs are not square
and they adjust the rows and columns to make the die square???  ;)


Johan Petersson wrote:
> 
> Hmm,
> 
> No idea, but it isn't the only non square chip around. Not that I'm an
> expert
> on chip squareness :) I think the terrible hole-mounted 5000 pld's from
> Altera
> were squre, and some memory chips are square, aren't they??
> 
> Maybe it's a question of bonding the signals out from the chip to the
> pins - or
> maybe internal routing efficiency...
> 
> Who knows,
> Tell me if you get the answer somehow!
> 
> --JOHAN :)
> 
> erika_uk@my-deja.com wrote:
> >
> > hey,
> >
> > why virtex chips are rectangular and not square
> >
> > --ERIKA
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.

-- 

Rick 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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com


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