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

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 40425

Article: 40425
Subject: Re: Using a battery instead of Config device
From: Peter Alfke <palfke@earthlink.net>
Date: Thu, 07 Mar 2002 03:08:19 GMT
Links: << >>  << T >>  << A >>
I can obviously not speak for Altera, but here are some general
observations:

If the manufacturer made sure that all dc-consuming utilities are turned
off as soon as the normal Vcc disappears, and if the process is somewhat
old-fashioned ( >0.5 micron), then there is a chance. XC3000L used to
consume <50 microamps, which is an acceptable (barely!) value.

If the manufacturer did not pay special attention, and does not indicate
so in the data sheet, your hopes are slim.
For all really up-to-date devices with geometries below 0.2 microns, (or
200 nanometers as it is more fashionably called), there is no hope. The
inherent so-called leakage current is milliamps ( and more).

But you can always try it out by measuring, both at room and at slightly
elevated temperature...


Peter Alfke, Xilinx Applications
====================================
Chris Cowdery wrote:

> I am considering using a lithium battery on a board instead of a
> config device to enable my Altera FLEX10KA to retain its
> configuration.
>
> Has anyone any idea of the absolute min quiescent current I can expect
> a 10KA to draw?
>
> Thanks,
>
> Chris.


Article: 40426
Subject: Re: exceeding 2GB limits in xilinx
From: "Peter Ormsby" <faepete.deletethis@attbi.com>
Date: Thu, 07 Mar 2002 03:30:43 GMT
Links: << >>  << T >>  << A >>
Lars Rzymianowicz <larsrzy@atoll-net.de> wrote in message
news:3C85C76F.3B5FA1A5@atoll-net.de...
> And since Xilinx and most other EDA vendors support Linux now, why
> step down to the bluescreen?

Just to be clear here, the Xilinx Linux solution is currently limited to
command-line only on WINE.  For those unfamiliar with this approach, check
out http://www.winehq.com .  Briefly, WINE is a piece of software that sits
between a Windows application and Linux and maps your Windows system calls
to Linux OS calls.  The whole point to WINE is that you don't have to change
your Windows application at all - rather you make sure that WINE is smart
enough to handle all the pieces of Windows that your program uses.  Running
Xilinx tools on Linux via WINE means that Xilinx made sure that WINE was
able to handle all the system calls the the command-line version of their
tools required.  There were probably few (if any) changes made to the
original Xilinx Windows software.

Any limitations that the Xilinx Windows software has under Windows will
still exist on WINE-on-Linux.

BLATANT ALTERA PROMOTIONAL PLUG:

The Altera Quartus II Linux port is a true Linux port tested for
compatibility with RedHat's v7.1 Linux release.

END BLATANT ALTERA PROMOTIONAL PLUG.

-Pete-



Article: 40427
Subject: Re: Quartus II 2.0 fast fit option
From: "Terry" <terry.dietrich@rogers.com>
Date: Thu, 07 Mar 2002 05:23:38 GMT
Links: << >>  << T >>  << A >>
Wow, I don't normally like to get involved, but here goes:



>         One of my major complaint of QII 1.1/2.0 (only tried Web Edition
> though) is that for some reason, QII drains Windows 9x's system
> resources much more heavily than ISE WebPACK.
> Because Windows 98 is so bad, I always have to put Resource Meter on the
> side of my screen, and whenever QII is running, I see it draining large
> amounts of system resources, which comes back if I exit QII, but each
> time this happens, I have to interrupt what I was doing, and I don't
> like that.
> Altera seemed to have made no improvements there compared to QII 1.1.
> I read somewhere that Altera doesn't recommend using QII under Windows
> 98, and instead recommend using Windows NT 4.0 or 2000, but I sort of
> suspect that is because the system resource issue.
> I do notice that Altera uses much more graphics than Xilinx in QII, and
> that might be another reason why it drains system resources heavily.

All I have to say here is avoid QII on Win 98.  I ran into several bugs, and
had to work around them...


>         From what I see, the improvements made from QII 1.1 to 2.0 seems
> small, although I do appreciate that Altera added ACEX1K support in QII
> 2.0 WE, but other than that not too much has changed.
> Perhaps, Altera should have called QII 2.0 as QII 1.2.
> I guess raising the version number is important to show that major
> improvements are being made, so that people will upgrade, but I think if
> things don't improve too much, that turns into disappointment.

Altera made some "major" improvements moving from V1.1 to V2.0.  Some of
which include smaller installation size, better database management (ie
smaller databases (approx 30x reduced vs V1.1) taking up less HD space),
faster compile times (relative term though), and better performance (higher
fmax).

I suspect that the change in the version number (to 2.0) corresponds with
the change in year (2002).  From what I gather, V2.1 will be out in the
June/July timeframe.

>         The problem I had with QII 2.0 + LS-Altera (NativeLink) +
> FLEX10KE was something that QII 2.0's NativeLink script tried to
> reference "flex10ke.syn" instead of "flex10e.syn."
> Being a beginner of QII tools, I had no idea what was going on until I
> was told to look at the LS-Altera's directory for the file, and after I
> noticed that small file name difference, it was easy to workaround it
> (make a copy, and rename it to match QII 2.0's NativeLink script), but
> it also shows that Altera must have forgotten to test QII 2.0 (Verilog
> flow) + LS-Altera (NativeLink) + FLEX10KE or ACEX1K combination before
> releasing.
> Not only that, in QII 1.1, NativeLink with LS-Altera (2001.1a_28) didn't
> even start (crashed at Quartus_cmp.exe), and I suspect lack of testing
> for the crash.

NativeLink...  I gotta tell ya, I don't use it.  There's a warm and cozy
feeling I get running the LS front-end tool, then importing the .EDF into
QII.  That way I know that everything gets done "right"...


>         Having seen these software problems, it is not surprising to me
> that no wonder Altera has only 10% of a highend FPGA market, and rest of
> 90% belongs to Xilinx.

Hmmm, while I believe that Xilinx has a larger market share, it wouldn't
suprise me to see the market turn (since it always does).

> I read some time ago on EE Times that much of the reason customers
> choose Virtex instead of APEX20K several years ago is because the
> quality of Quartus wasn't as good as Xilinx's software offering at the
> time.
> To me, software stability seems to be Altera's weakest point even now.

Stability was definitely a huge issue with the first release of Quartus.
Now that Quartus II is released, stability has gotten quite (I mean a whole
lot) better.


I suppose that's my two cents worth, and I hope its not too biased since I
am an Altera advocate...

rgds,
-Terry




Article: 40428
Subject: Re: exceeding 2GB limits in xilinx
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Thu, 07 Mar 2002 05:47:11 GMT
Links: << >>  << T >>  << A >>
On Wed, 06 Mar 2002 14:49:06 GMT, Ray Andraka <ray@andraka.com> wrote:

>It sounds like we are all barking up the wrong tree.  The solution is not to
>go to more and more memory...There is something to be said about using low
>cost PCs...instead, Xilinx needs to get the modular flow working so that one
>can truely partition a design and run each partition through the entire
>process, including place and route.  The individual completed parts can then
>be stitched together.  Until the modular flow is working though, we are stuck
>with the memory limits of the machines we work on.

Quite apart from the reduction in memory, this would also make PAR
much quicker!

I'm sure some of the algorithms they use must be at least O(N^2), so
breaking the problem into two halves will halve the total time taken.
(Or something like that.)

BTW, I see a significant speedup for large designs in Synplify if I
use the syn_hier attribute, which stops optimisations across module
boundaries.

Regards,
Allan.

>Johann Glaser wrote:
>
>> Hi!
>>
>> > The best solution is to move to 64-bit processors: Sun, IBM and HP (and
>> > some others) offer 64-bit workstations now, and there are a lot of EDA
>> > tools available (including all Xilinx tools). This is also a pretty
>> > expensive solution: workstations are much more expensive than PCs
>> > (probably slower nowaday), and EDA S/W for Unix is usually much more
>> > expensive than the same S/W for Windows (not familiar with Linux
>> > pricing).
>> >
>> > Right now, we are eagerly waiting for the AMD Hammer - this appears to
>> > be the perfect solution for us Windows users who are trying to build big
>> > FPGAs.
>>
>> This is the one solution. Use 64-bit pointers. Available in Linux
>> nowadays, upcoming for Windows in the future (but perhaps only in special
>> versions). Or on Workstations.
>>
>> Another idea would be to use a cluster for P&R. So, therefore P&R must be
>> done for some independant and seperabel parts. I don't know how P&R
>> software works and I'm afraid, it always needs the whole memory region,
>> but if smart programmers find a way to split P&R into several standalone
>> processes with only few communication, the easiest solution is a cluster.
>>
>> On machines with more than 3GB RAM each process itself can use 3GB.
>> Several processes so can use the whole memory. So, it isn't even necessary
>> to distribute the processes to numerous PCs.
>>
>> Linux is used very often for clusters, look for Mosix or Beowulf. In an
>> office with several FPGA designers all their PCs can be equiped with e.g.
>> Mosix and if one of them needs to do a P&R cycle, all PCs work together.
>> The priority system in Linux will do the rest, so all other workers don't
>> recognize a lot of the heavy load on their machine, because local
>> processes get fast reaction.
>>
>> "Fork and forget". Use more than one process for P&R and the rest is done
>> by the OS and the cluster Software.
>>
>> Advantage:
>>  - each PC can be a "normal" one with a rational amount of RAM and a not
>>    too expensive processor
>>  - enormous speed up of P&R
>>  - we will get native Linux tools :-)
>>
>> Or, why should your processor wait for your next keypress running at
>> 2GHz? ;-)
>>
>> Bye
>>   Hansi
>


Article: 40429
Subject: Re: exceeding 2GB limits in xilinx
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Thu, 7 Mar 2002 06:02:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3c86fdd9.8868772@netnews.agilent.com>,
Allan Herriman <allan_herriman.hates.spam@agilent.com> wrote:
>I'm sure some of the algorithms they use must be at least O(N^2), so
>breaking the problem into two halves will halve the total time taken.
>(Or something like that.)

No to mention that if you can do a good partitioning, you are a long
way towards making the tools able to use SMP and SMT architectures.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 40430
Subject: Re: Mutual Clock Synchronization
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Thu, 07 Mar 2002 06:10:09 GMT
Links: << >>  << T >>  << A >>
On Wed, 06 Mar 2002 18:19:46 -0500, Greg Neff <gregeneff@yahoo.com>
wrote:

>On Wed, 06 Mar 2002 21:08:39 GMT, John_H <johnhandwork@mail.com>
>wrote:
>
>I have not looked at the CEPT standard.  We are using E1 physical
>layer stuff for a non-telecom application.  Does the CEPT standard
>talk about mutual clock synchronization?  If so, I would appreciate a
>pointer to this standard.  I though that E1/T1 systems were typically
>clocked in a master/slave arrangement, or lived with slips.
>
> With regard to stability, I was thinking about the stability of the
>democratic clock, due to multiple feedback paths to the multiple phase
>error detectors on each PLL.
>
>>The references for stability...  shouldn't they be contained in the
>>ITU-T specifications regarding E1 reference timing?  The clock
>>distribution schemes, switchover conditions on signal loss, acceptable
>>jitter transfer and tolerance are all part of the CEPT standard.  Very
>>constrained.
>(snip)

As the other posters have mentioned, a "democratic" approach to timing
is unusual, and (to me) doesn't make sense.

Regarding the ITU-T specifications, I think you should look at the
SONET/SDH specs instead of the E1 ones.
Try: ITU-T G.707 (SDH) and the G.810 series (SDH timing).
Also GR-253 (SONET).

Even the Network Time Protocol (RFC1305) that is used to synchronise
time of day clocks on computers has a hierarchy of timing sources.
But it might give you some ideas that will help you with your problem.
http://www.ietf.org/rfc/rfc1305.txt

Oh, you should probably look at the datasheets for chips that are
designed for phone network timing, e.g. Zarlink (nee Mitel) MT90401
http://products.zarlink.com/partfinder/prodprofile.cgi?device=1127
or maybe this one from Semtech:
http://www.semtech.com/products/sets.html

Regards,
Allan.

Article: 40431
Subject: high active and low active reset signal mixed in a design
From: shengyu_shen@hotmail.com (ssy)
Date: 6 Mar 2002 23:12:26 -0800
Links: << >>  << T >>  << A >>
Hi everyone

in my design, some module use high active reset, and other use low
active reset, and the global reset is low active, so all high active
reset is generate by pass global reset through an inverter, if this
will cause any problem?

Article: 40432
Subject: Re: high active and low active reset signal mixed in a design
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 07 Mar 2002 20:12:48 +1300
Links: << >>  << T >>  << A >>
ssy wrote:
> 
> Hi everyone
> 
> in my design, some module use high active reset, and other use low
> active reset, and the global reset is low active, so all high active
> reset is generate by pass global reset through an inverter, if this
> will cause any problem?

Only if that inverter is placed inside a device that needs reset :-)
A tiny logic gate is ideal.

-jg

Article: 40433
Subject: Re: FPGA or DSP in a power supply?
From: frankmotje@hotmail.com (F. Modderkolk)
Date: 7 Mar 2002 00:13:07 -0800
Links: << >>  << T >>  << A >>
Maybe I don't quit understand the working of the fpga, so explain me
whem I'm wrong.
I want to give you give you an example why my resolution needs to be
so high.
When I'm switching the fets with 300 kHz and I can switch my output
with 300MHz, the following is  possible. Let's say the duty cycle of
my pulse is 40% ( it's always less than 50%). When I switch with 300
kHz, one period is 3,33333 us. the next frequncy I can create at my
output = 1/300k + 1/300M = 3,33666 us. That is a frequency of
299,700kHz. That is a difference of 300Hz. Such a difference means at
the output of the power supply a change of current of 0.2A. This is
because the working frequency is very small. I hope I made clear why I
need the high frequency.







Ray Andraka <ray@andraka.com> wrote in message news:<3C862BFA.6BD14523@andraka.com>...
> See my post to your previous post.  Knowing now what you are doing, I am
> sure you can get away with a much slower clock.  Jitter is not likely to
> be much of a problem in this application.  If, for example, you use a 10
> MHz clock and a 32 bit accumulator you get a frequency resolution of 0.002
> Hz with jitter no greater than 100ns (1 cycle of the master clock).  Your
> master clock determines the amount of jitter and the maximum output
> frequency (Fclk/2).  Resolution is determined just by the number of bits.
>

Article: 40434
Subject: pipeline
From: sdfg <sdlkf@uihre.aklhfd>
Date: Thu, 7 Mar 2002 00:23:39 -0800
Links: << >>  << T >>  << A >>
who can introduce some knowledge about pipeline(books/link)?

Article: 40435
Subject: Re: exceeding 2GB limits in xilinx
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 07 Mar 2002 09:45:28 +0100
Links: << >>  << T >>  << A >>
"Peter Ormsby" <faepete.deletethis@attbi.com> writes:

> Lars Rzymianowicz <larsrzy@atoll-net.de> wrote in message
> news:3C85C76F.3B5FA1A5@atoll-net.de...
> > And since Xilinx and most other EDA vendors support Linux now, why
> > step down to the bluescreen?
> 
> Just to be clear here, the Xilinx Linux solution is currently limited to
> command-line only on WINE.  For those unfamiliar with this approach, check
[...snip...]

Does anybody know why Xilinx did this rather than porting their
Solaris/HP-UX version to Linux?

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 40436
Subject: Re: exceeding 2GB limits in xilinx
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 07 Mar 2002 09:54:00 +0100
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> writes:

> It sounds like we are all barking up the wrong tree.  The solution is not to
> go to more and more memory...There is something to be said about using low
> cost PCs...instead, Xilinx needs to get the modular flow working so that one
> can truely partition a design and run each partition through the entire
[snip]
Johann Glaser:
> > Another idea would be to use a cluster for P&R. So, therefore P&R must be
> > done for some independant and seperabel parts. I don't know how P&R
[snip]

I agree with both of you. Even in a hierarchical/modular design
methodology you could benefit greatly of a cluster of cheap PCs do do
your job.

The EDA vendors seems to spend a lot of effort working on their GUIs.
I would like to see some effort spent on parallel synthesis and PAR
tools. The problem is that this is difficult to add later, you have to
design it in from the start.

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 40437
Subject: Re: FPGA or DSP in a power supply?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 07 Mar 2002 22:45:35 +1300
Links: << >>  << T >>  << A >>
F. Modderkolk wrote:
> 
> Maybe I don't quit understand the working of the fpga, so explain me
> whem I'm wrong.
> I want to give you give you an example why my resolution needs to be
> so high.
> When I'm switching the fets with 300 kHz and I can switch my output
> with 300MHz, the following is  possible. Let's say the duty cycle of
> my pulse is 40% ( it's always less than 50%). When I switch with 300
> kHz, one period is 3,33333 us. the next frequncy I can create at my
> output = 1/300k + 1/300M = 3,33666 us. That is a frequency of
> 299,700kHz. That is a difference of 300Hz. Such a difference means at
> the output of the power supply a change of current of 0.2A. This is
> because the working frequency is very small. I hope I made clear why I
> need the high frequency.

Since this sounds like a series resonant power supply, rather than a 
energy-transfer design, you could look at a 12 bit DAC and a VCO.
At 300KHz, this will be 1 part in 4096 in Freq, or in your case, 
a four fold improve in dI. ( same as a 1.2GHz FPGA :)

I believe 300MHz toggle & PLL is do-able in newest generation FPGA, 
but a 12 bit loadable counter at 300MHz is a bigger ask.
Peter or Ray will know the quick answer :-)

-jg
 
> Ray Andraka <ray@andraka.com> wrote in message news:<3C862BFA.6BD14523@andraka.com>...
> > See my post to your previous post.  Knowing now what you are doing, I am
> > sure you can get away with a much slower clock.  Jitter is not likely to
> > be much of a problem in this application.  If, for example, you use a 10
> > MHz clock and a 32 bit accumulator you get a frequency resolution of 0.002
> > Hz with jitter no greater than 100ns (1 cycle of the master clock).  Your
> > master clock determines the amount of jitter and the maximum output
> > frequency (Fclk/2).  Resolution is determined just by the number of bits.
> >

Article: 40438
Subject: Re: exceeding 2GB limits in xilinx
From: hamish@cloud.net.au
Date: 07 Mar 2002 10:07:34 GMT
Links: << >>  << T >>  << A >>
Rick Filipkiewicz <rick@algor.co.uk> wrote:
> What are the limitations on the modular design flow in real life ? I've looked at
> it and it seems clumsy and awkward but useable as long as the device density
> isn't too high, otherwise the limitation to rectangular regions will make layout
> difficult.

I found that the tool was just unable to properly place the logic. In
particular it had no idea how to place the interconnecting flip-flops
between the blocks. The modules I defined had very clean interfaces
(of up to 100 bits). P&R times were huge with very poor results.

I conclude that the idea is good but the current implementation is
unusable in my application.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 40439
Subject: DPRAM implementation in altera
From: dsredy3@mailcity.com (MegaPowerStar)
Date: 7 Mar 2002 02:08:51 -0800
Links: << >>  << T >>  << A >>
Hi 

Is there any equivalent verilog LPM/ALTPM function module from altera
for xillinx dualport ram block RAMB4_S16_S16 module.The currently
available DPRAM functions from altera(like
LPM_RAM_DP,ALTSYNCRAM,ALT3PRAM) do not match the above xillinx DPRAM
module.
If not how can I implement the DPRAM in altera device.

awaiting reply

thanx in adv.
regards
MPS

Article: 40440
Subject: Re: high active and low active reset signal mixed in a design
From: shengyu_shen@hotmail.com (ssy)
Date: 7 Mar 2002 03:50:04 -0800
Links: << >>  << T >>  << A >>
Hi

my question may seem a bit stupid, but if you know about my condition,
you can understand it.

 these days. I met with serious problem about simulation/synthesis
mismatch , so I search everywhere to find the cause, to make the
problem even worse, the post syn simulation just can not run
correctly.

thank you
Jim Granville <jim.granville@designtools.co.nz> wrote in message news:<3C8712F0.5DEE@designtools.co.nz>...
> ssy wrote:
> > 
> > Hi everyone
> > 
> > in my design, some module use high active reset, and other use low
> > active reset, and the global reset is low active, so all high active
> > reset is generate by pass global reset through an inverter, if this
> > will cause any problem?
> 
> Only if that inverter is placed inside a device that needs reset :-)
> A tiny logic gate is ideal.
> 
> -jg

Article: 40441
Subject: Converting old Mach 5 project from DSL to VHDL
From: "David Brown" <dav-nospam-id@westco-nospam-ntrol.com>
Date: Thu, 7 Mar 2002 13:50:14 +0100
Links: << >>  << T >>  << A >>
Hi,

We have an old project that used a Mach 5 PLD, programmed in DSL using
MachXL software, around 3 years ago.  We are now looking at updating the
project, and using a Mach 4 PLD instead (when we started, there were no Mach
4 chips that were big enough).  But the current design software does not
support the old DSL language.  Are there any tools or shortcuts that we
could use to convert the old DSL project to newer VHDL code?  We don't
actually need to make any significant changes to the functionality of the
design, just to fit it into a newer chip, so we'd really like to avoid
having to re-write everything in VHDL (or Verilog).

Many thanks for any help or tips.

David Brown
WestControl a.s
Norway.
david@westcontrol.com




Article: 40442
Subject: Re: exceeding 2GB limits in xilinx
From: Nial Stewart <nials@britain.agilent.com>
Date: Thu, 07 Mar 2002 14:12:10 +0000
Links: << >>  << T >>  << A >>
Petter Gustad wrote:
> 
> "Peter Ormsby" <faepete.deletethis@attbi.com> writes:
> 
> > Lars Rzymianowicz <larsrzy@atoll-net.de> wrote in message
> > news:3C85C76F.3B5FA1A5@atoll-net.de...
> > > And since Xilinx and most other EDA vendors support Linux now, why
> > > step down to the bluescreen?
> >
> > Just to be clear here, the Xilinx Linux solution is currently limited to
> > command-line only on WINE.  For those unfamiliar with this approach, check
> [...snip...]
> 
> Does anybody know why Xilinx did this rather than porting their
> Solaris/HP-UX version to Linux?
> 
> Petter

We've found that Xilinx tools running on HP Unix aren't as fast
as those running on a (comparable ?) PC.

I think this is because the tools are written on PCs and ported
to Unix/workstation architecture.

Porting this port back to Linux/PC architecture again might have the
effect of slowing them even more.

Nial (speculating wildly).

Article: 40443
Subject: Re: FPGA problems
From: paul.lee@sli-institute.ac.uk (Paul)
Date: 7 Mar 2002 06:12:38 -0800
Links: << >>  << T >>  << A >>
Hi

Sorry to bother you. i found the problem.

Thanks for all the advice.

Paul

paul.lee@sli-institute.ac.uk (Paul) wrote in message news:<9aeb7852.0203060848.10327822@posting.google.com>...
> Hi
> 
> Basically the circuit input and output consist of a decoder and
> encoder. All the signals are clocked before entering the system. I
> have done some test today and everything seem to be working fine when
> I connect the output to the input of the system but when using a GPS
> system to produced the input datastream, the system decodes it
> incorrectly. I have measured the signals/datastream produced by the
> GPS and it seem to be correct but once it enters the system and that
> is when it all goes wrong. The clock used to produced the trailing
> edge comes from the GPS system but it isn't the system clock. The GPS
> clock signal is used for the decoding process.
> What could be wrong with system?
> 
> Thanks 
> 
> Paul
> 
> 
> 
> kayrock66@yahoo.com (Jay) wrote in message news:<d049f91b.0203051241.14abc58d@posting.google.com>...
> > Maybe you can describe the circuit you're using, but if you're doing
> > something asynchronous that depends on the relative delays of gates
> > then all bets are off.  When you say this signal is a clock, is it THE
> > clock for the design, or can you sample it with another higher
> > freuency clock?
> > 
> > paul.lee@sli-institute.ac.uk (Paul) wrote in message news:<9aeb7852.0203050323.12f72b04@posting.google.com>...
> > > Hi everyone,
> > > 
> > > I'm producing a trailing edge pulse from a clock and passing it
> > > straight out as an output port for testing purposes but some of the
> > > pulses are missing when implementing onto a FPGA. It works fine when
> > > simulating with Modelsim.
> > > The clock going into the FPGA is correct.
> > > 
> > > Could it be a metastability issues? 
> > > 
> > > 
> > > Any help will be great.
> > > 
> > > Thanks 
> > > 
> > > Paul Lee

Article: 40444
Subject: How can I install Xilinx ISE 4.1i under Linux?
From: "dano" <dano@china.com>
Date: Thu, 7 Mar 2002 22:17:10 +0800
Links: << >>  << T >>  << A >>
Yes, I installed and configured WINE. And WINE works fine for many Windows
programs. Then I typed
$ wine setup
in the Installation directory. Then I entered my CDKEY. Then I select the
components I want to use. Everything seemed perfect before the real
installation begun. It just stuck at 0%. Finally, I lose my patience and
^C-ed the WINE.
The message on console indicated that the whole thing froze when "Create
ProcessA" for the JRE1.2.2 which ISE 4.1 is bundled with.
I checked the Internet, but find nothing about how to install Xilinx ISE 4.1
on my Debian GNU/Linux box. I am runing unstable dist.
Any suggestion?
Thank you.




Article: 40445
Subject: Re: high active and low active reset signal mixed in a design
From: "Phil Connor" <p.connorXXX@optionYYY.com>
Date: Thu, 7 Mar 2002 14:19:02 +0000 (UTC)
Links: << >>  << T >>  << A >>
"ssy" <shengyu_shen@hotmail.com> wrote in message
news:f4a5f64f.0203070350.2067c750@posting.google.com...

> 
>  these days. I met with serious problem about simulation/synthesis
> mismatch , so I search everywhere to find the cause, to make the
> problem even worse, the post syn simulation just can not run
> correctly.
> 
>

A first step might be to run the clock very slowly and see if the
synthesised chip behaves correctly.

Good luck

Phil 


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

Article: 40446
Subject: Re: FPGA or DSP in a power supply?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Mar 2002 15:02:04 GMT
Links: << >>  << T >>  << A >>
It's not the FPGA you don't follow, it is the direct digital synthesis that is eluding
you.  You can clock modern FPGAs at 300 MHz with careful design, but in your case there is
really no need to do so.  Clocking at a more comfortable 10-50 MHz will make the design
much easier, will permit a smaller part, will reduce your power, and will eliminate any
chance of needing a heatsink on the FPGA.

To the point, the reason a DDS gives you finer resolution than might be apparent is that
it accumulates fractional cycles.  This is manifested at the output by essentially
sampling the accumulated phase at the clock interval.  what that means is you can get very
fine frequency resolution but with some jitter due to the time sampling.  Picture the DDS
as a phase accumulator.  The accumulator bits represent a fraction of a revolution.  So if
you have a 4 bit accumulator, 0000 represents phase angle of 0, 0101= 5/16 of a
revolution, 1111=15/16 of a revolution.  Now if we have a fixed increment of 0101 or 5/16
then after 16 clocks we have gone around the phase circle exactly 5 times in the sequence:
0,5,10,15,4,9,14,3,8,13,2,7,12,1,6,11,0.  by setting the increment value we can go 1/16 to
8/16 times the input frequency, in steps with 1/16 the input frequency resolution.  For a
simple square wave, you can take the msb of the accumulator out.  In the example above
with an increment of 5 we then get the sequence:

0,0,1,1,0,1,1,0,1,1,0,0,1,0,0,1

Note that it gets better frequency resolution than would otherwise be apparent by
modulating the sequence of bits.  If you look closely, what it is doing is putting the
transitions at the clock interval closest to where it would be in an infinitely sampled
situation.  Now if we wanted to increase the resolution, we can add a bit to the
accumulator.  Sa instead of 5/16 * fclk we really needed 21/64* fclk.  If we have 32 bits
then we might use 11/32, getting the sequence:
0,11,22,1,12,23,2,13,24,3,14,25,4,15,26,5,16,27,6,17,28,7,18,29,8,19,30,9,20,31,10,21,0
which gives.

0, 0, 1 ,0, 0,  1 ,0, 0,  1, 0,  0,  1, 0, 0,  1,0 , 1,  1 ,0, 1 , 1 ,0, 1,   1,0,  1, 1,
0, 1,  1, 0,  1,

As you can see you now get 11 rising edges in 32 clocks instead of 5 in 16 (10 in 32).  By
adding a bit, we essentially increase the resolution by extending the time for the
sequence to repeat.  In all these sequences, the edges are as evenly spaced as possible
with the clock used, Hence the jitter of 1 cycle of your master clock we were speaking
of.  Unless your jitter requirement is less than 3ns, you have no reason to be working at
300 MHz.  In fact, if you use more than one of the MSBs, you can use the fractional pahse
angle with a DAC to get sub clock slicing.


"F. Modderkolk" wrote:

> Maybe I don't quit understand the working of the fpga, so explain me
> whem I'm wrong.
> I want to give you give you an example why my resolution needs to be
> so high.
> When I'm switching the fets with 300 kHz and I can switch my output
> with 300MHz, the following is  possible. Let's say the duty cycle of
> my pulse is 40% ( it's always less than 50%). When I switch with 300
> kHz, one period is 3,33333 us. the next frequncy I can create at my
> output = 1/300k + 1/300M = 3,33666 us. That is a frequency of
> 299,700kHz. That is a difference of 300Hz. Such a difference means at
> the output of the power supply a change of current of 0.2A. This is
> because the working frequency is very small. I hope I made clear why I
> need the high frequency.
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3C862BFA.6BD14523@andraka.com>...
> > See my post to your previous post.  Knowing now what you are doing, I am
> > sure you can get away with a much slower clock.  Jitter is not likely to
> > be much of a problem in this application.  If, for example, you use a 10
> > MHz clock and a 32 bit accumulator you get a frequency resolution of 0.002
> > Hz with jitter no greater than 100ns (1 cycle of the master clock).  Your
> > master clock determines the amount of jitter and the maximum output
> > frequency (Fclk/2).  Resolution is determined just by the number of bits.
> >


Article: 40447
Subject: Re: Fast transmission
From: "Roberto Capobianco" <capobianco@igi.pd.cnr.it>
Date: Thu, 7 Mar 2002 16:08:05 +0100
Links: << >>  << T >>  << A >>
Thank you Peter for reply,
yes i have a 100MHz free running receiver clock (4x oversampling).
Just few questions. In the case of NRZ transmission is correct to
synchronize the incoming signal with
my 100MHz clock (with a classic two stage flip-flops, no problem for me two
clock cycles delay) and after
to do sampling on synchronized signal or is better to do sampling directly
on incoming signal ?
In the case of Manchester transmission (50MHz transmission clock in this
case) receiver clock should be 200MHz (4x oversampling).
Maybe this frequency is too high for me. Can i do a manchester decoder with
different technique, maybe PLL with 50MHz
reference clock ?

Thanks.


Roberto Capobianco
Consorzio RFX - CNR di Padova
C.so Stati Uniti, 4
35127 - Camin (PD)
email: capobianco@igi.pd.cnr.it
web: www.igi.pd.cnr.it
tel.: +39-049-8295048
fax: +39-049-8700718





"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:3C86944B.F4D25F0@xilinx.com...
> NRZ is fine if you have exactly the same clock at the transmitting and the
> receiving end.
> If there is any question about clock accuracy, then Manchester is much
better,
> since it is kind of self-clocking. But it has far more transitions ( max
two per
> bit, vs max 1 for NRZ). That limits the max bandwidt, but may not be a
problem
> with fibre.
> 8 or even 4 times oversampling with a free-running receiver clock is ok,
> provided you have solid signals, and almost no clock frequency
uncertainty.
>
> Peter Alfke, Xilinx Applications
> ==============================
> Roberto Capobianco wrote:
>
> > Hi all,
> > i want to send on fiber a digital pattern of approximately 50 bits with
Tbit
> > = 40ns (25MHz transmission clock).
> > First question : NRZ or Manchester code ?
> > Second question: UART and Manchester decoders in FPGA often use 16x
> > oversampling to sample at mid-bit of data cell.
> > This is impossible for me.
> > In the design at http://www.xilinx.com/xcell/xl17/xl17-30.pdf  we have a
8x
> > oversampling manchester decoder
> > but with my flex (Altera ACEX 1K) is very difficult to have a single
global
> > clock at 200MHz for all.
> > Exist different ways to realize a good sampling with a low frequency ?
> >
> > Thanks.
> >
> > --
> > Roberto Capobianco
> > Consorzio RFX - CNR di Padova
> > C.so Stati Uniti, 4
> > 35127 - Camin (PD)
> > email: capobianco@igi.pd.cnr.it
> > web: www.igi.pd.cnr.it
> > tel.: +39-049-8295048
> > fax: +39-049-8700718
>



Article: 40448
Subject: Re: Rising and falling edge of a clk
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Thu, 07 Mar 2002 10:14:45 -0500
Links: << >>  << T >>  << A >>
Ray,
    How does one instantiate the BRAM directly?  I am using VHDL if that has any
impact on the question.  Can you give me a code snippet as an example?

Thanks,
Theron Hicks


Ray Andraka wrote:

> Personally, I prefer to instantiate the BRAM primitives directly rather than
> using the coregen.  That way you lose the extra layer of abstraction, that in
> this case does little more than make it harder to simulate.  If you do use the
> BRAM generator and select register inputs under the design options, then putting
> a small combinatorial mux in front of it should put the mux with the registers
> (at least the last layer of the mux if it is more than 2 inputs).  If you are
> instantiating the BRAMs, then your muxes should be registered.  One note of
> caution: if you are trying to get the most speed, keep in mind that you want the
> registers as close as possible to the BRAM.  Putting muxes with those registers
> is going to tend to congest the routing there, which may slow your critical BRAM
> connections.  For that matter, it also helps to keep the width of the BRAM
> relatively small so you don't have a ton of data lines going in and out
> (especially for dual ports with both ports used in both directions).
>
> "H.L" wrote:
>
> > Hello Ray,
> > thanks a lot your post clarified things.
> > Xilinx Core Generator cant put additional register on the EN signal, so the
> > only thing is to instantiate a D flip-flop and put it in the right place?
> >
> > Regarding my project I have to arbitrate the access in 3 BRAMs (registered
> > for the reason described above) so I think I must use a MUX_BUS from the
> > CORE GENERATOR (one MUX_BUS for each BRAM).  I will use 3 MUX_BUS with 3
> > input 41-bit buses (32 for the data, 7 for the address, 2 bits for EN,WE).
> > If I use non-registered MUXs I think is not good for the following reasons:
> > 1) The timing analysis will not include them in the period calculation so I
> > will not be able to see if my FPGA meets the timing constraints
> > 2) Combinatorial logic in the BRAM paths. Here is my second question, as I
> > said before I am going to use registered BRAMs do you think that these
> > registers are capable to cope with the inserted MUXs' combinatorial logic? I
> > don't know if these MUXs I'll use can be described as "large" or "small"
> > combinatorial logic.
> >
> > So the right thing to do is to use registered MUXs (LUT based only as Xilinx
> > says)?
> >
> > Best Regards,
> > Harris
> >
> > "Ray Andraka" <ray@andraka.com> wrote in message
> > news:3C824FD0.71540235@andraka.com...
> > >
> > >
> > > "H.L" wrote:
> > >
> > > > Hi Ray,
> > > > I have seen these tips written by you many times in this group. I have
> > them
> > > > always as a guide but I want to see if I understand them right. Please
> > > > correct me where I am wrong:
> > > >
> > > > 1) The need for additional registers in DATA_IN and ADDR signals.
> > > > In BRAMs the EN and WE signals  have long set-up times thats why we need
> > to
> > > > register the data_in and addr of the BRAM, in this way the addr and
> > data_in
> > > > signals have a clock period delay.As EN,WE reach the BRAM 1 clock period
> > > > earlier (at 155MHz  clock speed that means about 6 ns) the setup-time
> > for
> > > > these signals is not violated resulting BRAM to be in the operation mode
> > we
> > > > wish (read or write) the moment addr and data_in arrive.
> > >
> > > If you look at the data sheet, there are fairly long set-up times on all
> > the
> > > BRAM inputs.  Routing to the BRAMs also adds to the delay, as does any
> > > combinatorial logic on these inputs.  The idea of putting registers on the
> > > inputs (which includes the EN and WE inputs) is to minimize the amount of
> > delay
> > > added externally to these signals.  Your understanding is a bit incorrect,
> > as
> > > what you are suggesting is delaying signals to allow a long combinatorial
> > > delay.  That is dangerous, because there is no guarantee on the minimum
> > delay.
> > > Instead, what I am suggesting is to remove as much of the delay as
> > possible
> > > between the registers driving the BRAM inputs and the BRAM inputs, which
> > meahs
> > > avoiding combinatorial logic on these paths, minimizing the fanout of
> > these
> > > signals, and physically locating the registers close to the BRAMs.
> > >
> > > >
> > > > 2) The need for floorplanning
> > > > Xilinx software tool maybe has put the additional registers far from the
> > > > BRAMs, if this is the case we must manual place them near the BRAM to
> > > > decrease the propagation delay of the signals.
> > >
> > > That is correct.  Routing in FPGAs is not just wire, it also consists of
> > > switches which add to the propagation delay of signals on the connections
> > > between logic.  Manually placing the registers near the BRAM helps to
> > minimize
> > > the added delay.
> > >
> > > >
> > > > 3) Tying the WE,EN inputs and contol access through the address when
> > working
> > > > at high speeds.
> > > > Do you mean to keep WE,EN high all the time and when we wish not to use
> > the
> > > > BRAMs to write dummy data in some (or just one) specified addresses (or
> > > > address) reserved for this reason?
> > >
> > > That is correct.  The set up times for EN and WE are nearly twice the
> > set-up
> > > times for address and data, so if we can eliminate these from the equation
> > we
> > > can run at a higher clock rate.  They can be eliminated by always writing,
> > but
> > > directing the writes of invalid data to locations where it does not affect
> > the
> > > operation of the design.  In the case of FIFOs, you can just park the
> > write
> > > address until you have a valid write, since you are presumably not reading
> > that
> > > data until it is valid.
> > >
> > > >
> > > >
> > > > Also I have another one question about BRAMs, Xilinx says that BRAMs'
> > DATA
> > > > OUT are already registered. In Xilinx Floorplanner I believe this
> > register
> > > > is "inside" the BLKRAM box so no manual floorplanning for the output is
> > > > needed. You need to manual floorplan (in the same way you do for the
> > inputs)
> > > > only if you choose to add an additional output register, correct?
> > >
> > > That is correct, the BRAM acts as though it is registered, although I
> > believe
> > > the actual implementation has the register on the address, not on the
> > memroy
> > > outputs.  In any event, the clock to out time is long compared to that of
> > the
> > > CLB flip-flops.  The system clock rate can be increased by putting an
> > additional
> > > register on the BRAM data outputs and placing that register physically
> > close to
> > > the BRAM (that register should have no combinatorial logic in front of
> > it).
> > >
> > > >
> > > >
> > > > I really appreciate your help.
> > > >
> > > > Best Regards,
> > > > Harris
> > > >
> > > > "Ray Andraka" <ray@andraka.com> wrote in message
> > > > news:3C7FD73D.F6A3109A@andraka.com...
> > > > > VirtexE BRAMs can be written at 155MHz in any speed grade.  To do so,
> > you
> > > > will
> > > > > likely have to put registers near to and with no logic between them
> > and
> > > > the
> > > > > BRAMs.  Watch the loading too, routing to more than 1 BRAM for each
> > > > register may
> > > > > cause you some heartburn.  At higher speeds, you probably should also
> > > > consider
> > > > > tying the WE, and ENA inputs active and controlling your access
> > through
> > > > the
> > > > > address registers instead.  You'll also need to floorplan the
> > registers to
> > > > make
> > > > > sure they are located physically close to the BRAMs.
> > > > >
> > > > > "H.L" wrote:
> > > > >
> > > > > > Hi Peter, thanks for your reply
> > > > > > I was confident of this method's effectiveness but now I am worried
> > :))
> > > > . I
> > > > > > have already done a timing analysis in the paper and also the
> > simulation
> > > > > > waveforms seem promising.
> > > > > > I didnt understand what do you mean when telling me that one of my
> > words
> > > > > > arrives early and the other one late. The transmitter sends to my
> > FPGA
> > > > an
> > > > > > external clock (thats the 155MHz clock), a valid signal (1 bit
> > > > indicating
> > > > > > the transmission time period) and of course the 16-bit words that I
> > have
> > > > to
> > > > > > store. Every clock period (~6 ns) I have available in my ports one
> > > > 16-bit
> > > > > > word, I register two sequential words from the in port to a 32-bit
> > > > register
> > > > > > (31->16 the first incoming word, 15->0 the second one). Then , in
> > > > another
> > > > > > 32-bit register I register (2 nd time) the 32-bit word I just "made"
> > > > which
> > > > > > are the BRAM data_in. All the above operations are in a process that
> > has
> > > > in
> > > > > > its sensitivity list the 155 clock. I write to the BRAM at 77MHz
> > using
> > > > the
> > > > > > incoming clock divide by 2 using a DLL. BRAM input signals are
> > assigned
> > > > in
> > > > > > the falling edge of the 77MHz clock so as to be before the rising
> > edge
> > > > (of
> > > > > > the same clock) where the BRAM samples them. The write operations
> > are in
> > > > > > another process with the slow clock in its sensitivity list.
> > > > > > The timing waveforms of the simulation are the same with the timing
> > > > analysis
> > > > > > in paper but does this is a valid hardware design technique?
> > > > > > Thanks for your time and help!
> > > > > >
> > > > > > Best Regards,
> > > > > > Harris
> > > > > >
> > > > > > p.s: thats a small part of my design. I use DLL because other parts
> > need
> > > > > > them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155
> > MHz
> > > > and I
> > > > > > got many timing errors (floorplanning managed to reduce them but
> > still
> > > > lot
> > > > > > of work to be done)
> > > > > >
> > > > > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> > > > > > news:3C7E621F.1E77A244@xilinx.com...
> > > > > > > I suggest you grab pencil and paper and do a clock-by-clock timing
> > > > > > analysis. You
> > > > > > > will find that your clock-speed reduction buys you nothing, unless
> > you
> > > > > > also
> > > > > > > double-buffer the data.
> > > > > > > One of your words arrives nice and early, the other one late.
> > However
> > > > you
> > > > > > clock
> > > > > > > the BRAM, one of the two words has the same old short set-up
> > time...
> > > > > > > Double-buffering would help. But Ray has mentioned some neat
> > tricks to
> > > > > > avoid the
> > > > > > > long set-up time of the control inputs.
> > > > > > >
> > > > > > > I will get back with more constructive notes. "Gotta run"
> > > > > > >
> > > > > > > Peter Alfke
> > > > > > > ===================
> > > > > > > "H.L" wrote:
> > > > > > >
> > > > > > > > Hello all,
> > > > > > > >
> > > > > > > > I have a module that accepts 16 bit words at 155MHz and I want
> > to
> > > > store
> > > > > > then
> > > > > > > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA)
> > to
> > > > > > divide by
> > > > > > > > 2 the 155MHz clock as this frequency seems to be pretty high to
> > > > write in
> > > > > > the
> > > > > > > > BRAM. So far I think 2 processes are enough to do my job, one
> > > > operating
> > > > > > @
> > > > > > > > 155MHz to accept the 16-bit data and store them in a 32-bit
> > register
> > > > and
> > > > > > the
> > > > > > > > another one @ 75MHz to write the content of the 32-bit register
> > in
> > > > the
> > > > > > BRAM.
> > > > > > > > I am thinking to assign the BRAM's signals
> > > > > > (ENABLE,WRITE,ADDRESS,DATA_IN) in
> > > > > > > > the falling edge of the 75MHz clock, the main reason for this is
> > the
> > > > > > setup
> > > > > > > > time of the BRAMs signals (in this way the address,data are 6 ns
> > > > before
> > > > > > next
> > > > > > > > rising edge of the clock where BRAM samples its inputs). My
> > question
> > > > now
> > > > > > :)
> > > > > > > > , if one process uses the falling edge of one clock does this
> > causes
> > > > > > > > problems to other processes in the design , e.g to processes
> > that
> > > > use a
> > > > > > > > different clock or to  processes using the rising edge of the
> > same
> > > > > > clock?
> > > > > > > >
> > > > > > > > Best Regards,
> > > > > > > > Harris.
> > > > > > >
> > > > >
> > > > > --
> > > > > --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: 40449
Subject: Re: high active and low active reset signal mixed in a design
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Thu, 07 Mar 2002 15:21:04 GMT
Links: << >>  << T >>  << A >>
On 7 Mar 2002 03:50:04 -0800, shengyu_shen@hotmail.com (ssy) wrote:

>Hi
>
>my question may seem a bit stupid, but if you know about my condition,
>you can understand it.
>
> these days. I met with serious problem about simulation/synthesis
>mismatch , so I search everywhere to find the cause, to make the
>problem even worse, the post syn simulation just can not run
>correctly.

it's usually a bit of detective work unless the problem is obvious. It
could be a problem with your RTL where the synthesized hardware is not
what you think it will be. Or it could be a synthesizer bug which is
less likely. 
The solution is to try to isolate the bug. First do a simulation
without any timing annotated. If that works but not the annotated
netlist, you know you have  a timing problem. If you have a
multi-module design, you should individually synthesize the modules
and do a mixed RTL, gate level simulation and see which module breaks.
Of course by looking at how the gate level breaks, you should have
some idea which module could be the problem. If all the modules singly
synthesized, work correctly it is more likely a cross-boundry
optimization problem with synthesis. If you find one of the modules
breaking when synthesized, read the RTL carefully to see if you're
following all the rules of the specific tool for synthesizable subset
of the HDL you're using. 
These are some of the ways you can try to pinpoint the problem. Good
luck.

Muzaffer Kal

http://www.dspia.com
ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations



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

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