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
>This really belongs on comp.lang.verilog, but the topic >has been flogged to death there; and Verilog users on >comp.arch.fpga may find it vaguely relevant. > >On Wed, 06 Jan 2010 21:04:28 -0600, Nicholas Kinar wrote: > >>> What I don't understand is the assignment logic at the top of this >>> always block. Isn't "old_slow_flag" equal to "resync_slow_flag"? > >No, it's not. I carefully and correctly used a nonblocking >assignment <=, causing a delayed update of the target. >Whatever else you do, please get a robust understanding >of the relationship between blocking = and nonblocking <= >assignment before you do anything further with Verilog. > >>To help me better understand this, I've re-written the code: >> >>reg old_slow_flag; >>reg slow_flag; >> >>always @(posedge fast_clock) begin >> >> if (old_slow_flag != slow_flag) begin >> >> old_slow_flag <= slow_flag; >> freeze_register <= source_data; >> >> // Do whatever it takes to indicate that >> // source_data has been consumed, and make >> // the next source_data available no more >> // than 2 fast clocks later >> >> end >> end > >OK, I see what you're saying, but I'm afraid it's >completely wrong. I'm not quite sure how to respond >to this, but as a first try I'll explain why your >code is broken and then show you a slightly different >(and perhaps clearer) way to organize the design I >first offered. > >Error #1: Your model will never start running in >simulation, because both regs initialize to 1'bX >(as do all regs in Verilog) and the comparison > (old_slow_flag != slow_flag) >evaluates to "unknown", because both sides of the >equality are unknown. When if() tests an unknown >condition, it (by definition) takes the "else" >branch; your code has no "else", so the if() >statement will do nothing. Consequently the regs >will remain stuck at X in simulation. By contrast, >synthesis can't handle X values and will give you >the logic you expect; but that's probably wrong >too, because.... > >Error #2: slow_flag is generated in the source >clock domain, and therefore may not have enough >setup and hold time relative to the target clock. >Consequently you could get an input hazard: >the comparator result (old != new), which is used >to enable various flipflops, might be detected >"true" by some of the flops and "false" by others. >That's why I took care to resynchronize it. > >Subsequently you said that the fast clock is known >to be exactly 4x the slow clock; indeed, with a PLL, >you can get the slow clock's edges exactly lined up >with the fast clock's and you don't need to worry >about clock domain crossing at all. That somewhat >changes the goalposts, but my original solution >remains valid even when the two clocks are completely >asynchronous. > >OK< so now let's go back to my example and see >(a) why it's right and (b) how I could recode it >to be a little easier to follow. > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >THIS IS THE BIT THAT YOU REALLY MUST UNDERSTAND. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > always @(posedge fast_clock) begin // line 1 > resync_slow_flag <= slow_flag; // line 2 > old_slow_flag <= resync_slow_flag; // line 3 > if (old_slow_flag != resync_slow_flag) begin // 4 > freeze_register <= source_data; > // Do other related things > end > end > >On line 1, the always block waits for the next clock >edge. So far, so good. >On line 2, we copy the asynchronous signal "slow_flag" >into its resynchronizing register. However, we use <= >nonblocking assignment, which means that the updating of >resync_slow_flag is postponed until all other activity >caused by the clock edge has finished. This postponed >signal update behaviour nicely models the clock-to-output >delay of real flip-flops. In particular, it means that... >On line 3, we copy resync_slow_flag to old_slow_flag. >But the value of resync_slow_flag that we copy HAS NOT YET >BEEN UPDATED by the nonblocking assignment. In other >words, we get the flipflop's value as it was just before >the clock edge. Similarly, on line 4 the values tested >by the if() expression are the values as they were just >before the clock edge. The same would be true if those >values were tested in any other always block triggered by >the same clock event; the value that you read is the value >as it was just before (and also at the moment of) the clock >edge. New values assigned using <= are projected future >values; they will take effect just after the clock edge >and, in particular, AFTER the execution of any always >block that was triggered by the same clock. This is >precisely how you get proper synchronous behaviour in >Verilog RTL code. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >However, some folk (particularly those coming from a >software background, where assignments always update >their targets immediately) find this sort of thing a little >awkward to read. So you can, if you wish, re-code the >always block in a more software-like style provided you >give it some local variables. > > always @(posedge fast_clock) begin : my_resync // 1 > reg resync_slow_flag, old_slow_flag; // 2 > if (old_slow_flag != resync_slow_flag) begin // 3 > freeze_register <= source_data; // 4 > // Do other related things // 5 > end // 6 > old_slow_flag = resync_slow_flag; // 7 > resync_slow_flag = slow_flag; // 8 > end > >By labelling the "begin" on line 1, we are entitled to >declare local variables in the block (line 2). Note that >these variables are STATIC; they are NOT re-initialized >each time the block executes, but instead they hold their >value from its previous execution. >On line 3 we test those variables' values; of course, the >values we get are the values left over from the previous >clock - that's flipflop behaviour. >On lines 7 and 8 we update the variables using blocking >assignment, which takes effect immediately. Consequently >we must respect your original concerns, and reverse the >order of the two assignments so that the updating of >old_slow_flag uses the old, rather than the updated, value >of resync_slow_flag. > >This use of local variables has a number of benefits. We >have hidden the variables resync_* and old_* inside the >begin...end block where they're used, and they are not >(easily) accessible by other code that shouldn't be >concerned with them. We go back to a software-like model >of execution in which local variables update instantly. >However, we MUST continue to use nonblocking assignment >to freeze_reg because it will be read by other blocks >of code, outside this particular always block. Whenever >you write to a variable within a clocked process, and that >variable will be read by any other process, it's essential >to use nonblocking assignment in this way or else you will >get catastrophic race conditions in simulation, and mismatch >between simulation and synthesis behaviour. > >Asks with trepidation..... where did you learn your Verilog, >without finding out about the correct usage of <= ??? >-- >Jonathan Bromley > Hello Jonathan, I have simulated your code, however, I am only capturing every other data beats or the Even Data ( i.e. 0,2,4,6,8,..) the Odd Data beats are lost. My Slow clock is (slow_period >= (2*fast_period) + (2/Fmax)) as an example Fast clock 100Mhz, slow Clock at 48Mhz. The source data are bursts in at the Fast clock frequency. From your solution, it seems the source data are been sampled at slow_flag or at the half of the fast clock rate. This will drop the second beats or Odd data beats ( 1,3,5,7,.. Data Beats) Please clarify, if I am missing something? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145376
On Sun, 07 Feb 2010 07:33:49 -0600, "Al Momen" wrote: >I have simulated your code, however, I am only capturing every other data >beats or the Even Data ( i.e. 0,2,4,6,8,..) the Odd Data beats are lost. > >My Slow clock is (slow_period >= (2*fast_period) + (2/Fmax)) as an example >Fast clock 100Mhz, slow Clock at 48Mhz. The source data are bursts in at >the Fast clock frequency. > >From your solution, it seems the source data are been sampled at slow_flag >or at the half of the fast clock rate. This will drop the second beats or >Odd data beats ( 1,3,5,7,.. Data Beats) >Please clarify, if I am missing something? I'm confused: do you get data on every cycle of the 100MHz clock? If so, then you cannot expect to get every data item across the interface unless you add some buffer storage (FIFO) on the fast, source side. The original question, for which I wrote the specific answer, was about data transfer _with data freeze_; in other words, the source data must be held until the slow, target clock domain has taken it. Clearly you can't do that if you have new data on every cycle of the fast source clock. FIFO storage allows you to buffer up a fast burst and then transfer it slowly while the source is inactive. But that's not what the original question was about. It sounds as though your application needs a full-dress two-clock FIFO. -- Jonathan BromleyArticle: 145377
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > I remember when I first started working with computers I had a > book from our library about ECAP, IBM's Electronic Circuit > Analysis Program. I never saw or used the actual program, > and haven't heard about it since. I wonder where it went... re: http://www.garlic.com/~lynn/2010c.html#71 using an FPGA to emulate a vintage computer no direct knowledge and web search is rather sparse ... a couple IEEE citations: http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F23%2F4335780%2F04335910.pdf%3Farnumber%3D4335910&authDecision=-203 http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F6%2F5218140%2F05218152.pdf%3Farnumber%3D5218152&authDecision=-203 in the aftermath of the troubles of the early 90s ... there was push to move to industry standard tools ... part of which involved transfer of internal tools to chip tool vendors (and some number of the internal chip tools people spending a lot of time with these vendors ... and then some number leaving and joining external vendor). I've mentioned recently porting nearly 60k statement pascal program (that did circuit layout) to other platforms, as part of such a tool transfer. http://www.garlic.com/~lynn/2010b.html#74 Happy DEC-10 Day http://www.garlic.com/~lynn/2010c.html#29 search engine history, was Happy DEC-10 Day in the mid-80s ... internally, there was big push to expand a lot of mainframe manufacturing capacity anticipating the market would double in size by the early 90s. Not particularly "career enhancing" ... I made some observation that computer hardware was becoming increasingly commoditized ... resulting in thinner margins & profits ... which would at least require significantly cutting the number of related employees to stay out of the red. misc. past posts mentioning various (non) "career enhancing": http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer http://www.garlic.com/~lynn/2007f.html#30 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007r.html#6 The history of Structure capabilities http://www.garlic.com/~lynn/2008l.html#23 Memories of ACC, IBM Channels and Mainframe Internet Devices http://www.garlic.com/~lynn/2009c.html#54 THE runs in DOS box? http://www.garlic.com/~lynn/2009p.html#34 big iron mainframe vs. x86 servers http://www.garlic.com/~lynn/2009r.html#49 "Portable" data centers http://www.garlic.com/~lynn/2009r.html#50 "Portable" data centers http://www.garlic.com/~lynn/2009s.html#4 While watching Biography about Bill Gates on CNBC last Night -- 42yrs virtualization experience (since Jan68), online at home since Mar1970Article: 145378
On Feb 7, 12:10=A0am, Al Kossow <a...@bitsavers.org> wrote: > On 2/6/10 3:29 AM, James Dow Allen wrote: > > a National Semiconducter subsidiary once tried to > > emulate an IBM 3033 at full speed using Fairchild 100k parts. > > ... the reason for failure is interesting ... > . > I would be interested in what the reason for failure was. > I assume it wasn't the obvious chip-chip delays using commodity > ICs. I think you mean that chip-chip delays would be too obvious to be interesting. :-) The commodity high-speed ECL chips were almost in the same ballpark as IBM's chips for speed and density, but IBM's packaging was better in various ways. The one difference I found "interesting" and which seemed to be a significant factor in the slowdown was that IBM used smaller circuit boards. Each signal was therefore closer to the backplane, so closer to more chips total; in other words the smaller circuit boards allowed IBM's wiring to take better advantage, in some sense, of the 3rd dimension! I think there were other important factors in that project's failure, but there's no need to start any anti-NatSemi flamefest. :-) James Dow AllenArticle: 145379
Patrick Maupin wrote: > > Very good links! Thanks! > If you get anywhere with this, please post an update! A couple further notes/links: -------------- An old thread on using the Intusoft translator with LTSpice: http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/c4feb68203854343 -------------- Xilinx IBIS Package Models In the past few years, Xilinx has changed the package models for their most recent FPGA families; the original Tline-ahead-of-IBIS-parasitics method, that I had used in that simple LTSpice example, has changed to a lumped model with both coupled and uncoupled package data available. See my posts on the following thread for additional notes and links regarding the changes to package models: http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/3ff729ef8f851707 ( in the really big BGA packages, Lpkg for the single lump approach gets a bit unwieldy for high speed signals; I'd probably break that Lpkg/Cpkg into several smaller lumps ) BrianArticle: 145380
Sean Durkin wrote: > > With ChipScope you can read out the internal configuration status > Note, you can also read the status in Impact 10.1 with: Debug->Read Device Status FWIW another of my favorite Impact 10.1 settings is Edit->Preferences->Configuration Preferences-> Startup Clock->Automatic Correction > > The question is: Why is that? Is it a bug in iMPACT? Does it > stop clocking the configuration logic too soon? If so, why > doesn't this happen on any other boards? > If your normal method of configuration works fine, I wouldn't worry too much about curable JTAG issues like that. I've seen that same sort of problem on a multi-chip V5 DONE cascade with Impact 10.1: http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/2a291d5c38abbd3c And also on a Digilent S3 board when using their JTAG S/W: http://groups.google.com/group/comp.arch.fpga/msg/b06ca9faf716c347 http://groups.google.com/group/comp.arch.fpga/msg/8f9c895ece739c6e ------------- Random debug thoughts: Configuration mode - are the chip mode pins set to JTAG, or another boot mode? - does changing the mode pins to JTAG affect the problem? External DONE timing/levels - what value of pullup do you have on DONE pin? - are you using the "drive DONE" bitgen option? - what does the DONE risetime look like on the board? - have you tried the 'internal done pipe' bitgen option? - what happpens if you lower the JTAG clock rate? - is your DONE LED buffered? ( I've seen some boards with DONE LED hookups that load down the external DONE signal ) BrianArticle: 145381
On 02/06/2010 10:34 AM, Jecel wrote: > I try to keep a reasonably updated list of such projects at > > http://www.merlintec.com:8080/hardware/31 You can add to that list: http://www.abc80.org/~hpa/fpga/ -hpaArticle: 145382
On Feb 6, 2:01=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > In comp.arch.fpga rickman <gnu...@gmail.com> wrote: > (snip) > > > My bad here. =A0I am the one saying that the planes will capacitively > > couple and allow the return current to cross slots in one plane by > > jumping to the other. =A0I got your post mixed up with Symon's post > > where he recommends multiple ground planes stitched together with vias > > rather than capacitively coupled power/ground planes. > > Well, you want it to stay low impedance all the way down to DC. I don't get how this comment relates to the above. > >> (snip, I wrote) > >> I completely agree. ?Well, actually computers are probably about > >> fast enough to do the whole calculation for at least one board trace > >> using the actual geometry. ?With linearity you can compute each one > >> and add them together. ? > >> > Lee has done that. ?One test he made > >> > that really impressed me was to show that a decoupling cap does not > >> > need to be close to a pin to work well. ?If the power and ground pla= ne > >> > are closely spaced, the impedance is very low. ?If you understand > >> > transmission lines, you will know that the current into (or out of) = a > >> > driver into the transmission line is constant until the signal reach= es > >> > the other end and depending on what load it finds, either continues > >> > until the reflection returns to the driver (as in a series terminate= d > >> > line with high impedance load) or keeps flowing as when it reaches t= he > >> > decoupling cap. ? > >> Well, it has the impedance of the transmission line itself. > >> That depends on the inductance and capacitance of the conductors > >> making up the transmission line. ?You can consider a linear > >> transmission line as a sequence of series inductors and parallel > >> capacitors of constant value per unit length. ?Consider the > >> impedance of a finite length open ended transmission line as > >> a function of frequency. ?For some frequencies the impedance will > >> be very low, for others it will be very high. ?This property > >> is used for impedance matching and filtering in RF circuits. > > I am aware of what a transmission line is. =A0That is my point. =A0The > > transmission line of closely spaced planes is a very low impedance > > which supplies current for the full time it takes the impulse to reach > > the cap. =A0So the spacing of the caps is not at all critical contrary > > to what many will tell you. > > I believe, though, that radial transmission lines aren't > discussed much in classes. =A0I hadn't thought of them much until > I was replying to your post. =A0A google search for them brought > up the paper that I tried to reference. =A0I did the search on a > different computer and copied the link by hand. =A0I will try again. The point is that they work very well for power decoupling. The main point in designing them is to keep the spacing between the plates small so that the capacitance is high and the impedance is low. > >> Now, consider the case of a signal going into or out of a supply > >> plane. ?Now instead of the constant inductance and capacitance > >> per unit length you have concentric rings. ?The inductance decreases > >> and the capacitance increase with radial distance. ?In transmission > >> line terms, it is a line with the impedance decreasing with R. > >> Impedance decreases pretty fast, too. ? > >> A quick web search finds a paper that looks interesting on just > >> this problem. ? > >>http://www.waves.utoronto.ca/prof/gleefth/Backup_Old/jpub/6.pdf > >> The paper has much more detail than even I know, and includes > >> comparisons of calculations and actual boards. > > What paper? =A0I get a 404 error, page not found. =A0Still, I don't see > > the problem you seem to be describing. =A0So the impedance drops with > > increasing distance, low impedance in the power supply is a good > > thing, no? =A0Why would it dropping be a bad thing? > > OK, try again. > > =A0 =A0http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/6.pdf I still can't read it. 404 not found error again. > he seems to even include the reflections of other vias, which > seems more than is needed to me, but... > > It looks like the other papers on on slot antenna design, > so he is considering PC board design in slot antenna terms. > > > Lee actually has impedance vs. frequency measurements of power/ground > > planes and it is pretty interesting. =A0They don't do much below 100 MH= z > > or so, but beyond that the impedance is an up/down trace (all > > adequately low) until it finally starts to climb above several GHz. > > IIRC he explained the the sawtooth as having to do with the board > > dimensions. =A0I guess it has something to do with standing waves, but > > it was some four years ago and I don't recall for sure. > > With some bad luck you might get a resonance (standing wave) > where the impedance didn't stay low. Adding caps helps this in a couple of ways. Each size cap has an impedance min at different frequencies, but the fact that they are not high Q and have ESR means they damp out the high peaks from resonance. It appears to work very well in Lee's measurements. > > I do remember that he showed some interesting interactions between the > > plane capacitance and the inductance of the small sized and valued > > decoupling caps. =A0They have a resonance around 100-200 MHz I think, > > which drives the impedance way up at that value. =A0His solution was to > > add other value caps which effectively move that resonance and also > > damp it out to where it is acceptable. =A0I think he showed a board > > where he used a total of three different values of ceramic caps, but > > only a small number of each, to get a very quiet board with a very > > constant power delivery system impedance. =A0When I took the course, I > > understood how to figure it all out, but I have not had a design with > > difficult power decoupling needs, so I have forgotten some of it. > > Good thing I still have the book... somewhere... > > In the old days, it might be that the tolerance kept the resonances > from being too close. =A0The uniformity is so good now that they > will all have resonance too close together. It doesn't matter where the resonance is, the ESR keeps the peaks from being very high and using multiple values makes the result pretty flat or at least adequately low everywhere. > > So the physics of each board is different??? =A0The board Lee > > constructed was a test board. =A0I don't recall what he used for a > > source of the transient, but he had spots for capacitors at a minimum > > of three distances connected to the power/ground planes with optimally > > short runs to the vias. =A0He populated the caps one at a time and > > measured the effectiveness finding that it dropped off barely at all > > at an inch, IIRC and only moderately at a couple or three inches. =A0Th= e > > point is that it is not really needed to put the cap right on top of > > the power pin. =A0A good power/ground plane pair is much more > > important. > > (snip) > > > My point is that this is all theory. =A0Unless you take some > > measurements to verify what you are saying, you can't say it is an > > accurate description of a real board and chip. =A0Also consider that on= e > > via is not a power supply. =A0Vias are used in parallel giving an > > effectively low impedance. > > Hopefully the link is right now. =A0He does both theory and measurement. I'll have to wait until another day. BTW, does he actually relate this to power supply decoupling or is this just a transmission line analysis? RickArticle: 145383
On Feb 6, 7:44=A0pm, Symon <symon_bre...@hotmail.com> wrote: > On 2/6/2010 6:15 PM, rickman wrote: > > >> will increase with frequency. > > > My point is that this is all theory. =A0Unless you take some > > measurements to verify what you are saying, you can't say it is an > > accurate description of a real board and chip. =A0Also consider that on= e > > via is not a power supply. =A0Vias are used in parallel giving an > > effectively low impedance. > > > Rick > > Rick, > Do you measure every resistor you put on a board. Ohm's law is a theory, > after all. > Syms xx I have measured a resistor's value before as well as the voltage and current through it. Then I knew that there was nothing amiss in the circuit that I was not considering in my *theoretical* analysis of the circuit. Do you get the idea or are you still going to just arm chair philosophize your power supply designs? RickArticle: 145384
On Feb 6, 7:37=A0pm, Symon <symon_bre...@hotmail.com> wrote: > On 2/6/2010 5:38 PM, rickman wrote: > > > I keep asking you if you have done any real analysis or measurements > > of what you are stating? > > =A0> > > Well, this was the first time you asked IIRC, but thank you for doing > so. The answer is "For sure". I've used Hyperlynx and Spice on my > boards. I guess you have also, or else you would not be able to post > your opinions without worrying you might giving someone a bum steer. So are you going to share the results of these simulations on the vias you are talking about? > > I am no guru, > > Really? > > =A0> > > > but I was *very* impressed by > > what Lee Ritchey said just because he has full support for just about > > everything he stated in his course (except maybe that the food was > > good at the Chinese restaurant). > > > Rick > > You seem to be _very_ impressed. Almost as impressed as Steve Wier. > > http://www.freelists.org/post/si-list/Lee-Ritcheys-book,4 I don't see anything that is a real criticism of Lee's ideas. He is critiquing the book and most of what he says are negative points are actually editorial in nature. He may not have all the background in his book,, but everything he discussed in class was supported very thoroughly. I actually have not read the book in detail. I use the class handouts more I think. Notice the reviewer's comment, "Chapters 32 - 37 on power distribution issues are very good, with strong analysis, and practical solutions." That is exactly the topic we are covering. Rick BTW, I am not trying to turn this into a pissing contest. If you don't like the way I am discussing this, I am happy to stop.Article: 145385
On Feb 6, 9:13=A0pm, Symon <symon_bre...@hotmail.com> wrote: > On 2/7/2010 1:03 AM, glen herrmannsfeldt wrote: > > > Symon<symon_bre...@hotmail.com> =A0wrote: > > > (snip on bypass capacitors) > > >> What resonance? > > > The limit to the useful frequency range of a capacitor is > > when it reaches resonance with the series (lead, package, etc.) > > inductance. =A0 =A0Graph impedance vs. frequency, when the reactive > > component crosses zero that it resonance. > > > -- glen > > Hi Glen, > Are you sure? Even beyond that frequency the cap is still doing > something, isn't it? > Syms. Yes, it is not so important whether the circuit is in the capacitive or the inductive region. What is important is the impedance. So yes, a capacitor can be an effective decoupling agent beyond its own resonance. But this is a bit different. To be honest, I have not analyzed a circuit like this and I expect it might be a bit more complex than appears at first glance. I expect a proper simulation is in order. RickArticle: 145386
On Feb 7, 9:33=A0pm, Brian Davis <brimda...@aol.com> wrote: > If you get anywhere with this, please post an update! Well, I did a bit of work on how I could do a differential input amp, and between the small signal I wanted to decode, the offset voltage I was probably looking at with using discretes, and the fact I wanted to have controlled hysteresis, I decided to go with an external comparator. Microchip seems to have entered the market in a fairly aggressive way; they hit the performance I need at a much better price point than TI or Linear. I could possibly use the internal receiver on the FPGA without an external amplifier, but since Xilinx doesn't offer spice support and the total market for this particular product probably isn't worth me going in the lab and characterizing parts, I'm not going to do it. On the one hand, I understand Xilinx's perspective, and at one level it's a reasonable one -- they really only want to spend a lot on supporting large customers doing fairly standard stuff. On the other hand, when I go back and re-read a few of the threads here, they do seem a bit gruff about it. For instance, when Steve Austin says that the cost of HyperLynx is less than a single board spin, he's not living in my world. On this project, I'm trying out various things on a board I can plug into a S3A starter kit. Total cost of a spin is a couple of hundred dollars, and lots of board rework can be tried without actually doing a spin, and I don't anticipate any problems that HyperLynx would actually solve for me in any case (especially since I'm not a big customer that Xilinx would give an encrypted model to). Let me put it another way. You can't sell a single Spartan 3A for $5.40 at DigiKey or Avnet Express and expect that everyone who buys a single FPGA will have all the fancy tools, and that nobody who buys a single FPGA will have silly questions. So, while I appreciate the helpful information that Xilinx provides here, I also appreciate the answers that I've seen you and Symon and rickman and countless others give here over the years, and when I go back and read some of the threads, it almost surprises me that some of you guys are still here after some of the unwarranted flaming that you have received. I've been using Xilinx parts for 13 years; been heavily involved in projects which probably bought a total of over $2 million dollars of parts from them, and a) I've never had to respin a board because of any reason, much less SI (because I'm completely anal, and also because I haven't done any really high-speed designs), and b) I've never used anything remotely as complicated as HyperLynx. Steve acts like it's plug and play, but I've looked at stuff like that, and honestly, if you don't do it every day, the cost of ramping up to do it is as bad as the non-trivial license cost. So, although some of us would like to think that the whole purpose of buying an FPGA is to remove as much other stuff from the board as possible, I guess we have to add using any of the analog on the chip in a non-standard way to the long list of things that Xilinx doesn't want us to do. I just wish that we could convince them that it is possible for them to document how things are implemented without them having to support non-sanctioned use of the implementation. Sometimes I think headway is being made (like with the USB cable drivers under Linux), but sometimes it is very frustrating, especially when a feature like the differential receiver looks like it might be able to save me an external 60 cent part, but they don't think it's worthwhile to give me the information that would allow me to make that determination for myself. Anyway, thanks for the information. I'm sure I will refer back to this thread (and some of the previous threads) the next time I care about detailed I/O pin characteristics. Regards, PatArticle: 145387
On Feb 7, 9:33=A0pm, Brian Davis <brimda...@aol.com> wrote: > If you get anywhere with this, please post an update! Well, I did a bit of work on how I could do a differential input amp, and between the small signal I wanted to decode, the offset voltage I was probably looking at with using discretes, and the fact I wanted to have controlled hysteresis, I decided to go with an external comparator. Microchip seems to have entered the market in a fairly aggressive way; they hit the performance I need at a much better price point than TI or Linear. I could possibly use the internal receiver on the FPGA without an external amplifier, but since Xilinx doesn't offer spice support and the total market for this particular product probably isn't worth me going in the lab and characterizing parts, I'm not going to do it. On the one hand, I understand Xilinx's perspective, and at one level it's a reasonable one -- they really only want to spend a lot on supporting large customers doing fairly standard stuff. On the other hand, when I go back and re-read a few of the threads here, they do seem a bit gruff about it. For instance, when Steve Austin says that the cost of HyperLynx is less than a single board spin, he's not living in my world. On this project, I'm trying out various things on a board I can plug into a S3A starter kit. Total cost of a spin is a couple of hundred dollars, and lots of board rework can be tried without actually doing a spin, and I don't anticipate any problems that HyperLynx would actually solve for me in any case (especially since I'm not a big customer that Xilinx would give an encrypted model to). Let me put it another way. You can't sell a single Spartan 3A for $5.40 at DigiKey or Avnet Express and expect that everyone who buys a single FPGA will have all the fancy tools, and that nobody who buys a single FPGA will have silly questions. So, while I appreciate the helpful information that Xilinx provides here, I also appreciate the answers that I've seen you and Symon and rickman and countless others give here over the years, and when I go back and read some of the threads, it almost surprises me that some of you guys are still here after some of the unwarranted flaming that you have received. I've been using Xilinx parts for 13 years; been heavily involved in projects which probably bought a total of over $2 million dollars of parts from them, and a) I've never had to respin a board because of any reason, much less SI (because I'm completely anal, and also because I haven't done any really high-speed designs), and b) I've never used anything remotely as complicated as HyperLynx. Steve acts like it's plug and play, but I've looked at stuff like that, and honestly, if you don't do it every day, the cost of ramping up to do it is as bad as the non-trivial license cost. So, although some of us would like to think that the whole purpose of buying an FPGA is to remove as much other stuff from the board as possible, I guess we have to add using any of the analog on the chip in a non-standard way to the long list of things that Xilinx doesn't want us to do. I just wish that we could convince them that it is possible for them to document how things are implemented without them having to support non-sanctioned use of the implementation. Sometimes I think headway is being made (like with the USB cable drivers under Linux), but sometimes it is very frustrating, especially when a feature like the differential receiver looks like it might be able to save me an external 60 cent part, but they don't think it's worthwhile to give me the information that would allow me to make that determination for myself. Anyway, thanks for the information. I'm sure I will refer back to this thread (and some of the previous threads) the next time I care about detailed I/O pin characteristics. Regards, PatArticle: 145388
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> ? ?http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/6.pdf > I still can't read it. 404 not found error again. OK, try again: http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/ is the index of all his papers. http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/pdf/6.pdf should be the one. http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/pdf/3.pdf also looks like a related paper, and should probably be read first. All seem to be unusual problems involving transmission lines. (snip) > I'll have to wait until another day. BTW, does he actually relate > this to power supply decoupling or is this just a transmission line > analysis? It is specific to power/ground planes on PC boards with vias. -- glenArticle: 145389
(see below) wrote:
> On 05/02/2010 18:19, in article
> badc12c3-cb2b-4ce9-9543-237d60fc22d5@o8g2000vbm.googlegroups.com, "Eric
> Chomko" <pne.chomko@comcast.net> wrote:
>
>> Has anyone created a copy machine of an old system using an FPGA? I
>> was wondering if it would be possible to take an entire SWTPC 6800 and
>> compile the schematics and have it run on an FPGA board.? Wouldn't
>> even have to be the latest Xylinx product, I suspect.
>
> I think such a project would valuable, and perhaps even more valuable if it
> aimed to recreate a machine of the "heroic" era -- a 7094, an Atlas, or a
> KDF9, say. Perhaps even a Stretch.
A KDF9, maybe, but Stretch? You'd have to be seriously masochistic, or
downright insane :-)
Cheers, Mike.
---------------------------------------------------------------
Mike Hore mike_horeREM@OVE.invalid.aapt.net.au
---------------------------------------------------------------
Article: 145390"(see below)" <yaldnif.w@blueyonder.co.uk> wrote in message news:C7921944.13537A%yaldnif.w@blueyonder.co.uk... > On 05/02/2010 18:19, in article > badc12c3-cb2b-4ce9-9543-237d60fc22d5@o8g2000vbm.googlegroups.com, "Eric > Chomko" <pne.chomko@comcast.net> wrote: >> Has anyone created a copy machine of an old system using an FPGA? I >> was wondering if it would be possible to take an entire SWTPC 6800 and >> compile the schematics and have it run on an FPGA board.? Wouldn't >> even have to be the latest Xylinx product, I suspect. > I think such a project would valuable, and perhaps even more valuable if > it > aimed to recreate a machine of the "heroic" era -- a 7094, an Atlas, or a > KDF9, say. Perhaps even a Stretch. > KDF9 had about 20K transistors, a few K logic transformers, and a > comparable > number of diodes; less than 50K devices in total. I imagine this would be > easily accommodated on a modern FPGA. The big question would be whether to > go for functional equivalence, or whether to try to replicate the original > internal structures. If you want funtional equivalence to the KDF-9 instruction set, then get yourself a copy of the Forth language.Article: 145391
For your information A really great tool to generate VHDL or verilog files is here : http://www.easics.be/webtools/crctool On Feb 6, 2:19=A0pm, "dlopez" <d@n_o_s_p_a_m.designgame.ca> wrote: > >>However, the new problem is that I cannot feed in a data message, > followed > >>by the known good CRC, and get 0! This used to work before I added the > >>above logic. =A0 > > >You aren't supposed to get 0. =A0You get some magic constant. > > You are absolutely right. You also need to feed in the 'what used to be t= he > matching CRC' in reverse BYTE order (on top of reversing the bits). > > Now I'd like to understand why it doesn't give 0. This is what is mention= ed > in the 'painless guide to CRC error detection algorithm', line 575.http:/= /www.ross.net/crc/download/crc_v3.txt > > ''At the other end, the receiver can do one of two things: > =A0 =A0a. Separate the message and checksum. Calculate the checksum for > =A0 =A0 =A0 the message (after appending W zeros) and compare the two > =A0 =A0 =A0 checksums. > =A0 =A0b. Checksum the whole lot (without appending zeros) and see if it > =A0 =A0 =A0 comes out as zero!'' > > I thought this was a nice approach since the receiver in the FPGA only > needs to ever compare the CRC output with 0, instead of capturing the kno= wn > CRC (32 flops) and doing a full 32 bit compare. Although now with a magic > constant it's pretty much the same. > > Diego =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.comArticle: 145392
On 6 f=E9v, 19:34, Jecel <je...@merlintec.com> wrote: > I try to keep a reasonably updated list of such projects at > > http://www.merlintec.com:8080/hardware/31 > > -- Jecel You can add those too : http://torlus.com/index.php?2007/12/05/208-oric-in-a-fpga-continued http://torlus.com/index.php?2007/03/19/200-thomson-mo5-in-a-fpga http://torlus.com/index.php?2007/01/31/198-hector-hrx-in-a-fpga Someday, I will set up a dedicated page for all these projects :)Article: 145393
Hello guys, is there any chance to get work a lattice jtag programming cable with xilinx products? I think, JTAG is a common standard, didn't? I've a hw- usbn-2a lattice cable and I want use with xilinx cplds, but the iMAPCT doesn't find the cable. If this is not possible, can anyone suggest a webstore in Europe where I can order a xilinx JTAG cable? The digilent won't ship their programming cables until 15.marc which is totally unacceptable. I've phoned at least a dozen shop, but there is no ship within a month. thank you in advance DavidArticle: 145394
There is very little chance that a Lattice cable will work with Xilinx software. It would be nice if the vendors got together and came up with a way of any cable working with any software. However that is about as likely as a green pig flying past my window. For Xilinx cables in Europe you can buy them from Nuhorizons, Avnet (Silica) and Farnell also have some. We will be offering our own alternative http://www.enterpoint.co.uk/programming_solutions/prog3.html with development board sales within a few weeks. It will still be cheaper option that a standalone Xilinx cable with the of lower end boards that we sell. A few of our products on our shop website are showing this option (preorder) and more will be added over the next few weeks. John Adair Enterpoint Ltd. - Home of Merrick1. The FPGA High Performance Processing Board. On 8 Feb, 09:11, David Fejes <fej...@gmail.com> wrote: > Hello guys, > > is there any chance to get work a lattice jtag programming cable with > xilinx products? I think, JTAG is a common standard, didn't? I've a hw- > usbn-2a lattice cable and I want use with xilinx cplds, but the iMAPCT > doesn't find the cable. > > If this is not possible, can anyone suggest a webstore in Europe where > I can order a xilinx JTAG cable? The digilent won't ship their > programming cables until 15.marc which is totally unacceptable. I've > phoned at least a dozen shop, but there is no ship within a month. > > thank you in advance > DavidArticle: 145395
On 05/02/2010 03:43, TSMGrizzly wrote: >> >> Are there any examples out there of how to route memory chips on a >> bus? I'm kind of new to routing and don't really know what the >> strategy is for this kind of thing. I was thinking about this when >> designing a board to interface to expansion headers on a dev board for >> a first prototype, but I couldn't think of a way to do it with just >> two layers, so I gave each chip its own lines in that case since I had >> plenty of I/O. > > > Now that I think of it, I suppose I could make the bus connection job > a little simpler if I take advantage of the fact that RAM is "random > access," so the address/data line numbers from chip to chip don't > necessarily have to match up. Then the address/data lines could be > connected in whatever order is easiest and cleanest, since on the FPGA > side the data would go in and come out in the desired order either > way. > Would this for any reason be a bad design practice? > > Steve Are you thinking that, for example, pin D0 on one ram device is on the same bus line as pin D3 on the next ram device? That's certainly possible - for static ram, there is no difference between the data lines or most of the address lines (if the ram supports bursting of some sort, then some address lines are specific). However, the easiest way to connect multiple identical ram devices on a pcb is to simply place them close together and carefully aligned - then you can "bus route" between them with a neat pattern of routes straight across. Only the chip select line is handled separately. Mixing the bus numbering is not going to be of any benefit here, and it will make your schematics somewhat more confusing.Article: 145396
On Feb 8, 6:45=A0pm, David Brown <da...@westcontrol.removethisbit.com> wrote: > On 05/02/2010 03:43, TSMGrizzly wrote: > > > > > > >> Are there any examples out there of how to route memory chips on a > >> bus? I'm kind of new to routing and don't really know what the > >> strategy is for this kind of thing. I was thinking about this when > >> designing a board to interface to expansion headers on a dev board for > >> a first prototype, but I couldn't think of a way to do it with just > >> two layers, so I gave each chip its own lines in that case since I had > >> plenty of I/O. > > > Now that I think of it, I suppose I could make the bus connection job > > a little simpler if I take advantage of the fact that RAM is "random > > access," so the address/data line numbers from chip to chip don't > > necessarily have to match up. Then the address/data lines could be > > connected in whatever order is easiest and cleanest, since on the FPGA > > side the data would go in and come out in the desired order either > > way. > > Would this for any reason be a bad design practice? > > > Steve > > Are you thinking that, for example, pin D0 on one ram device is on the > same bus line as pin D3 on the next ram device? =A0That's certainly > possible - for static ram, there is no difference between the data lines > or most of the address lines (if the ram supports bursting of some sort, > then some address lines are specific). > > However, the easiest way to connect multiple identical ram devices on a > pcb is to simply place them close together and carefully aligned - then > you can "bus route" between them with a neat pattern of routes straight > across. =A0Only the chip select line is handled separately. =A0Mixing the > bus numbering is not going to be of any benefit here, and it will make > your schematics somewhat more confusing. Yes, that's what I was kind of thinking. It did occur to me that it would add confusion to the schematics. The devices are 44 pin TSOP-II packages, so I don't think I can squeeze any traces between the pads, so I'm trying to think of two things now.. how to get the traces to both sides of the chip in a tidy way, and how to get the traces to daisy-chained chips (though out of four chips, probably only two, maybe three will share a bus). I think I've come up with a scheme, though it requires a little bit of layer jumping, and the trace lengths will be different for each side of the chip.. I don't suppose it matters much at this low speed though. Looks like this thread has been pretty popular.. got lots of good information to consider! I have to get my first revision done and ordered in about four or five weeks, so it's time to get to work! SteveArticle: 145397
On 08/02/2010 07:46, in article hkofgc$g56$1@news.eternal-september.org, "Mike Hore" <mike_horeREM@OVE.invalid.aapt.net.au> wrote: > (see below) wrote: >> On 05/02/2010 18:19, in article >> badc12c3-cb2b-4ce9-9543-237d60fc22d5@o8g2000vbm.googlegroups.com, "Eric >> Chomko" <pne.chomko@comcast.net> wrote: >> >>> Has anyone created a copy machine of an old system using an FPGA? I >>> was wondering if it would be possible to take an entire SWTPC 6800 and >>> compile the schematics and have it run on an FPGA board.? Wouldn't >>> even have to be the latest Xylinx product, I suspect. >> >> I think such a project would valuable, and perhaps even more valuable if it >> aimed to recreate a machine of the "heroic" era -- a 7094, an Atlas, or a >> KDF9, say. Perhaps even a Stretch. > > A KDF9, maybe, but Stretch? You'd have to be seriously masochistic, or > downright insane :-) Very possibly. 8-) -- Bill Findlay <surname><forename> chez blueyonder.co.ukArticle: 145398
On 08/02/2010 08:19, in article hkohet$u7p$1@news.eternal-september.org, "invalid" <invalid@invalid.invalid> wrote: > "(see below)" <yaldnif.w@blueyonder.co.uk> wrote in message > news:C7921944.13537A%yaldnif.w@blueyonder.co.uk... >> On 05/02/2010 18:19, in article >> badc12c3-cb2b-4ce9-9543-237d60fc22d5@o8g2000vbm.googlegroups.com, "Eric >> Chomko" <pne.chomko@comcast.net> wrote: >>> Has anyone created a copy machine of an old system using an FPGA? I >>> was wondering if it would be possible to take an entire SWTPC 6800 and >>> compile the schematics and have it run on an FPGA board.? Wouldn't >>> even have to be the latest Xylinx product, I suspect. >> I think such a project would valuable, and perhaps even more valuable if it >> aimed to recreate a machine of the "heroic" era -- a 7094, an Atlas, or a >> KDF9, say. Perhaps even a Stretch. >> KDF9 had about 20K transistors, a few K logic transformers, and a comparable >> number of diodes; less than 50K devices in total. I imagine this would be >> easily accommodated on a modern FPGA. The big question would be whether to >> go for functional equivalence, or whether to try to replicate the original >> internal structures. > > If you want funtional equivalence to the KDF-9 instruction set, > then get yourself a copy of the Forth language. While there are strong similarities between KDF9's Usercode assembly language and FORTH, they are by no means functionally equivalent. As it happens, I already have a prototype KDF9 running in my laptop -- but implemented in software, not an FPGA. See: <http://www.findlayw.plus.com/KDF9> -- Bill Findlay <surname><forename> chez blueyonder.co.ukArticle: 145399
On Mon, 8 Feb 2010 01:11:32 -0800 (PST), David Fejes <fejesd@gmail.com> wrote: >Hello guys, > >is there any chance to get work a lattice jtag programming cable with >xilinx products? I think, JTAG is a common standard, didn't? I've a hw- >usbn-2a lattice cable and I want use with xilinx cplds, but the iMAPCT >doesn't find the cable. > >If this is not possible, can anyone suggest a webstore in Europe where >I can order a xilinx JTAG cable? The digilent won't ship their >programming cables until 15.marc which is totally unacceptable. I've >phoned at least a dozen shop, but there is no ship within a month. Not EU but if you're on a deadline: http://www.knjn.com/ShopJTAGcables_USB.html http://www.knjn.com/ShopJTAGcables_Parallel.html On the parallel page they do show a "universal" JTAG that can switch between Altera and Xilinx. -- Rich Webb Norfolk, VA
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