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 38700

Article: 38700
Subject: Re: Signal processing using FPGAs
From: John_H <johnhandwork@mail.com>
Date: Tue, 22 Jan 2002 17:57:35 GMT
Links: << >>  << T >>  << A >>
The "single bit out" to work as a shift position in the multiplier block is
beautiful.

But wouldn't it be faster and more efficient to do a cascade to generate this single
bit?  Cascade one logic value until the first "one" is encountered, then cascade the
other value.  Take an XOR of the cascade shifted zero and the cascade shifted one
and you have the single bit output like with the dual port ROM.  [If the timing
analyzer wouldn't choke on feeding YB back into the next stage LUT for n(tilo), the
XORCY could perform the function without an additional level of logic.]

Agreed, there are "many different methods" but I've never liked getting into the ROM
initialization issues.



Peter Alfke wrote:

> There must be many different methods. Here is one 18-input priority encoder that
> seems "creative"
> Use a BlockRAM, configured 1k x 18. Feed 9 bits into port A, the other 9 bits
> into port B.
>
> This produces un-encoded outputs, 9 from portA, 9 from port B ( stagger the
> output wiring appropriately ).
> Now you need a wide NOR of all 9 inputs on A to act as an enable for port B.
> If the BlockRAM were combinatorial, we could hide this wide NOR inside the ROM,
> but the BlockRAM read is clocked, so we must use external logic ( 2 or 3 LUTs )
> to enable the outputs from port B.
> But we save the encoder/decoder needed to control the multiplier. as a shifter.
> There is only a single 1 coming from this 18-input priority encoder.
>
> I thank Bernie New for the basic idea.
>
> Peter Alfke, Xilinx Applications
> =======================================
> Eric Smith wrote:
>
> > Peter Alfke <peter.alfke@xilinx.com> writes:
> > > Traditionally, FPGAs have shied away from floating point, but
> > > Virtex-II with hundreds of multipliers may change that ( the
> > > multiplier can also be used as a shifter ). This invites simplified
> > > non-IEEE floating point.
> >
> > What's the most efficient way to implement a priority encoder in a
> > Virtex-II to compute the number of bits needed to shift for normalization
> > after FP add/subtract?


Article: 38701
Subject: Re: Q: can ROM content affect logic syn result
From: sunny <sunny@sunrise.at>
Date: Tue, 22 Jan 2002 11:02:43 -0800
Links: << >>  << T >>  << A >>
I would recommend to use Synplify v7.02 instead of 6.24. The new release features an updated memory compiler. That memory compiler will synthesize your ROM in seconds instead of minutes or even hours. 

If you do not want to run both, Synplify and Quartus, I would recommend to instantiate the ROM instead of inferring it and to add the mif-file in Quartus. Quartus offers that capability (File, New...)

Article: 38702
Subject: Re: Analog input into Altera FLEX10K using ADC. Can anyone help??
From: "Gunther May" <g.may@tu-bs.de>
Date: Tue, 22 Jan 2002 20:11:56 +0100
Links: << >>  << T >>  << A >>
It is possible, but the ADC0804 has only got a resolution of 8Bit, the
possible sampling
frequency is not very high and you have no integrated DA-converter if you
need it to get
an analog signal back.
There are so called codecs which are specialized to work FPGAs or DSPs, they
have
an AD and DA converter integrated. The resolution and/or sampling frequency
are
normally much higher than the specs of the ADC0804. You can get them for
example from
Analog Devices or Crystal.
The disadvantage is that the interface protocol is normally more complex.

Bye,
Gunther


"jcding" <jcding@yahoo.com> schrieb im Newsbeitrag
news:3c4db1f1_2@news.tm.net.my...
> Hi..
>   I have designed a 8-tap FIR filter. Can anyone give me ideas on how to
> input analog signals into FLEX10K using ADC ICs. Is ADC0804 possible?
>
> Or can anyone tell me how to test and prove that my design is working ? I
> have tried out the timing simulation and the result is correct and now I
> want to demo it . How?
>
> Thanks alot.
>
>



Article: 38703
Subject: vhdl code example required - x186 uC bus interfacing
From: "ray.frost" <ray.frost@ic24.net>
Date: Tue, 22 Jan 2002 19:34:29 -0000
Links: << >>  << T >>  << A >>
I'm new to using vhdl and wish to interface a xilinx spartanII fpga with an
Am186 uC - does anyone have vhdl code they would like to share with me?
Cheers



Article: 38704
Subject: analog input via serial connection
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Tue, 22 Jan 2002 14:47:35 -0500
Links: << >>  << T >>  << A >>
Does anyone have any experience with an a/d or d/a connection via a
serial i/o connection?  The system doesn't look to complex but on the
otherhand there might be gremlins hidden that I can avoid with your
help.  Even better yet, does someone have code that they know works?
Why re-invent the wheel when it isn't necessary?

Thanks,
Theron


Article: 38705
Subject: Re: Atmel FPGA configuration memory?!
From: "Ulf Samuelsson" <ulf@atmel.REMOVE.com>
Date: Tue, 22 Jan 2002 21:46:41 +0100
Links: << >>  << T >>  << A >>
> At first I'd like to say, that the board, I start to design, is not
> commercial. It is just my hobby and Atmel sends me 3-4 free samples. May
be
> Xilinx too, but I didn't found any page for sample request... Now I have
2x
> XC2S200 and would like to use something for configuration. What is the
best
> type for this device? Thank you.
>
> Andrej
>

I think that the AT17LV002 may be a suitable device.


--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.






Article: 38706
Subject: Re: analog input via serial connection
From: Ray Andraka <ray@andraka.com>
Date: Tue, 22 Jan 2002 20:56:31 GMT
Links: << >>  << T >>  << A >>
Often with these serial ADCs you can get away with keeping the signal
serial and using bit serial processing at a significant area savings.
The protocol is pretty straight forward, a simple state machine is about
all you need.

Theron Hicks wrote:

> Does anyone have any experience with an a/d or d/a connection via a
> serial i/o connection?  The system doesn't look to complex but on the
> otherhand there might be gremlins hidden that I can avoid with your
> help.  Even better yet, does someone have code that they know works?
> Why re-invent the wheel when it isn't necessary?
>
> Thanks,
> Theron

--
--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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 38707
Subject: Re: Image Processing on FPGAs. Dose System Generator help??
From: Niall Battson <nbattson@xilinx.com>
Date: Tue, 22 Jan 2002 13:26:37 -0800
Links: << >>  << T >>  << A >>
There was alot of work done on Wavelet transforms in System Generator
in North Carolina. The ability to simulate a frame of video and view the
results is very appealing, unfortunately it takes a while to simulate the complete
frame. (about 20 mins) Better than 2 hours with Modelsim though.

Using the black box function you can add in personal VHDL blocks but these
will require equivalent Simulink or S-function blocks to simulate them with
System Generator.

I agree with Ray in that System Generator will not create the most optimal
sized solution, but I feel with the addition of automatic generation of the UCF
in version 2.1 the speed of designs has significantly increased.

So, overall System Generator is extremely useful for Video Image Processing,
especially for some like yourself using Xilinx cores already. But if you want
absolute control and personal optimisation of a function stick with HDL or
schematic.

THanks

Niall

Ray Andraka wrote:

> I haven't used the latest version of system generator yet, so this may have been
> fixed.  The biggest problem with the old system generator is that it is very
> difficult to incorporate your own blocks into the system generator unless they
> are comprised totally of the coregen macros that are supported by system
> generator or the very simple extra functions built into system generator.  This
> makes it very awkward to use if you are doing things that don't fit in the
> rather limited set of standard components.
>
> That said, it is enough for someone to put something together in system
> generator and get it to run in the FPGA.  You usually won't see the orders of
> magnitude performance increases, and your design is probably going to be bigger
> than it needs to be using system generator, but at least it lets the
> non-hardware DSP savvy guy in.  I like the system simulation capability it has,
> but it isn't too useful to me until they come up with an easy way to import
> custom macros.
>
> a_darabiha wrote:
>
> > Hi All,
> >
> > I'm trying to implement a Computer Vision Algorithm
> > on Xilinx Vitex2000E fpgas. I am now using CoreGen for some blocks
> > of my system. We are thinking of switching to System Generator to do
> > the simulation in the highest level and then translate the system
> > to VHDL. I hope it would make the life much easier!
> >
> > So does anybody have experience of using SysGen for Image Processing
> > applications? how easy is that compared with the standard method of
> > writing the whole VHDL myself? what are the major problems that
> > might be in the way? ...
> >
> > Any coment would be helpful,
> >
> > Thanks,
> > Ahmad Darabiha
>
> --
> --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
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759


Article: 38708
Subject: Re: analog input via serial connection
From: "Theron Hicks" <hicksthe@egr.msu.edu>
Date: Tue, 22 Jan 2002 16:41:16 -0500
Links: << >>  << T >>  << A >>
In my case, I am not even doing any processing.  I just need a remotely
programmable signal (DC) and a method to remotely monitor a varying level.
The processing is being done after the fact in a PC.  (Several different
users process differently depending on their requirements.)
"Ray Andraka" <ray@andraka.com> wrote in message
news:3C4DD32E.4F0836DC@andraka.com...
> Often with these serial ADCs you can get away with keeping the signal
> serial and using bit serial processing at a significant area savings.
> The protocol is pretty straight forward, a simple state machine is about
> all you need.
>
> Theron Hicks wrote:
>
> > Does anyone have any experience with an a/d or d/a connection via a
> > serial i/o connection?  The system doesn't look to complex but on the
> > otherhand there might be gremlins hidden that I can avoid with your
> > help.  Even better yet, does someone have code that they know works?
> > Why re-invent the wheel when it isn't necessary?
> >
> > Thanks,
> > Theron
>
> --
> --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
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>



Article: 38709
Subject: Re: CRC-32 48bit(width)
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Tue, 22 Jan 2002 23:42:42 GMT
Links: << >>  << T >>  << A >>
On Tue, 22 Jan 2002 16:38:46 GMT, Ray Andraka <ray@andraka.com> wrote:

>You need to decide how you will deal with these invalid bytes.  I presume they should be
>ignored (dropped) from the stream.  If that is the case, then you'll have to buffer the
>incoming data so that you can drop unwanted bytes.  Masking the unwanted bytes at the CRC
>is not trivial if you are presenting 6 bytes at a time.  It is much easier if you present
>a byte at a time, but it also means running the CRC at a 6x clock.  If you can't do the 6x
>clock, I'd opt for a fifo arrangement that stores bytes until you have at least 6 valid
>ones and drops bad bytes.  The holes left by bad bytes get grouped together so that you
>skip over 6 bytes at a time at the CRC.

Hi Ray,

There's a magic trick you can do in which the dropped bytes simply get
masked to all zeros.  The trick is arranging the 2nd parallel CRC
generator such that leading zero bytes have no effect on the value of
the CRC.  This happens when the 2nd CRC is initialised to zero.

Regards,
Allan.

>Muthu wrote:
>
>> Yeah,
>>
>> You can get the source code for 48bits crc-32 parallel calculation.
>> Incase, if the all 48bits are not valid, How will you calculate the
>> crc-32 for that valid bytes only.
>>
>> For example:
>>
>> Your code will take always 48bits ie., 6Bytes of data. If the incoming
>> frame is not multiple of 6Bytes, atlast you will have some less bytes
>> (<6Bytes). For that how will you use the same module.
>>
>> Regards,
>> Muthu.
>>
>> Ray Andraka <ray@andraka.com> wrote in message news:<3C308D4E.280F00EA@andraka.com>...
>> > Sure there is, but it is not obvious.  check the 32 AND the 16 bit
>> > boxes.  That gives you the 48 bit variant.
>> >
>> > Kenily wrote:
>> >
>> > > Thanks!
>> > > But there is not 48bit(width)
>> >
>> > --
>> > --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
>> >
>> >  "They that give up essential liberty to obtain a little
>> >   temporary safety deserve neither liberty nor safety."
>> >                                           -Benjamin Franklin, 1759
>
>--
>--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
>
> "They that give up essential liberty to obtain a little
>  temporary safety deserve neither liberty nor safety."
>                                          -Benjamin Franklin, 1759
>
>


Article: 38710
Subject: Access to http://ripem.msu.edu
From: mgdeonar@hotmail.com (laars kumar)
Date: 22 Jan 2002 16:22:41 -0800
Links: << >>  << T >>  << A >>
Hello all!

I came across this website and its ftp site.  Apparently, it has a
good VHDL implementation of DES.  However, I can't seem to get to the
website to access it.  Has anyone else been able to access this site?

Thanks
L.

Article: 38711
Subject: input source to feed 20 filters! how to decrease the load
From: "Hristo Stevic" <hristostev@yahoo.com>
Date: Wed, 23 Jan 2002 00:39:36 +0000 (UTC)
Links: << >>  << T >>  << A >>
heya

i have to implement 20 parallel FIR all using the same source of input.
My problem is that if i connect this input directly to the 20 filters,
it will be so overloaded. meantime the same input has to feed all the
filters at the same time, so adding delays will not do the trick

how this problem is solved?

thanks


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 38712
Subject: Re: input source to feed 20 filters! how to decrease the load
From: Ray Andraka <ray@andraka.com>
Date: Wed, 23 Jan 2002 01:39:41 GMT
Links: << >>  << T >>  << A >>
Use a tree of registers to distribute the input signal. That will add a few
clocks of latency, but it will be the same amount for all filters.  You may
be able to reduce the size of the design by sharing the delay queues too,
in which case the distribution delays might be able to be absorbed into the
tapped delay queue.

Hristo Stevic wrote:

> heya
>
> i have to implement 20 parallel FIR all using the same source of input.
> My problem is that if i connect this input directly to the 20 filters,
> it will be so overloaded. meantime the same input has to feed all the
> filters at the same time, so adding delays will not do the trick
>
> how this problem is solved?
>
> thanks
>
> --
> Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

--
--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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 38713
Subject: Re: input source to feed 20 filters! how to decrease the load
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 22 Jan 2002 18:30:54 -0800
Links: << >>  << T >>  << A >>
Hristo,
you are afraid that you have a fan-out loading problem.
Maybe you do, maybe you do not.
It all depends where you do the fan-out.
Between devices, inside a device, what device?

Peter Alfke

Hristo Stevic wrote:

> heya
>
> i have to implement 20 parallel FIR all using the same source of input.
> My problem is that if i connect this input directly to the 20 filters,
> it will be so overloaded. meantime the same input has to feed all the
> filters at the same time, so adding delays will not do the trick
>
> how this problem is solved?
>
> thanks
>
> --
> Posted via Mailgate.ORG Server - http://www.Mailgate.ORG


Article: 38714
Subject: Virtex-II Programming Highs and Lows
From: cjmusial@sprintmail.com (beav)
Date: 22 Jan 2002 19:59:47 -0800
Links: << >>  << T >>  << A >>
Our team has recently developed a custom image processing board built
around several Virtex-II FPGAs.   We have also recently developed a
variety of algorithms to run within this hardware - and - for the most
part the process has been a major success.   However, one of the most
maddening elements of the process has been the relative ease in which
we can "break" a working design by making small changes to "unrelated"
code (e.g. VHDL components).    Sometimes merely routing signals to
our logic analyzer header will cause formerly-functional bitstreams to
start putting out rubbish.  This all seems to point to proper timing
constraints - since even small changes can place logic in different
parts of the device.

Within our limits of VHDL and timing constraints knowledge (not yet
masters), we have (a) overconstrained the synthesis tool (Synplify)
and then (b) only constrained the periods on the clocks within the
Xilinx tools.   In general our design meets almost all of the timing
constraints we have set - although the actual video input clock rate
is well below our the stated timing performance of the design.  
Nevertheless, we must be missing something here as we continue to see
small changes "break" the design.  Often, we can even take this
"broken" design, remove the Xilinx constraints, and viola... she
starts working again !

I realize this is a vague description, but we are looking for insight
on those that may have pushed through such "learning curves".  Are
there other key things besides the clock periods that should really
warrant special attention (perhaps a silly question).   Why do we
often get better "stability" when leaving constraints out of the
design ?   If Xilinx tools cannot meet all stated timing objectives,
is the resulting bitstream questionable such that we should back off
on some numbers and re-run unti all are met ?

Sorry for the banter, but any help would be greatly appreciated. 
Regards,


Chris

p.s. We are using ES silicon and assume we are not encountering
crosstalk or other potential device "glitches"

Article: 38715
Subject: Re: Virtex-II Programming Highs and Lows
From: strut911@hotmail.com (strut911)
Date: 23 Jan 2002 00:47:45 -0800
Links: << >>  << T >>  << A >>
this is kind of a basic question, but have you guys ran the
post-synthesis and post-timing through a testbench? i think in most
cases, post-synthesis is good enough to ensure functional
verification, and after that, a pass through the static timing
analyzer should give good confidence on the post-layout timing. if
these all pass, another thing you would probably want to look at is
your environment. i just got done spending two days on a problem that
did not exist because the environment was noisy. we had such weird
data coming out of our system, that we thought for sure that it was a
bug. after we moved the system to more of a noise-free environment,
the problems disappeared and it was behaving like it should.
basically, the fpga should function correctly if you can guarantee the
synthesis is correct and the STA passes. one caveat is that the STA is
only for synchronous circuitry. if you have a lot of asynchronous
signals in your design, and you are seeing some weird stuff, my first
suspicion would be to chase after the asynchronous logic portion. in
these cases, you should really invest in the xilinx chipscope. that
tool is invaluable in terms of isolating a problem to a certain
portion of the design.
strut911

Article: 38716
Subject: Re: Virtex-II Programming Highs and Lows
From: Bob Perlman <no-spam@sonic.net>
Date: Wed, 23 Jan 2002 08:57:55 GMT
Links: << >>  << T >>  << A >>
Hi - 

Getting the place and route tool to meet timing is a little like
making balloon animals.  We squeeze one end of the balloon and another
part of the balloon pops out.  Make the horse's head, and all of a
sudden you have too much horse's rear end.

Similarly, when we place a timing constraint on a set of paths, the
place and route tool, which doesn't like to work any harder than it
has to, concentrates on those paths at the expense of the others, and
all of a sudden the unconstrained paths start coming in at delays you
would have sworn were impossible in a modern device.  But fair's fair;
that's exactly what we told the tool to do.

Therefore, when doing FPGA designs, it's important to constrain each
and every path in the design.  Not just the clock period, or the
"critical" paths, but each and every path.  And when I talk about
constraining a path, I mean constraining it in a way that the
router--not just the synthesis tool--knows about.  

At some point in every design, I find myself spending 2 or 3 days
running trce with the -u option.  I look at the unconstrained path
report, find some unconstrained paths, cover them with a constraint
that I add to the .ucf file, then run the router and trce again, until
every single unconstrained path is gone.   And from that point on, I
rerun trce every time I change the design, to make sure that I haven't
introduced a path that's not covered by timing delays.  This is all
tedious, to be sure, but absolutely essential.

As for setting timing constraints in Synplify, I haven't found doing
so to be all that helpful.  I'd rather use the richer set of
constraints that Xilinx makes available.  Your mileage may vary on
this one.  But keep in mind that no matter what you tell Synplify,
what really counts is the set of constraints that  the Xilinx place
and route tool sees.

One final comment.  As you've found out, if a design isn't fully
timing-constrained, removing constraints may sometimes temporarily
solve a timing problem, because the router may no longer be robbing
Peter to pay Paul.  This ploy will stop working just before product
shipment.

Best of luck in fighting your timing battles,
Bob Perlman

On 22 Jan 2002 19:59:47 -0800, cjmusial@sprintmail.com (beav) wrote:

>Our team has recently developed a custom image processing board built
>around several Virtex-II FPGAs.   We have also recently developed a
>variety of algorithms to run within this hardware - and - for the most
>part the process has been a major success.   However, one of the most
>maddening elements of the process has been the relative ease in which
>we can "break" a working design by making small changes to "unrelated"
>code (e.g. VHDL components).    Sometimes merely routing signals to
>our logic analyzer header will cause formerly-functional bitstreams to
>start putting out rubbish.  This all seems to point to proper timing
>constraints - since even small changes can place logic in different
>parts of the device.
>
>Within our limits of VHDL and timing constraints knowledge (not yet
>masters), we have (a) overconstrained the synthesis tool (Synplify)
>and then (b) only constrained the periods on the clocks within the
>Xilinx tools.   In general our design meets almost all of the timing
>constraints we have set - although the actual video input clock rate
>is well below our the stated timing performance of the design.  
>Nevertheless, we must be missing something here as we continue to see
>small changes "break" the design.  Often, we can even take this
>"broken" design, remove the Xilinx constraints, and viola... she
>starts working again !
>
>I realize this is a vague description, but we are looking for insight
>on those that may have pushed through such "learning curves".  Are
>there other key things besides the clock periods that should really
>warrant special attention (perhaps a silly question).   Why do we
>often get better "stability" when leaving constraints out of the
>design ?   If Xilinx tools cannot meet all stated timing objectives,
>is the resulting bitstream questionable such that we should back off
>on some numbers and re-run unti all are met ?
>
>Sorry for the banter, but any help would be greatly appreciated. 
>Regards,
>
>
>Chris
>
>p.s. We are using ES silicon and assume we are not encountering
>crosstalk or other potential device "glitches"

--
Cambrian Design Works
digital design, signal integrity
http://www.cambriandesign.com
e-mail: respond to bob at the domain above.

Article: 38717
(removed)


Article: 38718
Subject: Internal tri state buffer..
From: "uttam singh" <uttam6jan@yahoo.com>
Date: Wed, 23 Jan 2002 01:52:15 -0800
Links: << >>  << T >>  << A >>
what are the advantages and disadvantages of internal tri state buffer which xilinx provided but altera does not?

Article: 38719
Subject: Analog input into Altera FLEX10K using ADC. Can anyone help??
From: "jcding" <jcding@yahoo.com>
Date: Wed, 23 Jan 2002 02:42:41 -0800
Links: << >>  << T >>  << A >>
Hi..
  I have designed a 8-tap FIR filter. Can anyone give me ideas on how to
input analog signals into FLEX10K using ADC ICs. Is ADC0804 possible?

Or can anyone tell me how to test and prove that my design is working ? I
have tried out the timing simulation and the result is correct and now I
want to demo it . How?

Thanks alot.



Article: 38720
Subject: Re: CRC-32 48bit(width)
From: muthus@ctd.hcltech.com (Muthu)
Date: 23 Jan 2002 04:47:35 -0800
Links: << >>  << T >>  << A >>
Hi alan,

You are correct. If the initial value is zero, leading zeros will not
affect the crc calculation.

Can you suggess and othere common method , which won't consider about
the place where the invalid bytes come. If the invalid byte come in
the middle of the Etherenet packet, how can we handle that invalid
bytes.

Thanks in advance.


Regards,
Muthu.

Article: 38721
Subject: Re: Virtex-II Programming Highs and Lows
From: Ray Andraka <ray@andraka.com>
Date: Wed, 23 Jan 2002 12:50:04 GMT
Links: << >>  << T >>  << A >>
The synplicity constraints are somewhat useful in synthesis, but in my
experience, muck up the works if allowed to propagate to the xilinx tools.
You also have to careful of them in synplicity because they can cause
unexpected logic duplication or worse.  Anyway, I have found that a period
constraint is often all that is needed, even in fast designs, provided you
have coded with keeping the levels of logic minimum.  Make sure the
synplicity constraints are not sneaking in.  If you have write vendor
constraints turned on, you get a *.ncf file which xilinx's ngdbuild merges
with the *.ucf.  If you have an *.ncf, delete it.

That said, you are probably a victim of multiple levels of logic.  The
xilinx placer does pretty well with placing the first level of logic with
its flip-flop, and if you floorplan the flip-flops the logic will usually
follow.  The placer does an exceptionally poor job at placing a second
level of logic (ie a lut whose output feeds another lut, not a flip-flop).
Even if all the driving signals are local, it will often put the second lut
many CLBs away regardless of the timing constraints.  Flip-flops are
amenable to floorplanning because they tend to keep their names in
synthesis.  Unfortunately, the luts are not because that is where the
famous name changing takes place.  Your best bet for consistent results is
to keep the logic to a single level.  Where you can't, you can a)
instantiate the luts (very painful, not very readable), or b) break the
design into smaller sub-designs and synthesize each separately so that the
scope of synthesis name changes is limited for small design changes.
Neither of these is very pleasant, so I prefer to do the design with number
of levels in mind.



Bob Perlman wrote:

> Hi -
>
> Getting the place and route tool to meet timing is a little like
> making balloon animals.  We squeeze one end of the balloon and another
> part of the balloon pops out.  Make the horse's head, and all of a
> sudden you have too much horse's rear end.
>
> Similarly, when we place a timing constraint on a set of paths, the
> place and route tool, which doesn't like to work any harder than it
> has to, concentrates on those paths at the expense of the others, and
> all of a sudden the unconstrained paths start coming in at delays you
> would have sworn were impossible in a modern device.  But fair's fair;
> that's exactly what we told the tool to do.
>
> Therefore, when doing FPGA designs, it's important to constrain each
> and every path in the design.  Not just the clock period, or the
> "critical" paths, but each and every path.  And when I talk about
> constraining a path, I mean constraining it in a way that the
> router--not just the synthesis tool--knows about.
>
> At some point in every design, I find myself spending 2 or 3 days
> running trce with the -u option.  I look at the unconstrained path
> report, find some unconstrained paths, cover them with a constraint
> that I add to the .ucf file, then run the router and trce again, until
> every single unconstrained path is gone.   And from that point on, I
> rerun trce every time I change the design, to make sure that I haven't
> introduced a path that's not covered by timing delays.  This is all
> tedious, to be sure, but absolutely essential.
>
> As for setting timing constraints in Synplify, I haven't found doing
> so to be all that helpful.  I'd rather use the richer set of
> constraints that Xilinx makes available.  Your mileage may vary on
> this one.  But keep in mind that no matter what you tell Synplify,
> what really counts is the set of constraints that  the Xilinx place
> and route tool sees.
>
> One final comment.  As you've found out, if a design isn't fully
> timing-constrained, removing constraints may sometimes temporarily
> solve a timing problem, because the router may no longer be robbing
> Peter to pay Paul.  This ploy will stop working just before product
> shipment.
>
> Best of luck in fighting your timing battles,
> Bob Perlman
>
> On 22 Jan 2002 19:59:47 -0800, cjmusial@sprintmail.com (beav) wrote:
>
> >Our team has recently developed a custom image processing board built
> >around several Virtex-II FPGAs.   We have also recently developed a
> >variety of algorithms to run within this hardware - and - for the most
> >part the process has been a major success.   However, one of the most
> >maddening elements of the process has been the relative ease in which
> >we can "break" a working design by making small changes to "unrelated"
> >code (e.g. VHDL components).    Sometimes merely routing signals to
> >our logic analyzer header will cause formerly-functional bitstreams to
> >start putting out rubbish.  This all seems to point to proper timing
> >constraints - since even small changes can place logic in different
> >parts of the device.
> >
> >Within our limits of VHDL and timing constraints knowledge (not yet
> >masters), we have (a) overconstrained the synthesis tool (Synplify)
> >and then (b) only constrained the periods on the clocks within the
> >Xilinx tools.   In general our design meets almost all of the timing
> >constraints we have set - although the actual video input clock rate
> >is well below our the stated timing performance of the design.
> >Nevertheless, we must be missing something here as we continue to see
> >small changes "break" the design.  Often, we can even take this
> >"broken" design, remove the Xilinx constraints, and viola... she
> >starts working again !
> >
> >I realize this is a vague description, but we are looking for insight
> >on those that may have pushed through such "learning curves".  Are
> >there other key things besides the clock periods that should really
> >warrant special attention (perhaps a silly question).   Why do we
> >often get better "stability" when leaving constraints out of the
> >design ?   If Xilinx tools cannot meet all stated timing objectives,
> >is the resulting bitstream questionable such that we should back off
> >on some numbers and re-run unti all are met ?
> >
> >Sorry for the banter, but any help would be greatly appreciated.
> >Regards,
> >
> >
> >Chris
> >
> >p.s. We are using ES silicon and assume we are not encountering
> >crosstalk or other potential device "glitches"
>
> --
> Cambrian Design Works
> digital design, signal integrity
> http://www.cambriandesign.com
> e-mail: respond to bob at the domain above.

--
--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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 38722
Subject: Handling the events below in verilog coding??
From: muthus@ctd.hcltech.com (Muthu)
Date: 23 Jan 2002 04:56:22 -0800
Links: << >>  << T >>  << A >>
Hi,
Here i am having a basic doubt,that how to code the following things
in verilog.

ie., case1: 

I have a one module which takes 8bits of data always. No need to worry
about the functionality of the module. If i want to complement the
First 8bits, how can i do. should i use any counter so as to count the
clock and take the decision according to the value of the counter.ie.,
the counter gets incremented once for every clock cycle. so, i have to
complement the incoming data when the counter value is "0001".(No need
worry about counter length).

case2:

Say, in my module i want to assert a output signal only for a single
clock cycle. ie., wherever i assert that signal, that signal should
come to zero before the next clock.


thanks in advance...


Regards,
Muthu.

Article: 38723
Subject: Re: CRC-32 48bit(width)
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Wed, 23 Jan 2002 13:08:10 GMT
Links: << >>  << T >>  << A >>
On 23 Jan 2002 04:47:35 -0800, muthus@ctd.hcltech.com (Muthu) wrote:

>Hi alan,
>
>You are correct. If the initial value is zero, leading zeros will not
>affect the crc calculation.
>
>Can you suggess and othere common method , which won't consider about
>the place where the invalid bytes come. If the invalid byte come in
>the middle of the Etherenet packet, how can we handle that invalid
>bytes.

It isn't possible to (simply) deal with holes in the *middle* of a
packet.  You have to do what Ray suggested: buffer up bytes until you
can drop a whole word (6 bytes) at a time.


If you are interested in partial words at the *end* of the packet...

I really can't say: this is company IP.  Sorry about that.

Regards,
Allan.

Article: 38724
Subject: Post-synthesis simulation with Modelsim from Leonardo Netlist
From: "Josan Moreno" <joseanmo@unex.es>
Date: Wed, 23 Jan 2002 14:39:57 +0100
Links: << >>  << T >>  << A >>
Hi,
I have found problems with post-synthesis simulation in Modelsim with a
netlist generated from Leonardo with ASIC Design Kit (ADK 1.7) from Mentor.
I obtain the same resuls than functional pre-synthesis simulation, Leonardo
doesn't introduce the delays in Verilog netlist but it can calculate the
critical paths of design.
The steps I followed are:
- Compiling and mapping ADK library in Modelsim:
> vlib adk
> vmap adk adk
> vlog -work adk adk.v
- Generating Verilog netlist with Leonardo with "ami05_typ" technology lib
after optimizing with/without I/O pads.
- Simulating extracted netlist:
> vlog -work work synth_design.v
> vsim SYNTH_DESIGN -L adk
Also I have generated the SDF file and I have introduced the file to
Modelsim with:
> vsirm -sdftyp SYNTH_DESIGN.sdf SYNTH_DESIGN -l adk

The same steps I have follow in another technlogy (AMS) and the results are
ok, why can't I obtain delay with ADK?
In $MODEL_TECH/lib I have only the .syn libs for ADK, but in AMS I have also
.vhd libs, is possible that delays are in the.vhd files?, then as I haven't
.vhd files for that technology, can I generate them? or where can I get
them?

Can anyone help me about this?
Thanks in advance.

Josan.





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