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 109750

Article: 109750
Subject: Re: Virtex-II Pro Platform FPGA : Assembling the modules
From: "THANG NGUYEN" <airthang@yahoo.com>
Date: Wed, 4 Oct 2006 23:20:42 -0700
Links: << >>  << T >>  << A >>
Hi, I use the ISE 6.3i. I also try it with the ISE 8.2i in my University, but it doesn't work with the macro, I think so. This is the error message when I use 8.2i:

WARNING:Pds:119 - Attempted to load old format .nmc file "C:\THANG\CPR1\implementation\top_level_initial/bm_4b_v2p.nmc", but this format is no longer supported. EXCEPTION:Pds:Pds_PahFileConv.c:124:1.17 - Database conversion failed. FATAL_ERROR:NgdBuild:Portability/export/Port_Main.h:127:1.5.56.1 - This application has discovered an exceptional condition from which it cannot recover. Process will terminate.

This project is really important to me. I start working on my master thesis, and this is my first step. Thank you for your answers.

Article: 109751
Subject: Re: Virtex-II Pro Platform FPGA : Assembling the modules
From: "Jens Hagemeyer" <jenze@et.upb.de>
Date: 5 Oct 2006 00:27:23 -0700
Links: << >>  << T >>  << A >>
Hi Thang,

the NMC/NCD format has changed between ISE6/7. There is a way to
convert the macros, but i would suggest to use the ones from the xilinx
website for PREAT8 flow. The Early Access Partial Reconfiguration Suite
contains basic busmacros, examples, and much more. It may also be
possible, if you, for whatever reason, not be able to use ISE8.1, to
use the old patch for partial reconfiguration, based on ISE6.3. A new
partial reconfiguration patch, based on ISE 8.2, should become
available soon.

Regards,

Jens

THANG NGUYEN schrieb:

> Hi, I use the ISE 6.3i. I also try it with the ISE 8.2i in my University, but it doesn't work with the macro, I think so. This is the error message when I use 8.2i:
>
> WARNING:Pds:119 - Attempted to load old format .nmc file "C:\THANG\CPR1\implementation\top_level_initial/bm_4b_v2p.nmc", but this format is no longer supported. EXCEPTION:Pds:Pds_PahFileConv.c:124:1.17 - Database conversion failed. FATAL_ERROR:NgdBuild:Portability/export/Port_Main.h:127:1.5.56.1 - This application has discovered an exceptional condition from which it cannot recover. Process will terminate.
>
> This project is really important to me. I start working on my master thesis, and this is my first step. Thank you for your answers.


Article: 109752
Subject: An implementation of a clean reset signal
From: "Eli Bendersky" <eliben@gmail.com>
Date: 5 Oct 2006 00:43:51 -0700
Links: << >>  << T >>  << A >>
Hello all,

Following some discussion in these groups and reading a couple of
articles (especially the first one turning up when you google for
"asynchronous synchronous reset design techniques", it seems that the
best and the safest way to use resets in FPGA designs is to use a
special synchronizer circuit that assures that the reset of the FFs is
asserted asynchronously, but is deasserted synchronously.

The circuit is something like (kindly borrowed from the aforementioned
article):

~~~~~~~~

entity reset_synchronizer is
port
(
  clk, async_reset_n: in std_logic;
  sync_reset_n: out std_logic;
);
end reset_synchronizer;

architecture rtl of reset_synchronizer is
  signal rff1: std_logic;
begin
process (clk, async_reset_n)
begin
  if async_reset_n = '0' then
    rff1 <= '0';
    sync_reset_n <= '0';
  elsif rising_edge(clk) then
    rff1 <= '1';
    sync_reset_n <= rff1;
  end if
end process;
end rtl;

~~~~~~~~

When the asynchronous reset line enters this module, the synchronous
output can then be used as the _asynchronous_ reset of all FFs in the
design, as follows:

process (clk, sync_reset_n)
begin
  if sync_reset_n = '0' then
    ff <= '0';
  elsif rising_edge(clk) then
   ff ....
  end if;
end process;

This seems to bring the best of all worlds - all the FFs in the design
enter reset asynchronously, without being dependent on the clock, and
exit reset synchronously. The synthesis tools can analyze the path
delays for sync_reset_n and report the times and skews.

Moreover, from a talk I had with Altera support engineers - they claim
this is the recommended way to code resets in designs, and that
Altera's tools will know to route sync_reset_n via fast global
interconnects to minimize time delay and skews. And in any case,
there's a report to see for each compilation.

What does this technique lack to be the perfect solution for resets in
FPGA designs ? It seems that it evades all the common disadvantages of
conventional sync and async resets.

Thanks in advance
Eli


Article: 109753
Subject: Re: logic analyzer signal tap 2 - writing data
From: "david" <1024.david@gmail.com>
Date: 5 Oct 2006 01:54:02 -0700
Links: << >>  << T >>  << A >>
hello
thank you for your replay

we allready tried this option before, but we have a problam, because we
need to modify the data in the memory while the system is runing ( the
in system memory size is to small for ower application), every 512
clock cycles.
can we update the memory automaticly with new data from predefine files
(hex files) while the system is runing? (it's not practiclly to rewrite
manually every 512 clocks cycles, we need the system to run at least
for 32768 clock cycles continusly, we can spend clock cycles as need to
rewrite the content of the memory)

thanks
david


Subroto Datta =D7=9B=D7=AA=D7=91:
> It is definitely possible to update the memory and constants in a program=
med
> device from Quartus using the In System Memory Content Editor. Details can
> be found at:
>
> http://www.altera.com/literature/hb/qts/qts_qii53012.pdf
>
> You can use this in conjunction wiith SignalTap II Embedded logic analyzer
> to debug your work.
>
> Hope this helps,
> Subroto Datta
> Altera Corp.
>
> "david" <1024.david@gmail.com> wrote in message
> news:1159976602.300018.42380@e3g2000cwe.googlegroups.com...
> > hello
> > i am a student, working on development kit nios 2 cyclone edition.
> > i want to use the logic analyzer to import data to the fpga from the
> > logic analyzer, can i do it?
> >


Article: 109754
Subject: Generate 16MHz from 75MHz using DCM
From: moogyd@yahoo.co.uk
Date: 5 Oct 2006 02:25:00 -0700
Links: << >>  << T >>  << A >>
Hi,

We have an eval board with a spartan FPGA and a 75MHz XTAL
Within ourt design, we require an accurate 16MHz clock.
It is not possible to generate this frequency using a single DCM, is it
possible to chain 2 DCM's together to generate the 16MHz clock ?

(the obvious solution is to change the XTAL, but I'd like to know
whether it is possible without changing the XTAL :-) )

Thanks for any feedback,

Steven


Article: 109755
Subject: Re: Help required regarding PCI Master core
From: "Adnan" <madnan.rashid@gmail.com>
Date: 5 Oct 2006 02:34:40 -0700
Links: << >>  << T >>  << A >>
Hello again,
There is one other question, although I am supposed to find this by
myself  but just to get an idea I want to ask: what is the maximum
throughput I can get while running PCI opencores core at 33 Mhz in
windows environment and in embedded environment where there is a
dedicated PCI bus between two devices for example in a scenario where
FPGA is communicating with a RISC processor via PCI bus.

with best regards,
Muhammad Adnan


Article: 109756
Subject: Re: Just a matter of time
From: Kolja Sulimma <news@sulimma.de>
Date: Thu, 05 Oct 2006 12:16:47 +0200
Links: << >>  << T >>  << A >>
rickman schrieb:
> Over the years I have gotten a lot of junk email from Xilinx to email
> addresses that I have given out only to support and never to any
> marketing channel.  I have always been disappointed that Xilinx has
> done this.  But now they have sunk to a new low, they are giving or
> selling my email address to third party junk emailers.

I see that too.
I think it is bad business practice. It does not make me feel that I can
share sensitive information with them in a webcase or similar.

And who knows whom Foundation ISE sends your source codes to.
If a company sees cloak and dagger methods as part of their business
model you can not trust them anymore.

Kolja Sulimma

Article: 109757
Subject: Re: Just a matter of time
From: "Antti" <Antti.Lukats@xilant.com>
Date: 5 Oct 2006 03:24:22 -0700
Links: << >>  << T >>  << A >>
Kolja Sulimma schrieb:

> rickman schrieb:
> > Over the years I have gotten a lot of junk email from Xilinx to email
> > addresses that I have given out only to support and never to any
> > marketing channel.  I have always been disappointed that Xilinx has
> > done this.  But now they have sunk to a new low, they are giving or
> > selling my email address to third party junk emailers.
>
> I see that too.
> I think it is bad business practice. It does not make me feel that I can
> share sensitive information with them in a webcase or similar.
>
> And who knows whom Foundation ISE sends your source codes to.
> If a company sees cloak and dagger methods as part of their business
> model you can not trust them anymore.
>
> Kolja Sulimma

and did you notice that in ISE 8.2 there is now also a WEB-TALKBACK
feature that ask you to submit your design statistics to Xilinx !?
(similar to Altera software)

however if in Altera enabling the talkback enables the free use of jtag
logic analyzer features then the talkback in Xilinx is simple
additional burden for you and you get nothing in return !

Antti


Article: 109758
Subject: Re: An implementation of a clean reset signal
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 05 Oct 2006 10:34:22 GMT
Links: << >>  << T >>  << A >>

"Eli Bendersky" <eliben@gmail.com> wrote in message 
news:1160034231.247522.286040@m73g2000cwd.googlegroups.com...
> Hello all,
>
>
> This seems to bring the best of all worlds - all the FFs in the design
> enter reset asynchronously, without being dependent on the clock, and
> exit reset synchronously. The synthesis tools can analyze the path
> delays for sync_reset_n and report the times and skews.
>
> Moreover, from a talk I had with Altera support engineers - they claim
> this is the recommended way to code resets in designs, and that
> Altera's tools will know to route sync_reset_n via fast global
> interconnects to minimize time delay and skews. And in any case,
> there's a report to see for each compilation.
>
> What does this technique lack to be the perfect solution for resets in
> FPGA designs ? It seems that it evades all the common disadvantages of
> conventional sync and async resets.

It lacks nothing.  In fact any design that does NOT generate a synchronously 
timed trailing edge reset is 'lacking' and will eventually fail because at 
some point that trailing edge of reset will come along at a time relative to 
the clock that violates setup/hold timing requirements and cause a flip flop 
or two to go to the wrong state.  This is all assuming that the clock is 
free running (or at least running at the trailing edge of reset).

The next question to ponder is, given that the reset must be synchronized 
anyway, why use an asynchronous reset anywhere in your design (with the 
exception of course of the above mentioned synchronizer)?  People will 
pontificate on the subject but have yet to produce any coherent reason to 
prefer async or sync.  Or they will claim some logic resource advantage that 
when you test the claim is found to be baseless (in almost every case, the 
logic and performance is darn near identical).

KJ 



Article: 109759
Subject: EDIF
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Thu, 05 Oct 2006 05:42:19 -0500
Links: << >>  << T >>  << A >>

Hi

I am using synplify to synth a design with some xilinx core gen devices. I
get warnings on some of the core gen edif files stating that there is an
interface mismatch between the verilog and the edif. I can only assume
that it is something that core gen is not doing correctly. Has anyone else
seen this problem? Here is the warning I get.

@W: :  | Interface mismatch for Entity/Module dplbuf_16x512 



From removethisthenleavejea@replacewithcompanyname.co.uk Thu Oct 05 04:15:48 2006
Path: newssvr21.news.prodigy.com!newsdbm04.news.prodigy.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newsfeed.telusplanet.net!newsfeed.telus.net!hwmnpeer01.phx!news.highwinds-media.com!newsfeed2.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!newspeer1.nwr.nac.net!solnet.ch!solnet.ch!news.clara.net!wagner.news.clara.net!monkeydust.news.clara.net!demeter.uk.clara.net
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Newsgroups: comp.arch.fpga
References: <ahn4i25ir1pnpqbol22na85ggkrjeoam3m@4ax.com>   <1159882885.7617.0@proxy01.news.clara.net>   <J8uUg.18192$Oh3.12154@trnddc04> <1159907018.668373.267310@i3g2000cwc.googlegroups.com> <eg24sg$h8c$02$1@news.t-online.com>
Subject: Re: JTAG cable @ 2.5 V - where?
Date: Thu, 5 Oct 2006 12:15:48 +0100
Lines: 124
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-RFC2646: Format=Flowed; Original
X-Complaints-To: abuse@clara.net (please include full headers)
X-Trace: d258751c3e248630963c302dc23705000131250813041068233e30e44524e960
NNTP-Posting-Date: Thu, 05 Oct 2006 12:15:44 +0100
Message-Id: <1160046944.94302.0@demeter.uk.clara.net>
Xref: prodigy.net comp.arch.fpga:120688

Ulrich

It isn't one thing but a series of things from PCB layout through to choice 
of driver and decoupling. Actually as a cable our Prog1 cable does even 
better but it has the advantage of a Coolrunner-II CPLD and a voltage 
regulator built in. It is some way between what Xilinx do as Cable III and 
their Cable IV. At some stage we may effective take the best bits of Prog1 
and Prog2 and a couple of other things we know will think will make life 
better and make Prog3 but that isn't until we exhaust our current Prog2 
cable stock. We have a few new ideas we are trying out on our new 
development board Tarfessock1 which can double as a programming cable and 
depending if those work they may get fed back into the more general cable 
solutions.

Some of the problems people see in programming are actually the target board 
in the main and not necessarily the cable or a combination of them.

John Adair
Enterpoint Ltd. - Home of Tarfessock1. The Cardbus Spartan-3E FPGA 
Development Board.
http://www.enterpoint.co.uk


"Ulrich Bangert" <df6jb@ulrich-bangert.de> wrote in message 
news:eg24sg$h8c$02$1@news.t-online.com...
> John,
>
>>Prog2 actually performs very well against the competition and works in
> circumstances where many others fail.
>
> is this a business secret or can you elaborate a bit on that? Using the
> right buffers the high level to low level translation should not be a
> problem anymore. Is it a question of TDO conditioning?
>
> Best regards
> Ulrich Bangert
>
> "John Adair" <g1@enterpoint.co.uk> schrieb im Newsbeitrag
> news:1159907018.668373.267310@i3g2000cwc.googlegroups.com...
> Well I did say look-alike I didn't say the same. It looks the same to
> the Xilinx software so it can use it without issue. Prog2 actually
> performs very well against the competition and works in circumstances
> where many others fail. We have tried several of these in compatibility
> testing with our own boards. Our Prog2 isn't as good as Cable IV but
> then it is about 1/5 th of the price when buying and we do give them
> away with our own development boards.
>
> John Adair
> Enterpoint Ltd.
>
> John_H wrote:
>> I don't see where the "Parallel Cable III look-alike" PROG2 is 2.5V
>> compliant since the Parallel Cable III doesn't work so well from 2.5V.
>>
>> I think I've gotten the III to work with a 3.3V supply for 2.5V JTAG but
>> the IV or USB versions of the cable are certainly more robust.
>>
>> Perhaps the Xilinx online store could ship to Switzerland with a simple
>> credit card purchase.
>>
>> The Parallel Cable IV doesn't include schematics but it does show what
>> the input and output stages look like, easily replacing the simple
>> buffers in the Parallel Cable III which does have full schematics.
>>
>> - John Handwork
>>
>>
>> John Adair wrote:
>> > Markus
>> >
>> > Our Prog2 cable(ask for narrow head version) is available in the
> standard 14
>> > way 2mm connector. Cost GBP10. It is a Cable III look-alike as most
> third
>> > party cables are. Schematics for Cable IV are generally not in public
> domain
>> > and generally not replicated by anyone as far as I know.
>> >
>> > The only advantage of the Cable IV is the download speed.
>> >
>> > Our shop website has those listed under programming solutions for an
> easy
>> > order solution.
>> >
>> > John Adair
>> > Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development
>> > Board.
>> > http://www.enterpoint.co.uk
>> >
>> > "Markus Zingg" <m.zingg@nct.ch> wrote in message
>> > news:ahn4i25ir1pnpqbol22na85ggkrjeoam3m@4ax.com...
>> >> Hi group
>> >>
>> >> I'm a newbee, so please bear with me if this does not make sense.
>> >>
>> >> I got a AVNet (MEMEC) Virtex 4 based developper kit based on the
>> >> Virtex-4 FX12 Mini Module whoes baseboard JTAG port is documented as
>> >> "a 2.5V compatible JTAG chain header". The pinout is identical to what
>> >> Xilinx seems to use (14 pins etc.). The docs seem to asume that one
>> >> must use the Xilinx parallel cable IV which from what I understand
>> >> seems to automatically sense the voltage needs of the target and is
>> >> having other nice to have features. However, due to several reasons
>> >> which are beond the scope of this post, I can't simply pick up the
>> >> phone and order one from a supplier last not least also because I
>> >> don't know any that would carry this item here in Switzerland.
>> >>
>> >> The net seems to be full of homebrew JTAG cable websites giving
>> >> instructions to build you own. The question is can I use one of those?
>> >> I'm a bit afraid that this will not work cause from what I understand
>> >> they seem to be designed for 5V or 5V tolerant devices. What other
>> >> options do I have? Any links to a schema of the Xilinx paralell cable
>> >> IV or such to build my own JTAG cable running at 2.5V?
>> >>
>> >> I would also not mind to shell out the needed $$$ to get that original
>> >> cable if I could easily purchase it somewhere online using paypal or a
>> >> credit card and get it deliverd quickly. Any ideas?
>> >>
>> >> TIA
>> >>
>> >> Markus
>
> 



Article: 109760
Subject: Re: FPGA power-up and code relocation (basics)
From: "Andrea05" <cispa@email.it>
Date: 5 Oct 2006 04:46:25 -0700
Links: << >>  << T >>  << A >>
yes urban,
i've read that document and I think my board will adopt the solution
propsed in the application note.
In this moment I don't have such kind of PROM so I can't try it.
If you have some good results with it, please contact me and let me
know your solution!

Thanks for the hint,

Andrea.


Article: 109761
Subject: How to accelerate bitstream file generation?
From: "=?iso-8859-1?q?Robert_Llu=EDs?=" <robertdb@gmail.com>
Date: 5 Oct 2006 04:46:40 -0700
Links: << >>  << T >>  << A >>
Hi,

I am using Xilinx ISE software for an FPGA project.
Every time I do a small change in the HDL code I have to regenerate the
bitstream file and the ISE software  takes a long time to do the job.
Is there a way to accelerate it?
Is there a way to avoid synthesizing parts of the design that are
untouched since the last synthesis? What about the rest of tue
processes?
Is it faster to use a batch file instead of using the software GUI?

Thanks,
Robert


Article: 109762
Subject: Re: Xilinx Virtex-2 Pro MUXCY does not drive local FF
From: "Stefan Philipp" <sphilipp@ix.urz.uni-heidelberg.de>
Date: Thu, 5 Oct 2006 14:05:04 +0200
Links: << >>  << T >>  << A >>
Thanks but does not work....
Also, using the MUXCY_L primitive does not work.
I Also did not succeed with RLOCs - MAP exits the slice via local routing
and reenters after quite a long path.
But i CAN create a net using the Y/DY path with the FPGA-Editor without DRC
warnings, so in principle there is no technical problem.

still trying ...
"Brannon" <brannonking@yahoo.com> schrieb im Newsbeitrag 
news:1159540838.116591.300510@m7g2000cwm.googlegroups.com...
> Try using the LO output of the MUXCY_D primitive instead of the O
> output.
> 



Article: 109763
Subject: Re: An implementation of a clean reset signal
From: "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch>
Date: Thu, 5 Oct 2006 14:36:53 +0200
Links: << >>  << T >>  << A >>
Eli,

I use the technique you describe for system reset, i have a 
"reset_controller" block I paste into all my designs...  One case where I 
have clear results showing that this implementation is more efficient than a 
complete synchronous reset is in some older CPLDs (XC9500).

I assume that in these devices the implementation of an asynch reset (albeit 
one that has been synchronised) comes almost for free, whereas a synchronous 
one always appears to take more to be fitted.

> Or they will claim some logic resource advantage that when you test the 
> claim is found to be baseless (in almost every case, the logic and 
> performance is darn near identical).

I am one of "them"... Haha

--fully asynchronous reset 16-bit down-counter mapped in an xc9536

Macrocells Used  Pterms Used  Registers Used  Pins Used        Function 
Block Inputs Used
16/36  (45%)       15/180  (9%) 16/36  (45%)    18/34  (53%)  23/72  (32%)

--synchronous reset same circuit as before

Macrocells Used   Pterms Used     Registers Used  Pins Used        Function 
Block Inputs Used
16/36  (45%)        31/180  (18%)  16/36  (45%)    18/34  (53%)  26/72 
(37%)

I agree macrocells & registers is the same, but obviously the routing and 
functions required to implement the synchronous reset is not easily achieved 
in xc9500s.

Ben 



Article: 109764
Subject: Re: ISE timing errors
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 5 Oct 2006 05:56:17 -0700
Links: << >>  << T >>  << A >>

dhruvakshad@gmail.com wrote:
> Hello KJ,
>  I have added exactly one flip flop in  between the asycnhronous inputs
> and the state machines since the asynchronous input is coming at a much
> lower rate. is it ok?
>
> Thanks,
> D

I said two flip flops.

"What
you need to do there is first synchronize the signal with two flip
flops and
feed the output of the second flip flop to the rest of your design.
The
output of the first flip flop goes nowhere except for the input of the
second flip flop"

The 'lower rate' is irrelevant, if it's asynchronous you have no idea
when it will come in relative to the clock that is sampling it.

KJ


Article: 109765
Subject: Re: ISE timing errors
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 5 Oct 2006 05:57:43 -0700
Links: << >>  << T >>  << A >>

dhruvakshad@gmail.com wrote:
> how could I find the maximum frequency of the adder generated using
> core generator?
> thanks,
> D
>
When you run through the place and route, ISE will produce a timing
report telling you all of the numbers (Tsu, Tco, Tpd and T) that I
mentioned in my first post.

KJ


Article: 109766
Subject: Re: Generate 16MHz from 75MHz using DCM
From: "Marc Randolph" <mrand@my-deja.com>
Date: 5 Oct 2006 06:25:47 -0700
Links: << >>  << T >>  << A >>

moogyd@yahoo.co.uk wrote:
> Hi,
>
> We have an eval board with a spartan FPGA and a 75MHz XTAL
> Within ourt design, we require an accurate 16MHz clock.
> It is not possible to generate this frequency using a single DCM, is it
> possible to chain 2 DCM's together to generate the 16MHz clock ?
>
> (the obvious solution is to change the XTAL, but I'd like to know
> whether it is possible without changing the XTAL :-) )

Howdy Steven,

Unfortunately you didn't provide enough information to really help you
here.  Which generation Spartan are you using?  How accurate does the
clock need to be?  16.00000MHz?  Any duty cycle requirements?  Jitter
requirements?

There are five different generations of the Spartan.  As you probably
know, DLL's likely wouldn't help you much.  S3 and newer with DCM's
have CLKFX which might get you close, depending on your exact frequency
and jitter requirements.  Going the non-DCM route, I think a
combinational output of multiple flip-flop dividers would allow you to
generate this clock pretty accurately, but might cause jitter/duty
cycle distortions.

Good luck,

   Marc


Article: 109767
Subject: Re: Xilinx Virtex-2 Pro MUXCY does not drive local FF
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 05 Oct 2006 13:35:23 GMT
Links: << >>  << T >>  << A >>
Stefan Philipp wrote:
> Thanks but does not work....
> Also, using the MUXCY_L primitive does not work.
> I Also did not succeed with RLOCs - MAP exits the slice via local routing
> and reenters after quite a long path.
> But i CAN create a net using the Y/DY path with the FPGA-Editor without DRC
> warnings, so in principle there is no technical problem.
> 
> still trying ...
> "Brannon" <brannonking@yahoo.com> schrieb im Newsbeitrag 
> news:1159540838.116591.300510@m7g2000cwm.googlegroups.com...
>> Try using the LO output of the MUXCY_D primitive instead of the O
>> output.

I did have an issue the other day where a syn_hier="hard" in SynplifyPro 
caused some similar problems for a Spartan3E design.  If your register 
is in the module where your MUXCY is used, the nuance may let the 
register pack.  If you do use directives to keep the synthesizer from 
optimizing across module boundaries, try manipulating those.  I think a 
"firm" was the only difference I needed.

Article: 109768
Subject: Nios II interrupt
From: Frank van Eijkelenburg <someone@work.com.invalid>
Date: Thu, 05 Oct 2006 15:48:37 +0200
Links: << >>  << T >>  << A >>
Hi,

I am new to the Nios II core. I have built a simple system with a timer which is 
set as periodically timer. I have registered an interrupt service routine:

     alt_irq_disable(TIMER_0_IRQ);
     res = alt_irq_register(TIMER_0_IRQ, NULL, timer_isr);

With this code I still come in my installed ISR. So registering is also enable 
the interrupt. Is that correct, is there a way to register an ISR and leave the 
interrupt disabled (until you decide to enable it manually)?

Another question: where can I find a list with available routines for the 
peripheral. For instance, I saw in an example the call 
IOWR_ALTERA_AVALON_PIO_DATA to write to my io-pins. But where can I find a 
complete list. It not in the software developer's handbook.

best regards,
Frank

Article: 109769
Subject: Re: An implementation of a clean reset signal
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 5 Oct 2006 06:51:36 -0700
Links: << >>  << T >>  << A >>
Benjamin Todd wrote:
> Eli,
>
>
> I assume that in these devices the implementation of an asynch reset (albeit
> one that has been synchronised) comes almost for free, whereas a synchronous
> one always appears to take more to be fitted.
Careful when you say 'always', because you'll be wrong.  A single test
case does not imply 'always'.  Even I said "almost every case".

>
> > Or they will claim some logic resource advantage that when you test the
> > claim is found to be baseless (in almost every case, the logic and
> > performance is darn near identical).
>
> I am one of "them"... Haha
Only under some conditions, not all.  Granted, the condition might be
continued use of a particular part, or family of parts or even the
software that you use.  Try targetting an FPGA or use different front
end synthesis software and see what the differences are.

>
> --fully asynchronous reset 16-bit down-counter mapped in an xc9536
>
> Macrocells Used  Pterms Used  Registers Used  Pins Used        Function
> Block Inputs Used
> 16/36  (45%)       15/180  (9%) 16/36  (45%)    18/34  (53%)  23/72  (32%)
>
> --synchronous reset same circuit as before
>
> Macrocells Used   Pterms Used     Registers Used  Pins Used        Function
> Block Inputs Used
> 16/36  (45%)        31/180  (18%)  16/36  (45%)    18/34  (53%)  26/72
> (37%)
>
> I agree macrocells & registers is the same, but obviously the routing and
> functions required to implement the synchronous reset is not easily achieved
> in xc9500s.
You didn't post clock cycle (i.e. performance numbers) which I'm
guessing are identical or darn near.

The reason for my "almost every case" disclaimer did have to do mainly
with CPLDs since the and/or array physical implementation of those
devices is completely different than the sea of LUTs inside an FPGA.
Since this is the 'fpga' newsgroup I didn't really mention that but I
should have.  In an FPGA there is typically (but not always) a way for
the fitter to use an otherwise unused address input to the LUT in order
to implement the reset functionality.  It's a bit harder (but not at
all impossible) to come across the case where the synchronous reset
will require an extra LUT and delay....but it also does not come up
very often and I've yet to see it come up in the critical timing path
(but it might).

The thing is though depending on the device the async reset path might
lead to timing issues as well that the sync reset wouldn't, so the
'best' advice is probably that your mileage will vary each has
advantages and disadvantages in different scenarios...and that
proponents of each method have a point (unlike those "two process state
machine" guys ;)

KJ


Article: 109770
Subject: Re: Virtex-II Pro Platform FPGA : Assembling the modules
From: "THANG NGUYEN" <airthang@yahoo.com>
Date: Thu, 5 Oct 2006 07:08:57 -0700
Links: << >>  << T >>  << A >>
Hi,

"but i would suggest to use the ones from the xilinx website for PREAT8 flow. The Early Access Partial Reconfiguration Suite contains basic busmacros, examples, and much more. It may also be possible, if you, for whatever reason, not be able to use ISE8.1, to use the old patch for partial reconfiguration, based on ISE6.3. "

Could you tell me where I can find it? I try to search but I did not find the patch for ISE 6.3i. Thank you so much. Thang Nguyen

Article: 109771
Subject: Re: Generate 16MHz from 75MHz using DCM
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 5 Oct 2006 07:35:19 -0700
Links: << >>  << T >>  << A >>
Steven, if yor Spartan device has the CLKFX option, then you just use
one DCM to multiply by 16 and simultaneously divide by 15, which gives
you an 80 MHz output. You can then use a simple 3-bit synchronous
counter to divide by 5, and that gives you the 16 MHz accurately.
Peter Alfke, Xilinx Applications (from home)
================
moogyd@yahoo.co.uk wrote:
> Hi,
>
> We have an eval board with a spartan FPGA and a 75MHz XTAL
> Within ourt design, we require an accurate 16MHz clock.
> It is not possible to generate this frequency using a single DCM, is it
> possible to chain 2 DCM's together to generate the 16MHz clock ?
>
> (the obvious solution is to change the XTAL, but I'd like to know
> whether it is possible without changing the XTAL :-) )
> 
> Thanks for any feedback,
> 
> Steven


Article: 109772
Subject: This is great news
From: Eli Hughes <emh203@psu.edu>
Date: Thu, 05 Oct 2006 10:48:32 -0400
Links: << >>  << T >>  << A >>
On the Xilinx Home Page

XILINX OPENS DEVELOPMENT CENTRE IN INDIA
TO STRENGTHEN GLOBAL R&D ECOSYSTEM


Article: 109773
Subject: Re: How to accelerate bitstream file generation?
From: "Brannon" <brannonking@yahoo.com>
Date: 5 Oct 2006 08:00:19 -0700
Links: << >>  << T >>  << A >>
> I am using Xilinx ISE software for an FPGA project.
> Every time I do a small change in the HDL code I have to regenerate the
> bitstream file and the ISE software  takes a long time to do the job.
> Is there a way to accelerate it?

Yeah. It's called L1/2/3 cache. It costs several hundred dollars for a
fair amount of it. If you can cut your compile times from 20min to
15min by purchasing a $1000 CPU, how long would it take the company to
pay for that with the made-up time?

> Is there a way to avoid synthesizing parts of the design that are
> untouched since the last synthesis? What about the rest of tue
> processes?

You can resynth only part of the design currently. Using the GUI just
select the subcomponent and compile that portion. The Map/Par tools
support a similar functionality using what's called guide files. Last I
heard Xilinx was working on a major upgrade of this feature. Search the
news group for more info on it.

> Is it faster to use a batch file instead of using the software GUI?

There is no difference (assuming parameters are the same).

I think I'll post a letter on this forum begging for more work on
this...


Article: 109774
Subject: Re: EDIF
From: "Brannon" <brannonking@yahoo.com>
Date: 5 Oct 2006 08:02:23 -0700
Links: << >>  << T >>  << A >>
> I am using synplify to synth a design with some xilinx core gen devices. I
> get warnings on some of the core gen edif files stating that there is an
> interface mismatch between the verilog and the edif. I can only assume
> that it is something that core gen is not doing correctly. Has anyone else
> seen this problem? Here is the warning I get.
>
> @W: :  | Interface mismatch for Entity/Module dplbuf_16x512

Give us the Coregen version, OS, object and parameters so we can
reproduce the problem.




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