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
Hal Murray wrote: > > > Just checking to make sure I understand... > > "corrupted data" means some of the bits were written > by one side and some of the bits were written by the other. Right? > > So this only matters if the RAM is more than 1 bit wide. Yes. One-bit wide is the special case where it doesn't matter if the data is corrupted. If both sides write the same, 1 or 0, it will be fine. If the two sides differ, then the outcome will be either 1 or 0, which is acceptable. So in this particular case, you can ignore all precautions. Peter AlfkeArticle: 28076
Hal Murray wrote: > [Context is making a fast counter to measure the width of a pulse.] > > Could you get an extra half bit of resolution by clocking things > on the other edge of the clock too? > > I think that requires that both the clock-enable (pulse being measured) > and the clock be be routed to 2 CLBs with matching routing delays. > And I suppose you would then build two complete counters and add their values. That gives you the number of rising + the number of falling edges. Should work. Peter AlfkeArticle: 28077
Karl Olsen wrote > > Hi again, > > ds001_3.pdf mentions 500mA startup current for commercial parts, and nothing > for industrial. Is the startup current expected to be larger for industrial > parts in the whole -40°C to 100°C range? No, only when cold. It is a function of die temperature, not of the designated speed grade. > > > Another thing -- I haven't found much info about Spartan2 dynamic power. > The closest is the Virtex power estimator at > http://support.xilinx.com/cgi-bin/powerweb.pl > Can this be used with any accuracy for XC2S15 and XC2S30 designs, if I > select XCV50 in the power estimator? I cannot answer this. Just don't know. Peter AlfkeArticle: 28078
"Martin Heimlicher" <heimlicher@scs.ch> wrote in message news:3a37e67f@news.datacomm.ch... > How do I assure that an externally supplied reset signal connected to some > sort of GSR (global set/reset) net releases all registers simultaneously (in > the same clock cycle) and reliably (no metastability) ? > Martin Heimlicher, Supercomputing Systems AG, Switzerland On a related point, Why should the 'uncritical' resets be coded? The Synthesis/PAR tools know the VHDL code targets FPGA's, and adds the GSR. Post layout simulation of code resulting from un-Reset VHDL works e.g. "alt_en <= NOT alt_en WHEN Rising_Edge(clk);" However most vendors produce 'VHDL Simulators' that in Pre Layout simulation cannot cope with the FPGA's initialisation of registers and the simulation fails. As most designs target FPGA's, the simulators should have a 'PreSimulation Reset' command that can be overturned by code defaults on individual signals if required. The Tools will then simulate the above 'FPGA code' correctly with out having to code the asynchronous GSR reset or the "risky" signal initial values. Andrew InceArticle: 28079
This is a multi-part message in MIME format. --------------5220559A49A0A01D0E1A448A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrew, If you are using tools like Leonardo Specrum, then yes, this tool will duplicate the register for you. (It has certain rules though, such as the FF has to be at the top level) so probably not much use unless you remove the levels of hierarchy using: ungroup <inst> -hierarchy Dave Andrew Ince wrote: > "fred" <x@y.z> wrote in message news:91ptuj$3t5$1@news7.svr.pol.co.uk... > > "David Hawke" <dhawke@xilinx.com> wrote... > > > If you use Map -pr b then the mapper will place the > > registers for the Output Enable in the IOB, this is only the > > case however if there is one source register per pin (eg 32 > > bit bus with single OE register will not be placed in the > > IO). This will give you faster switch-over and make doing > > ZBT interfaces much easier... > > > > > Thank you Dave, the one OE reg per IOB thing is obvious when > > you look at it but I would have missed it - just saved me an > > age in debug time. > > But It is only obvious if you look for ways the tool may fail to work. > > As users we should expect tools to do simple tasks like automatic > duplication. > > Andrew Ince --------------5220559A49A0A01D0E1A448A Content-Type: text/x-vcard; charset=us-ascii; name="dhawke.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Hawke Content-Disposition: attachment; filename="dhawke.vcf" begin:vcard n:Hawke;David Hawke tel;cell:(+44) 778 875 5002 tel;work:(+44) 870 7350 517 x-mozilla-html:TRUE org:<br><img src="http://www.xilinx.com/images/smvirtex.gif" alt="Xilinx"> version:2.1 email;internet:dhawke@xilinx.com title:XILINX Field Applications Engineer adr;quoted-printable:;;Xilinx Northern Europe=0D=0ABenchmark House;203 Brooklands road;Weybridge;; x-mozilla-cpt:;2672 fn:David Hawke end:vcard --------------5220559A49A0A01D0E1A448A--Article: 28080
Jonas Thor wrote: > Why is the "standard" estimation of MTBF a function of only td, f1 and > f2? (td = acceptable extra delay, f1 = clock and f2 = data frequency). > The rise time of the clocks and data signals must matter... or? At > least for external interfaces. > > I don't think so. 1. There is sufficient gain in the input buffer and even some hysteresis to make any input rise time look fast once it reaches the internal flip-flop. 2. What matters is how often the master latch is caught in the process of changing and being "in the middle", exactly at the moment when the clock pulse stops it from being transparent. Then the issue is, how long it takes to fall to one side. The input rise time should be irrelevant. IMHO Peter AlfkeArticle: 28081
This is a multi-part message in MIME format. --------------0F4C2A6B857631C38411B6CA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Pascal C." wrote: > A few things: > > 1. for case 1, we did create a 32-bit registered OE and did PAR with the "-pr b" switch. What tools do you use David? Personnally, I am using Foundation 3.2i.5 (note: I installed SP6 yesterday and MAP crashed pathethically even when started by the GUI!) with FPGA Express 3.4.3. Is it possible that FPGA Express made it impossible for the PAR to recognize the OEs and place them properly (I did prevent it from merging the logic)? > I forgot to mention, the other reason that it may not do this, is if you have the logic sense the wrong way round in the code....(therefore requiring a LUT before the Tri) - Can't remember if it is active high or low to HighZ...Think it is high! Best thing to do it check the schematic viewer in Synopsys and checking whether there is a LUT in the way....If there is correct the code, and this should work... The tools I use is all of them! Spectrum, XST, Synplicity and FPGA Express... > > In case 2, the chips the FPGA is connected to are about an inch away. I believe that the measurement was made with a 1" ground, but I'll have to check up on that (I didn't take the measurement myself). > > I am already setting the DRIVE through the UCF. The problem is that PAR won't do its thing when the drive is below 12 mA... > I don't understand this...Which IO standard are you using? I have always reduced the drive strength on most IO to the point where I have enough speed left to meet constraints... Beware, even with default PAR options you do not necessarily need the full drive. It often makes better of a poor PCB design to do this. Don't forget these are the largest transistors on the die (0.35u) and have plenty of ooommph (you can also make a nice extra GND out of the transistors connected to GND internally and then increase the drive to 24) - basically you just grounded the substrate again.... > > One trick that was recommended to me was to synthesize with a drive of 12 mA (if that's what it takes), then using FPGA Editor to manually modify each of the pins. However there are 91 pins to change, and the prospect isn't too thrilling (it wouldn't matter, except we're not yet in production, and the idea of repeating these steps each time I synthesize isn't too exciting)... > > Thanks for all your help! > > Pascal --------------0F4C2A6B857631C38411B6CA Content-Type: text/x-vcard; charset=us-ascii; name="dhawke.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Hawke Content-Disposition: attachment; filename="dhawke.vcf" begin:vcard n:Hawke;David Hawke tel;cell:(+44) 778 875 5002 tel;work:(+44) 870 7350 517 x-mozilla-html:TRUE org:<br><img src="http://www.xilinx.com/images/smvirtex.gif" alt="Xilinx"> version:2.1 email;internet:dhawke@xilinx.com title:XILINX Field Applications Engineer adr;quoted-printable:;;Xilinx Northern Europe=0D=0ABenchmark House;203 Brooklands road;Weybridge;; x-mozilla-cpt:;2672 fn:David Hawke end:vcard --------------0F4C2A6B857631C38411B6CA--Article: 28082
Virtex-II, to be available very soon, will change the landscape: It has, as a configuration option, an internal triple-DES configuration-bitstream decryptor. That should be a big relief for any designers worrying about the security of their design. Please forgive this commercial message... Peter Alfke, Xilinx Applications ============================================Article: 28083
On Wed, 20 Dec 2000 08:53:05 -0800, Peter Alfke <peter.alfke@xilinx.com> wrote: >Hal Murray wrote: > >> >> >> Just checking to make sure I understand... >> >> "corrupted data" means some of the bits were written >> by one side and some of the bits were written by the other. Right? >> >> So this only matters if the RAM is more than 1 bit wide. > >Yes. One-bit wide is the special case where it doesn't matter if the data is >corrupted. If both sides write the same, 1 or 0, it will be fine. If the two >sides differ, then the outcome will be either 1 or 0, which is acceptable. So >in this particular case, you can ignore all precautions. > >Peter Alfke > Ummmmm, I'm not as sure. I believe that if both sides write a bit at the "same" time, and one writes a '0', and one writes a '1' there is a possibility of a metastable. If the two write clocks are the same clock signal, the delta time between the two will be constant, and the circuit will behave the same way probably all the time: either metastable each time, or one of them always wins, or a zero always wins or a one always wins. If the clocks are asynchronous, then as for all metastable situations, there will be some delta delay (clock vs clock) at which the charge injected into the RAM cell will make it metastable. It may resolve befor the next read, or the read may disturb the cell and resolve the metastable. Philip Freidin Philip Freidin FliptronicsArticle: 28084
Philip Freidin wrote: > > >Yes. One-bit wide is the special case where it doesn't matter if the data is > >corrupted. If both sides write the same, 1 or 0, it will be fine. If the two > >sides differ, then the outcome will be either 1 or 0, which is acceptable. So > >in this particular case, you can ignore all precautions. > > > >Peter Alfke > > > > Ummmmm, I'm not as sure. I believe that if both sides write a bit > at the "same" time, and one writes a '0', and one writes a '1' > there is a possibility of a metastable. If the two write clocks are > the same clock signal, the delta time between the two will be > constant, and the circuit will behave the same way probably > all the time: either metastable each time, or one of them always > wins, or a zero always wins or a one always wins. If the clocks > are asynchronous, then as for all metastable situations, there > will be some delta delay (clock vs clock) at which the charge > injected into the RAM cell will make it metastable. It may resolve > befor the next read, or the read may disturb the cell and resolve > the metastable. This seems to be the season of metastability. Ok, so in the absolute worst case scenario the two conflicting simultaneous writes leave the cell in the metastable condition. Everybody agrees that it cannot stay there very long. I claim that 5 ns is extremely unlikely, 10 ns only once in our lifetime. So, unless you read that same location that you just wrote conflicting information into ( so you really shouldn't care whether it's a 1 or a 0) within a few ns again, everything will be calm and peaceful. Phil and I have been friends ( and colleagues at AMD ) for the past 20 years. We just have this running battle over the practical ( not the philosophical !) aspects of metastability. Let me establish the probabilities by testing Virtex-II in January. Peter Alfke, Xilinx ApplicationssArticle: 28085
Hal Murray wrote: > > Could you get an extra half bit of resolution by clocking things > on the other edge of the clock too? > > I think that requires that both the clock-enable (pulse being measured) > and the clock be be routed to 2 CLBs with matching routing delays. > Come to think of it: Why limit yourself to just two edegs? You can create a bunch of increasingly longer clock delays with perhaps 100 ps granularity, and use all of them. Peter AlfkeArticle: 28086
This is the way I normally describe it: Drive the internal OE signal with an internal 2-input NAND gate. One of its inputs is the same signal driving the output buffer, the other one comes from the input buffer that looks at the output pin we want to drive. If you drive a 0, the NAND output is High, output is active. When you change to driving a 1, the output will first still be below the threshold, so the output driver stays active for a while, giving us a fast rise time. When the output passes through the threshold, the NAND gate output will go Low, 3-stating the output, and leaving it up to the external pull-up resistor to finish the job. Clearly, it is in your interest to make the feedback signal into the NAND gate reasonably slow, not fast! Peter Alfke Kent Orthner wrote: > Nial, > > Something else you *might* consider (I don't know > how fast your clock is, or how fast a rising edge > you need) is using the FPGA to pull up to a 3.3v > level, and then tristating, letting the resistor > pull it up the ret of the way. > > I think this solution comes from Peter Afke, but > I'm not sure. > > The VHDL process to drive your pins would be as > follows, assuming that PIN is of type inout, and > that OUTPUT is the output level that you want. > > process (PIN, OUTPUT) is > begin > if OUTPUT = '0' then > > PIN <= '0'; > > elsif PIN = '0' then -- This is when OUTPUT is '1, > -- but PIN isn't there yet, so > PIN <= '1'; -- you keep driving with the > -- FPGA. > else -- This is when PIN is above the > -- the FPGA's Vih threshold, and > PIN <= 'Z'; -- you let the resistor do the rest > -- of the work. > end if; > end process; > > Disclaimer: I have not done this myself, and I > don't know if it's a particularly good idea to do it > with a clock signal. > > HTH, > Kent. >Article: 28087
Paul Bateson wrote: > Q. Why can't manufactures provide the code for their models........ Micron does. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 28088
sulimma@my-deja.com writes: > In article <3A3FA329.C726271@jetnet.ab.ca>, > Ben Franchuk <bfranchuk@jetnet.ab.ca> wrote: > > Simon Gornall wrote: > > > I'll need to figure out how easy/stable it is when you get rid of > the > > > 24MHz clock. Presumably there's a good reason why they've crippled > it > > > like this Cheaper clock chip? This is after all only the default "good for most users" chip, which can be replaced by "we want max power" users. Also don't forget that the XC2S chips like the XCV have 4 on-chip DLLs which can do f*2 and of which pairs can be cascaded (App note says so). So you can go up to 96MHz with that default Osc. > > This could be for VGA output. One clock does all. > As would a 48 MHz or 96 Mhz or 144 MHz Clock. So they really might > have a problem with the power supply or similar. The post from Burch also mentioned expansion boards. One of these has an VGA connector and 3*4bit DACs on it. That board also has an second 24MHz Osc (and an 3.xxxMHz for the RS 232 on it). So the 24MHz on the main board is not for VGA. Hmmm. Having 24MHz for the VGA board would make reducing inventory positions an further reason for an 24MHz default. Given that Burch seems to be aiming for absolute minimal cost that could be it. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, MysticArticle: 28089
David Hawke wrote: > > "Pascal C." wrote: > > > A few things: > > > > 1. for case 1, we did create a 32-bit registered OE and did PAR with the "-pr b" switch. What tools do you use David? Personnally, I am using Foundation 3.2i.5 (note: I installed SP6 yesterday and MAP crashed pathethically even when started by the GUI!) with FPGA Express 3.4.3. Is it possible that FPGA Express made it impossible for the PAR to recognize the OEs and place them properly (I did prevent it from merging the logic)? > > > > I forgot to mention, the other reason that it may not do this, is if you have the logic sense the wrong way round in the code....(therefore requiring a LUT before the Tri) - Can't remember if it is active high or low to HighZ...Think it is high! David, According to the Virtex 23 May 2000 datasheet, "The output buffer and all of the IOB control signals have independent polarity controls." In fact, a quick peek via FPGA editor shows a four-input mux for the tristate enable. This means that you should be able to write the output enable as either active high or active low, and the synthesis tool should do the right thing. > Best thing to do it check the schematic viewer in Synopsys and checking whether there is a LUT in the way....If there is correct the code, and this should work... Ah, there's the rub. At least for FPGA Express v3.4 and the XC4KXLA family, there's a bug: FPGA Express doesn't know about the polarity-select mux, and if you write your output enable code active high, an inverter in a CLB is put before the IOB's output enable control. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 28090
"Nial Stewart" <nials@sqf.hp.com> wrote in message news:3A3F3339.AC12CB9E@sqf.hp.com... > I'm looking at a problem where we need to drive a > couple of 5V CMOS clock inputs from a SpartanII > 3v output. > > There are data lines being driven from the 3V output, > we can get away with the 'tristate and pull high > for logic high' trick, but I don't want to do this with > the clock signals. The active (rising) edges are > _very_ slow and the risk of double clocking etc > would be too high. > I guess you mean open collector signals have slow rise times (which they usually do). I would suggest using totem pole clock output, series terminate with 50R or so into the input of a 74ACT device (e.g. 74ACT244), then series terminating from that gate to your CMOS clock input. I would also recommend stuffing your data through one of these too. Some of these devices are available in different speed grades, and some even define skew between signals. In my experience series terminating clocks is superior to other forms of clock termination, but I'll leave that can of worms to another thread! > > Space is fairly tight so my immediate thought was > to use an 8 pin soic dual comparator with the -ve > input tied to 1.8V (power plane). > The above devices are available in QSOP and TSSOP, so shouldn't be that much larger once all the discretes are taken into account > My only concern with this is that I think I read a > while ago that comparators shouldn't be used for this > sort of application, I can't remember where I read this > so I can't check if I'm right. It might have been > because of the lask of hysteresis on the input, > but if the -ve input is set to a 'clean' part > of the waveform I don't think we should see > any problems. > > Can anyone think of any drawbacks of using a fast > comparator for this conversion? I wouldn't use comparators for this - even fast ones are much slower than the logic equivalent and it is difficult if not impossible to control skew. I don't know what the impedance on the line would be as it crosses the threshold, but if it does change as Robert suggests then there could be unwanted reflections. I wouldn't take the risk with a clock! Mark.Article: 28091
Probability of metastability depends on your clock rates too. If you are the average Virtex user doing a design between say 20 to 60 MHz, it is not likely to be a real problem in your system considering the probable time to resolve the metastable state, which Peter indicates is very unlikely to be 5-10ns (Peter what parts are we talking about here too, it'll make a difference. I suspect the 2.5v virtex-4 parts will have a higher probability. Anyway, push the clock rate up to where you are pushing the envelope, and think metastability is likely to become a real issue in your system. That said, even if it is not an issue, you still have to be careful when sending more than one signal or to more than one destination when crossing an async clock domain boundary. Metastability is only half the issue. Ya'll be careful out there :-) Peter Alfke wrote: > > Philip Freidin wrote: > > > > > >Yes. One-bit wide is the special case where it doesn't matter if the data is > > >corrupted. If both sides write the same, 1 or 0, it will be fine. If the two > > >sides differ, then the outcome will be either 1 or 0, which is acceptable. So > > >in this particular case, you can ignore all precautions. > > > > > >Peter Alfke > > > > > > > Ummmmm, I'm not as sure. I believe that if both sides write a bit > > at the "same" time, and one writes a '0', and one writes a '1' > > there is a possibility of a metastable. If the two write clocks are > > the same clock signal, the delta time between the two will be > > constant, and the circuit will behave the same way probably > > all the time: either metastable each time, or one of them always > > wins, or a zero always wins or a one always wins. If the clocks > > are asynchronous, then as for all metastable situations, there > > will be some delta delay (clock vs clock) at which the charge > > injected into the RAM cell will make it metastable. It may resolve > > befor the next read, or the read may disturb the cell and resolve > > the metastable. > > This seems to be the season of metastability. > Ok, so in the absolute worst case scenario the two conflicting simultaneous writes > leave the cell in the metastable condition. Everybody agrees that it cannot stay > there very long. I claim that 5 ns is extremely unlikely, 10 ns only once in our > lifetime. So, unless you read that same location that you just wrote conflicting > information into ( so you really shouldn't care whether it's a 1 or a 0) within a > few ns again, everything will be calm and peaceful. > > Phil and I have been friends ( and colleagues at AMD ) for the past 20 years. We > just have this running battle over the practical ( not the philosophical !) > aspects of metastability. Let me establish the probabilities by testing Virtex-II > in January. > > Peter Alfke, Xilinx Applicationss -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 28092
WOrks as long as 1) you can tolerate the ringing that inevitably occurs when the driver shuts off, and 2) it is not a wired or bus like you might have with a processor bus control signal (transfer start in a motorola processor with multiple masters comes to mind). Peter Alfke wrote: > > This is the way I normally describe it: > Drive the internal OE signal with an internal 2-input NAND gate. > One of its inputs is the same signal driving the output buffer, the > other one comes from the input buffer that looks at the output pin > we want to drive. > If you drive a 0, the NAND output is High, output is active. > When you change to driving a 1, the output will first still be below > the threshold, so the output driver stays active for a while, giving > us a fast rise time. > When the output passes through the threshold, the NAND gate output > will go Low, 3-stating the output, and leaving it up to the external > pull-up resistor to finish the job. > Clearly, it is in your interest to make the feedback signal into the > NAND gate reasonably slow, not fast! > > Peter Alfke > > Kent Orthner wrote: > > > Nial, > > > > Something else you *might* consider (I don't know > > how fast your clock is, or how fast a rising edge > > you need) is using the FPGA to pull up to a 3.3v > > level, and then tristating, letting the resistor > > pull it up the ret of the way. > > > > I think this solution comes from Peter Afke, but > > I'm not sure. > > > > The VHDL process to drive your pins would be as > > follows, assuming that PIN is of type inout, and > > that OUTPUT is the output level that you want. > > > > process (PIN, OUTPUT) is > > begin > > if OUTPUT = '0' then > > > > PIN <= '0'; > > > > elsif PIN = '0' then -- This is when OUTPUT is '1, > > -- but PIN isn't there yet, so > > PIN <= '1'; -- you keep driving with the > > -- FPGA. > > else -- This is when PIN is above the > > -- the FPGA's Vih threshold, and > > PIN <= 'Z'; -- you let the resistor do the rest > > -- of the work. > > end if; > > end process; > > > > Disclaimer: I have not done this myself, and I > > don't know if it's a particularly good idea to do it > > with a clock signal. > > > > HTH, > > Kent. > > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 28093
On 19 Dec 2000 08:39:20 GMT, murray@pa.dec.com (Hal Murray) wrote: >Speaking of global-reset, how does GSR work on a Virtex? If I look >with the FPGA Editor, I don't see any place where GSR connects up >to a CLB or IOB. > > If I specify an explicit set/reset term, does that replace what GSR > does or does it get ORed in with GSR? OR'ed in > Is there an extra input on some SR mux that isn't shown? Or does GSR > get wired up outside the CLB on some path that isn't shown? Or am I > just not looking in the right place? My guess is that it's an ASIC test structure, ie. it's under the hood and we don't get to see it. The only concession is that we're allowed to OR in our own FPGA-level signal, at our own risk. BTW, the last time I checked both the Virtex and the 4K data sheets there were no relevant skew timings on GSR. None of the important numbers are documented. This is, IMO, either (1) unnecessary embarassment at how slow it is (it has to be slow, I think, or there would be a large current spike at start-up), or (2) part of a conspiracy to remove user-level GSR connectivity on future software or hardware. > The SR input to a CLB is also used as a write-enable when the LUT > memory is used as a RAM or shift-register. Do the FFs still get > reset by GSR? They always get set/reset by GSR - the SR input is just an optional additional term. EvanArticle: 28094
On Mon, 18 Dec 2000 13:13:58 -0500, "Jamie Sanderson" <jamie@nortelnetworks.com> wrote: >While I distinctly didn't want to start a big argument, I guess it's >inevitable. The "reg" declaration in Verilog has always been a thorn in my >side. To the novice, it implies that it will be a register, typically with a >clock input. Actually, all it means is that the assignment must occur within >an "always" block. Therefore, some regs are "registers", while others are >combinational. Verilog 2000, as you may know, is replacing the term 'register' with 'variable' for exactly this reason. It's before my time, but I suspect that Verilog's original intention was that the register types should be used only for coding real registers, and that the net types were intended for all the combinatorial stuff. It would be interesting to hear from someone who can remember this far back. EvanArticle: 28095
markp wrote: > In my experience series terminating clocks is superior to other forms of > clock termination, but I'll leave that can of worms to another thread! > Series termination is great for signals that go from one source to one destination. Since the drive impdance is adjusted to match the transmission line Z0, a half-amplitude signal travels down the line, is reflected at the unterminated far end to become a full signal "instantaneously", then travels back to the source, where it is swallowed up in the output impedance = Z0. Neat trick. It USES the reflection instead of FIGHTING it. But beware: Never ever (NEVER EVER!) use series termination for a signal that has to travel to multiple destinations. All but the farthest of these destinations will see the half-amplitude signal for some time, which is the worst level possible. Poor noise immunity, double-triggering etc. Ugly stuff. The best way to terminate a clock that drives multiple loads is to have a strong ( low-impedance ) driver, then terminate the farthest end of the clock "snake" with a resistor (=Z0) in series with a capacitor to ground. (RC in SERIES, and this combination used as a parallel termination) Make the RC larger than the transition time, but smaller than the clock High or Low time. 50 Ohm and 100 pF is a proven combination for all but the very fastest clocks. Peter Alfke, Xilinx ApplicationsArticle: 28096
On Mon, 18 Dec 2000 13:41:03 +0100, Javier SERRANO <Javier.Serrano@cern.ch> wrote: >Hi, > >I am looking for an encoder/decoder pair to transmit serial data through >long distances. There will be one emitter and many receivers, and the >system cannot accept more than one nanosecond of jitter among receivers, >that is there can be absolute delay differences from one receiver's >decoder output to another's, but those differences have to be stable to >within one ns. On the other hand, I would not like to buy a commercial >pair of encoder/decoder but rather design my own with an FPGA (I might >have to give support for many years). I assume that to get that kind of >accuracy, I will have to use either an on-chip or an on-board PLL/DLL. >Does someone know where I can get schematics or text-based designs for >simple encoders like Manchester or biphase mark? Any good books or URLs >on the subject? > >Thank you very much. > >Javier An excellent place to start is NatSemi's AN808, 'Long transmission lines and data signal quality': http://www.national.com/an/AN/AN-808.pdf This covers various PCM schemes. If you want to spend money, try Bernard Sklar, Digital Communications, 0-13-211939-0, for starters. He covers PCM in a couple of pages. Xilinx have an app note on Manchester coding, but I don't think it covers the digital PLL, which is the only part of the design which requires any thought. EvanArticle: 28097
Paul Bateson wrote: > > Hi, > > Does anyone have experience with any Samsung SDRAM behavioural models? > I have been simulating the K4s281632b 128Mbit SDRAM model and I get : > > ** Warning: tRASmax: Maximum Row Active Violation at..... > > The strange thing is that the warning occurs during the power up period where > there are no commands sent to the SDRAM. > The warning would make sense if I had activated a row and left it Active for more > than tRASmax (100us). > > The problem is that Samsung only provide ModelSim compiled libraries, so I can > not look at the code to see what is happening. > > Q. Has anyone used this model before? > Q. Is this a bug in the model? > Q. Are any other bugs in this model I should watch out for. > > Q. Why can't manufactures provide the code for their models........ > > Thanks for your time, > Paul The Free Model Foundation provides a VHDL model for the Samsung KM416S4030, which appears to be almost identical, except that it is only 1Mx16x4. http://vhdl.org/fmf/fmf_public_models/ram/ I have found the FMF stuff to be pretty easy to setup and use. > > -- > Paul Bateson > Hardware Systems Division > Silicon & Software Systems > South County Business Park > Leopardstown, Dublin 18, IRELAND > tel: +353-1-207-8913 > fax: +353-1-207-8801 > mailto:paul.bateson@s3group.com > http://www.s3group.com -- My real email is akamail.com@dclark (or something like that).Article: 28098
Yes, I should have said 'series terminating clocks is superior to other forms of clock termination for point to point connections'. This is a subject in its own right, but off topic for this thread so I'll leave it at that! Mark. > Series termination is great for signals that go from one source to one > destination. > Since the drive impdance is adjusted to match the transmission line Z0, a > half-amplitude signal travels down the line, is reflected at the unterminated > far end to become a full signal "instantaneously", then travels back to the > source, where it is swallowed up in the output impedance = Z0. > > Neat trick. It USES the reflection instead of FIGHTING it. > > But beware: Never ever (NEVER EVER!) use series termination for a signal that > has to travel to multiple destinations. All but the farthest of these > destinations will see the half-amplitude signal for some time, which is the > worst level possible. Poor noise immunity, double-triggering etc. Ugly stuff. > > The best way to terminate a clock that drives multiple loads is to have a > strong ( low-impedance ) driver, then terminate the farthest end of the clock > "snake" with a resistor (=Z0) in series with a capacitor to ground. (RC in > SERIES, and this combination used as a parallel termination) > Make the RC larger than the transition time, but smaller than the clock High or > Low time. > 50 Ohm and 100 pF is a proven combination for all but the very fastest clocks. > > Peter Alfke, Xilinx Applications >Article: 28099
> They always get set/reset by GSR - the SR input is just an optional > additional term. Thanks. Is that in the documentation someplace? I don't remember seeing it and it's the sort of detail I think I would remember. > BTW, the last time I checked both the Virtex and the 4K data sheets > there were no relevant skew timings on GSR. None of the important > numbers are documented. Why are you interested in skew? Suppose the skew is 1 ns but the prop time is somewhere between 0 and 20. How do I use GSR if my clock time is 10 ns? My copy of the VirtexE data sheet has some GSR data: GSR to Pad, is on the bottom of the IOB Output Switching, Table 21. There is a similar number a few pages earlier for GSR to IQ on the input side. Yes, similar data for CLBs and RAMs would be helpful. (DS022 v1.6, Aug 2000) -- These are my opinions, not necessarily my employers. I hate spam.
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