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 60175

Article: 60175
Subject: Re: Schematic simulation and then FPGA programming?
From: Ray Andraka <ray@andraka.com>
Date: Sat, 06 Sep 2003 18:48:51 -0400
Links: << >>  << T >>  << A >>
I'm not sure I agree with HDL offering no advantage.  Let me preface first by
stating that I was a long time holdout prefering schematics (viewlogic) over
HDLs.
I changed to HDLs when they finally provided enough controls to permit me to
do the RLOCing (placement) that I was doing with schematics, partly because the
tools were starting to not support schematics, partly because customers insisted
on
HDLS, and partly because of superior macro generation capabilities.  HDLs do
give
a couple of distinct advantages:

1) you can read the source with a generic text editor.  After getting stuck on
old
designs that needed updates and finding the schematic program (viewlogic)
data base format or libraries had changed it was refreshing not to have the
right
version of reader to be able to look at an archived design.  This is
particularly
important for archived designs.

2) For portions of the design where time to completion is critical and
performance
or density is not, the ability to synthesize from higher level code is nice to
have.  This
is particularly true with state machines.

3) The ability to mix high level language style programming with hardware
description
is very helpful for writing testbenches for simulating the circuit.  Because of
this
ability, it is much easier to write testbenches that simulate the circuit both
more
realistically and more completely than is possible within a reasonable amount of
time
using strictly schematic tools.

4) Parameterized construction reduces the size of libraries, as well as the
effort
required to maintain them.  For example, with an HDL, you can have a macro
automatically size the logic to the width of either the inputs or outputs rather
than
having a different library element for each width or function variation (eg.
signed
vs. unsigned adders).  This is particularly helpful if you are using the HDL as
a placed macro generator, as the RLOC values are generated within the code.

The major disadvantage to HDLs is that it can be harder to interpret, especially
with
data path designs constructed from primitives rather than inferred logic.  Much
of that
difficulty can be worked around using one of the HDL to schematic viewer tools,
even though the results from those are less than perfect.




Patrick MacGregor wrote:

> I can sympathize.  I was in a multi-day argument thread a couple months back
> with an HDL zealot.  I, too, am a schematic based designer primarily because
> the currently trendy methods offer no advantages, and have numerous
> down-sides (like creating legions of people calling themselves "designers"
> who have no idea how the circuit they described in software is actually
> implemented).
>
> But, that is a very stale argument.  Both camps like what they like.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 60176
Subject: Stratix pricing
From: "Jerry" <nospam@nowhere.com>
Date: Sat, 6 Sep 2003 21:45:48 -0400
Links: << >>  << T >>  << A >>
We got a quote of around $4k for a EP1S80 from Altera. Yes small quantities.
Anybody getting them for much less, say sub $500?

Tks
Jerry






Article: 60177
Subject: Re: Schematic simulation and then FPGA programming?
From: tom1@launchbird.com (Tom Hawkins)
Date: 6 Sep 2003 21:51:37 -0700
Links: << >>  << T >>  << A >>
INVALIDANTISPAM@aol.com (John K.) wrote in message 
> 
> I think in a "object oriented" way.. for example, I make Flip-Flops from
> NAND gates. So I get a Flip-Flop object. I make registers/latches from
> Flip-Flops, so I get a Latch object. I mean, complexity can naturally
> get encapsulated and encapsulated, till you have a whole ALU, or a whole
> processor, etc.. and your schematic always looks simple (circuits and
> subcircuits encapsulated into virtual devices).
> I don't have much experience with current schematic software (I used
> mostly my own.. nothing fancy anyway, but worked well for encapsulating
> at least), but I see no reason why schematic based (using macros) should
> be any slower or more confusing than HDLs?

All real hardware engineers design with schematics.  Sometimes they're
use your method, but more often than not, schematics take the form of
sketches on bar napkins from which the designer codes HDL.  My point
is schematics and HDL are not two independent design methods.  Good
designers use both together.  Here's what I do:

  1. Draw up a design using paper, Visio, or whatever works.  (I've
found Simulink is the best dataflow block diagram editor around.)

  2. Then translate the schemtic to HDL (or better yet, CF).  Maintain
the same structure, hierarchy, and connections.

With this approach, you use a very small subset of HDL (Verilog
recommended), which is sure to pass through any simulation or
synthesis tool without complaints (Icarus recommended).  The
translation process from schematic to HDL actually goes very quickly. 
Once you get the hang of it, you start doing step 1 in your head.

(I've got a small list of structural HDL coding guidelines, if
interested.)

BTW, please don't code FPGA flip-flops as a pair of NAND gates. :-)

> 
> I can only think about one problem: simulation gets slower and slower.
> But neither this must be true: if simulating a whole Latch via NAND
> gates may be slow, after I know it works well and I have its timing
> characteristics known, I can encapsulate also them into the "black
> box" and simulation of a Latch will be very quick.. having just to
> simulate the function (and delays) from input to output.
> 
> HDL's IMHO are very confusing, hardware wise. A schematic is much more
> natural and intuitive. IMHO of course.

Totally agree.  I need to see boxes and lines before I can make sense
of it.

> 
> On the other hand the non-intuitive, too abstract HDLs will make you
> design things that then in silicon are very inefficient.. will not
> give you a good "big, real picture" of what you're doing, etc..

Commerical level HDL coding is always at RTL.  The same level as your
schematics.  If you stick with structural HDL coding, you'll know
exactly what's going on.  Golden rule: Never, ever, code HDL as a
sequential software program (else crap in = crap out).

Regards,
Tom

--
Tom Hawkins
Launchbird Design Systems, Inc.
952-200-3790
http://www.launchbird.com/

Article: 60178
Subject: Re: Disable Pull up
From: fabrizio@planet1.it (Master)
Date: 7 Sep 2003 02:19:36 -0700
Links: << >>  << T >>  << A >>
I have invert logic of the buffer drive, but he is not changed null.
then I have realized a component that, when the buffer is in tristate
mode,it imposes the intentional level.it works correctly.

Regards
Fabrizio




"John_H" <johnhandwork@mail.com> wrote in message news:<nK26b.35$X11.9145@news-west.eli.net>...
> Spartan-II internal tristates are different than Spartan-II IOB tristates.
> 
> IOB tristates to the outside world have user programmable pullups.
> 
> Spartan-II internal tristates are tristate emulators, not actual tristate
> lines.  I'm having trouble finding the datasheet reference, but the behavior
> is "like" there is a pullup with strong low drivers.  When there are no
> drivers, the state is high.  When there are multiple drivers with
> conflicting states, the part does not smoke but instead gives a logic low.
> If you need a logic low when there are no drivers, either add the additional
> circuitry to drive a logic low when no selects are active *or* invert the
> logic so your re-inverted TBUF defaults to low when there are no drivers and
> settles conflicts with a logic-high.
> 
> 
> "Master" <fabrizio@planet1.it> wrote in message
> news:d9da09be.0309050300.51dba2b2@posting.google.com...
> > "Giuseppe³" <miaooaim@inwind.it> wrote in message
>  news:<bj9a6r$gfbou$1@ID-61213.news.uni-berlin.de>...
> > > I don't sure to undestood your question but using the M0-M1-M2 pins is
>  not
> > > the right way to do what you want?
> > >
> > > Regards
> > > Giuseppe
> > >
> > > "master" <ff@pla.it> ha scritto nel messaggio
> > > news:iMM5b.292163$Ny5.9019956@twister2.libero.it...
> > > > Someone knows like turn off the  "pull up" that the family "spartan2"
> > > > connects for default to " tristate" placed inner lines in, from buffer
>  "
> > > > Tbuf"?
> > > > I use "Xilinx ISE 4.1ģ" and  language "vhdl".
> > > > thanks
> > > >
> > > >
> >
> > excuse me for the little clear english.
> > I reformulate the question.
> >
> > I use tool ise 4,1ģ, family spartan2 and language vhdl . When I
> > synthetize a project that uses internal buffer tristate (tbuf), Pull
> > up component have been connected to buffer output for default. I would
> > want to disable this option and to put on the buffer output some pull
> > up or pull down to my choice. Does some environment variable or some
> > procedure exist in order to make that?
> >
> > thanks

Article: 60179
Subject: Re: VGA display
From: "Abby" <abhigayl@hotmail.com>
Date: Sun, 07 Sep 2003 10:06:13 GMT
Links: << >>  << T >>  << A >>

"cfk" <cfk_alter_ego@pacbell.net> ha scritto nel messaggio news:L8t6b.10410


Thank you very much Charles!!!
I will try to search for some of titles you said to me.
I hope to solve my problem.






Article: 60180
Subject: CMOS camera w/ USB2 -- crazy?
From: "GB" <donotspam_grantbt@jps.net>
Date: Sun, 07 Sep 2003 15:03:39 GMT
Links: << >>  << T >>  << A >>
Hi,

I'm a firmware guy pulled into a project well out of my area of
expertise.  My boss wants to build (essentially) a digital camera
using an image sensor chip (1600x1200) and output it's data
"as fast as possible" using USB2.0.  His initial concept, being
that I'm a firmware guy, was to use a "really fast micro."
Normally the company is involved with small 8-bitter micro
projects, so you can see I'm well out of my normal bounds.

Now this seems like a pretty big stretch to me... and I don't see
how it can be done without the speed of hardware (the image
chips all seem to have clock speeds in the tens of MHz and the
USB2 transfer rate is 480Mbps (theor.).  Do aspects of this
project require an FPGA to keep the data "as fast as possible?"
If we use and FPGA for camera-to-RAM and then use a
 micro for the USB2 part, what kind of fast micros can
move data at that rate?

Also, this is something that I am sure we will have to contract
out, so if you have any past experience with this, please let
me know your thoughts (and if you are available).

Thanks!



Article: 60181
Subject: Re: CMOS camera w/ USB2 -- crazy?
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 07 Sep 2003 11:33:00 -0400
Links: << >>  << T >>  << A >>
GB wrote:
> 
> Hi,
> 
> I'm a firmware guy pulled into a project well out of my area of
> expertise.  My boss wants to build (essentially) a digital camera
> using an image sensor chip (1600x1200) and output it's data
> "as fast as possible" using USB2.0.  His initial concept, being
> that I'm a firmware guy, was to use a "really fast micro."
> Normally the company is involved with small 8-bitter micro
> projects, so you can see I'm well out of my normal bounds.
> 
> Now this seems like a pretty big stretch to me... and I don't see
> how it can be done without the speed of hardware (the image
> chips all seem to have clock speeds in the tens of MHz and the
> USB2 transfer rate is 480Mbps (theor.).  Do aspects of this
> project require an FPGA to keep the data "as fast as possible?"
> If we use and FPGA for camera-to-RAM and then use a
>  micro for the USB2 part, what kind of fast micros can
> move data at that rate?

I don't think the micro should be in the data path.  A micro can be used
for control and management, but the data path should be pure hardware
for maximum throughput.  If you look around, you will find that there
are USB chips with integrated micros (many are 8051s).  But the USB 2.0
chips typically have a DMA engine for the data path.  

> Also, this is something that I am sure we will have to contract
> out, so if you have any past experience with this, please let
> me know your thoughts (and if you are available).

We have some background in this area.  If you are interested, please
contact me at the email address below or at sales (at) arius.com.  

-- 

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: 60182
Subject: Re: Low-cost FPGA Development Board with built-in Computer core
From: hamilton <hamilton@deminsional.com>
Date: Sun, 07 Sep 2003 09:47:36 -0600
Links: << >>  << T >>  << A >>
Very nice, but the web site does not show a price.

Please share.

jjl wrote:
> Everybody,
> 
> (Excuse my sales pitch at this forum.. 
> but lots of folks are asking about where to 
> start with FPGAs..)
> 
> A new FPGA Development Board is out at:
> 
> http://www.cmosexod.com/fnd.htm
> 
> This board is ideal for:
> 
>  - Novice or everyone else just wanting to start out
>    exploring FPGAs.
> 
>  - SW engineers wishing to get into HW
>    ( no need to mess with solder and irons
>      and plug-in boards - unless you 
>      want to )
> 
>  - HW engineers wishing for a low-cost and yet
>    capable and expandable development board 
>    which can be turned into a permanent board.
>    ( no need to design another board
>      after your FPGA design is completed. Use
>      this board to permanently house your design. )
> 
> 
>  - The board is specially design to have the most
>    needed features.  You won't be buying an expensive
>    "everything board" just to use 1 or 2 features 
>    of the board. Similarly, if you need features
>    not present on the board, you can plug in your
>    own board.
> 
> This is a low-cost (relatively speaking), complete with 
> most frequently used peripherals.  Lots of expansion connectors
> allows cascading several boards or add your own "daughter" board.
> 
> YOU GET A BOARD AND A COMPUTER:
> ===============================
> The Board comes with a complete Computer System core, so
> it works right out of the box.  It shows the potentials
> of the board.  Plug in a VGA monitor a keyboard and mouse
> and start writing your own application.  
> The Computer core is yours to keep.  The bitstream image of 
> it is included in the CD, so you can always reload the 
> board with it.


Article: 60183
Subject: Spartan 2 xc2s150
From: shabana_rizvi@yahoo.com (rider)
Date: 7 Sep 2003 08:48:10 -0700
Links: << >>  << T >>  << A >>
Hi!
I have to redesign a TTL based design of discere components into an
FPGA. I have selected spartan 2 xc2s150. I have a few queries
regarding the board design.

1) I want my Inputs to be 5V tolerant..which input standard should i
use...LVTTL or PCI_5V ? How to select any of these standards as both
require VCCO=3.3V and No Vref or VTT...?

2)If any of my xc2s150 ouput pin is an open collector, can i pull it
up externally by 5V through a resistor?

3)I am intending to use a Level shifter IC(3.3V to 5V) at some FPGA
outputs..is it OK to do so?

4)I dont have a global set/reset in the design, can it create problems
at startup?

5)What should i do of un-used pins of FPGA...can i keep them
unconnected?

Thanks for everyone's support.

Article: 60184
Subject: Re: CMOS camera w/ USB2 -- crazy?
From: hamilton <hamilton@deminsional.com>
Date: Sun, 07 Sep 2003 10:00:23 -0600
Links: << >>  << T >>  << A >>
What image sensor chip are you looking at ???

GB wrote:

> Hi,
> 
> I'm a firmware guy pulled into a project well out of my area of
> expertise.  My boss wants to build (essentially) a digital camera
> using an image sensor chip (1600x1200) and output it's data
> "as fast as possible" using USB2.0.  His initial concept, being
> that I'm a firmware guy, was to use a "really fast micro."
> Normally the company is involved with small 8-bitter micro
> projects, so you can see I'm well out of my normal bounds.
> 
> Now this seems like a pretty big stretch to me... and I don't see
> how it can be done without the speed of hardware (the image
> chips all seem to have clock speeds in the tens of MHz and the
> USB2 transfer rate is 480Mbps (theor.).  Do aspects of this
> project require an FPGA to keep the data "as fast as possible?"
> If we use and FPGA for camera-to-RAM and then use a
>  micro for the USB2 part, what kind of fast micros can
> move data at that rate?
> 
> Also, this is something that I am sure we will have to contract
> out, so if you have any past experience with this, please let
> me know your thoughts (and if you are available).
> 
> Thanks!
> 
> 


Article: 60185
Subject: Re: CMOS camera w/ USB2 -- crazy?
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Sun, 07 Sep 2003 16:06:23 GMT
Links: << >>  << T >>  << A >>
GB wrote:

> I'm a firmware guy pulled into a project well out of my area of
> expertise.  My boss wants to build (essentially) a digital camera
> using an image sensor chip (1600x1200) and output it's data
> "as fast as possible" using USB2.0.  His initial concept, being
> that I'm a firmware guy, was to use a "really fast micro."
> Normally the company is involved with small 8-bitter micro
> projects, so you can see I'm well out of my normal bounds.
> 
> Now this seems like a pretty big stretch to me... and I don't see
> how it can be done without the speed of hardware (the image
> chips all seem to have clock speeds in the tens of MHz and the
> USB2 transfer rate is 480Mbps (theor.).  Do aspects of this
> project require an FPGA to keep the data "as fast as possible?"
> If we use and FPGA for camera-to-RAM and then use a
>  micro for the USB2 part, what kind of fast micros can
> move data at that rate?
> 
> Also, this is something that I am sure we will have to contract
> out, so if you have any past experience with this, please let
> me know your thoughts (and if you are available).

Sounds like a good project for an FPGA.  Micros don't keep up with this kind of data rates, standard parts do what everyone else is doing (and this doesn't sound standard), and ASICS can do this, if you have the volume to make it worthwhile, but it would be wise to prototype the design in a FPGA first.

I've done several FPGA designs to solve similar problems.  I'm not available, but I'm fairly sure I know of someone fairly good that is available, and if you send mail to (attbi.com phil-hays) I'll get you in contact with him.


-- 
Phil Hays

Article: 60186
Subject: Re: CMOS camera w/ USB2 -- crazy?
From: "GB" <donotspam_grantbt@jps.net>
Date: Sun, 07 Sep 2003 17:12:06 GMT
Links: << >>  << T >>  << A >>

"hamilton" <hamilton@deminsional.com> wrote in message
news:3f5b561c_3@omega.dimensional.com...

> What image sensor chip are you looking at ???
>

That's another undecided at this time, but CMOS most likely.

GB



Article: 60187
Subject: Re: CMOS camera w/ USB2 -- crazy?
From: "GB" <donotspam_grantbt@jps.net>
Date: Sun, 07 Sep 2003 17:19:53 GMT
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3F5B4FAC.41D84F7B@yahoo.com...

> I don't think the micro should be in the data path.  A micro can be used
> for control and management, but the data path should be pure hardware
> for maximum throughput.  If you look around, you will find that there
> are USB chips with integrated micros (many are 8051s).  But the USB 2.0
> chips typically have a DMA engine for the data path.

From what I understand, the image size is 1-2 MB (only need 8-bit depth)
large and the USB packets are quite small in comparison.  So there needs to
be some smarts for setting up what part of the data gets DMA'd to the
USB endpoint buffers for any given transfer?  Or does the FPGA
implementation just point to the image data stored in RAM (assuming image
frame captured to some local RAM buffer) and never move the data from
image_buffer -> to_endpoint -> to_USB (essentially skipping the middle
man by just using a pointer of sorts)?

It's just a still picture (not a movie).  Doesn't this seem like a somewhat
common function -- meaning wouldn't there be standard chips or
implementations that do this?

Thanks again,
GB



Article: 60188
Subject: Spartan3 multiplier
From: "Theron Hicks" <hicksthe@egr.msu.edu>
Date: Sun, 7 Sep 2003 13:27:13 -0400
Links: << >>  << T >>  << A >>
Hello,
    Can anyone give me an approximate time for an 18 by 18 multiply using
the spartan3.  I cannot seem to find a specification for this in the data
sheet.  I realize that the time is a function of the number of bits.  Also,
I assume that this multiplier is not clocked.  In otherwords, does the value
eventually ripple through to the output, or is this system in some fashion
clocked.  An input latch is quite acceptable, I just would rather not deal
with a clocked delay through the multiplier.
Thanks,
Theron



Article: 60189
Subject: Re: CMOS camera w/ USB2 -- crazy?
From: John <John@bilger.fsnet.co.uk>
Date: Sun, 07 Sep 2003 20:25:50 +0100
Links: << >>  << T >>  << A >>
On Sun, 07 Sep 2003 15:03:39 GMT, "GB" <donotspam_grantbt@jps.net>
wrote:

Look at the Cypress USB parts.  They have a 8051 full/high speed part
which might be useful. The 8051 code basically sets up endpoints, and
doesn't have to actually transfer the data.  Good luck.


>Hi,
>
>I'm a firmware guy pulled into a project well out of my area of
>expertise.  My boss wants to build (essentially) a digital camera
>using an image sensor chip (1600x1200) and output it's data
>"as fast as possible" using USB2.0.  His initial concept, being
>that I'm a firmware guy, was to use a "really fast micro."
>Normally the company is involved with small 8-bitter micro
>projects, so you can see I'm well out of my normal bounds.
>
>Now this seems like a pretty big stretch to me... and I don't see
>how it can be done without the speed of hardware (the image
>chips all seem to have clock speeds in the tens of MHz and the
>USB2 transfer rate is 480Mbps (theor.).  Do aspects of this
>project require an FPGA to keep the data "as fast as possible?"
>If we use and FPGA for camera-to-RAM and then use a
> micro for the USB2 part, what kind of fast micros can
>move data at that rate?
>
>Also, this is something that I am sure we will have to contract
>out, so if you have any past experience with this, please let
>me know your thoughts (and if you are available).
>
>Thanks!
>


Article: 60190
Subject: Re: CMOS camera w/ USB2 -- crazy?
From: Mario Trams <mtr@informatik.tu-chemnitz.de>
Date: Sun, 07 Sep 2003 21:58:13 +0200
Links: << >>  << T >>  << A >>
GB wrote:

> It's just a still picture (not a movie).  

Aha, that's an important fact as it greatly reduces the requirements.
Depending on what "as fast as possible" (in terms of latency) means, 
a DSP or a better RISC microprocessor might be a better solution 
for you. At least you won't have to introduce yourself to the new 
(for you) area of FPGAs.

I don't know how the interface of the CCD chip you are planning to 
use is working, but I can imagine that it uses some standard interface
that can be found on higher-class processors.

So I suggest you to check some DSPs first (Analog Devices, Texas
Instruments, Motorola, ...). Although you might not need the computing
power they provide, perhaps you can use their hardware interfaces.
DSPs are often used for image processing and therefore have a close
relationship to CCDs.

Perhaps you could also ask for this issue in comp.dsp.

Regards,
Mario   

-- 
----------------------------------------------------------------------
Digital Force / Mario Trams      Mario.Trams@informatik.tu-chemnitz.de
                                      Mario.Trams@wooden-technology.de
Chemnitz University of Technology       http://www.tu-chemnitz.de/~mtr
Dept. of Computer Science                     Tel.: (+49) 371 531 1660
Chair of Computer Architecture                Fax.: (+49) 371 531 1818
----------------------------------------------------------------------

Article: 60191
Subject: Re: Schematic simulation and then FPGA programming?
From: INVALIDANTISPAM@aol.com (John K.)
Date: 7 Sep 2003 20:54:04 GMT
Links: << >>  << T >>  << A >>
Hi Alex Gibson (alxx@ihug.com.au), you wrote:

> in project navigator
> ->new source ->schematic  type in the name of the file for it to create
> click okay
> ecs (xilinx schematic editor) will start up and you
> can start drawing up your schematic.

Maybe it's because I'm using the v5.2.03i of the free WebPack, but
I can't find any schematic option in the New Source window. :(

I can see only:

User Document
BMM File
MEM File
Implementation Constraints File


> with webpack the major hassle is simulating a schematic design.
> You have to convert your design to vhdl or verilog so
> modelsim can load your design.
> 
> Altera's software is much better for simulating schematics than 
> xilinx's.

Yup, I'm thinking to dump Xilinx and go with Altera instead. But
it's very confusing for me to find the right target device. What
would be a rough equivalent of the Spartan 2E 300? Altera has so
many families that it's very confusing (at least for me).

Moreover, what about programmers and development boards? My former
choice for Xilinx was motivated by the large (till 10 millions of
equivalent (fake, I know) gates!) rich choice of sizes, the low
cost development boards (like the ones from Digilent and Burched)
with integrated programmer. I need cheap, for the moment.

One thing, though, that puzzled me is why similar designs to the
one I have in mind, i.e. the C-One and XGameStation, both use
Altera devices. No, I won't ask if they're superior than Xilinx
(or inferior, for the matter :) ) to avoid to cause a possible
very boring flamewar here. ;)
What I really ask is instead if Altera devices are suitable for
low budget development (just to get confident with the FPGA world)
using schematic entry and simulation, and if then they will offer
the power to do serious stuff, without having to dump it all and
change brand/family of chips. Moreover, why not Actel or Lattice/
Vantis, or why not Lucent or QuickLogic (just to name those that
I heard the existance of and visited thousands times the website
of, without much results anyway)?
Moreover, if I go with Altera, which are the families roughly
equivalent in specs to the Spartan 2E and Virtex of Xilinx?

Thanks a lot for all your big patience and help!

Greets,
John


Article: 60192
Subject: PIC Programming Help
From: "Peter Scheuter" <peter3@mindspring.com>
Date: Sun, 07 Sep 2003 21:05:03 GMT
Links: << >>  << T >>  << A >>
Hello,
Is this a group for getting help for programming PIC's (16F84A)
Thanks
Peter



Article: 60193
Subject: Re: Spartan 2 xc2s150
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Sun, 7 Sep 2003 21:43:33 +0000 (UTC)
Links: << >>  << T >>  << A >>
rider <shabana_rizvi@yahoo.com> wrote:
: Hi!
: I have to redesign a TTL based design of discere components into an
: FPGA. I have selected spartan 2 xc2s150. I have a few queries
: regarding the board design.

: 1) I want my Inputs to be 5V tolerant..which input standard should i
: use...LVTTL or PCI_5V ? How to select any of these standards as both
: require VCCO=3.3V and No Vref or VTT...?

LVTTL

: 2)If any of my xc2s150 ouput pin is an open collector, can i pull it
: up externally by 5V through a resistor?

Yes.

For speed reasons, use it as tri-state totem pole. First pull it up
internally, then switch  to tristate to activate the 5V pull-up resistor.
There's a Xilinx appnote out there about that.

: 3)I am intending to use a Level shifter IC(3.3V to 5V) at some FPGA
: outputs..is it OK to do so?

If 2) isn't enough, you can do so.

: 4)I dont have a global set/reset in the design, can it create problems
: at startup?
You don't need to use it, if you don't need the functionality

: 5)What should i do of un-used pins of FPGA...can i keep them
: unconnected?

Define them as inputs with the "keeper" attribute, leave them
unconected. That will make reuse  easier.

: Thanks for everyone's support.

You're welcome
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 60194
Subject: Re: Spartan3 multiplier
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Sun, 7 Sep 2003 21:44:40 +0000 (UTC)
Links: << >>  << T >>  << A >>
Theron Hicks <hicksthe@egr.msu.edu> wrote:
: Hello,
:     Can anyone give me an approximate time for an 18 by 18 multiply using
: the spartan3.  I cannot seem to find a specification for this in the data
: sheet.  I realize that the time is a function of the number of bits.  Also,
: I assume that this multiplier is not clocked.  In otherwords, does the value
: eventually ripple through to the output, or is this system in some fashion
: clocked.  An input latch is quite acceptable, I just would rather not deal
: with a clocked delay through the multiplier.

Look at the Virtex datasheet to get a feeling of the multiplier behaviour.

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 60195
Subject: Re: PIC Programming Help
From: "Matt" <bielstein2002@comcast.net>
Date: Sun, 07 Sep 2003 21:48:54 GMT
Links: << >>  << T >>  << A >>
Not exactly. This group is mainly for FPGA technology. However, Microchip's
web site has a ton of information for beginners to experts. You might start
here:
http://www.microchip.com/1010/suppdoc/design/start/index.htm

Good luck!


"Peter Scheuter" <peter3@mindspring.com> wrote in message
news:34N6b.2903$Yt.1101@newsread4.news.pas.earthlink.net...
> Hello,
> Is this a group for getting help for programming PIC's (16F84A)
> Thanks
> Peter
>
>



Article: 60196
Subject: Re: CMOS camera w/ USB2 -- crazy?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Mon, 08 Sep 2003 10:52:55 +1200
Links: << >>  << T >>  << A >>
GB wrote:
> 
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:3F5B4FAC.41D84F7B@yahoo.com...
> 
> > I don't think the micro should be in the data path.  A micro can be used
> > for control and management, but the data path should be pure hardware
> > for maximum throughput.  If you look around, you will find that there
> > are USB chips with integrated micros (many are 8051s).  But the USB 2.0
> > chips typically have a DMA engine for the data path.
> 
> From what I understand, the image size is 1-2 MB (only need 8-bit depth)
> large and the USB packets are quite small in comparison.  So there needs to
> be some smarts for setting up what part of the data gets DMA'd to the
> USB endpoint buffers for any given transfer?  Or does the FPGA
> implementation just point to the image data stored in RAM (assuming image
> frame captured to some local RAM buffer) and never move the data from
> image_buffer -> to_endpoint -> to_USB (essentially skipping the middle
> man by just using a pointer of sorts)?
> 
> It's just a still picture (not a movie).  Doesn't this seem like a somewhat
> common function -- meaning wouldn't there be standard chips or
> implementations that do this?

 Yes, Data-> USB 2.0 is common, and a good example of a std chip
is the Cypress chip someone has already mentioned.

 You may need a CPLD or small FPGA to run the CMOS sensor
clocks, and help the transfer, but the idea is to do as much in
the standard  uC.USB2.0 package as you can.

 I would also nail down just what "as fast as possible" really
means. Tell your boss there is a speed/price/development time
tradeoff, and find what speed the product really NEEDS.

 Also find out, early on, if any form of compression is 
envisioned, or if a simple 'frame dump' is fine.

-jg

Article: 60197
Subject: Re: CMOS camera w/ USB2 -- crazy?
From: khimbittle@cliftonREMOVEsystems.com (Khim Bittle)
Date: Mon, 08 Sep 2003 01:36:54 GMT
Links: << >>  << T >>  << A >>
On Sun, 07 Sep 2003 15:03:39 GMT, "GB" <donotspam_grantbt@jps.net>
wrote:

>Hi,
>
>I'm a firmware guy pulled into a project well out of my area of
>expertise.  My boss wants to build (essentially) a digital camera
>using an image sensor chip (1600x1200) and output it's data
>"as fast as possible" using USB2.0.  His initial concept, being
>that I'm a firmware guy, was to use a "really fast micro."
>Normally the company is involved with small 8-bitter micro
>projects, so you can see I'm well out of my normal bounds.
>
>Now this seems like a pretty big stretch to me... and I don't see
>how it can be done without the speed of hardware (the image
>chips all seem to have clock speeds in the tens of MHz and the
>USB2 transfer rate is 480Mbps (theor.).  Do aspects of this
>project require an FPGA to keep the data "as fast as possible?"
>If we use and FPGA for camera-to-RAM and then use a
> micro for the USB2 part, what kind of fast micros can
>move data at that rate?
>
>Also, this is something that I am sure we will have to contract
>out, so if you have any past experience with this, please let
>me know your thoughts (and if you are available).
>
>Thanks!
>
>

Hello :

The first question that comes to mind is why are you designing this ?
( other than your boss told you to )

One answer may be high volume production where an absolutely cost
optimized solution is the correct answer.

Another answer may be special requirements for your application. If
this is so then you have not provided enough information above to tell
us what these special requirements are to suggest an architecture.

I ask this question simply because there are numerous small oem camera
modules on the market with hi res cmos sensors and USB2 output that
can get you to market rapidly and become cost effective as volumes
increase.   An example may be found at
http://www.lumenera.com/oem.htm  

If we proceed along the path that you need to design such a module :

Several companies are coming out with single chip imaging controllers
( national ,etc ) but I am not aware of an available part to do
exactly what you are looking for ... but I would do a very careful
search as this is the most streamlined approach.

An FPGA may be a good solution to interconnect the sensor module ,
capture memory and the USB controller.  The controller ( Cypress )
will normally setup the USB endpoints etc. and then get out of the
way. The FPGA can handle all of the high speed timing and perhaps a
SDRAM controller. 

Another most intriguing solution (hey this is the comp.arch.fpga
group) , however the most engineering intensive ($) ,  would be to use
an FPGA with softcore processor and perhaps a USB core ... so the
entire solution except sensor, memory and USB physical drive chip
could be in the FPGA. The softcore processor could be programmed in C
and code changes simply bootloaded in to a flash memory by the
softcore processor without an FPGA design change ( nice when you have
contracted the FPGA design out of house yet the in house programmers
can write C code which runs on the processor in the FPGA ). ( I am
currently involved with a video design utilizing  Altera Nios softcore
processor / Cyclone FPGA designs )

Good Luck, check out the link below, we have significant video and
imaging experience and may be able to assist your design efforts.

Khim Bittle
khimbittle@cliftonREMOVEsystems.com   
(remove REMOVE from email address to respond)

Clifton Systems Inc.
http://www.cliftonsystems.com/design









Article: 60198
Subject: system simulation and verification methods (NIOS)
From: jwing23@hotmail.com (J-Wing)
Date: 7 Sep 2003 19:14:06 -0700
Links: << >>  << T >>  << A >>
what ways and approaches are there to do system level simulation?
i have a nios system module and a user logic which have been connected
together via the avalon bus. can simulation be done using quartus II?

Article: 60199
Subject: Re: switching problem
From: "John Retta" <jretta@rtc-inc.com>
Date: Mon, 08 Sep 2003 02:28:06 GMT
Links: << >>  << T >>  << A >>
Hi Simone -
  As Eric suggested, there is code which simulates, but might not be
synthesizeable.  One problem area might be the use of multiple clocks.
   Switch does not need to be a clock in this case.  The starting point
would be to build a simple edge detect circuit for a normally HI signal,
with low going pulse for an event capture.

  q0_switch <= switch;             [clocked with clk_i]
  q1_switch <= q0_switch;      [clocked with clk_i]
  switch_leading_edge_detect = ~q0_switch & q1_switch.  [combinational]

  Then you can use switch leading_edge_detect in place of the switch'event
and
switch = 1'b0;

  Problem with above is that both the leading and trailing edges of the
switch
are typically noisy, and debouncing switch signal is required.  Logic here
would
be to generate a stable_hi signal which is set HI on reset.  When the switch
in
is low for 50 consecutive 1 msec samples, then stable_hi can be cleared.
When
switch in is high for 50 consecutive samples, it can be set hi again.

  Last problem is that you need a default condition defining sevseg_s for
counter values not specified in case statement.

  Good luck.

Regards,
John Retta

email : jretta@rtc-inc.com
web :  www.rtc-inc.com


----- Original Message ----- 
From: "Simone Winkler" <simone.winkler@gmx.at>
Newsgroups: comp.arch.fpga
Sent: Friday, September 05, 2003 1:59 PM
Subject: switching problem


> Hello!
>
> I'm trying to build the following thing: a 7-segment-led that increases
its
> value every time a switch is pressed.
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> entity sevsegment is
>     Port (
>     clk_i: in std_logic;
>     sevseg : out std_logic_vector(6 downto 0);
>            reset : in std_logic;
>      switch: in std_logic);
> end sevsegment;
>
> architecture Behavioral of sevsegment is
> signal sevseg_s: std_logic_vector(6 downto 0);
> begin
>
> process(reset,switch,clk_i)
> variable counter: integer range 0 to 9;
> begin
>  if clk_i'event and clk_i='1' then
>    if reset='0' then
>         counter:=0;
>         sevseg_s <= "1111110";
>   elsif switch'event and switch='0' then
>       if counter<9 then
>            counter:=counter+1;
>       else
>            counter:=0;
>       end if;
>   case counter is
>    when 0 => sevseg_s <= "1111110";
>    when 1 => sevseg_s <= "0110000";
>    when 2 => sevseg_s <= "1101101";
>    when 3 => sevseg_s <= "1111001";
>    when 4 => sevseg_s <= "0110011";
>    when 5 => sevseg_s <= "1011011";
>    when 6 => sevseg_s <= "1011111";
>    when 7 => sevseg_s <= "1110000";
>    when 8 => sevseg_s <= "1111111";
>    when 9 => sevseg_s <= "1111011";
>   end case;
> end if;
> end process;
>
> sevseg <= sevseg_s;
>
> end Behavioral;
>
>
> Why doesn't it work? I know that "multiple clocks" are not allowed, but i
> can't find any solution to solve my problem.... :-(((((((((
> In the end, everything should be implemented to a spartanII-FPGA...
>
> Thank you very much,
> Simone
>





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