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 60850

Article: 60850
Subject: Re: Location constraint
From: Christian Schneider <cgs-news@cgschneider.com>
Date: Tue, 23 Sep 2003 21:57:30 +0200
Links: << >>  << T >>  << A >>
Well, you can either put an area constraint on an module (search for 
AREA_GROUP in the manual), or you can put LOC constraints on either 
primitives or modules. So I am afraid you have to put the process into 
an own module.

Chris

Matthias Müller wrote:

> Hello,
> I'm working on a project with XC2V2000 and ISE4.2.
> Does anyone know, if there is a location constraint to locate a SINGLE
> PROCESS on a certain quadrant or slice-range?
> Thank you,
> Matthias
> 


Article: 60851
Subject: Re: Added Keyboard controller to C-NIT
From: do_not_reply_to_this_addr@yahoo.com (Sumit Gupta)
Date: 23 Sep 2003 13:17:04 -0700
Links: << >>  << T >>  << A >>
antti@case2000.com (Antti Lukats) wrote in message news:<80a3aea5.0309230458.3934bcc3@posting.google.com>...
> do_not_reply_to_this_addr@yahoo.com (Sumit Gupta) wrote in message news:<ae680d56.0309230000.265514b4@posting.google.com>...
> > I have added a keyboard controller to my soc implementation.
> > 
> > http://www.c-nit.net
> 
> download of cpu.v and soc.zip are bad links http: 404 not found
> please fix
> 
> antti

Fixed !

Thanks
Sumit

Article: 60852
Subject: Re: Regarding XC6216
From: Neil Franklin <neil@franklin.ch.remove>
Date: 23 Sep 2003 22:25:18 +0200
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> writes:
>
> "H.Azmi" wrote:
> >
> >          Does any body have datasheet for XC6216 ?

> My first answer is: look it up on google. You get 747 hits!

Of course that is just pages which have the 2 pieces of text "6216"
and "data sheet" (or wven "data" and "sheet" separate) on them. Of
course that does not have to be an data sheet for an 6216.

I once got a copy from: http://www.vcc.com/Papers/6200.pdf (at least
my bookmarks say that, in Jan 2001).


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Blacksmith
- hardware runs the world, software controls the hardware
  code generates the software, have you coded today?

Article: 60853
Subject: Re: IEEE 1284 Core for Xilinx
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 23 Sep 2003 15:46:24 -0500
Links: << >>  << T >>  << A >>


James Williams wrote:

>Hello,
>
>Is it possible to get the IEEE 1284 parrallel core for the ISE Webpack?  I
>am just a hobbiest and can't afford to pay thousands for the for release of
>the ISE.  I just want to be have to use the 1284 parrallel interface on my
>device.
>
>
>  
>
This is a slave device?  Do you need the full-scale 1284 protocol for device
recognition, or just the handshaking part of it?  I have built a set of 
devices that
control CNC machine axes using the 1284 handshaking (read encoder position,
compute new velocity, send velocity to DAC or step pulse rate generator).

I get a transfer rate of about 800 nS per byte.  I put an address 
counter in the
device, so consecutive registers can be loaded (or read) without sending 
a new address.

I found the most useful info on the protocol in the data sheets for the SMC
37C665 series of chips.  Note that the chips in motherboards do NOT follow
the Microsoft document on signal timing.  SMC chips send the strobes at
the same time as the data.  UMC chips send the strobes BEFORE the data!
(The standard shows the strobes being delayed by an unstated amount.)

The hardware to control this is trivial.  It fits on one small page of 
schematics,
and can be implemented in small CPLDs, as well as FPGAs.

Jon


Article: 60854
Subject: Re: Regarding XC6216
From: Neil Franklin <neil@franklin.ch.remove>
Date: 23 Sep 2003 23:35:46 +0200
Links: << >>  << T >>  << A >>
"Steve Casselman" <sc_nospam@vcc.com> writes:

> > as much as I know XC6216 is the only Xilinx device that has full public
> > bitstream documentation (or had at least)
>
> I still have a bag of XC6216s. I really wish Xilinx would publish the
> bitstream for the  V2Pro.

Or even just the standard V2 if they want to keep the top of the line
secret (or have some contract with the PPC hard core people).


> I don't get the logic any more the Pro has DES
> encryption so if you want to keep your design secret you can.

That reason is now dead. But they still have an whole large bag of
others. Such crappy things like "binary compatibility hinders us
innovating". Of course any "binary compatible" market would exclude
all not compatible competitors, so maximal innovation simply does
not matter in that market. And yes this means 2 series (binary and
power), so perhaps take the older V1 designs for this (OK, that loses
DES)?


> Maybe it is time to start an open the bitstream project?

Get Xilinx to cooperate with not immediately profit generating (small)
user demands?

Sounds unlikely given present corporate un-culture. It is large
corporations serving (mainly) large-account large corporations, who
could not care for anything other than "what we do today n% more
efficient". Damn the small guys who want to do something different.
Mass manufacturing industry sucks.

Just look how long it take just to get them to deliver their tools for
Linux.


Hmmm, perhaps aim at someone else who wants to expand their lesser
market share?

Ask Altera how many design wins they got from their far earlier
Linux tool availability exploiting Xilinxes stubbornness. Perhaps
they will see public bitstream as an other step in regaining
marketshare.

Or perhaps ask the upcoming 3rd guy Lattice if they want an hot
"accelerator" feature into the market (gain mind share with all the
new entering people). OTOH their "registrate just to see the data
sheets" policy does not point to enlightened people working there.

Or perhaps Actel would like more sales for their ProASIC parts? End of
their underdog status? (I doubt that write-once Antifuse looks good for
the experiment liking sort of people that open bitstreams would attract).


> Anyone got any good
> ideas?

Publicity campaign among open source hackers? Get then to join an
petition at Xilinx (or Altera or Lattice or Actel)? Slashdot?

Everyone of them would understand the implication of processor
instruction sets being closed (= no Linux). Even just 3D graphic
cards and some USB devices being secret is massively annoying. So
the promise of "make your own chip" (= get rid of the crappy pc
architecture, an future OpenPC) and the point about the parts for
that existing but being closed should be easy to get across.


Or some bluesky ideas:

1. Get own (2nd hand?) chip fabrication line and make an OpenFPGA, with
its bitstream (and chip design?) public? :-) Or (better?) even just be
an fabless house and make the FPGA as open-source portable VHDL or EDIF
and then let anyone download and have a batch of FPGAs made at any
ASIC house.

Could even fix some annoying features of todays commercial devices,
such as making an SRAM FPGA (so least demands on ASIC house), but
with separate battery driven VCCCONF, so it needs no config
device/boottime (just like Flash or Antifuse based FPGAs but without
their process/size/speed problems).

Of course damn patents make it illegal to sell chips implementing some
of the newer features (but the basic 4LUT/FF/Mux logic cell and PIP
based routing should be unencumbered until such a chip is ready for
sales). And just design and "produce for own use" may even make that
moot for some users, so make encumbered extra features compile time
selectable.


2. Or perhaps better ditch FPGAs (a method to get custom chips out of
mass manufacturing an single device), and invent some machine that
looks like an laser printer, but prints ASICs? Same as laser printers
do the same job as offset printing machines, but a lot smaller and
cheaper (but far lower output volume and at lower quality).

Perhaps based on ion implanting? Hmm, I need more semiconductor
physics knowledge.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Blacksmith
- hardware runs the world, software controls the hardware
  code generates the software, have you coded today?

Article: 60855
Subject: Re: USB 1.1/2.0 Implementation
From: "SneakerNet" <nospam@nospam.org>
Date: Wed, 24 Sep 2003 09:39:40 +1200
Links: << >>  << T >>  << A >>
"Antti Lukats" <antti@case2000.com> wrote in message
news:80a3aea5.0309222237.7c93ed9a@posting.google.com...
> "SneakerNet" <nospam@nospam.org> wrote in message
news:<fIObb.156268$JA5.3828849@news.xtra.co.nz>...
> > Hi All
> >
> > Has anyone successfully implemented USB 2.0 or USB 1.1 protocol in
Altera
> > Device. If yes, can you pls start me off. I'm not able to make any
progress
> > in this. I have found couple of sites in ths area, but always end
towards a
> > brick wall.
>
> if you dont say what your problem is how could one help?
> the USB cores available are working out of box for Xilinx, for altera
> you need to change the technology dependant portions and it should
> again work.
>
> antti

Hi Antti
Thanks for the response. I actually contacted you regarding USB page that
you mentioned in this newsgroup a while back (Japanese language).
Ok firstly regarding USB implementation, the way I see it, there are 3 major
parts, which are:
1. USB Transceiver (to connect the FPGA and the PC)
2. FPGA Implementation
3. Windows App

Now
1. USB Transceiver - I have found out that the Philips PDIUSBP11A is quite
suitable for this job. However if you look at this pdf (which shows the
circuit connection) www.semiconductors.philips.com/acrobat/
applicationnotes/AN10007-01.pdf  , on page 5 of this pdf there are 2 circuit
diagrams. I'm not able to understand the difference between upstream and
downstream circuits. Pls help/advice.
2. FPGA Implementation - Antti, you replyed saying (for altera you need to
change the technology dependant portions and it should again work.). What do
you mean by this? Help Again. Where can I download the USB cores to begin
with? Once I can get hold of the USB core, I guess I'll have a starting
point.
3. Windows Implementation - I have no clue with regards to windows drivers.
Any help in this matter would be very greatful.

Thanks guys



Article: 60856
Subject: Re: FPGA implementation in (V)HDL
From: Neil Franklin <neil@franklin.ch.remove>
Date: 24 Sep 2003 00:22:54 +0200
Links: << >>  << T >>  << A >>
jetmarc@hotmail.com (jetmarc) writes:

> > a VHDL or Verilog implementation of an FPGA?
>
> I know that somebody started one about 2 years ago, but I can't find
> the bookmark anymore.  The main problem was that the custom FPGA
> needs a custom toolchain, and that makes it a really huge project.

That would have been the:

MPGA - Meta Programmable Gate Array
http://ce.et.tudelft.nl/~reinoud/mpga/README.html


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Blacksmith
- hardware runs the world, software controls the hardware
  code generates the software, have you coded today?

Article: 60857
Subject: Accessing local GSR net of a Spartan-II
From: richieb@rediffmail.com (richie singh)
Date: 23 Sep 2003 17:17:56 -0700
Links: << >>  << T >>  << A >>
Hello Everyone,
I am new to this newsgroup and also relatively new to FPGA design. I
am working with a Spartan-II device and was wondering if the GSR net
could be used to reset the DLL. I know that GSR is asserted when DONE
goes high. Can I somehow have access to the GSR net and use it to also
reset the DLL as DONE goes high. I have also looked at the
STARTUP_SPARTAN2 primitive but dont think that I can use it. Just
wondering if this can be done in HDL...Any ideas???
Thanks to all that reply.
Rich

Article: 60858
Subject: Re: Regarding XC6216
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 23 Sep 2003 17:21:15 -0700
Links: << >>  << T >>  << A >>
If you have experience with google you know to put quotation marks
around : "XC6216 datasheet", and, voila, you get just one hit from a
spanish website:

http://www.ii.uam.es/~laboweb/LabWeb/pdfs/6kconf.pdf

That's the 72-page data sheet.
Isn't google.com great!
Peter Alfke
==================
Neil Franklin wrote:
> 
> Peter Alfke <peter@xilinx.com> writes:
> >
> > "H.Azmi" wrote:
> > >
> > >          Does any body have datasheet for XC6216 ?
> 
> > My first answer is: look it up on google. You get 747 hits!
> 
> Of course that is just pages which have the 2 pieces of text "6216"
> and "data sheet" (or wven "data" and "sheet" separate) on them. Of
> course that does not have to be an data sheet for an 6216.
> 
> I once got a copy from: http://www.vcc.com/Papers/6200.pdf (at least
> my bookmarks say that, in Jan 2001).
> 
> --
> Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
> Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Blacksmith
> - hardware runs the world, software controls the hardware
>   code generates the software, have you coded today?

Article: 60859
Subject: Re: FPGA implementation in (V)HDL
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 23 Sep 2003 17:27:38 -0700
Links: << >>  << T >>  << A >>
No comment...
Peter Alfke

Article: 60860
Subject: Re: Synchronous counter enable pulse length
From: "Vinh Pham" <vinh-pham@hawaii.rr.com>
Date: Wed, 24 Sep 2003 00:32:48 GMT
Links: << >>  << T >>  << A >>
> Is there anything in the physics that encourages this?

It doesn't involve physics and in fact it is pretty straight forward, but
it's hard to understand without a visual diagram to help.  I couldn't find
anything useful on the Web, and no textbook comes to mind.  Dr. Howard
Johnson recommends this book:

"I think John Wakerly covers a lot of good points about metastability in his
book Digital Design Principles and Practices, Prentice-Hall, 1990 (ISBN
0-13-212838-1). He has a nice "ball and hill" description that I find very
helpful."

You could do it yourself by drawing a diagram of two flip-flops.  Connect a
wire from FF#1's Q output to a cloud which represents a variable amount of
delay.  Then hook that cloud to FF#2's D input.  Both flip-flops are
connected to the same clock (you can assume there's zero clock skew).  Now
start drawing (or simulating) waveforms, varying the delay and clock
frequency, to see what conditions cause a setup-time violation and hold-time
violation.

Two things that you should discover is:

1)  A setup-time violation can be fixed either by reducing the delay or
increasing the clock period.

2)  A hold-time violation can ONLY be fixed by ADDING delay.

If designers had to worry about both setup and hold time, we'd have to worry
about minimizing logic delay (so we can meet our performance goals) BUT
having enough logic delay (so we don't violate hold-time).  Even if EDA
tools warned us when we have hold-time violations, what a waste of time
having to go back to fix your logic.  It's better to prevent the violations
by having zero-hold time.  That way instead of worrying about two things
during logic design, I only have to worry about one thing, minimizing logic
levels/delay.

You can have zero hold-time by making sure you have a large enough
clock-to-Q delay, or by adding delay in front of the FF's D input.  The
problem with the first solution is the IO flip-flop of your chip might take
an input from an external register which has clock-to-Q you can't guarantee
without taking time to check.  Once again, we want to minimize the things we
have to worry about, so it's better to add delay to the D input of a
flip-flop.

When you have zero hold-time, what you're doing is increasing your
setup-time, thereby reducing the maximum clock rate your chip can run at.
So your sacrificing some performance for ease of design.  As a designer I
rather have ease of design and peace of mind.

Well I hope that was helpful, and more importantly I hope that it's correct.
I had to give it my best guess because zero hold-time is one of those things
everyone does and uses, but most dont' know why.


Regards,
Vinh Pham



Article: 60861
Subject: Re: Xilinx S3 I/O robustness question
From: symon_brewer@hotmail.com (Symon)
Date: 23 Sep 2003 18:05:42 -0700
Links: << >>  << T >>  << A >>
Hi Rick,
      As a rule of thumb, when the signal's rise time is faster than
1/6th the time for the signal to get to the other end of the trace,
(guess at 170ps/in of track) then you MUST consider the SI
implications. (So for a 1ns rise time, i.e. a normal 'FAST' Xilinx
pin, you can have 1 inch of track before you have to worry about
reflections!) You can find the rise time data in the IBIS files Xilinx
provides on their website. Remember, the frequency of the signal isn't
important, it's the rise time. Leave those pins in 'SLOW' mode
whenever possible!
      As Austin says, the simulation tools are a BIG help here. Those
IC pins drive bloody hard and fast and I would never like to be
relying on the clamp diodes to save the day, this dumps energy into
the supplies and Austin is not joking when he says that ground bounce
is (and will continue to be) a big consideration. There's a reason
Xilinx have gone to the trouble of putting DCI on their devices!
      The receivers warrant the most attention as they can appear as
an open circuit, the drivers have low impedance and so limit
deviations a bit better. It's time to dust off "High-Speed Digital
Design" for some bed time reading! There's a new edition out I
believe? (Just found it:- High-Speed Signal Propagation: Advanced
Black Magic) I also recommend http://www.sigcon.com/ also by Dr.
Howard Johnson. More v. helpful stuff there for free!!
       HTH, cheers, Syms.


rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F70705F.EAB8FBC5@yahoo.com>...
> Hal Murray wrote:
> > 
> > >       The receiver pin is the one that gets the big hit.
> > 
> > So how bad is that hit?  How good are the protection diodes?
> > 
> > If the clamp diodes are any good they will reduce the reflection
> > and make things easier back at the transmitter.
> 
> This is a good question.  So far I have only read people considering the
> S3 chip driving.  What about the case where is is on the receiving end
> of the signal?  
> 
> My designs typically don't consider signal integrity on traces other
> than edge sensitive clock lines and chip enables.  For non-edge
> sensitive signals, I have always treated it a bit like metastability,
> allow some time for the signal to settle out and all will be good by the
> time of the clock edge.  But if we have to consider *every* trace on the
> board for reflections and overshoot, board design can become a
> nightmare!  
> 
> -- 
> 
> Rick "rickman" Collins
> 
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 60862
Subject: Re: FPGA implementation in (V)HDL
From: "Vinh Pham" <vinh-pham@hawaii.rr.com>
Date: Wed, 24 Sep 2003 01:12:18 GMT
Links: << >>  << T >>  << A >>
> The logical thing to do would be to combine this with the previous
> thread, implement a XC6216 on top of a Virtex-II, use the XC6200 tools
> that still exist, and satisfy those folks who can no longer get the
> XC6200 for research purposes...

Heh, someone should implement an Altera architecture on a Virtex  :_D

(not poking fun at the idea of a meta FPGA, of course)


Regards,
Vinh Pham



Article: 60863
Subject: Re: FPGA implementation in (V)HDL
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Wed, 24 Sep 2003 11:13:26 +1000
Links: << >>  << T >>  << A >>
Brian Drummond wrote:
> On 22 Sep 2003 12:15:59 -0700, jetmarc@hotmail.com (jetmarc) wrote:
> 
> 
>>>a VHDL or Verilog implementation of an FPGA?
>>
>>I know that somebody started one about 2 years ago, but I can't find
>>the bookmark anymore.  The main problem was that the custom FPGA
>>needs a custom toolchain, and that makes it a really huge project.
>>
>>Marc
> 
> 
> The logical thing to do would be to combine this with the previous
> thread, implement a XC6216 on top of a Virtex-II, use the XC6200 tools
> that still exist, and satisfy those folks who can no longer get the
> XC6200 for research purposes...

That's a great idea...

John


Article: 60864
Subject: Re: ISE 6.1 and Redhat 9
From: "Matt" <bielstein2002@comcast.net>
Date: Wed, 24 Sep 2003 03:14:28 GMT
Links: << >>  << T >>  << A >>
Hehe... okay, let me rephrase. Have you noted any performance differences
relative to your Windows experiences? Good and bad. I promise not to call it
a benchmark! ;-)

I haven't had the opportunity to try the Linux version yet. --Matt



"Hans" <hansydelm@no-spam-ntlworld.com> wrote in message
news:CIWab.308$Ne.985132@newsfep2-win.server.ntli.net...
> Hi Matt,
>
> No I haven't (too busy). Also you know what they say about benchmarks
"Lies,
> Damn Lies and Benchmarks :-)
>
> Hans.
>
> "Matt" <bielstein2002@comcast.net> wrote in message
> news:SMPab.521826$YN5.347243@sccrnsc01...
> > Question... have you done any benchmarks for performance relative to
> > Windows? (Synthesis/Translate/Map/PAR) Same or similar hardware would be
> > best.
> >
> > Thanks in advance!
> >
> > "Hans" <hansydelm@no-spam-ntlworld.com> wrote in message
> > news:1nzab.364$4G3.59567@newsfep2-gui.server.ntli.net...
> > > Try (bash),
> > >
> > > export LD_ASSUME_KERNEL=2.4.1
> > >
> > > It runs fine on my RH9,
> > > Hans.
> > > www.ht-lab.com
> > >
> > > "Garry Allen" <garrya@ihug.com.au> wrote in message
> > > news:3abc4240.0309181808.3e1b9cbc@posting.google.com...
> > > > I am very thankful that Xilinx is now supporting Linux directly in
> > > > ISE6.1. However, out of the box it only directly supports Redhat 7.3
> > > > and Redhat 8. Has anyone managed to install it under Redhat 9 and
what
> > > > if anything did you need to do to get it to call the glibc libraries
> > > > successfully?
> > > >
> > > > At the moment when I run ./setup, it fails with an error msssage
> > > > stating that it cannot find the glibc libraries. I am unsure if I
can
> > > > run multiple versions of the gcc compiler
> > > > Comments
> > > > Thanks
> > > > Garry Allen
> > >
> > >
> >
> >
>
>



Article: 60865
Subject: Re: USB 1.1/2.0 Implementation
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 23 Sep 2003 23:24:49 -0400
Links: << >>  << T >>  << A >>
SneakerNet wrote:
> 
> "Antti Lukats" <antti@case2000.com> wrote in message
> news:80a3aea5.0309222237.7c93ed9a@posting.google.com...
> > "SneakerNet" <nospam@nospam.org> wrote in message
> news:<fIObb.156268$JA5.3828849@news.xtra.co.nz>...
> > > Hi All
> > >
> > > Has anyone successfully implemented USB 2.0 or USB 1.1 protocol in
> Altera
> > > Device. If yes, can you pls start me off. I'm not able to make any
> progress
> > > in this. I have found couple of sites in ths area, but always end
> towards a
> > > brick wall.
> >
> > if you dont say what your problem is how could one help?
> > the USB cores available are working out of box for Xilinx, for altera
> > you need to change the technology dependant portions and it should
> > again work.
> >
> > antti
> 
> Hi Antti
> Thanks for the response. I actually contacted you regarding USB page that
> you mentioned in this newsgroup a while back (Japanese language).
> Ok firstly regarding USB implementation, the way I see it, there are 3 major
> parts, which are:
> 1. USB Transceiver (to connect the FPGA and the PC)
> 2. FPGA Implementation
> 3. Windows App
> 
> Now
> 1. USB Transceiver - I have found out that the Philips PDIUSBP11A is quite
> suitable for this job. However if you look at this pdf (which shows the
> circuit connection) www.semiconductors.philips.com/acrobat/
> applicationnotes/AN10007-01.pdf  , on page 5 of this pdf there are 2 circuit
> diagrams. I'm not able to understand the difference between upstream and
> downstream circuits. Pls help/advice.

I have not looked at the circuits, but upstream is closer to the PC and
so is a "host" type connection while downstream is closer to (or is) the
peripheral.  I think there are only very small differences having to do
with initialization protocol.  


> 2. FPGA Implementation - Antti, you replyed saying (for altera you need to
> change the technology dependant portions and it should again work.). What do
> you mean by this? Help Again. Where can I download the USB cores to begin
> with? Once I can get hold of the USB core, I guess I'll have a starting
> point.

I think he was saying that he is aware of IP that works in the Xilinx
chips and so would work in any other FPGA.  But the coding style may
have used chip specific features (like the 16 bit SRL in the Xilinx
parts).  If so, this code may need to be changed to something more
generic for an Altera part.  Any Xilinx features that are instantiated
will need to be replaced for sure.  

Check www.opencores.org.  They have USB 1.1 and 2.0 implementations
available.  I don't know if they are vendor specific or not.  


> 3. Windows Implementation - I have no clue with regards to windows drivers.
> Any help in this matter would be very greatful.

This depends on your application.  I believe there is a generic set of
drivers to support a "human interface device" or similar which means it
works like a mouse or keyboard in terms of sending data in small
packets.  

Again, I am not directly experienced with this, but I have been
listening intently when others discuss this here and elsewhere.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 60866
Subject: Re: USB 1.1/2.0 Implementation
From: "SneakerNet" <nospam@nospam.org>
Date: Wed, 24 Sep 2003 15:32:29 +1200
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3F710E81.AB8E310F@yahoo.com...
> SneakerNet wrote:
> >
> > "Antti Lukats" <antti@case2000.com> wrote in message
> > news:80a3aea5.0309222237.7c93ed9a@posting.google.com...
> > > "SneakerNet" <nospam@nospam.org> wrote in message
> > news:<fIObb.156268$JA5.3828849@news.xtra.co.nz>...
> > > > Hi All
> > > >
> > > > Has anyone successfully implemented USB 2.0 or USB 1.1 protocol in
> > Altera
> > > > Device. If yes, can you pls start me off. I'm not able to make any
> > progress
> > > > in this. I have found couple of sites in ths area, but always end
> > towards a
> > > > brick wall.
> > >
> > > if you dont say what your problem is how could one help?
> > > the USB cores available are working out of box for Xilinx, for altera
> > > you need to change the technology dependant portions and it should
> > > again work.
> > >
> > > antti
> >
> > Hi Antti
> > Thanks for the response. I actually contacted you regarding USB page
that
> > you mentioned in this newsgroup a while back (Japanese language).
> > Ok firstly regarding USB implementation, the way I see it, there are 3
major
> > parts, which are:
> > 1. USB Transceiver (to connect the FPGA and the PC)
> > 2. FPGA Implementation
> > 3. Windows App
> >
> > Now
> > 1. USB Transceiver - I have found out that the Philips PDIUSBP11A is
quite
> > suitable for this job. However if you look at this pdf (which shows the
> > circuit connection) www.semiconductors.philips.com/acrobat/
> > applicationnotes/AN10007-01.pdf  , on page 5 of this pdf there are 2
circuit
> > diagrams. I'm not able to understand the difference between upstream and
> > downstream circuits. Pls help/advice.
>
> I have not looked at the circuits, but upstream is closer to the PC and
> so is a "host" type connection while downstream is closer to (or is) the
> peripheral.  I think there are only very small differences having to do
> with initialization protocol.

Thanks for the clarification.

>
>
> > 2. FPGA Implementation - Antti, you replyed saying (for altera you need
to
> > change the technology dependant portions and it should again work.).
What do
> > you mean by this? Help Again. Where can I download the USB cores to
begin
> > with? Once I can get hold of the USB core, I guess I'll have a starting
> > point.
>
> I think he was saying that he is aware of IP that works in the Xilinx
> chips and so would work in any other FPGA.  But the coding style may
> have used chip specific features (like the 16 bit SRL in the Xilinx
> parts).  If so, this code may need to be changed to something more
> generic for an Altera part.  Any Xilinx features that are instantiated
> will need to be replaced for sure.
>
> Check www.opencores.org.  They have USB 1.1 and 2.0 implementations
> available.  I don't know if they are vendor specific or not.
>

Err.. I found this usb_phy from opencores.org however I'm struggling with
that. The main top layer file has so many I/O's compared to the I/Os of the
PDIUSBP11A, i'm stuck. I'm stuck in the sense that I do not know which pin
will map which one on the transcevier.

>
> > 3. Windows Implementation - I have no clue with regards to windows
drivers.
> > Any help in this matter would be very greatful.
>
> This depends on your application.  I believe there is a generic set of
> drivers to support a "human interface device" or similar which means it
> works like a mouse or keyboard in terms of sending data in small
> packets.
>
> Again, I am not directly experienced with this, but I have been
> listening intently when others discuss this here and elsewhere.

Sigh.. I guess I'll join you ..

Thanks for your input.

>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX



Article: 60867
Subject: Re: Xilinx S3 I/O robustness question
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 23 Sep 2003 23:37:01 -0400
Links: << >>  << T >>  << A >>
Symon wrote:
> 
> Hi Rick,
>       As a rule of thumb, when the signal's rise time is faster than
> 1/6th the time for the signal to get to the other end of the trace,
> (guess at 170ps/in of track) then you MUST consider the SI
> implications. (So for a 1ns rise time, i.e. a normal 'FAST' Xilinx
> pin, you can have 1 inch of track before you have to worry about
> reflections!) You can find the rise time data in the IBIS files Xilinx
> provides on their website. Remember, the frequency of the signal isn't
> important, it's the rise time. Leave those pins in 'SLOW' mode
> whenever possible!

But your use of the term "must" is not totally accurate.  The numbers
you give are a good rule of thumb for when reflections will be
significant to the signal waveform, but that does not automatically
indicate a problem will be created.  A data line can bounce around for
an extra ns or two and won't matter if there is extra time in the
setup.  Up until now I have not seen a chip rated to exclude ringing or
overshoot (or undershoot) because of damage.  In fact, most data sheets
specifically say that this will not be a problem if it only persists for
a few ns.  


>       As Austin says, the simulation tools are a BIG help here. Those
> IC pins drive bloody hard and fast and I would never like to be
> relying on the clamp diodes to save the day, this dumps energy into
> the supplies and Austin is not joking when he says that ground bounce
> is (and will continue to be) a big consideration. There's a reason
> Xilinx have gone to the trouble of putting DCI on their devices!

I have not heard of ringing being the cause of ground bounce.  My
experience has been that ground bounce is caused by the initial current
slug when an output changes state, not the result of a reflection from
the other end.  As the numbers that have been posted in this thread have
indicated, the reflection current is much smaller than the initial
slug.  


>       The receivers warrant the most attention as they can appear as
> an open circuit, the drivers have low impedance and so limit
> deviations a bit better. It's time to dust off "High-Speed Digital
> Design" for some bed time reading! There's a new edition out I
> believe? (Just found it:- High-Speed Signal Propagation: Advanced
> Black Magic) I also recommend http://www.sigcon.com/ also by Dr.
> Howard Johnson. More v. helpful stuff there for free!!
>        HTH, cheers, Syms.

If I actually have to simulate every signal on the board I am designing,
it may never get done.  I think there is something wrong with the idea
that this is a overly complex issue and can't be dealt with in a simpler
manner.  Or am I missing something of what you are saying?  


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 60868
Subject: Re: Xilinx Parallel Cable 4 (PC4) and Platform Flash JTAG
From: antti@case2000.com (Antti Lukats)
Date: 23 Sep 2003 22:51:30 -0700
Links: << >>  << T >>  << A >>
Chen Wei Tseng <chenwei.tseng@xilinx.com> wrote in message news:<bkpv3j$1f51@cliff.xsj.xilinx.com>...
> Antti,
[snip]
> - Thanks for your suggestions in this e-mail thread. Please don't 
> hesitate to open a case with the Xilinx hotline for other additional 
> suggestions that you have for iMPACT to make it a more user-friendly tool.
> 
> Regards, Wei
> Xilinx Applications

one word XHWIF
two words iMpact + XHWIF

in other words publish some (any) API to talk to Cable IV (and all upcoming
new cables) it could be xilinx XHWIF API, could be something else. 
but some API should be available.

thats it. dont see a point opening a webcase on that?
or dont see xilinx could close the webcase :)

antti
PS 6.1 is released, but it looks that Foundation 5.2 users can not
upgrade what is a realy pity :(
as is pity that Chipscope 5.1 users cant upgrade to Chipscope 5.2
(small things you dont know until you buy xilinx software)

Article: 60869
Subject: Re: Regarding XC6216
From: antti@case2000.com (Antti Lukats)
Date: 23 Sep 2003 23:00:55 -0700
Links: << >>  << T >>  << A >>
"Steve Casselman" <sc_nospam@vcc.com> wrote in message news:<bFZbb.9$AJ4.225483@newssvr14.news.prodigy.com>...
> > as much as I know XC6216 is the only Xilinx device that has full public
> > bitstream documentation (or had at least) also for XC6216 there is
> > free JERC6K JBits system inclusive Java sources still downloadable
> > from xilinx download site :)
> >
> > so there are historic and educational reasons to have XC6216, if
> > I would have that board would use it for P&R tool testing, as
> > bitstream is known and array is relativly simple.
> >
> 
> I still have a bag of XC6216s. I really wish Xilinx would publish the
> bitstream for the  V2Pro. I don't get the logic any more the Pro has DES
> encryption so if you want to keep your design secret you can.
> 
> Maybe it is time to start an open the bitstream project? Anyone got any good
> ideas?

Its already started
http://www.openchip.org

the main website is not yet open, but work is in progress :)
could you consider donating that bag of XC6216's to openchip project?
there are things you could get in return.

please contact me as antti@openchip.org

antti

PS there isnt much to show yet
http://www.graphord.com/proj/ChipDesigner/mpga.html

this is MPGA SVG viewer, similar could be made with no big effort
for XC6216 it would instantly spit out bitstream from the web based
editor interface.

sure a fitter tool would be needed for real desing fitting but thats
also work in progress :)

Article: 60870
Subject: Re: FPGA implementation in (V)HDL
From: antti@case2000.com (Antti Lukats)
Date: 23 Sep 2003 23:18:17 -0700
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote in message news:<3F70E4F9.2A7A642D@xilinx.com>...
> No comment...
> Peter Alfke

Hi Peter,

this is something, I mean if someone (like you) doesnt hold it back
to say 'no comments' it means something, need to figure out what :)

FYI

MPGA Meta Gate array 

pure Xilinx SRL16 oriented design,

1 MPGA cell = 1 Virtex slice
bitstream is prepared as ASCII chart that can be directly downloaded!
yes you have ASCII chart you edit it and download to FPGA

KRPAN (OC embedded FPGA)

this is very similar to Algotronix CAL1024 with little bit enhanced
interconnect and cell architecture

1 KRPAN cell is approx 26 Virtex slices

KRPAN comes with verilog to bitstream tool that does map place and route
(simulated annealing), it also has some Floorplanner, software is written
100% in Java and does work.

both the cell sized indicated for fpga-fpga include bitstream programmin
interface.

antti@openchip.org

I wonder if your comment is still no comment?
guess it is.
me smiling here :)

Article: 60871
Subject: Re: IEEE 1284 Core for Xilinx
From: antti@case2000.com (Antti Lukats)
Date: 23 Sep 2003 23:53:40 -0700
Links: << >>  << T >>  << A >>
"James Williams" <james@williams-eng.com> wrote in message news:<bkpq2c$d4aa$1@news3.infoave.net>...
> Hello,
> 
> Is it possible to get the IEEE 1284 parrallel core for the ISE Webpack?  I
> am just a hobbiest and can't afford to pay thousands for the for release of
> the ISE.  I just want to be have to use the 1284 parrallel interface on my
> device.

what you mean you cant afford ISE (full release) there is no difference
if you use ISE or ISE Webpack in this case.

a full IEEE1284 peripheral core is available from japanese site
it did show the windows parallel port enumaration screen i.e. the
parallel port device is recognized as plug and play and displays
manufacturer info.

unfortunatly I cant find the link any more :(
it wasnt of interest for me so I forgot.

but for simple handshaking its not hard to hand-craft it from scratch

antti

Article: 60872
Subject: Regulator for Spartan 2
From: shabana_rizvi@yahoo.com (rider)
Date: 24 Sep 2003 00:34:25 -0700
Links: << >>  << T >>  << A >>
Hi !

Thanks for the great help offered by the group to our FPGA issues.
This time the queries are:

1) I am planning to use a LM317(National Semi) Regulator to power my
board having Spartan2 XC2S150 and some other TTL Ics. Would this
regulator be able to provide the required POS current [power on surge
current] for the FPGA? What current rating is recommended? 2A or more?
If this is not good, which regulator would be OK?

2)I have a 20MHz clock in my design that is used in some flip flops in
the design. Most of the circuit is combinational and with about 18
combinational clocks. What bypass capacitor ratings would be OK for my
design .01uf would be OK?

3)In XST 5.1i , there is a synthesis option which says "Add I/O
buffers". Does that mean that if i check this option, the XST would
automatically insert I/O buffers[IBUF,OBUF,IBUFG,OBUFT etc] into my
top-level module ports and i don't have to instantiate these I/O
buffers into my HDL code?

Thanks
Rider

Article: 60873
Subject: Re: IEEE 1284 Core for Xilinx
From: antti@case2000.com (Antti Lukats)
Date: 24 Sep 2003 00:39:21 -0700
Links: << >>  << T >>  << A >>
"James Williams" <james@williams-eng.com> wrote in message news:<bkpq2c$d4aa$1@news3.infoave.net>...
> Hello,
> 
> Is it possible to get the IEEE 1284 parrallel core for the ISE Webpack?  I
> am just a hobbiest and can't afford to pay thousands for the for release of
> the ISE.  I just want to be have to use the 1284 parrallel interface on my
> device.

http://www.nahitech.com/nahitafu/fpgavhdl/index.html

there are 2 links to IEEE1284 vhdl for xilinx :)
found it

google: IEEE1284 FPGA
:)

antti

Article: 60874
Subject: Re: Synchronous counter enable pulse length
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Wed, 24 Sep 2003 08:02:40 GMT
Links: << >>  << T >>  << A >>

"Vinh Pham" <vinh-pham@hawaii.rr.com> wrote in message
news:QC5cb.1055$Ak3.463@twister.socal.rr.com...
> > Is there anything in the physics that encourages this?
>
> It doesn't involve physics and in fact it is pretty straight forward, but
> it's hard to understand without a visual diagram to help.  I couldn't find
> anything useful on the Web, and no textbook comes to mind.  Dr. Howard
> Johnson recommends this book:
>
> "I think John Wakerly covers a lot of good points about metastability in
his
> book Digital Design Principles and Practices, Prentice-Hall, 1990 (ISBN
> 0-13-212838-1). He has a nice "ball and hill" description that I find very
> helpful."
>
> You could do it yourself by drawing a diagram of two flip-flops.  Connect
a
> wire from FF#1's Q output to a cloud which represents a variable amount of
> delay.  Then hook that cloud to FF#2's D input.  Both flip-flops are
> connected to the same clock (you can assume there's zero clock skew).  Now
> start drawing (or simulating) waveforms, varying the delay and clock
> frequency, to see what conditions cause a setup-time violation and
hold-time
> violation.

It was more obvious to me connecting Qbar to D of the same FF.  Then there
is no question about clock skew.

> Two things that you should discover is:
>
> 1)  A setup-time violation can be fixed either by reducing the delay or
> increasing the clock period.
>
> 2)  A hold-time violation can ONLY be fixed by ADDING delay.
>
> If designers had to worry about both setup and hold time, we'd have to
worry
> about minimizing logic delay (so we can meet our performance goals) BUT
> having enough logic delay (so we don't violate hold-time).  Even if EDA
> tools warned us when we have hold-time violations, what a waste of time
> having to go back to fix your logic.  It's better to prevent the
violations
> by having zero-hold time.  That way instead of worrying about two things
> during logic design, I only have to worry about one thing, minimizing
logic
> levels/delay.

But if there is clock skew, then even zero hold time isn't good enough.  You
can't make it too easy.

> You can have zero hold-time by making sure you have a large enough
> clock-to-Q delay, or by adding delay in front of the FF's D input.  The
> problem with the first solution is the IO flip-flop of your chip might
take
> an input from an external register which has clock-to-Q you can't
guarantee
> without taking time to check.  Once again, we want to minimize the things
we
> have to worry about, so it's better to add delay to the D input of a
> flip-flop.
>
> When you have zero hold-time, what you're doing is increasing your
> setup-time, thereby reducing the maximum clock rate your chip can run at.
> So your sacrificing some performance for ease of design.  As a designer I
> rather have ease of design and peace of mind.

Not so long ago I was reading about the design of pipelined computers.   In
most cases there should be enough logic never to have to worry about hold
time, but in some cases FF's are wired with no logic in between.  Then you
might need to add some to be sure.  There is also a design for a combination
latch and two level of logic.  That helps in allowing faster clocks for the
amount of logic per pipeline stage.

> Well I hope that was helpful, and more importantly I hope that it's
correct.
> I had to give it my best guess because zero hold-time is one of those
things
> everyone does and uses, but most dont' know why.

-- glen





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