Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Sep 13, 3:03=A0pm, Jon Elson <jmel...@wustl.edu> wrote: > rickman wrote: > > > If you build the Parllel Cable III into your product, what will you > > connect it to? =A0I don't think they have built a PC with a parallel po= rt > > in a number of years and my understanding is that the drivers for USB > > parallel ports don't work properly with bit banging software like this. > > =A0 Am I mistaken? =A0Is this a workable solution? > > I have no idea about the USB-parport, but you CAN get computers with real > parallel ports, just not on laptops. =A0I use the parallel port for lots > of interconnect projects, and the Intel D525 chipset still has parport > support, if the motherboard maker chooses to bring it out. =A0For this > reason, we use a lot of Intel D525 (Atom) motherboards in projects. > > Jon Yeah, sadly for us we have no control at all over what computers people use, so we can't rely on parallel ports... Thanks!Article: 154251
On Sep 10, 2:07=A0am, Simon <goo...@gornall.net> wrote: > I think you're in luck... > > I was browsing around earlier today trying to figure out if I could do re= altime video-rate JPEG encoding on a DSP instead of having to code it up in= verilog, and ran across this... > > =A0http://www.nuhorizons.com/development/board.asp?product=3DLattice-ICE4= 0... > > For $20, you get: > > =A0- 4 capacitive buttons. I guess you still have to 'debounce' capacitiv= e buttons... > =A0- 63 i/o on breadboard-friendly 0.1" headers. You'll have to supply th= e headers. > =A0- can power off the USB > =A0- has ~1K logic cells (lut+flip-flop) > =A0- comes with USB cable & software can be downloaded. > > Assuming you can solder some headers onto the board, switches can be repl= aced by jumpers, and 63 i/o is actually really generous at this sort of lev= el. Most of the entry-level boards are seriously miserly in comparison. > > On the downside, you'd probably not get much of a bulk discount - I'm gue= ssing they're already cut to the bone at this price... > > Just FYI - not a recommendation since I've never used Lattice before, but= thought you'd be interested. > > Simon That is _really_ close to what we are looking for, just the headers as switches thing doesn't quite work. And I'd really like a bit more output LEDs. But very encouraging that what we want is possible, thanks so much for the pointer! MarkArticle: 154252
On 16/09/2012 16:53, Mark Brehob wrote: > On Sep 10, 2:07 am, Simon <goo...@gornall.net> wrote: >> I think you're in luck... >> >> I was browsing around earlier today trying to figure out if I could do realtime video-rate JPEG encoding on a DSP instead of having to code it up in verilog, and ran across this... >> >> http://www.nuhorizons.com/development/board.asp?product=Lattice-ICE40... >> >> For $20, you get: >> >> - 4 capacitive buttons. I guess you still have to 'debounce' capacitive buttons... >> - 63 i/o on breadboard-friendly 0.1" headers. You'll have to supply the headers. >> - can power off the USB >> - has ~1K logic cells (lut+flip-flop) >> - comes with USB cable & software can be downloaded. >> >> Assuming you can solder some headers onto the board, switches can be replaced by jumpers, and 63 i/o is actually really generous at this sort of level. Most of the entry-level boards are seriously miserly in comparison. >> >> On the downside, you'd probably not get much of a bulk discount - I'm guessing they're already cut to the bone at this price... >> >> Just FYI - not a recommendation since I've never used Lattice before, but thought you'd be interested. >> >> Simon > > That is _really_ close to what we are looking for, just the headers as > switches thing doesn't quite work. And I'd really like a bit more > output LEDs. But very encouraging that what we want is possible, > thanks so much for the pointer! > > Mark Mark - you asked earlier about Lattice Diamond software. I've used Lattice parts a lot for the last 5 years and Diamond since it came out. It works fine, not perfect, and nothing like as many whizzo features as the Xilinx stuff but it's cheap and it doesn't crash (at least for me.) I would much rather work with Lattice parts than X or A, it's all well short of the bleeding edge and for just getting the job done at a reasonable cost it's fine. Michael KellettArticle: 154253
Mark Brehob wrote: > > Humm, it's sounding like Lattice is going to be the way to go unless I > can get support from Altera or Xilinx (something I'll pursue if this > gets out of the "idea" stage). > > Has anyone worked with Lattice Diamond? How does it compare to the > software from Xilinx and Altera? I've been burned by some "bad" FPGA > software in the past (not horrible, just too steep of a learning curve > for the classroom) and would _really_ like the ability to do schematic > capture in addition to Verilog... > > Thanks again to everyone for their responses, this has been really > useful! > Mark Hello, Tried to use Lattice software for several years now. It never worked. At first it did not work, because my windows installation was too old, and they did not have a linux install. I gave it a try at my brother's laptop, which was a bit more recent software-wise. Unfortunately their license is locked to the boxes' MAC address, so I had to wait for a year, to be able to apply for a new one. On that box it did not work either... unsure why. Recent versions of lattice diamond are available for linux, so I gave it a try again. Synplify(the synthesis tool) failed with a SIGILL. It turns out it requires a SSE2 box. Synplify is a synthesis tool, that is included in diamond. For some parts it is the only practical choice... It is produced by 'synopsys', and they do not mention any instruction set requirements on their website... http://www.synopsys.com/Tools/Implementation/FPGAImplementation/FPGASynthesis/Pages/FPGAPlatformSupport.aspx#requirements The other synthesis tools supported are: Precision: 3rd party (`mentor graphics`), not included, MachXO2 not supported. Lattice LSE: Lattice Synthesis Engine, included. Available only with MachXO, MachXO2, and Platform Manager. I did not try those, as they don't support LatticeXP parts... they _probably_ work. All in all, things have improved. It might work on your common, everyday box.. if it isn't too old. regards, JKArticle: 154254
Hello, I'd like to announce the new release of OpenTech Package 1.9.0, the first a= nd the largest Open source EDA tools and open source hardware designs distr= ibution package. OpenTech is the first and largest world wide package of free open source ha= rdware designs, EDA software and Books for electronics designs. Since 2000 = we have sold OpenTech packages to Students, Professors, Engineers, Startup = and even large corporations. In OpenTech package you will find many things = that you can not imagine they even exist as open source. You will find CPUs= , Ethernet, USB and others. VHDL, Verilog, Schematic, IC and board layout = and many many other software programs. In short you will find lot of inform= ation that helps you in designing your system or testing it. The package is= composed of 5 DVDs that costs only 90 Euros. Use free open source tools an= d designs in OpenTech package and save more than $500,000 and more than 3 m= onths of search and download time. This release is the 16th release since the start of OpenTech in 2000 and contains=20 - More than 16 GB of information distributed=20 - More than 380 Electronics related software - More than 85 Hardware designs - More than 670 Ope Cores - More than 15 free books & tutorials -=20 Since 2000 more than 660 shipped CDROMs/Packages all over the world. This package is composed of 5 DVDs (Tools, Designs, Open Cores, and Books) = and it features EDAutils (www.edautils.com) which supports the development = and integration of SoC We offer new service, we can help you in finding free designs or tools by p= osting your requests to khatib@opencores.org and we will share the informat= ion on our facebook page Best regards, Jamil Khatib OpenTech maintainer http://opentech.handasarabia.org http://opencores.org/project,opentech http://www.facebook.com/OpenTechPackageArticle: 154255
On 9/17/2012 12:43 AM, Johann Klammer wrote: > Mark Brehob wrote: >> >> Humm, it's sounding like Lattice is going to be the way to go unless I >> can get support from Altera or Xilinx (something I'll pursue if this >> gets out of the "idea" stage). >> >> Has anyone worked with Lattice Diamond? How does it compare to the >> software from Xilinx and Altera? I've been burned by some "bad" FPGA >> software in the past (not horrible, just too steep of a learning curve >> for the classroom) and would _really_ like the ability to do schematic >> capture in addition to Verilog... >> >> Thanks again to everyone for their responses, this has been really >> useful! >> Mark > Hello, > > Tried to use Lattice software for several years now. It never worked. At > first it did not work, because my windows installation was too old, and > they did not have a linux install. I gave it a try at my brother's > laptop, which was a bit more recent software-wise. Unfortunately their > license is locked to the boxes' MAC address, so I had to wait for a > year, to be able to apply for a new one. On that box it did not work > either... unsure why. > Recent versions of lattice diamond are available for linux, so I gave it > a try again. Synplify(the synthesis tool) failed with a SIGILL. It turns > out it requires a SSE2 box. > Synplify is a synthesis tool, that is included in diamond. For some > parts it is the only practical choice... It is produced by 'synopsys', > and they do not mention any instruction set requirements on their > website... > http://www.synopsys.com/Tools/Implementation/FPGAImplementation/FPGASynthesis/Pages/FPGAPlatformSupport.aspx#requirements > > > The other synthesis tools supported are: > Precision: 3rd party (`mentor graphics`), not included, MachXO2 not > supported. > Lattice LSE: Lattice Synthesis Engine, included. Available only with > MachXO, MachXO2, and Platform Manager. > > I did not try those, as they don't support LatticeXP parts... they > _probably_ work. > > All in all, things have improved. It might work on your common, everyday > box.. if it isn't too old. > > regards, > JK I have no idea why you could not get their tools to work. I have never had trouble installing the tools other than the license issues which are common to all of these vendor supplied tools. I have also never had trouble with getting duplicate licenses for new computers. I don't know why you felt you needed to wait a year. In fact, when I ask for a license renewal, they send me a license file for every machine I have ever registered with them! The only real issue with any of the vendor packages are the IDEs which can be different. Typically they try to emulate a Windows look and feel with some sort of a file manager-like GUI and some icons for the various files and/or processes of compiling code to produce a bit stream. The "classic" ispLever is a little clunky in some ways, but it has never gotten in the way of doing work. I have yet to try Diamond. As to using schematic for any part of a design, I would point out that schematic for even top level design is rarely used in industry. It has notable disadvantages with the lack of potability at the top of the list. I suppose I can see why you might prefer it for teaching since it is very visual, but in the "real" world this will not be encouraged. Structural HDL is not hard to learn or use really. So why teach techniques that are unlikely to be used? RickArticle: 154256
Mark Brehob wrote: > Yeah, sadly for us we have no control at all over what computers > people use, so we can't rely on parallel ports... OK, one other thing is that due to export restrictions, no vendor's free software can run on 64-bit operating systems. There are ways to hack links to libraries on Linux to get around this for Xilinx web pack software, apparently. JonArticle: 154257
An article on the local/global and synchronous/asynchronous aspects of resets: http://www.fpga-dev.com/resets-make-them-synchronous-and-local/Article: 154258
hello all, I am new in the field of soft core processor. I want to implement multiple picoblaze on spartan 3E. I had gone through doc available on xilinx website. All demo available on web is working fine with me. I am trying to interface a seven segment with picoblaze but somehow i am not able to make my own design. Please guide me for same.Article: 154259
On Tue, 18 Sep 2012 07:43:13 -0700, rvm.rahul wrote: > hello all, > I am new in the field of soft core processor. I want to implement > multiple picoblaze on spartan 3E. > > I had gone through doc available on xilinx website. All demo available > on web is working fine with me. I am trying to interface a seven segment > with picoblaze but somehow i am not able to make my own design. > > Please guide me for same. I can't help you much because I haven't done this, but I can tell you a bit: First, you haven't told us everything. Most importantly, how far did you get? Have you gotten a picoblaze working on a test board? How did you determine that it works? Second: how are you trying to interface the seven-segment display to the Picoblaze? The obvious way to me (keeping in mind that I haven't played with a Picoblaze so I'm thinking like a board designer) would be to map a section of the Picoblaze's memory space to an 8-bit register that captures a byte on a write to a specific address, then connect that register to eight output pins on the FPGA. Those output pins can then go to your seven segments (plus decimal point!), and you can write any arbitrary combination of "on" and "off" that you want. I'd try to find a demo that shows how to get a Picoblaze working and "talking" to output pins on the FPGA and work from there. If you're lucky there's a demo that shows how to get an 8-bit parallel output port to the outside world, in which case your FPGA firmware task is _done_ and all you need to do is write software. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.comArticle: 154260
>Hello Group > >I=B4ve read a lot about resets and I=B4ve decided that for my designs, an >asynchronous solution with a synchronous source is a better solution. >No discussions here, this is a personal (almost religious) choice. > Religious choice is an apt description. How else can you justify something that has zero scientific evidence to support it? What you are looking for is called a synchronous reset distribution tree. Google that and you find some papers on it on Cliff Cumming's web site. It is the only way to distribute an asynchronous assert/synchronous deassert reset without skew. Global resources are used when you have to deal with fast signals. PowerOn reset is very very slow. Don't waste resources on it. Remember that the reset system only has two requirements. 1) Force the chip into a known good state while the reset button is pressed. 2) Do nothing while the reset button is not pressed. Most designers obsess over making sure the first condition is met while barely considering the second one. This is odd because if you screw up either one then your product will fail. Which one should keep you awake at night? Your product will spend 99.999999% of its power on time running and susceptible to esd induced resets but it is only possible to have a power on reset failure during the 0.000001% of the time that it is powering up. Modern digital tool flows can easily catch design errors that would prevent a chip reset in the RTL phase. Simulating esd events is a lot harder and most of this is done by QA testing. These failures are asymmetric. If an esd event can get into your chip and change state on a flop then your product is crap. If your power on reset fails to reach a flop it will simply take on the next state value provided by the mission mode logic. What will that be? It will almost always be the same as the reset state. The power on reset system has a good deal of redundancy.Everybody first puts in a power on reset system and then adds their mission mode logic that backs up the power on reset with the mission mode soft reset systems. You can forget to connect a flop into the power on system and it will likely still work. It is almost impossible to screw up the reset system so that your product fails to power up AND to do so in a way that your verification suite won't catch it. But it is very easy to have a esd entry path and not catch it till you get the customer returns. You should first worry about preventing phantom resets and after you have solved that then worry about getting power on reset into your chip. If you do that then you will never run an asynchronous reset signal down to the core flops. Read Xilinx WP-231. John Eaton --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154261
jt_eaton <1590@embeddedrelated> wrote: >>Hello Group >> >>I=B4ve read a lot about resets and I=B4ve decided that for my designs, an >>asynchronous solution with a synchronous source is a better solution. >>No discussions here, this is a personal (almost religious) choice. > Religious choice is an apt description. How else can you > justify something that has zero scientific evidence to support it? > What you are looking for is called a synchronous reset distribution tree. > Google that and you find some papers on it on Cliff Cumming's web site. It > is the only way to distribute an asynchronous assert/synchronous deassert > reset without skew. For FPGAs, power up is always asynchronous, and you have to have some way to get from configuration reset to operation. > Global resources are used when you have to deal with fast signals. > PowerOn reset is very very slow. Don't waste resources on it. Hopefully the FPGA designers did use (not waste) resources on it. > Remember that the reset system only has two requirements. > 1) Force the chip into a known good state while the reset button is > pressed. > 2) Do nothing while the reset button is not pressed. > Most designers obsess over making sure the first condition is met while > barely considering the second one. This is odd because if you screw up > either one then your product will fail. Which one should keep you awake at > night? If you can stop the clock until the system is out of reset and ready, then there should be no problem. Otherwise, yes, you do have to be very careful about the transition. -- glenArticle: 154262
Am Dienstag, 18. September 2012 16:43:14 UTC+2 schrieb rvm....@gmail.com: > hello all, > > I am new in the field of soft core processor. > > I want to implement multiple picoblaze on spartan 3E. > > > > I had gone through doc available on xilinx website. > > All demo available on web is working fine with me. > > I am trying to interface a seven segment with picoblaze but somehow i am not able to make my own design. > > > > Please guide me for same. Hi, do you have some knowledge/experience with HDLs or digital design? The PicoBlaze documentation shows very well how to add ports to the core and how to access these ports from the software. (Sorry Tim, there's no memory mapped I/O for the picoblaze. But the real solution is quite similar.) Many beginners questions regarding the Picoblaze have already been answered and can be found here: http://forums.xilinx.com/t5/PicoBlaze/bd-p/PicoBlaze If there are still things unclear you should explain them in more detail. - What board are you using? - What is your design method (schematic, verilog, VHDL)? - Where exactly are you haveing problems with your design? (Error messages etc.) The above mentioned subforum might be a better place for this, since it is specialized on Picoblaze related topics. Have a nice synthesis EilertArticle: 154263
On Tue, 18 Sep 2012 07:31:18 -0700 (PDT) Carl <carwer0@gmail.com> wrote: > An article on the local/global and synchronous/asynchronous aspects > of resets: > > http://www.fpga-dev.com/resets-make-them-synchronous-and-local/ Something that always seems to be missing when I read articles like this is any mention whatsoever of the FPGA’s built-in reset capabilities. For Xilinx Spartan FPGAs anyway, this is called “GSR” (global set/reset). It’s certainly global, and I believe it’s asynchronous. I don’t know what kind of skew it typically has, but it has one wonderful benefit when it’s usable: it’s absolutely 100% free. The GSR network is built into the chip whether you use it or not, so using it to reset all your FFs costs absolutely nothing in terms of LUTs and routing, something no other solution can claim. When dealing with a nearly-full FPGA, that’s a very attractive property. As far as issues of different FFs leaving reset on different clock cycles are concerned, could one not solve these issues by asserting GSR for long enough to reset all FFs, deassert it, then activate the clocks afterwards? Using BUFGCEs (in Xilinx parlance) one could do this with a very small chunk of logic, far less than the overhead of building synchronous resets by routing the reset signal around the chip and then feeding it into all the LUTs that make up feedback loops (increasing LUT count in, say, one sixth of such cases where the LUT was already populated by six inputs). Driving the ENABLE input of a canned oscillator off a shift register of sufficient length clocked by the internal configuration clock would probably achieve something similar. Am I missing something about this proposed solution? I really wish someone would write one of these articles about system reset that acknowledges the existence of GSR and compares it to other reset mechanisms and points out the advantages and disadvantages of each. Unfortunately “someone” won’t be me, because I’m nowhere near an FPGA expert and couldn’t hope to give it a proper treatment. Maybe someone has written such an article, but I haven’t seen it. ChrisArticle: 154264
On Thursday, 13 September 2012 20:03:07 UTC+1, Jon Elson wrote: > rickman wrote: >=20 >=20 >=20 >=20 >=20 > >=20 >=20 > > If you build the Parllel Cable III into your product, what will you >=20 > > connect it to? I don't think they have built a PC with a parallel port >=20 > > in a number of years and my understanding is that the drivers for USB >=20 > > parallel ports don't work properly with bit banging software like this. >=20 > > Am I mistaken? Is this a workable solution? >=20 > I have no idea about the USB-parport, but you CAN get computers with real >=20 > parallel ports, just not on laptops. I use the parallel port for lots >=20 > of interconnect projects, and the Intel D525 chipset still has parport >=20 > support, if the motherboard maker chooses to bring it out. For this >=20 > reason, we use a lot of Intel D525 (Atom) motherboards in projects. >=20 >=20 >=20 > Jon I've been burnt by this. Xilinx use a proper plug and play driver for their= parallel cable IV and will therefore work with a very cheap PCI parallel p= ort card. ALTERA don't, their driver insists on the parallel port being whe= re IBM put it in IO space 30 odd years ago. ColinArticle: 154265
On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote: > On Tue, 18 Sep 2012 07:31:18 -0700 (PDT) > Carl <carwer0@gmail.com> wrote: > >> An article on the local/global and synchronous/asynchronous aspects of >> resets: >> >> http://www.fpga-dev.com/resets-make-them-synchronous-and-local/ > > Something that always seems to be missing when I read articles like this > is any mention whatsoever of the FPGA’s built-in reset capabilities. For > Xilinx Spartan FPGAs anyway, this is called “GSR” (global set/reset). > > As far as issues of different FFs leaving reset on different clock > cycles are concerned, could one not solve these issues by asserting GSR > for long enough to reset all FFs, deassert it, then activate the clocks > afterwards? Yes. Perhaps better, activate clock enable(s) afterwards. Either way, you may need a hierarchy of clock activation; after reset, you don't want your main clock generator to wait for several cycles of a (stopped) clock... - BrianArticle: 154266
colin <colin_toogood@yahoo.com> wrote: (snip on FPGA programming) > I've been burnt by this. Xilinx use a proper plug and play > driver for their parallel cable IV and will therefore work > with a very cheap PCI parallel port card. ALTERA don't, > their driver insists on the parallel port being where IBM > put it in IO space 30 odd years ago. Go through the binary code of the driver and replace the port number with the desired, different, port number. I suppose that could also change something else, but it might work. -- glenArticle: 154267
On Tuesday, September 18, 2012 9:02:29 PM UTC-5, jt_eaton wrote: >If you do that then you will never run an asynchronous reset signal down to the core flops. Read Xilinx WP-231. I've read WP-231, and it best be taken with a big dose of salt, like most generalizations. Please note the date, and the applicable series of FPGAs. If we are trying to avoid religion, "never" is a very long time and is almost certainly untrue. There are many valid reasons to use an asynchronous reset, and many valid reasons to use a synchronous reset. Let's just leave it at that, without all the pontifications invoking "never" (or "always"). Besides, the OP's Q has nothing to do with async vs sync reset; both usually need to meet timing anyway. AndyArticle: 154268
>On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote: > >> On Tue, 18 Sep 2012 07:31:18 -0700 (PDT) >> Carl <carwer0@gmail.com> wrote: >> >>> An article on the local/global and synchronous/asynchronous aspects of >>> resets: >>> >>> http://www.fpga-dev.com/resets-make-them-synchronous-and-local/ >> >> Something that always seems to be missing when I read articles like this >> is any mention whatsoever of the FPGA’s built-in reset capabilities. For >> Xilinx Spartan FPGAs anyway, this is called “GSR” (global set/reset). >> >> As far as issues of different FFs leaving reset on different clock >> cycles are concerned, could one not solve these issues by asserting GSR >> for long enough to reset all FFs, deassert it, then activate the clocks >> afterwards? > >Yes. Perhaps better, activate clock enable(s) afterwards. > >Either way, you may need a hierarchy of clock activation; after reset, >you don't want your main clock generator to wait for several cycles of a >(stopped) clock... > >- Brian > Guys, You don't need to stop the clock at all. The reset deassert to clock edge spec only applies when you are trying to change state. So if you reset the flop to 0 and have a 1 sitting on the D input then you must meet timing or it will go metastable. If you have a 0 on the D input then it doesn't matter if you meet timing. The flop will stay at 0. Most designs already do this. When an ethernet interface comes out of reset it doesn't suddenly start ethernetting, It waits for the CPU to write setup and other data before it does anything. That means that once all of its flops are in reset state then they all have that reset state applied to their D inputs until the first cpu write. You can deassert a asynchronous reset at any time as long as your asynchronous reset system is backed up with a synchronous one provided by the mission mode logic. You do have to be careful with the cpu or any other block that self starts but thats easy to deal with. John Eaton --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154269
On Wed, 19 Sep 2012 09:50:35 -0500, jt_eaton wrote: >>On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote: >>> As far as issues of different FFs leaving reset on different clock >>> cycles are concerned, could one not solve these issues by asserting >>> GSR for long enough to reset all FFs, deassert it, then activate the >>> clocks afterwards? >> >>Yes. Perhaps better, activate clock enable(s) afterwards. >> >>Either way, you may need a hierarchy of clock activation; after reset, >>you don't want your main clock generator to wait for several cycles of a >>(stopped) clock... >> >>- Brian >> >> > Guys, > > You don't need to stop the clock at all. The reset deassert to clock > edge spec only applies when you are trying to change state. I know. But I was being a little facetious, after one occasion when I shot myself in the foot with a synchronous reset for a DLL... - BrianArticle: 154270
On Wed, 19 Sep 2012 09:50:35 -0500, jt_eaton wrote: >>On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote: >>> As far as issues of different FFs leaving reset on different clock >>> cycles are concerned, could one not solve these issues by asserting >>> GSR for long enough to reset all FFs, deassert it, then activate the >>> clocks afterwards? >> >>Yes. Perhaps better, activate clock enable(s) afterwards. >> >>Either way, you may need a hierarchy of clock activation; after reset, >>you don't want your main clock generator to wait for several cycles of a >>(stopped) clock... >> >>- Brian >> >> > Guys, > > You don't need to stop the clock at all. The reset deassert to clock > edge spec only applies when you are trying to change state. I know. But I was being a little facetious, after one occasion when I shot myself in the foot with a synchronous reset for a DLL... - BrianArticle: 154271
> >I've read WP-231, and it best be taken with a big dose of salt, like most generalizations. Please note the date, and the applicable series of FPGAs. > >Andy > It's dated 2006. While that is considered old in some parts of this industry it is very modern when it comes to reset systems. The global async assert/sync deassert reset that is prevalent through out the IC world has been around since the 1980's and was derived from the board level reset systems used back in the days of disco. The important thing about WP-231 is that it was written by the engineers that are the experts on the silicon and tools and provides very specific examples of why decades old design practices are not optimal for todays deep submicron processes A lot of advice that you hear from component designers is out of date and should be ignored, but when the people who wear bunny suits at work give you advice then you really need to listen. John Eaton --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154272
jt_eaton <1590@embeddedrelated> wrote: (snip) > You don't need to stop the clock at all. The reset deassert to clock edge > spec only applies when you are trying to change state. So if you reset > the flop to 0 and have a 1 sitting on the D input then you must meet > timing or it will go metastable. If you have a 0 on the D input then > it doesn't matter if you meet timing. The flop will stay at 0. More specifically, if your FFs have a clock enable input, and you can be sure that they are not enabled as they come out of reset, then you don't have to worry about the clock timing. > Most designs already do this. When an ethernet interface comes out of > reset it doesn't suddenly start ethernetting, It waits for the > CPU to write setup and other data before it does anything. > That means that once all of its flops are in reset state then > they all have that reset state applied to their D inputs until > the first cpu write. There has to be at least one FF with the enable determined though outside logic, but that should be usual in the case of a processor. > You can deassert a asynchronous reset at any time as long as your > asynchronous reset system is backed up with a synchronous one provided > by the mission mode logic. You do have to be careful with the cpu or any > other block that self starts but thats easy to deal with. -- glenArticle: 154273
This is only approximately the right place to be asking this, but if anyone's going to have an answer, I figure it'll be here. Does anyone know how actually find anything about a design out from a TCL script in Aldec Active-HDL. Not anything particularly complicated, things like a list of the active libraries, or what models have been compiled into them. Or what files are in a design. Or whether or not a simulation is currently running. These all seem like trivial and reasonable things to want to know, but I haven't been able to find any documentation telling me how. I can use vlib to create a library, but there doesn't seem to be a call telling me whether or not a library exists. Anyone know anything on this? Advice for how to do it under ModelSim would help too; there's a lot of cross-over. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 154274
On 19/09/2012 18:54, Rob Gaddi wrote: > This is only approximately the right place to be asking this, but if > anyone's going to have an answer, I figure it'll be here. > > Does anyone know how actually find anything about a design out from a > TCL script in Aldec Active-HDL. Not anything particularly complicated, > things like a list of the active libraries, or what models have > been compiled into them. Or what files are in a design. Or whether or > not a simulation is currently running. > > These all seem like trivial and reasonable things to want to know, but I > haven't been able to find any documentation telling me how. I can use > vlib to create a library, but there doesn't seem to be a call telling > me whether or not a library exists. > > Anyone know anything on this? Advice for how to do it under ModelSim > would help too; there's a lot of cross-over. > I don't know Active HDL but in Modelsim you have the report command which can give you bit and pieces like file list, the state of the simulator, log file locations etc. You can use the vmap command to list the libraries which are mapped in the modelim.ini file. This does not however tell you which libraries are actually used, it simply echoes the modelsim.ini [Library] section. The vdir command spews out lots of information on a design unit (or whole library). Another useful command (but currently broken in the 10.1x release) is the "echo [StartupGetArgs]" command which is useful to find out how Modelsim was invoked (not always clear if invoked from another tool like HDL Designer, ISE etc). Regards, Hans. www.ht-lab.com
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