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
it.stein@gmail.com wrote: > I would to interface a CMOS image sensor to my FPGA. I'm looking for > low-end sensor and a matching lens. Nothing fancy or several mega > pixels - just the bare minimum. We were looking for something similar like a mobile phone camera, but you can't get them in low quantities and they have a very short lifetime. ST seems to address this market now - look at http://www.st.com/stonline/products/families/imaging/imaging.htm Can't give you a lot of experience yet, we're just evaluating. - Philip -- I wouldn't recommend sex, drugs or insanity for everyone, but they've always worked for me. (Hunter S. Thompson)Article: 116326
http://www.amis.com/products/image_sensors/index.html http://www.rohm.com/products/shortform/14sensor/sensor_index.html <it.stein@gmail.com> wrote in message news:1173266549.653061.246930@8g2000cwh.googlegroups.com... > Hi everyone, > > I would to interface a CMOS image sensor to my FPGA. I'm looking for > low-end sensor and a matching lens. Nothing fancy or several mega > pixels - just the bare minimum. Do any of you have a few links to > vendors or distributors? It doesn't seem to be an "off the shelf" > product. > > Thank you very much. > Regards > - Stein >Article: 116327
Hi, I m doing a project on "IEEE 802.3 Packet generator on FPGA".The details of my project are as follows There are two swithes on the FPGA to input 4 different lengths of data between 0 to 1500bytes.if a particular input is set, for eg 60bytes,then the controller should generate data of 60 bytes.so, i need to design a generalised controller that will accept data of 4 different lengths and generate the data depending on that length.i have to write a code in vhdl.Plz help me to design the controller I m not getting data from any source.i have to generate random data.Its something like i m developing a smart bits generator on FPGA.I have to generate the data in IEEE 802.3 format.So, the controller which is to b designed has to send the control and timing signals to activate the different fields in the frame format.Different fields in the sense first preamble should come which should b of 7bytes.Then start of frame delimiter and so on. But one thing i want to know is whether i need to design a random number generator for generating data or there is any other method to generate rendom data.And after generating the data,do i need to store that in a memory and then transmit?Do i need to generate the preamble also? Please give me guidelines for finalising the designs Is the spec what i have got is enough?? If not,then what else is required? it might b a silly question.I m a fresher so i dont have an idea of whatelse is required.plz help me. Plz help me in this regard. Plz Its very urgent ThanksArticle: 116328
<pra.vlsi@gmail.com> wrote in message news:1173269021.700256.96120@t69g2000cwt.googlegroups.com... > > I m not getting data from any source. > I wouldn't be too hopeful of getting any data with this type of posting either! > >i have to generate random data. > But wait, perhaps you could generate random data from the content of homework questions posted on usenet. The sheer cheek of students asking folks to do their work for them for free implies a randomness of thought which should be reflected in their postings. Also, their spolling and caPITaliSation is atroshus, which should plz your rendom nuber generator. Lots of love, Syms.x p.s. For anyone who's interested in a proper random number generator, a search for random webcam smoke alarm gives interesting results.Article: 116329
On Mar 7, 6:51 am, "Rob" <robns...@frontiernet.net> wrote: > http://www.amis.com/products/image_sensors/index.html > > http://www.rohm.com/products/shortform/14sensor/sensor_index.html > > <it.st...@gmail.com> wrote in message > > news:1173266549.653061.246930@8g2000cwh.googlegroups.com... > > > Hi everyone, > > > I would to interface a CMOS image sensor to my FPGA. I'm looking for > > low-end sensor and a matching lens. Nothing fancy or several mega > > pixels - just the bare minimum. Do any of you have a few links to > > vendors or distributors? It doesn't seem to be an "off the shelf" > > product. > > > Thank you very much. > > Regards > > - Stein http://dkc3.digikey.com/PDF/T071/0583.pdfArticle: 116330
"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message news:1173140726.435538.84620@30g2000cwc.googlegroups.com... > Hi, > I am very confused with latch generation in VHDL. > > 1. I have been using VHDL for 7 years and I have never met a situation > I need a latch. > Just thought I'd add to this thread that, all other things being equal, latches generally have less setup time than FFs. This can be important for some circuits. HTH, Syms.Article: 116331
> Ahh, yes I can see that being a problem! In that case, SCons looks > like it could be a good route, it certainly looks a lot more flexible > than make, but it may have a bigger learning curve (!) At least by learning SCons I'll be learning some Python (hopefully) as well. > What source language are you using? I can see that it might be tricky > to teach SCons how to deal with VHDL, given that entities and archs > are unrealted by name to the file they exist in. Finding C > dependencies by header file name is a little easier! > > But Make will be no easier! I'm using VHDL. If I could make SCons smart enough to figure out dependencies automatically that would be nice but I'm not looking for something that smart. Actually I don't want something that smart. I want complete control over source files dependencies, even if that means that I must specify them explicitly myself. > If using VHDL, maybe you could create a Compiler target for Emacs' > vhdl-mode that runs XST (for example) instead of Modelsim's vcom etc. I keep hearing about Emacs vhdl-mode but I'm not using it at the moment. I might give it a try when I have more spare time. Thanks for the suggestion. Regards, PatrickArticle: 116332
On Mar 7, 3:02 am, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Weng Tianxiang" <wtx...@gmail.com> wrote in message > > news:1173237015.878201.302510@p10g2000cwp.googlegroups.com...> 1. Q <= (C and D) or (not(C) and Q); > > I have never seen such equation in my coding experiences and have no > > idea how this equation would be written. The logic result is beyond a > > reason. Could you please write it in equivalent latch equation in > > informal VHDL? > > It's the same old transparent latch that we've been talking about all along. > The following forms are exactly equivalent logic and will result in the > exact same synthesized result. > #1 -- Traditional form of writing a latch > process(C, D) > begin > if (C='1') then > Q <= D; > end if; > end process; > > #2 -- Another traditional form of writing a latch. > Q <= D when (C = '1'); > > #3 -- Latch equations written as a sum of products > Q <= (C and D) or (not(C) and Q); > > #4 -- Latch equation written in a sum of products form that includes a > 'cover' term > Q <= (C and D) or (not(C) and Q) or (D and Q); > > Try all four of the above out and run them through synthesis and you should > get the exact same fitted equations for all 4. > > Of the four different forms, only #4 is written in a way that will not have > timing issues that are caused simply by the implementation (over which you > have no real control in an FPGA). However, the last term ".. or (D and Q)" > is redundant and any synthesizer worth a dime will 'optomize the logic' and > implement it as form #3. This 'optomization' though creates a logic hazard > when 'C' switches from '1' to '0'. This logic hazard will in turn show up > as a failure in the latch operation. Specifically, what you'll run into is > that even if you have 'D' set up oodles of time before 'C' switches from '1' > to '0', the output 'Q' can latch itself at either '1' or '0' (depending on > the targetted part) because of differences in prop delay in computing the > first two or terms or glitches in 'C'. That last "D and Q" term is > absolutely required in order to even have a shot at inferring a latch that > will actually work but since it is logically 'redundant' it will always get > optomized away. If you hark back to Boolean Logic 101, you may recall that > adding redundant terms is the method you employ to get rid of logic hazards. > The FPGA LUT implementation leaves even more to the imagination as you > wonder just what those RAM outputs are doing with this combinatorial loop > and whether 'Q' will glitch and cause even more havoc since it would feed > back to the address input of the LUT. > > The bottom line is > - There are various forms of writing source code that infers a latch. > - Whether a latch is a 'good' thing or a 'bad' thing depends on the > targetted device itself and whether that device actually has a hard latch > and a way to guarantee the timing and glitch requirements of 'D' and 'C'. > - Inferring any storage element (flops, latches, memory) needs to be done in > such a way that the storage is not implemented as a collection of > LUTs/macrocells but instead uses hard storage resources of the device. > > > > > 2. FPGA of Xilinx chip really has latch primative and one may use it > > using latch primative to call it. But it is hard to refer to it in > > VHDL. > > You'll still have trouble meeting and guaranteeing the timing and glitch > requirements on 'D' relative to 'C' in order to get it to work correctly for > arbitrary signals 'D' and 'C'. If it does work, it likely won't scale well > (i.e. if you try to infer thousands of these as you would like to) > > > I don't mean VHDL should have included latch statement, what I > > mean is VHDL really lacks the statement element to refer to a latch in > > a clear and reliable way and the lack can be easily corrected. > > I've shown above four different forms for inferring the exact same latch > (i.e. synthesizes to the exact same thing). Which form you prefer (or if > you prefer to make up your own) to use is up to you. Making up a new method > though will not prohibit the earlier forms from being used and outlawing the > other forms gets in the way of people who do use latches and are doing so in > a way that they can control the various issues so you're not helping them by > outlawing their method. > > Kevin Jennings Hi KJ, Thank you very much for your points. Your answer really opens my eye and expand my knowledge range in FPGA and VHDL !!! WengArticle: 116333
On Mar 7, 4:31 am, "Symon" <symon_bre...@hotmail.com> wrote: > p.s. For anyone who's interested in a proper random number generator, a > search for > > random webcam smoke alarm > > gives interesting results. I was sure you were just joking, but that *is* fairly interesting! Alan NishiokaArticle: 116334
Alan, A bit on the slow side, but it sure is random! AustinArticle: 116335
Hi :
i am using ise 9.1i to run my designs which containted lvds .
In my ucf file , there are constrains like NET "Ring_In_P[47]"
IOSTANDARD = LVDS_25_DCI;
but later on in phase of map of ise , it reported the following error:
Phase 7.5
ERROR:Place:865 - Incompatible IOB's are range constrained to the same
bank 2
Conflicting IO Standards are:
IO Standard 1: Name = LVDS_25_DCI, VREF = NR, VCCO = 2.50, TERM =
SPLIT
List of range constrained IOB's:
Ring_In_P[0]
Ring_In_N[0]
.........
IO Standard 2: Name = LVDS_25_DCI, VREF = NR, VCCO = 2.50, TERM =
SPLIT
List of range constrained IOB's:
Ring_In_P[11]
Ring_In_N[11]
Ring_In_P[30]
.............
These IO Standards are incompatible due to DCI termination
mismatch.
But how should i fix it ?btw, if i use ise8.1, no such a problem . It
seemed to be ise91's bug? Any help would be appreciated !
mini_monkey
Article: 116336On Mar 7, 5:19 pm, Austin Lesea <aus...@xilinx.com> wrote: > Alan, > > A bit on the slow side, but it sure is random! > > Austin just get a stronger americium source :p is it just me or is usenet getting full of asian sounding names with gmail accounts asking for complete solutions to problems they have hardly tried to understand themselfs ? -LasseArticle: 116337
On Mar 7, 5:57 am, "Symon" <symon_bre...@hotmail.com> wrote:> > Just thought I'd add to this thread that, all other things being equal, > latches generally have less setup time than FFs. This can be important for > some circuits. > HTH, Syms. Symon, I disagree. The set-up time of a flip-flop is really the set-up time of the master latch (the last chance for input data to become locked up in the latch when the clock is going High.) The flip-flop's slave latch has nothing to do with the set-up time. Therefore I see no reason for the flip- flop to have a longer set-up time than a simple latch. The evidence seems to be anecdotal... Peter AlfkeArticle: 116338
Hello, Bill: Thank you very much for your response. Buf after I set up the enviroment variable and run the route again, I got the same error several hours later. What can I do? I will set the DCM as the top level file and try.Article: 116339
Lasse, As far as I am concerned, the questions come from students of engineering who will someday soon be designing with FPGAs. I would hope they consider Xilinx when they make their choice of vendors. AustinArticle: 116340
On Mar 7, 4:52 pm, langw...@ieee.org wrote: > is it just me or is usenet getting full of asian sounding names with > gmail accounts asking for complete solutions to problems they have > hardly tried to understand themselfs ? > > -Lasse Not just that. More often, we'r seeing images in media of asian- looking chap staring at a PCB or something in indication of "cutting- edge" intelligence to which everybody should aspire. Even empolyers are becoming more inclined to believe in you provided that you possess "certain" attributes. Cheers, -MannyArticle: 116341
pra.vlsi@gmail.com wrote: > I have to write a code in vhdl.Plz help me to design the controller See the reference design and testbench here http://home.comcast.net/~mike_treseler/ for some related examples. > Is the spec what i have got is enough?? If not,then what else is > required? it might b a silly question.I m a fresher so i dont have an > idea of whatelse is required.plz help me. You will have to learn vhdl simulation. It sounds to me like you are in water over your head. Consider dropping the class. -- Mike TreselerArticle: 116342
"Peter Alfke" <peter@xilinx.com> wrote in message news:1173287136.833622.29220@v33g2000cwv.googlegroups.com... > On Mar 7, 5:57 am, "Symon" <symon_bre...@hotmail.com> wrote:> >> Just thought I'd add to this thread that, all other things being equal, >> latches generally have less setup time than FFs. This can be important >> for >> some circuits. >> HTH, Syms. > > Symon, I disagree. > The set-up time of a flip-flop is really the set-up time of the master > latch (the last chance for input data to become locked up in the latch > when the clock is going High.) The flip-flop's slave latch has nothing > to do with the set-up time. Therefore I see no reason for the flip- > flop to have a longer set-up time than a simple latch. The evidence > seems to be anecdotal... > Peter Alfke > > Hi Peter, Yes, thinking about it again, you're absolutely right. I dredged back though my memory and the situation I so badly recalled was a double data rate circuit near the toggle limit of the part. I needed to synchronise phase alignment between two signals, one in the rising and one in the falling edge clock domains. To do this I had the output of a falling edge FF feeding the input of a rising edge FF. By changing the falling edge FF to a latch (transparent when clock is high), I gained extra set-up time for the rising edge FF, as the latch passed data through a little earlier. Many thanks for correcting me, and putting the record straight. Best regards, Symon.Article: 116343
Hello, Bill: Thank you very much for your response. Buf after I set up the enviroment variable and run the route again, I got the same error several hours later. What can I do? When I set the DCM as the top file and do the implementation, the .bit file can be generated successfully. But when I put my vhdl files (include dcm3.vhd) as a uer define core in the EDK, I always got the above error. The system in the EDK also incudes a DCM. Is there something wrong as shown: BEGIN dcm_module PARAMETER INSTANCE = dcm_0 PARAMETER HW_VER = 1.00.a PARAMETER C_CLK0_BUF = TRUE PARAMETER C_CLKDV_BUF = TRUE PARAMETER C_CLKDV_DIVIDE = 5.000000 PARAMETER C_CLKIN_PERIOD = 10.000000 PARAMETER C_CLK_FEEDBACK = 1X PARAMETER C_DLL_FREQUENCY_MODE = LOW PARAMETER C_EXT_RESET_HIGH = 1 PORT CLKIN = dcm_clk_s PORT CLKDV = sys_clk_s PORT CLK0 = dcm_0_FB PORT CLKFB = dcm_0_FB PORT RST = net_gnd PORT LOCKED = dcm_0_lock ENDArticle: 116344
On Mar 6, 7:46 pm, "Peter Alfke" <a...@sbcglobal.net> wrote: > On Mar 6, 7:28 pm, "Weng Tianxiang" <wtx...@gmail.com> wrote: > > > On Mar 6, 2:14 am, "wojt" <wojtek.bo...@gmail.com> wrote: > > >> Hi Wojt, > > 1. 'Single-Port Block Memory' means the RAM block cannot do read and > > write at the same clock. If your design cannot guarantee this > > principle, your choosing single-port is wrong and you have to switch > > to dual-port block memory ram. > > This is a wrong statement. > Each port of the BlockRAM has independent write and read data lines. > When data is being written into the port (WE active) then the data > output has 3 choices: either reflect the data being written (write > first) or reflect the previous content of the addressed location, > before it was being overwritten (read first) or keep the output the > way it was (no change) This describes Virtex-4 and Virtex-5 BRAM > behavior. Older Virtex BRAMs do not have the read-first option. > The other memory port has the same array of choices, since the two > ports are independent, sharing only the stored data. > Only when both ports happen to address the same location, is the > timing somewhat demanding... > Peter Alfke > > > > - Hide quoted text - > > - Show quoted text - Hi Peter, You are right. I mixed two things: single-port distributed ram and dual-port distributed ram with their block ram. My claim is true when read and write cannot happen at the same clock with single-port dristributed ram, not with single-port block ram. I have just finished a new project successfully that uses single-port distributed ram and purposely added logic to avoid read and write from happening at the same clock. Thank you. WengArticle: 116345
"Symon" <symon_brewer@hotmail.com> wrote in message news:esmu00$mnc$1@aioe.org... > Hi Peter, > Yes, thinking about it again, you're absolutely right. I dredged back > though my memory and the situation I so badly recalled was a double data > rate circuit near the toggle limit of the part. I needed to synchronise > phase alignment between two signals, one in the rising and one in the > falling edge clock domains. To do this I had the output of a falling edge > FF feeding the input of a rising edge FF. By changing the falling edge FF > to a latch (transparent when clock is high), I gained extra set-up time > for the rising edge FF, as the latch passed data through a little earlier. > Many thanks for correcting me, and putting the record straight. > Best regards, Symon. I've come up with this approach myself, subsequently seen it mentioned in an app note, and now find you've concluded the same circuit is useful in this situation. More engineers should be exposed to this one application where a latch is indespensible. Without it, DDR domains can get messy. The one sad thing about it, in my opinion, is that the Xilinx timing tools don't treat this case well. My recollection is that the setup is referenced to the wrong edge giving me no chance to get clean numbers by only including latch_d_q path tracing. - John_HArticle: 116346
Hi, I just got a newsletter stating the Spartan3AN being available now. While these Spartan3AN are market as "new non-volatile" FPGAs, this might (IMHO) be misleading. For my understanding "non-volatile" would mean no configuration on power-ON (as e.g. ACTEL AntiFuse) rather than Config-Eprom being integrated in FPGA chip's housing (being a separate die as well). Nevertheless this definitely is a nice appraoch, saving space and copper traces on PCB. As always, as soon as the new chip is on market the question on next enhancements arises. Any truth in rumors stating next generation Spartan (or what it will be called) has integrated Analog-Digital Converters? CU, Carlhermann SchlehausArticle: 116347
On Mar 7, 10:41 am, "John_H" <newsgr...@johnhandwork.com> wrote: > "Symon" <symon_bre...@hotmail.com> wrote in message > > news:esmu00$mnc$1@aioe.org... > > > Hi Peter, > > Yes, thinking about it again, you're absolutely right. I dredged back > > though my memory and the situation I so badly recalled was a double data > > rate circuit near the toggle limit of the part. I needed to synchronise > > phase alignment between two signals, one in the rising and one in the > > falling edge clock domains. To do this I had the output of a falling edge > > FF feeding the input of a rising edge FF. By changing the falling edge FF > > to a latch (transparent when clock is high), I gained extra set-up time > > for the rising edge FF, as the latch passed data through a little earlier. > > Many thanks for correcting me, and putting the record straight. > > Best regards, Symon. > > I've come up with this approach myself, subsequently seen it mentioned in an > app note, and now find you've concluded the same circuit is useful in this > situation. > > More engineers should be exposed to this one application where a latch is > indespensible. Without it, DDR domains can get messy. > > The one sad thing about it, in my opinion, is that the Xilinx timing tools > don't treat this case well. My recollection is that the setup is referenced > to the wrong edge giving me no chance to get clean numbers by only including > latch_d_q path tracing. > > - John_H Hi John, Could you please tell which application note you are talking about. Thank you. WengArticle: 116348
Assume we have this VHDL model
process(sig) begin
if ( sig = '1' ) then
q <= '1';
elsif ( sig'event and sig = '0' ) then
if ( cke = '1' ) then
q <= 0;
end if;
end if;
end process;
Modelsim shows it working fine but you may have better judgment for
this code. Is there anything wrong, or setup time violation?
Thanks
Article: 116349I personally see the FPGAs following a road that leads them to looking a lot like microcontrollers but with FPGA fabric where the processor is. ---Matthew Hicks > Hi, > I just got a newsletter stating the Spartan3AN being available now. > While > these Spartan3AN are market as "new non-volatile" FPGAs, this might > (IMHO) > be misleading. For my understanding "non-volatile" would mean no > configuration on power-ON (as e.g. ACTEL AntiFuse) rather than > Config-Eprom > being integrated in FPGA chip's housing (being a separate die as > well). > Nevertheless this definitely is a nice appraoch, saving space and > copper > traces on PCB. > As always, as soon as the new chip is on market the question on next > enhancements arises. Any truth in rumors stating next generation > Spartan (or > what it will be called) has integrated Analog-Digital Converters? > CU, Carlhermann Schlehaus >
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