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
Austin Lesea wrote: > I agree that a slit in the ground plane is going to be an impedance > discontinuity for signals that cross the split. > For that reason, I would probably have any signals that cross the split > have a continuous ground underneath them. That little bit of ground > that now connects the "isolated" ground plane to the rest of the ground > plane is also a DC short across the NEC-Tokin device, but from an AC > traveling wave point of view, it is an open, as the power and ground > currents return to the power supply, and are unlikely to return over a > small bridge between two planes. My first thought on your previous post on split power planes, and considering them as transmission lines, is that you can distribute the effect of the clock transitions back to the power supply. If you have multiple FPGAs on a board, all clocked at the same time, but with different length low impedance transmission lines to the power supply, (bypass capacitors), you distribute the effect of those capacitors. Then again, you should be able to get a similar effect with different clock delays. If you have a split ground plane it would seem that the signal lines should go around, and not cross the split. -- glenArticle: 116426
The problem with "the synthesizer should be able to figure it out" comments that keep being thrown around here is that that violates the entire purpose of VHDL. VHDL was intended to be a VERY strongly type'ed language. Which is why (std_logic_vector) * (floating point) is not defined in any standard IEEE library. This is precisely the constraint that makes your synthesis results reliable. Whether the programmers gone hardware designers in the group like it or not, writing VHDL is designing hardware. If you write VHDL with no regard for the hardware that will be built from it, and violate basic design rules, you WILL encounter problems - particularly if you try to get anywhere near the upper speed limit of the part you're designing. That being said... if you know how you want your multipliers/dividers to be built, I would recommend writing a library to do what you want. Once you define the function "SLV * FLOAT" in a library, you can write statements like that until your heart's content AND be confident in how it will be built because you designed the library. On Mar 4, 3:47 pm, "Peter Alfke" <a...@sbcglobal.net> wrote: > Matthew let me argue for peace: > It all depends on your roots. > If you started out as a logic designer (like I did), then you see the > FPGA as a wonderful way to design a production-worthy breadboard of > terrific complexity and very good performance. God's gift to the logic > designer, good-bye wire-wrap! > I think in terms of block diagrams, and use VHDL/Verilog to manage the > design process. I would never be in doubt about the choice of binary > vs decimal, or fixed vs floating point, because they have such > enenormous impact on the design efficiency. > > If you start out as a computer programmer, then you design=program the > way this thread was started, totally oblivious of hardware constraints > and limittions. Let the synthesizer worry about those details! The > trouble is that these unworthy details can impact the design by an > order of magnitude in size=cost and performance. > > You will never beat the urge for economy, performance, and design > elegance out of us hardware guys. Maybe one day FPGAs will become so > big and cheap and fast that it does not matter anymore. > Well, hopefully there will always be Social Security. > And St. Peter might show mercy with us former pip-pokers genus > schemato-saurus. > Peter Alfke > > On Mar 4, 12:12 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > > > > > First, to address the question, you're not really doing multiplication but > > performing division through multiplication with decimals. ISE doesn't do > > division either way. Like John_H said, scale your numbers up (refer to fixed > > point numbers) so multiplication is done with integers. When done, just > > scale the result down by the same amount for the final answer. A hint is > > to scale the numbers by a power of 2 so you just have to do bit shifts. > > > Second, I would like to give my two cents on John_H's 1990's attitude. You > > shouldn't tell someone to read up on vendor specific blocks when it is clear > > that they are just starting out, doesn't need an optimal implementation, > > and don't have a firm grasp on the basics. You should give them a very simple > > and concise explanation at their level and a fix at their level. The synthesizer > > is more than capable of handling the * symbol, the OP doesn't need to worry > > about what Xilinx puts on the hood. If Xilinx were smart and had good programmers, > > which it seems they are trying to work towards, no one would need to know > > of any of the blocks under the hood. People should be able to "program" > > the hardware. The synthesis program should be smart enough to use the blocks > > under the hood to provide a near optimal implementation of the "program". > > There is a reason why people use high level programming languages not assembly. > > For everyone's sake, "designing" a system on an FPGA shouldn't be hard. > > > ---Matthew Hicks > > > > VHDL_HELP wrote: > > > >> Hi every body , > > >> i hope that you can help me , i want to do this operation: > > >> s = c1 * 0.2+ c2 * 0.6 + c3 * 0.1 > > >> when i check the syntax , i have these errors > > >> ERROR:HDLParsers:808 - "C:/Xilinx/projet/operation.vhd" Line 44. * > > >> can > > >> not have such operands in this context. > > >> --------------------------------------------------------------------- > > >> --------------------------------------------------------------------- > > >> ---------------------- > > > >> library IEEE; > > > >> use IEEE.STD_LOGIC_1164.ALL; > > > >> use IEEE.STD_LOGIC_ARITH.ALL; > > > >> use IEEE.STD_LOGIC_UNSIGNED.ALL; > > > >> entity operation is > > >> Port ( clk : in STD_LOGIC; > > >> c1 : in STD_LOGIC_VECTOR (7 downto 0); > > >> c2 : in STD_LOGIC_VECTOR (7 downto 0); > > >> c 3: in STD_LOGIC_VECTOR (7 downto 0); > > >> s: out STD_LOGIC_VECTOR (7 downto 0); > > >> end operation; > > > >> architecture Behavioral of operation is > > > >> begin > > > >> s <=c1 * 0.2 + c2 * 0.6 + c3 * 0.1 ; > > > >> end Behavioral; > > > >> --------------------------------------------------------------------- > > >> --------------------------------------------------------------------- > > >> ---------------- > > > >> and thanks for your help > > > > Can you tell me how the synthesizer will format your floating point > > > result in s so it maps to silicon? > > > > Use scaled integers. Use the precision available in the hardware > > > multipliers to get a rather precise approximation of s. The digital > > > realm is binary, after all, not decimal. > > > > Please read up on how the hardware multipliers perform and how best to > > > utilize them. It's insanely sad to see someone trying to "program" an > > > FPGA rather than design it.- Hide quoted text - > > - Show quoted text -Article: 116427
Andy Peters wrote: > I do recall certain Xilinx representatives saying something like "on- > board configuration memory means that we'll have to use an older > process, meaning slower, more power-hungry parts, yadda yadda > yadda." That was refering to same-die configuration; the process constraints go away then you deploy 2 die in one package, which is what Xilinx have done. Some companies simply wire bond the second die in a spare area, in BGA that's easy - just design the BGA paddle & pgm the bonding machine. Others are working on flip-chip bump bonding, where the die is designed to take the daughter chip, and the bonding costs drop (not just $, but area/height costs too ) and you can get a lot of contacts going between the die. If you are already doing flip-chip onto the BGA, to get die-wide bond pads, and lower nH, then it's somewhat harder to find a place to put the second memory die ..... -jgArticle: 116428
"nfirtaps" <lloyd.rochester@gmail.com> wrote in message news:1173383894.763347.110110@64g2000cwx.googlegroups.com... > > 1.) Can I somehow drive a PLL with a general purpose I/O I don't think so. I'm using Cyclone II at the moment and I'm 99.9% sure you can't feed the PLLs with anything except one of the 'clock input' pins. (These can also be general purpose input pins, so I would always recommend connecting anything vaguely 'clock-like' to one of those pins, even if you think you might not actually use it as a clock.) > 2.) Is there another way of deserializing the DDR signal. You don't say anything about frequency, but I'd be inclined just to sample on the falling edge as well, and then shift the two bits (+ve edge and -ve edge) into your shift register on the next +ve clock. > Currently I have a the DDR clock coming in my fpga and I not the clock > so I can sample the DDR signal on the rising egde. Is that giving you a problem? WillArticle: 116429
GX wrote: > any IP vendor out there who supply hard/soft core for V.34Modem? I wrote: > V.34 is normally (probably always) implemented in software. You could > put any DSP core (or RISC core with DSP capability) into your FPGA or > ASIC, and run a V.34 implementation on it. GX wrote: > Thanks for your response. > > After googling, I have found lot of Single chip Modem ASICs. > like, MN195006 from Panasonic. > > Did anyone integrated the functional equivalent of these single chip > modem chip in to FPGA/ASIC/SoC? The answer is still the same. The MN195006 is almost certainly a mask programmed DSP, or perhaps an ASIC containing a DSP core and ROM. You can certainly put a DSP core into an FPGA, but there's not likely to be enough block RAM for all the code for V.34, so you'll need external memory. In an ASIC, it's possible to integrate the whole thing, as the MN195006 shows. If the MN195006 does what you need, you're almost certainly better off buying that and interfacing it to your own design, than trying to integrate a modem yourself. Unless you expect volumes well over 100K units, the integrated approach will be significantly more expensive. If you really think you want to do it, there are companies out there that will be happy to sell you a license for a V.34 software implementation, which you can then use in your FPGA or ASIC. Do a Google search for "v.34 soft modem" and several turn up. EricArticle: 116430
Hello all, Does anyone has some numbers on the frequency spectrum of the jitter from a DCM? The datasheet says the DCM has a jitter of 100ps but I would like to know a bit more about the spectrum to determine whether or not the clock from a DCM is usefull for sampling. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 116431
Don't forget to check out XAPP's 434 and 443: http://www.xilinx.com/bvdocs/appnotes/xapp434.pdf http://www.xilinx.com/bvdocs/appnotes/xapp443.pdf The reference designs here might be just what you are looking for. "Andreas Ehliar" <ehliar@lysator.liu.se> wrote in message news:espn0e$g9h$1@news.lysator.liu.se... > On 2007-03-08, jrabbani@gmail.com <jrabbani@gmail.com> wrote: >> Ok. I will try to get the data sheet this way. In the meantime, can >> you suggest the easiest way of establishing the Gigabit etherner >> connectivity between the FPGA and the host PC. I need speed in excess >> of 50 Megabytes / Sec. Should I go the EDk way or to try the verilog >> side. I have Virtex-4 FX so it has extensive support for Gigabit >> ethernet. Thanks. > > > It depends on what kind of application/data we are talking about. > It is for example not that hard to send UDP data to a static IP address > using a hardcoded MAC address in your design. The dataflow could be > something like the following: > > Data in --> FIFO --> Add UDP/IP header --> Asynchronous FIFO --> > --> CRC generator --> Ethernet PHY > > This setup should work well if you have a fast PC connected to your > design either directly or through a switch. However, you should be > prepared to lose a few packets here if your PC is not fast enough or > does not allocate enough buffer space for UDP packets coming in at 50 > MB/s. However, if you need something like TCP/IP or the ability to > buffer data in an off-chip memory and send it to the PC on demand, you > are facing a tougher problem. In this case it is probably worth to > investigate what the EDK has to offer. > > > If you are going the first route I would suggest that you look at the > following lab exercise which has some good information (only for > 10/100 Mb/s Ethernet but the only difference is that you are typically > using 8 wires for data to a gigabit Ethernet PHY instead of 4): > > http://www.sm.luth.se/~maglun/lab33/lab33.pdf and > http://www.sm.luth.se/~maglun/lab33/ > > In particular, they have an explanation of the Ethernet CRC and a > couple of example CRC:s which is very valuable when you are trying to > send an Ethernet packet through your own CRC generator. > > > /AndreasArticle: 116432
On Mar 8, 11:36 am, "Weng Tianxiang" <wtx...@gmail.com> wrote: > 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, > I have another question for you. > > 1. Is any combinational equation with target signal in both right part > and left part of the equation a latch like your equations 3 or 4 show? While Jim and Peter can debate whether or not it's a latch or an oscillator, suffice it to say that any time you have something of the form of equations #3 and #4 where you have the same signal on both sides of the '<=' in a concurrent statement you have some form of storage or memory being inferred that will cause you the exact same timing/glitch/hazard issues to deal with as you would if you have something that matches exactly #3 and #4. The important thing to take away is not whether it's a latch or an oscillator or anything else, just that red flags should go off in your head when you see the output being used on the right side of the equation. Whether this is a problem or not depends on what the target device is. In ASICs this will not be a problem, in FPGAs you have to be very careful or it will be a problem. > > 2. Is there any general algorithm to change such an equation to a > latch equation? Not sure what you mean....all four forms that I presented are exactly equivalent 'latch equations', they will produce the same synthesized result. Equations #1 and #2 involve less typing then #3 and #4. Also keep in mind, that latches do not need to fit into a single equation, any time that you form a combinatorial loop you have to be concerned about how this will get implemented. A combinatorial loop happens when you have multiple equations, none of which inherently shows any feedback but taken together the whole set does. A simple example of this would be #5 Q <= (C and X) or (not(C) and Y); -- Eqn. 5a Y <= Q and Z; -- Eqn. 5b Equation 5a, on the surface appears to be a 2->1 multiplexer where 'C' is simply used to select between two signals 'X' and 'Y'. Equation 5b, on the surface appears to be a simple anding of two signals 'Q' and 'Z'. But when you put them together the two form a combinatorial loop because 'Q' depends on 'Y' and 'Y' depends on 'Q'. When you run through synthesis, these things generally get flagged as warnings somewhere. The nice thing is that it will find all these loops no matter how complex the equations or how spread out they are as long as they are totally self contained within the entire design. By that I mean, lets say that Equation 5a was implemented in some entity somewhere in some file and Equation 5b in a totally different entity in some other file. By themselves, each entity/file will synthesize just fine. But when you add the code for the entity that ties these two blocks together that new design and synthesize that new block, you'll have now formed the loop and the synthesizer should flag the warning for you. Take those warning seriously if you're designing in the FPGA/CPLD world. Kevin JenningsArticle: 116433
> > If you have a split ground plane it would seem that the signal > lines should go around, and not cross the split. > The signal will go where the copper is which is over the ground plane split. The return current for that signal will follow it's copper which is in the ground or power plane so it will be forced around the split. This separates the signal current from it's return current which causes a nice big radiating loop....bad for EMI if the edge rate on that signal is single digit nanoseconds. Kevin JenningsArticle: 116434
Nico, The power spectral density (the spectrum you would see on a spectrum analyzer) is extremely close to the carrier -- that is no spurs. The reason for this is that if you make small adjustments to the delay lines every so many clocks, these small steps (~25ps steps) represent a tiny increase or decrease in the period of the clock, which means that there is a correspondingly tiny step of frequency that lasts for one period, and then is gone. The result is gaussian noise bump in spectra around the carrier. There are no other frequency components (unless they are already present in the input clock, in which case they come directly through -- a DCM does not attenuate jitter). In the time domain, if you do a histogram of periods, you will get two overlapping (or more) gaussian distributions of period length: period - tap, period + tap, possible period + two taps, possible period - 2 taps. The time domain is the superposition of period lengths with and without the taps inserted. Since the change in tap is completely random (like flipping a coin each time), there is no determinism, and hence no rate at which changes occur, and no sub-harmonics, or sidebands. AustinArticle: 116435
Peter, No argument from me as you seem to be saying the same thing I said. I interpreted Weng's question as being, when a combinational signal is on both the right and left side of an equation, is the only hardware solution a latch. The answer which we both observed is no and the simple case is an oscillator. Cheers, Jim > I think we will agree that a latch needs positive feedback from the > output to at least one of the inputs. > If the feedback is negative (Qbar to D, for example) you end up with > an oscillator. > Peter Alfke > > On Mar 8, 9:49 am, Jim Lewis <j...@synthworks.com> wrote: >> Weng> Hi KJ, >>> I have another question for you. >> >> Q <= (C and D) or (not(C) and Q); >> >>> 1. Is any combinational equation with target signal in both right part >>> and left part of the equation a latch like your equations 3 or 4 show? >> A latch is the most benign form. >> There are oscillators (however when they occur by >> accident, they are not necessarily this obvious): >> Q <= not Q ; >> >> There is also other strange latch-like behavior. >> I don't have an equation for you, but I do remember >> analyzing one - it was very interesting. >> >> Cheers, >> Jim > >Article: 116436
On Mar 8, 4:18 pm, Jim Lewis <j...@synthworks.com> wrote: > Peter, > No argument from me as you seem to be saying the same > thing I said. > > I interpreted Weng's question as being, when a combinational > signal is on both the right and left side of an equation, > is the only hardware solution a latch. > > The answer which we both observed is no and the simple > case is an oscillator. > > Cheers, > Jim > > > > > I think we will agree that a latch needs positive feedback from the > > output to at least one of the inputs. > > If the feedback is negative (Qbar to D, for example) you end up with > > an oscillator. > > Peter Alfke > > > On Mar 8, 9:49 am, Jim Lewis <j...@synthworks.com> wrote: > >> Weng> Hi KJ, > >>> I have another question for you. > >> >> Q <= (C and D) or (not(C) and Q); > > >>> 1. Is any combinational equation with target signal in both right part > >>> and left part of the equation a latch like your equations 3 or 4 show? > >> A latch is the most benign form. > >> There are oscillators (however when they occur by > >> accident, they are not necessarily this obvious): > >> Q <= not Q ; > > >> There is also other strange latch-like behavior. > >> I don't have an equation for you, but I do remember > >> analyzing one - it was very interesting. > > >> Cheers, > >> Jim- Hide quoted text - > > - Show quoted text - Hi KJ, Jim and Peter, Thank you for your response and help. Anyway now I understand the latch a little more than before the posting. In coding experiences, when writing code equations, a reasonalble FPGA engineer will never generate a situation that leads to a signal appearing in both sides of logic equation in concurrent area. Because most of time the odd behavior equations would be fully beyond the acknowledgable. And there is no reason to generate an oscillator neither. Jim correctly repeated my question and both of you gave me a right answer. WengArticle: 116437
Weng, > 2. Is there any general algorithm to change such an > equation to a latch equation? I have not seen any evidence of one you can expect different tool vendors to support. For RTL code, if you want a synthesis tool to reliably create a latch library part, only use #1 or #2 (below from KJs post). Going further, if you want to avoid portability issues with some of the ASIC synthesis tools, then use only #1. >> #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'); If you use other forms, a synthesis tool may generate logic that implements latching behavior without using a latch part. If you use these to deliberately create a latch, good luck. Generally people accidentally create the other forms when two separate pieces of logic communicate. Cheers, JimArticle: 116438
The problem I am having maybe due to jitter. I am not sure. I am running under 35 MHz, althougth I am using LVDS. I am sampling on the rising and falling edge of the clock, and the deserializer needs to take every 7 clocks (respective 14 bits) since it is DDR. When I look at the output clk/7 that I generate by a simple counter (when counter = 1-4 clk is high, when counter = 4-7 clk is low), I see that the duty cycle changes by about 1 clock. It seems as though the counter misses a beat or something of that nature. What I expect to see is a newly generated clock where the rising edges occur at the same place every time, although, I see a rising edges "walk" with respect to my trigger on the scope. I have no idea the source of the problem, or how to fix it. Regards On Mar 8, 2:12 pm, "Will Dean" <w...@nospam.demon.co.uk> wrote: > "nfirtaps" <lloyd.roches...@gmail.com> wrote in message > > news:1173383894.763347.110110@64g2000cwx.googlegroups.com... > > > > > 1.) Can I somehow drive aPLLwith a general purpose I/O > > I don't think so. I'm usingCycloneII at the moment and I'm 99.9% sure you > can't feed the PLLs with anything except one of the 'clock input' pins. > (These can also be general purpose input pins, so I would always recommend > connecting anything vaguely 'clock-like' to one of those pins, even if you > think you might not actually use it as a clock.) > > > 2.) Is there another way of deserializing the DDR signal. > > You don't say anything about frequency, but I'd be inclined just to sample > on the falling edge as well, and then shift the two bits (+ve edge and -ve > edge) into your shift register on the next +ve clock. > > > Currently I have a the DDR clock coming in my fpga and I not the clock > > so I can sample the DDR signal on the rising egde. > > Is that giving you a problem? > > WillArticle: 116439
On Mar 8, 8:22 pm, barukula.ram...@gmail.com wrote: > i have downloaded the CAN VHDL from opencores but am unable to > understand the code. > can anyone please tell me where i can get the document for that code. There isn't much (any?) documentation. But you only need to understand the operation of the core, and its interfaces, not how it works internally. The core basically replicates a Philips SJA1000 CAN controller - all the registers are the same. So just look at http://www.nxp.com/pip/SJA1000 and get the datasheet. There are 2 interfaces (at least in the Verilog version) - Wishbone and 8051. The Wishbone interface is specified by Opencores - get the spec from http://www.opencores.com/projects.cgi/web/wishbone/wishbone You can get the (Intel) 8051 spec from the datasheets and app notes from any of the vendors making 8051 clone chips - start here http://en.wikipedia.org/wiki/Intel_8051 Best wishesArticle: 116440
>>If you have a split ground plane it would seem that the signal >>lines should go around, and not cross the split. KJ wrote: > The signal will go where the copper is which is over the ground plane > split. The return current for that signal will follow it's copper > which is in the ground or power plane so it will be forced around the > split. What I meant was the the copper should follow the ground plane, such that the signal does go that way. It says signal lines, so I don't see how you would read it any other way. -- glenArticle: 116441
On Mar 9, 2:38 am, Eric Smith <e...@brouhaha.com> wrote: > GX wrote: > > any IP vendor out there who supply hard/soft core for V.34Modem? > I wrote: > > V.34 is normally (probably always) implemented in software. You could > > put any DSP core (or RISC core with DSP capability) into your FPGA or > > ASIC, and run a V.34 implementation on it. > GX wrote: > > Thanks for your response. > > > After googling, I have found lot of Single chipModemASICs. > > like, MN195006 from Panasonic. > > > Did anyone integrated the functional equivalent of these single chip > >modemchip in to FPGA/ASIC/SoC? > > The answer is still the same. The MN195006 is almost certainly a > mask programmed DSP, or perhaps an ASIC containing a DSP core and ROM. > > You can certainly put a DSP core into an FPGA, but there's not likely > to be enough block RAM for all the code for V.34, so you'll need > external memory. In an ASIC, it's possible to integrate the whole > thing, as the MN195006 shows. > > If the MN195006 does what you need, you're almost certainly better > off buying that and interfacing it to your own design, than trying > to integrate amodemyourself. Unless you expect volumes well > over 100K units, the integrated approach will be significantly more > expensive. > > If you really think you want to do it, there are companies out there > that will be happy to sell you a license for a V.34 software > implementation, which you can then use in your FPGA or ASIC. Do a > Google search for "v.34 softmodem" and several turn up. > > Eric Thanks very much Eric. This helps me a lot. -GXArticle: 116442
On Mar 8, 10:51 am, "Symon" <symon_bre...@hotmail.com> wrote: > "John McCaskill" <junkm...@fastertechnology.com> wrote in message > > news:1173371757.756269.53650@h3g2000cwc.googlegroups.com... > > > On Mar 8, 10:06 am, Austin Lesea <aus...@xilinx.com> wrote: > >> Symon, > > >> Intel is keeping this secret. If true, it is a huge improvement, and > >> one that the foundries will be itching to get their hands on. > > >> The hi-K dielectric for the transistor will keep the roadmap moving > >> forward with lower leakage (the gates leak at 65nm and below), and > >> perhaps better speed (hi-K makes the transistor stronger according to > >> Intel). > > >> Austin > > > I don't remember where I first saw it mentioned, but they are not > > keeping it a secret. Here are a few mentions about it: > > >http://pubs.acs.org/cen/news/85/i06/8506notw4.html > >http://www.intel.com/technology/silicon/45nm_technology.htm > > > And here is the leading supplier of it: > > >http://www.wahchang.com/pages/products/data/hafnium.htm > > > Regards, > > > John McCaskill > >www.fastertechnology.com > > I guess Austin means they're keeping the process details secret, not the > results. Go to the above link you posted on intel.com and search for > 'secret'! ;-) > HTH, Syms. Perhaps that is what he meant, but I would expect that either Intel would licence their technology after a while, or the IBM/AMD/Sony/ Toshiba group will. If none of them want to license it, I didn't want it anyway. After all, hafnium is only half as good as unobtanium which is used in all the best -K dielectrics. Regards, John McCaskill www.fastertechnology.comArticle: 116443
If your input clock is not on the global clock network you will be fighting with clock skew to the flops. When your clock edges are happening with respect to the data at the flops becomes an utmost concern for you. "nfirtaps" <lloyd.rochester@gmail.com> wrote in message news:1173383894.763347.110110@64g2000cwx.googlegroups.com... >I am trying to deserialize a DDR signal in my Cyclone. For reasons I > won't go into the DDR clock comes in off a general purpose I/O pin. I > need a way of deserializing this signal, and want to increase the > frequency of the DDR clock by 2 so I can use rising edge flip-flops. > > 1.) Can I somehow drive a PLL with a general purpose I/O > 2.) Is there another way of deserializing the DDR signal. > > Currently I have a the DDR clock coming in my fpga and I not the clock > so I can sample the DDR signal on the rising egde. > > Thanks >Article: 116444
In article <1173304789.265305.168410@p10g2000cwp.googlegroups.com>,
axr0284@yahoo.com says...
> Hi,
> I would like to know what are the common methods of introducing
> delays as low as 10ps between two outputs in an FPGA.
Do it on the PC board? Depending on board material, a 10 ps delay
translates to adding about 2 mm to a trace length.
A worked out example of the math: an FR-4 microstrip has a dielectric
constant of about 3.4, giving a transission velocity of:
(3e8 m/s)/sqrt(3.4) = 1.63e8 m/s
Multiplying by 10 ps (1e-11) cancels the seconds, giving 1.63e-3 m, or
1.63 millimeters.
Of course, you need to adjust the dielectric constant for the material
you're using, or you can end up wrong by a fairly substantial margin.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Article: 116445Hi, I feel you are talking about fullcustom ICs when talking about ASICs. There exist fix predesigned technology libs when doing cell based design, and Sea-of-Gate ASIC didn't allow to include anything not available in the technology. On 8 Mrz., 12:57, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> wrote: > Karl wrote: > The main differences: > - FPGAs come with IOBs (QDR/DDR/SDR, differential/single-ended, in/out/inout, etc.), with > ASICs you have to license someone else's or create your own Or choose a ASIC technology that fits. I never bothered about IOs in an ASIC. DDR is so easy in ASIC, but may be hard if your fpga didn't support it (every fpga allows DDR as long, as your FPGA is _slow_ clocked, but you have trouble getting data in and out on a speed exceeding your Fpgas fmax if your technology didn't support it by dedicated HW (don't expect to have all designs on a virtex *g*). > - FPGAs come with some analog bits (PLLs, DACs, ADCs, MGTs, etc.), with ASICs you have to > license someone else's or create your own Which FPGA provides DAC and ADC? Actel Fusion provides AFAIK only ADC and is the only available mixed signal FPGA known to me. I would have considered a PLL as a standard for actual ASIC technologies. > So, for me, the most significant difference between ASIC and FPGA after the development > cost and production timetable is having to license all the low-level nuts and bolts if I > want to be able to concentrate on the higher-level functions I wish to implement without > having to worry about going through a dozen re-spins just to get the low-level stuff like > FFs and IOBs to work properly. This is not true for the cell based design I worked on. by ThomasArticle: 116446
Sean Durkin schrieb: > Markus Fras wrote: >> Checking timing specifications ... >> Checking expanded design ... >> ERROR:NgdBuild:604 - logical block 'inst_fifo/BU2' with type >> 'fifo18w16d_fifo_generator_v2_3_xst_1' could not be resolved. A pin name >> misspelling can cause this, a missing edif or ngc file, or the >> misspelling of >> a type name. Symbol 'fifo18w16d_fifo_generator_v2_3_xst_1' is not >> supported >> in target 'virtex2'. > Is there a third file in the coregen-directory? There might be an > .ngc-file called fifo18w16d_fifo_generator_v2_3_xst_1.ngc. If so, you > have to add this to your project as well (also with the -exclude > option). The .edn is then just a wrapper for the .ngc, and is way smaller. > > I've had this problem before. Even if I explicitely tell CoreGen that I > want it to create an EDIF-netlist for third-party tools, I always get an > .edn and an .ngc, and I need them both. I don't remember this from > earlier ISE-versions, but I might just not have tried all different > settings. > > HTH, > Sean > Well, Xilinx CoreGen created two additional files: fifo18w16d_fifo_generator_v2_3_xst_1.ngc fifo18w16d_fifo_generator_v2_3_xst_1_blkmemdp_v6_2_xst.edn Even if I include both of the, I still get the same error message. The solution is to add the output directory of CoreGen to ngdbuild with the switch `-sd'. Then you need only to include the *.v file in the synthesis. I.e. in the synthesis script only add the line `add_input_file fifo18w16d.v' and to the ngdbuild command, add the switch `-sd <coregen_output_directory>' Cheers, Markus FrasArticle: 116447
Hi everyone, I just installed a new workstation, a Core2 duro running linux 64 bits. But I can use data2bram on it, it crashes every time. I've tested with both 8.2 and 9.1 (both with latest service pack). For 8.2 I even tried the 32b and the 64 version. Using this utility is really important for me to update picoblaze and microblaze software without a need to recompile each time I want to test a new firmware. Has anyone encountered such an issue ? SylvainArticle: 116448
I've been wondering if someone else has noticed that RLOCs does not seem to be working very well in ISE 8.2 and 9.1? Currently I'm experimenting with a project where the RLOCs are working ok for smaller submodules but when I try to instantiate these submodules into a larger design in several places the RLOCs are lost in some way. In ISE 8.1 everything is working as expected though. /AndreasArticle: 116449
jetm...@hotmail.com wrote: > Hi. > > I want to load the bitstream encryption key on a V4FX board. > > Using IMPACT and a Xilinx download cable, I can successfully load it > (together with a design file). > > However, my board doesn't normally expose the JTAG pins to connect a > Xilinx cable. Instead, it uses a proprietary interface. I can play > XSVF files over this interface to program the bitstream. > > To create the XSVF I repeat the same steps that work with a Xilinx > cable, recording to XSVF. However, playing this file on my board > doesn't load the keys. Analysis of the XSVF suggests that IMPACT (ISE > 8.1 SP3) forgets to include the JTAG commands for the key for some > reason. > > At least, when recording to an ASCII SVF file, I can't locate the key > anywhere. > > As alternative approach to the problem, I browsed the V4FX > documentation for instructions on how to create a key loader program > myself. Unfortunately the only hint I found is that ISC_PROGRAM can > be (somehow) used to enter a so-called "key-access mode", without > giving further details on the matter. > > I appreciate any information on that matter. Even just a sample > (X)SVF containing the instructions for a key load would be of help to > me. > > Thanks, > 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