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
Hi - On Thu, 17 Oct 2002 09:46:01 -0700, Peter Alfke <peter@xilinx.com> wrote: > > >Ray Andraka wrote: > >> it would be nice to have an option to significantly slow the edges (even the 2mA drive has some >> pretty fast edges) to help with SI and EMI on those designs where I/O speed needn't be really fast. >> I'm not sure what the implications from a chip design standpoint would be. If this >> capability were available, then leaded packages wouldn't be the issue they are now with fast edges, >> and you'd likely have a whole lot fewer SI cases to deal with. > >Ray, >how slow do you want them to be ? >I just kibitzed in Austin's office, and saw rise and fall times of 6 ns on a "2-mA" output (fast and >slow does not make a large difference at this "speed".) >HyperLynx is really a fantastic tool :-) > >Peter Alfke It is a great tool. But I just tried doing the same thing and got different results. I downloaded the latest Virtex-II IBIS models (9/6/2002) and set up three driver/receiver pairs: 1) LVTTL2F driving 1-foot, 50-ohm trace, single LVTTL2F receiver. 2) LVTTL2S driving 1-foot, 50-ohm trace, single LVTTL2F receiver. 3) LVTTL2F driving extremely short trace, single LVTTL2F receiver. Case (3) looks great: a smooth, monotonic edge with a ~6ns risetime. But if you look carefully at cases (1) and (2), you'll notice that the waveforms at both the driving and receiving ends are a series of tiny stairsteps, with the pedestals roughly the length of the round-trip travel time on the line (somewhat shorter, actually). In other words, the LVTTL2x outputs look like fast-risetime devices with a high output impedance. Fine for a synchronous data or control signal, but disastrous for a clock, at least if you're driving a trace of any length. (Anyone who has tried to distribute CCLK to multiple devices without an external buffer has seen this.) Normally, there's no way I would consider driving a foot-long trace with a 2mA driver, at least not if I'm worried about monotonicity. But it's a good way to distinguish between a truly slow-risetime driver and a fast, high-output-impedance driver. By the way, in my simulation results, there's a significant difference between the F and S drivers, at least at "typical." I think what Ray's suggesting--a truly slow risetime driver--would be useful for driving low-speed signals for long distances to multiple receivers without worrying about termination. Bob PerlmanArticle: 48451
Bob, the staircase just confirms what you and I have known for decades. That's what happens when your output impedance is significantly larger than the line impedance. And we all agree that it would be foolish to drive a foot-long clock line that way. That must absolutely be terminated, either series or parallel. But a non-critical data or control line should still be driven the 2-mA way, to minimize ground-bounce, EMI, crosstalk and other devilish things. Nice to hear from you again... :-) Peter Alfke ========================= Bob Perlman wrote: > Normally, there's no way I would consider driving a foot-long trace > with a 2mA driver, at least not if I'm worried about monotonicity. > But it's a good way to distinguish between a truly slow-risetime > driver and a fast, high-output-impedance driver. > > By the way, in my simulation results, there's a significant > difference between the F and S drivers, at least at "typical." > > I think what Ray's suggesting--a truly slow risetime driver--would be > useful for driving low-speed signals for long distances to multiple > receivers without worrying about termination. > > Bob PerlmanArticle: 48452
"momo" <shimo@atlas.riken.go.jp> wrote in message news:65242e4e.0210170353.7ee1baa9@posting.google.com... > Hi all > > I'm designing LCD Controller using ALTERA Quartus Ver2.1. > I want to assign output FF signal to IOE register by Quartus Ver2.1. > However, I don't know how to assign using this software. You have to make a I/O component embedding in your code COMPONENT altddio_out GENERIC ( width : NATURAL; power_up_high : STRING; intended_device_family : STRING; oe_reg : STRING; extend_oe_disable : STRING ); PORT ( dataout : OUT STD_LOGIC_VECTOR (0 DOWNTO 0); outclock : IN STD_LOGIC ; oe : IN STD_LOGIC ; datain_h : IN STD_LOGIC_VECTOR (0 DOWNTO 0); datain_l : IN STD_LOGIC_VECTOR (0 DOWNTO 0) ); END COMPONENT; Never rely on synthesis tool Same thing goes for Xilinx regards GeorgArticle: 48453
Peter - Ray said he thought that even the 2 mA driver was fast. You said that Hyperlynx showed that it was actually slow (6ns). My point is that the Virtex-II 2mA driver is not a slow driver; it's a fast but weak (high-impedance) driver. There are applications where a truly slow, i.e., risetime-controlled driver would be very useful. For example, driving a long I2C bus clock with an FPGA would be a lot easier if you offered a truly slow driver. If there were a driver that could drive a resistive load with a 6ns risetime, then it could reliably drive, say, an 18-inch, multi-drop I2C clock bus (you'd actually use a slow open-drain driver, but I digress). I'll post more often as soon as I can get 5.1i working with my latest design. Don't wait up ... :-) Bob Perlman Cambrian Design Works On Thu, 17 Oct 2002 13:30:57 -0700, Peter Alfke <peter@xilinx.com> wrote: >Bob, the staircase just confirms what you and I have known for decades. That's what happens when your >output impedance is significantly larger than the line impedance. > >And we all agree that it would be foolish to drive a foot-long clock line that way. That must absolutely >be terminated, either series or parallel. > >But a non-critical data or control line should still be driven the 2-mA way, to minimize ground-bounce, >EMI, crosstalk and other devilish things. > >Nice to hear from you again... :-) >Peter Alfke >========================= > >Bob Perlman wrote: > >> Normally, there's no way I would consider driving a foot-long trace >> with a 2mA driver, at least not if I'm worried about monotonicity. >> But it's a good way to distinguish between a truly slow-risetime >> driver and a fast, high-output-impedance driver. >> >> By the way, in my simulation results, there's a significant >> difference between the F and S drivers, at least at "typical." >> >> I think what Ray's suggesting--a truly slow risetime driver--would be >> useful for driving low-speed signals for long distances to multiple >> receivers without worrying about termination. >> >> Bob PerlmanArticle: 48454
Bert Wibble wrote: > > Interesting point about the Altera pricing. My company has > traditionally always used Xilinx parts - and we have no complaints. > Recently we spoke with Altera, and their pricing was far better than > what Xilinx would offer for an equivalent part. But, typically, we > have no time to invest in changing to an Altera part - so we end up > staying with Xilinx because we know the parts - and pay more for them. > I feel that maybe Xilinx trade on this point of view - and this allows > them to keep their prices high. Thoughts ? Last year I worked with a company who made a point of competing both vendors on every design they started. It actually hurt them a little technically since they could not make use of special features on the chips, but they felt in the long run it was a better way to go because it made the chips cheaper. I won't argue with the idea that you need to use competition to get pricing down. I will guarantee that you can get better pricing out of your vendor if they know you can switch to another. But you have to make this threat believable. If the only thing holding you back is lack of familiarity with the tools, perhaps you could do a new design using an outside consultant or hire someone with experience with the tools? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 48455
Bob, I agree, but being a (good?) applications engineer, I try to find a work-around: How's about an old-fashioned 100 pF capacitor to ground, right at the FPGA pin. That should smoothe out the edge. Not elegant, clutters up the pc-board, but it should work, and anybody can do it today. And the benefits of low ground-bounce, EMI, crosstalk etc. still apply. Peter Alfke ============= Bob Perlman wrote: > Peter - > > Ray said he thought that even the 2 mA driver was fast. You said that > Hyperlynx showed that it was actually slow (6ns). My point is that > the Virtex-II 2mA driver is not a slow driver; it's a fast but weak > (high-impedance) driver. > > There are applications where a truly slow, i.e., risetime-controlled > driver would be very useful. For example, driving a long I2C bus > clock with an FPGA would be a lot easier if you offered a truly slow > driver. If there were a driver that could drive a resistive load with > a 6ns risetime, then it could reliably drive, say, an 18-inch, > multi-drop I2C clock bus (you'd actually use a slow open-drain > driver, but I digress). > > I'll post more often as soon as I can get 5.1i working with my latest > design. Don't wait up ... :-) > > Bob Perlman > Cambrian Design Works > > On Thu, 17 Oct 2002 13:30:57 -0700, Peter Alfke <peter@xilinx.com> > wrote: > > >Bob, the staircase just confirms what you and I have known for decades. That's what happens when your > >output impedance is significantly larger than the line impedance. > > > >And we all agree that it would be foolish to drive a foot-long clock line that way. That must absolutely > >be terminated, either series or parallel. > > > >But a non-critical data or control line should still be driven the 2-mA way, to minimize ground-bounce, > >EMI, crosstalk and other devilish things. > > > >Nice to hear from you again... :-) > >Peter Alfke > >========================= > > > >Bob Perlman wrote: > > > >> Normally, there's no way I would consider driving a foot-long trace > >> with a 2mA driver, at least not if I'm worried about monotonicity. > >> But it's a good way to distinguish between a truly slow-risetime > >> driver and a fast, high-output-impedance driver. > >> > >> By the way, in my simulation results, there's a significant > >> difference between the F and S drivers, at least at "typical." > >> > >> I think what Ray's suggesting--a truly slow risetime driver--would be > >> useful for driving low-speed signals for long distances to multiple > >> receivers without worrying about termination. > >> > >> Bob PerlmanArticle: 48456
> I'm designing LCD Controller using ALTERA Quartus Ver2.1. > I want to assign output FF signal to IOE register by Quartus Ver2.1. > However, I don't know how to assign using this software. There are many ways to do this. The most standard (not the fastest) method is as follows: On the menu, go to Tools->Assignment Organizer, or just hit Alt-O. Then click the "Edit specific entity & node settings for..." selection and click the "..." button on the right side. This will get you into the Node Finder. In the Node Finder, set the filter to "Pins: all", make sure that the "include subentities" option is _NOT_ checked (this will save you time) and click the "Start" button. From the resulting list on the left, select the signals you want to change to an IOFF and click the ">" button so that the signals are copied to the list on the right, and then the "OK" button. This will return you to the Assignment Organizer. The line following "Edit specific entity & node settings for..." will now show you the signal you selected, or, if it was more than one "<multiple signals" or something like that. Now, click on the "+" sign in front of the line saying "Options for Individual Nodes Only", then on "Add a new Assignment". From the list of assignments on the right, select the option "Fast Output register" and set it to "On". Then click "Apply" and "Ok". Then recompile and all _should_ be OK now. If this does not work, just give me a shout. Best regards, BenArticle: 48457
Hello, Thanks for the encouragement, Jerry. That makes feel great. JaaC Jerry Avins <jya@ieee.org> wrote in message news:<3DAEF3AF.4D7DE478@ieee.org>... > Jaime Andres Aranguren Cardona wrote: > > > > Cordial saludo, > > > ... > > Congratulations! I wish you well. > > JerryArticle: 48458
Hi Itaso, > I would like to know if I need any terminator technology for Altera`s > APEX 20KE I/O pins. I have read a lot about this feature for Stratix > devices, but nothing for APEX devices. I think that the terminator > technology will depend on the standard I/O used. For more information > I add that I'm using LVTTL for all the pins. HELP, please! The APEX do not have Termnator Technology or something like that. As Falk Brunner pointed out, bouncing and ringing of signals is strongly dependant on the slew rate. Thus, if you are worried about signal integrity, look at Falk's equation (I'm not 100% sure where he got the figures but it feels ok) and turn on the "Slow Slew rate" option for the I/O's that you feel are at risk. This will add about 1.1ns to the rise and fall time (it's not quite symmetrical) of the signal, thus reducing bounce. It does add to your Tco as well, so make sure that you meet your timing budget for these signals. Best regards, BenArticle: 48459
Neil Franklin wrote: > > rickman <spamgoeshere4@yahoo.com> writes: > > > Neil Franklin wrote: > > > > > > > Yes, you are not an FPGA designer. You are on the fringe and you can > > > > use whatever you want. But this discussion was about the viability of > > > > open source tools and I think you will still find that they will not be > > > > well received by the FPGA design community. > > > > > > For me it is, and has allways been, about making them, and those > > > people I know who intend to use them. It you were labouring under > > > the impression that I intended to take over the market, then you were > > > reading my stuff wrong. > > > > No, but you have been saying that open source tools will become "better" > > than X or A tools. I don't agree that this will ever happen. > > I think we need to define "better" here. You seem to define it as > "supports newest stuff". Open source people define it as "more > flexible, less bugs, less usage restrictions", and also an fairly > difficult[1] to describe "feels right" that open source stuff has. > > [1] one ingredient is that it is user-written and therefore simple > "fits" the way users work better than anything that is specified by > an market research team. Ok, you define "better" that way then it may be better. But I don't know many engineer who use those metrics as their primary tests of a tool. Most of them want the tool to do a good job and to do it on the parts they want to use. > > > > have said that they feel they have to provide support to anyone using > > > > their chips regardless of the tools they are using. > > > > > > Simply point out, that it is not out tool - no support - come back > > > if problem also happens with our official tool. Open source users > > > understand this. > > > > I don't know what this means. > > Translation: "we don't support you, unless you use our tools". I think one of the problems we have is that you don't post in clear complete sentances and thoughts. The above "translation" is clear, but its purpose is not. I assume that you are saying that this is what Xilinx would say to a open source tool user? Xilinx people have posted here that they feel the need to support anyone buying their chips. If a company wants to put 1,000,000 boards out with a Xilinx FPGA and they are having trouble getting a bitstream to work reliably using open source tools, Xilinx isn't going to say "tough". Or at least this is how I understand the postings here on similar topics by Xilinx people. Providing such support will be very tough for Xilinx so they will try to avoid this situation ever happening by not supporting open source tools. > > > > How could anyone make a bitstream compatible > > > > FPGA? Can you explain how they would get around the legal IP issues? > > > > > > As I said: worst case get an license, in absolute worst case by > > > tripping up one of the existing players (if they blankly refuse). IP > > > law can be very interesting in that respect. > > > > > > Also anyone with enough financial interest can actually take an patent > > > to court and have it declared irrelevant on an whole range of issues. > > > It takes time and cost. But if enough profit are waiting, things like > > > that happen. > > > > Where do open source advocates get the financial backing??? > > We were not talking of open source (= software) developers here. We are > talking about an chip (= hardware) vendors. Such tend to have money, a > lot of it. So how do you know that anyone will be making a clone chip anytime in the future? Why do you think that a company could make money by trying to move into a "specialty" market and turning it into a "commodity" market? I certainly see no reason for a company to spend large sums of money to do so. > > to cooperate. But if you don't *have* IP, how will you bargan with > > them? > > Any chip company can buy in IP, until they have enough to make A&X > listen. Just look at how VIA got round Intels P4 signalling patents by > exactly that trick. They can't buy it from X&A! If X&A are using others IP, then they most likely are paying for it already so there is no leverage. I have not heard that the I&V suit is settled. Last I heard they were still in court, so Via has gotten away with nothing. > > > Also you may want to take into account, that Altera managed to > > > survive Xilinxes patents, despite starting when they Xilinx had > > > maximal protection, and with Altera an latecomer. Any new competitor > > > has an easier situation. > > > > > > And an further scenario: assume bit compatible becomes important. > > > Either X or A is the winner in becoming the standard. How long do you > > > think will the other of the 2 look at declining sales, until they > > > clone? And we already know that a patent battle between them 2 ends in > > > stalemate. > > > > I disagree that a newcomer *now* has an easier time of it. Now you have > > not only X to deal with, you have the X&A cartel. > > Whose remaining patents are becoming more and more detail focussed, as > the basic ones are running out. And so easier to circumvent by using > an different implementation. The days when simply an LUT or an PIP was > an new idea and patentable are over. And it would be very difficult to use that different implementation to make a bitstream compatible part. > > They have a vested > > interest in keeping others out. > > Interest yes, but success in doing it? So far, so good! What happened to all the others who have tried? > > > The short conclusion: IP law is in no way the "no chance" you seem to > > > regard it as. In particular when one has got enough money to run > > > through an dedicated battle. > > > > Well, then show us the money :) > > A: the entire sub-discussion was about an potential (= not yet the > case, and possible never the case) situation > > B: if the situation arrives, then the money can be shown. Basically > that demonstration will point to (part of) the profit possible by cloning. You are therefor making claims that you are now saying can not be demonstated. Kinda hard to draw a conclusion. I think you greatly under estimate the difficulty of starting such a business and over estimate the potential rewards. Both will keep any company out of the market for a long time unless they produce parts that are somehow new and don't infringe. > > > > You misunderstand. The did nothing to "help break the license" other > > > > than to use the bitstream that came from an Altera tool. > > > > > > And that is exactly the entire meaning of "help break the license". > > > Offering an service that is auxillary to an crime, without any other > > > legal use for that service. Look up "contributary infringement" if you > > > want an interesting read. I understand the legal concept here very > > > well, having read quite a bit on the Napster/Kazaa/etc cases and the > > > deCSS/2600/websites cases, and the argumentation against them. > > > > But you make a point that has nothing to do with the discussion. We are > > talking about making chips. > > In this sub-discussion (of about 5 subdiscussions in this thread) you > were claiming that Altera broke Clearlogic on an FPGA patent. I was > countering that claim. > > > > You can get around an patent. Altera survived Xilinxes ones. AMD has > > > wrung patents off of Intel, by tripping them over other stuff. Via has > > > stopped Intel attacks by tripping them up. Ask an good IP lawyer about > > > all the possibilities. IP law is not the clear "you lose" that you > > > believe it to be. > > > > > > In fact the very name IP is an error, they are no property, but rather > > > privileges, granted for very specific terms. And many patents do not > > > fit those terms, and only survive because being not challenged, because > > > fighting them is not profitable. Add an good slice of potential profit > > > and the overturning starts. > > > > Who is going to go up against X and A over these patents? Who has this > > money? > > Whoever convinces an investor or managment that there is money to be > made in clones. And no I am not going to try an predict a company name. And that is where we differ. There is very little money in making a "clone" and thereby changing the market to a commodity. All the manufacturers would suffer from this. > > > > Yes, but that is not an FPGA is it? The point is that Altera felt a > > > > threat and used their IP to shut them down. > > > > > > The point is that they only just managed. That IP is not the surefire > > > "end of competition" you seem to regard it as. > > > > You say they "just managed" but Clearpoint was not making FPGAs were > > they? So how is their case relevant? > > It is relevant to show you that FPGA patents are not the all-powerfull > things you presented them as. Again here: annother sub-discussion. > This thread has wandered quite far, even within single posts. And it failed to show that. > > > AFAIK ARMs patent claim was not that strong, they had luck that their > > > opponent was weak or possibly simply not interested (better stuff to > > > do than fight[1]) and caved in. MIPS had a stronger case against a > > > cloner, but their patent is also near/in EOL. > > > > If the ARM case is not strong, then why does everyone including the > > behemoth Intel license rather than "break" the patents? > > Intel did not just re-implement the ARM instruction set, they actually > took over ARM/DEC chip design internals and actual design code (and a > few employees AFAIK). That translated into faster to market for them. > That is what the license was for, and paid from. So in the Intel case it is a good business decision to license the technology from ARM rather than to try to fight them. In the case of Xilinx it is better to fight them than to license the technology or to buy the chips? Why? I think there is little difference. So what about all the dozens of other licensees of the ARM design? Obviously it is not that difficult a design to produce since a college student produced one. None of the licensees have tried to fight ARM over the patent issue rather than pay the license. And then there are dozens if not hundreds of competing CPUs that don't infringe the patents. You like making comparisons between CPUs and FPGAs. Why is it so different in this context? Why would *any* company try to build compatible FPGAs that infringe patents rather than build one that is different and does not? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 48460
Peter Alfke wrote > Bob, I agree, but being a (good?) applications engineer, > I try to find a work-around: > How's about an old-fashioned 100 pF capacitor to ground, > right at the FPGA pin. That should smoothe out the edge. > Not elegant, clutters up the pc-board, but it should work, > and anybody can do it today. > And the benefits of low ground-bounce, EMI, crosstalk etc. > still apply. Peter - since you put your head above the parapet... Would the tiny Philips/Phicomp/... RCB210 resistor/capacitor networks do the job, and be easier to route? The smallest values in my catalog seem to be 22pF/47R. 100pF/47R and 100pF/82R are also listed. Case size is 1608, 10 terminals.Article: 48461
Depends on the configuration. A series resistor of 100 Ohm or thereabouts would be acceptable, but the C must be to ground. Best would be R to the FPGA, C to ground, common point as output. Less good, but probably acceptable would be RC in series to ground, FPGA pin as output. RC in parallel would obviously not work. The idea is that at 2 mA the FPGA output impedance is close to a kilohm. Petert Alfke Tim wrote: > Peter Alfke wrote > > Bob, I agree, but being a (good?) applications engineer, > > I try to find a work-around: > > How's about an old-fashioned 100 pF capacitor to ground, > > right at the FPGA pin. That should smoothe out the edge. > > Not elegant, clutters up the pc-board, but it should work, > > and anybody can do it today. > > And the benefits of low ground-bounce, EMI, crosstalk etc. > > still apply. > > Peter - since you put your head above the parapet... > > Would the tiny Philips/Phicomp/... RCB210 resistor/capacitor > networks do the job, and be easier to route? The smallest > values in my catalog seem to be 22pF/47R. 100pF/47R and > 100pF/82R are also listed. Case size is 1608, 10 terminals.Article: 48462
at www.fpgaarcade.com look in the space invaders code top level by Daniel W, he has a small & neat ps2 decoder (vhdl) /MikeJ "Leon de Boer" <ldeboer@attglobal.net> wrote in message news:3daeeeda_3@news1.prserv.net... > Any suggestions how to make this crappy PS/2 decoder state machine better > appreciated. > > DEFINITIONS OF SIGNALS YOU MIGHT NEED TO KNOW > > P15, P16 are standard input pins of FPGA > in12Mhz is obviously a 12Mhz clock input pin > Reset is active low input pin > > --[ KEYBOARD STATE MACHINE CONTROL SIGNALS ]-- > TYPE key_states is (s0, s1, s2, s3, s4, s5, s6, s7); > SIGNAL keystate: key_states; > > --[ KEYBOARD INPUT CONTROL SIGNALS ]-- > SIGNAL kbparity: STD_LOGIC; > SIGNAL kbinclock: STD_LOGIC; > SIGNAL kbindata: STD_LOGIC; > SIGNAL kbbitcount: INTEGER RANGE 0 to 7; > SIGNAL kbwatchreset: STD_LOGIC; > SIGNAL kbwatchdog: INTEGER RANGE 0 TO 32767; > > --[ KEYBOARD IN FIFO SIGNALS ]-- > SIGNAL keyhead: INTEGER RANGE 0 to (keybufsize-1); > TYPE KeyMem is ARRAY (0 to keybufsize-1) of STD_LOGIC_VECTOR(7 downto 0); > SIGNAL keydata: keymem; > SIGNAL keyintemp: STD_LOGIC_VECTOR (7 downto 0); > > > THE CRAPPY CODE > > -------------------------------------------------------------------------- - > -- KEYBOARD HANDLER PROCESS > -------------------------------------------------------------------------- - > keyboard_handler: PROCESS (reset, in12mhz, keystate, keyhead, p15, p16, > kbinclock, kbindata, keyintemp) > BEGIN > IF (reset = '0') THEN -- reset is active > OR (kbwatchreset = '0') THEN -- watchdog has kicked in > keystate <= s0; -- start on state 0 > IF (reset = '0') THEN -- only on reset > keyhead <= 0; -- zero keyboard head > END IF; > kbwatchreset <= '1'; -- watch dog reset high > kbwatchdog <= 0; -- zero watchdog count > kbinclock <= '1'; -- set kbinclock to '1' > kbindata <= '1'; -- set kbindata to '1' > ELSIF rising_edge(in12mhz) THEN -- clock signal edge > kbinclock <= p15; -- latch keyboard clock > kbindata <= p16; -- latch keyboard data > kbwatchreset <= '1'; -- preset watchdog reset > high > IF (kbwatchdog = 32000) THEN -- watch dog has timed out > kbwatchreset <= '1'; -- set watchdog reset signal > ELSE > IF (keystate = s0) THEN -- in state s0 it is stable > kbwatchdog <= 0; -- watchdog never counts > ELSE > kbwatchdog <= kbwatchdog + 1; -- inc watchdog count > END IF; > END IF; > CASE keystate IS > WHEN s0 => -- find clock edge low > keystate <= s0; -- preset stay on this > state > IF (kbinclock = '0') THEN -- falling clock edge > keystate <= s1; -- move to next state > END IF; > WHEN s1 => -- find clock edge high > keystate <= s1; -- preset stay on this > state > kbparity <= '0'; -- clear parity check > kbbitcount <= 0; -- zero bit count > IF (kbinclock = '1') THEN -- clock is now high > keystate <= s0; -- preset error back to s0 > IF (kbindata = '0') THEN -- start bit was found > keystate <= s2; -- move to next state > END IF; > END IF; > WHEN s2 => -- find clock edge low > keystate <= s2; -- preset stay on this > state > IF (kbinclock = '0') THEN -- falling clock edge > keystate <= s3; -- move to next state > END IF; > WHEN s3 => -- find clock edge high > keystate <= s3; -- preset stay on this > state > IF (kbinclock = '1') THEN -- clock has gone high > keyintemp(kbbitcount) <= kbindata; -- hold data bit > kbparity <= kbparity XOR kbindata; -- add to parity > IF (kbbitcount = 7) THEN -- 8 bits loaded now > keystate <= s4; -- move to next state > ELSE > kbbitcount <= kbbitcount + 1; -- inc bit in count > keystate <= s2; -- back to wait clock low > END IF; > END IF; > WHEN s4 => -- find clock edge low > keystate <= s4; -- preset stay on this > state > IF (kbinclock = '0') THEN -- falling clock edge > keystate <= s5; -- move to next state > END IF; > WHEN s5 => -- find clock edge high > keystate <= s5; -- preset stay on this > state > IF (kbinclock = '1') THEN -- clock has gone high > kbparity <= kbparity XOR kbindata; -- create parity check > keystate <= s6; -- move to next state > END IF; > WHEN s6 => -- find clock edge low > keystate <= s6; -- preset stay on this > state > IF (kbinclock = '0') THEN -- falling clock edge > keystate <= s7; -- move to next state > END IF; > WHEN s7 => -- find clock edge high > keystate <= s7; -- preset stay on this > state > keydata(keyhead) <= keyintemp; -- store data to key buffer > IF (kbinclock = '1') THEN -- clock has gone high > IF (kbparity = '1') THEN -- parity correct > IF (keyhead=(keybufsize-1)) THEN -- at buffer end > keyhead <= 0; -- roll back to buffer > start > ELSE > keyhead <= keyhead + 1; -- advance buffer position > END IF; > END IF; > keystate <= s0; -- move to start state > END IF; > END CASE; > END IF; > END PROCESS keyboard_handler; > > > >Article: 48463
More importantly you can play pacman and space invaders in a 300e (ok, external program rom required) ! MikeJ "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message news:aomr61$1esa$1@agate.berkeley.edu... > In article <aomqje$nr2og$2@ID-84877.news.dfncis.de>, > Falk Brunner <Falk.Brunner@gmx.de> wrote: > >Nowadays, Iwouldnt recommend anythink below 200k. Get a nice Spartan-II(E) > >with 200 or even 300k gates. > >They are cheap. > > > >www.nuhorizons.com (200k) > >www.burched.com (300k) > > > >The tools from Xilinx are free. Go for Webpack. > > Not only that, but consider the following: > > In a Spartan 2-100, you can do 1.3 Gbps AES encryption. In a $10 > part. About 1.7 Gbps in an E. > > In a Spartan 2-200, you can probably build a 70-80MHz, 2 thread, MIPS > or SPARC compatable processor. Probably >100 MHz in an E. > > In a Virtex 400, you can dump a SYNTHESIZED, GPL'ed SPARC core. > > Those cheap parts (Spartan II/IIE) are big and powerful, as well as > cheap. > > (I not very wistfully remember doing a sample-based MIDI synthesizer > in a 4005 as a class project. It ALMOST fit in a 4003.) > -- > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 48464
I commend your use of x's for the sake of readable code but unfortunately you're pushing the limits of the free-bee synthesizer packaged with Quartus. What you desire will work fine with the more seasoned synthesizers but if you're targeting the built in Quartus synthesizer your code better look like a section from Verilog 101 and run a gate lavel sim following to verify correct translation. Regards "Brian Guralnick" <innerdimension@videotron.ca> wrote in message news:<EnMp9.9726$dE6.209743@weber.videotron.net>... > The 'x' was a habit gained from the AHDL language. When I started with verilog a few months back, I figured it might work. In > Quartus2.0 and earlier, it did work. It was very handy in creating a bus decoder with different pages. > > eg: > > parameter adr_range = "16b'1x000000xxxxxxxx'"; > OLD: > ...... > if (adr_in == adr_range) ena <= 1; > else ena <= 0; > ...... > > new: > ...... > if ( (adr_in[15] == 1) && (adr_in[13:8] == 0) ) ena <= 1; > > else ena <= 0; > ...... > > The problem here is that I can not use the parameter, unless there is a proper way to do the compare within Verilog. > > > > ____________ > Brian Guralnick > innerdimension@hotmail.com > (514) 624-4003 > > > "Blackie Beard" <BlackBeard@FearlessImmortalWretch.com> wrote in message news:YbLp9.3453$qb.2015@nwrddc01.gnilink.net... > > I'm not convinced that Verilog will let you use 'x' as a don't care. > > I do know that 'x' from a simulation result found on a wire is not > > a don't care, but an error (no signal driven, or contention) > > > > > > "Brian Guralnick" <innerdimension@videotron.ca> wrote in message > > news:KSKp9.9423$dE6.195978@weber.videotron.net... > > > So, if I understand you correctly, you want Quartus to see the results > coming in from externally connected ram & you want that ram > > > to be functional. > > > > > > It would seem that the contents of the Verilog SRAM model should behave as > your SRam. Though I'm getting fairly good at verilog > > > programming, I still have to learn how to use the simulation models. If > you contacted Altera, you'll probably get the answer to do > > > everything in verilog & use Leonardo Spectrum for simulation. > > > > > > > > > My all in Quartus solution would be something like this: > > > > > > Make a second dummy Quartus project which emulates your SRAM using > standard RAM_DQ. Create a symbol for that project. Now, in your > > > main project's simulation block diagram, place the SRAM projects > > > > > > I have successfully done this for 8 megabit sram. It worked fine for > functional simulation, but, in timing mode, everything messed > > > up. > > > > > > > > > Warning: If you use Quartus to compile your *.v files, changing from Q2.0 > to Q2.1 can mess up a whole lot of things... > > > My recent finds are: > > > ---> if (adr[7:0] == 8'b1000xxxx') begin... > > > The don't cares 'x' no longer work, and they don't work even with the > '===' when they should, Quartus2.1 will simplify out this 'if' > > > block to do nothing. > > > ---> notadr[7:0] <= !adr[7:0]; > > > This also used to work, now, it also does something funny. > > > > > > ____________ > > > Brian Guralnick > > > innerdimension@hotmail.com > > > (514) 624-4003 > > > > > > > > > "Paul Baxter" <pauljnospambaxter@hotnospammail.com> wrote in message > news:3da72d0e$0$1291$cc9e4d1f@news.dial.pipex.com... > > > > > > > > "Engineer" <victor1357@hotmail.com> wrote in message > > > > news:b041a362.0210111058.742f72e0@posting.google.com... > > > > > Hi all, > > > > > I am trying to develop a SRAM controller using Quartus 2.1 from > > > > > Altera. The design contains a controller and also a Verilog file with > > > > > SRAM model (which I need for simulation and other kinds of > > > > > verifications). > > > > > The question is: how to separate controller files from SRAM files in a > > > > > design, so that Quartus doesn't put SRAM together with controller on a > > > > > chip. > > > > > Unfortunately, I was not able to achieve this so far. > > > > > Any comments appreciated. > > > > > ======================== > > > > > Victor Ober > > > > > Transtech > > > > > > > > The big problem you'll probably run into is that Quartus is a > synthesis-only > > > > simulator so quite often models of RAMs etc simply do not work in > Quartus. > > > > > > > > What you're describing is having the main design synthesised and placed > to > > > > provide a full timing-correct 'model of your device under test. A > simulation > > > > testbench then models the connections of your DUT with the SRAM for > > > > simulation. > > > > > > > > Altera does provide a limited edition Modelsim license in the full > version > > > > which CAN do this sort of thing. Personally I found ActiveHDL a far > easier > > > > and comprehensive simulator but this unfortunately costs more money > (similar > > > > to a purchase of the full Modelsim license) > > > > > > > > I really would recommend downloading the ActiveHDL trial (www.aldec.com) > as > > > > it also has comprehensive help files explain just such a setup. > > > > > > > > Good luck > > > > > > > > Paul Baxter > > > > > > > > > > > > > > > > > >Article: 48465
>I have not heard of this threading concept before, but it makes sense at >a hardware level. I am not sure I understand the software >implications. It seems to me that the multiple instruction streams must >be completely independant and infact, you must have a separate PC for >each stream, no? So how do you run something like this? I guess there >must be instructions for starting and stopping each separate thread in >the processor. Or do all the threads start following reset??? How >would the OS manage that? It's just like SMP. The hardware is time interleaved rather than replicated. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 48466
Peter Alfke wrote > Depends on the configuration. A series resistor of 100 Ohm or > thereabouts would be acceptable, but the C must be to ground. > Best would be R to the FPGA, C to ground, common point as output. > Less good, but probably acceptable would be RC in series to ground, > FPGA pin as output. > RC in parallel would obviously not work. > The idea is that at 2 mA the FPGA output impedance is close to a kilohm. > <snip> > > Would the tiny Philips/Phicomp/... RCB210 resistor/capacitor > > networks do the job, and be easier to route? The smallest > > values in my catalog seem to be 22pF/47R. 100pF/47R and > > 100pF/82R are also listed. Case size is 1608, 10 terminals. > That is the way it works. The Rs look like a standard 8-pin RP, with caps in series from the output terminals to common ground terminals on the short edges.Article: 48467
Hal Murray wrote: > > >I have not heard of this threading concept before, but it makes sense at > >a hardware level. I am not sure I understand the software > >implications. It seems to me that the multiple instruction streams must > >be completely independant and infact, you must have a separate PC for > >each stream, no? So how do you run something like this? I guess there > >must be instructions for starting and stopping each separate thread in > >the processor. Or do all the threads start following reset??? How > >would the OS manage that? > > It's just like SMP. The hardware is time interleaved rather than replicated. Yes, I understand that. But when you replicate the hardware, you replicate *all* of the hardware. I have not heard anyone say that there are multiple copies of the program counter (PC). If you are working off one PC how do you switch between the threads on a clock cycle basis? Additionally, how do you start up a thread? When this multiple thread CPU starts following reset, each of the threads will need to be running *something*. How is that managed? Do they all boot the BIOS or whatever startup code you have? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 48468
Hi, Is it possible to use the JTAG port on an FPGA (Spartan IIE) for debugging with Xilinx Webpack? Is the cable expensive? I would like to use the JTAG port to act as a logic analyzer on the FPGA I/O's. What is the peak frequency the JTAG port would be useful for this? cheers, Jamie MorkenArticle: 48469
hi i am new to FPGAs. i want to run compression algorithms on virtex xcv50 configuration file. i have consulted the xilinx app. notes as well as other few websites. The xilinx website says the configuration bits needed are 559,200bits (= 69,900 bytes) but at fpgaconfigurator.com, it is mentioned tht 559,232 bits are needed. The bit file generated by Xilinx tools has the size 69,967 bytes which is 67 bytes more than specified by xilinx. I am really confused about what's going on ?? moeover from what i understand, xcv50 needs 15,876 32-bit words for CLBs, 780*2 for ram and 39 words for issuing commands. The sum of all these is less than the number of configuration bits required (559,232), So, how exactly is this figure calculated ?? MeghnaArticle: 48470
The xilinx app note: xapp253 ( DDR SDRAM controller using Virtex II) talks about using HEX lines for low skew routing. Here is the snippet from the app note. "As described in the Virtex-II data sheet, each I/O tile contains four IOBs that share a switchmatrix.IOB PAD4 is the top IOB in a I/O tile. In order for the DQS to access a local low-skew clock line, DQS must be placed on the top IOB, PAD4 in the I/O tile. If IOB PAD4 is not available in a tile, or is unbonded, then it cannot be used to place the DQS signal. Placing the DQS signal in PAD4 gives access to a local clock line which is a HEX line spanning five rows above the chosen I/O tile and six rows below the chosen I/O tile. The data (DQ) pads should be placed in the bonded IOBs available within these specific rows." Question is 1) How does one locate the "IOB pad4: top IOB of an I/O tile" ? 2) We know that 4 adjacent IOB's share the routing resources. How do we know which four? Virtex II data sheets and hand book mention this but do not give any info on how to locate them . So where will I find this info. Thanks Brijesh brijesh at vt dot eduArticle: 48471
Christopher Cole <cole@scoob.coledd.com> writes: > Actually, XScale is Intel's own IP. Intel created the XScale core via > clean-room approach, licensing only the instruction set from ARM Ltd. > The Intel StrongARM processor, on the other hand, uses an ARM core > developed by ARM Ltd. Actually the StrongARM core was designed by the late, lamented Digital Equipment Corporation (DEC).Article: 48472
I am a student at SJSU working on my senior project. For this, I will be creating an FPGA using Xilinx software, but I am really overwhelmed with the ammount of information on how I can actually do this. Can anyone direct me to some good documentation on creating FPGA's when I have the verilog/VHDL code? thanks! kyleArticle: 48473
The PC just needs to have more than one register in its feedback. The SRL16's are
great for this. We do this type of thing all the time with counters in our designs
so that one increment logic and an SRL 16 make up a set of time multiplexed
counters all on a common path. The trick is to be careful that all the loops are
pipelined to the correct level. You can reset one counter without resetting the
rest, branch on each one independently etc.
rickman wrote:
> Yes, I understand that. But when you replicate the hardware, you
> replicate *all* of the hardware. I have not heard anyone say that there
> are multiple copies of the program counter (PC). If you are working off
> one PC how do you switch between the threads on a clock cycle basis?
> Additionally, how do you start up a thread? When this multiple thread
> CPU starts following reset, each of the threads will need to be running
> *something*. How is that managed? Do they all boot the BIOS or
> whatever startup code you have?
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design URL http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 48474Brijesh wrote: > The xilinx app note: xapp253 ( DDR SDRAM controller using Virtex II) talks about using HEX lines for low skew routing. Here is the snippet from the app note. > > "As described in the Virtex-II data sheet, each I/O tile contains four IOBs that share a switchmatrix.IOB PAD4 is the top IOB in a I/O tile. In order for the DQS to access a local low-skew clock line, DQS must be placed on the top IOB, PAD4 in the I/O tile. If IOB PAD4 is not available in a tile, or is unbonded, then it cannot be used to place the DQS signal. > > Placing the DQS signal in PAD4 gives access to a local clock line which is a HEX line spanning > five rows above the chosen I/O tile and six rows below the chosen I/O tile. The data (DQ) pads > should be placed in the bonded IOBs available within these specific rows." > > Question is > 1) How does one locate the "IOB pad4: top IOB of an I/O tile" ? FPGA Editor. The app note gives information on how to use it to find the subset of pads that can be DQS pins > 2) We know that 4 adjacent IOB's share the routing resources. Word of warning. Remember that some IOBs are unbonded, so there may be only two bonded IOBs that share routing resources. And remember that the routing of clocks for DDR is shared between pairs of IOBs even more closely. These pairs are easy to identify: the name in the pinout tables shows pairs, for example: IO_L06N_0 IO_L06P_0. > How do we know which four? FPGA Editor. > Virtex II data sheets and hand book mention this but do not give any info on how to locate them . > So where will I find this info. If you find a better source, please post it. -- Phil Hays
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