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 69775

Article: 69775
Subject: Re: Nios II Going Live...
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Wed, 19 May 2004 13:19:44 -0700
Links: << >>  << T >>  << A >>

Goran Bilski wrote:
> 
> There should only be different 3 numbers used as sizes,
> 0, 1 or infinity.  Any other number will creating barriers
> that will be reach and have impacts on the system.

I'm headed over to payroll right now!

Eric

Article: 69776
Subject: Re: program flash memory through JTAG on FPGA
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Wed, 19 May 2004 13:21:20 -0700
Links: << >>  << T >>  << A >>

Hi,

I have no idea what it costs, the students were able
to make use of the downloadable demo version, and they
were even offered technical support when they ran into
trouble...

Eric

"E.S." wrote:
> 
> Eric Crabill wrote:
> 
> > Hi,
> >
> > There's a tool called Universal Scan that does just what
> > you are looking for.  http://www.universalscan.com/
> > I had some students using it at SJSU to program an Intel
> > Flash attached to a Spartan-IIE.  I was impressed with
> > the tool.
> 
> In the last issue of Xcell-Journal (49) there is an article
> about it. They call it "inexpensive" ;-)

Article: 69777
Subject: Re: NIOS Board Stratix Edition - FPGA won't configure
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 19 May 2004 22:24:59 +0200
Links: << >>  << T >>  << A >>
kempaj@yahoo.com (Jesse Kempa) writes:

> "Subroto Datta" <sdatta@altera.com> wrote in message news:<n4zqc.524$1O4.119@newssvr15.news.prodigy.com>...
> > Vadim, make sure that you have the Unused Pins for your Quartus project set
> > to be Inputs Tristated. You can do this as follows after the project is
> > opened in Quartus:
> > 
> > 1. Click on Assign Device
> > 2. Click on the Device and Pin Options Button
> > 3. Click on the Unused Pins Tab.
> > 4. This should be the first Radio button.
> > 
> > Hope this helps.
> > 
> > - Subroto Datta
> > Altera Corp.
> 
> 
> Just to elaborate on why this is:
> 
> A feature of the Nios development boards is to demonstrate remote
> reconfiguration. This is done via an FPGA I/O which is connected to
> the MAX CPLD on the board. The MAX CPLD is programmed to re-configure
> the FPGA when the signal is driven low (in this way, the FPGA can send
> a signal telling the MAX chip to reconfigure itself). For reference
> designs that include this pin and leave it high, or tri-stated, there
> is no issue. However, a user design must either drive this pin high
> manually, tri-state the pin manually, or leave the pin un-assigned and

I informed Vadim about reconfigure issue a few weeks ago in:

http://groups.google.com/groups?safe=images&ie=UTF-8&as_ugroup=sci.electronics.cad&as_umsgid=m3brlbcge1.fsf@scimul.dolphinics.no&lr=&hl=en


Maybe there's another problem?

Petter

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 69778
Subject: Re: Nios II Going Live...
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 19 May 2004 20:58:21 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <40ABC160.8B7D3197@xilinx.com>,
Eric Crabill  <eric.crabill@xilinx.com> wrote:
>Goran Bilski wrote:
>> There should only be different 3 numbers used as sizes,
>> 0, 1 or infinity.  Any other number will creating barriers
>> that will be reach and have impacts on the system.
>
>I'm headed over to payroll right now!

Sorry, Cisco has decided to switch back to 100% ASIC, your payroll is
now set to size 0.  :)


-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 69779
Subject: Re: Nios II Going Live...
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 20 May 2004 08:59:52 +1200
Links: << >>  << T >>  << A >>
Jon Beniston wrote:
<snip>
> 
> Fair play to them, I didn't really think too much of NIOS, but if they
> really can push 200MHz with this, then I am impressed.

  I think I spotted the words 'simulated' close to that number... :)
ie the standard 'release it today, but talk about how fast it will
be next year....'

-jg


Article: 69780
Subject: Re: Nios II Going Live...
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 20 May 2004 09:03:32 +1200
Links: << >>  << T >>  << A >>
Eric Crabill wrote:

> Goran Bilski wrote:
> 
>>There should only be different 3 numbers used as sizes,
>>0, 1 or infinity.  Any other number will creating barriers
>>that will be reach and have impacts on the system.
> 
> 
> I'm headed over to payroll right now!

No, No, stooop !   They'll choose the ONE in the middle!! :)


Article: 69781
Subject: Re: Nios II Going Live...
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 20 May 2004 09:13:06 +1200
Links: << >>  << T >>  << A >>
Goran Bilski wrote:

> It's creating weird situation in embedding processing where you reach 
> the limit of the window.
> There should only be different 3 numbers used as sizes, 0, 1 or infinity.
> Any other number will creating barriers that will be reach and have 
> impacts on the system.
> On reaching the limit of the register window, you have a big chunk of 
> data to save and load which isn't nice to have when you need to have a 
> deterministic system.

  I'm lost - since the register count is finite at around 32 in most RISC
designs, how does removing a feature improve the situation ?.

  I don't know the specific NIOS details, but Register window/Frame 
Pointer/Register Bank select schemes have been around for years, and
can greatly help code density and reaction speed if done properly.
  I think sparc had a clever partial frame pointer, that allowed some
registers to carry calling/return parameters, and some as local variables.
  The compiler needs 'to be on its toes', but that's a SW
housekeeping issue.
  Another nice feature of register frame pointers, is if you are
uncomfortable with them, you can just ignore it, and you have
a 'vanilla RISC' core.

-jg


Article: 69782
Subject: S3 cheap shot
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 19 May 2004 14:14:37 -0700
Links: << >>  << T >>  << A >>
Tim,

Low blow.

S3 shipped a lot of parts last quarter.  A whole lot of parts.

No one expected the product to gather that many orders that fast.  Even 
the optomists among us were made to look like pessimistic fools.

If we would have only believed our own sales pitch that S3 was a better 
deal than an ASIC in volume (which it is), we might have been at least 
partially prepared.

Austin

Tim wrote:
> "Austin Lesea" wrote
> 
> 
>>At lunch the other day we were reminiscing about how the Z8000 never
>>took off because they changed their architecture and instruction set
>>completely from the Z80 and immediately alienated all of their customers
>>(who were still programming in assembly language in those days).
> 
> 
> Not quite getting it into production may have troubled some customers...
> 
> 
>>Not like that anymore.
> 
> 
> The Spartan-3 of its day ;-)
> 
> 

Article: 69783
Subject: Re: How to replace Triscend - Xilinx plans for the future
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 20 May 2004 09:26:01 +1200
Links: << >>  << T >>  << A >>
rickman wrote:

> Jim Granville wrote:
> 
>>Jim Granville wrote:
>><snip>
>>
>>> There are a LOT of Arm cores comming as MCU, with on chip FLASH, and
>>>that solves the smaller-memory end, by removing the memory BUS layout
>>>problems.
>>>
>>> Look at Philips LPC2xxx, STm STR7xxx, Analog Devices ADuC7xxx, TIs
>>>TMS470, Sony, etc for FLASH+ARM offerings, many with external memory
>>>interfaces.
>>
>>.. I should have included Motorola's MAC7100 ARM devices, TQFP144,
>>512KF, 32KR, Automotive specs..
> 
> 
> Wow!  This is a part I have been looking for for quite sometime.  I
> don't see any info on pricing or availability... any idea?  

Nope, but when I saw 5V and Automotive I did think of you :)
The date tags on the info gives some idea - looks 'real' to me.

I'd guess it's like the TMS470, targeted to the Automotive sector
in the truest sense of the term. (ie helps if you're called Ford, GM, 
BMW.. ) - but I'm sure both TI and Motorola are seeing customers
in the 'tough industrial' sectors who would like these devices too..

-jg


Article: 69784
Subject: Re: How to select an FPGA size (beginner)
From: pm940@yahoo.com (Paul Marciano)
Date: 19 May 2004 15:00:06 -0700
Links: << >>  << T >>  << A >>
"E.S." <emu@ecubics.com> wrote in message news:<C9vqc.149$Ou.77@fe39.usenetserver.com>...
> > The VGA timing interface will have a couple or three counters.
> > 
> > As you can instantly tell, it hasn't been thought through yet.  This
> > is day two of my "do something concrete" plan.
> 
> Have a look at www.fpgacpu.org. Jan Gray put a 16bit 
> RISC,DMA,MemoryControl & Video in a chip which is so small, it isn't 
> even supported by xilix tools anymore ;-)

That's very interesting.  His VGA timing block uses half as many
registers as my first go at it.  I think I'm over-using registers
(where wires would work fine).

Jan uses an LSFR counter for his horizontal and vertical counters.  I
read a thread on this newgroup about such counters from, I think,
around 2001.  Talking about wide 100MHz counters.  The general view
was that LFSR counters use fewer CLBs than binary counters, and run
faster due to the lack of a carry chain, but come with caveats.  A
post near the end of the thread said, effectively, "use straight
binary counters and let the synthesis tool figure it out - modern
FPGAs are fast and the tools are good".


The VGA dot clock is around 25MHz.  I need a 10-bit horizontal counter
and a 9-bit vertical counter.

reg [9:0] xcnt;  // counts from 0 to 799.

always @(posedge clk)
  if (reset || xcnt == 799)
    xcnt <= #`TP 10'h0;
  else
    xcnt <= #`TP xcnt + 1;

Is that sufficient for a 10-bit 25MHz counter in the real world for
this application, or should I already been looking at LFSR counters?


> Just start with your design, and look the place & route statistics.
> Then you really get a feeling what resources you use on what function,
> and probably you even notice, that you implement it in a not so 
> efficient way for an FPGA.
> 
> And as soon you have some solid design,
> you still can run the place & route on different families & chips,
> then you really see what the difference is.

Thanks.  That sounds like a plan.

Paul.

Article: 69785
Subject: Re: Atmel Zigbee solutions
From: jon@beniston.com (Jon Beniston)
Date: 19 May 2004 15:32:53 -0700
Links: << >>  << T >>  << A >>
> Each has their own uses...
> Europe fought for 30 years to determine which should prevail:
> 
>                 Catolicism  *OR*  Protestantism.
> 
> Guess what ....
> 

What? You're saying both ZigBee and Bluetooth are a waste of time?

Cheers,
JonB

Article: 69786
Subject: Xilinx EDK (PPC): Problems Porting to Memec 2VP4LC Board
From: apple2ebeige@yahoo.com (Dave)
Date: 19 May 2004 17:54:35 -0700
Links: << >>  << T >>  << A >>
I'm having problems getting a system running with a Memec 2VP4LC
board.  I use Base System Builder, following Xilinx EDK 6.2 tutorial
instructions, specifying a Memec Virtex-II Pro P4-FG456 board and
making the appropriate changes to the UCF file.  The whole process
runs fine and the FPGA programs fine but seems inert.  Memec's
Ultracontroller demo runs OK so the board is probably OK.

Has anyone had luck with this board?

Thanks.

-Dave

Article: 69787
Subject: Re: How to select an FPGA size (beginner)
From: Ray Andraka <ray@andraka.com>
Date: Wed, 19 May 2004 21:06:42 -0400
Links: << >>  << T >>  << A >>
Using LFSRs for video counters comes from the days when 25-30 MHz performance took a lot of
work, and especially with earlier families like the 3000 and 3100 that did not have carry
chains (in which case, a binary counter not only was slow, but it also took up a lot of
resources...more than one level of logic).  10 bit counters in modern FPGAs can run at
several hundred MHz, and the carry logic is free.  For 25 MHz video, it is not worth the
extra headache of working with an LFSR.  It gains you nothing in this case.  If you look at
my Dynamic VIdeo hardware paper from ca. 1996, it also used LFSRs in the video timing logic.
That was done in National CLAY FPGAs, which are structurally similar to the Atmel 6000 series
parts, no carry chain, very limited interconnect, and simple logic cells that did not do
random logic well.




Paul Marciano wrote:
<snip>

>
> reg [9:0] xcnt;  // counts from 0 to 799.
>
> always @(posedge clk)
>   if (reset || xcnt == 799)
>     xcnt <= #`TP 10'h0;
>   else
>     xcnt <= #`TP xcnt + 1;
>
> Is that sufficient for a 10-bit 25MHz counter in the real world for
> this application, or should I already been looking at LFSR counters?
>

--
--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: 69788
Subject: Re: Nios II Going Live...
From: Ray Andraka <ray@andraka.com>
Date: Wed, 19 May 2004 21:10:59 -0400
Links: << >>  << T >>  << A >>
Hopefully the size of your paycheck will be the third possible
size, not the first ;-)

Eric Crabill wrote:

> Goran Bilski wrote:
> >
> > There should only be different 3 numbers used as sizes,
> > 0, 1 or infinity.  Any other number will creating barriers
> > that will be reach and have impacts on the system.
>
> I'm headed over to payroll right now!
>
> Eric

--
--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: 69789
Subject: Re: How to select an FPGA size (beginner)
From: "Chuck McManis" <devnull@mcmanis.com>
Date: Thu, 20 May 2004 02:42:48 GMT
Links: << >>  << T >>  << A >>

"Ray Andraka" <ray@andraka.com> wrote in message
news:40AB48D9.C3F88E92@andraka.com...
> If you are doing a synchronous design you normally shouldn't run out of
clock
> resources.  What are you doing that uses so many clocks?  I suspect your
> clocking is also causing your routing woes.  The virtex parts have
abundant
> routing resources; it is not that easy to use them up.

Some assumptions in there Ray :

"...If you are doing a synchronous design ..." but these days people are
doing SOC designs that might have a video clock, a CPU clock, a clock
driving an ethernet PHY, and a perhaps some refresh logic for their DRAM
controller. I'm not disagreeing with you, my point was that "gates" are
generally not the thing you run out of first.

Next up "...The virtex parts..." however the original poster wanted to stay
away from the "expensive" chips. so starting from CPLDs and moving up,
you're somewhat constrained there. Lots of clock resources in a Virtex II
Pro, but then again in single quantities the chip is $300. :-)

--Chuck



Article: 69790
Subject: Re: How to select an FPGA size (beginner)
From: Ray Andraka <ray@andraka.com>
Date: Thu, 20 May 2004 00:00:26 -0400
Links: << >>  << T >>  << A >>
Even the smallest FPGAs have four or more clock nets, and that is going back to
the
4000's.  Clock enables can do a lot for you, in most cases there is not really
a need for
a proliferation of clocks.  Multiple clock domains give rise to potential
timing
constraints issues, as well as problems crossing clock domain boundaries.  Not
that
any of that is insurmountable, just that it requires extra diligence to make
sure you
do it right, and that the tools don't mess up your good work.

When I said virtex parts, I was referring to the virtex architecture, which
includes all the
current families.  SpartanII is the virtex1 architecture, spartan2e is virtexE,
spartan3 is
a mutation of virtexII.  The point is all of these families have ample
routing.  Now,
whether the tools make efficient use of that routing is another question
altogether (they
don't, the tools now do a 'lazy' routing that only improves the routing until
it is good
enough.  Problem is in a dense design, the circuitous routing artificially
congests the
routing resources which can make it appear that you do not have the routing to
make timing.
Poor placement can also aggravate the routing.  The placer is *still* very bad
at placing
logic when a signal goes through multiple LUTs between flip-flops, often
placing the LUTs
without flip-flops far from the destinations, and well out of the way between
the source and
destination.  The result is again unnecessary congestion of the routing
resources, and pathetic
timing results.  Floorplanning will relieve enough of the problems caused by
the placer that
it is very hard to run out of routing.

BTW, the routing is generally more stressed with larger devices rather than the
smaller ones.
Required routing goes up roughly with the square of the number of LUTs, yet the
routing
network is virtually unchanged across the family. Additionally, placement is
more critical with
larger devices because haphazard placement will incur large routing delay
penalties, and that
makes the job of the router tht much harder (possibly leading to a no-route
situation due to timing)
With small FPGAs, it is the memories followed by logic that gets used up
first.  I would argue
that the routing in the cheap FPGAs is even more abundant.

CPLDs are a different animal altogether.  There, the routing between macrocells
is generally
sparse, and without careful planning it can be easy to use up the routing
there.

I stand by my earlier comments.


Chuck McManis wrote:

> "Ray Andraka" <ray@andraka.com> wrote in message
> news:40AB48D9.C3F88E92@andraka.com...
> > If you are doing a synchronous design you normally shouldn't run out of
> clock
> > resources.  What are you doing that uses so many clocks?  I suspect your
> > clocking is also causing your routing woes.  The virtex parts have
> abundant
> > routing resources; it is not that easy to use them up.
>
> Some assumptions in there Ray :
>
> "...If you are doing a synchronous design ..." but these days people are
> doing SOC designs that might have a video clock, a CPU clock, a clock
> driving an ethernet PHY, and a perhaps some refresh logic for their DRAM
> controller. I'm not disagreeing with you, my point was that "gates" are
> generally not the thing you run out of first.
>
> Next up "...The virtex parts..." however the original poster wanted to stay
> away from the "expensive" chips. so starting from CPLDs and moving up,
> you're somewhat constrained there. Lots of clock resources in a Virtex II
> Pro, but then again in single quantities the chip is $300. :-)
>
> --Chuck

--
--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: 69791
Subject: Re: Xilinx V2P: DCM and changing input clock
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Thu, 20 May 2004 14:04:48 +1000
Links: << >>  << T >>  << A >>
On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com>
wrote:

>Sean,
>
>Brute force!
>
>As long as the locked signal is low, periodically reset the DCM, and see 
>if the locked signal remains low.
>
>It takes a little state machine, and it would have to run off the DCM 
>CLKIN (which is OK, just assume it is running at 25 MHz to calculate how 
>many counts you need to wait to make sure that LOCKED has gone high).
>
>Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM, 
>use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset 
>the DCM).
>
>(pseudo code below)
>
>while CLKIN_STOPPED = 1 (clock is running)
>
>      assert (reset for one clock)
>      wait XX uSec
>
>      check DCM:  DCM not operating? (check approp. status)
>                       assert reset (for one clock)
>                       wait XX uSec
>                  else do nothing
>
>      wait XX uSec (use one counter for all waits)
>
>      go to check DCM

Hi Austin,

Is there any fundamental reason why this logic couldn't be built into
the DCM and be enabled/disabled by a config bit?

The "wait XX usec" might be a problem, but this could by worked around
in a number of ways (e.g. by using psclk as a timing reference, etc.)

I find that having to add this state machine to all DCMs just to get
them to work reliably is a bit of a pain.

Regards,
Allan.

Article: 69792
Subject: Re: NIOS Board Stratix Edition - FPGA won't configure
From: "Subroto Datta" <sdatta@altera.com>
Date: Thu, 20 May 2004 04:32:50 GMT
Links: << >>  << T >>  << A >>
Vadim acknowledged that setting the Unused Pins to be Iputs tristated solved
his problem.

- Subroto

"Petter Gustad" <newsmailcomp6@gustad.com> wrote in message
news:87isescgh0.fsf@filestore.home.gustad.com...

>
> Maybe there's another problem?
>
> Petter
>



Article: 69793
Subject: Debugging - Post-synthesis simulation
From: srkumar26@hotmail.com (kumar)
Date: 19 May 2004 22:03:11 -0700
Links: << >>  << T >>  << A >>
Hello friends,
I am new to working with Xilinx tools. I have a verilog design and its
pre-synthesis similation is tested. Now to verify the design, I have
synthesized it using Xilinx ISE tool (using XST) to get .ngd file.
a verilog netlist is generated from .ngd using ngd2ver command. I
think the generated netlist uses the simprims library. i simulated
(using ModelSim) the netlist using the same testbench as i used
before.

vsim -L simprims_ver simprims_ver.glbl mytopdesign

But one of the signal is different. an output signal 'a_recieved'
should be high for 1 clock cycle and go down, but it is high for 2
clock cycles.
i didn't know any way to debug as the names of internal wires
generated are completely different.

could anyone please tell if i am doing correctly and help me in
debugging?

thanks
kumar

Article: 69794
Subject: Re: Drive strength on I/O pads
From: praveenkn123@yahoo.com (prav)
Date: 19 May 2004 22:25:57 -0700
Links: << >>  << T >>  << A >>
Hi jamie,

I am already using the DPLL, but by using the DPll how will  it reduce
the PAD delay.I want the PAD delays to be less.

rgds,
prav


"Jamie Sanderson" <jamie@nortelnetworks.com> wrote in message news:<c8djnn$6jb$1@zcars0v6.ca.nortel.com>...
> If you aren't already using a DLL, you might consider it. It can remove
> several nanoseconds of clock-to-output delay. These are available in the
> device you're using.
> 
> Increasing drive strength can cause problems with simultaneous switching
> such as ground bounce. Xilinx's documentation should have guidelines telling
> you how many drivers of each strength you can use within a bank before
> having problems, but these are only guidelines.
> 
> "prav" <praveenkn123@yahoo.com> wrote in message
> news:863df22b.0405180416.23b4ec7e@posting.google.com...
> > Hi all,
> >
> > I am targeting my design to XCS200 -5 fg256(SPARTAN device) . My
> > OFFSET OUT timing constraints are very tight.So inorder to decrease
> > the PAD delay i am forced to set the drive strength to 24 and
> > SLEW=FAST. only 2 pins of the 137 I/O's which i am using have a drive
> > strength of 24 rest of them have a DRIVE=12.
> >
> > Can anyone tell me what is the significance of this DRIVE strength in
> > REAL time.Will it create any problems having a DRIVE=24 in real
> > time??.
> >
> > Thanks n rgds,
> > prav

Article: 69795
Subject: Re: Xilinx EDK (PPC): Problems Porting to Memec 2VP4LC Board
From: Sean Durkin <smd@despammed.com>
Date: Thu, 20 May 2004 08:04:00 +0200
Links: << >>  << T >>  << A >>
Dave wrote:
> I'm having problems getting a system running with a Memec 2VP4LC
> board.  I use Base System Builder, following Xilinx EDK 6.2 tutorial
> instructions, specifying a Memec Virtex-II Pro P4-FG456 board and
> making the appropriate changes to the UCF file.  The whole process
> runs fine and the FPGA programs fine but seems inert.  Memec's
> Ultracontroller demo runs OK so the board is probably OK.
> 
> Has anyone had luck with this board?
I don't know this board, but a common problem when the program doesn't 
start is the wrong reset level. Maybe the tutorial uses active high 
reset, but the board generates active low, so the FPGA stays in reset 
all the time.

cu,
Sean

Article: 69796
Subject: Timing Questions?
From: javodv@yahoo.es (javid)
Date: 20 May 2004 00:43:04 -0700
Links: << >>  << T >>  << A >>
Dear All,

I would like to ask you some timing questions. 

First scenatio and first question:

I have two signals, for example, /CS and /RD. Looking at the device
datasheet it says that:

-tCLRL CS LOW to RD LOW 0 ns
-tRHCH RD HIGH to CS HIGH Intel mode 0ns

Then looking at the datasheet I must assert /CS before /RD and
de-assert /CS after /RD. I would like to know if it is possible to
Assert /CS and /RD in the same clock cycle or should I first assert
/CS in a clock cycle and in the next clock cycle assert /RD. I mean,
in my state machine would be ok to assert /CS and /RD in the same
cycle due to "0ns" of the tCLRL and tRHCH or should I use two clock
cycles?.


And second scenario and question:

RULE 2.58:
During read cycles, the responding SLAVE MUST release all of D00-D31
before
releasing DTACK* or BERR* to high.

In a Read Data cycle in an VME Slave when the slave places the data
and asserts the signal /DTACK, waits until detects that /DS is high
again (Master). Then must release the data bus and rise (de-assert)
/DTACK at least "0ns" after releasing the data bus.

Could I release the Data bus and de-assert /DTACK in the same clock
cycle or should I release the data bus in a clock cycle and de-assert
/DTACK in the next clock cycle?.

Thanks a lot and best regards,

Javi

Article: 69797
Subject: Re: Timing Questions?
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 20 May 2004 03:08:50 -0500
Links: << >>  << T >>  << A >>
>Then looking at the datasheet I must assert /CS before /RD and
>de-assert /CS after /RD. I would like to know if it is possible to
>Assert /CS and /RD in the same clock cycle or should I first assert
>/CS in a clock cycle and in the next clock cycle assert /RD. I mean,
>in my state machine would be ok to assert /CS and /RD in the same
>cycle due to "0ns" of the tCLRL and tRHCH or should I use two clock
>cycles?.

What are your priorities?

"0ns" means one signal has to happen before or at the same time
as the other.  If you change two signals on the same clock edge,
you don't know which one of them might change first.  So you
need to do something to make sure the one you want changes first.

A clock cycle is the simple and clean way to do that.  It costs
a cycle.  Can you afford that?  If so, end of problem.

If you don't want to burn a whole cycle, then you start looking
for tricks.

You can sometimes use the other edge of the clock.  Now it only
costs you a half-cycle.  Or use a much faster clock where the
state machine counts several clocks for each of the old states.

Add some routing delay on the PCB (6 inches per ns).

Clock one signal in an IOB and the other one in a CLB near the IOB
so it takes a little longer to get out there.

Use lower drive on one signal.  (This assumes the loading and
layout are matched.)

[Don't forget to check the other edge too.]

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 69798
Subject: Re: Phase relationship management
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 20 May 2004 03:33:56 -0500
Links: << >>  << T >>  << A >>
>This doesn't explicitly clock out SO on the falling edge, however SO should
>have the correct value on the rising edge of a parallel clock right? Since
>the propagation delay of the clocking in the new data is non-zero, is it
>reasonable to assume that S0 will have the correct data on the rising edge?

The rules of the game are that you have to meet both setup and hold times.

If you have a string of FFs like a shift register, you are depending
on the clock-out delay of the source FF to cover the hold time of the
target FF.  You also have to leave room for clock skew.

If the manufacturer promises that things like that will work in their
silicon, the tools don't have to bother checking for hold times.
Xilinx works that way.   I assume others do, but I'm not familiar
with the details.


When you go between chips, you can't ignore hold time anymore.  You
have to check them just like you check the setup times.

The case you describe will probably work, but it's possible to
make things like that fail.  Clock skew is probably the easiest
way.


The classic clock problem with (really) old CMOS logic was a clock
feeding a long string of DIPs.  The capacitive load of the clock
pins turns the clock trace into a loaded transmission line which is
quite a bit slower than the speed of light.  Unloaded data bits could
beat the clock and cause hold problems.

Or the input thresholds could be slightly different on a slowly
rising clock so one chip of an adjacent pair clocks ahead of
its neighbor.


Using the other edge of the clock avoids all that nonsense.
It gives you a half cycle of setup and a half cycle of hold.
It will work with horrible clock skew between chips.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 69799
Subject: Re: Malfunctioning dual port block ram.
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 20 May 2004 12:49:11 +0100
Links: << >>  << T >>  << A >>
jon@beniston.com (Jon Beniston) writes:

> > > Possibly not the same problem, but I've seen issues recently with a
> > > Core Gen RAM not being synthed properly by XST. I switched over to
> > > Synplify and the problem disappeared.. My faith in XST is limited!
> > > 
> > 
> > I didn't think that Coregen'ed stuff *was* synthesised - does the
> > synth not see it as a black box? Then the downstream tools find the
> > EDIF netlist to fill in the gap..
> 
> Could it wire up the black box wrong? Functional sim worked okay and
> post-translate sim didn't (neither did h/w). It could have been the
> translate prog that screwed up I guess, but I didn't have the time or
> will to find out. 

That sounds more likely - or the synthesis of something else related
to the RAM (like a WE or address counter for example)

> Whenever things like that have happened before,
> switching to Synplify always fixed it.
> 

It's not bug-free either....

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt



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