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 Mar 9, 3:17=A0am, Petter Gustad <newsmailco...@gustad.com> wrote: > rickman <gnu...@gmail.com> writes: > > Ok, that's what I get from the Aldec or Lattice ispLever tools. =A0I'll > > have to look at EMACs sometime soon. =A0Can it be used to do pretty > > print formatting on VHDL files? > > Yes, it will "beautify", either the entire buffer or the current > region (using C-c C-b or C-c M-b). > > I'm also using Emacs/Gnus writing this message and reading this > newsgroup. I'm using Emacs/Mew for writing E-mail, also writing > Verilog, Common Lisp, Python, C, Java, LaTex, etc., as well as doing > GIT commits, diffs, creating branches, merges, even surfing the web > using w3m. Dired in Emacs provides a great file browser where I can to > bulk editing etc. Whenever I want to perform tedious repetitive > editing tasks I will usually make a small Emacs Lisp function to do it > for me... > > Petter > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? Petter, There was a guy in some of the Yahoo groups who had a tag line about not being able to chew a radio wave. For some reason it struck me as annoying and eventually I asked him to change it. He was not wedded to it and was nice enough to do so. I find your tag line to be pretty annoying as well. It is one of those things that once you've read it, you don't need to keep reading it. But it is there at the bottom of each post you make and it is hard to ignore. At least I find it hard to ignore. What are the chances you can switch to something else? RickArticle: 146251
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: (snip, someone wrote) >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> A: Top-posting. >> Q: What is the most annoying thing on usenet and in e-mail? (snip, someone else wrote) > I find your tag line to be pretty annoying as well. It is one of > those things that once you've read it, you don't need to keep reading > it. But it is there at the bottom of each post you make and it is > hard to ignore. At least I find it hard to ignore. What are the > chances you can switch to something else? I agree. While I mostly agree that top posting is bad, I don't believe that it is always true. I will rarely read a post if there is nothing new in the first two pages scrolling down. If I do get to the bottom, though, I do seem to keep reading the above comments. In the case of a small addition to a large post, and which has no likely follow-ups. (Doesn't ask a question or extend one.) I would rather see it at the top where I can read it quickly. I don't mind the comments applied to actual top posts, but it gets pretty annoying to see it all the time. -- glenArticle: 146252
rickman wrote: > On Mar 9, 2:13 pm, Andy Peters <goo...@latke.net> wrote: >> On Mar 8, 4:10 pm, "Pete Fraser" <pfra...@covad.net> wrote: >> >> >> >>> Thankyou everybody for your help so far. >>> I seem to be confused by the waveform viewer now. >>> My typical debug cycle in Modelsim XE uses wave.do. >>> I will load the sim, run wave.do to bring up the waveforms >>> I'm interested in, then run the sim. >>> If the waveforms point to mistakes I've made, I'll often >>> want to add a few more waveforms, save the updated >>> wave.do file, then re-start the sim using the new wave.do. >>> I can't work out how to do the equivalent in Active-HDL. >>> My modesim wave.do seems to work in Aldec, but I can't >>> see how to save it when I've added waveforms. >>> I can't even work out how to add waveforms reliably; >>> sometimes dragging signals from the structure pane to an >>> existing waveform viewer opens a new viewer window. >>> I'm also not sure which viewer I'm using (advanced or standard), >>> or how I control that. Sometimes the title bar says >>> "untitled.awc", and sometimes "untitled.asdb". >>> Help, I haven't felt this clueless in a long time. >> I had a conversation with Aldec support yesterday about this very >> topic. >> >> And I agree -- it's very confusing. >> >> There are two things involved with waveform display: >> >> a) The .asdb is the waveform data database (sorry for the redundancy). >> This is a compressed binary that holds all transactions on all signals >> in the design (not just what is displayed). > > WHAT???!!! Is this saying that all of the signals are there and I > should be able to display a new signal without rerunning the > simulation??? I only see .aws and .adf files, no .asdb file. Do I > have to turn a switch to get the .asdb file so I can look at what I > want after the simulation is complete? > > >> b) The .awc is the "accelerated waveform configuration" file. This is >> what the GUI needs to display data in the associated .asdb. >> >> BUT! The above files are really only so you can save a copy of a >> simulation run and display it later without re-running the simulation. > > Well, yeah, in essence that's what I'd like to do. > > >> What you REALLY want is to do is this. The first time you run your >> simulation (after Initialize Simulation), you create a new waveform >> window (which will then show the "untitled.awc" in the title bar), and >> drag all of the signals of interest into that window. > > Yes, go on! > > >> To save this list of signals for future simulation runs, from the >> Waveform window's menu, choose "Waveform -> Save To Macro." This is >> akin to the ModelSim menu item "Save Format As ..." and it will create >> a macro file with the extension .do and it will be stored, by default, >> in the src directory. It will also appear in the current Design in the >> Workspace. Once you've created the file, for future simulation runs, >> you can right-click on the macro file name in the Design and choose >> "Execute" and it will repopulate the waveform display window with your >> desired signals. >> >> What this means is that unless you really need to save the simulation >> waveforms, you can shitcan both the .asdb and .awc files. All you need >> is the macro .do file. > > Ok, but when I'm debugging, I often need to look at intermediate > signals to see where the problem is coming from. It would be great to > not have to rerun the simulation to do that. There is more than once > that I added some signals only to find that the problem took a > slightly different curve than the one I expected and I have to add > more signals. In the end I may have to run the simulation 10 or more > times before I see the problem. Even at 1 minute each, that can waste > a lot of time if there is an easy way to avoid it. > > So how do I get the .asdb and .awc files? > > Rick It has been some time since I used ActiveHDL. From what I can remember you must switch to what is called "accelerated waveform". (I assume you are using standard.) I think this was a preference setting for the program itself. The accelerated waveform has a slightly different look, and you can't use it generate stimuli. MagneArticle: 146253
Magne Munkejord wrote: > rickman wrote: >> On Mar 9, 2:13 pm, Andy Peters <goo...@latke.net> wrote: >>> On Mar 8, 4:10 pm, "Pete Fraser" <pfra...@covad.net> wrote: >>> >>> >>> >>>> Thankyou everybody for your help so far. >>>> I seem to be confused by the waveform viewer now. >>>> My typical debug cycle in Modelsim XE uses wave.do. >>>> I will load the sim, run wave.do to bring up the waveforms >>>> I'm interested in, then run the sim. >>>> If the waveforms point to mistakes I've made, I'll often >>>> want to add a few more waveforms, save the updated >>>> wave.do file, then re-start the sim using the new wave.do. >>>> I can't work out how to do the equivalent in Active-HDL. >>>> My modesim wave.do seems to work in Aldec, but I can't >>>> see how to save it when I've added waveforms. >>>> I can't even work out how to add waveforms reliably; >>>> sometimes dragging signals from the structure pane to an >>>> existing waveform viewer opens a new viewer window. >>>> I'm also not sure which viewer I'm using (advanced or standard), >>>> or how I control that. Sometimes the title bar says >>>> "untitled.awc", and sometimes "untitled.asdb". >>>> Help, I haven't felt this clueless in a long time. >>> I had a conversation with Aldec support yesterday about this very >>> topic. >>> >>> And I agree -- it's very confusing. >>> >>> There are two things involved with waveform display: >>> >>> a) The .asdb is the waveform data database (sorry for the redundancy). >>> This is a compressed binary that holds all transactions on all signals >>> in the design (not just what is displayed). >> >> WHAT???!!! Is this saying that all of the signals are there and I >> should be able to display a new signal without rerunning the >> simulation??? I only see .aws and .adf files, no .asdb file. Do I >> have to turn a switch to get the .asdb file so I can look at what I >> want after the simulation is complete? >> >> >>> b) The .awc is the "accelerated waveform configuration" file. This is >>> what the GUI needs to display data in the associated .asdb. >>> >>> BUT! The above files are really only so you can save a copy of a >>> simulation run and display it later without re-running the simulation. >> >> Well, yeah, in essence that's what I'd like to do. >> >> >>> What you REALLY want is to do is this. The first time you run your >>> simulation (after Initialize Simulation), you create a new waveform >>> window (which will then show the "untitled.awc" in the title bar), and >>> drag all of the signals of interest into that window. >> >> Yes, go on! >> >> >>> To save this list of signals for future simulation runs, from the >>> Waveform window's menu, choose "Waveform -> Save To Macro." This is >>> akin to the ModelSim menu item "Save Format As ..." and it will create >>> a macro file with the extension .do and it will be stored, by default, >>> in the src directory. It will also appear in the current Design in the >>> Workspace. Once you've created the file, for future simulation runs, >>> you can right-click on the macro file name in the Design and choose >>> "Execute" and it will repopulate the waveform display window with your >>> desired signals. >>> >>> What this means is that unless you really need to save the simulation >>> waveforms, you can shitcan both the .asdb and .awc files. All you need >>> is the macro .do file. >> >> Ok, but when I'm debugging, I often need to look at intermediate >> signals to see where the problem is coming from. It would be great to >> not have to rerun the simulation to do that. There is more than once >> that I added some signals only to find that the problem took a >> slightly different curve than the one I expected and I have to add >> more signals. In the end I may have to run the simulation 10 or more >> times before I see the problem. Even at 1 minute each, that can waste >> a lot of time if there is an easy way to avoid it. >> >> So how do I get the .asdb and .awc files? >> >> Rick > > It has been some time since I used ActiveHDL. From what I can remember > you must switch to what is called "accelerated waveform". (I assume you > are using standard.) I think this was a preference setting for the > program itself. > The accelerated waveform has a slightly different look, and you can't > use it generate stimuli. > > Magne Aldec appnote on using accelerated waveform : http://support.aldec.com/KnowledgeBase/Article.aspx?aid=000724Article: 146254
> Ok, but when I'm debugging, I often need to look at intermediate > signals to see where the problem is coming from. It would be great to > not have to rerun the simulation to do that. There is more than once > that I added some signals only to find that the problem took a > slightly different curve than the one I expected and I have to add > more signals. In the end I may have to run the simulation 10 or more > times before I see the problem. Aye, this wouldn't be uncommon if I'm tracing a fault in a reasonably complex design. It's a big selling point for Aldec if you don't need to re-run a sim to add more signals. I have had a few simulations that take 10 minutes to get to the point I'm interested in so this could have saved a _lot_ of time. How much is an Active HDL license (£GBP) approx ? Nial.Article: 146255
On Wed, 10 Mar 2010 09:49:28 -0000, "Nial Stewart" wrote: >> Ok, but when I'm debugging, I often need to look at intermediate >> signals to see where the problem is coming from. It would be great to >> not have to rerun the simulation to do that. There is more than once >> that I added some signals only to find that the problem took a >> slightly different curve than the one I expected and I have to add >> more signals. In the end I may have to run the simulation 10 or more >> times before I see the problem. > >Aye, this wouldn't be uncommon if I'm tracing a fault in a reasonably >complex design. ModelSim lets you do this too - it costs disk space and simulation speed, of course, but may still be worth it for tough debug: log -r /* Now *everything* goes in the waveform log file, and you can add any signal you want to the waveform retrospectively. >It's a big selling point for Aldec if you don't need to re-run a sim to >add more signals. I have had a few simulations that take 10 minutes to >get to the point I'm interested in so this could have saved a _lot_ of >time. Yup. The log does introduce an overhead, but it's unlikely to be worse than a factor of 2 or 3, so likely to be a win if you initially don't know where to start looking. -- Jonathan Bromley (not connected with Mentor, but does use ModelSim quite a lot)Article: 146256
> I've got a problem with my DDR2 (MT47H32M16) on my Spartan3AN board. I > use MIG 2.3 controler. The burst lenght is 4. When I'm writing the > data like x"A1A1B2B2" or x"01010101" everything works. I'm reading the > data after data_valid is set and writing to internal registers. Then > I'm sending it to RS232. > > Problem is when I want write data with zeros... like x"A100B2B2" or > x"01010001". Then data which I'm reading are wrong. For x"A100B2B2" A1 > I can read but else data are wrong:/ > > I'm little confused why it happens.. Is this a custom board or a 3rd party eval board? How confident are you about the terminations between the FPGA and memory? What exactly do you get back when you write x"A100B2B2"? What do you get back if you write all zeros? Can you slow the transfer down (half speed?). I'd be worried about signal integrity, but then the x"01010101" case would suggest this might not be a problem. ? Sounds like you're confident about the RS232 connection, if you weren't this is the sort of thing my 1Pin Interface is useful for. http://www.1pin-interface.com :-) NialArticle: 146257
> ModelSim lets you do this too I need a smiley for a red face :-0 I started using Modelsim 15 odd years ago and am still using it in the same way I 'picked it up'. I have often wondered if I'm missing out on productivity enhancements. > - it costs disk space and > simulation speed, of course, but may still be worth it for > tough debug: > > log -r /* > > Now *everything* goes in the waveform log file, and > you can add any signal you want to the waveform retrospectively. > >>It's a big selling point for Aldec if you don't need to re-run a sim to >>add more signals. I have had a few simulations that take 10 minutes to >>get to the point I'm interested in so this could have saved a _lot_ of >>time. > > Yup. The log does introduce an overhead, but it's unlikely to be > worse than a factor of 2 or 3, so likely to be a win if you > initially don't know where to start looking. Even debug of small modules usually takes a few iterations so this might be a useful 'default' simulation style when using the GUI for fault tracing. I presume for smaller designs the overhead is negligable and it's more likely to pay off for bigger designs. Thanks Jonathan. (Perhaps I should RTFM). Nial.Article: 146258
On Wed, 10 Mar 2010 10:20:15 -0000, "Nial Stewart" wrote:
>(Perhaps I should RTFM).
Nah. That would spoil all the fun, thrill of
the chase, etc, etc.
Anyhow, there's just too much of it. Try this
entertaining little experiment.
1) Open a vanilla Tcl shell (if you have Tcl
installed). Ask it how many commands it
knows about:
llength [info commands]
The answer is about 86, depending on version.
2) Try the same in ModelSim's Tcl console.
Be very, very afraid.
--
Jonathan Bromley
Article: 146259Nial Stewart wrote: >> ModelSim lets you do this too > > I need a smiley for a red face > > :-0 > > I started using Modelsim 15 odd years ago and am still using it in > the same way I 'picked it up'. I have often wondered if I'm > missing out on productivity enhancements. > > >> - it costs disk space and >> simulation speed, of course, but may still be worth it for >> tough debug: >> >> log -r /* >> >> Now *everything* goes in the waveform log file, and >> you can add any signal you want to the waveform retrospectively. >> I had a quick look in aldec, and it has a command log -r * According to the help this is a synonym for trace -r * There are also various settings on the Trace/Debugging tab to do with how Aldec preserves the signals you've added to the wavefrom window, regards Alan <snip> > > (Perhaps I should RTFM). > That's what I did :-; -- Alan Fitch Senior Consultant Doulos – Developing Design Know-how VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 1AW, UK Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com Fax: +44 (0)1425 471573 http://www.doulos.com ------------------------------------------------------------------------ This message may contain personal views which are not the views of Doulos, unless specifically stated.Article: 146260
Hi, I'm doing this project using ISE 9.2i and am getting the ngd build error: 604 during translation. Can anyone please let me know how to resolve this error. I'm able to synthesize the code successfully. Thanks. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146261
The world's first 3D FPGA has arrived! We have a very compelling and cost effective solution. Come check it out folks. www.tierlogic.com JeffArticle: 146262
On Mar 10, 3:03=A0am, Magne Munkejord <magnem...@yahoo.no> wrote: > rickman wrote: > > On Mar 9, 2:13 pm, Andy Peters <goo...@latke.net> wrote: > >> On Mar 8, 4:10 pm, "Pete Fraser" <pfra...@covad.net> wrote: > > >>> Thankyou everybody for your help so far. > >>> I seem to be confused by the waveform viewer now. > >>> My typical debug cycle in Modelsim XE uses wave.do. > >>> I will load the sim, run wave.do to bring up the waveforms > >>> I'm interested in, then run the sim. > >>> If the waveforms point to mistakes I've made, I'll often > >>> want to add a few more waveforms, save the updated > >>> wave.do file, then re-start the sim using the new wave.do. > >>> I can't work out how to do the equivalent in Active-HDL. > >>> My modesim wave.do seems to work in Aldec, but I can't > >>> see how to save it when I've added waveforms. > >>> I can't even work out how to add waveforms reliably; > >>> sometimes dragging signals from the structure pane to an > >>> existing waveform viewer opens a new viewer window. > >>> I'm also not sure which viewer I'm using (advanced or standard), > >>> or how I control that. Sometimes the title bar says > >>> "untitled.awc", and sometimes "untitled.asdb". > >>> Help, I haven't felt this clueless in a long time. > >> I had a conversation with Aldec support yesterday about this very > >> topic. > > >> And I agree -- it's very confusing. > > >> There are two things involved with waveform display: > > >> a) The .asdb is the waveform data database (sorry for the redundancy). > >> This is a compressed binary that holds all transactions on all signals > >> in the design (not just what is displayed). > > > WHAT???!!! =A0Is this saying that all of the signals are there and I > > should be able to display a new signal without rerunning the > > simulation??? =A0I only see .aws and .adf files, no .asdb file. =A0Do I > > have to turn a switch to get the .asdb file so I can look at what I > > want after the simulation is complete? > > >> b) The .awc is the "accelerated waveform configuration" file. This is > >> what the GUI needs to display data in the associated .asdb. > > >> BUT! The above files are really only so you can save a copy of a > >> simulation run and display it later without re-running the simulation. > > > Well, yeah, in essence that's what I'd like to do. > > >> What you REALLY want is to do is this. The first time you run your > >> simulation (after Initialize Simulation), you create a new waveform > >> window (which will then show the "untitled.awc" in the title bar), and > >> drag all of the signals of interest into that window. > > > Yes, go on! > > >> To save this list of signals for future simulation runs, from the > >> Waveform window's menu, choose "Waveform -> Save To Macro." This is > >> akin to the ModelSim menu item "Save Format As ..." and it will create > >> a macro file with the extension .do and it will be stored, by default, > >> in the src directory. It will also appear in the current Design in the > >> Workspace. Once you've created the file, for future simulation runs, > >> you can right-click on the macro file name in the Design and choose > >> "Execute" and it will repopulate the waveform display window with your > >> desired signals. > > >> What this means is that unless you really need to save the simulation > >> waveforms, you can shitcan both the .asdb and .awc files. All you need > >> is the macro .do file. > > > Ok, but when I'm debugging, I often need to look at intermediate > > signals to see where the problem is coming from. =A0It would be great t= o > > not have to rerun the simulation to do that. =A0There is more than once > > that I added some signals only to find that the problem took a > > slightly different curve than the one I expected and I have to add > > more signals. =A0In the end I may have to run the simulation 10 or more > > times before I see the problem. =A0Even at 1 minute each, that can wast= e > > a lot of time if there is an easy way to avoid it. > > > So how do I get the .asdb and .awc files? > > > Rick > > It has been some time since I used ActiveHDL. From what I can remember > you must switch to what is called "accelerated waveform". (I assume you > are using standard.) I think this was a preference setting for the > program itself. > The accelerated waveform has a slightly different look, and you can't > use it generate stimuli. > > Magne Well kiss my grits! It seems Lattice licensees are second class citizens and the accelerated waveform viewer is not available. No wonder I didn't know about it. The docs say the accelerated viewer is the default! RickArticle: 146263
Jeff, Except you require registration to even see what it is that you have. What are you afraid of? Competition? So, until you decide to stop "qualifying customers" I am afraid you will remain a relatively unknown company. That is OK: the longer it takes for you to make money, the more likely the investors pull the plug, and you go away like all the other FPGA companies have in the past. Good luck, AustinArticle: 146264
On Mar 10, 7:42=A0pm, austin <aus...@xilinx.com> wrote: > Jeff, > > Except you require registration to even see what it is that you have. > > What are you afraid of? =A0Competition? > > So, until you decide to stop "qualifying customers" I am afraid you > will remain a relatively unknown company. > > That is OK: =A0the longer it takes for you to make money, the more > likely the investors pull the plug, and you go away like all the other > FPGA companies have in the past. > > Good luck, > > Austin 100% agree!! not seen so dumb stupid website launch for a long time AnttiArticle: 146265
Weng, Let's look at what behavior generates a latch: The need for the circuit to remember a previous assignment from a previous execution of the process, when no other storage media is implied (i.e. in a combinatorial process). In a clocked process, the register does the remembering, since the process will have to remember the previous assignment when it executes on the falling edge too). A clock enable is added when the process must remember over more than one clock cycle. Looking at it another way, conceptually, a latch is nothing than a mux with feedback around whatever the input logic was (combinatorial). A register with clock enable is conceptually just a mux with feedback too, but the feedback is from the output of the register back to its input. So, in a combinatorial process with a missed assignment, you get a latch, whereas in a clocked process, it gets implemented with a clock enable on the register, and no latch is needed. Some synthesis tools may be getting smart enough to optimize an inferred latch from a combinatorial process into a clock enable on the corresponding register implied by the clocked process. But if there are any other combinatorial processes that use that latched output of the first combinatorial process, then the latch cannot be replaced by a clock enable on a register. AndyArticle: 146266
On Mar 9, 12:15=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > I would strongly encourage you to change the RESET function from > asynchronous to synchronous. On what basis do you make this recommendation, and what does this have to do with latches? AndyArticle: 146267
On Mar 10, 11:46=A0am, Tier Logic <jeff.ka...@gmail.com> wrote: > The world's first 3D FPGA has arrived! We have a very compelling and > cost effective solution. > > Come check it out folks.www.tierlogic.com > > Jeff Sad. I have a passing interest in anything proclaiming itself "new" and "revolutionary" but I won't bother to register to get more information. I *might* have the next $1M+ design but it will go to standard FPGAs because I can't find out about the promising technology on a casual basis. ___ "Are you interested in dating me?" "Not without a ring." Huh?Article: 146268
On Mar 10, 1:11=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > On Mar 10, 11:46=A0am, Tier Logic <jeff.ka...@gmail.com> wrote: > > > The world's first 3D FPGA has arrived! We have a very compelling and > > cost effective solution. > > > Come check it out folks.www.tierlogic.com > > > Jeff > > Sad. > > I have a passing interest in anything proclaiming itself "new" and > "revolutionary" but I won't bother to register to get more > information. > > I *might* have the next $1M+ design but it will go to standard FPGAs > because I can't find out about the promising technology on a casual > basis. > ___ > > "Are you interested in dating me?" =A0"Not without a ring." =A0Huh? I didn't realize the *entire* site is off limits until you have registered. Registration means giving them your email address and waiting for them to get back to you... I guess they want to exclude the little guys and I am a little guy. So in effect, I don't exist. To me, they don't exist. RickArticle: 146269
On Mar 10, 10:06=A0am, Andy <jonesa...@comcast.net> wrote: > On Mar 9, 12:15=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > I would strongly encourage you to change the RESET function from > > asynchronous to synchronous. > > On what basis do you make this recommendation, and what does this have > to do with latches? > > Andy Synchronous versus asynchronous resets have been discussed at length in other threads. Asynchronous resets have their place in a designer's toolbox, however they should be used sparingly. Some reasons to use these are for handshakes crossing clock domains, anticipated loss of clock and asynchronous inputs to the synchronous domain. In a synchronous domain, such as the original state machine example, the asynchronous functionality offers no additional benefit in FPGAs as the area cost is identical for both. Asynchronously asserting and de-asserting a reset across multiple registers may/will result in the registers being released before and after a clock edge due to large net delay and skew on the reset net. This will result in different parts of a design coming out of reset across clock boundaries and being out of sync with each other. Synchronous resets simplify timing analysis and timing closure without having to worry about the consequences of the asynchronous functions and how to correctly constrain them. I often see problems with FPGA designs that are built with asynchronous resets, but I have yet to see a problem with a FPGA design that was traced to a synchronous reset. In an FPGA there is no downside to a synchronous reset, but there are many pitfalls with an asynchronous reset. None of this has anything to do with a latch, which you also want to avoid using in an FPGA. Ed McGettigan -- Xilinx Inc.Article: 146270
On 3/10/2010 4:46 PM, Tier Logic wrote: > The world's first 3D FPGA has arrived! We have a very compelling and > cost effective solution. > > Come check it out folks. www.tierlogic.com > > Jeff Hi Jeff, I've examined all the old FPGAs I've found in my office, and they all seem to have three dimensions already. Even the old ones from 1986. This seems to be the biggest marketing fraud since the film 'The NeverEnding Story'. Syms. p.s. Apologies to Lionel Hutz.Article: 146271
On Mar 9, 1:42=A0pm, Michael Wojcik <mwoj...@newsguy.com> wrote: > Greg Menke wrote: > > > C++ does make for a nice "type-safe linking" C compiler. > > Except that it's not a C implementation, and so is not a C compiler at > all. > > C and C++ are different languages. > There is a subset/superset relationship between the two. Not unlike the 8080 and Z-80, except IMO, the Z-80 is better than the 8080 and C is better than C++.Article: 146272
On Mar 10, 10:06=A0am, Andy <jonesa...@comcast.net> wrote: > On Mar 9, 12:15=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > I would strongly encourage you to change the RESET function from > > asynchronous to synchronous. > > On what basis do you make this recommendation, and what does this have > to do with latches? > > Andy Please allow me to chime in with a basic tutorial: Latches and flip/flops=3Dregisters have common features and also a big difference: They both are storage elements, both have a Data input (D) and a data output ( Q), and both have a control input called Enable or Clock. (Let me ignore the contentious issue of asynchronous or synchronous Reset/clear or Preset) The big difference: A latch is transparent,( i.e. Q follows D, and thus there is no storage), whenever the Enable input is active. But Data is stored when Enable is inactive. A flip-flop is NEVER transparent. (D can never affect Q directly). Q assumes the state that D had right before the rising edge of the clock. How is this done? Inside the flip-flop, there are two cascaded latches (called Master and Slave). The Master latch is transparent and its internal output follows the D input as long as the Clock is low. The Slave latch is transparent and its external output Q follows the slave's internal output whenever the Clock is High, but during this time the Master is non-transparent =3D locked up. So the two cascaded latches have the opposite enable polarity. Thus the flip-flop's Q output can only change on (i.e. right after) the rising clock edge. I do not want to belabor the advantages of either design, just to avoid confusion. The flip-flop or register is the prevalent design. It wins the Oscar in most (but not all) cases..., but RAM cells always use the simpler latch structure. Peter Alfke, (teacher at heart)Article: 146273
Wow, tough crowd. http://www.eetimes.com/showArticle.jhtml?articleID=223400002&cid=NL_eet has some info for the link-inclined. FPGA architecture looks pretty standard. Value-added is almost entirely in their Tier-FPGA to Tier-ASIC transition, from what I can tell. Seems to me that that limits their potential customers-- for really large volume pipelined life-cycle products, ASIC probably makes sense off the bat. For low-volume, more specialty products, you're stuck at FPGA timing, so why not use an FPGA? So you're left with moderate volume customers where time-to-market drives everything. I'm not a business head, but I guess if you really got into a groove with these guys to reduce the FPGA-to-ASIC transition to a couple of weeks, that could be really cool for some folks. --Josh On 3/10/2010 2:25 PM, Symon wrote: > On 3/10/2010 4:46 PM, Tier Logic wrote: >> The world's first 3D FPGA has arrived! We have a very compelling and >> cost effective solution. >> >> Come check it out folks. www.tierlogic.com >> >> Jeff > > Hi Jeff, > I've examined all the old FPGAs I've found in my office, and they all > seem to have three dimensions already. Even the old ones from 1986. This > seems to be the biggest marketing fraud since the film 'The NeverEnding > Story'. > Syms. > > p.s. Apologies to Lionel Hutz.Article: 146274
In comp.arch.fpga Peter Alfke <alfke@sbcglobal.net> wrote: (snip) > I do not want to belabor the advantages of either design, > just to avoid confusion. > The flip-flop or register is the prevalent design. It wins the Oscar > in most (but not all) cases..., but RAM cells always use the simpler > latch structure. To be more specific, SRAM. Now, are there more SRAM cells around than registers bits in processors? If you count SRAM in processor cache memory it might be that there are more. For the first digital logic class I had, all the classroom demonstrations were done with paired RS flip-flops and a two phase clock. It does make it easier to understand in a classroom setting. Also, many past processors did use a two (or more) phase clock. (I remember stories about the four phase clock for the TMS9900.) It would be interesting to have an FPGA with transparent latches after each LUT instead of the current edge triggered FFs. -- glen
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