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 Aug 1, 7:09=A0am, "sharanbr" <sharanb@n_o_s_p_a_m.hcl.com> wrote: > >Sharan wrote: > >> can someone tell me if there is any differences in the die for the > >> following 2 devices in virtex-7 > > >> XC7VX415TFFG1158 and XC7VX415TFFG1927 > > >> Both these devices are listed as having same logic resources. > >> XC7VX415TFFG1158 has 35 X 35 mm package > >> XC7VX415TFFG1927 has 45 X 45 mm package > > >> Can I assume that the only difference is the package and the > >> underlying die is going to be the same? > > >> TIA > > >I'm not in the V7 camp yet, but to date that is the way > >Xilinx handles chip products. =A0For each family and gate > >size there is one die, which has different bond-outs > >depending on the package. =A0If it's a small die in a > >large package you end up with non-connected package pins. > >A large part in a small package ends up with unbonded > >IOB's. =A0But open the parts in the FPGA editor and you > >see the exact same diagram with just different labels > >on the IOB's. =A0In fact on the smaller packages you > >can use the unbonded IOB's as extra resources if you > >run out of fabric flops for example. > > >-- Gabor > > Thanks, Gabor. > > Also, can you tell why certain devices are in a specific package while > another device with more supported pins is in a smaller package. > > For example (example only, nothing specific to Virtex-7) > v7vx1140t - min package is 45 x 45 mm package & supports 480 pins > v7vx585T =A0- min package is 35 x 35 mm package & supports 600 pins > > I am not sure why a 480 pin needs 45X45 mm package while 600 pins is put = in > a 35X35 mm package > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com- Hide quoted text - > > - Show quoted text - Trying again, as the first post doesn't seem to have gone through (at least on google groups). The 7VX1140T will be available in two packages the FLG1928 and the FLG1930 both of these are 45x45mm 1.0mm pitch packages. The 7VX1140T-FLG1928 supports 0 GTX lanes, 96 GTH lanes and 480 IO The 7VX1140T-FLG1930 supports 0 GTX lanes, 24 GTH lanes and 1100 IO The 7VX585T will be available in two packages the FFG1157 (35x35mm) and the FFG1761 (42.5x42.5mm) both of these are 1.0mm pitch packages. The 7VX585T-FFG1157 supports 20 GTX lanes, 0 GTH lanes and 600 IO The 7VX585T-FFG1761 supports 36 GTX lanes, 0 GTH lanes and 850 IO Your original comparison was only for the Select I/O pins which is why it seemed odd to you. Each of the GTX/GTH (MGT) lanes takes 4 pins for the TX/RX and for each quad block of MGTs there are 2 reference clocks (4 pins) plus additional power and ground pins. Ed McGettigan -- Xilinx Inc.Article: 152301
Tim Wescott <tim@seemywebsite.com> writes: > Most of my experience with this has been as an amused observer, rather > than an appalled participant. It stemmed from a corporate rule "thou > shalt make the synthesis tool happy about timing" and a rather aggressive > design group from out of state that was known to have scripts that would > do synthesis runs over and over until one happened to meet timing, then > stop and ship that file 'upstairs'. Ahh, I can see where that might cause hassle. I'm not a fan of stochastic timing closure... I tend to fix timing problems by grovelling through the tmiing reports on the failing paths and fixing something in the RTL to make life easier for the tools (I tend not to push silicon right to it's limits, so I can get away with that!) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 152302
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Martin Thompson <martin.j.thompson@trw.com> wrote: > > (snip on timing of processors and FPGAs) > >> More usefully (again IMHO) there are statistical methods for measuring >> execution time and its variability down various code paths, which can be >> used to provide arbitrarily high levels of confidence as to the >> likelihood of missing a real-time deadline, as well as showing what to >> optimise to improve the worst-case - this sometimes means using what >> might be regarded in mainstream compsci as "inefficient" algorithms, as >> they have better bounds on worst-case performance, even at the expense >> of average performance. I ought to stop now, I'm no doubt "rambling to >> the choir" as well as getting off-topic :) > > Sounds right to me. Now, isn't that also true for FPGAs? The statistics or the algorithms? Certainly, FPGAs often suit different algorithms. And yes, the statistics is also there... I should've made that clear at the start - I put "worst-case" in quotes without explaining what i meant. Sorry about that. > >>>> In hardware, the tools know everything they need to about the timing >>>> of the chips and can give you a "cast-iron" statement as to how >>>> fast things will be in the worst-case. > >>> They might do some rounding up in the timing, to be sure. > >> I'm not sure what you mean by that: The tools "know" worst-case >> timings for the various silicon paths and add them all up. >> Rounding doesn't come into it. > > Consider that some timings might be Gaussian distributed with > a tail to infinity. Also, that it is really difficult to get > the exact timings for all possible routing paths. Indeed. It's a little easier for the FPGA, especially in a highly pipelined design as the timing paths are broken up much more - so there are less "long chains of logic and routing" than their might be "chains of control flow through software". As you say, it's a very simialr problem, but the FPGA is much more constrained. > As with the > real-time processor, you don't really want worst-case, but > just sufficiently unlikely to be exceeded times. Indeed, and because the FPGA vendors give us a timing analyser that people are going to have a reasonably high level of trust in, they define "unlikely to be exceeded" pretty conservatively. Of course, if your system is pushing the edges in some sense (esp. criticality of operation) the prudent engineer will allow more margin etc. > > Some of the distributions won't quite be Gaussian, as some of > the worst-case die are rejected. Consider, though, that there > are a finite number of electrons on a FET gate, ever decreasing > as they get smaller. > > Some of the favorite problems in physics class include determining > the probability of all the air molecules going to one half of > a room, or of a person quantum-mechanically tunneling through > a brick wall, running at a given speed. Both have a very low, > but non-zero, probability. > I think we're in violent agreement. My point really was (and I shouln't have used the phrase "worst-case" without qualification) that getting an arbitrarily high confidence of "meeting timing" is readily-available with FPGA tools, but in the software domain, it's only just starting to be an automatable task, and that out-of-the-box commercial compilers (AFAIK) are of no assistance in that respect. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 152303
Martin Thompson <martin.j.thompson@trw.com> wrote: (snip) > Ahh, I can see where that might cause hassle. > I'm not a fan of stochastic timing closure... I tend to fix timing > problems by grovelling through the tmiing reports on the failing paths > and fixing something in the RTL to make life easier for the tools > (I tend not to push silicon right to it's limits, so I can get > away with that!) After my previous post, I was thinking about how FPGA companies have an incentive to quote faster devices, and so want the timing reports to be fast, without an excessive margin. There are always process variations, and for the user voltage and temperature variations. For most, it shouldn't be so hard to stay within the voltage range, though maybe not so hard to miss by a little. (Slightly defective power supply.) Temperature is a little harder to control. If one is too close on timing, and the temperature is a little high, the design could fail. -- glenArticle: 152304
valtih1978 <do@not.email.me> writes: > I remember there was a picoBlaze-related program that could update BRAM in a > compiled bitstream with any userdata. Data2MEM is the tool I think you're thinking of. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 152305
>valtih1978 <do@not.email.me> writes: > >> I remember there was a picoBlaze-related program that could update BRAM in a >> compiled bitstream with any userdata. > >Data2MEM is the tool I think you're thinking of. > >Cheers, >Martin > >-- >martin.j.thompson@trw.com >TRW Conekt - Consultancy in Engineering, Knowledge and Technology >http://www.conekt.co.uk/capabilities/39-electronic-hardware > I do hope the OP enjoys reading The Fine Data2mem Manual (UG437, for those of a curious turn of mind). --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152306
I have a client who is trying to use the QuartusII Ver 11.0 stand alone programmer to program a Cyclone IV board, and is having problems and his machine isn't seeing the programmer (It's an Entner EEBlaster but it also can't see a Terasic blaster so I'm confident that isn't the problem). Version 9.0 of the programmer can see it OK but can't drive the Cyclone IV on his board. Has anyone seen any problems like this before and have any recommendations? Thanks for any pointers, Nial Stewart ---------------------------------------------------------- Nial Stewart Developments Ltd Tel: +44 131 516 8883 32/12 Hardengreen Business Park Fax: +44 131 663 8771 Dalkeith, Midlothian EH22 3NX www.nialstewartdevelopments.co.ukArticle: 152307
On Fri, 05 Aug 2011 08:38:56 +0100, Martin Thompson wrote: > Tim Wescott <tim@seemywebsite.com> writes: > >> Most of my experience with this has been as an amused observer, rather >> than an appalled participant. It stemmed from a corporate rule "thou >> shalt make the synthesis tool happy about timing" and a rather >> aggressive design group from out of state that was known to have >> scripts that would do synthesis runs over and over until one happened >> to meet timing, then stop and ship that file 'upstairs'. > > Ahh, I can see where that might cause hassle. > > I'm not a fan of stochastic timing closure... I tend to fix timing > problems by grovelling through the tmiing reports on the failing paths > and fixing something in the RTL to make life easier for the tools (I > tend not to push silicon right to it's limits, so I can get away with > that!) Interestingly enough, the engineering group that I was with (which was a short walk away from the production line) felt exactly the way you did -- they would go as far as look for the worst possible path, and if it passed timing, but barely, they'd look for things sticking out and fix them. The other group consistently got rewarded for "getting done" quickly, and somehow no one ever kept track of the number of times that their work was what was stalling production (while we fixed it in our "spare time", because we were closer). -- www.wescottdesign.comArticle: 152308
> The balance has stemmed from folks taking the Xilinx speed grades at face > value, and using what the synthesis tool says (using Xilinx's defaults) > at face value. Once the group learned that you have to force a bit of > margin into the process (and the group thinks that a design that fails to > synthesize once out of ten is a problem, as opposed to thinking that a > design that succeeds once out of twenty is 'shippable') then those > problems went away. Tim, are talking about synthesis or the timing analysis after P&R? NialArticle: 152309
On Fri, 05 Aug 2011 16:43:01 +0100, Nial Stewart wrote: >> The balance has stemmed from folks taking the Xilinx speed grades at >> face value, and using what the synthesis tool says (using Xilinx's >> defaults) at face value. Once the group learned that you have to force >> a bit of margin into the process (and the group thinks that a design >> that fails to synthesize once out of ten is a problem, as opposed to >> thinking that a design that succeeds once out of twenty is 'shippable') >> then those problems went away. > > > Tim, are talking about synthesis or the timing analysis after P&R? Sorry -- muddled thinking working in concert with mostly being an observer. Timing analysis after P&R, yes. -- www.wescottdesign.comArticle: 152310
"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in message news:9a2gthFnv8U1@mid.individual.net... >I have a client who is trying to use the QuartusII Ver 11.0 > stand alone programmer to program a Cyclone IV board, and is having > problems and his machine isn't seeing the programmer (It's an Entner > EEBlaster but it also can't see a Terasic blaster so I'm confident > that isn't the problem). > > Version 9.0 of the programmer can see it OK but can't drive the Cyclone IV > on his board. > > Has anyone seen any problems like this before and have any > recommendations? > > > Thanks for any pointers, Hello, I had problems when installed very old FTDI drivers. Altera programmer gets frustrated when any FTDI chip is connected, but works if drivers are new. Tell the customer to unplug all the USB<->UART devices firstly or better to unplug everything from the USB, except the programmer. Regards, Tomas D.Article: 152311
Hi all I want to do a project with a FPGA. The FPGA that I choos is ALTERA Cyclone III.I think that there is no analog input in that. Of course, I know that I can use an external ADC(A/D) but I cannot do it because my inputs and outputs are too much. can everyone tell me a FPGA from this family (ALTERA) that have analog inputs and output? RegardsArticle: 152312
"ECS.MSc.SOC" <mahdiyar.sarayloo@gmail.com> wrote in message news:1a84ac7b-ee97-45b5-9bf7-10343d9571b4@g4g2000yqb.googlegroups.com... > Hi all > > I want to do a project with a FPGA. The FPGA that I choos is ALTERA > Cyclone III.I think that there is no analog input in that. Of course, > I know that I can use an external ADC(A/D) but I cannot do it because > my inputs and outputs are too much. > > can everyone tell me a FPGA from this family (ALTERA) that have analog > inputs and output? > > Regards AFAIK none of the Altera Cyclone or Stratix series have 'analog' I/O. The only combo devices I am aware of and have tried to use are the Actel Fusion series. The downside is the analog portion tends to have low usable bandwidth (like 1MHz), and the ADC's of low resolution (12bits max) and low sample rate (600kHz) so for most of my applications are a) expensive, and b) unusable. Your best bet if you have limited I/O resource ( and even with plenty of I/O resource!) is to use ADC's and DACs with serial I/O. You can get some pretty decent fast ADC's now with LVDS DDR outputs which will easily interface with your Cyclone III. The trouble with trying to make FPGA's a real total SOC solution is you always end up with a very expensive compromise with lots of spare unusable expensive resource which you have paid for. The same applies (IMHO) with embedding processors in an FPGA. Why pay $200 for an integrated solution when a $20 FPGA and a separate $2 processor fits the bill? Same applies to trying to integrate analog devices on to an FPGA. Just my opinion PhilArticle: 152313
Hi all I am using Altera DE0 Cyclone III board. I am confused about the RS232 connection in DE0 Cyclone II. my question is that: There are some connection in FPGA board related to the RS232. Dose it mean that there is a transceiver in the DE0 board or I should connect it to a tranceiver? RegardsArticle: 152314
"ECS.MSc.SOC" <mahdiyar.sarayloo@gmail.com> wrote in message news:11e1075b-601d-4229-8345-5b02cc64a8ed@y16g2000yqh.googlegroups.com... > Hi all > > I am using Altera DE0 Cyclone III board. > > I am confused about the RS232 connection in DE0 Cyclone II. my > question is that: > > There are some connection in FPGA board related to the RS232. Dose it > mean that there is a transceiver in the DE0 board or I should connect > it to a tranceiver? > > Regards 1) Download the manual here:- http://tinyurl.com/cannot-be-arsed 2) Turn to page 37 and read section 4.8 3) If you want further info on the ADM3202 then Google and search yourself. 4) Don't give up the day job. PhilArticle: 152315
Hi there! I need some advice. I want to make a circuit to drive a VGA monitor. I've done it with the FPGA trainer boards with Xilinx chips, but now I want to design a custom board that host only the necessary circuitry to do so and not depend on eval boards with lot of stuff I don't need. I've got already a bit experience on designing PCBs, I get pretty much along with the EagleCad, I've build mostly boards with microcontrollers and simply stuff. But now for what I see, handling FPGA is a completely different thing. For what I've been reading, FPGA need a lot of requirements, 50-ohms impedance for some clock traces, copper layer thickness, lots of different power planes,... heck, there is even some excel spreasheet from altera to calculate power supply stage decoupling caps =S Now I realize this might be a project beyond my current training, however, I want to give it a shot. I just need the basics: voltage regulators, configuration ROM, 50MHz clock, downloading cable interface; and of course, the VGA dac and some extra broke out pins to interface a microcontroller. Now, my question is... from the two FPGA biggest names, Altera and Xilinx, which one do you think would be easier to implement? Like in the programming interface, in meeting the power requirements, clock sources, etc... I mean, it's not that I want to start a flame war, I suppose there must be one superior in this particular aspect, or maybe not, and both are equally easy/difficult to use. And of course, as a last thought, if you thing I better should stick with a demo board and leave this for the future when I get to study more about transmision lines, advanced CAD tools, etc... Regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152316
Hello I want to compile rhe jpeg code for the microblaze processor. So i download the gnu tool for the microblaze ( i follow this http://xilinx.wikidot.com/mb-gnu-tools) I use a ubunto machine to compile i use the command: mb-linux-gcc timer.cpp jpge.cpp jpgd.cpp tga2jpg.cpp So that i obtain the file a.out. So what is the command to use now to have the executable file. Thanks in advance. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152317
On Mon, 08 Aug 2011 06:52:40 -0500, system85 wrote: > Hello > I want to compile rhe jpeg code for the microblaze processor. So i > download the gnu tool for the microblaze ( i follow this > http://xilinx.wikidot.com/mb-gnu-tools) I use a ubunto machine > to compile i use the command: mb-linux-gcc timer.cpp jpge.cpp jpgd.cpp > tga2jpg.cpp > So that i obtain the file a.out. > So what is the command to use now to have the executable file. Thanks in > advance. You need to call the compiler with a flag to the linker to use a linker command file that is specific to the Microblaze installation that you have in your FPGA. It needs to call out ROM and RAM areas, and specify whatever segments your code and libraries need to have specified. The best way to get this is to probably start with an example project that uses the tools, then figure out how to rip out the c files that are in there and replace them with your own. -- www.wescottdesign.comArticle: 152318
linobi <linobi@n_o_s_p_a_m.msn.com> wrote: > I need some advice. I want to make a circuit to drive a VGA monitor. I've > done it with the FPGA trainer boards with Xilinx chips, but now I want to > design a custom board that host only the necessary circuitry to do so and > not depend on eval boards with lot of stuff I don't need. So one of the smaller FPGAs in the series... > I've got already a bit experience on designing PCBs, I get pretty much > along with the EagleCad, I've build mostly boards with microcontrollers and > simply stuff. But now for what I see, handling FPGA is a completely > different thing. I believe that some of the smaller ones have simpler to work with packages. BGA is likely not easy for a first try. (I haven't tried, so I can't really say.) > For what I've been reading, FPGA need a lot of requirements, 50-ohms > impedance for some clock traces, copper layer thickness, lots of different > power planes,... heck, there is even some excel spreasheet from altera to > calculate power supply stage decoupling caps =S VGA doesn't need the top speed, but you still need to do some for both decoupling and impedance. Series termination is not so hard, and should work for VGA speeds. What else will your FPGA do besides drive a VGA? I can imagine a while graphical terminal, which should fit in a fairly small one. > Now I realize this might be a project beyond my current training, however, > I want to give it a shot. I just need the basics: voltage regulators, > configuration ROM, 50MHz clock, downloading cable interface; and of course, > the VGA dac and some extra broke out pins to interface a microcontroller. Also some data input source? (snip) > And of course, as a last thought, if you thing I better should stick with a > demo board and leave this for the future when I get to study more about > transmision lines, advanced CAD tools, etc... You should know a little about impedance matching before you do much electronics at all these days. -- glenArticle: 152319
On Mon, 08 Aug 2011 06:52:10 -0500, linobi wrote: > Hi there! > > I need some advice. I want to make a circuit to drive a VGA monitor. > I've done it with the FPGA trainer boards with Xilinx chips, but now I > want to design a custom board that host only the necessary circuitry to > do so and not depend on eval boards with lot of stuff I don't need. > > I've got already a bit experience on designing PCBs, I get pretty much > along with the EagleCad, I've build mostly boards with microcontrollers > and simply stuff. But now for what I see, handling FPGA is a completely > different thing. > > For what I've been reading, FPGA need a lot of requirements, 50-ohms > impedance for some clock traces, copper layer thickness, lots of > different power planes,... heck, there is even some excel spreasheet > from altera to calculate power supply stage decoupling caps =S The copper layer thickness requirement comes from current supply requirements. 50 ohms impedance on clock traces _hopefully_ only applies if you're going fast. > Now I realize this might be a project beyond my current training, > however, I want to give it a shot. I just need the basics: voltage > regulators, configuration ROM, 50MHz clock, downloading cable interface; > and of course, the VGA dac and some extra broke out pins to interface a > microcontroller. > > Now, my question is... from the two FPGA biggest names, Altera and > Xilinx, which one do you think would be easier to implement? Like in the > programming interface, in meeting the power requirements, clock sources, > etc... > I mean, it's not that I want to start a flame war, I suppose there must > be one superior in this particular aspect, or maybe not, and both are > equally easy/difficult to use. > > And of course, as a last thought, if you thing I better should stick > with a demo board and leave this for the future when I get to study more > about transmision lines, advanced CAD tools, etc... I don't know about which is better, but I would hazard a guess that if you're just running a 50MHz clock then you can get by with a lot less precision in the board than if you're trying to run right at the limit of the part. The biggest clock issue I'd be concerned with would be reflections causing false clocks, and that can be cured by putting your oscillator as close to the FPGA as you can get it, and/or terminating the clock line. I would recommend using a leaded package, as those can, with only moderate difficulty, be soldered by hand. If you're willing to forgo being able to use all the pins, you may even be able to use a two-layer board, although it's probably smarter to go with at least a four-layer board with ground and power planes. I think you could do this with EagleCad, if you're careful and know what you're doing. -- www.wescottdesign.comArticle: 152320
The best thing you could do is to have a look at some of the schematics and gerber files from the Xilinx boards. Getting a schematic that is functionally correct shouldnt be too much of a problem but you need to be a bit more carefull with the pcb. The lower the frequency you use the easier things will be, so you may be better off sticking to around 50MHz for your first board. BGAs are not hard to work with, however you can forget about soldering them yourself. So if you plan to do the soldering yourself then use a non BGA package. I mainly use Xilinx devices but I doubt there is too much difference between them and Altera. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152321
maxascent <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > BGAs are not hard to work with, however you can forget about > soldering them yourself. I believe I have heard stories about people doing BGA in a toaster oven. No idea about the success rate, though. -- glenArticle: 152322
Yes, I think I've seen some videos in Youtube where people does BGA rework even with hot air. But no, definitely no; I'll stick with some QFP package I can do by hand, so preferably one without pad. The thing is I noticed the 50-ohms impedance for the JTAG clock in the Spartan-6 Configuration guide, and then I found the excel spreadsheet for decoupling caps for the Cyclone IV power requirements. That's when I started wondering which one would give me somewhat of a bigger error margin. I'll go either with a Spartan 6 or 3A, or a cyclone IV, tqfp 100 or 144 max Yes, I'll try to follow from some schematics I found, but on the other hand, I don't think is very easy to mimic PCB routing, maybe just for isolated parts like the VGA dac. Thanks everyone, this is a really nice place to ask for help. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152323
Your question is very, very vague. It's not even clear what you're asking, though if I were to take a wild guess, I'd say you want to know how to get the data from the PC and store it in the BRAM. This is very open-ended and depends on a lot of things, there are many ways you can do it.. no single answer here. What communication protocol would you like to use? RS232, USB, something else? You need something in the FPGA that can receive your data stream. Then, you can either write a state machine which takes the data that you've received and figures out where to put it, or you could put a soft CPU in there and write an embedded program that could do the same thing. My full answer to this would also depend on what FPGA vendor you're using, and what other hardware and interfaces are on board, assuming you are using some already existing dev board or something of that sort... Supposing I was using a Xilinx FPGA to do this, I might go with a Picoblaze soft microcontroller and a simple UART or similar. If I want data faster than a UART can provide (sometimes I do), then I might use an FTDI chip FT245, which works just like a serial port on the host PC side, but gives the data to your device in parallel, 8-bits, and several times faster than the best you can probably do with a UART. If I still need something faster, then maybe I'd go for a Cypress FX2 USB controller, which many FPGA dev boards happen to have on board. That'd be overkill for what you're doing, but a good learning experience anyway, if you happen to be using a board that has this. Anyway, be more specific about what you have to work with and what you're trying to do, and I'm sure I or somebody else here would be happy to point you in the right direction. SteveArticle: 152324
I'm still using ISE 8.2i. Yes, I know. But it's served me well and I live by the "if it works don't upgrade it principle." "Served me well" until now that is. I may have found a bug. My FPGA works sometimes. Then I make certain innocent, harmless, neutral changes in an un-related area ... things stop working. Not an uncommon experience for FPGA engineers, I know. I've possibly traced it to a high speed (200 MHz) counter which is reloaded using data from another clock domain . That data is stable when the counter reloads; but the point where it changes relative to the counter clock is uncontrolled. I've checked the counter implementation using FPGA editor and noticed something curious about the LUT equations. When it works I get: <F>=((A1*A4)@A2); bel <vco_fa[0]/Mxor_d_Result1>. when it doesn't work I get: <F>=((~A2*(A1*A4))+(A2*(~A1+~A4))); bel <vco_fa[0]/Mxor_d_Result1>. for the same LUT, which is bit 0 of the counter. A1 is the reload control A2 is counter Q[0] A4 is the load input from another clock domain. The above two boolean expressions are equivalent; but why does FPGA Editor dump them in different formats and how do I verify what is actually in the LUT? I'm wondering if a glitch is coming through the LUT when A4 changes TIA
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