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
Hello everybody,
I am trying to connect a 2 Meg pixel PixelPlus
camera with a XUPV2P board based on Virtex 2P. The camera PCB has male
connectors and tried connecting it using black tape. But when I read
back from the expansion ports in the FPGA I found the signals not
coming from the camera PCB. Anybody has any similiar experiences with
interfacing a camera with FPGA ? What sort of socket/placeholder was
used for hooking up the camera?
Thanks a lot in advance.
Koustav
Article: 121276"Jon Beniston" <jon@beniston.com> wrote in message news:1183133181.732700.262600@q69g2000hsb.googlegroups.com... > > always @(posedge clk) > > begin > > > > if (ce) > > q <= d; > > > > end > > Omitting an else here is fine if you ask me. > > Cheers, > Jon ThanksArticle: 121277
"John_H" <newsgroup@johnhandwork.com> wrote in message news:138af86nl08qp2d@corp.supernews.com... It *is* safe to assume that no latch is inferred when there's already a flop that stores the value. The latches in combinatorial equations are because the LHS or combinatorial output relies on itself as a combinatorial input in the RHS. In sequential logic, the new register value depends on the onld register value and nowhere tries to assign the new value based on the new value which *would* generate a latch. Your figure B always holds true always because the implied "q <= q" in the absent else clause is effectively "next_q <= prev_q" rather than "next_q <= next_q" which is *not* implied. The sequential logic LHS equation is always the value after the clock edge. The sequential logic RHS is always the value before the clock edge. Everything flows nicely. - John_H GoodArticle: 121278
I also had trouble reading the schematic. Here is my solution: Use a pnp bipolar transistor, any one will do. Connect the emitter to the FPGA/CPLD output. Connect the collector through 200 Ohm to the negative voltage (-1.3 V) Connect the base through a 1000 Ohm resistor to ground. This structure is non-inverting and does not amplify the current. The output rise time is very fast, the fall time depends on the capacitive load. e.g. 200 Ohm x 20 pF = 4 ns Peter Alfke, Xilinx Applications On Jun 29, 8:40 am, "John_H" <newsgr...@johnhandwork.com> wrote: > <Albert Nguyen> wrote in messagenews:eea7b1c.13@webx.sUN8CHnE... > > Ben, > > > I did a little reading on the bipolar transistors and made some > > calculations to figure out the base resistor value. But my caluclation > > does not match the base resistor value of 1K. > > > Icollecor = (1.2-(-1.3))/500 > > > = 2.5/500 > > > = 5 mA > > > IBase = 0.7/28.6 = 0.0244 Amps > > > If the FPGA is driving 3.3V signal then > > > Rbase = (3.3 - 0.7)/0.0244 > > > = 106 Ohm. > > > You mentioned about using 1K Ohm base resistor but as per my calucaltion > > it needs to be about 106 Ohms if the FPGA is driving 0 to 3.3V signals. > > > Thus Rcollector = 500 Ohms and R base = 106 Ohms. > > > Does this make sense? > > > Thanks. > > > Albert > > Read further on "current gain" or Hfe, alpha, or Beta for transistors. The > transistor you choose will affect the level of current gain for your > calculation. Another thing to read up on is "saturation" where you can > start to understand how much base overdrive gives you what saturation > voltage, information also found in the transistor data sheet.Article: 121279
I am using four GTP transceivers of V5 LXT 110T FPGA. I used coregen to create the verilog output. When I looked at the verilog output, the 200MHz reference clock was fed to the GTP tile from the differential clock input reference pins. The clock connection looks like this: Input pin to Tile0 Input clock pin Tile0 output to Bufg input Bufg output to PLL input. Pll generates two outputs: (1) One clock is fed back to the tile (2) Second clock is used by the FPGA fabric to feed the data to the transceivers My questions are: (1) Why PLL is needed in this and is fed back to the Tile. The PLL is not really multiplying or dividing the clock in this case. Virtex 5 has very limited PLL resources. I would like to avoid using PLL for this. Is there an alternative? (2) why the second clock output from the PLL which used by the FPGA farbic is not assigned a bufg? The coregen uses this to clock out the data from BRAM but in a real application, it may have more loads. Why BUFG is not used here but is used to feed only one clock from the tile to the PLL? EddieArticle: 121280
On 6 28 , 12 34 , gamer <csan...@gmail.com> wrote:
> My goal is to implement a bit-error counter targeting 1GHz. The
> datawidth is parametrizable. I started off this way,
>
> Verilog code:
> ----------
> assign mismatch[datawidth-1:0] = input_data ^ expected_data;
> assign matched = ~( | mismatch); // reduction NOR
>
I guess the critical path of timming is summation chain.
There're serveral binary tricks to get number of bit "1" in a word,
take C code of 32-bit word for example, there's only 5 summations
instead of 32.
unsigned int bitcount32(unsigned int x)
{
x = (x & 0x55555555UL) + ((x >> 1) & 0x55555555UL); // 0-2 in 2
bits
x = (x & 0x33333333UL) + ((x >> 2) & 0x33333333UL); // 0-4 in 4
bits
#if 1
// Version 1
x = (x & 0x0f0f0f0fUL) + ((x >> 4) & 0x0f0f0f0fUL); // 0-8 in 8
bits
x = (x & 0x00ff00ffUL) + ((x >> 8) & 0x00ff00ffUL); // 0-16 in 16
bits
x = (x & 0x0000ffffUL) + ((x >> 16) & 0x0000ffffUL); // 0-31 in 32
bits
return x;
#else
// Version 2
x = (x + (x >> 4)) & 0x0f0f0f0fUL; // 0-8 in 4 bits
x += x >> 8; // 0-16 in 8 bits
x += x >> 16; // 0-32 in 8 bits
return x & 0xff;
#endif
}
> always @(posedge clk or posedge reset) begin
> if (reset)
> error_count = 0;
> else if (~matched)
> for (i=0; i<datawidth; i=i+1)
> error_count = error_count + mismatch[i];
> end
> ---------/////////----------------------
> The above meets timing for small datawidths (like 8-bits) and starts
> failing to meet timing once the datawidth gets larger. I will be glad
> for suggestions of alternate ways to implement this bit-error counter.
> In practice our datawidths could go upto 256 bits.
>
> Thanks
Article: 121281On Thu, 28 Jun 2007 11:02:38 +0200, "Ulrich Bangert" <df6jb@ulrich-bangert.de> wrote: >Gents, > >please allow me to confront you with some strange timing behaviour which I >have measured with an Xilinx XC95108 cpld. > >Consider two well conditioned clock signals of 10 MHz (both having EXACTLY >the same frequency) entering the cpld. Inside the cpld each clock signal is >divided by 4 by means of two d-flip-flops. The two resulting 2.5 Mhz signals >enter an exclusive-or-gate which delivers an output signal where the >pulse/pause-relationship directly depends on the phase relationship of the >two input clocks. > >If some of you feel reminded to something that you have seen before: Yes, >basically this is the principle of an so called linear phase comparator >which has been used to compare high stability clocks (for example cesium >clocks) against each other before high resolution time interval counters >like the HP5370 or the Stanford Research SR620 were available. > >Now imagine one of the two clocks is de-tuned by exactly 0.001 Hz. It is a >bit beyond the discussion HOW this is achieved but you may believe me that >this is possible and that THIS is not part of the discussed problem. Now the >phase relationship of the clocks changes slowly in time as does the >pulse/pause relationship behind the xor gate. The pulse/pause relationship >of the xor's output can be measured by two completely different methods: > >a) by generating an dc voltage which is directly proportional to the >pulse/pause relationship (again a bit tricky if you want it to be an really >high resolution measurement, but it can be done) > >b) by directly measuring the output pulse width with an high resolution time >interval counter like the SR620 having a 25 ps single shot resolution for >time interval measurements. > >It is important to note that both methods to measure can be applied at the >same time and that both methods (although based on completely different >physical laws) deliver results that despite some statistical fluctuations >are basically the same. That is why I am pretty sure that what I measure is >really an property of the signal itself and not one of the measurement >apparatus. > >If I record the pulse width over time using the two methods and display it >graphically it looks like an pretty linear relationship at the first glance. >If however some math is applied to make it evident how good the linear >relationship really is met then the result is that there are fluctuations in >the pulse width in the order of some +/-450 ps from the expected values. > >About these fluctuations the following facts are known: > >1) They are not existent in the inputs clocks > >2) Expressed in time units as well as expressed as an dc voltage the >fluctuations are orders of magnitude bigger than the resolution and >precision of the time/dc measurement. > >3) The fluctuations are by no means of stochastical nature. Instead, If an >positive fluctuation is noticed at an certain phase between the clock >signals, an fluctuation of the same magnitude and sign will be noticed the >next time when the clock signals have the same phase relationship. Or in >other words: The pulse width is an direct function of the phase relationship >of the clocks + an error function which is an direct function of the phase >relationship between the clocks. > >It seems as if the phase state of one of the signals can have an linear like >modulating effect on the phase state of the second signal (and perhaps vice >versa). Some of you may come to the conclusion that +/-450 ps is not an >number to cause real world troubles but in my case: The whole arrangement >has the intention to measure phase fluctuations of the input clocks that ARE >REALLY THERE but that are smaller at least one order of magnitude than the >noticed errors. And that is why +/-450 ps is an real annoying number for me. > >Any hint will be highly appreciated >TIA, Ulrich Bangert > > > Sounds like crosstalk internal to the cpld, and likely the fact that the xor gate behaves differently in the case where one edge changes, as opposed to when both edges change simultaneously. I'd suggest using discrete logic, ECL or Eclips for serious performance. A d-type flipflop makes a good phase detector, too. JohnArticle: 121282
In comp.arch.fpga Richard Henry <pomerado@hotmail.com> wrote: > On Jun 27, 1:06 pm, Uwe Bonnes <b...@hertz.ikp.physik.tu-darmstadt.de> > wrote: > > In comp.arch.fpga Steve at fivetrees <s...@nospamtafivetrees.com> wrote: > > ... > > > > > To the OP re bidirectional: it's not clear to me whether you expect to > > > run two loops (one outgoing, one incoming), or shove data down one pair > > > of wires in boith directions. If the latter, I'm not clear on where > > > you'd put the receiver load - at both ends? If so, expect to see half > > > the voltage across each receiver. > > > > That's what Bus-LVDS for. > > > > Called also M-LVDS, LVDM or ... > How about a hybrid solution? I don't want to run so many wires (I > don't have room for such a big connector). Could I gang up 4 signals > per pair without a lot of overhead, and still keep it bidirectional? You can use any protocoll and multiplex the lines as you like. But that will need protocoll overhead. Look e.g. at TI or National, what can be done with LVDS. Bus LVDS is anyways a good choice, as is has stronger send levels and more sensitive receive levels. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 121283
I would like to ask some questions regarding a Xilinx JTAG programmer: First, it seems that the programmer doesn't actually connect to the LPT port because of gender mismatch. Luckily I have a parallel port gender changer. Is this still ok? Second point, I connect the programmer and start up xilinx ise and impact. I get a message that many unknown devices are being detected, is this normal? Last point, the download cable seems to be some sort of 2 x 8 block socket, i.e. 16 pins, how do I identify the required pins i.e. vdd,gnd,tdi,tms,tck,tdo? Thanks in advanceArticle: 121284
darrick wrote: > I would like to ask some questions regarding a Xilinx JTAG programmer: > First, it seems that the programmer doesn't actually connect to the LPT > port because of gender mismatch. Luckily I have a parallel port gender > changer. Is this still ok? > Second point, I connect the programmer and start up xilinx ise and impact. > I get a message that many unknown devices are being detected, is this > normal? No. Probably your chain from TDI at the programmer through the devices up to TDO at the programmer is broken somewhere. > Last point, the download cable seems to be some sort of 2 x 8 block > socket, i.e. 16 pins, how do I identify the required pins i.e. > vdd,gnd,tdi,tms,tck,tdo? Carefully check the documents or what els you have. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 121285
> Come on Xilinx. **PLEASE** release some signed hardware drivers!! > Ditto Altera....... Come on Microsoft, let the user do what they want with their _own_ hardware. SylvainArticle: 121286
There is nothing to check, the programmer is connected and that's all. I did not connect anything else.Article: 121287
Does somebody know how to execute (pass) several commands inside xps? Now I invoke xps from a batch file through xps -nw project_dir\system.xmp Then I would like to execute several commands and to exit using commands passed through script file. Is there a way to do, the xilinx docs are not clear for this questions or at least I have not found the right tutorial. Thanks, ZlatkoArticle: 121288
darrick wrote: > I would like to ask some questions regarding a Xilinx JTAG programmer: > > First, it seems that the programmer doesn't actually connect to the LPT > port because of gender mismatch. Luckily I have a parallel port gender > changer. Is this still ok? > It seems to fit all my pcs. What computer are you trying to hook it up to? Do you get an error message about the interface? > Second point, I connect the programmer and start up xilinx ise and impact. > I get a message that many unknown devices are being detected, is this > normal? > When there is no device connected or when there is no power on the connected device, noise seems to generate the unknown devices message. The programmer must be connected to your device and the power must be on for that device. > Last point, the download cable seems to be some sort of 2 x 8 block > socket, i.e. 16 pins, how do I identify the required pins i.e. > vdd,gnd,tdi,tms,tck,tdo? > That is in the documentation. I forget where but that is where I got it from. > Thanks in advance > >Article: 121289
On Wed, 27 Jun 2007 09:09:45 -0700, Andy <jonesandy@comcast.net> wrote: >On Jun 27, 10:39 am, Richard Henry <pomer...@hotmail.com> wrote: >> I need to extend a memory-mapped bus into another enclosure and >> thought that a bidirectional LVDS implementation with serial/ >> deserializer pairs at each end might work. Does anyone have any >> experience or guidance on such a setup? > >LVDS has a really low common mode voltage tolerance, so if you use it >between enclosures, make very sure you have an excellent grounding >scheme and control of return currents between enclosures. Generally >not a good application of LVDS without some means of improving CMV >tolerance. > >Andy Most of the LVDS receivers that we've tested, including the Xilinx Spartan3 parts, seem to behave like excellent, very fast rail-to-rail comparators, at a fraction of the price of an officialy-designated comparator of similar performance. They do generally have a deliberate input offset, in the 10's of millivolts sort of range. Most of them make good zero-crossing detectors, signal on one input pin and ground on the other. Still, one wouldn't want to drive any input hard much beyond its local rails. Return currents? JohnArticle: 121290
On Jun 20, 3:12 am, Jay <jaycp.iit...@gmail.com> wrote: > Hello, > > Can anybody help me with some reference designs, through which I can > get an insight to using UART on Spartan 3E Starter Kit ? I have > downloaded few reference designs which uses UART but I am not getting > exact hands on experience. > > Thanks in advance. > > Jayesh :-| I've successfully used the verilog serial core from OpenCores. Worked fine.Article: 121291
Make sure you don't have the board end connector turned around the wrong way. ---Matthew Hicks > I would like to ask some questions regarding a Xilinx JTAG programmer: > > First, it seems that the programmer doesn't actually connect to the > LPT port because of gender mismatch. Luckily I have a parallel port > gender changer. Is this still ok? > > Second point, I connect the programmer and start up xilinx ise and > impact. I get a message that many unknown devices are being detected, > is this normal? > > Last point, the download cable seems to be some sort of 2 x 8 block > socket, i.e. 16 pins, how do I identify the required pins i.e. > vdd,gnd,tdi,tms,tck,tdo? > > Thanks in advance >Article: 121292
I would like to know why the coregen software uses the PLL to generate the two user clocks - one for the GTP and one for the fpga fabric? There are very limited number of PLLs so why not use the DLL for this task? EddieArticle: 121293
First I need to know where in this header are the jtag pins. Any ideas. Then we need to make sure the notch is facing the right way (or whatever)Article: 121294
What board do you have? You might have the wrong kind of cable end for the type of jtag connector on your board. Your board probably has a Parallel-(# here) Jtag connector which isn't directly compatible with the single in-line programmer cable end. ---Matthew Hicks > First I need to know where in this header are the jtag pins. Any > ideas. Then we need to make sure the notch is facing the right way (or > whatever) >Article: 121295
darrick wrote: > First I need to know where in this header are the jtag > pins. Any ideas. Then we need to make sure the notch > is facing the right way (or whatever) Please read the online documantation for your programmer. Typically the programming heads for Xilinx programmers 1) are fully documented, 2) come with "flying lead" headers and "high speed" ribbon cable jumpers, and 2) have the pins labeled on the side of the programmer that the ribbon jumper (or flying lead header) plug into. If you cannot find documentation online (I'm sure it's there but you must've tried to find it) call the applications guys on Monday. JTAG should be much simpler that it sounds it is for your situation. By the way - are you using a PC-XT as your platform? Those have serial and parallel ports that are the inverse of the common PC of today (starting with the PC-AT).Article: 121296
I have a problem about the data width of the output of multiplier. I am using the coregen Multiplier in Xilinx. a : std_logic_vector(3 downto 0); b : std_logic_vector(15 downto 0); q: std_logic_vector(15 downto 0); I simulated the result by using Modelsim. I found 'q' cannot get correct result unless I change the width of 'q' to 19. I want to know if it is possible to get 16 bit accurate result. Because i need 'q' to connect to another input port with 16 bits width. One more thing, Is the modelsim can simulate the delay time for the Coregen Multiplier. I have pre-define the parameters of the Multiplier to make the latency is zero. Why I see the result of 'q' is shown with a long delay after the input 'a' 'b' are written into the port. Any comment about the multiplier is appreciated. Thank you.Article: 121297
I have an SOC design built in EDK 8.2.03 for a v4fx12. The fpga boots from an xcf08p serial prom. I have an intermittent problem that seems to come and go with every rebuild. What happens is the chip will configure from prom okay but the software doesn't run. I can tell the chip is fully configure because my debug led lights and the current jumps to full. The design always runs fine when I load the fpga over jtag so something is squirelly with the boot from prom. Also, when it misconfigures the PPC core doesn't appear on the jtag scan path with xmd so I can't even load the software manually. Here is my bitgen options: -g ConfigRate:4 -g CclkPin:PULLUP -g TdoPin:PULLNONE -g M1Pin:PULLNONE -g DonePin:PULLUP -g DriveDone:Yes -g StartUpClk:JTAGCLK -g DONE_cycle:4 -g GTS_cycle:5 -g M0Pin:PULLNONE -g M2Pin:PULLNONE -g ProgPin:PULLUP -g TckPin:PULLUP -g TdiPin:PULLUP -g TmsPin:PULLUP -g DonePipe:No -g GWE_cycle:6 -g LCK_cycle:NoWait -g Security:NONE -m -g Persist:No Any help is appreciated, ClarkArticle: 121298
ZHI wrote: > I have a problem about the data width of the output of multiplier. > I am using the coregen Multiplier in Xilinx. > a : std_logic_vector(3 downto 0); > b : std_logic_vector(15 downto 0); > q: std_logic_vector(15 downto 0); > > I simulated the result by using Modelsim. I found 'q' cannot get > correct result unless I change the width of 'q' to 19. > > I want to know if it is possible to get 16 bit accurate result. > Because i need 'q' to connect to another input port with 16 bits > width. > > One more thing, Is the modelsim can simulate the delay time for the > Coregen Multiplier. I have pre-define the parameters of the Multiplier > to make the latency is zero. Why I see the result of 'q' is shown with > a long delay after the input 'a' 'b' are written into the port. > > Any comment about the multiplier is appreciated. Thank you. What's 65535 * 15 ?Article: 121299
On Jun 30, 8:03 pm, "cpope" <cep...@nc.rr.com> wrote: > I have an SOC design built in EDK 8.2.03 for a v4fx12. The fpga boots from > an xcf08p serial prom. I have an intermittent problem that seems to come and > go with every rebuild. What happens is the chip will configure from prom > okay but the software doesn't run. I can tell the chip is fully configure > because my debug led lights and the current jumps to full. The design always > runs fine when I load the fpga over jtag so something is squirelly with the > boot from prom. Also, when it misconfigures the PPC core doesn't appear on > the jtag scan path with xmd so I can't even load the software manually. > > Here is my bitgen options: [...] > Any help is appreciated, > Clark Howdy Clark, I didn't go over your bitgen options, but are you using the DONE to let you know when to stop sending CCLK's? Numerous people (including myself) have been bit by the "ALMOST DONE" pin: In select-map mode, when DONE goes high, it really means "not quite done yet" or "you're almost done". By default, CCLK has to be strobed several more times after DONE goes high. Whatever your solution, be sure to post it here. Good luck, Marc
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