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
In article <LOd3k.9642$Ri.1039@flpi146.ffdc.sbc.com>, Vladimir Vassilevsky <antispam_bogus@hotmail.com> wrote: > > >rickman wrote: > >> I couldn't figure out how to do a lot of things and I ended up >> installing Win2000 over it. > >> So what exactly is better about Linux? > >I second your opinion regarding Linux. It is a toy of students and >enthusiasts who are enjoying the process of configuring the computer >instead of getting the actual job done hard and fast. The OP has not so much on opinion about Linux as wel as bad experiences, and is willing to learn. The only hindrance to getting my job done on Linux is when I meet deliberately created incompatibilities and deviations from standards originating from you know who. > >BTW, why do you prefer Win2k rather then XP? > > >Vladimir Vassilevsky >DSP and Mixed Signal Design Consultant >http://www.abvolt.com Haven't we met? (I'm the guy of the ESO optical delay line in Paranal Chile, meeting the requirements of 14 nanometer deviation RMS.) -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- like all pyramid schemes -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horstArticle: 133226
In article <e4bae6ce-2596-4010-83a2-1e8790d98478@b1g2000hsg.googlegroups.com>, rickman <gnuarm@gmail.com> wrote: >On Jun 7, 12:13 am, Randy Yates <ya...@ieee.org> wrote: >> rickman <gnu...@gmail.com> writes: >> > [...] >> > But if I want a laptop, I won't have much choice but to run Win XP >> > (for the next few weeks) or Vista. I only wish I had a choice. >> >> You do. I have successfully installed Fedora 8 on an HP Pavillion >> DV9620US. >> >> However one thing to be careful of in running linux on laptops is >> Broadcom's stubborn refusal to open up their wireless card >> specifications so that open source drivers can be developed. Translated: >> don't buy a laptop with a Broadcom wireless card (or chipset) if you >> want to run linux on it. Atheros I've heard is very good and supported >> by madwifi.org. >> >> But, even though Broadcom is stubborn, I have still been successful at >> getting the card to work on my home network. Unfortunately the reverse >> engineered drivers (b43-fwcutter...) do not seem to support the Master >> modes used in public hotspots. > >I knew someone would mention Linux. Linux is still an alien platform >to me and there is any amount of software that is not supported under >it... or I should say that there is any amount of software that is >only supported on specific versions of Linux. If I run Fedora 8, >maybe vendor X gives me support and vendor Y doesn't. I run Redhat >and vendor X gives me support and vendor Z doesn't... etc, etc, etc. Officially Dutch tax forms runs only under certain brands of linux, not my brand. Guess what? The windows software is reasonably cross- platform (withing windows that is). Bottom line, the *windows* version of the tax forms installed and run under wine on my Ubuntu 64 bit 7.03. (12 Megabyte to fill in 12 zero's in a a form, but anyway). Including sending the completed form over a safe channel. >The reason that I still run windows at all is because for me, it is >the only option. Currently Win2000 is the best that runs the minimum >required set of software. If I want a laptop, my only choice >currently is to buy a machine running XP which I can do for the next >few weeks. After that there will be no choice on a new machine except >for Vista. With a number of vendors not supporting that still, I will >not have the option of buying a new laptop with an installed OS that >runs the software I need. My guess: Windows package intended for XP run better on Ubuntu/wine than one Windows Vista. At least you can check it out at no cost. > >Rick -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- like all pyramid schemes -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horstArticle: 133227
hello... in order to interface between my pc (via matlab) and the XUP Virtex 2 pro board, i came to know i'll have to use the lwIP library/stack... is that right? (there is no OS running on the ppc405 in the board, and windows xp on the pc....) should i use the raw API or sockets? also, could you please recommend examples (with codes to show functionalities...) for both? (i referred to xilinx app note 663...) please reply asap and help out... thanks in advance.. vikramArticle: 133228
> in order to interface between my pc (via matlab) and the XUP Virtex 2 > pro board, i came to know i'll have to use the lwIP library/stack... > > is that right? (there is no OS running on the ppc405 in the board, and > windows xp on the pc....) You can interface to the PC in many ways. Does the board you have include a serial port? That could be simpler, but it of course depends on what you are trying to do. You will probably want to be running the xilinx kernel on the PPC to give you threading support. > should i use the raw API or sockets? Sockets is probably the best. Then just about any examples of socket programming you can find on the web will be relevant. JonArticle: 133229
On May 29, 8:52 pm, Eric Smith <e...@brouhaha.com> wrote: > Peter Alfke wrote: > > ... > > the "six easy pieces" that seem to be lost. > ... > The "six easy pieces" article is exactly the sort of thing that I was > worried would be lost. :-( > ... > Eric Eric, Peter, Don't worry! it's not completely lost... You can find the text here: http://web.archive.org/web/20051118160637/www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=pa_six_easy and... guess... the images are here: http://direct.xilinx.com/bvdocs/images/techx/6easy_1.gif http://direct.xilinx.com/bvdocs/images/techx/6easy_2.gif http://direct.xilinx.com/bvdocs/images/techx/6easy_3.gif http://direct.xilinx.com/bvdocs/images/techx/6easy_4.gif http://direct.xilinx.com/bvdocs/images/techx/6easy_5.gif Regards SandroArticle: 133230
"Jon Beniston" <jon@beniston.com> wrote in message news:66a7941d-4a8d-4819-8ae2-3b878d4f28e1@j22g2000hsf.googlegroups.com... >> should i use the raw API or sockets? > > Sockets is probably the best. Then just about any examples of socket > programming you can find on the web will be relevant. POSIX and Berkeley sockets lead to ugly, unscalable architectures. I would use raw sockets where they're available. They're not any more difficult to use, and the concepts are identical.Article: 133231
General Schvantzkopf <schvantzkopf@yahoo.com> writes: > times as fast on Linux as it does on XP. I'm pretty sure that the time > difference can be attributed to the performance of the Linux file system > (EXT3) vs the XP file system (NTFS). The real purpose of my investigation But simulations are not file system IO bound unless your dumping trace files to the disk. You typically load the simulation image into memory and run (unless you're dumping waveform data to the disk). Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 133232
On Sat, 21 Jun 2008 21:42:08 +0200, Petter Gustad wrote: > General Schvantzkopf <schvantzkopf@yahoo.com> writes: > >> times as fast on Linux as it does on XP. I'm pretty sure that the time >> difference can be attributed to the performance of the Linux file >> system (EXT3) vs the XP file system (NTFS). The real purpose of my >> investigation > > But simulations are not file system IO bound unless your dumping trace > files to the disk. You typically load the simulation image into memory > and run (unless you're dumping waveform data to the disk). > > Petter We have display statements in this testbench, it's not nearly as much IO as when you dump a .trn file but it's enough so that slow disk IO has between a 3X and 5X slowdown depending on how bad the IO is.Article: 133233
Quick summary: Under what circumstances, if any, can you use 3.3V VCCIO for PCI, with Cyclone 3 parts ? I've read Altera apnote AN447 http://www.altera.com/literature/an/an447.pdf I understand this apnote to suggest that any/all 3.3V LVTTL or LVCMOS signals connected to a Cyclone III must employ series termination. (Assumptions for my design: 3.3V VCCIO on the Cyclone III, and the signal source is *not* configurable to moderate rise/fall time) This seems rather bizarre. At first I thought this applied only to PCI, rather than straight 3.3V LVTTL and LVCMOS, because the open-system PCI spec requires tolerance of nasty overshoots. This would be easy to waive off, as I'm not designing an open PCI system, just 6" PCI using 3.3V 5% supplies. But no, it seems that Altera is requiring a new and unique supply voltage for all 3.3V (the predominant signaling standard in my designs). Other than reverting to Cyclone II or Xilinx devices for my current design, are there any other options? External Schottky clamp diodes to 3.3V at each end of the bus ? Parallel termination at each end of the bus ? I cringe at using 3.0V VCCIO. First, I'll need linear LDOs at each device. Then there's the due diligence work to ensure there are no unforseen "collateral damages" from 3.0V devices talking to 3.3V devices (e.g. what supply do you use for pullup resistors ?) -- I appreciate the old maxim: "I don't know what I don't know". I regret starting this design with three Cyclone IIIs on the board. Unless the bird of Altera Paradise lands on my head to soothe me, I'll seek other options going forward. Thanks in advance for any words of wisdom and advice. Please post followups in this newsgroup! - Bob ElkindArticle: 133234
Some of my colleagues have designed complex PC type controller boards (PCI interfaces) where many different voltages are needed. In these cases, a complex switching power supply design is utilized and deriving one more voltage isn't too much of an issue. By the way, there were a couple of recent discussions on this newsgroup about this topic titled, "Cyclone 3 on chip termination" and "Cyclone 3 margins: none at all at 3.3v" For PCI, the recommendation is to use 3.0V at the VCCIO pins; but for normal LVTTL type interface you can use 3.3V, I've done it. You just have to make darn sure that your transmission lines are designed properly. Take care, Rob bob elkind wrote: > Quick summary: Under what circumstances, if any, can you use 3.3V VCCIO for PCI, with Cyclone 3 parts ? > > I've read Altera apnote AN447 http://www.altera.com/literature/an/an447.pdf I understand this apnote to suggest that any/all 3.3V > LVTTL or LVCMOS signals connected to a Cyclone III must employ series termination. (Assumptions for my design: 3.3V VCCIO on the > Cyclone III, and the signal source is *not* configurable to moderate rise/fall time) > > This seems rather bizarre. At first I thought this applied only to PCI, rather than straight 3.3V LVTTL and LVCMOS, because the > open-system PCI spec requires tolerance of nasty overshoots. This would be easy to waive off, as I'm not designing an open PCI > system, just 6" PCI using 3.3V 5% supplies. But no, it seems that Altera is requiring a new and unique supply voltage for all > 3.3V (the predominant signaling standard in my designs). > > Other than reverting to Cyclone II or Xilinx devices for my current design, are there any other options? External Schottky clamp > diodes to 3.3V at each end of the bus ? Parallel termination at each end of the bus ? > > I cringe at using 3.0V VCCIO. First, I'll need linear LDOs at each device. Then there's the due diligence work to ensure there > are no unforseen "collateral damages" from 3.0V devices talking to 3.3V devices (e.g. what supply do you use for pullup resistors > ?) -- I appreciate the old maxim: "I don't know what I don't know". > > I regret starting this design with three Cyclone IIIs on the board. Unless the bird of Altera Paradise lands on my head to soothe > me, I'll seek other options going forward. > > Thanks in advance for any words of wisdom and advice. Please post followups in this newsgroup! > > - Bob Elkind > >Article: 133235
Some of my colleagues have designed complex PC type controller boards (PCI interfaces) where many different voltages are needed. In these cases, a complex switching power supply design is utilized and deriving one more voltage isn't too much of an issue. By the way, there were a couple of recent discussions on this newsgroup about this topic titled, "Cyclone 3 on chip termination" and "Cyclone 3 margins: none at all at 3.3v" For PCI, the recommendation is to use 3.0V at the VCCIO pins; but for normal LVTTL type interface you can use 3.3V, I've done it. You just have to make darn sure that your transmission lines are designed properly. Take care, Rob bob elkind wrote: > Quick summary: Under what circumstances, if any, can you use 3.3V VCCIO for PCI, with Cyclone 3 parts ? > > I've read Altera apnote AN447 http://www.altera.com/literature/an/an447.pdf I understand this apnote to suggest that any/all 3.3V > LVTTL or LVCMOS signals connected to a Cyclone III must employ series termination. (Assumptions for my design: 3.3V VCCIO on the > Cyclone III, and the signal source is *not* configurable to moderate rise/fall time) > > This seems rather bizarre. At first I thought this applied only to PCI, rather than straight 3.3V LVTTL and LVCMOS, because the > open-system PCI spec requires tolerance of nasty overshoots. This would be easy to waive off, as I'm not designing an open PCI > system, just 6" PCI using 3.3V 5% supplies. But no, it seems that Altera is requiring a new and unique supply voltage for all > 3.3V (the predominant signaling standard in my designs). > > Other than reverting to Cyclone II or Xilinx devices for my current design, are there any other options? External Schottky clamp > diodes to 3.3V at each end of the bus ? Parallel termination at each end of the bus ? > > I cringe at using 3.0V VCCIO. First, I'll need linear LDOs at each device. Then there's the due diligence work to ensure there > are no unforseen "collateral damages" from 3.0V devices talking to 3.3V devices (e.g. what supply do you use for pullup resistors > ?) -- I appreciate the old maxim: "I don't know what I don't know". > > I regret starting this design with three Cyclone IIIs on the board. Unless the bird of Altera Paradise lands on my head to soothe > me, I'll seek other options going forward. > > Thanks in advance for any words of wisdom and advice. Please post followups in this newsgroup! > > - Bob Elkind > >Article: 133236
"Rob" <buzoff@leavemealone.com> wrote in message news:485DC7BF.9030200@leavemealone.com... ... > For PCI, the recommendation is to use 3.0V at the VCCIO pins; but for normal LVTTL type interface you can use 3.3V, I've done > it. You just have to make darn sure that your transmission lines are designed properly. > > Take care, > Rob Rob, what's the difference between PCI and 3.3V LVTTL, that one requires 3.0V and the other does not ? - Bob ElkindArticle: 133237
Hi,
I am thinking of using Verilog for a project I am working on. Originally
I was going to use a processor core (and C) on an environment someone
set up for me in VHDL/Verilog, then I thought of using FpgaC and doing
it myself, and now I'm more or less decided on using Verilog to do most
of it (minus the hardware stuff, after initial development and simulation).
My first questions, of which I hope there won't be many, relate to
connecting 'wires' between modules, and simulations.
In my code I am attempting to change a value of 'addr' in setaddr to a
specific value when processing starts, this will later be set by an
address switch on the hardware. I am then trying to match this value in
another module called decpacket when 'pktrx' changes, when a packet
comes in (code not written for serial communications).
In ModelSim, the simulator shows that 'addr' in decpacket is 8 bits
wide, but for some reason 'addr' in setaddr is only shown as a single
bit. Could someone kindly point out what I am doing wrong, and how I can
set this value in one location and use it in another?
Thanks,
RL
`timescale 1ns / 100ps
module setaddr(addr);
output[0:7] addr;
reg addr;
initial begin
addr = 8'd 1;
end
endmodule
module decpacket (addr,pktrx,pkt,pkttype);
input[0:7] addr;
input pktrx;
input[0:95] pkt;
output[0:7] pkttype;
reg pkttype;
always @(posedge pktrx)
begin
if(pkt[0:7] == addr)
begin
end
end
endmodule
Article: 133238On Sun, 22 Jun 2008 16:43:17 +1200, RL <rl@null.void.test> wrote: >My first questions, of which I hope there won't be many, relate to >connecting 'wires' between modules, and simulations. > I'm afraid, by looking at your first question, you'll have many more; which is OK but asking all of them to the Internet may not be the most efficient way to get them answered. Maybe a Verilog book? >In ModelSim, the simulator shows that 'addr' in decpacket is 8 bits >wide, but for some reason 'addr' in setaddr is only shown as a single >bit. Could someone kindly point out what I am doing wrong, and how I can >set this value in one location and use it in another? > >Thanks, > >RL > > >`timescale 1ns / 100ps > >module setaddr(addr); > > output[0:7] addr; > reg addr; Here you need to change the reg to 8 bits too: reg [0:7] addr; > > initial begin > addr = 8'd 1; > end > >endmodule > the way to connect setaddr & decpacket is to instantiate both of them and connect the addr wires to each other ie wire [0:7] addr; setaddr u0(.addr(addr)); decpacket u1(.addr(addr)...); >module decpacket (addr,pktrx,pkt,pkttype); > > input[0:7] addr; > input pktrx; > input[0:95] pkt; > output[0:7] pkttype; > > reg pkttype; > > always @(posedge pktrx) > begin > if(pkt[0:7] == addr) > begin > > end > end > >endmoduleArticle: 133239
Muzaffer Kal wrote: > On Sun, 22 Jun 2008 16:43:17 +1200, RL <rl@null.void.test> wrote: >> My first questions, of which I hope there won't be many, relate to >> connecting 'wires' between modules, and simulations. >> > I'm afraid, by looking at your first question, you'll have many more; > which is OK but asking all of them to the Internet may not be the most > efficient way to get them answered. Maybe a Verilog book? Thanks for your assistance. I'll give it a try when I get time (tomorrow afternoon). I've been looking around for good tutorials, but unfortunately most seem to assume I come from an electronics background. Books will likely have a similar focus. Fortunately what I need to do isn't particularly complicated. It is very basic serial communications and simple data manipulation, so basic Verilog should get me a long way. If I do make some progress, and am comfortable working with hardware concepts (I come from a C development background), then I'll probably end up buying a book to further my knowledge. Thanks, RLArticle: 133240
On Jun 20, 10:46 am, Patrick Dubois <prdub...@gmail.com> wrote: > On 19 juin, 22:45, rickman <gnu...@gmail.com> wrote: > > > I use a purely HDL hierarchy. I find that top level schematics or > > even low level schematics of large functions tend to end up being more > > like a net list than a drawing anyway. You have pins with names X,Y,Z > > connected to net R,S,T on page 1. On page 2 you have nets R,S,T > > connected to another part with pin names A,B,C. Making it a drawing > > doesn't add much in my opinion. Once I gave up hope for schematics > > and embraced the HDL world, I found joy in a life of text files and > > the infinite advantages they have in the land of version control! > > I agree that a top level schematic is exactly like a netlist, but the > difference to me anyway is that I can quickly grasp how each blocks > are connected together. I try to keep most blocks on one large 11x17 > page. Here's an example of what I mean:http://www.yousendit.com/transfer.php?action=download&ufid=B152F0A35F... > > With a netlist, I have to read the several lines of vhdl code to > understand how the blocks are connected and that takes a longer time. > Ideally, the vhdl netlist is also accompanied by a block diagram. With > the schematics flow, the block diagram comes free. > > The drawbacks of course are the version control problems associated > with schematics files and the lack of a standard file format. To me > the version control issues are not a big deal because all the meat is > in the vhdl blocks anyway, not the top level. I agree completely with the enhanced readability of a drawing at a high level. The details are not improved at all, but it is easy to see the large scale connections in a drawing. I guess I just don't bother to use a schematic for that, I just make a block diagram to go with the HDL. It is a shame that there is no standard way of representing drawings. This would help a lot with the other issues of version control, etc. But my preference would be to use software which would *produce* a drawing from the source code. Even if it required the user to draw the connection lines, it would be helpful to have a program that would create the symbols and keep them in sync with the HDL code for each module. I would find this useful even at lower levels. After all, a picture is worth a thousand words, right? As long as we are talking about our "wish list", I would also like an editor that was smart enough to complete words and sentences in my HDL. There are any number of ways that a program can track what you are doing and try to anticipate your actions as you type. For example, if I am creating a clocked process and typing an assignment for a signal or variable , it would be nice to have the software know that it needs a definition and an initialization in the reset portion of the process. So as soon as I enter the assignment, it would take me to the appropriate spot for the definition and start it for me to complete followed by the same for the initialization in the reset section of the process. If I am typing a "with" statement, I want the software to see the word "with" and put the rest of the structure on the screen for me to fill in the blanks. I find all the typing to be tedious and error prone, not to mention that after all these years, I still don't have the syntax memorized and keep a small stack of books by my elbow. Just think how nice it would be to have the editor add the appropriate conversion function when you type an assignment between incompatible signals. No error message telling you that you need to convert that integer to an unsigned, it just adds the conversion! I hate to use a microsoft product as an example of the "right" way to do anything, but the version of Word that I use does a pretty good job of completing words for me sometimes. Even though it is not always accurate, I have to admit that it does a pretty impressive job of spell checking and syntax checking, and that is with *English*, not a well defined language like VHDL or Verilog. I can only imagine that it would be a much easier job to implement something similar for an HDL. (spell checkers don't catch when you type and instead of an though...) RickArticle: 133241
Hi, I am planning to read an image sensor using an FPGA but I am a
little confused about a bunch of things. Hopefully someone here can
help me understand the following things:
Note: The image sensor output is an ANALOG signal. Datasheet says that
the READOUT clock is 40MHz.
1. How is reading of an image sensor using an ADC different then
reading a random analog signal using an ADC?
- Any random signal is read using nyquist theorem that is sample
the signal @ 2 times the highest frequency.
And the amount of data or memory required can be calculated
using:
Sampling rate x ADC resolution
- This is different in case of an image sensor ? Why ? Because
each pixel output is an analog signal and all of
that signal gets converted into a digital value ? Do I use an
ADC running at 40 MSamples/second since the
pixel output 40 MHz ?
How do I calculate the required memory ?
Is it simply 40 MS/s x 16 bits (adc resolution) for each pixel
or just 16 bits per pixel ?
If each frame is 320 x 256 then data per frame is - (320x256) x
16 bits, why not multiple this by 40 MS/s like
you would for any other random analog signal ?
Thanks,
Article: 133242On Jun 22, 10:01=A0am, ertw <gil...@hotmail.com> wrote: > Hi, I am planning to read an image sensor using an FPGA but I am a > little confused about a bunch of things. Hopefully someone here can > help me understand the following things: > > Note: The image sensor output is an ANALOG signal. Datasheet says that > the READOUT clock is 40MHz. > > 1. How is reading of an image sensor using an ADC different then > reading a random analog signal using an ADC? > > =A0 =A0 - Any random signal is read using nyquist theorem that is sample > the signal @ 2 times the highest frequency. > =A0 =A0 =A0 And the amount of data or memory required can be calculated > using: > =A0 =A0 =A0 Sampling rate x ADC resolution > > =A0 =A0 - This is different in case of an image sensor ? Why ? Because > each pixel output is an analog signal and all of > =A0 =A0 =A0 that signal gets converted into a digital value ? Do I use an > ADC running at 40 MSamples/second since the > =A0 =A0 =A0 pixel output 40 MHz ? > =A0 =A0 =A0 How do I calculate the required memory ? > > =A0 =A0 =A0 Is it simply 40 MS/s x 16 bits (adc resolution) for each pixe= l > or just 16 bits per pixel ? > =A0 =A0 =A0 If each frame is 320 x 256 then data per frame is - (320x256)= x > 16 bits, why not multiple this by 40 MS/s like > =A0 =A0 =A0 you would for any other random analog signal ? > > Thanks, Just realized after posting ... is it because for the image sensor I am only reading the amplitude using the ADC ? as opposed to any other random signal where the whole signal is sampled at different intervals ?Article: 133243
rickman wrote: > But my preference would be to use software which would *produce* a > drawing from the source code. Quartus rtl viewer does that. > As long as we are talking about our "wish list", I would also like an > editor that was smart enough to complete words and sentences in my > HDL. Emacs vhdl-mode completes words. -- Mike TreselerArticle: 133244
Software C/C++ (and other programming languages, too) have been doing this for YEARS. Microsoft calls its solution "intelliSense". It's in Developer Studio (VC++/VC##, VB.net/etc.). The first time you (sucessfully) compile the project's source-code, the class/variable browser registers every user-defined identifier (typedef, class, function, struct, union, built-in type int/float/char) with the editor. Then, as you type source-code, the browser pops up a 'helper' box. For function-calls (including the C/C++/Windows standard library), it shows the argument-names and their data-type. I guess you could call it dynamic annotation. You can jump to the definition of the object under the cursor, at any time. (For standard library calls, this is less useful -- most of the compiler header-files are unreadable jibberish.) > As long as we are talking about our "wish list", I would also like an > editor that was smart enough to complete words and sentences in my > HDL. There are any number of ways that a program can track what you > are doing and try to anticipate your actions as you type. For > example, if I am creating a clocked process and typing an assignment > for a signal or variable , it would be nice to have the software know > that it needs a definition and an initialization in the reset portion > of the process. So as soon as I enter the assignment, it would take > me to the appropriate spot for the definition and start it for me to > complete followed by the same for the initialization in the reset > section of the process. > > If I am typing a "with" statement, I want the software to see the word > "with" and put the rest of the structure on the screen for me to fill > in the blanks. I find all the typing to be tedious and error prone, > not to mention that after all these years, I still don't have the > syntax memorized and keep a small stack of books by my elbow. Yeah, intelliSense does this for many contexts. Though it sounds like you additionally want some form of AutoCompletion, combined with context-sensitive editing.Article: 133245
On Sun, 22 Jun 2008 07:01:10 -0700 (PDT), ertw <gill81@hotmail.com> wrote: >Hi, I am planning to read an image sensor using an FPGA but I am a >little confused about a bunch of things. Hopefully someone here can >help me understand the following things: > >Note: The image sensor output is an ANALOG signal. Datasheet says that >the READOUT clock is 40MHz. It somewhat depends on whereabouts in the sensor's output signal processing chain you expect to pick up the signal. Is this a raw sensor chip that you have? Is it hiding behind a sensor drive/control chipset? Is it already packaged, supplying standard composite video output? > >1. How is reading of an image sensor using an ADC different then >reading a random analog signal using an ADC? You're right to question this. Of course, at base it isn't - it's just a matter of sampling an analog signal. But the image sensor has some slightly strange properties. First off, the analog signal has already been through some kind of sample- and-hold step. In an idealised world, with a 40 MHz readout clock, you would expect to see the analog signal "flat" for 25ns while it delivers the sampled signal for one pixel, and then make a step change to a different voltage for the next pixel which again would last for 25ns, and so on. In the real world, of course, it ain't that simple. First, you have the limited bandwidth of the analog signal processing chain (inside the image sensor and its support chips) which will cause this idealised stair-step waveform to have all manner of non-ideal characteristics. Indeed, if the output signal is designed for use as an analog composite video signal, then it will probably have been through a low-pass filter to remove most of the staircase-like behaviour. Second, even before the analog signal made it as far as the staircase waveform I described, there will be a lot of business about sampling and resetting the image sensor's output structures. In summary, all of this stuff says that you should take care to sample the analog signal exactly when the camera manufacturer tells you to sample it, with the 40 MHz sample clock that they've so thoughtfully provided (I hope!). > And the amount of data or memory required can be calculated >using: > Sampling rate x ADC resolution > > - This is different in case of an image sensor Of course it is not different. If you get 16 bits, 40M times per second, then you have 640Mbit/sec to handle. > Do I use an ADC running at 40 MSamples/second since the > pixel output 40 MHz ? If the camera manufacturer gives you a "sampled analog" output and a sampling clock, then yes. On the other hand, if all you have is a composite analog video output with no sampling clock, you are entirely free to choose your sampling rate - bearing in mind that it may not match up with pixels on the camera, and therefore you are trusting the camera's low-pass filter to do a good job of the interpolation for you. > How do I calculate the required memory ? > > Is it simply 40 MS/s x 16 bits (adc resolution) for each pixel eh? >or just 16 bits per pixel ? Only the very highest quality cameras give an output that's worth digitising to 16 bit precision. 10 bits should be enough for anyone; 8 bits is often adequate for low-spec applications such as webcams and surveillance. > If each frame is 320 x 256 then data per frame is - (320x256) x >16 bits, why not multiple this by 40 MS/s like > you would for any other random analog signal ? I have no idea what you mean. 40 MHz is the *pixel* rate. Let's follow that through: 40 MHz, 320 pixels on a line - that's 8 microseconds per line. But don't forget to add the extra 2us or thereabouts that will be needed for horizontal synch or whatever. Let's guess 10us per line. 256 lines per image, 10us per line, that's 2.56 milliseconds per image - but, again, we need to add a margin for frame synch. Perhaps 3ms per image. Wow, you're getting 330 images per second - that's way fast. But whatever you do, if you sample your ADC at 40 MHz then you get 40 million samples per second! ~~~~~~~~~~~~~~~~~~~~~~~ More questions: What about colour? Or is this a monochrome sensor? Do you get explicit frame and line synch signals from the camera, or must you extract them from the composite video signal? Must you create the camera's internal line, pixel and field clocks yourself in the FPGA, or does the camera already have clock generators in its support circuitry? ~~~~~~~~~~~~~~~~~~~~~~ You youngsters have it so easy :-) The first CCD camera controller I did had about 60 MSI chips in it, an unholy mess of PALs, TTL, CMOS, special-purpose level shifters for the camera clocks (TSC426, anyone?), sample-and-hold and analog switch devices to capture the camera output, some wild high-speed video amplifiers (LM533)... And the imaging device itself, from Fairchild IIRC, was only NTSC-video resolution and cost around $300. Things have moved on a little in the last quarter-century... -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 133246
On Jun 21, 11:37 pm, RL <r...@null.void.test> wrote: > Muzaffer Kal wrote: > > On Sun, 22 Jun 2008 16:43:17 +1200, RL <r...@null.void.test> wrote: > >> My first questions, of which I hope there won't be many, relate to > >> connecting 'wires' between modules, and simulations. > > > I'm afraid, by looking at your first question, you'll have many more; > > which is OK but asking all of them to the Internet may not be the most > > efficient way to get them answered. Maybe a Verilog book? > > Thanks for your assistance. I'll give it a try when I get time (tomorrow > afternoon). > > I've been looking around for good tutorials, but unfortunately most seem > to assume I come from an electronics background. Books will likely have > a similar focus. > > Fortunately what I need to do isn't particularly complicated. It is very > basic serial communications and simple data manipulation, so basic > Verilog should get me a long way. If I do make some progress, and am > comfortable working with hardware concepts (I come from a C development > background), then I'll probably end up buying a book to further my > knowledge. > > Thanks, > > RL You may want to take a look at some example designs to get an idea of how to code in Verilog. Opencores has lots of projects that you can look at. Bear in mind that the quality of the projects vary, so don't take them as gospel - use them to get a flavor of what's required. Something beginners don't realize is that some Verilog constructs don't synthesize into hardware - they're mainly used for simulations. Good luck! John ProvidenzaArticle: 133247
Hi all, I have a camera and a Virtex-5 FPGA, and i would like to store frames in FPGA Block Ram. In my design (that worked with Spartan-3E) i need to double camera clock frequency, in order to get all data, because camera send data on both clock edges. The problem is the following: I can't use DCM, because camera clock frequency is about 163 ns (~6 Mhz), and when I'm trying to generate DCM (selecting Maximum Range Mode) , Xilinx Clock Wizard says that "DLL Low Frequency Mode Range is: 19-32 Mhz, and DFS Low Frequency Mode Range is 1-40 Mhz". How can I avoid this problem? Do you think that I could use component DCM of Unisim Library? Moreover, isn't there a VHDL 2X Clock Multiplier that works fine? GiulioArticle: 133248
On Jun 22, 6:20=A0pm, techG <giuliopul...@gmail.com> wrote: > In my design (that worked with Spartan-3E) i need to double camera > clock frequency, in order to get all data, because camera send data on > both clock edges. Have you looked into DDR flip-flops? Those should allow you to read data coming in on both clock edges at the regular clock frequency. Check out the Virtex 5 IDDR input primitive. Regards, -- Hauke DArticle: 133249
On Jun 22, 8:36 am, jprovide...@yahoo.com wrote: > On Jun 21, 11:37 pm, RL <r...@null.void.test> wrote: > > > > > Muzaffer Kal wrote: > > > On Sun, 22 Jun 2008 16:43:17 +1200, RL <r...@null.void.test> wrote: > > >> My first questions, of which I hope there won't be many, relate to > > >> connecting 'wires' between modules, and simulations. > > > > I'm afraid, by looking at your first question, you'll have many more; > > > which is OK but asking all of them to the Internet may not be the most > > > efficient way to get them answered. Maybe a Verilog book? > > > Thanks for your assistance. I'll give it a try when I get time (tomorrow > > afternoon). > > > I've been looking around for good tutorials, but unfortunately most seem > > to assume I come from an electronics background. Books will likely have > > a similar focus. > > > Fortunately what I need to do isn't particularly complicated. It is very > > basic serial communications and simple data manipulation, so basic > > Verilog should get me a long way. If I do make some progress, and am > > comfortable working with hardware concepts (I come from a C development > > background), then I'll probably end up buying a book to further my > > knowledge. > > > Thanks, > > > RL > > You may want to take a look at some example designs to get an idea of > how to code > in Verilog. Opencores has lots of projects that you can look at. > Bear in mind that the > quality of the projects vary, so don't take them as gospel - use them > to get a flavor > of what's required. > > Something beginners don't realize is that some Verilog constructs > don't synthesize into > hardware - they're mainly used for simulations. > > Good luck! > > John Providenza You may be able to take free online courses at the FPGA/CPLD vendor whose part you have on your board... e.g. http://www.altera.com/education/training/courses/OHDL1120 Just a reminder though - when you design something meaningful with verilog you are designing hardware and not software. So very soon it will help you to also pick up the fundamentals of the digital logic design and hardware design practices otherwise it can get to be very frustrating.
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