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 80975

Article: 80975
Subject: Help on Looser-Take-All / Winner-Take-All circuit
From: etantonio@gmail.com (Etantonio)
Date: 15 Mar 2005 07:50:34 -0800
Links: << >>  << T >>  << A >>
Good morning,
a friend of mine have inserted this post on a Forum I created on my site 
www.etantonio.it/en , this is the question :

"Someone knows something about LTA/WTA circuits?
I mean the best approach to the problem,
the best topology and all that can be usefull
to design an accurate and high-speed LTA?"

I don't know the answer, if you know it please post it just following this link:

http://www.etantonio.it/Forum/topic.asp?TOPIC_ID=15

Many Thanks,

Eng. Antonio D'Ottavio
etantonio@etantonio.it
www.etantonio.it/en/

Article: 80976
Subject: Re: Which HDL?
From: "Peter Sommerfeld" <psommerfeld@gmail.com>
Date: 15 Mar 2005 08:05:45 -0800
Links: << >>  << T >>  << A >>
Before you create your own HDL, take a look at Confluence,
www.confluent.org. It's IMO much more advanced than Verilog or VHDL and
generates FNF, which can be converted to all kinds of stuff including
Verilog or VHDL. 3 lines of Confluence is equivalent to about 30 lines
of VHDL in some cases (ie. component instantiation). I think there are
problems with creating dual-ported RAMs though, but this is mostly
because other vendor tools (ie. Quartus, ISE) inference structures from
generic HDL is still pretty poor in some cases. This may no longer be
the case, it's been awhile since I checked.

-- Pete

> Genericity is not a programming language approach. This is an
> abstract concept, which is used by many programming languages,
> but is not a part of them. Moreover, it is much more useful in
> hardware specifications than in programming languages. However,
> its support in VHDL and Verilog is very restricted and annoying.
> So the only reasonable thing I can do is to create my own HDL
> and a translator to VHDL, to reuse existing tools. :-)
> 
>     Best regards
>     Piotr Wyderski


Article: 80977
Subject: Register file with LUTs in a SPARTAN3
From: "Isidoros Sideris" <isidoros@microlab.ntua.gr>
Date: Tue, 15 Mar 2005 18:36:02 +0200
Links: << >>  << T >>  << A >>
I want to implement a register file with 2 read ports and one write port in
a Spartan3. Is this feasible using LUTs? Another solution is to use flip
flops, but I overuse the resources in this way.

Thanks,
Isidoros



Article: 80978
Subject: Re: Which HDL?
From: "Thomas Entner" <aon.912710880@aon.at>
Date: Tue, 15 Mar 2005 17:37:03 +0100
Links: << >>  << T >>  << A >>
>> Genericity is not a programming language approach. This is an
>> abstract concept, which is used by many programming languages,
>> but is not a part of them. Moreover, it is much more useful in
>> hardware specifications than in programming languages. However,
>> its support in VHDL and Verilog is very restricted and annoying.
>> So the only reasonable thing I can do is to create my own HDL
>> and a translator to VHDL, to reuse existing tools. :-)

> Before you create your own HDL, take a look at Confluence,

You might also check EVHDL, available at www.entner-electronics.com

Thomas Entner



Article: 80979
Subject: PLB_EDK_Simulation
From: mmkumar@gmail.com
Date: 15 Mar 2005 08:41:39 -0800
Links: << >>  << T >>  << A >>
Hi ,
  I am doing EDK Simulation of  power pc(Ml 310)system,I have a master
which does some write access to the external memory(plb bram), then in
my application the processor is reading the same locations from the
external bram (to which my dma master had written earlier).the first
read happens from the processor ,after that it doesn't proceed
further.(say instead some 8 reads ,only one read happens).Does any one
came across this problem.Please help me out in this.Both the
instruction and data resides in the plb_bram.

Regards,
Mack.


Article: 80980
Subject: Re: Register file with LUTs in a SPARTAN3
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 15 Mar 2005 16:45:45 GMT
Links: << >>  << T >>  << A >>
You should get your HDL code to produce two dual-port primitives if you
infer the register file with a single write and two reads.  The total cost
in the Spartan-3 is 4 LUTs (2 slices) per bit for up to 16 entries.

"Isidoros Sideris" <isidoros@microlab.ntua.gr> wrote in message
news:d172ti$i9t$1@ulysses.noc.ntua.gr...
> I want to implement a register file with 2 read ports and one write port
in
> a Spartan3. Is this feasible using LUTs? Another solution is to use flip
> flops, but I overuse the resources in this way.
>
> Thanks,
> Isidoros



Article: 80981
Subject: Lattice ispLEVER
From: "Fred" <Fred@nospam.com>
Date: Tue, 15 Mar 2005 17:05:33 -0000
Links: << >>  << T >>  << A >>
The freebie version has a 6 month temporary license.

Can this be renewed indefinitely or must I pay money after the 6 months has 
expired? 



Article: 80982
Subject: Tri-Stae Bus
From: "FPGA05@gmail.com" <FPGA05@gmail.com>
Date: 15 Mar 2005 09:41:51 -0800
Links: << >>  << T >>  << A >>
Hello All,

I am developing a partial reconfigurable system that allows modules to
be dynamically placed and removed at run-time on Virtex XCV1000 FPGA.
As part of my effort I have to develop a shared memory bus through
which all these modules can communicate. Inorder to accommodate the
partial reconfiguration, the only option left is to implement the bus
using tri-state logic (bus macros). There is an central arbiter
responsible to generate the enable signal for each of the modules. This
enable signal controls the tri-state inputs of the Shared bus signals
(Data,Address). I have an address bus of width 19 bits and data bus of
width 40 bits. So the enable signal output is to be connected to nearly
50 tri-state input pins.

Is there a limit on the maximum number of signals that an output can
drive? Incase if the fanout requirements are not met then the only
alternative I could think of was to generate multiple enable signals
for each module and use each of these to drive the shared signals. I
was wondering if there would be any issues in this approach or if there
are any better approaches

Thanks


Article: 80983
Subject: Re: XC3000 non-recoverable lockup problem
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 16 Mar 2005 07:33:42 +1300
Links: << >>  << T >>  << A >>
lecroy7200@chek.com wrote:
> Thanks again.  I will try the pulsed supply as suggested today and post
> my findings.
> 
> To give you an idea of the MTBF, of about 90 ICs being run, I have seen
> or heard of the problem 5 times over about a six month period.  There
> is not a good way to probe the parts after the fact to see what is
> going on.  Reproducing the problem seems to be the only good way to
> solve it at this point.

  Besides power supply transient, you should also look at IO pin 
transients, or even RF field bursts. The consensus is the logic is being
disturbed, but the source is a mystery.
  Large IO transisents can cause lateral currents in the die.
Do the failures have any site/user-clusters ?
-jg


Article: 80984
Subject: Re: Xilinx ISE and IP cores
From: Nemesis <nemesis@nowhere.invalid>
Date: Tue, 15 Mar 2005 18:50:35 GMT
Links: << >>  << T >>  << A >>
Mentre io pensavo ad una intro simpatica "Jim George" scriveva:

>> Hi everyone,
>> I'm going to buy Xilinx ISE Foundation, I'd like to know if this package
>> contains also IP cores like DDC, FFT and so on.
>> It seems that the "LogiCore" IPs should be shipped within ISE
>> Foundations, am I right?
> Yes, ISE Foundation comes with Coregen.

Thanks, I'm still trying to found a complete list of the IP shipped with
ISE. I found at least on LogiCore IP wich is not given for free (the PCI
IP).

-- 
"Costacurta colpisce Batistuta al polpaccio, che finisce a terra"
(Carlo Sassi)
 
 |\ |       |HomePage   : http://nem01.altervista.org
 | \|emesis |XPN (my nr): http://xpn.altervista.org


Article: 80985
Subject: Re: XC3000 non-recoverable lockup problem
From: lecroy7200@chek.com
Date: 15 Mar 2005 10:59:11 -0800
Links: << >>  << T >>  << A >>

> Do the failures have any site/user-clusters ?
> -jg

Not sure what you mean by this.

I did look at all of the signals to/from the devices and there is not
an excessive amount of over/undershoot.

I tried setting up a test to pulse the power to the board.  The problem
in doing this is the amount of bulk and high frequency capacitance on
the board prevents me from getting a good solid pulse.  I thought about
doing a push-pull but have not tried this yet.  Just interrupting the
power, I set the pulse time to where the devices would just start to
become effected.  I would then reprogram them and repulse the supply.
I ran this test for about four hours today and was still not able to
replicate the problem.

I also opened a case file with Xilinx.  I would drop the old 3000A
parts if I knew that would fix the problem, but until I am able to
reproduce it I don't see this being an option.  I have never seen an
FPGA get into a mode like this that required a power cycle to clear it.


Article: 80986
Subject: Re: Memory gate count in ASIC and in FPGA
From: xing1234@yahoo.com
Date: 15 Mar 2005 11:32:47 -0800
Links: << >>  << T >>  << A >>
Thanks Gabor and JJ for your reply.

If I really want to implement the 300KMbyte ROM in FPGA, I guess I have
to use at least Xilinx Virtex II 6000, which has 144 Block RAM(totally
324KByte). I may need to think about using external memory.

The question comes from an eveluation of an hardware IP, which has 500K
logic gate counts in ASIC plus 300KByte ROM. When I consider if I can
implement it in FPGA, the first thing is what FPGA and how many FPGAs I
need for. For this case, I can barely get ROM done on Virtex 6000, but
not sure if the rest resource of 6000 can accomendate the 500K logics.
Do I have to synthesis the Logic in Synplicity and place&route it to
know how many slices it requires? or there is a way so that I can know
in advance?


Thanks.


Article: 80987
Subject: Re: Lattice ispLEVER
From: Luc <lb.edc@pandora.be>
Date: Tue, 15 Mar 2005 20:37:56 +0100
Links: << >>  << T >>  << A >>
Hi,

You can renew be downloading the latest version after 6 months. You
don't have to pay anything.

Regards,

Luc

On Tue, 15 Mar 2005 17:05:33 -0000, "Fred" <Fred@nospam.com> wrote:

>The freebie version has a 6 month temporary license.
>
>Can this be renewed indefinitely or must I pay money after the 6 months has 
>expired? 
>


Article: 80988
Subject: Re: XC3000 non-recoverable lockup problem
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 16 Mar 2005 09:44:38 +1300
Links: << >>  << T >>  << A >>
lecroy7200@chek.com wrote:
>>Do the failures have any site/user-clusters ?
>>-jg
> 
> 
> Not sure what you mean by this.

  Are the failures random across all your installations, or
do they cluster in a few sites or users. Often these
external impact effects are local.
  Any relays or contactors involved ?

> I did look at all of the signals to/from the devices and there is not
> an excessive amount of over/undershoot.

  It is not a 'normal signal' effect, but an external impulse effect.

  A good 'chip cracker' test is a self commutating mains relay, and a 
short 'wand' cable. The arcing contact + bounce effects mean you can
generate wave fronts of over 1KV/ns. Wave the wand around your cables
and PCB, and watch for your effect.

  We have used this type of severe test setup, to find that a number of 
chips have the (Reset < Power Cycle) effects.

> I tried setting up a test to pulse the power to the board.  The problem
> in doing this is the amount of bulk and high frequency capacitance on
> the board prevents me from getting a good solid pulse.  I thought about
> doing a push-pull but have not tried this yet.  Just interrupting the
> power, I set the pulse time to where the devices would just start to
> become effected.  I would then reprogram them and repulse the supply.
> I ran this test for about four hours today and was still not able to
> replicate the problem.
> 
> I also opened a case file with Xilinx.  I would drop the old 3000A
> parts if I knew that would fix the problem, but until I am able to
> reproduce it I don't see this being an option.  I have never seen an
> FPGA get into a mode like this that required a power cycle to clear it.


Article: 80989
Subject: Re: XC3000 non-recoverable lockup problem
From: lecroy7200@chek.com
Date: 15 Mar 2005 13:24:41 -0800
Links: << >>  << T >>  << A >>

Jim Granville wrote:
> lecroy7200@chek.com wrote:
> >>Do the failures have any site/user-clusters ?
> >>-jg
> >
> >
> > Not sure what you mean by this.
>
>   Are the failures random across all your installations, or
> do they cluster in a few sites or users. Often these
> external impact effects are local.
>   Any relays or contactors involved ?

This is a random failure from what I am able to tell and not tied to a
particular location or setup.  The environment is clean (from a noise
perspective).

>
> > I did look at all of the signals to/from the devices and there is
not
> > an excessive amount of over/undershoot.
>
>   It is not a 'normal signal' effect, but an external impulse effect.
>
>   A good 'chip cracker' test is a self commutating mains relay, and a

> short 'wand' cable. The arcing contact + bounce effects mean you can
> generate wave fronts of over 1KV/ns. Wave the wand around your cables
> and PCB, and watch for your effect.
>
>   We have used this type of severe test setup, to find that a number
of
> chips have the (Reset < Power Cycle) effects.
>

We sell products all over the world and require CE certification.  We
perform a full set of conducted and radiated tests on every product.
During these tests I have not seen this problem.  This is a much worse
environment than where the units are being run.

The main clock on this card is 500MHz and we sample on both edges.
There are several layers of ECL before getting to the Xilinx parts that
are running at a modest 60MHz.  So termination and correct layout are a
big factor in making the designs work. Almost every trace is
controlled.

I went ahead and installed a second FET to crowbar the supply to the
card once power was cut in order to force the bulk and high frequency
caps. to discharge at a faster rate.  This did help me achieve a faster
edge with my power supply testing, but again I was not able to
reproduce the problem.


Article: 80990
Subject: EDPS 2005 Early Registration Ends March 16, 2005
From: b_kapoor@yahoo.com
Date: 15 Mar 2005 13:32:26 -0800
Links: << >>  << T >>  << A >>
Please register by March 16, 2005, to take advantage of early
registration for the EDPS 2005, April 7-8, Monterey, CA. Please contact
the Beach Resort at Monterey before March 23, 2005, for the best rates!

EDPS follows ISPD 2005, April 3-6, San Francisco, CA.

Please forward this message to anyone else in your organization who may
be interested in attending the EDPS 2005.

For more information on EDPS 2005, please visit the website listed
below and follow the link for registration:

http://www.eda.org/edps

Thanks and best regards,
EDPS 2005 Program Committee


Article: 80991
Subject: Re: PLB_EDK_Simulation
From: "Nju Njoroge" <njoroge@stanford.edu>
Date: 15 Mar 2005 13:56:43 -0800
Links: << >>  << T >>  << A >>
mmkumar@gmail.com wrote:
> Hi ,
>   I am doing EDK Simulation of  power pc(Ml 310)system,I have a
master
> which does some write access to the external memory(plb bram), then
in
> my application the processor is reading the same locations from the
> external bram (to which my dma master had written earlier).the first
> read happens from the processor ,after that it doesn't proceed
> further.(say instead some 8 reads ,only one read happens).Does any
one
> came across this problem.Please help me out in this.Both the
> instruction and data resides in the plb_bram.
I have seen this problem a few times. In both instances, the problem
was caused by not giving the BRAM's enough time to "set-up" in the
ModelSim simulation. Apparently, you have to wait more than 100 ns of
simulation time for the BRAM's to be able to capture data you write to
them, otherwise, you'll read back zeroes.  This was even the case when
the BRAM's were pre-initialized with instructions--I had to wait 100 ns
to be able to read the instructions.

A caveat is defining a 100 ns in simulation because this depends on the
timescale. In setting-up EDK, go to the "Project Options", select the
"HDL and Simulation" tab and select "Verilog" in the HDL type to ensure
that the simulation uses 1 ns for its timescale. Otherwise, in VHDL
mode, I think it uses a 1 ps, so you have to use many more simulation
cycles to set-up the BRAM's.


Article: 80992
Subject: Re: Which HDL?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 15 Mar 2005 17:38:38 -0500
Links: << >>  << T >>  << A >>
Peter Sommerfeld wrote:

>I find Verilog a heck of a lot easier and results in more compact code
>vs. VHDL. Verilog-2001 seems to have what was missing between the last
>version and VHDL (generate, configurations, good file I/O, lots of
>other new stuff). AHDL was the easiest to write, but supported only by
>Altera, therefore no coded testbenching.
>
>-- Pete
>
>  
>
Verilog 2001 still lacks the ability to define constants  inside 
generates that are dependent on the generate index variable.  Structural 
placement, eg assigning values to the RLOC constraints for placed 
instances, remains difficult to do with Verilog 2001, while it has been 
available with VHDL for quite a while.  Also,  I find that the type 
checking in VHDL is a life saver for designs that have a lot of 
arithmetic.  If you are already comfortable with VHDL, you may very well 
find Verilog to be frustrating to use for designs that are more 
structural than behavioral.

-- 
--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: 80993
Subject: Re: Which HDL?
From: aa55 <aa55@nospam.invalid>
Date: Wed, 16 Mar 2005 09:40:21 +1100
Links: << >>  << T >>  << A >>
How well do these HDLs cope with asynchronous or high speed designs?
I find that Verilog/VHDL allows you to get the most out of the FPGA, 
albeit with the use of vendor constraints ;)
Peter Sommerfeld wrote:
> Before you create your own HDL, take a look at Confluence,
> www.confluent.org. It's IMO much more advanced than Verilog or VHDL and
> generates FNF, which can be converted to all kinds of stuff including
> Verilog or VHDL. 3 lines of Confluence is equivalent to about 30 lines
> of VHDL in some cases (ie. component instantiation). I think there are
> problems with creating dual-ported RAMs though, but this is mostly
> because other vendor tools (ie. Quartus, ISE) inference structures from
> generic HDL is still pretty poor in some cases. This may no longer be
> the case, it's been awhile since I checked.
> 
> -- Pete
> 
> 
>>Genericity is not a programming language approach. This is an
>>abstract concept, which is used by many programming languages,
>>but is not a part of them. Moreover, it is much more useful in
>>hardware specifications than in programming languages. However,
>>its support in VHDL and Verilog is very restricted and annoying.
>>So the only reasonable thing I can do is to create my own HDL
>>and a translator to VHDL, to reuse existing tools. :-)
>>
>>    Best regards
>>    Piotr Wyderski
> 
> 

Article: 80994
Subject: Re: Tri-Stae Bus
From: aa55 <aa55@nospam.invalid>
Date: Wed, 16 Mar 2005 09:46:50 +1100
Links: << >>  << T >>  << A >>
FPGA05@gmail.com wrote:
> Hello All,
> 
> I am developing a partial reconfigurable system that allows modules to
> be dynamically placed and removed at run-time on Virtex XCV1000 FPGA.
> As part of my effort I have to develop a shared memory bus through
> which all these modules can communicate. Inorder to accommodate the
> partial reconfiguration, the only option left is to implement the bus
> using tri-state logic (bus macros). There is an central arbiter
> responsible to generate the enable signal for each of the modules. This
> enable signal controls the tri-state inputs of the Shared bus signals
> (Data,Address). I have an address bus of width 19 bits and data bus of
> width 40 bits. So the enable signal output is to be connected to nearly
> 50 tri-state input pins.
> 
> Is there a limit on the maximum number of signals that an output can
> drive? 

The limit will depend on the speed that of the busses, the number of 
loads and the location of the loads.  I've found that 50 loads is no 
problem on a 33MHz bus in the spartan2E.

Incase if the fanout requirements are not met then the only
> alternative I could think of was to generate multiple enable signals
> for each module and use each of these to drive the shared signals. I
> was wondering if there would be any issues in this approach or if there
> are any better approaches
> 
> Thanks
> 


Article: 80995
Subject: Re: Xilinx XST 6.3i: Typo in generics, silent failure?
From: David Dye <david.dye@xilinx.com>
Date: Tue, 15 Mar 2005 15:57:04 -0700
Links: << >>  << T >>  << A >>
Marius Vollmer wrote:
> Brian Philofsky <brian.philofsky@no_xilinx_spam.com> writes:
> 
> 
>>[...]
>>If you did not use any translate_off / ons in the code, you should
>>have seen errors during either XST or NGDBUILD as it would have
>>identified the incorrect parameter and properly warned but if those
>>are in the code, the tools ignore them as you are instructing with
>>those commands.
> 
> 
> This is not my experience.  In the code below, the generic
> associations marked with XXX are clearly wrong but go unnoticed.

Marius,

I have reproduced the behaviour you are seeing and I agree that this is 
indeed a defect that needs to be addressed.  If pin names are 
misspelled, an error is generated, and we don't see the same behaviour 
when defparams are used in Verilog to perform the equivalent function. 
I will check to see how soon the XST team can build a fix.

In the meantime, one solution would be to copy the DCM component 
declaration found in $XILINX/vhdl/src/unisims/unisim_VCOMP.vhd into your 
HDL source and remove all the generics you are not using in that 
architecture (leave all the pins though).  This will allow XST to 
compare your instantiation's generics to this local declaration and will 
cause your testcase to produce an error (3 errors actually).

> 
> Also, I was unsuccessful in setting the "PERIOD" attribute from VHDL
> (also marked with XXX in the code).  Xst says:
> 
>     Timing constraint: NET clkgen_clk_100_buf PERIOD = 10 nS HIGH 5 nS
> 
> But par does not see this constraint, I think.  If I put the
> constraint in a .ucf file, then par does see it.  Hmmm.

This is correct.  Any timing specifications applied during synthesis
either through an .XCF file or within the HDL source will not be sent to
implementation by default.  To enable this feature use the "Write Timing
Constraints" command line / ISE option.  We determined that users were
more likely to start their timing constraints in UCF for implementation,
then go back and add them to synthesis if necessary (in an XST flow), so
we didn't want to add the extra or redundant constraints the
implementation flow without the user's explicit consent.

thanks,
david.

David Dye
Xilinx Technical Marketing

> 
> Thanks a lot, Brian!
> 
> 
> Here is the code fragment:
> 
> -- clock_generator -- generates deskewed system clocks and handles reset
> 
> library ieee;
> use ieee.std_logic_1164;
>   
> library unisim;
> use unisim.vcomponents.all;
> 
> use work.common.all;
> 
> entity clock_generator is
> 
>   generic (
>     clk_var_mult : positive;   -- Frequency multiplier for variable clock
>     clk_var_div  : positive);  -- Frequency divider
>   
>   port (
>     -- external connections
>     clk_100_in  : in u1;   -- 100MHz Clock from external oscillator
>     clk_sd_out  : out u1;  -- 100MHz to SDRAM
>     clk_sd_in   : in u1;   -- 100MHz feedback from SDRAM
>     reset_in    : in u1;   -- Reset input from switch
> 
>     -- global clock and reset
>     clk_100     : out u1;  -- Deskewed 100MHz clock, suitable for the
>                            -- SDRAM controller, for example.
>     clk_var     : out u1;  -- Variable frequency clock, see generics.
>     reset       : out u1); -- Reset
>     
> end entity;
> 
> architecture syn of clock_generator is
>   
>   signal clk_sd_in_buf, clk_100_deskewed, clk_100_buf : u1;
>   signal clk_var_unbuf, clk_var_buf : u1;
>   signal locked : u1;
> 
>   attribute period : string;
>   attribute period of clk_100 : signal is "10 ns"; -- XXX - no effect
>   attribute period of clk_var : signal is "40 ns"; -- XXX - no effect
>   
> begin
> 
>   -- The 100MHz clock is directly routed to the SDRAM.  The clock for
>   -- internal logic is deskewed with respect to the clock coming back
>   -- from the SDRAM.
>   
>   clk_sd_out <= clk_100_in;
> 
>   inbuf: IBUFG
>     port map (
>       i => clk_sd_in,
>       o => clk_sd_in_buf);
>   
>   deskew: DCM
>     generic map (
>       clkfx_mult => clk_var_mult,  -- XXX - no error for this
>       clkfx_div  => clk_var_div,   -- XXX - no error for this
>       hi_xst_how_is_your_day => 0, -- XXX - no error for this
>       clkin_period   => 10.0)
>     port map (
>       rst    => reset_in,
>       clkin  => clk_sd_in_buf,
>       clkfb  => clk_100_buf,
>       clk0   => clk_100_deskewed,
>       clkfx  => clk_var_unbuf,
>       locked => locked);
> 
>   buf_clk_100: BUFG
>     port map (
>       i => clk_100_deskewed,
>       o => clk_100_buf);
> 
>   buf_clk_var: BUFG
>     port map (
>       i => clk_var_unbuf,
>       o => clk_var_buf);
> 
>   clk_100 <= clk_100_buf;
>   clk_var <= clk_var_buf;
>   reset <= not locked;
>   
> end syn;
> 


Article: 80996
Subject: Re: (Stupid/Newbie) Question on UART
From: Eric Smith <eric@brouhaha.com>
Date: 15 Mar 2005 15:01:31 -0800
Links: << >>  << T >>  << A >>
"Alexei A. Frounze" <alexfru@chat.ru> writes:
> If the noise happens to invert two of the middle samples... I think better
> would be to have more than 3 and less than 16 to drop the boundary effects
> and count on more samples. 8?

If your line is that noisy, you're unlikely to have good results no matter
how the sampling is done.  I've never seen a serial line have that much
trouble, except on a 150m run from a factory floor to a computer room
three floors above.  On that, the main problem was a difference in ground
potential, and the cure was to switch to a balanced EIA-422 line with
electrical isolation at one end (cheaper than going to fiber, which would
also have worked).

Eric

Article: 80997
Subject: Annapolis WildCard for System Generator hardware-in-the-loop - Extreme DSP
From: "Pete" <padudle@sandia.gov>
Date: Tue, 15 Mar 2005 16:13:17 -0700
Links: << >>  << T >>  << A >>
Hello

Has anyone used an Annapolis WildCard for simulation acceleration under
System Generator for DSP?

I have a long IIR filter simulation that I need to run but VHDL simulations
are too slow to get meaningful data through the thing. The filter is heavily
serialized so each sample requires 800 clocks.

My hope was that using hardware-in-the-loop simulation with System Generator
would greatly accellerate the simulation but I really see no increase in
speed using a V2 board and parallel download cable.

The Annapolis web page claims that they add a DMA layer to the Sysgen
interface to their WildCard2 cardbus card. I own an original WildCard with a
Virtex 300.

Can you tell me if this runs a lot faster than the parallel cable interface?

  Pete



Article: 80998
Subject: Re: Xilinx ISE and IP cores
From: "Marc Randolph" <mrand@my-deja.com>
Date: 15 Mar 2005 17:57:46 -0800
Links: << >>  << T >>  << A >>

Nemesis wrote:
> Mentre io pensavo ad una intro simpatica "Jim George" scriveva:
>
> >> Hi everyone,
> >> I'm going to buy Xilinx ISE Foundation, I'd like to know if this
package
> >> contains also IP cores like DDC, FFT and so on.
> >> It seems that the "LogiCore" IPs should be shipped within ISE
> >> Foundations, am I right?
> > Yes, ISE Foundation comes with Coregen.
>
> Thanks, I'm still trying to found a complete list of the IP shipped
with
> ISE. I found at least on LogiCore IP wich is not given for free (the
PCI
> IP).

Howdy,

   I looked everywhere I could think of and could not find a list of
which cores cost money and which are included with Core gen.

I don't know what DDC is (did you mean DCT, in which case there are 1-D
and 2-D DCT's included).  There are a number of different FFT's
included with Coregen as well.

Good luck,

   Marc


Article: 80999
Subject: Re: Xilinx ISE and IP cores
From: Stephan Neuhold <stephan.neuhold@xilinx.com>
Date: Tue, 15 Mar 2005 18:13:01 -0800
Links: << >>  << T >>  << A >>
Nemesis wrote:
> Hi everyone,
> I'm going to buy Xilinx ISE Foundation, I'd like to know if this package
> contains also IP cores like DDC, FFT and so on.
> It seems that the "LogiCore" IPs should be shipped within ISE
> Foundations, am I right?
> 

Nemesis,

You can find all supported IP for Coregen 7.1i at the following site
http://www.xilinx.com/ipcenter/coregen/coregen_iplist_71i.htm

Regards,
Stephan



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