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
On Thu, 3 Jan 2008 12:41:25 -0000, "Symon" <symon_brewer@hotmail.com> wrote: >"Symon" <symon_brewer@hotmail.com> wrote in message >news:flidms$1j2$1@aioe.org... >>>> >>>>There are further experiments here:- >>>> http://www.emcesd.com/tt2003/tt010103.htm >> >> John, I think you might have missed this link, but this experiment shows >> where the current flows. It shows the return current in black and white. >> (Or maybe yellow!) I'd be especially interested in your comments about >> this experiment. It shows the signal does not capacitively couple across >> the slit to any great degree. >> >Hmm, thinking harder about it, it doesn't necessarily show the lack of >current across the gap. But it does show that not all of it couples across. >Further experimentation and/or calculation would be necessary to show where >the majority of current goes, but the fact that at least some of it follows >the path around the slit shows the problem with increased inductance and >EMI. >Cheers, Syms. > I don't really understand his setup. He claims it simulates a 4-layer board with slits in both the ground and power planes (and who would do THAT?), but doesn't show the copper, if any, on the back side of his test board. And I still think that wire is a poor model for microstrip and an insane model for stripline. I'd certainly not advocate slitting both the power and ground planes, especially not in the same place; that makes a slotline! My point was that a narrow slit in a power plane is effectively shorted by an adjacent ground plane, by plane-plane capacitance and by explicit bypass caps, and a stripline signal cruising between those planes is barely affected by the slit. He seems to be demonstrating that current flows in loops where it's forced to flow in loops, which isn't very profound. I do note that his signal source is made from HC gates, so will have a slow, roughly 7 ns, risetime. That's practically DC for his geometry, so the current flow could have been measured more quantitatively by using dc and measuring the microvolt drops in the copper plane. At serious speeds, and if there were another layer of unbroken plane, things would be different. All these non-quantitative science projects are sort of irrevelent to the OP's question. Fact is, normal FPGA logic levels can be routed on FR4 multilayer boards, from point to point, with normal care about impedances and termination and obvious crosstalk hazards, without bothering about the effects of vias or crossing power plane slits or "return currents." There's certainly little reason to worry about EMI from a stripline trace sandwiched between bypassed planes. Things start to get dicey in the 100 ps edge rate ballpark, or for super-speed differential pairs, where more care is required. And routing FPGA clocks, including CCLK, deserves extra care to avoid crosstalk that wiggles rising or falling edges, or diff pair skew for LVDS clocks. JohnArticle: 127601
On Jan 3, 11:55=A0am, FPG...@gmail.com wrote: > On Jan 3, 10:58=A0am, Dave <dhsch...@gmail.com> wrote: > > > > > > > On Jan 3, 10:37=A0am, Andy <jonesa...@comcast.net> wrote: > > > > On Jan 3, 9:29 am, FPG...@gmail.com wrote: > > > > > On Jan 3, 9:57 am, Andy <jonesa...@comcast.net> wrote: > > > > > > On Jan 3, 7:16 am, "Symon" <symon_bre...@hotmail.com> wrote: > > > > > > > <FPG...@gmail.com> wrote in message > > > > > > >news:360692c0-6368-485b-bb36-42c9d33a8204@h11g2000prf.googlegroup= s.com...>Iwouldliketoknowwhich round,fix and floor algorithm would be best > > > > > > > to be implemented on an FPGA. I am working on a DSP project. I= want to > > > > > > > write funtions in VHDL which can be called and would return th= e round, > > > > > > > fix and floor value of integers. > > > > > > > I'm missing something. How do you 'round' or 'floor' an integer?= They > > > > > > already are, aren't they? > > > > > > Cheers, Syms. > > > > > > For integers, I think it should be approached as round(), ceil() o= r > > > > > floor() of a ratio of two integers, since rational numbers (includ= ing > > > > > rational approximations of non-rational numbers) are the primary > > > > > issue, not integers. Unsigned integer division uses floor anyway. = I've > > > > > implemented unsigned ceil(n/d) before as (n + d - 1) / d, used for= > > > > > constants only (no synthesized hardware created). I haven't tried = it, > > > > > but I suppose something like (n + d / 2) / d would work for unsign= ed > > > > > round()? It makes my head hurt to think about signed versions of > > > > > these... > > > > > > In hardware, bit operations are probably more efficient (i.e. perf= orm > > > > > a fixed point division, and add one if the fraction msb is set for= > > > > > round(), or if any fraction bits are set for ceil(), then truncate= the > > > > > fraction. Anyone looked at the fixed point package to see how they= do > > > > > it? > > > > > > Andy > > > > > I want to implement Round Half Up algorithm in FPGA's. The inputs ar= e > > > > in the form unsigned_logic_vector having a bit width "bw1". Output i= s > > > > return unsigned_logic_vector of width "bw2". I would like to know ho= w > > > > to implement this. I am not sure, but i guess I have to add a '10' > > > > after the decimal point. But I dont understand one thing. How would = I > > > > know where the decimal point is in a string of '1' and '0' in the > > > > input. > > > > Using std_logic_vector, signed or unsigned types, you just have to > > > keep track of the binary point yourself. > > > > That's the beauty of the fixed point package and sfixed or ufixed > > > types: bit 0 is always lsb of integer, bit -1 is msb of fraction. > > > Positive bit indexes are the integer, and negative ones are the > > > fraction. > > > > Andy- Hide quoted text - > > > > - Show quoted text - > > > It's always helped me to comment my code where I use a fixed-point > > numbers, showing where the binary point is =A0I describe the number as > > "Qx.y", where x is the umber of integral bits (including sign), and y > > is the number of fractional bits. Something like: > > > signal x : signed(15 downto 0); -- Q1.15 > > signal y : signed(15 downto 0); -- Q1.15 > > signal z : signed(31 downto 0); -- Q2.30 > > signal a : signed(16 downto 0); -- Q2.15 > > > ... > > > z <=3D x * y; -- Q1.15 * Q1.15 =3D Q2.30 > > a <=3D x + y; -- Q1.15 + Q1.15 =3D Q2.15 (to avoid overflow) > > > Dave- Hide quoted text - > > > - Show quoted text - > > I am still under confusion. I understand binary point. What I dont > understand is if I get an input whose bit width is different than the > bit width of ouptut, how will I know where the bianry point of the > inout is. I am trying to write a function for floor, ceiling and round > in VHDL. All these functions would have variable input and output bit > widths. How will I know where the binary point of the output is? > > Thanks- Hide quoted text - > > - Show quoted text - I meant binary point and not decimal point.Article: 127602
Hi John, I agree with most of that. I can get back to work now! :-) Thanks and cheers, Syms.Article: 127603
On Jan 3, 11:55=A0am, FPG...@gmail.com wrote: > On Jan 3, 10:58=A0am, Dave <dhsch...@gmail.com> wrote: > > > > > > > On Jan 3, 10:37=A0am, Andy <jonesa...@comcast.net> wrote: > > > > On Jan 3, 9:29 am, FPG...@gmail.com wrote: > > > > > On Jan 3, 9:57 am, Andy <jonesa...@comcast.net> wrote: > > > > > > On Jan 3, 7:16 am, "Symon" <symon_bre...@hotmail.com> wrote: > > > > > > > <FPG...@gmail.com> wrote in message > > > > > > >news:360692c0-6368-485b-bb36-42c9d33a8204@h11g2000prf.googlegroup= s.com...>Iwouldliketoknowwhich round,fix and floor algorithm would be best > > > > > > > to be implemented on an FPGA. I am working on a DSP project. I= want to > > > > > > > write funtions in VHDL which can be called and would return th= e round, > > > > > > > fix and floor value of integers. > > > > > > > I'm missing something. How do you 'round' or 'floor' an integer?= They > > > > > > already are, aren't they? > > > > > > Cheers, Syms. > > > > > > For integers, I think it should be approached as round(), ceil() o= r > > > > > floor() of a ratio of two integers, since rational numbers (includ= ing > > > > > rational approximations of non-rational numbers) are the primary > > > > > issue, not integers. Unsigned integer division uses floor anyway. = I've > > > > > implemented unsigned ceil(n/d) before as (n + d - 1) / d, used for= > > > > > constants only (no synthesized hardware created). I haven't tried = it, > > > > > but I suppose something like (n + d / 2) / d would work for unsign= ed > > > > > round()? It makes my head hurt to think about signed versions of > > > > > these... > > > > > > In hardware, bit operations are probably more efficient (i.e. perf= orm > > > > > a fixed point division, and add one if the fraction msb is set for= > > > > > round(), or if any fraction bits are set for ceil(), then truncate= the > > > > > fraction. Anyone looked at the fixed point package to see how they= do > > > > > it? > > > > > > Andy > > > > > I want to implement Round Half Up algorithm in FPGA's. The inputs ar= e > > > > in the form unsigned_logic_vector having a bit width "bw1". Output i= s > > > > return unsigned_logic_vector of width "bw2". I would like to know ho= w > > > > to implement this. I am not sure, but i guess I have to add a '10' > > > > after the decimal point. But I dont understand one thing. How would = I > > > > know where the decimal point is in a string of '1' and '0' in the > > > > input. > > > > Using std_logic_vector, signed or unsigned types, you just have to > > > keep track of the binary point yourself. > > > > That's the beauty of the fixed point package and sfixed or ufixed > > > types: bit 0 is always lsb of integer, bit -1 is msb of fraction. > > > Positive bit indexes are the integer, and negative ones are the > > > fraction. > > > > Andy- Hide quoted text - > > > > - Show quoted text - > > > It's always helped me to comment my code where I use a fixed-point > > numbers, showing where the binary point is =A0I describe the number as > > "Qx.y", where x is the umber of integral bits (including sign), and y > > is the number of fractional bits. Something like: > > > signal x : signed(15 downto 0); -- Q1.15 > > signal y : signed(15 downto 0); -- Q1.15 > > signal z : signed(31 downto 0); -- Q2.30 > > signal a : signed(16 downto 0); -- Q2.15 > > > ... > > > z <=3D x * y; -- Q1.15 * Q1.15 =3D Q2.30 > > a <=3D x + y; -- Q1.15 + Q1.15 =3D Q2.15 (to avoid overflow) > > > Dave- Hide quoted text - > > > - Show quoted text - > > I am still under confusion. I understand binary point. What I dont > understand is if I get an input whose bit width is different than the > bit width of ouptut, how will I know where the bianry point of the > inout is. I am trying to write a function for floor, ceiling and round > in VHDL. All these functions would have variable input and output bit > widths. How will I know where the binary point of the output is? > > Thanks- Hide quoted text - > > - Show quoted text - It sounds like what you're actually trying to implement is a truncate/ sign extend function. Try looking at the resize() function in numeric_std. If the input width is less than the output width, you probably want to sign extend. If the input width is larger than the output width, then you may want to chop off some of the LSB's, or possibly chop off some MSB's (designer's choice). Be careful, because I think the resize function actually may chop off MSB's - I can't remember. The exact position of the binary point is something that the caller of the function will have to keep track of, keeping in mind the behavior of the function. You shouildn't have to worry about it while writing the function. With fixed point, the binary point position exists only in the designer's mind (or comments). What you're describing has nothing to do with rounding. There is, however, a truncation method called "round-to-even", which is much like truncation (chopping off LSB's), but twiddles with the LSB of the result to try to get rid of any DC bias resulting from the truncation, which otherwise would always be rounding in the same direction. Google for it in comp.dsp or the internet to get a better explanation of it - it's been a while for me. Hope this helps. DaveArticle: 127604
On Jan 3, 10:55 am, FPG...@gmail.com wrote: > On Jan 3, 10:58 am, Dave <dhsch...@gmail.com> wrote: > > > > > On Jan 3, 10:37 am, Andy <jonesa...@comcast.net> wrote: > > > > On Jan 3, 9:29 am, FPG...@gmail.com wrote: > > > > > On Jan 3, 9:57 am, Andy <jonesa...@comcast.net> wrote: > > > > > > On Jan 3, 7:16 am, "Symon" <symon_bre...@hotmail.com> wrote: > > > > > > > <FPG...@gmail.com> wrote in message > > > > > > >news:360692c0-6368-485b-bb36-42c9d33a8204@h11g2000prf.googlegroups.com...>Iwouldliketoknowwhich round,fix and floor algorithm would be best > > > > > > > to be implemented on an FPGA. I am working on a DSP project. I want to > > > > > > > write funtions in VHDL which can be called and would return the round, > > > > > > > fix and floor value of integers. > > > > > > > I'm missing something. How do you 'round' or 'floor' an integer? They > > > > > > already are, aren't they? > > > > > > Cheers, Syms. > > > > > > For integers, I think it should be approached as round(), ceil() or > > > > > floor() of a ratio of two integers, since rational numbers (including > > > > > rational approximations of non-rational numbers) are the primary > > > > > issue, not integers. Unsigned integer division uses floor anyway. I've > > > > > implemented unsigned ceil(n/d) before as (n + d - 1) / d, used for > > > > > constants only (no synthesized hardware created). I haven't tried it, > > > > > but I suppose something like (n + d / 2) / d would work for unsigned > > > > > round()? It makes my head hurt to think about signed versions of > > > > > these... > > > > > > In hardware, bit operations are probably more efficient (i.e. perform > > > > > a fixed point division, and add one if the fraction msb is set for > > > > > round(), or if any fraction bits are set for ceil(), then truncate the > > > > > fraction. Anyone looked at the fixed point package to see how they do > > > > > it? > > > > > > Andy > > > > > I want to implement Round Half Up algorithm in FPGA's. The inputs are > > > > in the form unsigned_logic_vector having a bit width "bw1". Output is > > > > return unsigned_logic_vector of width "bw2". I would like to know how > > > > to implement this. I am not sure, but i guess I have to add a '10' > > > > after the decimal point. But I dont understand one thing. How would I > > > > know where the decimal point is in a string of '1' and '0' in the > > > > input. > > > > Using std_logic_vector, signed or unsigned types, you just have to > > > keep track of the binary point yourself. > > > > That's the beauty of the fixed point package and sfixed or ufixed > > > types: bit 0 is always lsb of integer, bit -1 is msb of fraction. > > > Positive bit indexes are the integer, and negative ones are the > > > fraction. > > > > Andy- Hide quoted text - > > > > - Show quoted text - > > > It's always helped me to comment my code where I use a fixed-point > > numbers, showing where the binary point is I describe the number as > > "Qx.y", where x is the umber of integral bits (including sign), and y > > is the number of fractional bits. Something like: > > > signal x : signed(15 downto 0); -- Q1.15 > > signal y : signed(15 downto 0); -- Q1.15 > > signal z : signed(31 downto 0); -- Q2.30 > > signal a : signed(16 downto 0); -- Q2.15 > > > ... > > > z <= x * y; -- Q1.15 * Q1.15 = Q2.30 > > a <= x + y; -- Q1.15 + Q1.15 = Q2.15 (to avoid overflow) > > > Dave- Hide quoted text - > > > - Show quoted text - > > I am still under confusion. I understand binary point. What I dont > understand is if I get an input whose bit width is different than the > bit width of ouptut, how will I know where the bianry point of the > inout is. I am trying to write a function for floor, ceiling and round > in VHDL. All these functions would have variable input and output bit > widths. How will I know where the binary point of the output is? > > Thanks You won't, unless you are given an argument to your function that tells you where the binary point(s) are, or you use sfixed or ufixed from the fixed point packages as your argument and return data types. Don't reinvent the wheel; these packages were designed for exactly that. AndyArticle: 127605
Hi, I have a question regarding area group constraints for Xilinx ISE software Using VHDL to describe this: I have an entity A that uses 3 components B, C and D as well as glue logic connecting everything together. If I set my area constraint as follows: AREA_GROUP "AG_A" RANGE = SLICE_X0Y149:SLICE_X3Y66 ; INST "A" AREA_GROUP = "AG_A"; Will PAR place the entity as well as the components inside the area constraints OR will it map the entity glue logic to the area constraint and then place B, C and D anywhere. What if I do this: AREA_GROUP "AG_ABCD" RANGE = SLICE_X0Y149:SLICE_X3Y66 ; INST "A" AREA_GROUP = "AG_ABCD"; INST "B" AREA_GROUP = "AG_ABCD"; INST "C" AREA_GROUP = "AG_ABCD"; INST "D" AREA_GROUP = "AG_ABCD"; How different will be the placed design. Thanks for the insight. AmishArticle: 127606
On Jan 3, 1:29=A0pm, Andy <jonesa...@comcast.net> wrote: > On Jan 3, 10:55 am, FPG...@gmail.com wrote: > > > > > > > On Jan 3, 10:58 am, Dave <dhsch...@gmail.com> wrote: > > > > On Jan 3, 10:37 am, Andy <jonesa...@comcast.net> wrote: > > > > > On Jan 3, 9:29 am, FPG...@gmail.com wrote: > > > > > > On Jan 3, 9:57 am, Andy <jonesa...@comcast.net> wrote: > > > > > > > On Jan 3, 7:16 am, "Symon" <symon_bre...@hotmail.com> wrote: > > > > > > > > <FPG...@gmail.com> wrote in message > > > > > > > >news:360692c0-6368-485b-bb36-42c9d33a8204@h11g2000prf.googlegro= ups.com...>Iwouldliketoknowwhichround,fix and floor algorithm would be best > > > > > > > > to be implemented on an FPGA. I am working on a DSP project.= I want to > > > > > > > > write funtions in VHDL which can be called and would return = the round, > > > > > > > > fix and floor value of integers. > > > > > > > > I'm missing something. How do you 'round' or 'floor' an intege= r? They > > > > > > > already are, aren't they? > > > > > > > Cheers, Syms. > > > > > > > For integers, I think it should be approached as round(), ceil()= or > > > > > > floor() of a ratio of two integers, since rational numbers (incl= uding > > > > > > rational approximations of non-rational numbers) are the primary= > > > > > > issue, not integers. Unsigned integer division uses floor anyway= . I've > > > > > > implemented unsigned ceil(n/d) before as (n + d - 1) / d, used f= or > > > > > > constants only (no synthesized hardware created). I haven't trie= d it, > > > > > > but I suppose something like (n + d / 2) / d would work for unsi= gned > > > > > > round()? It makes my head hurt to think about signed versions of= > > > > > > these... > > > > > > > In hardware, bit operations are probably more efficient (i.e. pe= rform > > > > > > a fixed point division, and add one if the fraction msb is set f= or > > > > > > round(), or if any fraction bits are set for ceil(), then trunca= te the > > > > > > fraction. Anyone looked at the fixed point package to see how th= ey do > > > > > > it? > > > > > > > Andy > > > > > > I want to implement Round Half Up algorithm in FPGA's. The inputs = are > > > > > in the form unsigned_logic_vector having a bit width "bw1". Output= is > > > > > return unsigned_logic_vector of width "bw2". I would like to know = how > > > > > to implement this. I am not sure, but i guess I have to add a '10'= > > > > > after the decimal point. But I dont understand one thing. How woul= d I > > > > > know where the decimal point is in a string of '1' and '0' in the > > > > > input. > > > > > Using std_logic_vector, signed or unsigned types, you just have to > > > > keep track of the binary point yourself. > > > > > That's the beauty of the fixed point package and sfixed or ufixed > > > > types: bit 0 is always lsb of integer, bit -1 is msb of fraction. > > > > Positive bit indexes are the integer, and negative ones are the > > > > fraction. > > > > > Andy- Hide quoted text - > > > > > - Show quoted text - > > > > It's always helped me to comment my code where I use a fixed-point > > > numbers, showing where the binary point is =A0I describe the number as= > > > "Qx.y", where x is the umber of integral bits (including sign), and y > > > is the number of fractional bits. Something like: > > > > signal x : signed(15 downto 0); -- Q1.15 > > > signal y : signed(15 downto 0); -- Q1.15 > > > signal z : signed(31 downto 0); -- Q2.30 > > > signal a : signed(16 downto 0); -- Q2.15 > > > > ... > > > > z <=3D x * y; -- Q1.15 * Q1.15 =3D Q2.30 > > > a <=3D x + y; -- Q1.15 + Q1.15 =3D Q2.15 (to avoid overflow) > > > > Dave- Hide quoted text - > > > > - Show quoted text - > > > I am still under confusion. I understand binary point. What I dont > > understand is if I get an input whose bit width is different than the > > bit width of ouptut, how will I know where the bianry point of the > > inout is. I am trying to write a function for floor, ceiling and round > > in VHDL. All these functions would have variable input and output bit > > widths. How will I know where the binary point of the output is? > > > Thanks > > You won't, unless you are given an argument to your function that > tells you where the binary point(s) are, or you use sfixed or ufixed > from the fixed point packages as your argument and return data types. > > Don't reinvent the wheel; these packages were designed for exactly > that. > > Andy- Hide quoted text - > > - Show quoted text - Do all tools support these new packages? Which ones do? i have ISE Webpack 9.2, and I don't think it does yet. They are definitely very cool.Article: 127607
On Dec 27 2007, 5:54 pm, Peter Alfke <al...@sbcglobal.net> wrote: > On Dec 27, 3:20 pm, MikeShepherd...@btinternet.com wrote: > > > >Please suggest to your web developers that they...put technical > > >documentation...at permanent URLs... > > >Someone...pointed out years ago that URLs for real documents... > > >should be persistent. There was a paper on it, but I can't > > >find it now. Unfortunately few web developers have taken > > >this to heart. > > > The point has probably been made in various places, but one is: > > > http://www.useit.com/alertbox/980614.html > > > Mike > > I understand, and I agree somewhat. But we also have to realize that > this is a fast-changing technology, and something that was cool and > interesting in 2002 is now often obsolete and perhaps even misleading. > That's why we want to overhaul the old TechXclusives, throw some away, > and bring the others up to snuff. We want to cater to working > engineers, not to archaeologists... > An overview of FPGAs that stops with Virtex-II is not meaningful > anymore, and neither are complex asynchronous FIFO explanations, when > you get ready-made designs in the more modern Virtex chips. > Sometimes we will annotate the old stories with warnings that there > are better ways of designing with the more modern parts. > The same considerations should be applied to application notes. Most > of them that are 5 years old are more amusing than enlightening. > Scary... > Peter Alfke Even though some interesting old techniques may seem useless to users of new products with such circuits already built in, the articles remain useful to allow users that need something slightly different (and not available built-in).. I agree that these articles often need editing or augmenting to inform would-be users of now-available alternatives, and some articles are just too far gone to resurrect. But many things old become new again eventually... Just look at CORDIC algorithms, for example. And now they are even falling out of favor again in some cases, supplanted by the availability of more multipliers, etc. I remember when I first started working with FPGA's in the early 90's (schematic capture), and reused techniques I had learned in college for implementing logic functions with multiplexers and decoders, but had not used for years in favor of PALS with SOP implementations. AndyArticle: 127608
Goli wrote: > Hi, > > I am working on a Xilinx Virtex5 design. I generated a pin lock file > (ucf) and have a top level verilog file. Top level verilog file does > not have any code, but it has only IO declarations.And I want to > generate the pad file out of this. > > The issue is that since it is an empty design, I get the following > error message, > " > NCD was not produced. All logic was removed from design. This > is usually due to having no input or output PAD connections in the > design and > no nets or symbols marked as 'SAVE'. You can either add PADs or > 'SAVE' > attributes to the design, or run 'map -u' to disable logic trimming > in the > mapper. > " > > I tried -u options in MAP, and I have also enable add IO buffer > options in XST, but it still gives the same error. > > I know I can write some dummy logic and generate the pad file, but was > wondering if there is any easier method of doing this? > > Does anyone know how can I give this SAVE attribute as mentioned in > the error above? Or is there any way to generate the pad file. > > Regards, > Goli Your outputs might be getting stripped out in synthesis. You could rectify this by just tying by using "syn_keep" constraints or just by tying them high or low. Like this: module top (input clk, reset, output a, b, c); assign a=0; assign b=0; assign c=0; endmodule That should keep the outputs from getting removed. -KevinArticle: 127609
On Jan 3, 10:28 am, "MJ Pearson" <mjp...@york.ac.uk> wrote: > Hello, > > I've some issues hooking up some external components (camera link based > cameras) to my XUPV2P board. I've built a PCB which connects the high > speed expansion port of the XUPV2P to the outputs of the National Chip > DS90CR288A. I've two cameras running simultaneously, so thats two chips on > the PCB. > > On the high speed expansion port of the XUPV2P there's a clock input, but > because I've got two external clocks (one from each chip), I decided to > attach them to the 'regular' FPGA pins. Sorry if this makes no sense! The > other high speed expansion port connections are connected to the data > signals, and data-valid signals from the chips. > > I've created a peripheral which samples the camera data according to these > clock signals, and then sampled again using the Bus2IP clock. I use a > microblaze processor just to output various data. On the scope, my clock > signals seem to have a period of 16ns, is this too fast for what I want to > do? The voltage swing is about 600mV. My design doesn't seem to be working! > Just wondered if anyone had any suggestions comments on how best to debug > and proceed. I would first check that the clocks are being received properly by the V2P. Add a T flip-flop on each input clock and drive it to an I/O or LED that is easy to scope. Check that the frequency is 1/2 of the input frequency and that you don't get runt pulses or other undesired behavior. If your two input clocks are running O.K., but your data capture is not consistent, it is possible to run standard (non-GCLK) inputs to a DCM to adjust the clock phase. You might need to set an environment variable to force ISE to do this depending on the version of ISE you run. On my system I set: XIL_MAP_ALLOW_ANY_DLL_INPUT = 1 But that was for a very old version of Foundation, so you may not need this. I'm not sure what you mean by sampling the camera data according to these clock signals, and then sampled again using the Bus2IP clock. I would think you need to use a FIFO to move from the camera clocks to the Bus2IP clock. Camera Link places a LVAL signal on each of the Channel-Links, so you can generate a FIFO write signal for each link independently using its own clock. Hope this helps, GaborArticle: 127610
Brian Davis wrote: > Veering back onto discussing single bit DDS's, given a high rate > serializer to press into use, there are a variety of fractional-N > or noise shaping techniques that should work well, e.g. [4],[5] I'm not sure, if this results in a cleaner frequency output, because it has other artifacts. For a test equipment signal generator, which needs to change the frequency only every some seconds, maybe an easier idea could work: Using a VCO, controlled with a high precision 24 bit DAC (like one of these high quality audio codecs, which are nevertheless cheap, because of mass production). The frequency of the VCO could be measured by the FPGA over a long time, maybe counting the cycles in one second, and sophisticated (filtering, PID etc.) adjustments for the VCO voltage can be implemented. The only drawback is, that the VCO frequency and the DAC voltage must be very solid for at least some seconds, which means good decoupling and filtering of the power supply, maybe shielding etc. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 127611
I am instantiating an LVPECL iobuffer in a xilinx spartan-3 device. This buffer is sending out data at 150Mbps into an LVPECL receiver chip located about 18 inches away. The sent signal doesn't have enough amplitude to overcome the hysteresis in the receiver. My measurements indicate that there is very little attenuation in this signal from driver to receiver. Its just that the signal at the fpga is of almost no amplitude. If i lower the clock rate to 100Mbps it works fine. I don't really care about standards compliance here, i just want it to work ( at 150Mbps). Is there some way i can increase the slew rate or drive strength of the driver? Perhaps changing io-standards? Thanks in advance, Jon PryArticle: 127612
On Jan 3, 1:43=A0pm, Dave <dhsch...@gmail.com> wrote: > On Jan 3, 1:29=A0pm, Andy <jonesa...@comcast.net> wrote: > > > > > > > On Jan 3, 10:55 am, FPG...@gmail.com wrote: > > > > On Jan 3, 10:58 am, Dave <dhsch...@gmail.com> wrote: > > > > > On Jan 3, 10:37 am, Andy <jonesa...@comcast.net> wrote: > > > > > > On Jan 3, 9:29 am, FPG...@gmail.com wrote: > > > > > > > On Jan 3, 9:57 am, Andy <jonesa...@comcast.net> wrote: > > > > > > > > On Jan 3, 7:16 am, "Symon" <symon_bre...@hotmail.com> wrote: > > > > > > > > > <FPG...@gmail.com> wrote in message > > > > > > > > >news:360692c0-6368-485b-bb36-42c9d33a8204@h11g2000prf.googleg= roups.com...>Iwouldliketoknowwhichround,fixand floor algorithm would be best= > > > > > > > > > to be implemented on an FPGA. I am working on a DSP projec= t. I want to > > > > > > > > > write funtions in VHDL which can be called and would retur= n the round, > > > > > > > > > fix and floor value of integers. > > > > > > > > > I'm missing something. How do you 'round' or 'floor' an inte= ger? They > > > > > > > > already are, aren't they? > > > > > > > > Cheers, Syms. > > > > > > > > For integers, I think it should be approached as round(), ceil= () or > > > > > > > floor() of a ratio of two integers, since rational numbers (in= cluding > > > > > > > rational approximations of non-rational numbers) are the prima= ry > > > > > > > issue, not integers. Unsigned integer division uses floor anyw= ay. I've > > > > > > > implemented unsigned ceil(n/d) before as (n + d - 1) / d, used= for > > > > > > > constants only (no synthesized hardware created). I haven't tr= ied it, > > > > > > > but I suppose something like (n + d / 2) / d would work for un= signed > > > > > > > round()? It makes my head hurt to think about signed versions = of > > > > > > > these... > > > > > > > > In hardware, bit operations are probably more efficient (i.e. = perform > > > > > > > a fixed point division, and add one if the fraction msb is set= for > > > > > > > round(), or if any fraction bits are set for ceil(), then trun= cate the > > > > > > > fraction. Anyone looked at the fixed point package to see how = they do > > > > > > > it? > > > > > > > > Andy > > > > > > > I want to implement Round Half Up algorithm in FPGA's. The input= s are > > > > > > in the form unsigned_logic_vector having a bit width "bw1". Outp= ut is > > > > > > return unsigned_logic_vector of width "bw2". I would like to kno= w how > > > > > > to implement this. I am not sure, but i guess I have to add a '1= 0' > > > > > > after the decimal point. But I dont understand one thing. How wo= uld I > > > > > > know where the decimal point is in a string of '1' and '0' in th= e > > > > > > input. > > > > > > Using std_logic_vector, signed or unsigned types, you just have to= > > > > > keep track of the binary point yourself. > > > > > > That's the beauty of the fixed point package and sfixed or ufixed > > > > > types: bit 0 is always lsb of integer, bit -1 is msb of fraction. > > > > > Positive bit indexes are the integer, and negative ones are the > > > > > fraction. > > > > > > Andy- Hide quoted text - > > > > > > - Show quoted text - > > > > > It's always helped me to comment my code where I use a fixed-point > > > > numbers, showing where the binary point is =A0I describe the number = as > > > > "Qx.y", where x is the umber of integral bits (including sign), and = y > > > > is the number of fractional bits. Something like: > > > > > signal x : signed(15 downto 0); -- Q1.15 > > > > signal y : signed(15 downto 0); -- Q1.15 > > > > signal z : signed(31 downto 0); -- Q2.30 > > > > signal a : signed(16 downto 0); -- Q2.15 > > > > > ... > > > > > z <=3D x * y; -- Q1.15 * Q1.15 =3D Q2.30 > > > > a <=3D x + y; -- Q1.15 + Q1.15 =3D Q2.15 (to avoid overflow) > > > > > Dave- Hide quoted text - > > > > > - Show quoted text - > > > > I am still under confusion. I understand binary point. What I dont > > > understand is if I get an input whose bit width is different than the > > > bit width of ouptut, how will I know where the bianry point of the > > > inout is. I am trying to write a function for floor, ceiling and round= > > > in VHDL. All these functions would have variable input and output bit > > > widths. How will I know where the binary point of the output is? > > > > Thanks > > > You won't, unless you are given an argument to your function that > > tells you where the binary point(s) are, or you use sfixed or ufixed > > from the fixed point packages as your argument and return data types. > > > Don't reinvent the wheel; these packages were designed for exactly > > that. > > > Andy- Hide quoted text - > > > - Show quoted text - > > Do all tools support these new packages? Which ones do? i have ISE > Webpack 9.2, and I don't think it does yet. They are definitely very > cool.- Hide quoted text - > > - Show quoted text - Thank you all for your help.Article: 127613
Jon, Using the two external series 70 ohm, and external 240 ohm then over a 100 ohm (or two 50 ohm) t-line, terminated in 100 ohms (and another Spartan 3 set of inputs), I get ~ 1700 mV p-p at 150 MHz in my Hyperlynx simulations. Are you sure you have the required external networks properly wired? Have you driven the + output and - outputs out of phase? (one goes hi, while the other goes lo...). http://www.xilinx.com/support/documentation/data_sheets/ds099.pdf Figure 32, page 65 of 126. AustinArticle: 127614
On Jan 3, 2:07 pm, austin <aus...@xilinx.com> wrote: > Jon, > > Using the two external series 70 ohm, and external 240 ohm then over a > 100 ohm (or two 50 ohm) t-line, terminated in 100 ohms (and another > Spartan 3 set of inputs), I get ~ 1700 mV p-p at 150 MHz in my Hyperlynx > simulations. > > Are you sure you have the required external networks properly wired? > > Have you driven the + output and - outputs out of phase? (one goes hi, > while the other goes lo...). > > http://www.xilinx.com/support/documentation/data_sheets/ds099.pdf > > Figure 32, page 65 of 126. > > Austin This is the verilog code i use to instantiate the driver defparam laser_buf.IOSTANDARD = "LVPECL_25"; OBUFDS laser_buf (.I(laser), .O(laser_p), .OB(laser_n) ); It is then loc'd to a pin in the ucf file. afaik, OBUFDS always drives the pins out of phase. i verified this on a scope, and it works fine at lower speed. i have the 70 ohm resistors, but not the 240 as i think it is just there to lower the voltage to be within the lvpecl spec, which i don't care about. i suspect that setting IO_STANDARD=LVPECL does some things in the background, like set the drive strength and slew rate as low as possible. this output need not be relative to any clock, so maybe the best thing is to use 2 lvcmos buffers driven out of phase.Article: 127615
Jon, OK, that all should work just fine. As low as 4mA fast LVCMOS is what is used for LVPECL, and is plenty fast for a clean 6.6ns "eye" pattern even at the slow/weak IBIS corner. The fact that it works at 100 MHz, and does not at 150 MHz does not match the simulation AT ALL! From this, I suspect there is something else going on (capacitive loading, inductive t-line, asymmetric/bad duty cycle, ... etc.) which causes the "wheels to fall off" at 150 MHz! If you change your programming for two separate out of phase drivers to two 4 mA FAST LVCMOS, there should be no change from the LVPECL case you have now. If there is, then the IO standard isn't setting the bits right in the configuration, and that would be a software bug in bitgen (but, I can't imagine it working at 100 MHz, and then not at 150 MHz!!!). Boosting the drive strength won't do anything at all. Leaving out the 240 ohms may be the cause of your problem, as the transmit is also matched to 100 ohms (if the reflection is just right, you could be canceling your receive signal because of transmit impedance mis-match). AustinArticle: 127616
On Jan 3, 3:36 pm, austin <aus...@xilinx.com> wrote: > Jon, > > OK, that all should work just fine. As low as 4mA fast LVCMOS is what > is used for LVPECL, and is plenty fast for a clean 6.6ns "eye" pattern > even at the slow/weak IBIS corner. > > The fact that it works at 100 MHz, and does not at 150 MHz does not > match the simulation AT ALL! From this, I suspect there is something > else going on (capacitive loading, inductive t-line, asymmetric/bad duty > cycle, ... etc.) which causes the "wheels to fall off" at 150 MHz! > > If you change your programming for two separate out of phase drivers to > two 4 mA FAST LVCMOS, there should be no change from the LVPECL case you > have now. > > If there is, then the IO standard isn't setting the bits right in the > configuration, and that would be a software bug in bitgen (but, I can't > imagine it working at 100 MHz, and then not at 150 MHz!!!). > > Boosting the drive strength won't do anything at all. > > Leaving out the 240 ohms may be the cause of your problem, as the > transmit is also matched to 100 ohms (if the reflection is just right, > you could be canceling your receive signal because of transmit impedance > mis-match). > > Austin Apparently i am retarded and in one of the connectors the wires were off by one. So only one line of my diff pair was actually connected. There was so much coupling between the wires that on the scope it looked like they were both hooked up. It is rather amazing this worked at all. My guess is that there was enough capacitance in the termination resistor to cause a phase lag in the other wire. I didn't get around to trying the 240 ohm resistor. Sorry for troubling you and thanks for all the help.Article: 127617
Jon, No need to apologize! Congratulations: you FOUND IT! That makes you smarter than 99.9995% of the rest of us in our 'armchairs'! AustinArticle: 127618
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:fh7mn3pl84g9ccugdov2vml0nfg3f8le45@4ax.com... > On Tue, 01 Jan 2008 17:41:14 -0800, John_H > <newsgroup@johnhandwork.com> wrote: > >>John Larkin wrote: >>> On Tue, 01 Jan 2008 14:04:19 -0600, "maxascent" >>> <maxascent@yahoo.co.uk> wrote: >>> >>>> Hi >>>> >>>> I am designing an 8 layer board with a Virtex 4 device on it. I will >>>> have >>>> 2 solid ground planes and 2 split power planes. If I have a signal >>>> plane >>>> that is between a ground and power plane will it matter if I cross a >>>> split >>>> on the power plane with a signal track. I know that you should not >>>> cross a >>>> split it in a plane if you are referencing to that plane. But if I have >>>> a >>>> solid ground plane beneath the track will it use this plane as its >>>> reference rather than the power plane. >>>> >>>> Cheers >>>> >>>> Jon >>> >>> No, it doesn't matter. The strange concept of "reference planes" is >>> irrelevent here... how does the signal know what plane you think it's >>> referenced to? >>> >>> If the power planes are bypassed well enough to make them reliable >>> power sources, then they are AC equipotential with the ground plane, >>> so the signal sees them all as ground. And a small slit in a power >>> plane is essentially invisible for edges slower than a few 10's of >>> picoseconds. >>> >>> John >> >>John, >> >>You're the only person who I won't directly challenge on your assertion >>because of your experience in producing quality products while >>confronting these types of issues directly. >> >>Suffice it to say that "today's common theory" suggests crossing the >>split in the specified case - like crossing any split - can be the root >>of crosstalk and EMI issues in addition to signal fidelity issues, just >>to a lesser extent than for signals on the outside layers. >> >>I'd love to be able to wrap my mind around how crossing this split >>wouldn't affect the signal in measurable ways, but the things I've been >>taught - my "faith" perhaps - suggests otherwise. I was once of a mind >>where crossing the split would be a non-issue but was brought over to >>the dark side with convincing arguments that tied in mith my more >>fundamental understanding of transmission line theory. >> >>- John_H > > > > > ground============================================================ > > signal------------------------------------------------------------ > > power ======================== ================================= > > whatever ======================================================== > > > OK, there's a slit in the power plane. It's probably about as wide as > a normal trace width, call it 8 mils. Let's say the plane-plane > spacings are similar distances. Both halves of the split power plane > are bypassed to the ground plane by real capacitors and by the > considerable large-area plane-plane capacitance. > > In order for the trace impedance to change as the trace cruises over > the gap, the potential in the middle of the gap would have to be > non-zero. But the electric field from the signal trace can hardly > penetrate through the gap... that's simple electrostatics. The signal > sees uniform ground above, and a slightly lower dielectric constant > below, in the gap region. That raises the trace impedance a tiny bit > just above the gap, for a tiny distance. The "reference plane" issue > is silly, as all the planes are at AC ground. > > I've built and TDR's such structures to better than 30 ps resolution. > A reflection from such a gap is lost in the normal impedance noise, > caused by thickness variations and the glass weave in the board. In > the nanosecond domain, it's totally invisible. > > On a 2-sided board, a microstrip trace on one side and a cut ground > plane on the other, > > > signal----------------------------------- > > ground================== ============== > > > a narrow slit in the ground plane is still a tiny impedance > discontinuity on a TDR plot. > > All this "reference plane" stuff is ludicrous. It sure ain't > "transmission line theory", it's folklore. > > John > I agree, most of this topic is a non-issue. It only becomes one when layouts and/or designs get ugly, usually meaining lack of experience of the designer. Avoid what you can, do what you HAVE to, just do it smart. A bit of thinking before hand will help pass even the most ludicrous tests (and I have seen some doozies).Article: 127619
On 2008-01-03, Arlet Ottens <usenet+5@c-scape.nl> wrote: > Habib Bouaziz-Viallet wrote: >> always @(posedge clk) >> begin >> out<=out+1; >> if (reset==1) >> out[7:0] <= 0; >> else if(load==1) >> out[7:0] <= in[7:0]; >> end > > You're doing two assignments to 'out' in the same clock cycle. Doing more than one assignment to a signal is allowed for synthesizable code, both in Verilog and VHDL. The last assignment in the process block takes precedence. (This assumes that all assignments are done in the same process, if not you will have a whole bunch of problems...) It can allow for quite a bit more readable code in some cases, especially if you have a combinational block where you must be sure to always assign a value to a certain signal in order to avoid a latch. /AndreasArticle: 127620
Hi, Am far from being an expert in fpga usage and programming, I was wondering if there exists any ip cores out there that would allow the use of ethernet interfaces on recent FPGAs. For instance say that I have a rather important bandwidth (500Mb/s) and that I want to send that over the Gigabit interface of a Virtex 5 in UDP frames. Is there any blackbox concept IP Core that would allow me to do that without having to learn about UDP frame and TCP and the use of the Xilinx ethernet MAC usage etc etc ? Thanks PatArticle: 127621
On Jan 1, 10:04=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Hi > > I am designing an 8 layer board with a Virtex 4 device on it. I will have > 2 solid ground planes and 2 split power planes. If I have a signal plane > that is between a ground and power plane will it matter if I cross a split= > on the power plane with a signal track. I know that you should not cross a= > split it in a plane if you are referencing to that plane. But if I have a > solid ground plane beneath the track will it use this plane as its > reference rather than the power plane. Please enlight me: how do you know the trace you are discussing about will have the "reference" plane either the ground plane or the ground signal plane ? The return path will be the smallest impedance path. Meaning it could be a part from the ground plane and a part of your solid signal ground plane. You haven't too many options in controlling precisely the return path as long you have plenty of vias between those two ground planes... VasileArticle: 127622
"Pat Magnits" <Pat@Magnits.com> wrote: >Hi, > >Am far from being an expert in fpga usage and programming, I was wondering >if there exists any ip cores out there that would allow the use of ethernet >interfaces on recent FPGAs. For instance say that I have a rather important >bandwidth (500Mb/s) and that I want to send that over the Gigabit interface >of a Virtex 5 in UDP frames. Is there any blackbox concept IP Core that >would allow me to do that without having to learn about UDP frame and TCP >and the use of the Xilinx ethernet MAC usage etc etc ? Sending UDP packets is rather straightforward. Look here: http://www.fpga4fun.com/10BASE-T.html You'll need a phy to send the data. These aren't difficult to connect & control. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 127623
"Pat Magnits" <Pat@Magnits.com> wrote in message news:flkr96$tb3$1@s1.news.oleane.net... > Hi, > > Am far from being an expert in fpga usage and programming, I was wondering > if there exists any ip cores out there that would allow the use of > ethernet interfaces on recent FPGAs. http://www.opencores.org/browse.cgi/by_categoryArticle: 127624
Andreas Ehliar wrote: > On 2008-01-03, Arlet Ottens <usenet+5@c-scape.nl> wrote: >> Habib Bouaziz-Viallet wrote: >>> always @(posedge clk) >>> begin >>> out<=out+1; >>> if (reset==1) >>> out[7:0] <= 0; >>> else if(load==1) >>> out[7:0] <= in[7:0]; >>> end >> You're doing two assignments to 'out' in the same clock cycle. > > Doing more than one assignment to a signal is allowed for > synthesizable code, both in Verilog and VHDL. The last assignment > in the process block takes precedence. (This assumes that > all assignments are done in the same process, if not you > will have a whole bunch of problems...) I didn't know that.. Thanks. I noticed it synthesized OK, but I assumed the behavior would be unspecified.
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