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 105225

Article: 105225
Subject: Partial shift register extraction in ISE
From: =?ISO-8859-1?Q?Johan_Bernsp=E5ng?= <xjohbex@xfoix.se>
Date: Tue, 18 Jul 2006 17:03:34 +0200
Links: << >>  << T >>  << A >>
Hi all,

I'm building a design where I want ISE (8.1) to extract the shift 
registers in some parts, i.e. where I have inferred SRL counters etc, 
and not to extract them in other parts. For instance where I have coded 
multiple stages of pipelining in order to obtain timing closure. Has 
anybody done this? Partial shift register extraction, that is.

The design is occupying about 50% of a Virtex-2 2000 and running mostly 
at 200 MHz. This is why I need to insert some pipelining between 
different stages in the signal path. My intention is to add a few stages 
to enable ISE to divide the routing in shorter bits.

Any input is highly appreciated

/Johan


-- 
-----------------------------------------------
Johan Bernspång, xjohbex@xfoix.se
Research engineer

Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems

www.foi.se

Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------

Article: 105226
Subject: Re: OpenFire - public domain MicroBlaze clone in verilog
From: "Stephen Craven" <nevarcs@gmail.com>
Date: 18 Jul 2006 08:22:40 -0700
Links: << >>  << T >>  << A >>
> its not the same at all - the OpenFire docs explain why they did not
> use the aeMB but rather designed a new core.

You are correct.  I wrote the OpenFire from scratch after encountering
difficulties understanding and modifying aeMB.  From what I remember
aeMB departed from the MicroBlaze three-stage pipeline to obtain better
performance.  For my purposes, however, I desired a simple pipeline and
controller. Performance did not suffer much, as I am able to obtain 100
MHz in a Virtex-II Pro.

The processor should be posted to OpenCores in the coming weeks.  In
the meantime, the official website is:
http://www.ccm.ece.vt.edu/~scraven/openfire.html

While the processor correctly executes a large subset of the MicroBlaze
instructions (minus the optional instructions), there is much room for
improvement.  If anyone would be interested in contributing to the
processor, please contact me.

Stephen


Article: 105227
Subject: NAND flash hangs
From: baker.ea@gmail.com
Date: 18 Jul 2006 08:24:06 -0700
Links: << >>  << T >>  << A >>
Please help...

I'm trying to access a Samsung K9K4G08U0M NAND flash device with an
Altera Cyclone II.

The NAND flash requires some setup signals do to a read from flash, ie.
CLE, nCE, nWE, ALE, nRE, and IO. After I have setup these signals, the
device's R/nB signal goes low, as expected, but it never goes high
again!!!  It just stays in the Busy state indefinitely!

The R/nB signal should stay low for a maximum of 25us for a read
according to the data sheet.

Even when I execute the Reset command to the flash, the flash hangs in
the Busy state.

I have already checked the hardware for shorts, the power rails for
noise, and I have even replaced the NAND flash chip.
I have checked the timing requirements for the setup signals and I have
tried slowing everything down to half speed.

I think my setup signals are correct, because the flash responds to
them, but I may be wrong.

Does anyone have any experience with this problem or advice for me?
It would be greatly appreciated.
Thanx
Eric


Article: 105228
Subject: Re: OpenFire - public domain MicroBlaze clone in verilog
From: "Antti" <Antti.Lukats@xilant.com>
Date: 18 Jul 2006 09:27:05 -0700
Links: << >>  << T >>  << A >>
Stephen Craven schrieb:

> > its not the same at all - the OpenFire docs explain why they did not
> > use the aeMB but rather designed a new core.
>
> You are correct.  I wrote the OpenFire from scratch after encountering
> difficulties understanding and modifying aeMB.  From what I remember
> aeMB departed from the MicroBlaze three-stage pipeline to obtain better
> performance.  For my purposes, however, I desired a simple pipeline and
> controller. Performance did not suffer much, as I am able to obtain 100
> MHz in a Virtex-II Pro.
>
> The processor should be posted to OpenCores in the coming weeks.  In
> the meantime, the official website is:
> http://www.ccm.ece.vt.edu/~scraven/openfire.html
>
> While the processor correctly executes a large subset of the MicroBlaze
> instructions (minus the optional instructions), there is much room for
> improvement.  If anyone would be interested in contributing to the
> processor, please contact me.
>
> Stephen

contact!

:)

* missing feature: byte enables in toplevel, they are internally there
but memory writes seem to be only 32 bit wide as byte enable signals
are not going to memories or to toplevel

Antti


Article: 105229
Subject: Re: 2048 input or gate ?
From: "Symon" <symon_brewer@hotmail.com>
Date: 18 Jul 2006 18:35:36 +0200
Links: << >>  << T >>  << A >>
"Ben Jones" <ben.jones@xilinx.com> wrote in message 
news:e9is6s$63f2@cliff.xsj.xilinx.com...
>
> I am not a sub-micron designer,
>
Just as well, you wouldn't be able to reach your keyboard! :-)
>
> so I don't really know how they achieved it
> :) but I'll bet it's a combination of the two factors you mentioned.
>
Yep, sounds like it. Thanks for that heads-up.
Cheers, Syms. 



Article: 105230
Subject: Re: NAND flash hangs
From: "Antti" <Antti.Lukats@xilant.com>
Date: 18 Jul 2006 09:51:27 -0700
Links: << >>  << T >>  << A >>
baker.ea@gmail.com schrieb:

> Please help...
>
> I'm trying to access a Samsung K9K4G08U0M NAND flash device with an
> Altera Cyclone II.
>
> The NAND flash requires some setup signals do to a read from flash, ie.
> CLE, nCE, nWE, ALE, nRE, and IO. After I have setup these signals, the
> device's R/nB signal goes low, as expected, but it never goes high
> again!!!  It just stays in the Busy state indefinitely!
>
> The R/nB signal should stay low for a maximum of 25us for a read
> according to the data sheet.
>
> Even when I execute the Reset command to the flash, the flash hangs in
> the Busy state.
>
> I have already checked the hardware for shorts, the power rails for
> noise, and I have even replaced the NAND flash chip.
> I have checked the timing requirements for the setup signals and I have
> tried slowing everything down to half speed.
>
> I think my setup signals are correct, because the flash responds to
> them, but I may be wrong.
>
> Does anyone have any experience with this problem or advice for me?
> It would be greatly appreciated.
> Thanx
> Eric

hm,

I just connected NAND flash to Xilinx OPB_EMC (sram-flash IP core) and
I had
no issues.

CLE to A0
ALE to A1
nCE GND

and it seems to work. you must keep nCE low during all transfer except
for special "CE DONT CARE" option NANDs

hum your chip seems to be "CE DONT CARE" so you can connect nCE to the
CS of the controller as well

Antti
PS the best testing is - connect it to GPIO and test, then later
connect to the system memory controller


Article: 105231
Subject: Re: Reuse a Speed Grade -8 Stratix image in Speed Grade -6 ...?
From: "Slurp" <slip@slap.slop>
Date: Tue, 18 Jul 2006 18:15:32 +0100
Links: << >>  << T >>  << A >>

<Jesper.Kristensen@tellabs.com> wrote in message 
news:1153198978.431574.203500@p79g2000cwp.googlegroups.com...
> Hello Group.
>
> Quite simple question... but I cannot seem to be able to find the
> answer:
>
> Given a Code Image initially targeted for a Stratix EP1S40F780C8 - i.e.
> Speed Grade "-8" - would it then be without troubles to load and run
> that Image on the corresponding "-6" device...?
>
> The need for the question arises in the crossfire of device
> availability and the wish of having only one Coding Image to update.
>
> Thanks in advance & best regards,
>
>  Jesper.
>

If the design is fully synchronous then there should be no problems, bearing 
in mind Altera's oddball numbering system where the higher the part suffix 
the slower the part.

However if you have any dodgy asynchronous behaviour included in the design 
which relies on things having certain prop. delays to work then definatley 
not - but you didn't design/verify it like that - did you?

You also need to check out the significance of the 'I' and 'C' (industrial 
and commercial) speedgrades and verify that your substitute part is indeed 
faster over your desired operational temp. range.

Slurp 



Article: 105232
Subject: Re: OpenFire - public domain MicroBlaze clone in verilog
From: "Stephen Craven" <nevarcs@gmail.com>
Date: 18 Jul 2006 10:43:44 -0700
Links: << >>  << T >>  << A >>
> * missing feature: byte enables in toplevel, they are internally there
> but memory writes seem to be only 32 bit wide as byte enable signals
> are not going to memories or to toplevel

It has been a while since I looked at it, but byte and half-word
addressing should be completely supported.  To keep the memory
interface simple, all accesses are 32-bits wide.  Byte and half-word
loads occur in the registerfile and byte and half-word stores operate
on a read-modify-write basis within the execute stage.

This does cause some difficulties in completely integrating the
processor into the EDK flow, among other things, so I may look into
adding an LMB interface.


Article: 105233
Subject: Re: OpenFire - public domain MicroBlaze clone in verilog
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 18 Jul 2006 19:56:49 +0200
Links: << >>  << T >>  << A >>
"Stephen Craven" <nevarcs@gmail.com> schrieb im Newsbeitrag 
news:1153244624.634326.318660@m79g2000cwm.googlegroups.com...
>> * missing feature: byte enables in toplevel, they are internally there
>> but memory writes seem to be only 32 bit wide as byte enable signals
>> are not going to memories or to toplevel
>
> It has been a while since I looked at it, but byte and half-word
> addressing should be completely supported.  To keep the memory
> interface simple, all accesses are 32-bits wide.  Byte and half-word
> loads occur in the registerfile and byte and half-word stores operate
> on a read-modify-write basis within the execute stage.
>
> This does cause some difficulties in completely integrating the
> processor into the EDK flow, among other things, so I may look into
> adding an LMB interface.
>

read-modify-write - thats not sufficent - the external memory interface must 
be able todo real byte writes as well, in the case that some stupid ip core 
is connected with 8 bit registers and side-effects on register reads. there 
are other reasons as well.

the byte_sel signal seems to be the signal that should go to toplevel and 
optionally be used by external memory interface

Antti 



Article: 105234
Subject: Re: Virtex 4, LVDS I/O: Sanity check please
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 18 Jul 2006 11:34:50 -0700
Links: << >>  << T >>  << A >>
John Adair wrote:
> Standards like SSTL are good for this due to the low signal swing. The
> biggest decision is if to use DCI which burns more power in the V4 or to use
> external resistors which take board area and make routing more difficult.
>
> The other decision is weither you use source synchronous clocking or a
> common clock approach. At 150 Mhz the common clock is slightly marginal
> depending on how long tracks are, speed grade, etc. unless you use some DCM
> based techniques. You can generate a clock that is offset from the common
> clock a little by using a DCM and use that as clock for register input to
> gain more time. Alternatively you can use a DCM to null out the clock to
> output time and get more margin from that.
>
> John Adair
> Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development
> Board.
> http://www.enterpoint.co.uk
>
>
> "Marc Reinig" <Marco@newsgroups.nospam> wrote in message
> news:44bc1fed@darkstar...
> >I have a project where I will have a large array of V4 FPGAs.  Each chip is
> >intended to connect to its four orthogonal neighbors with no intervening
> >logic.  I would like the number of bus connections between chips in any
> >direction in the array to be 150 (600 total I/O per chip).  The connections
> >will be bi-directional.  The distance between chips will be the minimum I
> >can have with sockets, heat sinks (with individual fans), good layout and
> >noise control.  Some of the lines, what ever is necessary, will be used for
> >clock and framing for the bus data signals.  I would like to use DDR.
> >During bus transfers, all the lines on opposite sides of the chip will be
> >operating and the other two sides will be quiescent.  I'm hoping for a bus
> >clock of 150 MHz.
> >
> >
> > Comments? ;=)
> >
> > Marco
> > ________________________
> > Marc Reinig
> > UCO/Lick Observatory
> > Laboratory for Adaptive Optics
> >
> >

If Marc uses SSTL, and uses resistive terminators, I would agree it
takes board space, but I disagree it would make routing significantly
more difficult, except for the sheer number of devices. In a point to
point situation only a series terminator is really required for speeds
up to at least 200MHz / 400Mb/s (I've done it).

Assuming these busses would be bidirectional, external series resistors
would [arguably, at least] actually be better in reducing EMI and
reflections than just DCI (less power too) assuming the devices are
close together (of the order of perhaps 4 inches or less). Much really
depends on the distance. I've used BGA style resistor packs that cram
more resistors into the device than can be done in multipack type SMT
devices. Apart from that, the tiny quad pack devices are particularly
sensitive to even slightly imperfect chip shooters and have a nasty
tendency to crack the resistor, particularly at the ends of the device.

CTS corp makes a particularly nice range of devices
(http://www.ctscorp.com/components/clearone.asp) [I have no affiliation
with them except for having used the parts in the past].

Cheers

PeteS


Article: 105235
Subject: Which PCI core for Cyclone II board?
From: "Brian McFarland" <brian.mcf1985@gmail.com>
Date: 18 Jul 2006 11:55:48 -0700
Links: << >>  << T >>  << A >>
Does anyone have experience with more than one of the PCI cores out
there?  I'm working a PCI card that's still in the early stages of the
design.  I'm hoping to be able to do pretty much everything on a single
Altera FPGA - most likely a Cyclone II device.

I've looked at the PCI Compiler from Altera.  It seems very poorly
documented, which I think will make the backend difficult to develop
and complicated.  The one from opencores.org looks like it's easier to
use, better documented, and has the advantage of being LGPL.  I haven't
looked at the one from Eureka much.

Any comment's regarding PCI compliance, ease of use, compatability with
Altera parts, etc?


Article: 105236
Subject: Re: P160 Communications module 3 with V2PRO--> EDK 7.1 errors
From: "Vivek Menon" <vivek.menon79@gmail.com>
Date: 18 Jul 2006 11:58:31 -0700
Links: << >>  << T >>  << A >>
suggestions anyone??
Vivek Menon wrote:
> Hi,
> I am trying to implement the sample design (Web server) that comes with
> the P160 communications module 3 from Avnet design. I have connected
> this module to the V2Pro7 FF672 board from Xilinx. When I run the
> tools-> buil applications, I get a series of errors:
> Running DRC Tcl procedures for OPTION IPLEVEL_DRC_PROC...
> ERROR:MDT -
> Unknown Tcl procedure ::hw_opb_emc_v1_10_b::check_iplevel_settings
> called
> ERROR:MDT - ERROR FROM TCL:- opb_emc_0 (opb_emc) -
> while executing
> "::hw_opb_emc_v1_10_b::check_iplevel_settings 37696248"
> ERROR:MDT - Errors occured while creating Hardware System
> make: *** [ppc405_i/lib/libxil.a] Error 2
> 
> Has anyone seen this?? any solutions?? 
> Vivek


Article: 105237
Subject: Re: Pointers for sending data using ethernet connection from V2Pro
From: "Vivek Menon" <vivek.menon79@gmail.com>
Date: 18 Jul 2006 12:11:43 -0700
Links: << >>  << T >>  << A >>
Hi,
I am trying to design and implement an interface or application that
will allow me to send data to the host PC through Ethernet cable. For
this purpose, I am using the P-160 communications module-3 that
includes a SMSC 91C11 Ethernet controller.
The sample design that came with Avnet design does not compile and
synthesize for EDK 7.1. I know that the PowerPC is a good option for
interfacing to the Ethernet controller, but I am not aware of the steps
to do so on my own. I am more familiar with the ISE design flow and
would prefer such an implementation.

Can someone who has designed or implemented such type of interface help
me or suggest some pointers??
Thanks,
Vivek

Vivek Menon wrote:
> Thanks for all the pointers. I have a couple of questions/doubts:
> The Verilog implementation for the Ethernet connection is too good.
> However, what is the standard practice?? I have two options:
> 1. Implement the Ethernet module(fpgas4fun) and connect it as another
> I/O module to my design block and send the data to the buffers which in
> turn will be transmitted over the ethernet to the host PC.
> 2. Use the PowerPC which will send the data to the host PC through the
> ethernet module. This means tweaking the web server design that comes
> with the P160 comm3 module and then instantiating the system.xmp as a
> VHDL module in ISE. I presume that the module would have a valid 8-bit
> port that will accept the data from my design block and transmit it
> over the ethernet to the host PC.
>
> I would like to know which option is better. Has anyone done it this
> way. Any suggestions??
> 
> Thanks,
> Vivek


Article: 105238
Subject: Re: P160 Communications module 3 with V2PRO--> EDK 7.1 errors
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 18 Jul 2006 12:16:27 -0700
Links: << >>  << T >>  << A >>
Vivek Menon wrote:
> suggestions anyone??

find the declaration for check_iplevel_settings
reinstall/update software
call the vendor
etc

       -- Mike Treseler

Article: 105239
Subject: Re: Which PCI core for Cyclone II board?
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 18 Jul 2006 21:19:48 +0200
Links: << >>  << T >>  << A >>
"Brian McFarland" <brian.mcf1985@gmail.com> schrieb im Newsbeitrag 
news:1153248948.387051.197670@p79g2000cwp.googlegroups.com...
> Does anyone have experience with more than one of the PCI cores out
> there?  I'm working a PCI card that's still in the early stages of the
> design.  I'm hoping to be able to do pretty much everything on a single
> Altera FPGA - most likely a Cyclone II device.
>
> I've looked at the PCI Compiler from Altera.  It seems very poorly
> documented, which I think will make the backend difficult to develop
> and complicated.  The one from opencores.org looks like it's easier to
> use, better documented, and has the advantage of being LGPL.  I haven't
> looked at the one from Eureka much.
>
> Any comment's regarding PCI compliance, ease of use, compatability with
> Altera parts, etc?
>

the easiest is the free PCI target from lattice, free download

I have used it on more than 5 different boards, altera and xilinx based
it has worked almost always first time tried - just set pin constraints and 
thats it

there are other free alternatives as well, but the lattice pci target is the 
simplest

Antti 



Article: 105240
Subject: Re: Post Place and Route simulation for Microblaze....
From: =?ISO-8859-1?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Tue, 18 Jul 2006 13:54:56 -0600
Links: << >>  << T >>  << A >>
Hi,

There is too little information for me to give you an answer of your 
problem.

Can you explain a little what you mean with "irregular patterns"?
Are you running simulation with the timing information file (.sdf) ?

Göran Bilski

Xesium wrote:
> Hi guys,
> I posted my problem a few days ago but I think I didn't make my points
> clear so I've decided to post it again.
> I have a very simple Microblaze based system which just has the
> processor and LMB BRAMs for instruction and data. I'm running my code
> on this system and I basically want to measure the power consumption of
> the system. I've generated a .vcd file by behavioral simulation of my
> design and estimated the power with that. But it seems that it is far
> unrealistic. As well by behavioral simulation I could verify my system
> behavior. I was monitoring my ilmb_lmb_abus which was the address bus
> of the instruction port of the microblaze and on the other hand I had
> the assembly code of my software so I could see what's going on in the
> system. However now to get a better estimation of power consumption of
> my system I want to do Post Place and Route simulation and generate the
> .vcd by doing so. I've made sure that there is data in BRAMs in
> system_stub_timesim.vhd file generated by ISE. But when modelsim
> simulates my design I observe irregular fetches on my address bus. Even
> the contents of the addresses which should be the opcodes of the
> instructions doesn't match with the assembly file that I have. I'm also
> monitoring Program  Counter value but that one too has irregular
> patterns in addresses though different from address bus. I'm trying to
> verify my simulation to make sure that the .vcd file that is generated
> is what it should be however I'm stuck here because I don't know what
> the problem is.
> I am wondering if any of you have any idea what is going on and what
> can I do about it,
> 
> I really appreciate your response and thanks alot beforehand,
> 
> Amir
> 
> PS. By the way I'm using ISE 8.1.03i and EDK 8.1.01i and Modelsim SE 6.0
> 

Article: 105241
Subject: Re: Virtex 4, LVDS I/O: Sanity check please
From: "Marc Reinig" <Marco@newsgroups.nospam>
Date: Tue, 18 Jul 2006 13:07:03 -0700
Links: << >>  << T >>  << A >>
We'll have >50 devices on a board, in a square array, depending on packing 
density and 5 to 10 boards.  I'm trying to keep the density high.



The buses theoretically could use a single clock and a single framing signal 
for 150 lines, but I know that's not practical.  I'm assuming 15 8-bit buses 
with individual clocks and framing on each of the four sides of the chip. 
Only two opposite sides will be active at any time.  So, 10 lines per bus 
for a total of 150 pins total and the same on the opposite side of the chip. 
That's 300 lines going at once for over 50 chips on each board.  I'm 
thinking of burying at least some of the traces internally to minimize EMI. 
If I have to use resistors, I will.



I just wanted to make sure that on the surface, assuming good design, there 
was nothing patently ridiculous about such a system.


Thanks,

Marco
________________________
Marc Reinig
UCO/Lick Observatory
Laboratory for Adaptive Optics

"PeteS" <PeterSmith1954@googlemail.com> wrote in message 
news:1153247690.204567.14300@75g2000cwc.googlegroups.com...
> John Adair wrote:
>> Standards like SSTL are good for this due to the low signal swing. The
>> biggest decision is if to use DCI which burns more power in the V4 or to 
>> use
>> external resistors which take board area and make routing more difficult.
>>
>> The other decision is weither you use source synchronous clocking or a
>> common clock approach. At 150 Mhz the common clock is slightly marginal
>> depending on how long tracks are, speed grade, etc. unless you use some 
>> DCM
>> based techniques. You can generate a clock that is offset from the common
>> clock a little by using a DCM and use that as clock for register input to
>> gain more time. Alternatively you can use a DCM to null out the clock to
>> output time and get more margin from that.
>>
>> John Adair
>> Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development
>> Board.
>> http://www.enterpoint.co.uk
>>
>>
>> "Marc Reinig" <Marco@newsgroups.nospam> wrote in message
>> news:44bc1fed@darkstar...
>> >I have a project where I will have a large array of V4 FPGAs.  Each chip 
>> >is
>> >intended to connect to its four orthogonal neighbors with no intervening
>> >logic.  I would like the number of bus connections between chips in any
>> >direction in the array to be 150 (600 total I/O per chip).  The 
>> >connections
>> >will be bi-directional.  The distance between chips will be the minimum 
>> >I
>> >can have with sockets, heat sinks (with individual fans), good layout 
>> >and
>> >noise control.  Some of the lines, what ever is necessary, will be used 
>> >for
>> >clock and framing for the bus data signals.  I would like to use DDR.
>> >During bus transfers, all the lines on opposite sides of the chip will 
>> >be
>> >operating and the other two sides will be quiescent.  I'm hoping for a 
>> >bus
>> >clock of 150 MHz.
>> >
>> >
>> > Comments? ;=)
>> >
>> > Marco
>> > ________________________
>> > Marc Reinig
>> > UCO/Lick Observatory
>> > Laboratory for Adaptive Optics
>> >
>> >
>
> If Marc uses SSTL, and uses resistive terminators, I would agree it
> takes board space, but I disagree it would make routing significantly
> more difficult, except for the sheer number of devices. In a point to
> point situation only a series terminator is really required for speeds
> up to at least 200MHz / 400Mb/s (I've done it).
>
> Assuming these busses would be bidirectional, external series resistors
> would [arguably, at least] actually be better in reducing EMI and
> reflections than just DCI (less power too) assuming the devices are
> close together (of the order of perhaps 4 inches or less). Much really
> depends on the distance. I've used BGA style resistor packs that cram
> more resistors into the device than can be done in multipack type SMT
> devices. Apart from that, the tiny quad pack devices are particularly
> sensitive to even slightly imperfect chip shooters and have a nasty
> tendency to crack the resistor, particularly at the ends of the device.
>
> CTS corp makes a particularly nice range of devices
> (http://www.ctscorp.com/components/clearone.asp) [I have no affiliation
> with them except for having used the parts in the past].
>
> Cheers
>
> PeteS
> 



Article: 105242
Subject: Re: Partial shift register extraction in ISE
From: "Gabor" <gabor@alacron.com>
Date: 18 Jul 2006 13:37:52 -0700
Links: << >>  << T >>  << A >>
Any register with a reset term should not infer SRL, since there
is no asynchronous (or synchronous) reset on distributed RAM.
So normally just adding the asynchronous reset process for the
pipeline stages and not for the slower stages should get the job
done.  I've noticed that XST likes to use SRL whenever possible,
and it will warn you about large registers that don't fit into SRL
due to reset requirements.

Johan Bernsp=E5ng wrote:
> Hi all,
>
> I'm building a design where I want ISE (8.1) to extract the shift
> registers in some parts, i.e. where I have inferred SRL counters etc,
> and not to extract them in other parts. For instance where I have coded
> multiple stages of pipelining in order to obtain timing closure. Has
> anybody done this? Partial shift register extraction, that is.
>
> The design is occupying about 50% of a Virtex-2 2000 and running mostly
> at 200 MHz. This is why I need to insert some pipelining between
> different stages in the signal path. My intention is to add a few stages
> to enable ISE to divide the routing in shorter bits.
>
> Any input is highly appreciated
>
> /Johan
>
>
> --
> -----------------------------------------------
> Johan Bernsp=E5ng, xjohbex@xfoix.se
> Research engineer
>
> Swedish Defence Research Agency - FOI
> Division of Command & Control Systems
> Department of Electronic Warfare Systems
>
> www.foi.se
>
> Please remove the x's in the email address if
> replying to me personally.
> -----------------------------------------------


Article: 105243
Subject: Re: Opencore ddr_controller
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 18 Jul 2006 20:56:07 GMT
Links: << >>  << T >>  << A >>
"KJ" <kkjennings@sbcglobal.net> wrote:

>
>"subint" <subin.82@gmail.com> wrote in message 
>news:1153200381.707271.324810@p79g2000cwp.googlegroups.com...
>> Hi,
>>         I am trying to do the post_par simulation of the opercore ddr
>> controller(from opencore.org)
>> There is feedback clk in this design which is said to be routed
>> externally to the ddr_clk. Since i cannot do this in the board
>
>That statement right there says that you need to stop and re-read how to use 
>the core and DDR.  The whole point of the feedback clock in any DDR design 
>is to compensate for PCB delays.  Trying to emulate these delays in some 
>manner is exactly the wrong approach.

The external feedback is completely unnecessary. If you use a DDR
flipflop in the output pad, you can create an external clock which has
a very predictable delay in respect to the internal clock. If you use
a 90 degrees shifted clock to capture the data into the input DDR
flipflop, you'll see there is more than enough timing margin (even
more margin than using DQS in combination with IOB delay to capture
the data). If trace lengths between the memory are almost equal, using
a phase shifted clock is the best option.

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

Article: 105244
Subject: ISE 8.2 - time to crash 20 minutes
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 18 Jul 2006 23:36:09 +0200
Links: << >>  << T >>  << A >>
Hi

Xilinx software is getting better! With 8.1 release I managed to get first 
fatal crash within 5 minutes after install, with 8.2 it did take 20mins 
already!

ok, actually its not even a crash - with WebPack 8.2 if running coregen and 
selecting

Clocking - Virtex 5

then the screen will start to blink wild

and a double click will then terminate the coregen.

still 20 mins to crash is an improvment compared to 5 mins.

Antti
PS the hotkeys in ISE text editor now work again! finally! 



Article: 105245
Subject: Re: JED file translator
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 19 Jul 2006 09:39:31 +1200
Links: << >>  << T >>  << A >>
sjulhes wrote:
> Hi all,
> 
> I have a JED file for an old PAL device  and I have to put this design in an 
> EPLD.
> Is there a tool that can read the JED file and translate it to any usable 
> language (vhdl, verilog or other ) ???
> 
> Have you any tip for this handling JED files ??

Some choices:
* Some device programmers will do this : eg PGM 16V8 as 16L8 etc
* Anachips WinPLACE will take old JEDs and create JEDs for their SPLDs
   [but it seems to not create an EQN report, which would have been 
sensible.. ]
* Search for JED2EQN, from Natsemi's ancient Opal sw
* reverse engineer of JEDs is not complex, but is a task best avoided...

-jg


Article: 105246
Subject: Re: NAND flash hangs
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Tue, 18 Jul 2006 23:58:05 +0200
Links: << >>  << T >>  << A >>

<baker.ea@gmail.com> wrote
> Please help...
>
> I'm trying to access a Samsung K9K4G08U0M NAND flash device with an
> Altera Cyclone II.
>
> The NAND flash requires some setup signals do to a read from flash, ie.
> CLE, nCE, nWE, ALE, nRE, and IO. After I have setup these signals, the
> device's R/nB signal goes low, as expected, but it never goes high
> again!!!  It just stays in the Busy state indefinitely!
>
> The R/nB signal should stay low for a maximum of 25us for a read
> according to the data sheet.
>
> Even when I execute the Reset command to the flash, the flash hangs in
> the Busy state.
>
> I have already checked the hardware for shorts, the power rails for
> noise, and I have even replaced the NAND flash chip.
> I have checked the timing requirements for the setup signals and I have
> tried slowing everything down to half speed.
>
> I think my setup signals are correct, because the flash responds to
> them, but I may be wrong.
>
> Does anyone have any experience with this problem or advice for me?
> It would be greatly appreciated.

Are you sure there is a pull-up on the R/nB signal? It's an open drain 
signal.

Marc 



Article: 105247
Subject: Virtex 4 ACE Compact Flash configuration problem
From: Dan <dan_mr@hotmail.com>
Date: Tue, 18 Jul 2006 15:31:25 -0700
Links: << >>  << T >>  << A >>
I am trying to program Xilinx Virtex4 evaluation board ML402 via ACE using Compact Flash card. Every time when I turn the device on the red LED 'Err' turns on.

Article: 105248
Subject: Re: Virtex 4, LVDS I/O: Sanity check please
From: "Tim" <tim@rockylogiccom.noooospam.com>
Date: Wed, 19 Jul 2006 00:22:56 +0100
Links: << >>  << T >>  << A >>
Marc Reinig wrote

> We'll have >50 devices on a board, in a square array, depending on packing 
> density and 5 to 10 boards.  I'm trying to keep the density high.
>

When I had a crack at this a few years ago, in Virtex2 days, I built
the array from little boards fitted together with high speed edge-mount
Samtec QSE/QTE connectors. Power came from a separate mother
board. Cooling was via commodity heat sinks and fans, using Maxim
fan controllers. The common clock came via a chip-style H-route on
the motherboard. We were targeting a giant motherboard, which was
itself made from click-together modules.

Sounds like fun. Good luck with the project and let the group know
how you get along.

Tim 



Article: 105249
Subject: Re: Virtex 4, LVDS I/O: Sanity check please
From: "Marc Reinig" <Marco@newsgroups.nospam>
Date: Tue, 18 Jul 2006 16:52:32 -0700
Links: << >>  << T >>  << A >>
"Tim" <tim@rockylogiccom.noooospam.com> wrote in message 
news:e9jqgl$apn$1$8302bc10@news.demon.co.uk...
> Sounds like fun. Good luck with the project and let the group know
> how you get along.

Will do!  Thanks everyone for the help.

Marco
________________________
Marc Reinig
UCO/Lick Observatory
Laboratory for Adaptive Optics





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