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
Hi Pete... How does Jbits help one get better Altera designs? Eric Pearson "Peter Sommerfeld" <petersommerfeld@hotmail.com> wrote in message news:5c4d983.0302081113.48392c92@posting.google.com... > Is there anything equivalent to JBits for Altera devices? I'm dearly hoping so ...Article: 52451
Kevin Becker wrote: > > Hi, > > I'm looking for a table that lists the typical delays (or maximum > clock frequencies) of often-used structures in FPGAs. It should look > about like this: > > 8 to 1 MUX / Virtex-II (speed 5): XX ns > 16 bit Adder / Spartan-II (speed 4): XX ns > 24 bit Adder / Virtex-II (speed 4): XX ns > 24 bit par. multiplier / VirtexE (speed 5): XX ns > > Of course, I could describe everything, synthesize it and look at the > reports. But isn't there somebody who has done that before (Xilinx > maybe?) The reason is that I am building a design, and I am not sure > if I should use for example a parallel 24bit Adder or rather split > this up into 2 clock cycles for speed reasons. I have not much > experience, but it would be a lot of work to try every possible > implementation by myself... is there such a table somewhere? > > Thanks! > Kevin Dear Kevin, There is not so much work to try to synthesize these combinations and go thru the tools (MAP,PAR) and see what you get, it very unlikely that somebody has run these combinations (design/architecture/speed-grade) and store them somewhere (If I had them somewhere probably it will take more time to find them instead of re-run them) You can try coregen if you don't like coding in HDL (or you don't want spend time coding) put some constraints, implement the cores, and see what is coming out. You were saying that you don't have experience, after you try'll these combinations you'll have more... BTW: SpartanII is only -5 and -6 Aurash -- __ / /\/\ Aurelian Lazarut \ \ / System Verification Engineer / / \ Xilinx Ireland \_\/\/ phone: 353 01 4032639 fax: 353 01 4640324Article: 52452
Petter, Windrvr is a multilinx driver. It's been known to cause a conflict with Win2K sp3. Your library file does sound corrupted somehow and the reinstall must have fixed it as you indicated. ISE 5.1i has a good version of the Windrvr file in case you wish to upgrade the software. Regards, Wei Petter Gustad wrote: > Petter Gustad <newsmailcomp4@gustad.com> writes: > > > The patch worked. I was able to boot my system after I installed ISE > > 4.2. I then installed ISE 4.2 SP3. Whenever I try to start any of the > > programs I get a message saying something like: > > > > The procedure entry point > > ?printMsg@Port_MsgManDefault@@UAXW4MsgType@Port_MsgMan@@PBGHPBD2H2@Z > > could not be located in the dynamic link library libPortability.dll > > I repeated the install of ISE 4.2 and downloaded SP3 again. Then I > installed on top of the old version (replying no to overwrite of > windrvr) and my installation seem to work!? Could be that my previous > version of ISE4.2-SP3 was corrupted somehow. > > BTW, what is windrvr? Is this where the device driver for the download > cables reside? IIRC I got into the same endless boot loop when I > selected no for both the parallel cable and the MultiLinx cable. > > Petter > -- > ________________________________________________________________________ > Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petterArticle: 52453
Lijo asked: "Hi, Can anyone tell me what is sysnthesis scripts?" A synthesis script is a file containing the commands used to compile your file(s) and possibly some other operations (such as deleting temporary files). If you are familiar with make files, they are similar. "And why is it necessary?" They are not necessary, they are just for convenience by making easier the synthesis process for a design.Article: 52454
Hello all,
thanks a lot for your answers! You are a great help!
Best Regards,
Harris
"Florian-Wolfgang Stock" <f.stock@tu-bs.de> wrote in message
news:b20u0e$nq$05$1@news.t-online.com...
> Steve Lass <lass@xilinx.com> writes:
>
> > Harris,
> >
> > There is a Xilinx program called DATA2BRAM that allows you to change
> > the block RAM initialization in the bitstream. It was designed for
updating
> > the object code of embedded processors without having to rerun place and
> > route, but can be used for any block RAM.
>
> Another possibility is to use jbits. Its a ten-liner in java to modify
> the BRAM, and if the value are somehow calculated, you can easily do
> this in java too (So you can put the calculation of the values and the
> modification of the bitstream into one programm).
>
> Florian
> --
> int m,u,e=0;float l,_,I;main(){for(;1840-e;putchar((++e>907&&942>e?61-m:u)
> ["\t#*fg-pa.vwCh`lwp-e+#h`lwP##mbjqloE"]^3))for(u=_=l=0;79-(m=e%80)&&
> I*l+_*_<6&&26-++u;_=2*l*_+e/80*.09-1,l=I)I=l*l-_*_-2+m/27.;}
Article: 52455Dear Alan, The main thing is to implement an FFT that just does what you require. I know of one customer that implemented an FFT that had a transform time of 10ns - Yes I mean that! The whole transform in 10ns is seriously fast but it comes at a price as it requires a lot of silicon and a lot of I/O! For most applications, the transform time doesn't need to be anywhere near as fast as 10ns. So start with some simple calculations. 1024 points requires 20480 multiplication's using a simple radix-2 architecture. How fast do you want to clock your design? Let's just say 100MHz for now and get some estimates... 1 multiplier = Transform time of 204.8us 2 multipliers = Transform time of 102.4us 4 multipliers = Transform time of 51.2us 8 multipliers = Transform time of 25.6us 16 multipliers = Transform time of 12.8us 32 multipliers = Transform time of 6.4us If we look at the Virtex-II devices, then the XC2V40 (smallest) has 4 multipliers and the XC2V1000 has 40 multipliers. But simply having more multipliers to do the 'work' doesn't solve the problem. You have to organise the memory in such a way that you can feed all those compute engines with data. At the same time you need to be collecting the next set of samples. This type of study is covered in the DSP Techniques Course which I wrote for Xilinx. Find out when it is running near you and I hope you find it useful. Here's the pointer to the course description (note the section at the end of day 3). http://support.xilinx.com/support/training/abstracts/v4/atp-dsp.htm You may find it useful to consider alternative approaches to transforms such as the work by RF Engines. http://www.rfel.com/ Hope this is useful and you get the opportunity to attend the course. Yours sincerely, Ken ChapmanArticle: 52456
Hi All Thank you for your replies. Much appreciated Alan "Britta Fuhrmann" <britta.fuhrmann@polar-design.de> wrote in message news:3E4924DB.5AC59DA2@polar-design.de... > Hi, > > Ken is correct in what he writes. In particular, the organisation of the > memory is the important issue to analyze. I've designed a FFT that does not > use any "RAM" at all - at least not in the classical way. The system > required a pretty fast FFT (256 ns), which didn't allow the data to be > written and read to and from a RAM in the given time. The system is > described in the article at http://www.polar-design.de/dsp.html (sorry, no > english version available today, only german - but the drawings should > explain the concept). > > I would recommend to study the application you want to implement in some > detail and maybe even try a couple of implementations to figure out which > one best suits your requirements (I usually do it on paper, but that's just > my way to work these things out ;-)). In the above mentioned FFT I had to > analyze each stage of the FFT to see which strategy of building multipliers > and storing the results fits best. > > It takes some time upfront, but this is easily paid for at the end, because > you know exactly how to build your design. > > Good luck, > Britta Fuhrmann > > > > Ken Chapman wrote: > > > Dear Alan, > > > > The main thing is to implement an FFT that just does what you require. I > > know of one customer that implemented an FFT that had a transform time > > of 10ns - Yes I mean that! The whole transform in 10ns is seriously fast > > but it comes at a price as it requires a lot of silicon and a lot of > > I/O! > > > > For most applications, the transform time doesn't need to be anywhere > > near as fast as 10ns. So start with some simple calculations. 1024 > > points requires 20480 multiplication's using a simple radix-2 > > architecture. How fast do you want to clock your design? Let's just say > > 100MHz for now and get some estimates... > > > > 1 multiplier = Transform time of 204.8us > > 2 multipliers = Transform time of 102.4us > > 4 multipliers = Transform time of 51.2us > > 8 multipliers = Transform time of 25.6us > > 16 multipliers = Transform time of 12.8us > > 32 multipliers = Transform time of 6.4us > > > > If we look at the Virtex-II devices, then the XC2V40 (smallest) has 4 > > multipliers and the XC2V1000 has 40 multipliers. > > > > But simply having more multipliers to do the 'work' doesn't solve the > > problem. You have to organise the memory in such a way that you can feed > > all those compute engines with data. At the same time you need to be > > collecting the next set of samples. > > > > This type of study is covered in the DSP Techniques Course which I wrote > > for Xilinx. Find out when it is running near you and I hope you find it > > useful. Here's the pointer to the course description (note the section > > at the end of day 3). > > > > http://support.xilinx.com/support/training/abstracts/v4/atp-dsp.htm > > > > You may find it useful to consider alternative approaches to transforms > > such as the work by RF Engines. > > > > http://www.rfel.com/ > > > > Hope this is useful and you get the opportunity to attend the course. > > > > Yours sincerely, > > > > Ken Chapman >Article: 52457
Nicholas C. Weaver wrote: > In article <b235lh$n01$03$1@news.t-online.com>, > Florian-Wolfgang Stock <f.stock@tu-bs.de> wrote: >>S. Trimberger, D. Carberry, A. Johnson, J. Wong: A time-multiplexed >>FPGA. In "Proceedings of IEEE Workshop on FPGAs for Custom Computing >>Machines" (April 1997), pp. 22-28 > > This one, a Xilinx design for a multicontext XC4000, was basically > killed as a potential product because context switching draws a LOT of > power, especially in all the interconnect bits, and they envisionsed > multicontext being used to virtualize larger circuits. Do you have any idea, why some multi-context devices are seem to consume a lot of power when context switching? Any idea how the power dissipation related to context switching relates to the power consumed by a 'typical' user application? I understand that a context switch can potentially cause a lot of elements to switch at once, but also a user application might generate quit a lot of signal toggling. Regrads, Christian -- Christian Plessl <plessl@tik.ee.ethz.ch> Computer Engineering and Networks Lab, ETH Zurich, SwitzerlandArticle: 52458
In article <3e47e49e@pfaff.ethz.ch>, Christian Plessl <plessl@tik.ee.ethz.ch> wrote: >> This one, a Xilinx design for a multicontext XC4000, was basically >> killed as a potential product because context switching draws a LOT of >> power, especially in all the interconnect bits, and they envisionsed >> multicontext being used to virtualize larger circuits. > >Do you have any idea, why some multi-context devices are seem to consume a >lot of power when context switching? It depends really on how many interconnect points and logic changes. If you JUST context switch the data, or if the amount of points which change in a context switch is low, the power consumption isn't bad. The other factor is how quickly things change. The Xilinx one had to support single-cycle changes over the entire design, including all interconnect, which meant a lot of bits changing every clock cycle, as it was designed to virtualize larger designs. >Any idea how the power dissipation related to context switching relates to >the power consumed by a 'typical' user application? I understand that a >context switch can potentially cause a lot of elements to switch at once, >but also a user application might generate quit a lot of signal toggling. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 52459
In addtion to Paul's comments read below. This basically defines the important characteristics of the digital designs such as clock, reset, multi-cycle paths, false-paths, timing and area constraints, etc. Basically with this script you can tell the synthesis engine to create the hardware you want from the HDL description. Kumaran Colin Paul Gloster wrote: > Lijo asked: > "Hi, > Can anyone tell me what is sysnthesis scripts?" > > A synthesis script is a file containing the commands used to > compile your file(s) and possibly some other operations (such as deleting > temporary files). If you are familiar with make files, they are similar. > > "And why is it necessary?" > > They are not necessary, they are just for convenience by making easier the > synthesis process for a design. >Article: 52460
Hi Giuseppe, thank you for the hint. I used my JTAG cable all the day with your modification and it really worked fine. I think that was the problem, thank you very much! Greetings MarkusArticle: 52461
Roger wrote:
> As described in an earlier posting to the group I'm having a weird problem
> with the Quartus simulator (when it doesn't hang up) so I've looked at the
> ModelSim tool for the first time that ships with Quartus. I'm not really
> sure what it does that the Quartus simulator should do. What extra
> functionality does it have?
Modelsim allows you to test your source code before synthesis,
and it allows you to apply stimulus algorithmically.
The Quartus simulator requires a synthesized design as a starting point,
and requires a vector stream for stimulus.
> Also do the input signals need to be defined
> using "force" commands
You can use force commands or a testbench
program written in VHDL or Verilog.
> or can it read .vwf files from Quartus or is there
> some other graphical way to achieve the same thing?
Many vhdl text editors can write the testbench
framework for you. The only graphical part of modelsim is
the simulation waveforms.
> I've not been able to run ModelSim from Quartus for some unknown reason. I
> would have thought that installing from the CDs would have performed all the
> configuration required to allow the two packages to run but it seems not. I
> get a couple of messages in Quartus that say the VHDL failed to compile
> (ModelSim) and something about vcom failing (is this the compiler again?).
It's better to run modelsim by itself until you've debugged your code.
This is where you will spend most of your time.
-- Mike Treseler
Article: 52462Hi Skillie, In the ASIC flow (from your mail I guess you are talking about an FPGA flow) there is an element of timing analysis while synthesis in progress. The synthesis tool uses the timing requirements (alternatively called constraints) that you specify along with design rules that are inherent within the technology library. From a personal point of I tend to be pessimistic when I set up my constraints, for example setting the clock to be a bit faster than is required (yes I know the guys at Cadence say you just need to use the exact timing but why not give yourself some headroom ?) and also put a little bit of uncertainty in there as well (ie make the synthesis tool worry about the clock arriving a little bit ahead or behind). Some of the posters here have mentioned wire load models, some tools make this selection automatically but you can force a tool to use a larger one. It's interesting that some layout groups no longer expect gate lists to have hold time violations already fixed and advise that they will fix them in the layout. Personally I rather like to see some form of hold violation fixing done up ahead, even if you provide a net list without the fixes its good to look at the worst violators (remembering to ensure the conditions are set to absolute best). All the best Andre' "Skillwood" <skillwoodNOSPAM@hotmail.com> wrote in message news:b1fj7l$12qoi7$1@ID-159866.news.dfncis.de... > Hi, > Can Anyone tell me why static timing analysis is done after synthesis and > implementation ? > > Regards, > Skillie > >Article: 52463
Hi Lijo, Scripts are very important for several reasons. Almost every synthesis tool will have the ability to read in a file which contains a sequence of commnds instructing the tool how to synthersize a design. The command set will include instructions of how to read in files, set timing/area etc constraints on the design, how to synthesize it and how to dump out the resulting design. There is a 'generic' format for commands called TCL (Tool Command Language, pronounced Tickle) that aids the transfer of scripts from one tool to another, AMBIT from Cadence uses it and I now believe Synopsis does also. I'm not too sure if the FPGA tools use TCL specifically but there will be similar commands in their instruction set. As to why we use scripts, the first is that for a complex design there will be a few test runs on the synthesis, working out various problems. What then happens is that an engineer 'learns' the various problems associated with synthesizing the design he/she is working on. Now if the engineer decided to constantly use the GUI interface there is going to be something that will be forgotten.It can take all weekend for a synthersis to run and to come in on Monday morning (possibly hungover) to discover that you had forgotten to set something up is AMAZINGLY frustrating ! So a script is written so that you don't forget to do something. Another reason for writing a script is for repeatability, if you need to rerun a synthesis for what ever reason you just call it up and you will know that everything is done correctly. And the most important reason for writing a script is that it becomes part of the project documentation that is as important as the RTL you have designed. You comment the script liberally so that when somebody else comes along to change something they can see WHY you have done things that way. There you go, just my two penneth worth :-) Best Regards Andre' Powell "Lijo" <lijo_eceNOSPAM@hotmail.com> wrote in message news:b27nto$19hq6h$1@ID-159866.news.dfncis.de... > Hi, > Can anyone tell me what is sysnthesis scripts? > And why is it necessary? > > Thanks > Lijo > >Article: 52464
Nicholas C. Weaver wrote: > In article <3e47e49e@pfaff.ethz.ch>, > Christian Plessl <plessl@tik.ee.ethz.ch> wrote: >>> This one, a Xilinx design for a multicontext XC4000, was basically >>> killed as a potential product because context switching draws a LOT of >>> power, especially in all the interconnect bits, and they envisionsed >>> multicontext being used to virtualize larger circuits. >> >>Do you have any idea, why some multi-context devices are seem to consume a >>lot of power when context switching? > > It depends really on how many interconnect points and logic changes. > If you JUST context switch the data, or if the amount of points which > change in a context switch is low, the power consumption isn't bad. > > The other factor is how quickly things change. The Xilinx one had to > support single-cycle changes over the entire design, including all > interconnect, which meant a lot of bits changing every clock cycle, as > it was designed to virtualize larger designs. Interessting point! Do you know any paper, where power issues in multi-context FPGAs have been discussed? The argument that multi-context FPGAs may consume excessive power comes up frequently, but I've never seen any figures and analysis. In particular, I would be interessted in knowing the reason for this excesive power consumption: - Is it the transients occuring in all routing resources, when the flip-flops driving these routes change state? - Or is it the capacitive load of the context selection bus, that needs to be routed to every configuration memory. As the configuration memory is presumable distributed and not just on central block, the context selection bus, would be a high-fanout net, which might be a problem, when it toggles at every clock cycle. Best regards, Christian -- Christian Plessl <plessl@tik.ee.ethz.ch> Computer Engineering and Networks Lab (TIK), ETH Zurich, SwitzerlandArticle: 52465
In article <3e48198a$0$33245$fb624d75@newsspool.solnet.ch>, Christian Plessl <plessl@tik.ee.ethz.ch> wrote: >Interessting point! Do you know any paper, where power issues in >multi-context FPGAs have been discussed? The argument that multi-context >FPGAs may consume excessive power comes up frequently, but I've never seen >any figures and analysis. Not that I know of. >In particular, I would be interessted in knowing the reason for this >excesive power consumption: > - Is it the transients occuring in all routing resources, when the >flip-flops driving these routes change state? > - Or is it the capacitive load of the context selection bus, that needs to >be routed to every configuration memory. As the configuration memory is >presumable distributed and not just on central block, the context selection >bus, would be a high-fanout net, which might be a problem, when it toggles >at every clock cycle. Don't know. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 52466
Chen Wei Tseng wrote: > Petter, > > If you have Win2K sp3, then please take a look at the link below. > > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=15380 > > Regards, Wei > > Petter Gustad wrote: > > >>I've tried a couple times to install Xilinx ISE 4.2i on a fresh >>Windows 2000 installation and it causes the PC to restart on next >>reboot when connecting to the network. >> >>If I don't install ISE 4.2i the PC is working fine. I used it for a >>couple weeks and then I tried to install ISE 4.2i again and the >>machine just went into an endless boot loop... >> >>Have anybody else experienced this problem? >> yeh, I had the same problem, I generally don't like to change things like that in the middle of a project but I work for big company and when the IT guys think a update is safe and important enough (in this case w2k-sp3) they just push it to all PC's the SW guys weren't to impressed either when a known build started to produce a (slightly) different binary ... -LasseArticle: 52467
Hello all, I'm looking for someone who has capabilities to make our custom desingn (don't need any pre fabbed parts, just to be VirtexE 2000 equivalent as gates count an block ram's) fast using solutions like RapidChip from LSI to meet our time-to-market requirements. After that we'll need the same chip as standard cell ASIC. Can you guys provide me with more informations about the players in this market? TanksArticle: 52468
Working with the Spartan-IIE and similar devices, the ENA and WE setup times for the BlockRAMs are greater than the address and data setup times. To get high write speeds into these devices, the (write) enables must always active. It's been suggested in the past that using a trash location for those cycles when writes shouldn't happen to the rest of the BlockRAM is a good compromise allowing the highest performance. I'm wondering: would there be any problems if - rather than using a trash location - the last address and data were just kept? The .CEs on the CLB registers that feed the BlockRAM are easily manipulated. Would I give myself any problems? My gut says it's fine but I worry that the logic that bypasses the portA .D input to the portB .Q output when the two port addresses match might get confused either by the nature of the bypass logic or - more probable - if the load address and data change away from the common value on the high speed write port around the clock edge of the lower speed read port. Any thoughts or experiences would be appreciated. - John_HArticle: 52469
That works just fine as long as you don't mind overwriting the data at the
current address with garbage. In FIFOs and other similar buffers this is rarely
a problem. In random access buffers, you might need valid data present at all
normal write locations at all times, in which case you will need to either use
the enable ( :-( ) or you'll have to substitute an address where it is
acceptable to push the garbage.
John_H wrote:
> Working with the Spartan-IIE and similar devices, the ENA and WE setup times
> for the BlockRAMs are greater than the address and data setup times. To get
> high write speeds into these devices, the (write) enables must always
> active.
>
> It's been suggested in the past that using a trash location for those cycles
> when writes shouldn't happen to the rest of the BlockRAM is a good
> compromise allowing the highest performance.
>
> I'm wondering: would there be any problems if - rather than using a trash
> location - the last address and data were just kept? The .CEs on the CLB
> registers that feed the BlockRAM are easily manipulated. Would I give
> myself any problems?
>
> My gut says it's fine but I worry that the logic that bypasses the portA .D
> input to the portB .Q output when the two port addresses match might get
> confused either by the nature of the bypass logic or - more probable - if
> the load address and data change away from the common value on the high
> speed write port around the clock edge of the lower speed read port.
>
> Any thoughts or experiences would be appreciated.
> - John_H
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 52470nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote in message news:<b28oob$hph$1@agate.berkeley.edu>... > In article <3e47e49e@pfaff.ethz.ch>, > Christian Plessl <plessl@tik.ee.ethz.ch> wrote: > >> This one, a Xilinx design for a multicontext XC4000, was basically > >> killed as a potential product because context switching draws a LOT of > >> power, especially in all the interconnect bits, and they envisionsed > >> multicontext being used to virtualize larger circuits. > > > >Do you have any idea, why some multi-context devices are seem to consume a > >lot of power when context switching? > > It depends really on how many interconnect points and logic changes. > If you JUST context switch the data, or if the amount of points which > change in a context switch is low, the power consumption isn't bad. > > The other factor is how quickly things change. The Xilinx one had to > support single-cycle changes over the entire design, including all > interconnect, which meant a lot of bits changing every clock cycle, as > it was designed to virtualize larger designs. > > >Any idea how the power dissipation related to context switching relates to > >the power consumed by a 'typical' user application? I understand that a > >context switch can potentially cause a lot of elements to switch at once, > >but also a user application might generate quit a lot of signal toggling. Certainly a single cycle change would have given a large power spike that might have been difficult to cope with. If I were paying for (or even designing in) this feature I could live with a few clock cycles to bank change say 16 clocks to serially rewrite each LUT. Such a LUT serial swap out would also be alot easier on the Si area budget than par swap. The alternative though is to use a N x bigger array, now a rare dynamic power event is replaced by a large increase in constant leakage of silent logic as well as uneven power distribution. In any case for such an expensive part you really want a certain percentage of the nodes to be switching all the time relative to static leakage, but not too much. John JaksonArticle: 52471
In article <adb3971c.0302101830.2a79a036@posting.google.com>, john jakson <johnjakson@yahoo.com> wrote: >Certainly a single cycle change would have given a large power spike >that might have been difficult to cope with. If I were paying for (or >even designing in) this feature I could live with a few clock cycles >to bank change say 16 clocks to serially rewrite each LUT. Such a LUT >serial swap out would also be alot easier on the Si area budget than >par swap. The Xilinx one was killed not because of the power cost of A context switch, but that it was designed to context switch every cycle. As such, it would overheat a plastic package. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 52472
Yes, I know what you mean and although you can move the label around, the pin stays on the side. Annoying. It's interesting that you use VHDL and graphical entry. This is the way I do designs as I like a graphical top level although I think it's not the done thing anymore (for some reason). I'm glad your Quartus hangs up now and again as well. It's obviously not my fault! Maybe later versions will improve its reliability. I'm having problems with simulation. Which simulator do you use? Rog. "Ruth" <ruthsims@hotmail.com> wrote in message news:ff5ada4a.0302060845.bb262bc@posting.google.com... > Hi, > > After creating a symbol from a piece of vhdl in Quartus, in the block > symbol editor, how can you move a port that appears on one side of the > block symbol to the other side? I only seem to be able to move/drag > the port vertically, it won't let me drag it around the edges of the > block to the other side or top of the block? > > Thanks > > RuthArticle: 52473
So basically the only way of graphically describing input waveforms for a simulation is via the Quartus simulator?! Rog. "Roger" <rogerwilson@hotmail.com> wrote in message news:VLJ1a.174$YF2.23664@newsfep1-win.server.ntli.net... > As described in an earlier posting to the group I'm having a weird problem > with the Quartus simulator (when it doesn't hang up) so I've looked at the > ModelSim tool for the first time that ships with Quartus. I'm not really > sure what it does that the Quartus simulator should do. What extra > functionality does it have? Also do the input signals need to be defined > using "force" commands or can it read .vwf files from Quartus or is there > some other graphical way to achieve the same thing? > > I've not been able to run ModelSim from Quartus for some unknown reason. I > would have thought that installing from the CDs would have performed all the > configuration required to allow the two packages to run but it seems not. I > get a couple of messages in Quartus that say the VHDL failed to compile > (ModelSim) and something about vcom failing (is this the compiler again?). > > If anyone can shed any light on what's going on, I'd be grateful. > > Thanks. > > Rog. > >Article: 52474
Ray Andraka <ray@andraka.com> wrote in message news:3E486125.AC4E29E3@andraka.com... > That works just fine as long as you don't mind overwriting the data at the > current address with garbage. In FIFOs and other similar buffers this is rarely > a problem. In random access buffers, you might need valid data present at all > normal write locations at all times, in which case you will need to either use > the enable ( :-( ) or you'll have to substitute an address where it is > acceptable to push the garbage. Ray, You could also push the enabling back one level to a set of registers which would store the last valid address/data combination. Nial. ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design www.nialstewartdevelopments.co.uk
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