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
> That explains it! Going in the right direction apparently. :-) That > said, > I'll also start off with the Windoze version, and see where that goes. > The only thing here, if you're not already aware of it, is that the full-fat Linux -SE version is many $$$ more expensive than the -PE. In UK terms we paid ~ £4500 for the PE edition and to upgrade to the -SE Linux would cost another £14000 ! (wishing & hoping) Maybe ModelTech/Mentor will come out with a -PE on Linux. Just one note of gloom. There's a thread on CAF sometime back where ``Rickman'' was saying that he experienced the -PE edition crashing fairly frequently IIRC he was claiming something pretty bad like one time in 4 or 5. BUT, again IIRC, he was doing his sims in the ``compile & simulate'' mode whereas I've always compiled the source files into separate libraries - design code, my testbench models, Vendor libs, etc. - and then run vsim with a bunch of `-L' flags to pull in the pre-compiled code at run time. Also: There are two irritations with ModelSim & maybe you could join my one man campaign to persuade ModelTech to eliminate them :-) 1. If ModelSim cannot find a way to satisfy an instantiation there's no way to send a Ctrl-C to the console to stop vsim. If the missing entry is used several thousand times in a post-synth or post-route simulation, all you see is a never ending stream of error messages. The best thing I can do is kill ModelSim completely & start again. 2. If there's a port mis-match where an instantiation has more ports then the module definition ModelSim doesn't tell you the name of the ``extra'' port in the error message. Sometimes needs a binary chop to find the error. That said I'm still using 5.4c (no real reason to upgrade to 5.5+ yet) so they might have been fixed.Article: 37976
Thank you for your follow-up! The modified design (according to your tips and hours of experiments) now works in the silicon. However, I do not (yet) have the feeling that it works "by design" rather than for being lucky. > What synthesis tool are you using?? And are you simulating? Burn-and-crash debugging is little more than a time-waster, especially when you are new to a design tool. I use Atmel System Designer 2.1 which comes with Leonardo Spectrum (Atmel OEM) and Atmel IDS Figaro place & route. The simulator is from Modeltech. I'm not simulating because I'm not a friend of simulators and because it is not easy to get the FPGA and microcontroller to simulate both at the same time (the FPSLIC contains an AT40K FPGA and an AT90 AVR microcontroller). However, after reading your follow-up I modeled the microcontroller read/write accesses separately and simulated the FPGA alone. It worked fine, even before applying the changes that finally made it work in the silicon. I see an inherent problem of simulators in the fact that they are based on interpreters. For example: If the compiler doesn't generate the error that you expected after reading my source, the simulator probably won't generate it either. The simulation does not bring this problem to the light. > 3) If you're looking for the edge of a non-clock signal, you'll need to > write edge-detector code. You might think that rising_edge() and > falling_edge() do that, but you'd be wrong. And it's not obvious. I don't understand this comment. Isn't rising_edge() exactly for this purpose? I do understand that the signal must be on the sensitivity list for it to work. > > sh0 : PROCESS (XTAL,shift,val_in) > > What's happening here is that you're trying to build a shift register > out of purely combinatorial logic. You have XTAL (assuming that's your > clock) on the sensitivity list, yet you don't use it in the process. > Oversight? Again, the only thing you want in the sensitivity list for > your flops are the clock and reset. You should read your synth tool's > manual. It is meant to be purely combinatorial. I added XTAL for testing, because the design didn't work as expected, and later forgot to remove it. I expected the combinatorial logic to settle after 5*X ns, where X is in the range of 10ns or so. The microcontroller has a cycle time of >50ns and I can specify to insert a NOP instruction before reading back the result. However, I do not want to specify 32 NOPs to rotate the value bit by bit with every XTAL cycle. (the design is intended to speed up RC5 encryption where 32-bit ADD, XOR and ROTATE are used as mathematical primitives). Two general questions: Is there any way to control the compiler output? With ANSI-C I can look at the assembler output to verify that it is correct, and to learn how to write efficient ANSI-C code. Can I look at the output of a VHDL compiler? I used ABEL-HDL earlier with Lattice Synario and there it was possible to view the final logic equations that are burned into the GAL. Is this possible with Atmel System Designer, too? And, can you recommend a good book about VHDL? I have plenty of formal language spec documents but still haven't found a book that shows how to do real world designs with tips that come from experience rather than theory. MarcArticle: 37977
To carry forward this spirit of honesty, let me clarify point #4. While VirtexE did require the external resistor network for LVDS outputs, Virtex2 does not. The external termination resistor for the LVDS receiver input is required in both cases. R "Stuart Moses" <mostuus@yahoo.com> wrote in message news:99d0603.0112271646.78c1888b@posting.google.com... > FYI, > > Th Xilinx FAE who blasted Altera's Mercury CDR later realized his > mistake and apologized, but with a new posting, not as a response to > any posting in this thread. See below: > > "I am sorry to have made a basic mistake, and I apologize if I have > mislead > anybody. The question was about Mercury, and I answered it as if it > were about > APEX-II." > > ==================================================== > > So for the real scoop: > > 1. Mercury CDR DOES NOT require a training pattern. This is a true > Clock-Data recovery circuit. > > 2. At 1.25Gbps the clock granularity is 14 ps, not the ridiculous > 300ps Peter claims. > > 3. As for driver power consumption, Altera's Quartus provides a > simulation-based power estimator. Try it youself & see the output > power consumption for 1 bit at 1.25Gbps LVDS. > > Note: While APEX and Mercury provide true LVDS drivers and receivers, > Xilinx uses an external resistor network (in addition to the > termination resistor) to generate LVDS levels and a voltage-referenced > input with the LVDS -channel tied to the reference pin for receivers.Article: 37978
"Stuart Moses" <mostuus@yahoo.com> schrieb im Newsbeitrag news:99d0603.0112271555.2803a21d@posting.google.com... > > Virtex-E is faster (and cheaper). > > Virtex-II is even more faster. > > Have you looked at Altera's Mercury devices? They're an all-copper No. > performance-optimized architecture. Altera claims ~40% performance > increase over Virtex-II and 150MHz non-pipelined 16x16 multipliers. I ;-))) Reading the datasheets is not enought. Its a nice new marketing word, all-copper-performance-optimized-architecture. WOW. > think the largest part in this family is slightly smaller than the > XCV1000, but would be worth looking at. Sure, the Altera parts are also worth looking at (no kidding here). But its more or less useless just to compare datasheets. -- MfG FalkArticle: 37979
Rick Filipkiewicz <rick@algor.co.uk> wrote in message > Just one note of gloom. There's a thread on CAF sometime back where ``Rickman'' > was saying that he experienced the -PE edition crashing fairly frequently IIRC he > was claiming something pretty bad like one time in 4 or 5. BUT, again IIRC, he > was doing his sims in the ``compile & simulate'' mode whereas I've always > compiled the source files into separate libraries - design code, my testbench > models, Vendor libs, etc. - and then run vsim with a bunch of `-L' flags to pull > I had some crashes when I upgraded to PE v5.5a. From what I've been able to gather, there was a memory leak in v5.5a, and it was fixed in v5.5b. I have not really had a crash since. It was interesting that you mentioned that development is done in a Linux environment. The Modelsim editor on NT feels like an X-Window. The Modelsim editor is kindof weak, and I only use it if I have to, like setting breakpoints, and to quickly goto errors identified in the transcript window. I likewise agree with you on your port mismatch complaint. I cringe when I see that error/warning at load time, cause I know it will be tedious to track down. But overall, Modelsim allows me to quickly identify problems in my code, and correct the problems. NewmanArticle: 37980
jetmarc wrote: > Thank you for your follow-up! > > The modified design (according to your tips and hours of experiments) > now works in the silicon. However, I do not (yet) have the feeling that > it works "by design" rather than for being lucky. That's one Very Good Reason for simulating -- and verifying -- your design. > >>What synthesis tool are you using?? And are you simulating? Burn-and-crash debugging is little more than a time-waster, especially when you are new to a design tool. >> > > I use Atmel System Designer 2.1 which comes with Leonardo Spectrum > (Atmel OEM) and Atmel IDS Figaro place & route. The simulator is from > Modeltech. I'm not simulating because I'm not a friend of simulators > and because it is not easy to get the FPGA and microcontroller to > simulate both at the same time (the FPSLIC contains an AT40K FPGA and > an AT90 AVR microcontroller). I strongly encourage you to be a friend of simulators. Your problem of connecting the microcontroller to the FPGA is a common one. In the "it would be really nice" category, it would be really nice if Atmel (or any other microcontroller/microprocessor/DSP/PCI-interface/etc chip vendor) would provide bus-functionals model of their chips. I mean, I've written maybe a dozen of these sorts of models. From your FPGA's point of view, all you care about are transactions on the processor's bus. The op-codes the processor is executing don't matter. [From a system simulation point of view, it's way cool indeed to have the micro fetch, decode and execute instructions, which maybe results in a bus transaction, which your FPGA deals with. However, that's a lot of work -- which you may need to do.] > However, after reading your follow-up I modeled the microcontroller > read/write accesses separately and simulated the FPGA alone. Ah -- very good. That's exactly the point I make above. > It worked > fine, even before applying the changes that finally made it work in the > silicon. > > I see an inherent problem of simulators in the fact that they are based > on interpreters. For example: If the compiler doesn't generate the > error that you expected after reading my source, the simulator probably > won't generate it either. The simulation does not bring this problem > to the light. The problem here is that HDLs (much the same way that C or whatever) let you write code that is sytactically correct (in other words, it'll compile) but functionally wrong. A further problem is that when writing code that'll be implemented in a chip, you have to restrict yourself to a "synthesizable subset" of the language. This is where your synth tool's reference and user manuals are valuable: they'll tell you what sort of code -- or template -- to write to get a specific sort of logic. >>3) If you're looking for the edge of a non-clock signal, you'll need to >>write edge-detector code. You might think that rising_edge() and >>falling_edge() do that, but you'd be wrong. And it's not obvious. > I don't understand this comment. Isn't rising_edge() exactly for this > purpose? I do understand that the signal must be on the sensitivity > list for it to work. For simulation purposes, rising_edge(foo) and falling_edge(bar) indeed trigger when the signal foo or bar rise or fall. Foo and bar can be any signal at all. However, in the synthesis world -- the real world of actual hardware -- rising_edge() and falling_edge() are part of the template that tells the synth "edge-triggered flip flop." In this case, foo and bar must be clock signals. (They could be global clocks, or clocks divided down, or even the combinatorial function of two or more signals. This last type is the so-called "gated clock," which you don't want to even consider using, especially in an FPGA, unless you really know what you are doing, and even then, you don't want to use them.) It looks as if you wanted to use XTAL as a clock in your original code. Your synth manual will tell you what the code for a flip-flop should look like. >>> sh0 : PROCESS (XTAL,shift,val_in) >>> >>What's happening here is that you're trying to build a shift register >>out of purely combinatorial logic. You have XTAL (assuming that's your >>clock) on the sensitivity list, yet you don't use it in the process. >>Oversight? Again, the only thing you want in the sensitivity list for >>your flops are the clock and reset. You should read your synth tool's >>manual. >> > > It is meant to be purely combinatorial. I added XTAL for testing, > because the design didn't work as expected, and later forgot to remove > it. Why a combinatorial shift register? You DO have a clock available? > I expected the combinatorial logic to settle after 5*X ns, where X is > in the range of 10ns or so. The microcontroller has a cycle time of >>50ns and I can specify to insert a NOP instruction before reading back > the result. However, I do not want to specify 32 NOPs to rotate the > value bit by bit with every XTAL cycle. (the design is intended to > speed up RC5 encryption where 32-bit ADD, XOR and ROTATE are used as > mathematical primitives). You may want to read up on static timing analysis. You don't want to hope and pray that your logic settles in time. Sounds like your particular problem needs to be pipelined. > Two general questions: > > Is there any way to control the compiler output? With ANSI-C I can look > at the assembler output to verify that it is correct, and to learn how > to write efficient ANSI-C code. There are various compiler pragmas that control how logic is created and optimized. All of these are compiler-specific, so crack open the book. > Can I look at the output of a VHDL > compiler? There should be a compiler option (either from command-line or in the GUI) to turn on the logic-equation output report. >I used ABEL-HDL earlier with Lattice Synario and there it > was possible to view the final logic equations that are burned into > the GAL. Is this possible with Atmel System Designer, too? You may want to read that manual, too, as I've never used Atmel parts. > And, can you recommend a good book about VHDL? I have plenty of formal > language spec documents but still haven't found a book that shows how > to do real world designs with tips that come from experience rather than > theory. Bhasker's synthesis book is very good for its discussion of synthesizable coding techniques. Ashenden's book is very good for an overall user's guide to VHDL, but it's not syhnthesis-specific. Bergeron's "Writing Test Benches" is excellent if you are trying to learn how to test and verify your code. --aArticle: 37981
Hi Rob, You can use FPGA Editor to do this. Here are the steps: 1) open design in FED 2) change edit mode to read-write 3) find the block ram in question and double-click on it to bring into view 4) click the "begin editing" button (looks like a little pencil writing on paper) 5) click "attributes" button (looks like F=) 6) fill in the particular "Init" values that you want to take place 7) click the "apply" button (looks like a down arrow) 8) close the RAM window 9) save the .ncd file 10) rerun bitgen on new .ncd file (you can do this from FED's Probes menu or by running command line) Bam! you've changed the initialization values for your block RAM without ever thinking of running PAR. Hope that helps. Cheers, Ryan Laity Xilinx Applications Rob Finch wrote: >How do I set block ram contents without going through the PAR process ? Can >someone point me to more info ? > >Thanks >Rob > > >Article: 37982
Rob, As of 4.1i, XST no longer produces an edif netlist. Since you don't get Express with Webpack, you can't get an edif from Webpack 4.1i. However, you can still download Webpack 3.1 WP8 from the web site (same place, just change the pulldown menu) from which you can get an edif netlist. That's the only supported way to go at this point. Sorry for the inconvenience, I'm told that the optimization that comes from the elimination of the netlist is a huge advantage that XST now has. Happy new year, Ryan Rob Finch wrote: >How do I generate a .edn file in Webpack ? > >Thanks >Rob > > >Article: 37983
I want to use LUTs as 16x1 RAM, but the data sheet isn't clear about writing to the LUT. Does input data show up on the output as long as the write strobe is active, or only after the trailing edge? My application would use 8 CLBs to store an array of 16 16-bit counters. A counter would be incremented by selecting it and clocking the LUT's write line. The output would be routed back to the input through a +1 adder. -- Brad EckertArticle: 37984
1) Is FPGA editor available as a free tool ? 2) Actually I should have given more detail what I'm trying to do. I generate code from an assembler that's then run through a little utility to create a series of "INIT_xx=" attributes. Is it possible to script the update so that I don't have to key anything ? I think I have seen posted before that it's possible to modify the bitstream (using a program) to do this. I'd like to automate the whole thing if possible. (My coding skills are expert C/C++ preferred and I'm not afraid to hack things as long as I have the info..). Rob "Ryan Laity" <laity@xilinx.com> wrote in message news:3C2CD90F.1010708@xilinx.com... > Hi Rob, > You can use FPGA Editor to do this. > Here are the steps: > 1) open design in FED > 2) change edit mode to read-write > 3) find the block ram in question and double-click on it to bring into view > 4) click the "begin editing" button (looks like a little pencil writing > on paper) > 5) click "attributes" button (looks like F=) > 6) fill in the particular "Init" values that you want to take place > 7) click the "apply" button (looks like a down arrow) > 8) close the RAM window > 9) save the .ncd file > 10) rerun bitgen on new .ncd file (you can do this from FED's Probes > menu or by running command line) > > Bam! you've changed the initialization values for your block RAM without > ever thinking of running PAR. Hope that helps. > > Cheers, > > Ryan Laity > Xilinx Applications > > Rob Finch wrote: > > >How do I set block ram contents without going through the PAR process ? Can > >someone point me to more info ? > > > >Thanks > >Rob > > > > > > >Article: 37985
can some body help me understand what an instruction processor is? thanks for your reply newbieArticle: 37986
"Brad Eckert" <brad@tinyboot.com> wrote in message
news:4da09e32.0112281339.5bcddebc@posting.google.com...
> I want to use LUTs as 16x1 RAM, but the data sheet isn't clear about
> writing to the LUT. Does input data show up on the output as long as
> the write strobe is active, or only after the trailing edge?
>
> My application would use 8 CLBs to store an array of 16 16-bit
> counters. A counter would be incremented by selecting it and clocking
> the LUT's write line. The output would be routed back to the input
> through a +1 adder.
>
> --
> Brad Eckert
Brad,
Look at the following link, which is the Spartan XL data sheet, page
13, Distributed RAM. Now I am assuming that you really mean a Spartan XL,
not a Spartan II, because they work differently.
http://support.xilinx.com/partinfo/ds060.pdf
The Spartan XL has edge triggered synchronous RAM implemented in its
CLB LUTs. The section called Memory Configuration Overview says that for
both single-port and dual-port (my favorite!), write operations are
synchronous (edge-triggered), while read operations are asynchronous. This
means that as soon as a write occurs on the edge, the data can be seen at
the output port after a delay t-sub_WOS or t-sub-WODS, assuming that the
read address is the same as the write address. The two delays above are for
single-port and dual-port (my favorite!), respectively, and are depicted on
page 57. The actual values are given in the table preceding the timing
diagrams.
If you read the data sheets enough, you will eventually find everything
you need. It is rare to have to go to Xilinx on something missing in the
data sheets, and even then, they have a great deal of literature that is
searchable at:
http://support.xilinx.com
Good luck with your application and use of Xilinx FPGAs.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
Article: 37987Ryan Laity wrote: > Rob, > As of 4.1i, XST no longer produces an edif netlist. Since you don't > get Express with Webpack, you can't get an edif from Webpack 4.1i. > However, you can still download Webpack 3.1 WP8 from the web site (same > place, just change the pulldown menu) from which you can get an edif > netlist. That's the only supported way to go at this point. Sorry for > the inconvenience, I'm told that the optimization that comes from the > elimination of the netlist is a huge advantage that XST now has. > > Happy new year, > > Ryan I'm really not ready to buy the ``huge advantage ...''. Running edif2ngd to create a .ngo file from a .edf takes hardly any time at all.Article: 37988
Hi Brad, Simon has pointed you to the info that I think you need, and I will just add a few comments of my own. 1) LUT RAM reads are asynchronous. There is just a delay from stable address to valid data out. This is identical to when the LUT is being used as a ROM or for gates (assumng no writes are occuring). 2) In the Spartan parts (and Spartan XL, Spartan-II, Virtex, and Virtex-2, and Virtex-II-Pro, and 4000E, 4000EX, 4000XL, 4000XV) the LUT RAMs ALL work the same way. (Simon indicated that Spartan-XL and Spartan-II are different, but this is not true for LUT RAMs). Assuming you have selected the default rising edge clock mode for the LUT RAM, the write occurs immediately after the rising edge of the clock, assuming the WE is asserted. I.E. fully synchronous, just like a flip-flop. The output of the LUT RAM continues to follow the address, so when you do a write, and just hold the address stable, you will see the new data just written, a short async time after the write's rising clock edge. If WE is not asserted, then data is not written, and the old data will continue to be on the output. 3) You can think of the WE signal as a RAM equiv of the CE for the flipflops. On Sat, 29 Dec 2001 01:14:10 GMT, SIMON wrote: > >"Brad Eckert" <brad@tinyboot.com> wrote in message >news:4da09e32.0112281339.5bcddebc@posting.google.com... >> I want to use LUTs as 16x1 RAM, but the data sheet isn't clear about >> writing to the LUT. Does input data show up on the output as long as >> the write strobe is active, or only after the trailing edge? See above: Output tracks address, write occurs on rising edge. >> My application would use 8 CLBs to store an array of 16 16-bit >> counters. A counter would be incremented by selecting it and clocking >> the LUT's write line. The output would be routed back to the input >> through a +1 adder. This can be an extremely efficient structure. Because the write occurs on a clock edge, you can use the edge to also change the address to the next counter to be incremented. It goes something like this: The address is held in a register (ADDR), clocked on rising edge. On a rising edge of clock, the ADDR is updated to a new value, and the WE (also in a reg) is asserted (may have already been asserted, if we have back to back increments of either the same or different counters). Since the address has changed, the LUT output will be the current value in that location. This goes through your +1 circuit (incrementor) and its output goes to the LUT RAM data input. On the following rising clock edge, the D input has the new counter value, the address ADDR is still pointing at the location we want to increment, and WE is asserted. A new address is waiting on the input of ADDR. On the rising edge, we write the updated value to the LUT RAM, and the ADDR changes to the new value, and we fetch the current value of the counter at address ADDR. Philip Freidin >> >> -- >> Brad Eckert > >Brad, > Look at the following link, which is the Spartan XL data sheet, page >13, Distributed RAM. Now I am assuming that you really mean a Spartan XL, >not a Spartan II, because they work differently. > > http://support.xilinx.com/partinfo/ds060.pdf > > The Spartan XL has edge triggered synchronous RAM implemented in its >CLB LUTs. The section called Memory Configuration Overview says that for >both single-port and dual-port (my favorite!), write operations are >synchronous (edge-triggered), while read operations are asynchronous. This >means that as soon as a write occurs on the edge, the data can be seen at >the output port after a delay t-sub_WOS or t-sub-WODS, assuming that the >read address is the same as the write address. The two delays above are for >single-port and dual-port (my favorite!), respectively, and are depicted on >page 57. The actual values are given in the table preceding the timing >diagrams. > If you read the data sheets enough, you will eventually find everything >you need. It is rare to have to go to Xilinx on something missing in the >data sheets, and even then, they have a great deal of literature that is >searchable at: > > http://support.xilinx.com > > Good luck with your application and use of Xilinx FPGAs. >Simon Ramirez, Consultant >Synchronous Design, Inc. >Oviedo, FL USA > Philip Freidin FliptronicsArticle: 37989
XESS is the best as far as support and finished designs go, but it is rather pricey for what you want (Ethernet/USB) etc. As a matter of fact they killed their Virtex line that comes with lotsa interfaces integrated, a while back but are now bringing it back by popular demand. I personally got a Digilab 2 (in stock, a family-ran shop ... very personal :) and their IO board (LCD/7seg/keyboard), for something like $150 . It also has integrated PS2/VGA, Serial and parallel ports. I wanted to get Burch's design, but couldnt wait for them to deliver the superpack (sorry Tony :) Almost all designs work with Xilinx Webpack and it's bigger brother, ISE and include parallel cable so you don't need anything extra to get you going. Some only give you JTAG pins, so you need to buy/build your own Xilinx III cable ( $5 worth of parts @ your local RatShack). Memec has a really interesting offer(take a look @ Xilinx eval kits on their Website): ~$500 for Virtex II 1M gate setup, with 32Mb DDRAM. They also offer expansion cards ... including one with Ethernet/USB etc ,not sure about the price. You might quickly discover that Spartan IIs, even 200K gates ones, put you just under needed capacity for complex designs, CPUs etc, so ... if you wait a month or two, Spartan IIs with 300K gates will become available. Or you might want to spring to something like the VII from Memec. All the cards come with expansion sockets, that route out as many of the pins as possible. Connectors range from .100mil DIPs to impossible-to-find-high-density ones. Good cards also expose some essential pins for LA/scope connection. Some give you tiny breadboard area. Some cards provide you with a bank of pre-set refrence voltages, so you can route them to Vcco pins to support various signalling standards, while other wire all the Vcco to 3.3v. In any way, XESS is the site to go for tutorials and some easy (and not so easy) designs, if you are just starting. Xilinx has a wealth of info on their site.Article: 37990
Andy Hall wrote: ...snip... > I have what > appears to be an attractive offer from Model Tech, but only good till > the end of the quarter, and for other reasons I need to make a > decision this week. ... snip > Andy Hall > andy at gordian dot com > Gordian I did not even get all the way through your message before I felt compelled to respond. You should NEVER let a salesman rush you into a decision to buy a product. That is a common technique to keep you from making an informed decision. I expect that all of the tool vendors are competing very heavily for sales to new customers, trying to lure away the customers of their competitors. I find it hard to believe that if you don't make a decision until January that they will not cut you a deal of some kind. In fact, deadlines are often their way of saying, "we want you to buy this package deal now because the price will be better in a month and we want to close the deal before we drop the price". Everyone is getting hungry these days. Use time to your advantage. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 37991
Rick Filipkiewicz wrote: > > > That explains it! Going in the right direction apparently. :-) That > > said, > > I'll also start off with the Windoze version, and see where that goes. > > > > The only thing here, if you're not already aware of it, is that the full-fat > Linux -SE version is many $$$ more expensive than the -PE. In UK terms we paid ~ > £4500 for the PE edition and to upgrade to the -SE Linux would cost another > £14000 ! > > (wishing & hoping) Maybe ModelTech/Mentor will come out with a -PE on Linux. > > Just one note of gloom. There's a thread on CAF sometime back where ``Rickman'' > was saying that he experienced the -PE edition crashing fairly frequently IIRC he > was claiming something pretty bad like one time in 4 or 5. BUT, again IIRC, he > was doing his sims in the ``compile & simulate'' mode whereas I've always > compiled the source files into separate libraries - design code, my testbench > models, Vendor libs, etc. - and then run vsim with a bunch of `-L' flags to pull > in the pre-compiled code at run time. My problem surfaced when I reloaded simulations from scratch repeatedly without restarting Modelsim. Because there was no way to position and size the windows on startup and I found it irritating to have to save the waveform setups just because I added a couple of signals, I would just reload the simulation and keep using my current window setups. After 5 or so reloads Modelsim would crap out under NT. It never crashed the machine, so it could be restarted. But it took a couple of minutes to get everything organized again so I could see what I was looking for. This was reported to Mentor, so it may be fixed by now. > Also: There are two irritations with ModelSim & maybe you could join my one man > campaign to persuade ModelTech to eliminate them :-) > > 1. If ModelSim cannot find a way to satisfy an instantiation there's no way to > send a Ctrl-C to the console to stop vsim. If the missing entry is used several > thousand times in a post-synth or post-route simulation, all you see is a never > ending stream of error messages. The best thing I can do is kill ModelSim > completely & start again. I agree that is was annoying. I don't remember it often being a problem though. > 2. If there's a port mis-match where an instantiation has more ports then the > module definition ModelSim doesn't tell you the name of the ``extra'' port in the > error message. Sometimes needs a binary chop to find the error. I found this very annoying. I don't think we had to do the "binary chop" but it can be a PITA to search and compare two long signal name lists when the names change as they pass through your heirarchy. This was modifications of OPC (Other People's Code). -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 37992
i am using xilinx foundation series . For some unknown reason i cant view the PROJECT MANAGER FLOWCHART . Hence i have to use the menu bar . When i work on some other Pc i found that when i simulate using the FLOWCHART icon i can access all the signals in the list . and when i use the simulate option of the menu bar i cant... kindly help me frenyArticle: 37993
Thanks! input data:2bit parallel i want to make 32-bit CRC according to IEEE802.3 Can you tell me?Article: 37994
Yesterday I got my small NIOS board functional. When I started out I wanted to achieve a few things: -Replace my 8051 (big board,large RAM/ROM) designs. -Have something that can be upgraded. -Have some useable tools. I am not trying to plug an ad. for Altera but I am impressed. My entire PCB is 120mm by 90mm, 32 bit NIOS, 64 I/Os, 6 serial ports (if I simplify the UARTs), RTC , 256K RAM, 1Meg FLASH. I can configure from a single EPC1 or 2 or from flash, although I think the EPC1 is eventually cheaper/cost effective and safer (if you consider that you might wipe your CPU design configuration from flash). You still need to apply external power and MAX232. I wrote a small program to test memory copy to a port (at clk=20MHz). At this speed, with a serializer, I will be able to transmit about 73megabits per second. This small PCB is magnitudes faster than the 8051 (at whatever speed you can buy .e.g. Dallas has produced a 50MIPS device). If Altera discontinues the 20K100 (device that I am using at the moment) I can easily migrate to other packages(The drawback is that you can only use it with Altera devices (legally)). The tools are easy to use and free (GNU C/C++). Plus, looking at NIOS ver2 more features can be packed into the FPGA. Plus,plus... you don't need a killer heatsink and fan, everything runs pretty cool. Cost and effort wise it might not be an option for many people to develop your own PCB. The development kit is $995. The components are hard to find in small quantities and believe me it takes a bit more effort to get it going than a simple 8051 design. I think Altera can supply more of the kit's populated PCBs but these cost about $600 to $700 (correct me if I am wrong). Now a plug for my business. I am using NIOS for my access control systems and vehicle management systems. I am also situated in South Africa and for those who watch the money markets you will notice that the South Africa Rand is about 11 to 1 to the US dollar, which means we are dirt cheap. I can supply small quantity populated PCBs, tested with all the software you need for less than $300. I am also planning an ACEX1k100 NIOS which in large quantities will be lots cheaper. My PCB is not production ready yet but email me (zerksus@mweb.co.za) is you have any questions. Question: Does anybody know if MicroBlaze is a reality or not. For the last year I have been reading specs of how much better and cheaper it is than NIOS but nobody wants to sell anything to me. I always get responses that it will be available later this year (Ray, any response ?) Victor Zerksus Engineering "Stuart Moses" <mostuus@yahoo.com> wrote in message news:99d0603.0112271625.5b56fdd1@posting.google.com... > The biggest criteria is performance. What performance do you need? > A soft-core processor implemented in programmable logic will be slower > than a hard-core processor. There are several soft-cores available on > the market, some of these are synthesizable Verilog and VHDL verions > of 6502, 8051, etc. or architecture-specific soft-cores such as > Altera's Nios. If you are replacing a 68000 micro in you system, a > Nios will have more horsepower than you would need. > > Hard-Core processors in FPGAs include Altera's ARM9 implementation > (@200MHz) and Triscend's ARM7 (@50MHz.) In this case, the Altera and > Triscend implementations have hard-wired processor bus interfaces, > guaranteeing fast external memory bus speeds & allowing the processor > to power-up and operate before the FPGA is configured (this allows the > processor to configure the device.) Xilinx had announced something in > a hard-core processor, but I don't believe they're shipping these > parts. > > Another important criteria is the S/W development tools and OS support > (if you require an OS.) Make certain that there are compilers and > debug tools available. On an ARM or MIPs, OS and tools support will > not be a problem at all. The Nios includes S/W tools and a debugger > and has two RTOSes and a Linux port. > > Hope this helps.Article: 37995
"David G." <dgeerinck@yahoo.com> wrote in message news:<3c27e328$0$10318$ba620e4c@news.skynet.be>... > Hi, > I saw this year some basics of vhdl at school. > I'm now looking for some kind of FPGA-starterkit who allows me > to experiment on simple I/O like leds, LCD screens, com-ports, > RAM, ETHERNET,etc that are accesible through a simple electronic board. > > I heard of a Xilinx starterkit but found it a bit expesive > for the pour student I am :-( > > > Thanks. > > David. With the emphasis on *simple* you may find the hardware that accompanies my text book Combinational and Sequential Logic of interest. If you are poor you can just buy the pcb and chip, or set of parts, or you can buy built and tested. The chip is a small CPLD rather than FPGA, but you get input switches, clock, output LEDs and seven-segment displays, and 11-way jumper connector to go off the board. Book takes you through standard digital electronics stuff up to design of synchronous and asynchronous state machines, but with emphasis on programmable logic. Comes with Webpack and lots of examples. See www.Booksites.co.uk/rice Best wishes, MartinArticle: 37996
"Philip Freidin" <philip@fliptronics.com> wrote in message
news:17hq2ug88cr6onmsofav2cpmlqp6kahd7b@4ax.com...
> 2) In the Spartan parts (and Spartan XL, Spartan-II, Virtex,
> and Virtex-2, and Virtex-II-Pro, and 4000E, 4000EX, 4000XL, 4000XV)
> the LUT RAMs ALL work the same way. (Simon indicated that
> Spartan-XL and Spartan-II are different, but this is not true for
> LUT RAMs).
> Philip Freidin
> Fliptronics
Phil,
Thanks for the clarifications. I went back to the Spartan II databook
and reread the section on CLBs, and you are correct! Previously I was
reading in a hurry and confused the operation of the LUT RAMs with the
storage elements, i.e., the flip flops, and thought they were edge triggered
AND level sensitive. Thanks for setting me straight!
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
Article: 37997I know that it must be an easy question, but I can't find the answer - it is not published in the Help. Seems that some loop should be added to max2plus PLL megafunction to implement the F*N multiplier. Any comments are welcome, I am the beginner. Thanks!Article: 37998
Philip Freidin wrote:
> Hi Brad,
>
> Simon has pointed you to the info that I think you need, and I will
> just add a few comments of my own.
>
> 1) LUT RAM reads are asynchronous. There is just a delay from
> stable address to valid data out. This is identical to when
> the LUT is being used as a ROM or for gates (assumng no writes
> are occuring).
>
> 2) In the Spartan parts (and Spartan XL, Spartan-II, Virtex,
> and Virtex-2, and Virtex-II-Pro, and 4000E, 4000EX, 4000XL, 4000XV)
> the LUT RAMs ALL work the same way. (Simon indicated that
> Spartan-XL and Spartan-II are different, but this is not true for
> LUT RAMs).
>
> Assuming you have selected the default rising edge clock
> mode for the LUT RAM, the write occurs immediately after the
> rising edge of the clock, assuming the WE is asserted. I.E.
> fully synchronous, just like a flip-flop. The output of the
> LUT RAM continues to follow the address, so when you do a
> write, and just hold the address stable, you will see the new
> data just written, a short async time after the write's rising
> clock edge. If WE is not asserted, then data is not written, and
> the old data will continue to be on the output.
>
> 3) You can think of the WE signal as a RAM equiv of the CE for the
> flipflops.
>
Just to add, expanding on Simon's ``my favourite'' (my feeling as well) dual port
comment.
For the DP variants there are
o Separate read & write addresses.
o Two read data ports. One of them outputs the data pointed to by the read
address and so does not track new data as its written. The other outputs data
pointed to by the write address and so tracks in the same way the SP LUT RAM
does.
o 2 LUTs per DP RAM bit.
These are synthesisable, at least if you are using a decent synth tool, and so
give a nice way to make parametrisable MxN memories. The Verilog template goes
like this (assuming you don't need the ``write tracking'' read data port):
reg [N-1:0] ram [M-1:0];
always @(posedge ram_clk)
if (ram_write_en)
ram[ram_write_addr] <= data_in;
assign data_out = ram[ram_read_addr];
If you need the other read port as well then, for Synplify at least, this works:
assign other_data_out = ram[ram_write_addr];
Article: 37999"Rob Finch" <robfinch@sympatico.ca> writes: > 1) Is FPGA editor available as a free tool ? No. :-(
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