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 Apr 21, 9:32=A0am, John_H <newsgr...@johnhandwork.com> wrote: > Michael wrote: > > <snip> > > > > > > > > > A-ha! I realized I could get rid of the edge checking and just compare > > with my saved previous state. It synthesizes! Unfortunately, it gives > > me some warnings during synthesization, and then (I believe due to the > > warnings) it won't give me a programming file. The warnings are: > > > the following signal(s) form a combinatorial loop: led<7>, enc_cnt<7>, > > Maddsub_enc_cnt14. > > > (for led<7> - led<0>) > > > Then it gives me a bunch of errors during mapping, like this one: > > > ERROR:MapLib:661 - LUT4 symbol "Maddsub_enc_cnt41" (output > > =A0 =A0signal=3DMaddsub_enc_cnt4) has input signal "Maddsub_enc_cnt" whi= ch > > will be > > =A0 =A0trimmed. See the t > > > I'm so close now (I think!) Can anybody tell me what is wrong with my > > code? I've never had a problem with mapping before - so this is very > > odd for me. I've posted the full code below. Thanks so much! > > > -Michael > > > library IEEE; > > use IEEE.STD_LOGIC_1164.ALL; > > use IEEE.numeric_std.all; > > > entity hello_world is > > port ( > > =A0 =A0clk, enc_a, enc_b : in std_logic; > > =A0 =A0switches : in std_logic_vector (3 downto 0); > > =A0 =A0led : out std_logic_vector (7 downto 0) > > ); > > end hello_world; > > > architecture rtl of hello_world is > > =A0 =A0signal cnt : unsigned (30 downto 0); > > =A0 =A0signal encval : unsigned (7 downto 0); > > =A0 =A0signal enc_cnt : unsigned (7 downto 0); > > =A0 =A0signal prevstate : std_logic_vector (1 downto 0); > > begin > > =A0 =A0process(clk) > > =A0 =A0begin > > =A0 =A0 =A0 =A0 =A0 =A0if rising_edge(clk) then > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cnt <=3D cnt + 1; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0encval <=3D "000000" & enc_b & en= c_a; > > =A0 =A0 =A0 =A0 =A0 =A0end if; > > =A0 =A0end process; > > > process(enc_a, enc_b) > > begin > > =A0 =A0if prevstate(0) /=3D enc_a then > > =A0 =A0 =A0 =A0 =A0 =A0case prevstate is > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when "00"=3D> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enc_cnt <=3D enc_= cnt + 1; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when "01"=3D> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enc_cnt <=3D enc_= cnt - 1; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when "10"=3D> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enc_cnt <=3D enc_= cnt - 1; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when "11"=3D> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enc_cnt <=3D enc_= cnt + 1; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when others =3D> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enc_cnt <=3D enc_= cnt; > > =A0 =A0 =A0 =A0 =A0 =A0end case; > > =A0 =A0else > > =A0 =A0 =A0 =A0 =A0 =A0case prevstate is > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when "00"=3D> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enc_cnt <=3D enc_= cnt - 1; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when "01"=3D> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enc_cnt <=3D enc_= cnt + 1; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when "10"=3D> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enc_cnt <=3D enc_= cnt + 1; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when "11"=3D> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enc_cnt <=3D enc_= cnt - 1; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when others =3D> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enc_cnt <=3D enc_= cnt; > > =A0 =A0 =A0 =A0 =A0 =A0end case; > > =A0 =A0end if; > > > =A0 =A0prevstate(0) <=3D enc_a; > > =A0 =A0prevstate(1) <=3D enc_b; > > end process; > > > =A0 =A0led <=3D std_logic_vector(cnt(30 downto 23)) when switches(0)=3D'= 0' else > > std_logic_vector(enc_cnt); > > > end rtl; > > You almost have what you want but you will still have troubles because > mechanical chatter can matter in a binary implementation. =A0One way you > CAN achieve your goals is to use Gray code counters, at least for the > LSbits. > > I previously designed a 3-bit Gray code counter for a first stage of a > very fast counter such that I only have 1 LUT of delay for each bit and > was able to count at a clock frequency limited by the delay of a single > LUT. =A0My design produced the same combinatorial loops warning but for a > stable =A0combinatorial quadrature counter, those are expected warnings > and should still produce a programming file. =A0Even here, I used this > first stage as a divide-by-8 prescaler rather than using the count > directly because getting a 3-bit Gray counter to sync up with a > multi-bit Gray or binary counter isn't trivial though it is doable with > a little care. > > The key to getting a quadrature counter to work with a Gray code counter > is to realize that when you are at a specific Gray count, only two bits > can change: one for the forward direction, one for reverse. =A0Effectively= > one channel of the quadrature counter can be slaved to the LSbit while > the count determines which upper bit (and at what polarity) the other > quadrature channel controls. =A0When you transition between two upper bits= > being controlled by the one quadrature channel, the bits are both safe > because the quadrature channel that controls those upper bits is in the > middle, stable part of its cycle while the LSbit channel is > transitioning the count, affecting which upper bit is controlled. > > When the Gray count is read, the value is (typically) registered in the > clock domain twice such that if one bit is caught mid-transition then > that value will be settled upon by the second register - only one > register - as a defined value. =A0If instead there are multiple registers > fed by that one first-stage value, it's possible two paths could "see" > different values for this asynchronously changing signal. > > If you can figure how to count in Gray and then how to change one bit > (at a defined polarity) at a time for a given count, you will have an > every-transition counter for full resolution and be > asynchronous-friendly in your design. =A0And you will get plenty of > combinatorial-loop warnings for your design but you will be able to > produce a programming file; they are just warnings, after all. > > - John_H John - unless I'm missing something here... I think just watching edges is good enough to deal with any sort of debouncing problems, as long as only A or B (not both) are bouncing at any given time. But either way - right now I really just want to figure out why I can't get the stupid thing to map properly - and then I will worry more about dealing with the small things. I just posted the full code, constraints, and console output on the FPGA4Fun forum: http://www.fpga4fun.com/forum/viewtopic.php?t=3D1281 Can somebody please look at this? I just am at a complete loss as to what is wrong - but to you more experienced people the problem will probably jump right out. Thanks! -MichaelArticle: 131426
rickman wrote: > > On Apr 21, 3:24 am, "Michael A. Terrell" <mike.terr...@earthlink.net> > wrote: > > John Larkin wrote: > > > > No reason to live if you have nothing to do. :( > > > > --http://improve-usenet.org/index.html > > > > Use any search engine other than Google till they stop polluting USENET > > with porn and junk commercial SPAM > > > > If you have broadband, your ISP may have a NNTP news server included in > > your account:http://www.usenettools.net/ISP.htm > > What is the point of including a link to the "improve usenet" page? I > don't see any useful information there. The page complains about a > few things and offers no advice on what to do about any of it... > counter to its stated purpose of being "an attempt to make Usenet > participation a better experience for those who are clued as to what > the Usenet medium is and how to use it". Instead of offering anything > constructive, they even insult people that they should be trying to > reach and convince... "most of the people who post to Usenet via the > clunky Google Groups web interface are lusers or lamers". > > Do you think that this page has had any sort of positive influence on > usenet? Does your posting the link help in any way? Yes. It has a link to the current version of News Proxy, and a lot of people have installed it because of that link. More and more are completely filtering out Google Groups in protest of the spam they dump on Usenet. I will probably stop tagging Google Groups messages and drop them, starting on May first. -- http://improve-usenet.org/index.html Use any search engine other than Google till they stop polluting USENET with porn and junk commercial SPAM If you have broadband, your ISP may have a NNTP news server included in your account: http://www.usenettools.net/ISP.htmArticle: 131427
Hi Joerg, "Joerg" <notthisjoergsch@removethispacbell.net> wrote in message news:PLsOj.7522$GE1.332@nlpi061.nbdc.sbc.com... > Private companies generally offer zilch in retirement benefits. Those days > are long gone. Actually I think a very significant fraction of companies (at least those hiring EEs) offer some sort of contribution to 401k plans, sometimes profit sharing, sometimes stock options, etc... but I concur that the old days of "company pensions" is pretty much gone. > A 70 year old programmer can be better than a 40 year old. Absolutely, but if you're an employer it's definitely a legitimate consideration that starting a bunch of 70-year-olds on a, say, decade-long "modernization" project is rather riskier than if you toss a few 50- or 30-year-olds into the mix as well. :-) > Anyhow, why should retirement checks be based on the last year of service? > IMHO that's wrong. I agree that one year seems too short, but trying to figure out how many years should be taken into consideration (which is effectively what happens in private companies if the company is contributing to your 401k) is not going to be easy either. ---JoelArticle: 131428
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:coen041brmqf342022figkpv9ogjol2h0i@4ax.com... > Easier to inspect, too, > since you can't inspect them at all. I'm sure you know this, but plenty of places will X-ray BGAs to "inspect" them.Article: 131429
>> Second point : signal switches is an array of std_logic, not an array of >> integers. std_logic litteral constants must be written betwen single quotes: >> if switches(0) = '0' then >> led <= std_logic_vector(led(30 downto 23)); > > Ah - perfect! Adding those quotes just fixed one of my problems! > >> Since cnt is now unsigned, you need to cast it to std_logic_vector >> before assigning to led. >> >> Nicolas > > So is a cast in VHDL just like a cast in C? I must admit this is the > first I've heard of VHDL having that ability. > > Thanks! > > -Michael Yes, my son--you are quickly learning the lameness of VHDL. A number isn't a number--sometimes it must be in single quotes, sometimes in double quotes, and most often expressed in binary, just as the ancients used to write. And almost never can you use a number directly, but must convert it from one arcane type to another. -KevinArticle: 131430
Haile Yu (Harry) wrote: > Dear all, > > I've designed a macro, and put "ring.nmc" file in my project dir. > In my verilog module file, I wrote > ... > ring r1(.en(en),.ro(ro)); > ... > to instantiate ring macro, but failed. > > Any one could give some hint? > > Thank you! If this is a ring oscillator, you may be having problems with the tools stripping away the logic. -KevinArticle: 131431
On Apr 21, 12:42=A0pm, "HT-Lab" <han...@ht-lab.com> wrote: > "KJ" <kkjenni...@sbcglobal.net> wrote in message > > >If I did have to write test vectors I would probably use something to > >generate those test vectors as an output file artifact from a > >simulation run. > > If you look at tools like Mentor's inFact they do exactly that although th= ey > don't create a vector file but an intelligent testbench instead. The input= s > are high-level rules and actions. These high-level rules are compiled into= > testbench graphs which are then use to generate optimised vector sets. > There is a huge difference between specifying high level rules and specifying vectors as the thing that the test creator needs to input. In fact it's hard to imagine a lower level form of rules than vectors. As a general rule, most skilled people are likely to be much more productive working with a higher level of abstraction than with a lower one. > For example to test a UART you write different rules for all the different= > options like word size, parity type, number of stop bits, interrupt > sequence, read/write sequence etc. The compile will then use this info to > generate an optimised vector set that test all valid combinations (not 100= % > sure on this one). I believe this is one step up from writing assertions a= nd > feeding your design with constrained random data. > > This is a trivial example but you can understand that with more rules this= > becomes more and more powerful. From what I understand these tools are ver= y > complex since they not only need to find the smartest set of testvectors b= ut > also handle all the different constraints and constraint solvers is one ar= ea > which is still heavily being researched. > Sounds like a pitch for the Mentor stuff, not Evan's. > I would say kudos to Evan for attempting to develop a product like this an= d > making it freely available to the rest of us, > I agree, I wasn't trying to disparage the effort, just questioning the rationale for creating a tool that requires the user to input vector sets which is a form of test creation popular 20 years ago. KJArticle: 131432
On Apr 21, 1:11=A0pm, Kevin Neilson <kevin_neil...@removethiscomcast.net> wrote: > > Yes, my son--you are quickly learning the lameness of VHDL. =A0A number > isn't a number--sometimes it must be in single quotes, sometimes in > double quotes, and most often expressed in binary, just as the ancients > used to write. =A0And almost never can you use a number directly, but must= > convert it from one arcane type to another. =A0-Kevin- Hide quoted text - > On the first day, the VHDL gods created 'integer', 'natural', etc. and created ways to easily specify such numbers in any base, and saw that it was good...and the VHDL gods said, go forth and use these types for they are of my creation and they are good....but the unbelievers who think every number will potentially be bigger than 32 bits on each and every design that they create and the scallywags that created std_logic_arith refused to use 'integer' and instead used std_logic_vectors to perform arithmetic and then cursed the VHDL language for the numerous type conversions that they themselves brought down upon themselves.... KJArticle: 131433
Joel Koltner wrote: > Hi Joerg, > > "Joerg" <notthisjoergsch@removethispacbell.net> wrote in message > news:PLsOj.7522$GE1.332@nlpi061.nbdc.sbc.com... >> Private companies generally offer zilch in retirement benefits. Those days >> are long gone. > > Actually I think a very significant fraction of companies (at least those > hiring EEs) offer some sort of contribution to 401k plans, sometimes profit > sharing, sometimes stock options, etc... but I concur that the old days of > "company pensions" is pretty much gone. > Mostly it's a mere pittance. And that's ok, I am a strong believer that everyone should pull their own weight. Except disabled people, of course. >> A 70 year old programmer can be better than a 40 year old. > > Absolutely, but if you're an employer it's definitely a legitimate > consideration that starting a bunch of 70-year-olds on a, say, decade-long > "modernization" project is rather riskier than if you toss a few 50- or > 30-year-olds into the mix as well. :-) > True. However, we should embrace the Japanese concept of letting older folks teach the young ones, not lay them off. >> Anyhow, why should retirement checks be based on the last year of service? >> IMHO that's wrong. > > I agree that one year seems too short, but trying to figure out how many years > should be taken into consideration (which is effectively what happens in > private companies if the company is contributing to your 401k) is not going to > be easy either. > Just make it the same as with 401(k), IRA, old style pension funds, social security etc. What counts is what you pay in over your whole career. We can read such stories almost daily, just an example from this morning: http://www.sacbee.com/111/story/876845.html Guess who gets to pay the tab for the agency's legal defense? -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 131434
Hi, There's been a few discussions about this the last couple years, but it seems nothing ended with firm conclusions. What I would like to do is to run DDR2 at 25MHz (DDR50). I understand that to do this I have to turn off the DLL (which can't work at below 125MHz) and that this should work but is not supported. My question is, what happens then? Ie: How do the DQS signals behave during read? Do they turn off, become random, are synchronized with the clock? Is it safe to just read the data a quarter cycle after the clock edge, or is it more complicated than that? I haven't designed an sdram core before, but I'm going to have to do this for this project and have many other, more general questions. If someone knows some good reading material, please let me know. Aleksandr DubinskyArticle: 131435
On Mon, 21 Apr 2008 09:34:32 -0700, Mike Treseler <mike_treseler@comcast.net> wrote: >Maybe the intended audience is those >unmotivated to learn vhdl or verilog. >Sort of a testbench 'wizard' to go with >wizard generated code. Could be, but I hope not. I've noticed a couple of interesting things over the years: - Most EEs aren't programmers; electronic design and programming are two completely different things. Verification is programming; the techniques, tools, and mindset required are different from those required to do electronic design. And yet, bizzarely, we generally expect the same people to use the same language to do both things. The reasons for this are, I think, historical and market-related, and have nothing to do with the abilities (or otherwise) of Verilog and VHDL. - Most EEs don't actually verify their code, mainly for the reason above. I know people who don't verify at all, and others who use waveform displays. You can get away with this in the FPGA world because it's fairly simple (if time-consuming) to fix things, and in the ASIC world because you've got a verification department to find the problems (or you've actually got your personal verification engineer assigned to you; I've been there). Given that lot, the target audience is actually competent EEs who don't have the time or inclination to start writing complex programs in an inappropriate language to test their RTL code. Imagine you've spent a day writing your FSM, or bus interface, or whatever. It gets to 5 o'clock, and your choice is either (a) to go home and spend the next day writing a testbench for it, when you've already forgotten what it does, or (b) spend the next half-hour writing "test vectors" (yes, bad phrase) for it. I know which one I'd go for. There's at least one other target audience. If you can read a spec for someone else's module, then you write vectors for it, even if you know absolutely no VHDL or Verilog. So, next time your intern's got nothing to do, you can get them doing something constructive without having to send them on a training course first. -EvanArticle: 131436
On Mon, 21 Apr 2008 10:37:52 -0700 (PDT), KJ <kkjennings@sbcglobal.net> wrote: >I agree, I wasn't trying to disparage the effort, just questioning the >rationale for creating a tool that requires the user to input vector >sets which is a form of test creation popular 20 years ago. I wouldn't get too carried away by the 'test vector' terminology. When you get down to it, most TBs involve only 3 activities: 1 - generate a set of input data 2 - make sure that the input data gets applied to the DUT at the right time 3 - wait a bit, check that the output data is as expected, repeat That's how the RTL works, so it would be difficult to do it any other way. I call that lot a 'test vector'. It's convenient to put everything in a "[,,] -> [,,]" format, because it's then obvious exactly what expressions have to be evaluated and applied to the DUT, and what exactly the DUT outputs have to be tested against. It's actually a lot more sophisticated than ABEL - all the inputs and outputs can be arbitrary expressions, for example, and there are full C-like control structures, so you get reactive TBs, and all the rest of it. If you'd prefer, they're not actually "test vectors" - they're just groups of input and output expressions, but I couldn't think of a word for that. The great thing (if I do say so myself :)) is that you have to write absolutely no multi-process code to do this. You don't need to know any of the TB-related intricacies of VHDL or Verilog to do this; it's trivial. It's not a magic bullet, as I say on the website. There are basically 2 reasons that you can't use it for all your everyday verification needs: 4 - the real smarts in a TB is generating the input data; ie. step 1 above (I'm ignoring here the additional smarts required for coverage stats collection, temporal assertions, and so on). Currently, your only options in Maia are essentially table- and algorithm-based. I should also have file input before too long. I've already done constrained randomisation for another tool, and that should make its way in at some point in the future. 5 - There's currently no way to add additional behavioural code to talk to your DUT (a complex bus interface fronting a memory, for example). But, again, I've already done this code elsewhere, so it should make its way in at some point. -EvanArticle: 131437
"Joerg" <notthisjoergsch@removethispacbell.net> wrote in message news:Jr5Pj.4650$vF.1890@newssvr21.news.prodigy.net... > Mostly it's a mere pittance. And that's ok, I am a strong believer that > everyone should pull their own weight. I guess it depends on the employer... Do you see anything bad about the old system of pensions (from private companies, ignore the government for the moment)? I see them more as "different" than particularly better or worse. These days you're personally responsible for more of your retirement planning, which has the upside that you can probably do a better job than some company-wide pension programs used to do, but the downside is that those who plan poorly (or not at all) end up needing that much more government assistance once they're retired. > True. However, we should embrace the Japanese concept of letting older folks > teach the young ones, not lay them off. Yes, agreed 100%. > Just make it the same as with 401(k), IRA, old style pension funds, social > security etc. What counts is what you pay in over your whole career. The end result there is that if your employer requires you to move to, e.g., California for the last few years of employment you'll pretty much be forced to then immediately move when you hit retirement. I suppose that isn't particularly awful, since that fact would have been clear when the employer said, "move!" > Guess who gets to pay the tab for the agency's legal defense? Sheesh... screw the taxpyers with retiremend funding and then screw'em again when someone tries to blow the whistle. Nice... ---JoelArticle: 131438
Jim Wu wrote: > On Apr 18, 11:32 pm, b...@hometoolong.inv wrote: >> I used the latest version of MIG to generate pinouts for a Virtex 4 >> DDR2 interface. In addition to all the usual Address, Data, and >> Control I/Os, MIG assigned an I/O pin for a signal called >> SYS_RESET_IN_N. What is the function of this pin? > This is off-topic, but the "_N" probably indicates that this is an active-low signal; I want to know why we still have new designs with active-low signals. Is it 1982? Does the MiG only work on TTL parts? -KevinArticle: 131439
Michael wrote: <snip> > > John - unless I'm missing something here... I think just watching > edges is good enough to deal with any sort of debouncing problems, as > long as only A or B (not both) are bouncing at any given time. <snip> Can you guarantee that the edge will transition fully and stay transitioned for a minimum length of time? While most debounce problems are a true mechanical bounce issue where hard contacts make it difficult to engage and hold a contact instantly, I'm not comfortable enough to say that a bounce will be a hard transition from one logic level to another with microsecond-scale valid levels between bounces. I've always considered the mechanical transition to be undefined enough to make undebounced (I like this word) switches extremely poor for things like clocks. In your case, do you even use those edges as clocks? I thought you had non-clocked combinatorial loops where you had binary counts affected by the edge. If that edge gets undefined, some bits may go one way while other bits go another way in that binary word unless you can guarantee the debounced behavior of those edges. The Gray code based quadrature counter doesn't have problems with bounce. At all. I'd like to make some time to look at your code but I natively code Verilog and I don't have a synthesizer at home. I'll see what I can do. - John_HArticle: 131440
adubinsky457@gmail.com wrote: > Hi, > > There's been a few discussions about this the last couple years, but > it seems nothing ended with firm conclusions. What I would like to do > is to run DDR2 at 25MHz (DDR50). I understand that to do this I have > to turn off the DLL (which can't work at below 125MHz) and that this > should work but is not supported. My question is, what happens then? > > Ie: How do the DQS signals behave during read? Do they turn off, > become random, are synchronized with the clock? Is it safe to just > read the data a quarter cycle after the clock edge, or is it more > complicated than that? I haven't designed an sdram core before, but > I'm going to have to do this for this project and have many other, > more general questions. If someone knows some good reading material, > please let me know. > > Aleksandr Dubinsky You won't find any firm conclusions. As you've probably found out, the datasheets make no statements one way or another about usage when the DLL is disabled. I did some experiments with this for a project that was later aborted. As I recall, I ran DDR (type 1, I think) at 75MHz or so, disabling the DLL. As I recall it worked fine. The main difference just seems to be that you don't have a guaranteed difference between the clock and DQS. If your design doesn't depend on this, then it should work. I think most designs rely on a narrow window where they expect DQS to show up, because the clock speed and copper lengths are fixed. But if you have a design that is flexible enough to allow for any sort of delay, it should work OK. This type of flexibility is difficult, though. There is ambiguity in the DQS edge, because you might not know which edge it is. My design required writing data to the DRAM and then reading it back to determine which DQS edge I was seeing. As you know, though, disabling the DLL carries no guarantees and performance may differ between brands. You could always have a design which runs the IOBs at high speeds (125MHz) but then connects to a memory controller running at a lower rate. I.e., the effective speed would be about the same as a slower single-clock design because you would have gaps between the bursts. But you'd need asynchronous FIFOs. -KevinArticle: 131441
KJ wrote: > > Not to be too much of a slug, but I'm kinda missing the point I think > of this tool.... > > Why would I want to write test vectors (Hint: I don't). Using a > language with control structures is far more concise and easier to > maintain. > ... > > Having flashbacks to generating test vectors in ABEL...something from > 20 years ago. > > KJ That's a good point. I'm always confused when someone asks me if I have "test vectors" for a design. No; I have a testbench. The whole concept of test vectors doesn't even seem to apply for any design with feedback. I'm having flashbacks to testbenches composed of simulator-specific "force" commands. -KevinArticle: 131442
On Apr 21, 4:09 pm, Kevin Neilson <kevin_neil...@removethiscomcast.net> wrote: > Jim Wu wrote: > > On Apr 18, 11:32 pm, b...@hometoolong.inv wrote: > >> I used the latest version of MIG to generate pinouts for a Virtex 4 > >> DDR2 interface. In addition to all the usual Address, Data, and > >> Control I/Os, MIG assigned an I/O pin for a signal called > >> SYS_RESET_IN_N. What is the function of this pin? > > This is off-topic, but the "_N" probably indicates that this is an > active-low signal; I want to know why we still have new designs with > active-low signals. Is it 1982? Does the MiG only work on TTL parts? > -Kevin MIG creates a wrapper for the memory code. You don't need to route the reset input to a pin of the FPGA. Most designs just use a simple startup circuit (a few flip-flops initialized to 1 during config in a shift-register configuration) unless the FPGA needs to wait for some external event to start up.Article: 131443
Hi Hans Thanks for the idea. i contacted them.. but its been 4 weeks since i first contacted them and have had very little sucess...at the time their legacy server was down so the guy in support couldn't do anything.. and he hasn't replied to my emails since... i figured i'd keep trying them and see if i have any luck on here too TimArticle: 131444
On Mon, 21 Apr 2008 10:04:21 -0700, "Joel Koltner" <zapwireDASHgroups@yahoo.com> wrote: >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:coen041brmqf342022figkpv9ogjol2h0i@4ax.com... >> Easier to inspect, too, >> since you can't inspect them at all. > >I'm sure you know this, but plenty of places will X-ray BGAs to "inspect" >them. > Yes, but that's expensive and it's not usually done on a production basis. We do have a video prism thing the lets us peek under the chip, with fair visibility three or maybe four balls in. But we don't routinely use it. The BGAs just work. JohnArticle: 131445
On Mon, 21 Apr 2008 18:56:41 GMT, Joerg <notthisjoergsch@removethispacbell.net> wrote: >Joel Koltner wrote: >> Hi Joerg, >> >> "Joerg" <notthisjoergsch@removethispacbell.net> wrote in message >> news:PLsOj.7522$GE1.332@nlpi061.nbdc.sbc.com... >>> Private companies generally offer zilch in retirement benefits. Those days >>> are long gone. >> >> Actually I think a very significant fraction of companies (at least those >> hiring EEs) offer some sort of contribution to 401k plans, sometimes profit >> sharing, sometimes stock options, etc... but I concur that the old days of >> "company pensions" is pretty much gone. >> > >Mostly it's a mere pittance. And that's ok, I am a strong believer that >everyone should pull their own weight. Except disabled people, of course. My company contributes 15% of employee salaries (including bonuses) to their 401K. It's tax deductable to the company, not taxable to the employees, and makes everybody happy. That's what really matters, after all. But it's not a pension, in that the company has no obligations at all. JohnArticle: 131446
John Larkin wrote: > On Mon, 21 Apr 2008 18:56:41 GMT, Joerg > <notthisjoergsch@removethispacbell.net> wrote: > >> Joel Koltner wrote: >>> Hi Joerg, >>> >>> "Joerg" <notthisjoergsch@removethispacbell.net> wrote in message >>> news:PLsOj.7522$GE1.332@nlpi061.nbdc.sbc.com... >>>> Private companies generally offer zilch in retirement benefits. Those days >>>> are long gone. >>> Actually I think a very significant fraction of companies (at least those >>> hiring EEs) offer some sort of contribution to 401k plans, sometimes profit >>> sharing, sometimes stock options, etc... but I concur that the old days of >>> "company pensions" is pretty much gone. >>> >> Mostly it's a mere pittance. And that's ok, I am a strong believer that >> everyone should pull their own weight. Except disabled people, of course. > > My company contributes 15% of employee salaries (including bonuses) to > their 401K. It's tax deductable to the company, not taxable to the > employees, and makes everybody happy. That's what really matters, > after all. > Yes, but all along I've had the impression that your company does a lot more for emplyee motivation than most others. 15% is huge. > But it's not a pension, in that the company has no obligations at all. > And it shouldn't be. Employees must understand that investing it is their responsibility, not yours. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 131447
Hello, I have a question about instantiating a module in a verilog
testbench. Sometimes the instantiation may have lots of inputs and
output that you may not want to appear in the ModelSim simulation, is
there a way to stimulate particular signals in a module so the
simulation won't include (display) all of the i/o in your design.
Below if my testbench:
//
// Copyright 2006 Mentor Graphics Corporation
//
// All Rights Reserved.
//
// THIS WORK CONTAINS TRADE SECRET AND PROPRIETARY INFORMATION WHICH
IS THE PROPERTY OF
// MENTOR GRAPHICS CORPORATION OR ITS LICENSORS AND IS SUBJECT TO
LICENSE TERMS.
//
`timescale 1ns/1ns
module test_counter;
reg clock_80mhz, fiber_rst;
reg delay_clock;
wire pin_in;
ModelSimTopblock dut ( fib_rx_dv,
fib_rx_er,
fib_rx_clk,
reset_fpga,
clock_80mhz,
fiber_rcv_rdreq,
fiber_go_xmit,
fiber_wrreq,
fiber_rst,
pin_in,
fib_rx_data,
fiber_tx_data,
//------------------------------
fib_tx_en,
fib_tx_er,
fifo_ef_dsp,
dsp_fib_rx_interrupt,
fib_rx_data_led,
fib_tlk_sig_loss,
fib_tx_data_led,
fifo_ef_ctl,
pin_out,
fib_tx_data,
fiber_data_rcvd
);
parameter tON = 15, tOFF = 7;
initial // Clock generator
begin
clock_80mhz = 0;
forever #15 clock_80mhz = !clock_80mhz;
end
always
begin
#tON delay_clock = 0;
#tOFF delay_clock = 1;
end
initial // Test stimulus
begin
fiber_rst = 1;
#5 fiber_rst = 1;
#4 fiber_rst = 0;
end
assign pin_in = delay_clock;
initial
$monitor($stime,, fiber_rst,, clock_80mhz,,, pin_out);
endmodule
When I launch modelsim all of the io signals of the ModelSimTopblock
would be present in the sim. Can I do something like this:
ModelSimTopblock dut ( 0,
fib_rx_er,
0,
0
clock_80mhz,
0,
0
fiber_wrreq,
fiber_rst,
pin_in,
fib_rx_data,
fiber_tx_data,
//------------------------------
0,
0,
0
0,
0,
0,
fib_tx_data_led,
fifo_ef_ctl,
pin_out,
fib_tx_data,
fiber_data_rcvd
);
Here only a few signals would be stimulated and few signals would
appear in the ModelSim simulation window. Is there a way to do this?
thanks,
joe
Article: 131448Michael wrote: > > John - unless I'm missing something here... I think just watching > edges is good enough to deal with any sort of debouncing problems, as > long as only A or B (not both) are bouncing at any given time. > > But either way - right now I really just want to figure out why I > can't get the stupid thing to map properly - and then I will worry > more about dealing with the small things. I just posted the full code, > constraints, and console output on the FPGA4Fun forum: > http://www.fpga4fun.com/forum/viewtopic.php?t=1281 > > Can somebody please look at this? I just am at a complete loss as to > what is wrong - but to you more experienced people the problem will > probably jump right out. > > Thanks! > > -Michael What does your trim report say about the trimmed signals? From your mapper output you posted on FPGA4Fun, "See the trim report for details about why the input signal will become undriven." - John_HArticle: 131449
On Apr 21, 4:34 pm, "jjlind...@hotmail.com" <jjlind...@hotmail.com> wrote: > Hello, I have a question about instantiating a module in a verilog > testbench. Sometimes the instantiation may have lots of inputs and > output that you may not want to appear in the ModelSim simulation, is > there a way to stimulate particular signals in a module so the > simulation won't include (display) all of the i/o in your design. > Below if my testbench: > > // > // Copyright 2006 Mentor Graphics Corporation > // > // All Rights Reserved. > // > // THIS WORK CONTAINS TRADE SECRET AND PROPRIETARY INFORMATION WHICH > IS THE PROPERTY OF > // MENTOR GRAPHICS CORPORATION OR ITS LICENSORS AND IS SUBJECT TO > LICENSE TERMS. > // > `timescale 1ns/1ns > > module test_counter; > > reg clock_80mhz, fiber_rst; > > reg delay_clock; > > wire pin_in; > > ModelSimTopblock dut ( fib_rx_dv, > fib_rx_er, > fib_rx_clk, > reset_fpga, > clock_80mhz, > fiber_rcv_rdreq, > fiber_go_xmit, > fiber_wrreq, > fiber_rst, > pin_in, > fib_rx_data, > fiber_tx_data, > //------------------------------ > fib_tx_en, > fib_tx_er, > fifo_ef_dsp, > dsp_fib_rx_interrupt, > fib_rx_data_led, > fib_tlk_sig_loss, > fib_tx_data_led, > fifo_ef_ctl, > pin_out, > fib_tx_data, > fiber_data_rcvd > ); > > parameter tON = 15, tOFF = 7; > > initial // Clock generator > begin > clock_80mhz = 0; > forever #15 clock_80mhz = !clock_80mhz; > end > > always > begin > #tON delay_clock = 0; > #tOFF delay_clock = 1; > end > > initial // Test stimulus > begin > fiber_rst = 1; > #5 fiber_rst = 1; > #4 fiber_rst = 0; > end > > assign pin_in = delay_clock; > > initial > $monitor($stime,, fiber_rst,, clock_80mhz,,, pin_out); > > endmodule > > When I launch modelsim all of the io signals of the ModelSimTopblock > would be present in the sim. Can I do something like this: > > ModelSimTopblock dut ( 0, > fib_rx_er, > 0, > 0 > clock_80mhz, > 0, > 0 > fiber_wrreq, > fiber_rst, > pin_in, > fib_rx_data, > fiber_tx_data, > //------------------------------ > 0, > 0, > 0 > 0, > 0, > 0, > fib_tx_data_led, > fifo_ef_ctl, > pin_out, > fib_tx_data, > fiber_data_rcvd > ); > Here only a few signals would be stimulated and few signals would > appear in the ModelSim simulation window. Is there a way to do this? > > thanks, > joe Hello again, I tried putting 0 in the instantiation and it gives an error. There must be some way to create a testbench were only a few signals are stated and thereby would create a simulation consisting of only the signals of interest are displayed.
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