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
2017JanFebMarApr2017

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 139500

Article: 139500
Subject: Re: Digital design references for timing, etc.
From: wondering.gnome@gmail.com
Date: Wed, 1 Apr 2009 09:04:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 8:44=A0am, Koorndyk <kris.koorn...@gmail.com> wrote:
> On Mar 31, 7:45=A0pm, wondering.gn...@gmail.com wrote:
>
>
>
> > Hi, all.
>
> > I'm relatively new to the field of digital design, and have completed
> > a few FPGA-based designs, successfully integrated and debugged them.
> > Writing HDL, using vendor tools and performing simulations have been
> > fairly straightforward and within my comfort zone. But now I'm faced
> > with the foreign task of debugging some nasty timing problems, and I'm
> > realizing how little I understand about some fundamental digital
> > design principles, like setup and hold timing, clock skew and jitter,
> > and the like.
>
> > What books and other resources would you recommend for someone who
> > needs a better understanding of digital design principles, with a
> > special focus on timing concerns?
>
> > Thanks,
> > The Wondering Gnome
>
> I've found the latest Xilinx Timing Constraints User Guide to be
> invaluable.
>
> www.xilinx.com/itp/xilinx10/books/docs/timing_constraints_ug/timing_c...

Thanks for that -- I've also found Xilinx docs to be particularly
helpful. But in this case I'm interested in learning about timing
considerations from first principles; what are the electrical
engineering considerations (so to speak) that I should be aware of,
especially with regards to timing. I'm not designing ASICs, but I hope
to gain that kind of requisite digital design logic. Any
recommendations on that front?

Regards,
W.G.

Article: 139501
Subject: Re: DCM vs PLL
From: austin <austin@xilinx.com>
Date: Wed, 1 Apr 2009 09:42:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
Sharan,

The DCM requires less area in silicon, thus we can provide more of
them.

They are digital, and greatly immune to power supply noise (as
compared to PLL's).

They are a state machine, so a "crummy clock" signal is NOT
recommended, as a DCM will have a hard time, where  a PLL is commonly
used to "clean up" a "crummy clock" in order to make it useful at all.

DCM will add totally random, white, broad band jitter, where a PLL
will remove high frequency jitter, while adding low frequency jitter
(due to its oscillator having very low Q on the silicon).  It will
also add as jitter any power supply noise present varies the VCO in
the PLL.

External PLL's may be used with voltage controlled crystal oscillators
where the quality of the on-chip PLL oscillator is unacceptable (for
example SONET/SDH transmit clock jitter requirements are tough to meet
without a very high Q resonantor).

PLL and DCM have their uses.  We provide a mix of both, and you may
precede a DCM with a PLL if you have a "crummy clock" or pass the DCM
through the PLL if you wish to remove all nearly all the high
frequency jitter components.

The DCM also offers precise dynamic phase shifting, which is not so
easy to do in a PLL.

Use a hammer for nails, and a screwdriver for screws.  They are both
fasteners.  Which is better?  Silly question.

Austin

Article: 139502
Subject: Re: DCM vs PLL
From: filter001@desinformation.de
Date: Wed, 1 Apr 2009 11:43:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 1 Apr., 17:36, "Symon" <symon_bre...@hotmail.com> wrote:
> PLL's have a higher potential for failures due tu their non-state-machine
> behaviour.
>
> For Example EMI could disturb some clocks getting into a PLL phase
> detector and you get a lock loss.

Did i miss some braindead engineer's pll design which needs a reset
after it got out of lock like the DCM's i know?

> Digital DCM's are more tolerant about that and especially if you want
> to have deterministic operation that is not component value dependent you
> are lost with the PLL.

And i also seem to have missed analog PLLs in FPGA's whose process
temperature voltage variations violate the specs.

> I would always chose a good DCM over analog PLL.- Zitierten Text ausblenden -

That's good as long as you can forbid your devices to pick up EMI or
any noise on it's clocks and do a preventive restart every minute or
so.

Article: 139503
Subject: Re: Dynamic reconfiguration in Spartan 3
From: Dirk Koch <dirk.koch@cs.fau.de>
Date: Wed, 01 Apr 2009 21:43:54 +0200
Links: << >>  << T >>  << A >>
austin wrote:
> Antti,
> 
> Spartan 3 does not support dynamic reconfiguration.  The design of the
> memory cells is such that a frame is reset to all zeroes prior to
> being written with the configuration.  This is the "glitching" that
> was referenced.
> 
> Now, Spartan 3A is different, and does not have this reset before
> being written behavior.
> 
> I am aware of Recobus, and of their excellent work.  I suggest that
> the best experience with dynamic reconfiguration will be with
> something other than Spartan 3, however.

The motivation for Spartan is simple: its cheaper and
consumes less power.
I was once asked, why to do runtime reconfiguration -
and on the argument "we can use a smaller device and
save money", I got "but you have to pay more for the
according Virtex FPGA".
So this was the motivation for using a cheap device
and to figure out some fancy workarounds for still
supporting partial runtime reconfguration.

If you go through the ReCoBus-Builder tutorial
(available on www.recobus.de) you will recognize the mentioned
"glitching" as an interruption of the video stream
running over the reconfigurable resource slots.
By using two channels that are displaced by one CLB
column (such that there is always a redundant channel),
this effect can be easily masked.
More on this is in our paper "A Communication Architecture
for Complex Runtime Reconfigurable Systems and its
Implementation on Spartan-3 FPGAs".
One remaining issue is that I/O pins cannot be simply
masked.
The lesson of this work is that the full "glitchless"
reconfiguration feature provided in Virtex FPGAs is
not necessary required. But this would require
some additional effort in the tools.
So let us assume that Xilinx may save 1% of the almost
1 billion USD Virtex market by kicking out all not
absolutely required stuff in their high-end
devices, then this is 10 million per annum.
(OK - not considering the cost for the changes - but
still this could be an interesting option for the future)

May be I should make a deal with Xilinx: I do the tool for
5 Million per year and Xilinx may save the rest...

By then, you follow Austin and take a Spartan 3A.
You can request a ReCoBus-Builder version also for this
device. Just drop me a mail: info@recobus.de
(We provide the tool for free, but only for non-commercial
  use; this is why you have to explicitly request support
  for larger Spartan-3 devices or the E/A/AN families.
  Furthermore, we have no boards with A/AN FPGAs - so its
  not tested from our side - but I don't expect any major
  problems.)

And if you have already a Spartan-3 board, you may accept
"glitches", as we do in our lecture on "Reconfigurable
Computing" where students build a partial runtime
reconfigurable System on the Spartan-3 FPGA-Board from
Digilent in just one evening.

Dirk


> 
> If you don't care that the entire frame is set to zeroes before being
> written (you can stop what you are doing, and resume), then you can do
> what you wish.  I suppose this would be just "plain" reconfiguration
> (to configure again).
> 
> More to the point, if you call or email with a problem while
> dynamically reconfiguring Spartan 3, you will be told that dynamic
> reconfiguration is not supported in Spartan 3.
> 
> Austin

Article: 139504
Subject: Virtex-5 DDRII SRAM Calibration Issues
From: "Colin" <cm.howe@hotmail.com>
Date: Wed, 01 Apr 2009 14:54:55 -0500
Links: << >>  << T >>  << A >>
Hi guys,

I'm trying to use a MIG v2.3 generated DDRII SRAM controller to verify our
hardware for a 36 Mb, x18, Burst length 4, GSI SRAM chip. We're using a
Virtex-5 LX110T chip with a 1738 package size.

The design passes stage 1 calibration but hangs during stage 2
calibration. The same behaviour is exhibited when running the controller at
250 MHz or 200 MHz. Both the controller and the SRAM chip in question have
been verified in simulation (memory test and all calibration stages pass).
I had heard that the Xilinx tap controller does not have a large enough
window to allow certain devices to operate with worst case datasheet
timing...

Any thoughts as to what might be occurring?

cheers,
Colin



Article: 139505
Subject: Re: DCM vs PLL
From: halong <ccon67@netscape.net>
Date: Wed, 1 Apr 2009 13:26:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 10:36=A0am, "Symon" <symon_bre...@hotmail.com> wrote:
> "Sharan" <sharan.basa...@gmail.com> wrote in message
>
> news:6374ea0e-4cdb-474a-9cd6-df68f8252302@v15g2000yqn.googlegroups.com...
>
>
>
>
>
> > Hi,
>
> > From the datasheets, it is looks like the only major difference
> > between DCM and PLL is that PLL additionally does jitter filtering.
> > Rest of the features are present in both these macros. So what decides
> > whether one should use a PLL or DCM in FPGA.
>
> > The following are the common features present in both DCM and PLL:
> > 1) frequency synth
> > 2) deskew
> > 3) frequency div
>
> > Additionally DCM can also do phase shift.
>
> > Regards,
> > Sharan
>
> PLL's have a higher potential for failures due tu their non-state-machine
> behaviour.
>
> For Example EMI could disturb some clocks getting into a PLL phase
> detector and you get a lock loss.
>
> Digital DCM's are more tolerant about that and especially if you want
> to have deterministic operation that is not component value dependent you
> are lost with the PLL.
>
> I would always chose a good DCM over analog PLL.- Hide quoted text -
>
> - Show quoted text -

Haha, It rings the bell about the battle between DLL vs. PLL not long
ago. :-)

So far, jitter is the only thing I concern about... so who's the
winner ?


Article: 139506
Subject: Re: Programming Digilent Nexys 2 from Linux
From: =?ISO-8859-1?Q?Ronan_Paix=E3o?= <ronanpaixao@yahoo.com.br>
Date: Wed, 1 Apr 2009 14:23:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 30 mar, 20:46, Andy Ross <andy.ross...@gmail.com> wrote:
> I recently bought a Digilent Nexys 2 board, and after a few days of
> research got to the point where I can successfully program it over USB
> from a Linux host without the use of a separate (and expensive!) JTAG
> interface. =A0Google told me even before I purchased the board that this
> is a very common requirement; it seems that I'm not the only one
> interested in linux-hosted FPGA development. =A0The pieces to make this
> work were all there, happily (see the README in the download below for
> details -- the chain of responsibility here is long); it just took
> work to assemble them correctly.
>
> For those interested, I wrote a quick perl script to automate the
> process, available at: [url]http://plausible.org/andy/nexys2prog.tar.gz
> [/url]
>
> This wraps the multi-step mess (device detection/configuration, SVF
> generation, and JTAG download) as fully as possible, most importantly
> by doing the USB bus enumeration and dynamically reprogramming the
> Nexys 2 with a patched usb_jtag firmware blob in the script itself.
> The user just specifies the Xilinx bitstream file as the sole
> argument.
>
> Installation is as simple as I could make it, requiring only Xilinx
> ISE, two binary packages (fxload and libftdi -- both available via apt-
> get on Ubuntu Intrepid) and one source install (UrJTAG -- just a
> simple "./configure;make;make install" will do).
>
> Hopefully this will help other newbies with the learning curve. =A0Let
> me know if something doesn't work, or if there are questions.

That's great! Any idea if that works for a Nexys (not version 2)? I'm
trying to get it working but so far I wasn't able to. The program
detects if the cable is present or not, and appears to change the
board's firmware somehow, since until the board is powered down, its
lsusb output changes from:
Bus 007 Device 033: ID 1443:0005
to:
Bus 007 Device 034: ID 16c0:06ad VOTI
but the program doesn't show anything else.

Do you have any idea of what's happening, since it appears both the
nexys 1 and 2 have the same programming interface?

Article: 139507
Subject: Switching an AC power socket from an FPGA
From: News123 <news123@free.fr>
Date: Wed, 01 Apr 2009 23:46:08 +0200
Links: << >>  << T >>  << A >>
Hi,

I'd like to control power sockets via an FPGA.
Perhaps one of you in this Forum controlled already power sockets from
an FPGA.
I'm looking for a nice starting point.


I have a Spartan 3A starter kit and wondered about an easy way to switch
a 230V AC socket.

I would be interested in solutions for devices below 100W and devices
below 2000W.


The laziest option would probably a small power plug / socket with
plastic case with all electronic built in and a small connector to
connect a controlling low voltage FPGA / TTL signals.

Does something like this exist already?

Another interesting option would be if anybody knew just a
socket / plug in a small plastic box with a small PCB, which has enough
space to add the required electronic components.


thanks in advance for any suggestions.

Article: 139508
Subject: Re: Programming Digilent Nexys 2 from Linux
From: Andy Ross <andy.ross.or@gmail.com>
Date: Wed, 1 Apr 2009 15:12:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 2:23=A0pm, Ronan Paix=E3o <ronanpai...@yahoo.com.br> wrote:
> Do you have any idea of what's happening, since it appears both the
> nexys 1 and 2 have the same programming interface?

The script was written specifically for the Nexys 2, as obviously
that's all I have available to test with and I'm still new enough at
this stuff (FPGA work, not software development, that is) that I'm
more likely to hurt things than help by guessing at inappropriate
abstractions.  But looking really briefly at the schematics, it seems
like it should work in principle.  The JTAG pinout on the FX2 chip
looks identical, and obviously you're seeing the firmware reload work
successfully.

First off, run the script with a "-v" to enable verbose mode and see
what the underlying error is.

The one thing I see that will need to be changed is the path to the
BDSL files on line 236; the Nexys has (I think) a Spartan 3, not a 3E,
and Xilinx spreads these files out all over their tree.  Try this:

--- nexys2prog
+++ nexys2prog
@@ -233,7 +233,7 @@
 sub play_svf {
     open JTAG, ">$TMPID.jtag" or die "cannot write to $TMPID.jtag";
     # Just the BSDL directories needed for the 2 chips on the
Nexys2...
-    print JTAG "bsdl path $XILINX/spartan3e/data;$XILINX/xcf/data\n";
+    print JTAG "bsdl path $XILINX/spartan3e/data;$XILINX/spartan3/
data;$XILINX/xcf/data\n";
     print JTAG "cable usbblaster\n";
     print JTAG "detect\n";
     print JTAG "part 1\n";

Another potential gotcha is that the iMPACT script generator is
specifying an XCF04S and not the 02 part that seems to be on the
Nexys.  But as this is just being fed a bypass command, I can't see
why it would matter.  And now that I'm understanding JTAG better, I'm
not sure why this chip needs to be specified at all just to generate
SVF, when the real bypass command is actually done by UrJTAG at
runtime...

Let me know how things work out.  Now that I have a better handle on
things and am getting out of the "blind stitchwork" phase, I'm
starting to think about nicer interfaces.  One thing to note is that a
Xilinx bitstream file embeds its part identifier, so there's really no
need to know anything about the board design a priori -- we could just
scan the JTAG bus for a matching part number, regardless of where it
lives on the chain, and program that.  Likewise extending the FX2
interface to handle other known FX2 parts (the KNJN Saxo boards, which
I almost bought, or the Digilent cable), or even arbitrary JTAG
interfaces that can be detected, is possible.

Then again, the whole point here is to allow me to play with FPGAs and
learn something, not do tool integration that won't teach me anything
new. :)

Article: 139509
Subject: Lattice EPIC Logic Block Editor for Slice in CCU2 mode
From: rickman <gnuarm@gmail.com>
Date: Wed, 1 Apr 2009 16:09:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am trying to optimize some code and I am examining parts of the
resulting logic in the Lattice design editor, EPIC.  When I look at
the details of a slice in the logic block editor it provides details
for the LUT data when in logic mode.  But when in ripple mode,
specifically CC2 mode, it doesn't provide logic equations.  You can
examine the "Logic Strings" which seem to provide all the info for the
entire slice configuration including the LUT data.  The part that
controls the LUT seems to be:

CCU2::S0=0x5006,S1=0x3006:INJECT1_0=NO,INJECT1_1=NO

When I try to match the LUT contents (0x5006 and 0x3006) to the
inputs, I can't seem to find a match that makes sense.  I am thinking
I am missing something important in this.

I am expecting the LUT to be used intact even though only three inputs
are used, A, B and Cin (D).  I expect the output to be an Exclusive OR
of all three inputs.  But the logic string doesn't seem to be that and
they are different for the two LUTs in a slice. So what am I
missing?

When searching for CC2 on the Lattice site, I did find some mention
that instead of generating a carry, the slice generates signals
propagate and generate for "fast carry" operation.  But I don't see
any sign of this in EPIC.  The adder is connected as a typical ripply
carry chain with one carry in and one carry out between slices.

I am looking at this, because sometimes other logic seems to be
combined with the adder LUT and I want to understand what they are
doing.

Rick

Article: 139510
Subject: Re: Digital design references for timing, etc.
From: mng <michael.jh.ng@gmail.com>
Date: Wed, 1 Apr 2009 16:29:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 11:04=A0am, wondering.gn...@gmail.com wrote:
> On Apr 1, 8:44=A0am, Koorndyk <kris.koorn...@gmail.com> wrote:
>
>
>
> > On Mar 31, 7:45=A0pm, wondering.gn...@gmail.com wrote:
>
> > > Hi, all.
>
> > > I'm relatively new to the field of digital design, and have completed
> > > a few FPGA-based designs, successfully integrated and debugged them.
> > > Writing HDL, using vendor tools and performing simulations have been
> > > fairly straightforward and within my comfort zone. But now I'm faced
> > > with the foreign task of debugging some nasty timing problems, and I'=
m
> > > realizing how little I understand about some fundamental digital
> > > design principles, like setup and hold timing, clock skew and jitter,
> > > and the like.
>
> > > What books and other resources would you recommend for someone who
> > > needs a better understanding of digital design principles, with a
> > > special focus on timing concerns?
>
> > > Thanks,
> > > The Wondering Gnome
>
> > I've found the latest Xilinx Timing Constraints User Guide to be
> > invaluable.
>
> >www.xilinx.com/itp/xilinx10/books/docs/timing_constraints_ug/timing_c...
>
> Thanks for that -- I've also found Xilinx docs to be particularly
> helpful. But in this case I'm interested in learning about timing
> considerations from first principles; what are the electrical
> engineering considerations (so to speak) that I should be aware of,
> especially with regards to timing. I'm not designing ASICs, but I hope
> to gain that kind of requisite digital design logic. Any
> recommendations on that front?
>
> Regards,
> W.G.

If you're looking for first principles, it sounds like you want a
digital circuit design book. I've never looked at any besides the one
I used in undergrad (Rabaey) but if you search "digital circuit
design" at Amazon or your library you'll have lots of options. Class
notes posted online are also a good place to start.

Cheers,
Mike

Article: 139511
Subject: Re: Switching an AC power socket from an FPGA
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 2 Apr 2009 01:01:35 +0100
Links: << >>  << T >>  << A >>
Can your FPGA send packets?
http://www.digital-loggers.com/lpc.html 



Article: 139512
Subject: Re: Switching an AC power socket from an FPGA
From: -jg <Jim.Granville@gmail.com>
Date: Wed, 1 Apr 2009 17:49:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 2, 9:46=A0am, News123 <news...@free.fr> wrote:
> The laziest option would probably a small power plug / socket with
> plastic case with all electronic built in and a small connector to
> connect a controlling low voltage FPGA / TTL signals.
>
> Does something like this exist already?
>
> Another interesting option would be if anybody knew just a
> socket / plug in a small plastic box with a small PCB, which has enough
> space to add the required electronic components.
>
> thanks in advance for any suggestions.

Remote Controlled mains Outlets perhaps ?
Certainly isolates your FPGA from the Mains!

Article: 139513
Subject: Re: Lattice EPIC Logic Block Editor for Slice in CCU2 mode
From: rickman <gnuarm@gmail.com>
Date: Wed, 1 Apr 2009 17:55:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 7:09=A0pm, rickman <gnu...@gmail.com> wrote:
>
> I am looking at this, because sometimes other logic seems to be
> combined with the adder LUT and I want to understand what they are
> doing.
>
> Rick

I added KEEP attributes to force the logic to be distributed the way I
intended and added a register to the output of the adder.  The
register seems to have been moved to the other side of the adder so
that the inputs to the adder are being registered.  I guess the tool
is free to do that, but when I added a timing constraint to the output
of the adder, rather than move the register to where I asked for it,
the tool just reports a timing violation!

Do I have to add special attributes to get the register where I want
it so that it meets timing constraints?

Rick

Article: 139514
Subject: Re: Programming Digilent Nexys 2 from Linux
From: John Eaton <nospam@spam.com>
Date: Wed, 01 Apr 2009 21:40:40 -0700
Links: << >>  << T >>  << A >>
Andy,

Sure hope this works. I'm tried of having to reboot into windows to burn
code into my boards.

Does this reprogram the 8051? Does that mean if I use it I cannot go 
back and use the digilent adept software?

John Eaton



Andy Ross wrote:
> I recently bought a Digilent Nexys 2 board, and after a few days of
> research got to the point where I can successfully program it over USB
> from a Linux host without the use of a separate (and expensive!) JTAG
> interface.  Google told me even before I purchased the board that this
> is a very common requirement; it seems that I'm not the only one
> interested in linux-hosted FPGA development.  The pieces to make this
> work were all there, happily (see the README in the download below for
> details -- the chain of responsibility here is long); it just took
> work to assemble them correctly.
> 
> For those interested, I wrote a quick perl script to automate the
> process, available at: [url]http://plausible.org/andy/nexys2prog.tar.gz
> [/url]
> 
> This wraps the multi-step mess (device detection/configuration, SVF
> generation, and JTAG download) as fully as possible, most importantly
> by doing the USB bus enumeration and dynamically reprogramming the
> Nexys 2 with a patched usb_jtag firmware blob in the script itself.
> The user just specifies the Xilinx bitstream file as the sole
> argument.
> 
> Installation is as simple as I could make it, requiring only Xilinx
> ISE, two binary packages (fxload and libftdi -- both available via apt-
> get on Ubuntu Intrepid) and one source install (UrJTAG -- just a
> simple "./configure;make;make install" will do).
> 
> Hopefully this will help other newbies with the learning curve.  Let
> me know if something doesn't work, or if there are questions.

Article: 139515
Subject: Re: Programming Digilent Nexys 2 from Linux
From: emeb <ebrombaugh@gmail.com>
Date: Wed, 1 Apr 2009 22:17:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'm pretty sure that the Digilent 8051 code is loaded from flash at
power-up and this process reloads new open-source code from USB which
is lost at the next power down or reset. You should be OK using this
with Adept as long as you cycle power.

Eric

On Apr 1, 9:40=A0pm, John Eaton <nos...@spam.com> wrote:
> Andy,
>
> Sure hope this works. I'm tried of having to reboot into windows to burn
> code into my boards.
>
> Does this reprogram the 8051? Does that mean if I use it I cannot go
> back and use the digilent adept software?
>
> John Eaton
>
> Andy Ross wrote:
> > I recently bought a Digilent Nexys 2 board, and after a few days of
> > research got to the point where I can successfully program it over USB
> > from a Linux host without the use of a separate (and expensive!) JTAG
> > interface. =A0Google told me even before I purchased the board that thi=
s
> > is a very common requirement; it seems that I'm not the only one
> > interested in linux-hosted FPGA development. =A0The pieces to make this
> > work were all there, happily (see the README in the download below for
> > details -- the chain of responsibility here is long); it just took
> > work to assemble them correctly.
>
> > For those interested, I wrote a quick perl script to automate the
> > process, available at: [url]http://plausible.org/andy/nexys2prog.tar.gz
> > [/url]
>
> > This wraps the multi-step mess (device detection/configuration, SVF
> > generation, and JTAG download) as fully as possible, most importantly
> > by doing the USB bus enumeration and dynamically reprogramming the
> > Nexys 2 with a patched usb_jtag firmware blob in the script itself.
> > The user just specifies the Xilinx bitstream file as the sole
> > argument.
>
> > Installation is as simple as I could make it, requiring only Xilinx
> > ISE, two binary packages (fxload and libftdi -- both available via apt-
> > get on Ubuntu Intrepid) and one source install (UrJTAG -- just a
> > simple "./configure;make;make install" will do).
>
> > Hopefully this will help other newbies with the learning curve. =A0Let
> > me know if something doesn't work, or if there are questions.


Article: 139516
Subject: Re: Xilinx partitions vs. smartguide
From: Mike Treseler <mtreseler@gmail.com>
Date: Wed, 01 Apr 2009 22:20:52 -0700
Links: << >>  << T >>  << A >>
stephen.craven@gmail.com wrote:

> Though a long-time Xilinx user, I have yet to try partitions or the
> updated smartguide feature.  I would appreciate your thoughts on these
> features.  Which is best at reducing runtime?

I like simulation.
It doesn't reduce synthesis time,
just the number of repetitions required.

     -- Mike Treseler

Article: 139517
Subject: Re: Switching an AC power socket from an FPGA
From: News123 <news123@free.fr>
Date: Thu, 02 Apr 2009 09:46:28 +0200
Links: << >>  << T >>  << A >>
Thanks for your answer.

Basically I'd like that the FPGA does what the box in your URL is doing,
but without an ethernet protocol.
As means of communication is was looking for ideally  a single GPIO
signal / or at least nothing more complex than a One-Wire / I2C protocol.

Symon wrote:
> Can your FPGA send packets?
> http://www.digital-loggers.com/lpc.html 
> 
> 

Article: 139518
Subject: Re: Switching an AC power socket from an FPGA
From: News123 <news123@free.fr>
Date: Thu, 02 Apr 2009 09:54:05 +0200
Links: << >>  << T >>  << A >>
Hi JG,

-jg wrote:

>>
>> thanks in advance for any suggestions.
> 
> Remote Controlled mains Outlets perhaps ?
> Certainly isolates your FPGA from the Mains!

In fact I was more thinking about the FPGA being next to the socket and
having a simple wired communication.

On the other hand:
remote controlled would also be interesting.
Are there any good, not too expensive sets of remote controlled main
outlets (for 230V Europe) where it would be easy to control the
transmission unit via the FPGA?

preference for wireless protocol wuld then be Zigbee, but the 433 MHz
protocols would be OK as well.


Article: 139519
Subject: delays in XC95144XL CPLD
From: David Fejes <fejesd@gmail.com>
Date: Thu, 2 Apr 2009 01:12:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,

I want to use the XC95144XL CPLD to switching paralell video buses up
to 165Mhz frequency. The logic has only combinatorial parts and there
are no feedbacks from the macrocells output to the FastConnectII
inputs.
It's very important that the signals must have the same delays but I'm
a bit confused with the delays and the timing modells.

I don't use registers or any feedback in my configuration, so I'm
pretty sure that Fsystem is irrelevant to me. The combinatorial delays
are given as Tpdi for different speed grades, but I'm not sure wether
this delay is uniform or not. My Pterms have the same configurations
in all FBs due to the symmetrical topology.

Will it work with a 10 (lowest) speed grade CPLD or not? Shall I use a
faster (and a much more expensive) version or not? What will be the
order of jitters between the paralell signals?

Thank you for the answers
David

PS: timings are available at http://www.xilinx.com/support/documentation/data_sheets/ds056.pdf
p5-p6

Article: 139520
Subject: Re: delays in XC95144XL CPLD
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Thu, 2 Apr 2009 01:18:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 2, 11:12=A0am, David Fejes <fej...@gmail.com> wrote:
> Hello,
>
> I want to use the XC95144XL CPLD to switching paralell video buses up
> to 165Mhz frequency. The logic has only combinatorial parts and there
> are no feedbacks from the macrocells output to the FastConnectII
> inputs.
> It's very important that the signals must have the same delays but I'm
> a bit confused with the delays and the timing modells.
>
> I don't use registers or any feedback in my configuration, so I'm
> pretty sure that Fsystem is irrelevant to me. The combinatorial delays
> are given as Tpdi for different speed grades, but I'm not sure wether
> this delay is uniform or not. My Pterms have the same configurations
> in all FBs due to the symmetrical topology.
>
> Will it work with a 10 (lowest) speed grade CPLD or not? Shall I use a
> faster (and a much more expensive) version or not? What will be the
> order of jitters between the paralell signals?
>
> Thank you for the answers
> David
>
> PS: timings are available athttp://www.xilinx.com/support/documentation/d=
ata_sheets/ds056.pdf
> p5-p6

have you looked the CPLD output signals at 165MHz with a good DSO?
I have. For a project where it was important to generate 120mhz phase
shifted
clocks with an CPLD. as much as i recall i did not like the cpld
output
waveforms what i observed.

running parallel 165mhz datapaths via XC95 doesnt sound like a good
idea
but maybe i am wrong, has happened b4

Antti





Article: 139521
Subject: Maximum frequency
From: knight <krsheshu@gmail.com>
Date: Thu, 2 Apr 2009 02:36:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

Iam using Xilinx XST for synthesis.
Iam using almost 20 modules in my design.
each if i synthesize seperately iam getting a maximum frequency of
more than 400 Mhz. But when i combine everything iam getting
only 121Mhz.

Can you tell me the reason...???
Does this mean i cannot use a clock more than 121 Mhz in my design(iam
using and found it working well..)
How can i increase my timing for high frequencies..??
Iam providing the synthesis report here.
Can you tell me what is the Maximum frequency mentioned here..?

Timing Summary:
---------------
Speed Grade: -1

   Minimum period: 8.226ns (Maximum Frequency: 121.566MHz)
   Minimum input arrival time before clock: 3.043ns
   Maximum output required time after clock: 3.281ns
   Maximum combinational path delay: 2.072ns

I want to acheive minimum 400Mhz for my entire design.... Is it
possible...? That is my target....
Do comment...

Article: 139522
Subject: Re: delays in XC95144XL CPLD
From: David Fejes <fejesd@gmail.com>
Date: Thu, 2 Apr 2009 03:01:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
> running parallel 165mhz datapaths via XC95 doesnt sound like a good
> idea
> but maybe i am wrong, has happened b4

There is a similar application note at the Xilinx webpage in the
xapp944.pdf  It is true that the maximum frequency of the signals is
only 27Mhz in this design and it uses CoolRunnerII instead of XC95,
but there is a interesting sentence at the end of the document:

,,All similar signals travel through the same path in the CPLD, so
they will emerge from the other side with negligible skew, because of
to the deterministic nature of the timing model and architecture."

I think it should be true at higher frequencies too, didn't?

On Apr 2, 10:18=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Apr 2, 11:12=A0am, David Fejes <fej...@gmail.com> wrote:
>
>
>
> > Hello,
>
> > I want to use the XC95144XL CPLD to switching paralell video buses up
> > to 165Mhz frequency. The logic has only combinatorial parts and there
> > are no feedbacks from the macrocells output to the FastConnectII
> > inputs.
> > It's very important that the signals must have the same delays but I'm
> > a bit confused with the delays and the timing modells.
>
> > I don't use registers or any feedback in my configuration, so I'm
> > pretty sure that Fsystem is irrelevant to me. The combinatorial delays
> > are given as Tpdi for different speed grades, but I'm not sure wether
> > this delay is uniform or not. My Pterms have the same configurations
> > in all FBs due to the symmetrical topology.
>
> > Will it work with a 10 (lowest) speed grade CPLD or not? Shall I use a
> > faster (and a much more expensive) version or not? What will be the
> > order of jitters between the paralell signals?
>
> > Thank you for the answers
> > David
>
> > PS: timings are available athttp://www.xilinx.com/support/documentation=
/data_sheets/ds056.pdf
> > p5-p6
>
> have you looked the CPLD output signals at 165MHz with a good DSO?
> I have. For a project where it was important to generate 120mhz phase
> shifted
> clocks with an CPLD. as much as i recall i did not like the cpld
> output
> waveforms what i observed.
>
> running parallel 165mhz datapaths via XC95 doesnt sound like a good
> idea
> but maybe i am wrong, has happened b4
>
> Antti


Article: 139523
Subject: Can I capture the jtag TDO pin of a Spartan3AN
From: fpgauser <klausfpga@gmail.com>
Date: Thu, 2 Apr 2009 03:25:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

 The cell BSCAN_SPARTAN3A allows to monitor the jtag input pins TCK,
TDI and TMS of a Spartan3A chip.

I was curious, whether I would also be able to capture the value of
the TDO pin (without soldering or wiring it back to another pin of the
3AN)

If yes, what would be the trick?

Thanks in advance and bye


Article: 139524
Subject: Re: Can I capture the jtag TDO pin of a Spartan3AN
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Thu, 2 Apr 2009 03:45:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 2, 1:25=A0pm, fpgauser <klausf...@gmail.com> wrote:
> Hi,
>
> =A0The cell BSCAN_SPARTAN3A allows to monitor the jtag input pins TCK,
> TDI and TMS of a Spartan3A chip.
>
> I was curious, whether I would also be able to capture the value of
> the TDO pin (without soldering or wiring it back to another pin of the
> 3AN)
>
> If yes, what would be the trick?
>
> Thanks in advance and bye

No

you only know the TDO value IF the TAP is in USER1/USER2 and DRSCAN
state
but the value is what you shift out, so you would know it anyway...

Antti




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
2017JanFebMarApr2017

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