Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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: 60176We got a quote of around $4k for a EP1S80 from Altera. Yes small quantities. Anybody getting them for much less, say sub $500? Tks JerryArticle: 60177
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
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? > > > > thanksArticle: 60179
"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
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
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 FAXArticle: 60182
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
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
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
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 HaysArticle: 60186
"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. GBArticle: 60187
"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, GBArticle: 60188
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: 60189On 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
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: 60191Hi 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, JohnArticle: 60192
Hello, Is this a group for getting help for programming PIC's (16F84A) Thanks PeterArticle: 60193
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
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
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
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. -jgArticle: 60197
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/designArticle: 60198
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
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:
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