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 Fri, 15 Dec 2000 12:03:28 -0800, "Andy Krumel" <andy@krumel.com> wrote: >To date I have programmed the Spartan II using the MultiLinx cable in >slave-serial mode. We are now cutting over to program it using a >microcontroller. Can the .bit file generated by bitgen be fed directly into >the chip? > >I am confused because XAPP 098 "The Low-Cost, Efficient Serial Configuration >of Spartan FPGAs" on page 8 says a hex file should be generated and then >convert that to binary format. Yet XAPP 138 "Vertex FPGA Series >Configuration and Readback" does not make any mention of this consideration. >Does the XAPP 098 procedure need to be followed? > >Finally, I assume all the required CRCs are embedded in the generated >bitstream. Is that a correct assumption? > >Thanks, >Andy > Andy, we program Xilinx chips from a 68332 uP. We wrote a program that builds a ROM image from an S28 (motorola hex) file and one or more Xilinx .RBT files. The RBT files are ascii 1's and 0's (with some header lines) and include all the bits (fill, CRC etc) you need. Is a .bit file the same as a .rbt? Mail me (usual despam) if you want the program. JohnArticle: 27951
WTB: SAB82258, or R82258 in a PLCC package or PGA package Need 26 units ASAP, will pay $5.00 each.. Regards Dan Mathias -------------------------- Future-Bot Components Web: http://www.futurebots.com 106 Commerce way, A8 Email: fuboco@bellsouth.net Jupiter, Fl. 33458 USA Phone/Fax (561) 575-1487 ----------------------------------------------------------------------- Robotic and Electronic Components for the Hobbyist and Professional.. We have Motors, IC Chips, PC-Parts, Sensors, Robotic items......Article: 27952
Hi, I am trying to design a method of loading a number of counters with a preset values stored in store registers. Data is clked serially clked into a shift register on the rising edge of the serial clk(10 MHz) whilst the en signal is low, the serial to parallel converted data is then clked into store registers on the rising edge of the en signal( high for min period of 50 ns) which is asynchronous to the clk that is clking the counters .The clk to the counters can range between 10 Mhz to 400 Mhz, the counters count down to 0 then are reloaded with a preset value stored in the store registers. Any ideas how I can ensure that the no problems occur whilst new data is being loaded into the store registers and the counter is being reloaded? Thanks RobArticle: 27953
> On Fri, 15 Dec 2000 12:03:28 -0800, "Andy Krumel" <andy@krumel.com> > wrote: > > >To date I have programmed the Spartan II using the MultiLinx cable in > >slave-serial mode. We are now cutting over to program it using a > >microcontroller. Can the .bit file generated by bitgen be fed directly into > >the chip? Certainly -- with one minor caveat. At least in my (limited) experience, the .Bit file consists of a header followed by the raw bitstream itself. We have a PCI card with an XCV400 on it as well as a PLX 9054 for the PCI interface, and we slightly abuse the '9054's EEPROM and LED lines to serially program the FPGA when the board wakes up. The C code to do it seeks into the .Bit file to the correct magic offset (you have just look at a hex dump in the file to find this offset, since you know what the bitstream's preamble is) and then starts shifting bits serially through the '9054 to the FPGA. You can, of course, run the PROM formatter utility to generate a .Hex or .MCS or whatever file, but in our case, this was just an added step that didn't provide any utility. On the other hand, if you have funny programming requirements, the PROM formatter can prove useful -- we did a 4K design a couple years back where a DSP's serial port shifted out the configuration bitstream to the FPGA, and it was easier to let the PROM formatter do the bit swapping (due to the endianess of the serial port) than to write our own software to do it. Xilinx probably officially grumbles at the "hack the .Bit file directly" approach, since they can argue with complete validity than the format might change in the future, and only guarantee that the new PROM formatter utility would then know the correct interpretation of that new .Bit file format. We're not the only guys doing this, however -- we have a supplier whose boards do it as well. ---Joel KolstadArticle: 27954
4 associate professor/professor positions in System-on-Chip design at Royal Institute of Technology, Stockholm, Sweden ( http://www.ele.kth.se/ESD/Opportunities) The School of Information Technology of the Roayl Institute of Technology (KTH) is located in the center of Kista Science Park in Stockholm, Sweden. The Kista Science Park is ranked worldwide among top 3 leading development centers in mobile communications and information technology, with world-class research and a thriving industrial base. It offers the best opportunities for dynamic research and fruitful collaboration with the leading industrial partners. Due to our rapid expansion in our research programs and education in system-on-chip design area, we are announcing four Associate Professor positions in Electronic Systems Design with focus on different SoC aspects. All four positions include research and education at the graduate and undergraduate level and we can provide excellent opprtunities in financing and infrastructure for world-class research. The teaching language is English due to our international M.Sc. and Ph.D. programs (www.ele.kth.se/SoC/). These tenured Associate Professor positions can be upgraded to full Professors based on academic qualifications during the application time or afterwards. The four open positions are in the areas "Circuit design", "System-on-Chip design methods", "Design methods for embedded systems/reconfigurable computing", and "VLSI/ULSI design". For more information please read the announcement at www.ele.kth.se/ESD/Opportunities and contact Prof. Hannu Tenhunen <hannu@ele.kth.se>, Ph: +46-70-7335748. Application deadline is 15.2. 2001.Article: 27955
Hi, Kim Gunnar Enkovaara wrote: > > On Sat, 16 Dec 2000 13:28:07 +0530, Srinivasan Venkataramanan wrote: <SNIP> > > For example digital clock is good example. All the numbers can be > defined independently in a record and that record can be used in the > data bus definition. I think it's easier to say bus.sec than > bus[10:15]. The code is much easier to read when the names are used. > I got the idea of using records from one VHDL course where the trainer > was very experienced VHDL coder and synthesis tool trainer, > Very interesting indeed. > Those records even synthesized very well. The tools I tried were > Synplify Pro 6.0 (or 6.1 but that doesn't matter) and Synopsys Design > Compiler so the tools were not low end. I get my net connection up in > few days, after that I can give some examples if you want. > Would really appreciate that, TIA. > > > Well I don't know the tool that you talk about. But IMHO a *GOOD* > >lint tool MUST be > > > >1.> "configurable" i.e. the user should be able to specify *with ease* > >new rules > >2.> It should be possible to turn the checks ON & OFF with ease > > I tried TransEDA VNCheck. I think the tool was excellent and I > customized the rules but the Verilog coding style was still > the problem. It's difficult for the tool to guess what the designer > was thinking when he/she coded something weird. > Well, with a *GOOD* linter, you can "filter" out unwanted messages. But when you don't know whether the message is unwanted (I guess that's the situation that depicted) - I can imagine how annoying it could be. It is a BAD coding style (as you yourself mentioned) rather than a *BAD* lint tool itself. > >With the above qualities I think a lint tool can be of GREAT help to > >the design community (especially Verilog). > > I think that without good lint tools coding Verilog is quite > difficult. The lint tools do what VHDL compiler does during the > compilation. Human errors are just too easy to make, even the best > coder can make error at some point. Agreed :-) Regards, Srini -- Srinivasan Venkataramanan (Srini) ASIC Design Engineer, Chennai (Madras), IndiaArticle: 27956
Does anyone use this tool for simulating VHDL-stuff for a FPGA? What's your opinion? Any other suggestions? We need a tool only to simulate a VHDL-design. We already use Synplicity to synthesize. THX, JBArticle: 27957
Guido Pohl wrote: > Hello Everybody, > > I have some questions regarding external setup & hold time > considerations. > > (1) I am just reading the chapter of Xilinx' Development System > Reference Guide dealing with their TRACE tool . There I found the > following definitions of setup and hold times, respectively: > > (page 14-21) The external setup time is defined as the setup time of the > DATAPAD within an IOB relative to CLKPAD within CLKIOB. > > (page 14-22) The external hold time is defined as the hold time of the > DATAPAD within IOB relative to the CLKPAD within CLKIOB. > > The external setup and hold times are therefore given in reference to > the chip border, i.e. in reference to the input pads. It is not meant > in the definitions above that setup and hold times exclusively exist > for FFs within IOBs, i.e. only for input FFs, does it? The shortest set-up time ( at the package porder) is with respect to the IOB input flip-flop, and it is also with repect to that flip-flop that we specify the (hopefully negative) hold time. For any CLB flip-flop, the set-up time from the chip-border will inevitably be longer, and the hold time be more neagtive. > Moreover, > setup and hold times exist for buried FFs, i.e. non-input FFs, > too. The actual amount of external setup and hold times is influenced > by the placement of the FF (routing delays, internal clock skew) and > propagation delays through combinatoric logic to the FF's data input. That's right, and therefore these values have to be calculated. they cannot eb specified in the data sheet. > > > Am I completely wrong up to this point? Not really. It's all really quite straightforeward. > > > (2) Now, I have the following scenario: > > I have an upstream device that is connected to an FPGA. The spec of > the upstream device states for an output signal, say A, a minimum and > maximum propagation delay in respect to the system clock edge > tPDmin = 2 ns and tPDmax = 20 ns. > > Signal A is an input into the FPGA. For Place&Route I have given a > constraint for the PERIOD, namely 40 ns, 50 % duty cycle. Furthermore, > I gave a constraint for signal A : NET A OFFSET = IN 20 ns AFTER clk > in order to meet tPDmax, which must be taken into account for the > setup time of FFs. > > The datasheet report generated after Place&Route shows that the setup > time is met. But a hold time of about 4 ns shows up in the report. > > This hold time is a problem as far as I understand. Due to the worst > case of tPDmin the data on signal A is changed by the upstream device > already 2 ns after the clock edge. So it is important that Place&Route > keeps the hold time below tPDmin. > > So, if my train of thought is right, how can I persuade Place&Route to > keep the relation tHOLD < tPDmin in mind? Is there any constraint > construction for this purpose? > > I would be glad to have any serious comment to the stated issue. > Thanks in advance, sincerely > > Guido Your description is right. ( The duty cycle is irrelevant if all action is on the same clock edge. And set-up time, i.e. performance is no problem at all. You have at least 15 ns over.) You do have a problem with the input hold time requirement of 4 ns. It's 2 ns too long. One solution is to use a CLB flip-flop, which makes the set-up time longer ( no problem) and the hold time more towards the negative. Or you can use the input delay option. ( forgot how you specify this, it's an option Xilinx inputs have always had for the past 10 years). Peter AlfkeArticle: 27958
rob wrote: > Hi, > > I am trying to design a method of loading a number of counters with > a preset values stored in store registers. > Data is clked serially clked into a shift register on the rising edge of > the serial clk(10 MHz) whilst the en signal is low, the serial to parallel > converted data is then clked into store registers on the rising edge of the > en signal( high for min period of 50 ns) which is asynchronous to the clk > that is clking the counters .The clk to the counters can range between 10 > Mhz to 400 Mhz, the counters count down to 0 then are reloaded with a preset > value stored in the store registers. > Any ideas how I can ensure that the no problems occur whilst new data is > being loaded into the store registers and the counter is being reloaded? > > Thanks > > Rob You (should) worry about the store register changing state just as it is being used to preset the counter. Luckily, you have early warning in the counter approaching zero. I would decode this fact ( say the n-2 MSBs of the counter being zero), and use it as an inhibit for transfer of new data from the shift register into the parallel register. Peter AlfkeArticle: 27959
"Swift" <jboss@wxs.nl> writes: > Does anyone use this tool for simulating VHDL-stuff for a FPGA? What's your > opinion? Any other suggestions? We need a tool only to simulate a > VHDL-design. We already use Synplicity to synthesize. I use Active-HDL v4.1 and I find it very very good. The interface itself is beautiful, and really easy to use. I find it simulates quickly, but I don't really have another simulator to compare it against there. The help files and options that come bundled with it are really good as well. It seems to me, however, that Modelsim is the de facto standard; I haven't found that to be a problem for me (I'm not sharing designs with anyone, so . . .). HTH, KentArticle: 27960
In article <91a2q0$f7va$1@as121.tel.hr>, "Damir Danijel Zagar" <damir.zagar@tipro.hr> wrote: > I'm starting new FPGA design. In some previous projects I've used > schematic entry, but for this one I would like to dive into HDL. > My dilemma is - VERILOG or VHDL. Design is Xilinx Spartan II based. > What are advantages/disadvantages for both of them? Which one > to pick up? Thank you for all suggestions. > > Damir > > When selecting which one is "better" you should also keep in mind what your verification strategy is. I find verilog to be good for doing behavioral modeling of my test objects : processor bus models, data packet generators/monitors etc that reside in the testbench and are "wired" to the FPGA under test. These test objects have tasks that your testcase file can "call" and then your test case file make actions based on results returned from task. This allows great control over the flow of the test. Also in verilog you can place parameter specifications in your models to test setup and hold times etc... I'm not real VHDL literate but I have not seen this same testability in VHDL. Bottom line is the synthable code effort is a smaller task than the verification effort. So don't disregard language impact on your verification strategy. Bob Dittmar Sent via Deja.com http://www.deja.com/Article: 27961
In article <3A2EB079.98A36DD1@yahoo.com>, Jerry Pongstaporn <jerryp@enikia.com> wrote: > has anyone tried to implement a true dual port ram in an altera 20k > device. by true dual port, i mean you can write and read both ports. > Be aware that Xilinx does not offer "true" dual port. They offer bi-directional dual port. You still must arbitrate conflict access to same addresses. If you are doing an implementation where access conflicts can occur you need some level of arbitration even with Xilinx Virtex. So if you are not doing a real high speed design you can 2x your clock and put wrapper logic around an altera single port EAB that does cycle interleaving at 2x clock rate. Bob Dittmar Sent via Deja.com http://www.deja.com/Article: 27962
I have both modelsim and Aldec. I use the Aldec for most of my simulation, as it is considerably more user friendly. Modelsim is more or less a defacto standard, so there are clients who insist on it. For the money, you gt much more with the Aldec tool. In addition to it being a very capable simulator, it is a first class design entry tool, and it has much better error reporting than modelsim. It also has excellent on-line help for those just learning VHDL. Swift wrote: > > Does anyone use this tool for simulating VHDL-stuff for a FPGA? What's your > opinion? Any other suggestions? We need a tool only to simulate a > VHDL-design. We already use Synplicity to synthesize. > > THX, > > JB -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 27963
Distributed arithmetic will usually get you a denser design, as it makes more efficient use of the 4LUTs. Saqib wrote: > > Hi! > Which one is the best technique for implementing FIR/IIR filters in > ASICS/FPGAs ?..CSD or Distributed arithmetic?.. > > -- > --saqib yaqub-- > > Sent via Deja.com > http://www.deja.com/ -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 27964
It depends on what level you are coding at too. VHDL makes it fairly easy to embed placement (you know, RLOCs) in your code. I haven't figured out how to do that with verilog yet. Granted, I do much mure structural coding than your average bear, but the truth of the matter is that I can't do what I need to do in verilog, at least not yet. "S. Ramirez" wrote: > > Damir, > The truth to the matter is that it doesn't matter which language you go > with, unless you consider certain factors which probably don't apply to you. > At one time, I would have recommended VHDL for FPGA design. The reason > WAS that there were more tools supporting VHDL than Verilog. They were > cheaper, easier to get and relatively common. VHDL tools were cheaper > probably because the VHDL standards committee made it into IEEE standard > 1076 in 1987, while Verilog was nowhere near a standard. It was owned by > Gateway Design Automation, which was bought out by Cadence; therefore, most > designers and tools manufacturers considered Verilog as a proprietary > language. > During that time, Verilog was adopted by most of the ASIC industry in > the United States due to its fast gate level simulation, higher levels of > abstraction, introduction by Synopsis of the first Verilog synthesizer > (1988), and Cadence Verilog-XL simulator sign off certification by ASIC > vendors (1989). As you can see, many things caused Verilog to kick off in > the ASIC world in the late 1980s. So the difference between ASICs and FPGAs > back around 1990 was much more pronounced than it is today, not just in gate > count but in the tools suites. FPGAs were the cheapie versions of ASICs, > and along with them came cheapie VHDL tools. I am convinced that the IEEE > standard caused tools vendors to be more efficient and thus produce cheaper > tools. They did this, because Cadence and Synopsis had a stranglehold on > the Verilog language, and VHDL was the only other HDL that could compete > with it. > Then around 1994-1997, things started to turn around in the FPGA world. > The Verilog language was handed over to OVI (Open Verilog International), > which drastically improved the Language Reference Manual, and promoted > Verilog openly to become IEEE standard 1364 in 1995. All of this occurred > mostly due to the HDL war with VHDL. Now that it was an open language and > carried the prestigious IEEE logo, tools vendors started coming out with > Verilog versions of FPGA tools. My personal experience was that most FPGA > tools did not support Verilog until around 1996-1997. But when they did, > they came on like gangbusters. > Today engineers flame each other on which language is better. The > truth is that both languages will do the job. VHDL will do some things > better (e.g. better control of synthesis, error checking, etc.); Verilog > will do other things better (e.g. faster quicky jobs, PLI, etc.). But both > will do the job, and both are supported by most tools today. If you are an > FPGA tool vendor or plan to become one, then you'd better support both HDLs. > A decade ago, there was a true, compelling reason to go with VHDL due > to tools support for FPGAs. Today, the only compelling reason I can think > of to go with an HDL is if you plan to migrate to ASICs. If you are in the > U.S., then Verilog is the preferred ASIC HDL. If you are in Europe, then > VHDL is the preffered HDL. I don't know about the Pacific Rim -- maybe one > or some of our Pacific Rim brothers/sisters can answer that one. > I am glad that both HDLs exist. If you read the brief history given > above, one can understand that it was competition that made both languages > what they are today. Competition resulted in cheaper and better tools, > proliferation of HDL design entry, and better end results. > As an experienced VHDL and Verilog user, I will advise you to select > one of the HDLs and just start using it. If you have to switch later on, > then just do it! You'll have plenty of time to do so before you become a > power user that is stuck in one language. > Simon Ramirez, Consultant > Synchronous Design, Inc. > Oviedo, FL > > "Damir Danijel Zagar" <damir.zagar@tipro.hr> wrote in message > news:91a2q0$f7va$1@as121.tel.hr... > > I'm starting new FPGA design. In some previous projects I've used > > schematic entry, but for this one I would like to dive into HDL. > > My dilemma is - VERILOG or VHDL. Design is Xilinx Spartan II based. > > What are advantages/disadvantages for both of them? Which one > > to pick up? Thank you for all suggestions. > > > > Damir -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 27965
Peter, It isn't jsut a delay issue in all cases. I have a photograph somewhere around here of a 54LS374 output oscillating rail to rail at about 100MHz due to a metastable event. That one rang until the next clock. I've also seen mateastability cause a flip-flop's output meander about between 1/4 and 3/4 vcc for several ns before settling on high or low. Peter Alfke wrote: > > If you violate the set-up time requirement, the flip-flop will usually work > fine and respond in time with either a 1 or a 0, and you obviously don't > care which one. > Sometimes, when your D input changes right within the fractional-picosecond > window where the master latch stops looking at the D input, the flip-flop > goes metastable. That does not mean that the output goes to a half-voltage. > It means that the flip-flop has a hard time deciding what to do, and will > take a while to make up its mind. That means an output change that is later > than the specified clock-to-Q delay. For the probability of such a delay, > see teh Xilinx App Note XAPP094. > > It is "only" this timing uncertainty that is the curse of metastability. > The 1-or-0 uncertainty is obviously acceptable. > > The Florida election fiasco is a perfect example of metastability. Just > because the result was so very close, the "mechanism" (or lack thereof) > caused a >4 week delay before deciding on one of the two choices. But > let's not get into politics... > > Peter Alfke, Xilinx Applications > ============================================ > Nicolas Matringe wrote: > > > Hi > > I was thinking about setup violation in real world (not simulation). > > If the setup time is not respected, the simulation result will be an 'X' > > on the output of the FF, but in the real world, will it be "either 0 or > > 1, can't say", or can it be an intermediate, metastable value? > > As long as it's 0 or 1, I don't mind > > -- > > Nicolas MATRINGE IPricot European Headquarters > > Conception electronique 10-12 Avenue de Verdun > > Tel +33 1 46 52 53 00 F-92250 LA GARENNE-COLOMBES - FRANCE > > Fax +33 1 46 52 53 01 http://www.IPricot.com/ -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 27966
For the last 3 projects (on an Altera 7128) I tried VHDL,Verilog and AHDL. All of them ended up compiling to the same gate amount, although one AHDL design was about 10ns faster. AHDL (Altera HDL) is initially difficult to understand because of the lack of documentation and is only suited for Altera devices. Even if you can port some of it to another manufacturer's IC it would be stupid to do so. VHDL is a strict language and everything must be explicitly defined, especially data type. Try converting between integer, std_logic_vectors etc... I would say that I have a greater degree of gate count control with VHDL. Verilog I would somtimes compare to a language like Basic. The data types are easier to use and you are left with a simpler syntax to design and understand. The problem is that if you don't know what you are doing that you can easily use up most of the gates on a simple design. Both VHDL and Verilog have advantages. Quite a few of my PLD designer friends are starting to mix these two languages in their designs as the one might prove easier to implement an ALU and the other easier to implement procedures and sequential statements. Remember, PLD tool suppliers are also looking at implementing some sort of a C compiler for FPGAs. That will be the source of more confusion for years to come. Victor "Jason A. Daughenbaugh" <jad_NOSPAM@aedinc.net> wrote in message news:ee6f057.0@WebX.sUN8CHnE... > When we asked this same question about 2 years ago, and our Xilinx FAE told us to go with Verilog. So all of my experience since then has been with verilog. My guess is that eveyone would respond that whatever hdl they use is best, and like them, I cannot give a very objective opinion. I can supply a couple of observations. One is that Verilog is much more dense - If you look at a Xilinx app note that supplies example code in VHDL and Verilog, it always seems that the VHDL is 4x as long. Not that this is necessarily a bad thing... You might want to take a look at one of these and see which you find more readable. > Also, a big advantage to us has been that all of our clients use Verilog - in fact I have not yet come in contact with anyone who uses VHDL, but again, this is just me. I do know that much of the world's ASIC design is done in verilog. > I once heard that the difference is like the programming languages C and ADA. They both can get the job done. C is quicker to code, but easier to shoot yourself in the foot. ADA has a lot of conventions to prevent this (resulting in longer listings). > > Your Xilinx FAE might be a good person to ask. > > Jason Daughenbaugh > http://www.aedinc.netArticle: 27967
Dear all, I'm developing a PCI card with Xilinx's XC9572 on board and I have a problem. I would like to use PCI bus to program XC9572 via JTAG interface. This solution would allow me to program the card without opening computer case and in the future remotely with a use of a modem. Is it possible to handle JTAG protocol with 4-bit IO port (I have such a port and I would like to connect it to JTAG)? Can I connect it directly or should I use any glue logic? Where can I find JTAG protocol? More: to allow our service people to update XC9572's configuration at customer site I need to have a configuration file for CPLD and a simple downloader. It must fit on a 3,5" diskette. Some kind of batch - "run & forget". In this case let's assume that downloading will be done via standard Xilinx's parallel cable. Is there any kind of such a downloader? Which file is a configuration file for XC9572? Note: I'm a beginner in CPLD's. Best regards DanielArticle: 27968
AFAIK the metastability parameters for Virtex/E devices aren't published I'm wondering what sort of rule to use as a derate for synchroniser FFs. Up to now I've just been applying a fractional multiplier to the clock period in the synchroniser FF timespecs. Since the only one I've come across in the ASIC world is the one where you multiply the unloaded delay by some factor, say N, I'd like to try using that. Although its not clear whether or not the data book Tco(max) for IOB/CLB FFs has any allowance for trace loading its the only thing I've got so I'll have to use that. The question is: On a paranoia scale from blase -> men-in-white-coats what value of N to choose ? Are there any better metastab rules ? Peter A - any comments ? I seem to remember you saying on this NG some while back that the problem with Virtexes is that metastab events are so rare that the figures are hard to measure. This would imply a small N say 3-4. Note that for N = 4 & VirtexE-6 @100MHz this implies derating the clock period to 7nsec i.e. as a fraction, equivalent to multiplying by 0.7 whereas up to now my metastab multiplier has been 0.25 for fast clocks and 0.33 for slow ones.Article: 27969
"Martin.J Thompson" wrote: > > Nial wrote: > > >Note that the Altera tool set is only $2K and for that you get a version of > >Modelsim which isn't limited to any size of design (and is 50% quicker than > >Modelsim XE) and FPGA Express or Exemplar Spectrum with Quartus and Maxplus2 > >which between them allow any Altera device to be targeted. > > > >It also _isn't_ time base licensed, after a year you don't get any more > >free tool updates or suport but all tools (including third party) will > >continue to work and new designs can be started. > > > > The Modelsim and Exemplar licenses *are* time based, at least according to my > license file. When I queried our supplier about this, apparantly Mentor wanted > it this way. :-( > The other licenses are, as you say, just limited in how long you can have updates > for - which seems fair. > > Cheers, > Martin I've been assured by an Altera FAE that all tools will be fully operational at the end of the year. It's partly on this understanding that I've just ordered the tools. Can you apply for another license file for Modelsim/Exemplar at the end of the first year with your current license number? Nial.Article: 27970
Hi Rob, You could implement the store registers on the counter clock. You could sample the en signal on the counter clock and load the new value from the shift register when you see a rising edge on en. This requires a 2 state FSM. Regards, Martin Heimlicher, Supercomputing Systems AG, Switzerland "rob" <rob4@xyz123abc.com> wrote in message news:<91gtko$g7l$1@neptunium.btinternet.com>... > Hi, > > I am trying to design a method of loading a number of counters with > a preset values stored in store registers. > Data is clked serially clked into a shift register on the rising edge of > the serial clk(10 MHz) whilst the en signal is low, the serial to parallel > converted data is then clked into store registers on the rising edge of the > en signal( high for min period of 50 ns) which is asynchronous to the clk > that is clking the counters .The clk to the counters can range between 10 > Mhz to 400 Mhz, the counters count down to 0 then are reloaded with a preset > value stored in the store registers. > Any ideas how I can ensure that the no problems occur whilst new data is > being loaded into the store registers and the counter is being reloaded? > > Thanks > > Rob > >Article: 27971
Thanks, I've got it. The reason is that there always is a low glitch on /PROG pin, sometime even a 100MHz logic analyser can not capture it. if I disconnect it from the board, everything works fine. the solution in Answer Database 6545 does not help. I think Xilinx must have recognized this problem, why it still exist? How do they think about it?Article: 27972
Hi, I am looking for an encoder/decoder pair to transmit serial data through long distances. There will be one emitter and many receivers, and the system cannot accept more than one nanosecond of jitter among receivers, that is there can be absolute delay differences from one receiver's decoder output to another's, but those differences have to be stable to within one ns. On the other hand, I would not like to buy a commercial pair of encoder/decoder but rather design my own with an FPGA (I might have to give support for many years). I assume that to get that kind of accuracy, I will have to use either an on-chip or an on-board PLL/DLL. Does someone know where I can get schematics or text-based designs for simple encoders like Manchester or biphase mark? Any good books or URLs on the subject? Thank you very much. JavierArticle: 27973
bobdittmar@my-deja.com wrote: > > These test objects have tasks that your testcase file can "call" and > then your test case file make actions based on results returned > from task. This allows great control over the flow of the test. You can do that in VHDL. Parameters in procedures, for example. > Also in verilog you can place parameter specifications in your > models to test setup and hold times etc... You can use generics. I do. > I'm not real VHDL literate but I have not seen this same testability > in VHDL. It's there, and arguably better, IMHO. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 27974
Jerry wrote: > Thanks, I've got it. The reason is > that there always is a low glitch > on /PROG pin, sometime even a 100MHz > logic analyser can not capture it. > if I disconnect it from the board, > everything works fine. the solution > in Answer Database 6545 does not > help. I think Xilinx must have recognized this problem, why it still exist? How do they think about > it? 7 CCLKs is about the time the device starts up & starts driving its outputs. Have you looked for the possibility that one of the device's outputs enables a high speed buffer whose inputs are floating ? Or a whole lot of buffers suddenly turn on together. This could easily pump noise into the /PROG pin which has only a weak pull-up.
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