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 110675

Article: 110675
Subject: Microblaze uclinux Kernel panic
From: "Francesco" <francesco.poderico@trendcomms.com>
Date: 19 Oct 2006 08:43:47 -0700
Links: << >>  << T >>  << A >>
Hi I'm trying to porting uclinux using microblaze 4.0.
When I try to run the OS I've got the following error message.

Kernel panic: VFS: Unable to mount root fs on 1f:00

Does anybody had a similar problem?

Thanks in advance,
Francesco


Article: 110676
Subject: Re: WebPack on Linux
From: Henrik Pedersen <henrik.kirneh@gmail.com>
Date: Thu, 19 Oct 2006 18:15:51 +0200
Links: << >>  << T >>  << A >>
Josh Rosen wrote:

> On Thu, 19 Oct 2006 16:38:26 +0200, Henrik Pedersen wrote:
> 
>> Josh Rosen wrote:
>> 
>>> On Thu, 19 Oct 2006 13:54:10 +0200, Henrik Pedersen wrote:
>>> 
>>>> Next problem.
>>>> 
>>>> Running a simulation turns up the following error.
>>>> ERROR:Simulator:222 - Generated C++ compilation was unsuccessful
>>>> 
>>>> Seaching Xilinx.com does'nt give many ideas as to what is happening.
>>>> 
>>>> Anyone here has a clue ?
>>>> 
>>>> Henrik
>>> 
>>> What simulator are you using?
>> 
>> I was told that Multisim was'nt supported for the free edition of webpack
>> for Linux, så i'm trying to make the ISE simulator work.
>> 
>> Henrik
> 
> I don't know anyone who is using the ISE simulator. Most people use NCsim,
> VCS or ModelSim, I use NC. If you are looking for a free simulator I'd
> suggest that you give icarus a try.
> 
> http://www.icarus.com/eda/verilog/


I ment ModelSim offcourse.
I would like to use ModelSim, as i have some experience with it.
Does Icarus support VHDL as well as Verilog ?

Henrik

Article: 110677
Subject: FAQ: Re: Fastest ISE Compile PC?
From: "Tommy Thorn" <tommy.thorn@gmail.com>
Date: 19 Oct 2006 09:19:03 -0700
Links: << >>  << T >>  << A >>
Marc, why didn't you try to google for the answer? This question is
asked every other week on comp.arch.fpga. I only reply because I have
some new numbers.

marc_ely wrote:
> Has anyone recently done any benchmarking of Windows PC's for Xilinx
> ISE Compiles?

No, but I have for Quartus which is very similar.

> Is ISE multithreaded?

No and not for a while to come.

> Can it use multiple processors (or cores)?

Nope.

> Do big CPU caches help?

Oh yeah, but once you have that, core frequency is all that matters.

I recently went from an Athlon 64 2.0 GHz/1 MiB L2$ to a E6600 Core 2
Duo 2.4 GHz/4 MiB L2$. For my benchmark, the time for Synth/P&R went
from 12m34/33m40 to ~6m/~15m, thus more then double the P&R
performance. When overclocked to 3.3 GHz the result scaled to
5m54/11m12, thus 3X the P&R performance. Other experiments confirm that
it scales linearly with frequency (assuming memory scales equally).

I have expensive memory, but from my experiments the benchmark results
showed very little sensitivity to memory bandwidth and latency.

The 4 MiB Core 2 Duo is a very fast chip for FPGA work, probably the
fastest x86 available, but it's still not fast enough to reduce the
compilation times to an acceptable level.

Tommy


Article: 110678
Subject: Re: Microblaze uclinux Kernel panic
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: Thu, 19 Oct 2006 09:19:48 -0700
Links: << >>  << T >>  << A >>
Francesco wrote:
> Hi I'm trying to porting uclinux using microblaze 4.0.
> When I try to run the OS I've got the following error message.
> 
> Kernel panic: VFS: Unable to mount root fs on 1f:00
> 
> Does anybody had a similar problem?
> 
> Thanks in advance,
> Francesco
> 

Linux is up but it can't mount the root
partition. What is your kernel command line?
What is the "root=xxx" specifically. That device
number 1f:00 seems screwy. It's not listed in
include/linux/major.h.

-Dave

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Article: 110679
Subject: Re: Cheapest FPGA board to study VHDL on
From: samiam <samiamSPAMTHIS@spamalert.com>
Date: Thu, 19 Oct 2006 16:26:26 GMT
Links: << >>  << T >>  << A >>
> Digilent has a $59 board with a 100k-gate FPGA, switches, port
> connectors, LEDs etc.
> http://digilentinc.com/Products/Detail.cfm?Prod=BASYS

BINGO!!!

Id like to start there ... after I have gained some experience, I can
buy a more more expensive FPGA board with larger resources

Thanks

> I think that seeing something work in reality is an important part of
> learning, even though simulators give you more insight into what's
> happening.  Otherwise you get to your first real design after a few
> years of learning VHDL and then you ask 'what does non-synthesizable
> mean?'

I like to put equal time in reading/research as I do in "lab work".

Theres a certain joy and "ahah" factor that comes from seeing the
results in front of you.

priceless!

Article: 110680
Subject: Re: Scoreboard and Checker in Testbench?
From: "Alex" <agnusin@gmail.com>
Date: 19 Oct 2006 09:26:49 -0700
Links: << >>  << T >>  << A >>
NigelE wrote:

> I actually think the broad scope of TLM is one of its key strengths.
> Being able to apply the same techniques across a wide range of problems
> means the same methodology can be used at multiple abstraction levels.
> Transactors are used to communicate across these abstraction boundaries
> (not just the TLM<>signal boundary) enabling modelling to occur at the
> highest abstraction level appropriate resulting in smaller/faster code.

Sorry, Nigel, I don't agree with this.
Broad definitions lead to ambiguity. Everything which is not formalized
is ambiguis. Ambiguity of the basic terms leads to ambiguity of the
whole system, based on these terms.

We all know how difficult is to work with ambiguis specifications. The
problem is that we believe that we understand correctly the meaning of
some term, and don't do any efforts to clarify things further. Then, we
spend significant amount of time and energy in wrong direction.

As verification engineers, we have to formalize design specification
documents in verification plans, thus removing ambiguity from them.
However, we have ambiguity in our own definitions, which leads to many
communication problems. Transaction definition is one example. Here is
another one: what is the difference between assertions, assertion
monitors, asertion-based checkers, non-assertion-based checkers and
scoreboards? All of them validate the correctness od some design
properties during all simulation time and independently of stimulus.

> A quick point on AVM monitors.
> The AVM provides a capability called an analysis port (which is an
> implementation of the OO design observer design pattern).
>
> An analysis port provides a mechanism for a monitor to broadcast
> transactions to zero or more subscribers (listeners) via a single
> write() function call.
>
> The subscribers need to implement a write() function, each of which can
> do different things (eg record functional coverage, update a scoreboard
> etc). Thus a monitor does not need to know in what context it will be
> used as it is only in the top level environment of the simulation where
> analysis components are registered onto a particular analysis port.
>
> This makes AVM monitors extremely generic, being able to be used in
> module, chip and system verification and across multiple designs using
> the same interface.

Thanks for clarification. In this case, the monitors are not
"transaction senders" but rather "transaction presenters", which really
make them highly reusable. I am also using similar concept to build
Verilog testbenches for more than 4 years. 

Regards,
-Alex


Article: 110681
Subject: Re: WebPack on Linux
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Thu, 19 Oct 2006 12:28:01 -0400
Links: << >>  << T >>  << A >>
On Thu, 19 Oct 2006 18:15:51 +0200, Henrik Pedersen wrote:

> Josh Rosen wrote:
> 
>> On Thu, 19 Oct 2006 16:38:26 +0200, Henrik Pedersen wrote:
>> 
>>> Josh Rosen wrote:
>>> 
>>>> On Thu, 19 Oct 2006 13:54:10 +0200, Henrik Pedersen wrote:
>>>> 
>>>>> Next problem.
>>>>> 
>>>>> Running a simulation turns up the following error.
>>>>> ERROR:Simulator:222 - Generated C++ compilation was unsuccessful
>>>>> 
>>>>> Seaching Xilinx.com does'nt give many ideas as to what is happening.
>>>>> 
>>>>> Anyone here has a clue ?
>>>>> 
>>>>> Henrik
>>>> 
>>>> What simulator are you using?
>>> 
>>> I was told that Multisim was'nt supported for the free edition of webpack
>>> for Linux, så i'm trying to make the ISE simulator work.
>>> 
>>> Henrik
>> 
>> I don't know anyone who is using the ISE simulator. Most people use NCsim,
>> VCS or ModelSim, I use NC. If you are looking for a free simulator I'd
>> suggest that you give icarus a try.
>> 
>> http://www.icarus.com/eda/verilog/
> 
> 
> I ment ModelSim offcourse.
> I would like to use ModelSim, as i have some experience with it.
> Does Icarus support VHDL as well as Verilog ?
> 
> Henrik

Icarus is Verilog. There are some free VHDL projects out there, I don't
know anything about them, I use Verilog.


Article: 110682
Subject: Re: Scoreboard and Checker in Testbench?
From: "Alex" <agnusin@gmail.com>
Date: 19 Oct 2006 09:28:29 -0700
Links: << >>  << T >>  << A >>
NigelE wrote:

> I actually think the broad scope of TLM is one of its key strengths.
> Being able to apply the same techniques across a wide range of problems
> means the same methodology can be used at multiple abstraction levels.
> Transactors are used to communicate across these abstraction boundaries
> (not just the TLM<>signal boundary) enabling modelling to occur at the
> highest abstraction level appropriate resulting in smaller/faster code.

Sorry, Nigel, I don't agree with this.
Broad definitions lead to ambiguity. Everything which is not formalized
is ambiguis. Ambiguity of the basic terms leads to ambiguity of the
whole system, based on these terms.

We all know how difficult is to work with ambiguis specifications. The
problem is that we believe that we understand correctly the meaning of
some term, and don't do any efforts to clarify things further. Then, we
spend significant amount of time and energy in wrong direction.

As verification engineers, we have to formalize design specification
documents in verification plans, thus removing ambiguity from them.
However, we have ambiguity in our own definitions, which leads to many
communication problems. Transaction definition is one example. Here is
another one: what is the difference between assertions, assertion
monitors, asertion-based checkers, non-assertion-based checkers and
scoreboards? All of them validate the correctness od some design
properties during all simulation time and independently of stimulus.

> A quick point on AVM monitors.
> The AVM provides a capability called an analysis port (which is an
> implementation of the OO design observer design pattern).
>
> An analysis port provides a mechanism for a monitor to broadcast
> transactions to zero or more subscribers (listeners) via a single
> write() function call.
>
> The subscribers need to implement a write() function, each of which can
> do different things (eg record functional coverage, update a scoreboard
> etc). Thus a monitor does not need to know in what context it will be
> used as it is only in the top level environment of the simulation where
> analysis components are registered onto a particular analysis port.
>
> This makes AVM monitors extremely generic, being able to be used in
> module, chip and system verification and across multiple designs using
> the same interface.

Thanks for clarification. In this case, the monitors are not
"transaction senders" but rather "transaction presenters", which really
make them highly reusable. I am also using similar concept to build
Verilog testbenches. 

Regards,
-Alex


Article: 110683
Subject: Re: Scoreboard and Checker in Testbench?
From: "NigelE" <nigel_elliot@mentor.com>
Date: 19 Oct 2006 10:08:00 -0700
Links: << >>  << T >>  << A >>

Alex wrote:
> NigelE wrote:
>
> > I actually think the broad scope of TLM is one of its key strengths.
> > Being able to apply the same techniques across a wide range of problems
> > means the same methodology can be used at multiple abstraction levels.
> > Transactors are used to communicate across these abstraction boundaries
> > (not just the TLM<>signal boundary) enabling modelling to occur at the
> > highest abstraction level appropriate resulting in smaller/faster code.
>
> Sorry, Nigel, I don't agree with this.
> Broad definitions lead to ambiguity. Everything which is not formalized
> is ambiguis. Ambiguity of the basic terms leads to ambiguity of the
> whole system, based on these terms.
>
> We all know how difficult is to work with ambiguis specifications. The
> problem is that we believe that we understand correctly the meaning of
> some term, and don't do any efforts to clarify things further. Then, we
> spend significant amount of time and energy in wrong direction.
>
> As verification engineers, we have to formalize design specification
> documents in verification plans, thus removing ambiguity from them.
> However, we have ambiguity in our own definitions, which leads to many
> communication problems. Transaction definition is one example. Here is
> another one: what is the difference between assertions, assertion
> monitors, asertion-based checkers, non-assertion-based checkers and
> scoreboards? All of them validate the correctness od some design
> properties during all simulation time and independently of stimulus.
>
> > A quick point on AVM monitors.
> > The AVM provides a capability called an analysis port (which is an
> > implementation of the OO design observer design pattern).
> >
> > An analysis port provides a mechanism for a monitor to broadcast
> > transactions to zero or more subscribers (listeners) via a single
> > write() function call.
> >
> > The subscribers need to implement a write() function, each of which can
> > do different things (eg record functional coverage, update a scoreboard
> > etc). Thus a monitor does not need to know in what context it will be
> > used as it is only in the top level environment of the simulation where
> > analysis components are registered onto a particular analysis port.
> >
> > This makes AVM monitors extremely generic, being able to be used in
> > module, chip and system verification and across multiple designs using
> > the same interface.
>
> Thanks for clarification. In this case, the monitors are not
> "transaction senders" but rather "transaction presenters", which really
> make them highly reusable. I am also using similar concept to build
> Verilog testbenches.
>
> Regards,
> -Alex

Alex,

I think this definition issue depends on the perspective you are
looking from ;)

I agree that within a verification team, you should have a clear,
common understanding of what each component should and shouldn't do.
However, what may be suitable for one team may be too loose OR too
restrictive for another team. Thus a methodology that can accommodate
most user requirements is one that can be broadly adopted.  However
that doesn't preclude it being used in a tightly defined manner.

I guess where we differ is who should be responsible for defining these
precise definitions - the user or the tool/methodology provider ?

Regards

- Nigel


Article: 110684
Subject: Re: Meeting Timing Constraint
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Thu, 19 Oct 2006 19:44:42 +0200
Links: << >>  << T >>  << A >>
Roger schrieb:

> A design is built to work at 50MHz, but the deisgn when tested works
> only at 48MHz. What
> should we do to make the design meet specific timing constraint .i.e.
> to make the design to make it work at 50 MHz? 

Read the report of the critical path. You need to understand, where this
path is located (not the placement - I mean the logical connection from
one flipflop to an other) and why it is so long. Then think about
shortening the path. (Maybe you can insert a pipeline step or move some
combinational logic block outside this path.)


Ralf

Article: 110685
Subject: Re: An implementation of a clean reset signal
From: "Eli Bendersky" <eliben@gmail.com>
Date: 19 Oct 2006 11:04:42 -0700
Links: << >>  << T >>  << A >>

Al wrote:
> Eli Bendersky wrote:
> > The solution usually used is an external
> > reset circuit (they come packed in nice tiny ICs these days) that
> > provides a clean reset signal of 200 ms (or whatever you set it to)
> > whenever there's a problem with the supplies, and as a byproduct, when
> > the power is going up.
>
> Excuse me Eli, can you give me a reference for those tiny ICs?
> thanks a lot
>
> Al
>

Hello Al,

Googling "voltage supervisor" will bring up lots of results

Eli


Article: 110686
Subject: Re: Meeting Timing Constraint
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 19 Oct 2006 18:17:42 GMT
Links: << >>  << T >>  << A >>
"Roger" <hpsham@gmail.com> wrote:

>A design is built to work at 50MHz, but the deisgn when tested works
>only at 48MHz. What
>should we do to make the design meet specific timing constraint .i.e.
>to make the design to make it work at 50 MHz? 
>Thanks

Are you sure all signals are covered by timing constraints? Don't
forget connections which connect IO cells to internal flipflops. These
should be constrained as well.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 110687
Subject: Re: Fixing Down Parts of Logic in ISE (8.2)
From: Joseph Samson <user@example.net>
Date: Thu, 19 Oct 2006 18:27:49 GMT
Links: << >>  << T >>  << A >>
marc_ely wrote:
> I would really like to fix down some of the blocks to stop the Xilinx
> tool re-placing etc.
<snip>
> 
> At first glance there seems to be many options in the Xilinx tools to
> do this, but I can't get any of them to work properly.
> So far I have tried the following:
<snip>
>  - Planahead.  Beta, poor doc's, didn't know where to start really.
> Even my FAE doesn't have a scooby-doo about this one.

I have to come to the defense of PlanAhead here. Although I don't use it 
as part of an incremental flow, I do use it to improve timing, and I 
found it surprisingly easy to use. I watched the video-on-demand demo, 
scanned the documentation then started floorplanning. In most cases I've 
found it sufficient to just assign area groups to modules, but it's not 
hard to lock the placement (but not routing) of logic elements within 
the module.

---
Joe Samson
Pixel Velocity

Article: 110688
Subject: Re: Scoreboard and Checker in Testbench?
From: "Alex" <agnusin@gmail.com>
Date: 19 Oct 2006 12:32:13 -0700
Links: << >>  << T >>  << A >>
> Alex,
>
> I think this definition issue depends on the perspective you are
> looking from ;)
>
> I agree that within a verification team, you should have a clear,
> common understanding of what each component should and shouldn't do.
> However, what may be suitable for one team may be too loose OR too
> restrictive for another team. Thus a methodology that can accommodate
> most user requirements is one that can be broadly adopted.  However
> that doesn't preclude it being used in a tightly defined manner.

In this context, I am not speaking about "what each component should
and shouldn't do". I am speaking about terminology and basic
definitions. The whole industry will betefit from speaking the same
language. Imagine, for example, job interview question: "What is
scoreboard?". Or : "What does transaction mean?". The applicant is
lucky, if his/her understanding of scoreboard/transaction matches the
understanding of the interviewer.


> I guess where we differ is who should be responsible for defining these
> precise definitions - the user or the tool/methodology provider ?

For me, there is only one answer: methodology provider. Methodiology is
a building, and definitions/concepts are the building blocks. If the
shape of building block changes (at least, slightly), the shape of the
whole buiding changes significantly. Then, user definitions are not
always complementary - they can also contradict. The attempt of "being
nice to everyone by making loose definitions" may reduce the technical
value of the whole methodology, developed by EDA company.

Regards,
-Alex


Article: 110689
Subject: Re: DDR access for multiple procs on a ML310 (Virtex-II Pro)
From: Siva Velusamy <siva.velusamy@xilinx.com>
Date: Thu, 19 Oct 2006 15:12:10 -0700
Links: << >>  << T >>  << A >>
Stevo_V2pro wrote:
> Does anyone know if it is possible to have mutltiple processors be able
> to access the DDR memory in an ML310 board(Virtex-II Pro)?  Currently I
> am experimenting with 2 PowerPC cores, but I am also looking into using
> a single PPC core and a single microblaze core.  I'm intending to run a
> seperate operating system on each of the cores and would like each to
> have access to a fast and decent sized amount of RAM.  I've seen guides
> using shared BRAMS for having two procs accessing the same memory for
> data sharing, but BRAMs are relatively small.  I'm not looking to share
> data between the procs.  Essentially, I want both processors to be able
> to use RAM, but have separate memory spaces within that RAM.  If this
> is not possible, is it possible for the two procs to have access to the
> same memory space, but to avoid collisions by assigning each operating
> system a spearate portion of that memory space to use?   I would assume
> that both processors need to be on the same bus as the memory
> controller, and some sort of bus arbitration mechanism would be needed.
>  Any help that anyone can provide would be greatly appreciated.
> 

You can put both the processors on a single plb and use plb_ddr. If you 
are concerned about bandwidth, then you should look into MPMC2 design 
examples @ www.xilinx.com/mpmc2

/Siva

Article: 110690
Subject: Re: Meeting Timing Constraint
From: "VC" <chopra_vikram@excite.com>
Date: 19 Oct 2006 15:15:20 -0700
Links: << >>  << T >>  << A >>
Nico Coesel wrote:
> "Roger" <hpsham@gmail.com> wrote:
>
> >A design is built to work at 50MHz, but the deisgn when tested works
> >only at 48MHz. What
> >should we do to make the design meet specific timing constraint .i.e.
> >to make the design to make it work at 50 MHz?
> >Thanks
>

You can try one or more of the following -
1. Over-constrain your clock frequency in the Synthesis tool -
    Set the clock frequency to 55-60Mhz and then run it through the P&R
tool. This sometime results in better timing for the bitstream (I have
myself noticed this with Synplify synthesis + Xilinx ISE on a couple of
ocassions).

2. The P&R tool (Xilinx, Altera, or whichever you are using) will
always have options to compile for speed, area, etc. Assuming area (or
resources) is not a critical concern you can set the compile option for
"compile for speed". Some tools also offer multiple synthesis runs with
different seeds and then pick the best result for the bitstream.

3. As someone has already suggested earlier, make sure that you have
the latest speed files (technology) files and/or latest P&R software.
However, sometimes an older version can give better results, so you can
try runs with one or two tool versions.

4. If nothing works, then, go back to the source - make changes to the
RTL and re-code to optimize for timing.

Hope this helps.


Article: 110691
Subject: Re: 64 bit division compensate NCO
From: luca_grossi@hotmail.com
Date: 19 Oct 2006 16:04:16 -0700
Links: << >>  << T >>  << A >>
Really appreciate everyone's input ,  the specifies are a little
different to my first understand of the problem but never the less
useful information ( I'm just an undergrad , still learning the
ropes) . Ben with your response , I'm unable to make count1 2^N
because its actually the measured result that will vary depending on
the drift of the oscillator, if the formula was the other way around it
would make the problem much easier , using your solution.
Peter , I can't use the external clock reference because the nco
utilizes a rocketio mgt component and the specifics require the local
125MHz clock to drive it ,, only with hardware changes can I change
this " and for the time been isn't really the most viable option ,
hence implementing compensator circuit.
Ray , similar to Bens answer , the problem is , the denominator is
measured , thus varying

So delta2 = (nominal/ measured) * delta1

One solution is to do a lookup table and also utilize linear
interpolation between points. Count of NCO (which is measured count of
local oscillator) corresponds to a particular delta correction phase.

Please feel free to ask more question if anything is un clear.. Also
you future references are there custom cores available for divisions?


Ray Andraka wrote:
> luca_grossi@hotmail.com wrote:
>
> > Hi everyone,
> > I'm currently using a vitex-II pro FPGA, I've implemented an NCO
> > frequency generator, which is supplied with a 64bit init & delta phase
> > value. I'm currently using a local oscillator to clock the NCO ( must
> > use specific local oscillator) but this does contain a margin of offset
> > and drift thus influencing output frequency of NCO. A compensation
> > circuit which includes another stable clock is used to correct the
> > drift and offset by using a frequency counter on both clocks then
> > calculating appropriate delta phase to compensate. My problem is that
> > my equation to calculate adjusted delta which requires a 64 bit
> > division
> >
> > Delta2 = (count2/count1) * delta1
> >
> > Delta2 = new delta phase with correction
> > Count2 = frequency counter for Local Oscillator
> > Count1 = frequency counter for external Oscillator
> > Delta1 = Original calculated delta phase to product output frequency
> >
> > What would be the most appropriate way of doing this calculation,
> > especially with the division? also time constraints, everyone 1.6ms
> > roughly this will occur.
> > Maybe this could be done differently? Ideas I've been thinking about
> > are on the lines of, Maybe reduces the counting resolution ? use
> > internal PPC (CPU)
> >
> > Any advice would be appreciated :)
> > Cheers Luca
> >
>
> Division is the brute force way of addressing that, but is not really a
> good approach in most cases.  When dealing with two counts like that,
> you can count the number of clocks of the numerator clock per cycle (or
> multiple cycles) of the denominator clock to determine the ratio without
> performing an explicit division.  In fact, you don't even need a
> frequency counter, as that is what you are constructing here anyway.
> The more cycles of clk1 you accumulate clk2 over, the greater the
> precision of your result.  Basically you have a counter that counts up
> with each cycle of clk2 that is read and reset every N cycles of clk1.
> Multiply that by your delta constant to get the adjustment.
>
> There are some more advanced tricks to determine fractional clocks in
> order to reduce the accumulation time, but that is beyond the scope of a
> usenet post I think.
>
> For this type of application, it is more common to use a feedback loop
> and a measured parameter such as residual frequency after the mixer to
> nudge the DDS increment up or down.  Look at phase lock loops for this.


Article: 110692
Subject: FIR filter generic
From: "Zorjak" <Zorjak@gmail.com>
Date: 19 Oct 2006 16:23:20 -0700
Links: << >>  << T >>  << A >>
Hi.
I am trying to write generic VHDL code for FIR filter. generic
parametars  should be word_length, filter_order. Can anybody help me
how to input filter coeficients. I tought something like, read
coeficitients from file and write it in some LUT table. Could it be
done (or something similar)?

Thanks for  help


Article: 110693
Subject: Re: 64 bit division compensate NCO
From: "JustJohn" <john.l.smith@l-3com.com>
Date: 19 Oct 2006 16:34:19 -0700
Links: << >>  << T >>  << A >>


On Oct 19, 4:04 pm, luca_gro...@hotmail.com wrote:
>
> So delta2 = (nominal/ measured) * delta1
>
> One solution is to do a lookup table and also utilize linear
> interpolation between points. Count of NCO (which is measured count of
> local oscillator) corresponds to a particular delta correction phase.

Since you are in a V2Pro, you have multipliers galore, and can build
adders. For a 64-bit quotient in good time you might try Newton-Raphson
approximation. See e.g.:
http://www.azillionmonkeys.com/qed/adiv.html
for a start (the simplest early google hit for Newton-Raphson
division).
If you have 1.6ms, that's an incredibly long time, and a long divider
would work easily if you are strapped for multipliers or fabric.

> Please feel free to ask more question if anything is un clear.. Also
> you future references are there custom cores available for divisions?

The circuitry goes together easily, if you're a student, the exercise
will do you good!


Article: 110694
Subject: Re: 64 bit division compensate NCO
From: Ray Andraka <ray@andraka.com>
Date: Thu, 19 Oct 2006 21:11:16 -0400
Links: << >>  << T >>  << A >>
luca_grossi@hotmail.com wrote:

> Really appreciate everyone's input ,  the specifies are a little
> different to my first understand of the problem but never the less
> useful information ( I'm just an undergrad , still learning the
> ropes) . Ben with your response , I'm unable to make count1 2^N
> because its actually the measured result that will vary depending on
> the drift of the oscillator, if the formula was the other way around it
> would make the problem much easier , using your solution.
> Peter , I can't use the external clock reference because the nco
> utilizes a rocketio mgt component and the specifics require the local
> 125MHz clock to drive it ,, only with hardware changes can I change
> this " and for the time been isn't really the most viable option ,
> hence implementing compensator circuit.
> Ray , similar to Bens answer , the problem is , the denominator is
> measured , thus varying
> 
> So delta2 = (nominal/ measured) * delta1
> 
> One solution is to do a lookup table and also utilize linear
> interpolation between points. Count of NCO (which is measured count of
> local oscillator) corresponds to a particular delta correction phase.
> 
> Please feel free to ask more question if anything is un clear.. Also
> you future references are there custom cores available for divisions?
> 

Perhaps I am missing a few things here.  You have both clocks, no?  If 
you do, you don't need the frequency measurement from somewhere else, 
you use the clocks themselves and the counter arrangement I described.

A more conventional approach would be to not worry about the specific 
delta, but instead nudge it up or down with feedback derived from the 
frequency or phase error at the NCO output (mix the NCO with the signal 
and determine the phase/frequency offset from the resulting beat). 
Properly done, it will self adjust without ever having to compute the 
delta value.

The sample rate through your NCO is fixed by the clock (I think you said 
it is a 125 MHz clock). The signal's center frequency is determined by 
the transmitter, but you don't have access to exact transmitter 
frequency (besides, it will drift).  As a result, you need to vary the 
phase increment for the NCO in order to match the transmitter's carrier.

Article: 110695
Subject: Re: FIR filter generic
From: Ray Andraka <ray@andraka.com>
Date: Thu, 19 Oct 2006 21:20:42 -0400
Links: << >>  << T >>  << A >>
Zorjak wrote:

> Hi.
> I am trying to write generic VHDL code for FIR filter. generic
> parametars  should be word_length, filter_order. Can anybody help me
> how to input filter coeficients. I tought something like, read
> coeficitients from file and write it in some LUT table. Could it be
> done (or something similar)?
> 
> Thanks for  help
> 

If it is synthesizable code, it can't go and read files.  What you can 
do though is have a helper function that converts your coefficient file 
into a VHDL package containing the coefficient constants.  Write that 
package to a file, and then include that file with the rest of the 
design when you compile the design.  The helper function can be 
non-synthesizable VHDL, C, Matlab or any other programming language you 
feel like using.  Alternatively, you can cut and paste your coefficients 
into a VHDL package or directly into a constant array in your code.

You can also pass the coefficients into the entity through a generic by 
defining an integer_array type in a top level package, referring to that 
package in the library declarations, and then putting the int_array in 
the generics like this:

	component matrix
	generic(
		coefs: int_array:= (
		-62465, -8923, 24026, 39814, 41873, 33635, 18534,     			 
0,-18534,-33636,-41873,-39813,-24025, 8925, 62468,
		 48188, 27536, 10061));
	port(
		clk : in std_logic;

Leaving the integer array unconstrained allows you to put in an 
arbitrary number of coefficients (must be more than 1).

Article: 110696
Subject: EDK - XPS 8.1i segmentation
From: "=?iso-8859-1?q?Jaime_Andr=E9s_Aranguren_Cardona?=" <jaime.aranguren@gmail.com>
Date: 19 Oct 2006 21:58:06 -0700
Links: << >>  << T >>  << A >>
Hi,

I installed XPS - EDK 8.1i in my WinXP machine. When I try to call XPS
the DPS window appears, and dissapears within a few seconds and nothing
else happens. Reviewing the C:\EDK folder, a file bash.exe.stackdump
appears, which contents are:

Exception: STATUS_ACCESS_VIOLATION at eip=00000000
eax=00000000 ebx=0247ED28 ecx=0247EB64 edx=7C91EB94 esi=0247ED2C
edi=00000000
ebp=0247ED30 esp=0247ED08 program=C:\EDK\cygwin\bin\bash.exe, pid 1680,
thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
End of stack trace

How could I fix this?

Regards.


Article: 110697
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: Simon <news@gornall.net>
Date: Thu, 19 Oct 2006 21:59:25 -0700
Links: << >>  << T >>  << A >>
On 2006-10-09 08:55:58 -0700, Austin Lesea <austin@xilinx.com> said:

> Rajeev,
> 
> Xilinx takes seriously any suggestions.
> 
> We, of all people, with the introduction of the Virtex 5 LX330, know
> that we need to somehow make everything work better, and faster.
> 
> Note that due to the memory required, the LX330 can ONLY be complied on
> a 64 bit Linux machine.... there are just too many logic cells, and too
> much routing.  8 Gbytes is about what you need, and windoze can't handle
> it (at all).

Well then, it's about time you ported it to the Mac, isn't it ? A full 
64-bit OS, with quad top-of-the-range processors on the desktop machine 
and gobs of RAM using this new weirdo serial-network RAM interface...

Given that you've got a Linux version (which uses X), and an X server 
on the Mac (which also runs a pretty plain-vanilla Unix for its OS), 
the only real barrier ought to be the QA overhead... Perhaps not 
*quite* as simple as typing 'make', but almost certainly within the 
confines of an intern's summer job :)

Well ?

Simon :)


Article: 110698
Subject: Re: Fixing Down Parts of Logic in ISE (8.2)
From: "jtw" <wrightjt @hotmail.invalid>
Date: Fri, 20 Oct 2006 05:29:55 GMT
Links: << >>  << T >>  << A >>

"marc_ely" <marc_ely@yahoo.co.uk> wrote in message 
news:1161261816.609566.34830@b28g2000cwb.googlegroups.com...
> Hi
> I am working on some Spartan3 projects using ISE8.2 on WindowsXP.
>
> One of the designs (XC3S4000) instantiates a core from a 3rd party as
> an EDIF netlist.  I then add all sorts of other home spun blocks around
> it.
>
> I am quite happy with the core's function, and am now just adding
> peripheral blocks and debugging them etc.
> This is proving frustrating due to the Xilinx tool ripping up and
> re-routing the whole design each time I compile.  It takes 1.5hrs to
> recompile, which may not sound a lot, but to add a wire is a bit
> ridiculous IMHO.
>
> I would really like to fix down some of the blocks to stop the Xilinx
> tool re-placing etc.
>
> At first glance there seems to be many options in the Xilinx tools to
> do this, but I can't get any of them to work properly.
> So far I have tried the following:
> - Partitions.  They don't work >at all< do they?  I can't even add one
> and get it to pass through MAP.
> - Incremental Design Flow, I don't seem to be able to get ISE to use
> my area constraints, and how do you find out how big to make blocks in
> floorplanner?
> - Planahead.  Beta, poor doc's, didn't know where to start really.
> Even my FAE doesn't have a scooby-doo about this one.
> - FPGA Editor  Does anyone use the probe points to debug?  I don't
> seem to have anywhere near a full netlist to choose from, even if I
> don't flatten
>
> So questions to experienced ISE users;
> 1) How do you tie blocks down?  (or do you not bother?)
Typically, the main reason for a long par time is challenging timing 
constraints.  The tool is 'throwing darts' initially, and then working 
towards a locally optimal solution.  If you can spend the time to figure out 
where the trouble spots are, you can:
    1)  Determine if the timing requirement is real on these critical paths. 
(Often, there is a multi-cycle path.  When you take unnecessary pressure off 
the tool, it tends to do a better job achieving timing closure.)
    2)  Lock down the endpoints in the critical paths.  Sometimes this is 
obvious, sometimes it's not.
    3)  Force (in your code, for instance) register/logic replication to 
reduce fanout.
    4)  Prohibit register/logic replication.  (The answer is:  it depends.)
    5)  Direct par to leverage a previous route.  (This can improve things, 
and it can make things much worse.  It depends.)
    6)  Use incremental and/or hierarchical design techniques.  The tools 
are very good at solving challenging, but small, problems.  They are pretty 
good at solving easy, but large, problems.  Oftentimes blocks A, B, & C will 
meet timing closure individually quite quickly, but flounder when all three 
are present.  I haven't experimented with the hierarchical design flow in a 
couple of years, but I did notice that the final par can run much more 
quickly (achieving timing closure) this way, rather than making the tool 
solve all the issues at once.  Starting with a 'known-good' baseline can 
really speed things up.  Further, it is less susceptible to the impact of 
small design changes.  (The impact is felt when running par on the 
appropriate block more than it is for the final par.)
     This technique tends to produce larger designs, but the turnaround time 
may be quicker.
>
> 2) Are the 8.2 service packs an improvment?  I briefly tried pack2 a
> couple of weeks back, but it destroyed one of my projects so I couldn't
> load it into a non SP version on another PC.  Obviously backwards
> compatibility is not high on Xilinx's lists.
I haven't upgraded from 8.1sp3 to 8.2 yet, so I can't say.  There are 
reasons I want to (the corrupted project file can be such a pain...), but 
for compatibility reasons, I stay at 8.1.
>
> 3) Does anyone use Floorplanner?  Are there any GOOD tutorials out
> there?
I have only used it a little bit; mainly, to get insight, or as a starting 
point.  I've been handplacing critical registers for better than 10 years, 
and old habits die hard.  (Especially when they work.  It seems most of by 
timing challenges have been datapath, and the tool seems to get the most 
help by hand-placing things register by register.  I have seen designs go 
from almost never meeting timing, to easily meeting timing, by fixing the 
locations of registers in the critical path.  My experience has been:  let 
the tool work hard on what it is good at, and give it explicit directions on 
what it is not good at.)
>
> Regards
> Marc
>

Food for thought,

Jason 



Article: 110699
Subject: Re: Meeting Timing Constraint
From: "jtw" <wrightjt @hotmail.invalid>
Date: Fri, 20 Oct 2006 05:42:49 GMT
Links: << >>  << T >>  << A >>
Have you properly specified the input/output timing constraints?  Most of 
the effort is spent defining internal timing constraints, but the I/O can be 
messed up--even if it meet the specifications you've given it, if they 
aren't correct!  (The rate may be correct, but the offset may not.)

What is the clock phase uncertainty for the incoming signals?  What is the 
setup/hold time on the device the FPGA sends data to?

Xilinx FPGAs (4k, V2, probably many others) let you adjust the delay 
(coarsely) on your inputs; you get to select drive strength and fast/slow on 
the outputs.  Are the settings appropriate for your device's environment?

Also, there are the physical board issues:  how far from nominal are the 
voltages?  How noise are the voltage and ground planes?  Even at 50 MHz, you 
could create quite a bit of simultaneous switching noise if the chip isn't 
bypassed correctly, or ....

Also, "doesn't work" can mean many things; you may want to insert some test 
circuity (Chipscope, or something similar, perhaps) to characterize the 
failure.  If you identify "where" the failure occurs, "why" might not be far 
behind.  And then it is often (but not always) just a quick jog to "fixed."

Jason

"Nico Coesel" <nico@puntnl.niks> wrote in message 
news:4537c0f0.1286740364@news.kpnplanet.nl...
> "Roger" <hpsham@gmail.com> wrote:
>
>>A design is built to work at 50MHz, but the deisgn when tested works
>>only at 48MHz. What
>>should we do to make the design meet specific timing constraint .i.e.
>>to make the design to make it work at 50 MHz?
>>Thanks
>
> Are you sure all signals are covered by timing constraints? Don't
> forget connections which connect IO cells to internal flipflops. These
> should be constrained as well.
>
> -- 
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U op www.adresboekje.nl 





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