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
Hello, We are trying to migrate a fully functional project from Xilinx ISE v7.1 to Xilinx ISE v11.1. We started off by creating a new project under v11.1 and bringing over all the .v (verilog source) files, .ise file, .xco files and ucf file. The project synthesizes successfully, however when trying to Implement design, translate fails with several of the following errors (a) NgdBuild 924: input pad net '....' is driving non-buffer primitives (b) NgdBuild 455: logical net '....' has multiple drivers (c) NgdBuild 462: input pad net '....' drives multiple buffers (d) NgdBuild 809: output pad net'....' has an illegal load Has anyone encountered these errors in the past while migrating from an older version of Xilinx ISE to v11.1 ? Why are these caused and how do we get rid off these errors ? Thanks in advance for your help, Regards. Vikram. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146876
On 3/30/2010 9:41 PM, austin wrote: > Peak to peak, > > Austin Hi Austin, Right, but is that from one cycle to the next? Or from one cycle to infinity? Or beyond? My Trimble GPS box (it's a nice brushed aluminium can, anodised a lovely gold colour!) gives me a signal, which it is claimed has 50ns of jitter. That's all the spec. I get. One pulse per second comes out of this bugger. Should I worry? Is 50ns "a lot"? Syms!Article: 146877
On Mar 30, 7:24=A0pm, Symon <symon_bre...@hotmail.com> wrote: > Right, but is that from one cycle to the next? Or from one cycle to > infinity? Or beyond? > > My Trimble GPS box (it's a nice brushed aluminium can, anodised a lovely > gold colour!) gives me a signal, which it is claimed has 50ns of jitter. > That's all the spec. I get. One pulse per second comes out of this > bugger. Should I worry? Is 50ns "a lot"? Heh. Reminds me of a few years ago, when I was pressed into service to torture (I believe "verify" is the correct word, but whenever someone wants me to test something, they're kidding themselves if they think I'm anything other than a pit bull. Maybe that's why they usually just have me writing high level system specs and designing emulation platforms. But I digress...) a USB 2.0 high speed receiver. I thought the USB definition of jitter for high speed was crystal clear -- just stack up 480 bit times worth of data vertically and see if the template was ever violated. But, it turns out that a designer dedicated to proving himself "right" can find something to disagree about even there. He decided that (since my test case that really put his design into a tailspin was not running at exactly the nominal 480 Mb/s) the 480 bit times you were stacking had to be at exactly 480 Mb/ s, and not at the nominal transmit frequency. This let him "prove" that I was exceeding the jitter tolerance, by adding drift and jitter together to show that the signal was outside the specified template! I showed him (well, tried to show him) that, if you used his wacky definition, then if you took a signal that was transmitted at the edge of the specified frequency margin, and stacked up 480 of those bit times using nominal rather than transmitted period, you would violate the template EVEN WITH ZERO JITTER, so that couldn't be what they mean, right? I never convinced him of that, but the management understood. I also never convinced him that when his uber-fancy data recovery lost lock and just started spewing garbage (which it did in a rather spectacular way when it got lost, not just losing a bit here or there), that a 16 bit CRC was mathematically reduced to the same efficacy as a 16 bit checksum, e.g. incorrectly passing good data on 1 out of every 65536 bad packets. Regards, PatArticle: 146878
On Mar 30, 7:58=A0pm, -jg <jim.granvi...@gmail.com> wrote: > > are you assuming a 'classic PLL' design ? - it is unlikely the FPGA > PLLs are classic in nature, but are more likely to have 'other tricks' > and shortcuts to integrate better in digital process. > > -jg There are silicon VCOs with on-board PLLs that do a fine job with rather standard - albiet higher frequency - phase detector schemes. We may not have the charge pumps with two caps and a resistor but the schemes are still somewhat standard. Maybe it's done very different in the FPGA realm.Article: 146879
MitchAlsup <MitchAlsup@aol.com> wrote:
+---------------
| The most memorable hardware structure is the vector indirect
| addressing mode.
+---------------
I was always rather fond of the PDP-10's multi-level indirect addressing
which allowed additional indexing with a different accumulator at each
level of indirection, and how that permitted multi-dimension array indexing
to be done in a *single* instruction, albeit requiring auxiliary Iliffe
vectors for the arrays [as was done in ALGOL-10]. Quoting myself:
Newsgroups: alt.folklore.computers
Date: Sun, 30 Aug 2009 06:03:04 -0500
From: rpw3@rpw3.org (Rob Warnock)
Subject: Re: PDP-10 Assembly Language Questions
Message-ID: <HrWdnRhVz531wQfXnZ2dnUVZ_v6dnZ2d@speakeasy.net>
...
For, say, a three-dimensional array, if A, B, & C were already
in the proper registers, then "FOO[A,B,C] := FOO[A,B,C] + 1"
could be done in *one* instruction!! (No joke!)
What, you don't believe me? ;-} Here's the code:
MOVE T1,A ; Load up the array indices
MOVE T2,B
MOVE T3,C
AOS @FOO(T1) ; Increment FOO[A,B,C] (and don't skip).
[Assumes the first level of Iliffe vectors has the indirect-addressing
bit on and "T2" in the index field, and the second level of Iliffe vectors
has the indirect-addressing bit *off* and "T3" in the index field.]
-Rob
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Article: 146880The two hardware datastructures supporting out of order execution: Reservation stations. And, less beautifully, the register renaming map. But then I am biased. -- Really, I do think that the reservation stations are beautiful. Even the naive CAM implementation. Especially since there are more efficient implementations that are logically equivalent. I am also pretty high on bit matrix schedulers.Article: 146881
On 3/29/2010 7:39 PM, MitchAlsup wrote: > The most memorable hardware structure is the vector indirect > addressing mode. > > Mitch Aagh! No! Although work I did on that veered towards reservation stations, which I like. Nvidia has shown that vector indirect is unnecessary on a SIMT. Although^2, it turns out that very similar hardware is needed for SIMT scalar indirect.Article: 146882
Some good CMOS references: 1. Principles of CMOS VLSI Design by Weste/Harris 2. Digital Integrated Circuit Design: From VLSI Architectures to CMOS Fabrication by Hubert Kaselin 3. CMOS Digital Integrated Circuits: Analysis and Design S.M. Kang and Y. Leblebici 4. Low power design by Chandrakasan/Brodersen. 5. You can also look at books by John P. Uyemura but they might be quite old. Hope this helps.Article: 146883
In comp.arch.fpga "Andy \"Krazy\" Glew" <ag-news@patten-glew.net> wrote: > The two hardware datastructures supporting out of order execution: > Reservation stations. > And, less beautifully, the register renaming map. Both from the IBM 360/91, as far as I know. S/360 has only four floating point registers, so register renaming was pretty important for out-of-order execution. OK, how about imprecise interrupts? -- glenArticle: 146884
>On 26/03/2010 10:38, weldat wrote: >> Hi every body; >> i am working on xilinx EDK with MicroBlaze soft core processor. i am using >> Virtex 5 ML506 platform studio and my EDK is EDK 9.2 >> on this processor i am downloading C code for Elliptic curve diffie-hellman >> key exchange and it is done but result is not displayed on the >> hyperterminal so is there any body who can help me how to fix my problem? >> but the connetion of the RS232_uart is working properly i have checked it >> with simple C code. the baud rate is all ok >> thank you in advance. >> kind regards >> weldat > >I have no idea about your system, but hyperterminal is notoriously >unreliable and entirely unsuitable to embedded development. Try a >decent terminal emulator first to eliminate that source of problem. >Many people (including me) like Tera Term Pro, but there are hundreds of >alternatives. > >but when i power ON the FPGA(xilinx virtex 5 ML506)welcome to xilinx virtex 5 is displayed on the hyperterminal.the problem is when download the C code for the elliptic curve diffie hellman key exchange on the FPGA the LEDs are blinking showing that downloading is performed bur the result of the code is not displayed on the hyperterminal.even i have checked for simple C codes of secure hash algorithm(SHA)and it works and result is displyed on the hyperterminal. but till now i did not fix why it is not displaying result of the elliptic curvr diffie hellman key exchange. thank you weldat --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146885
On 29 Mar, 22:36, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: ... > No? =A0Don't like that? =A0OK, the Transputer's tiny 3-register > evaluation stack, with context switches permitted only at > points where the stack is known to be empty. =A0The > 21st century operating system wonks could REALLY learn > something about lightweight elegance from that one. And from its one-byte instructions. Four-bit opcode and four-bit data fields lead to 29 of the most-used instructions taking just one byte and allowing for about 256 others to be encoded in two bytes (though some used more). All this made effective on a 32-bit machine in the 1980s! Of course the stack and zero-operand addressing made such tiny encoding possible. These days a single stack would probably effect a dependency between instructions which did not need one. Perhaps today such would be built as many micro-cores. JamesArticle: 146886
Patrick Maupin wrote: > I also never convinced him that when his uber-fancy data recovery lost > lock and just started spewing garbage (which it did in a rather > spectacular way when it got lost, not just losing a bit here or > there), that a 16 bit CRC was mathematically reduced to the same > efficacy as a 16 bit checksum, e.g. incorrectly passing good data on 1 > out of every 65536 bad packets. It is easily proved, sure, and CRC are not magic. "Garbage in, garbage out", so if you input random data, CRC fails in average every 2^N packet, where N is the size of your CRC (in bits). That's probably why the Ethernet protocols use 32 bits... wait, did I just imply that 100BaseT is better than USB ?? > Regards, > Pat yg -- http://ygdes.com / http://yasep.orgArticle: 146887
In article <houi8s$rdm$1@naig.caltech.edu>, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >In comp.arch.fpga "Andy \"Krazy\" Glew" <ag-news@patten-glew.net> wrote: >> The two hardware datastructures supporting out of order execution: > >> Reservation stations. > >> And, less beautifully, the register renaming map. > >Both from the IBM 360/91, as far as I know. > >S/360 has only four floating point registers, so register >renaming was pretty important for out-of-order execution. > >OK, how about imprecise interrupts? Not a problem, until you try to resume after trapping them :-) And the reason they were a problem was that they DID'T have a lot of data structure to support them .... I like them, as a design methodology, but only if integrated into a restartable code sequence design and/or NOT used for anything that might need resumption. E.g. one of the Alpha's most stupid mistakes was to try and merge them with the use of interrupts for supporting IEEE's edge cases. The 8087 was just plain idiotic. Regards, Nick Maclaren.Article: 146888
Does anybody else, besides xilinx, make FMC boards for ml605 & sp605 ? HW-FMC-XM105-G FMC XM105 DEBUG CARD HW-FMC-XM104-G FMC CONNECTIVITY MEZZANINE CARD Buying Xilinx products now means going through Avnet, which is a nightmare and HUGE lead times ... Thanks, rudiArticle: 146889
On Wed, 31 Mar 2010 09:42:30 +0200, whygee <yg@yg.yg> wrote: >Patrick Maupin wrote: >> I also never convinced him that when his uber-fancy data recovery lost >> lock and just started spewing garbage (which it did in a rather >> spectacular way when it got lost, not just losing a bit here or >> there), that a 16 bit CRC was mathematically reduced to the same >> efficacy as a 16 bit checksum, e.g. incorrectly passing good data on 1 >> out of every 65536 bad packets. > >It is easily proved, sure, and CRC are not magic. >"Garbage in, garbage out", so if you input >random data, CRC fails in average every 2^N packet, >where N is the size of your CRC (in bits). >That's probably why the Ethernet protocols use 32 bits... > >wait, did I just imply that 100BaseT is better than USB ?? > As opposed to USB, there is no CRC at the PHY level in 100B-TX (nor in 1000B-TX; which has FEC but still no CRC). The 32 bit CRC is at MAC layer and is more or less independent of the PHY. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 146890
>What version of ISE/EDK are you using? Are you using a core or did >you write your own interface to the DDR? > Hi! The version of ISE that I'm using is 9.2. I'm using a DDR controller found on www.opencores.org for communication with a memory that is on board with a Virtex2 then modified for my board with a Virtex4. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146891
On Mar 30, 5:17=A0pm, "vragukumar" <vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com> wrote: > Hello, > > We are trying to migrate a fully functional project from Xilinx ISE v7.1 = to > Xilinx ISE v11.1. We started off by creating a new project under v11.1 an= d > bringing over all the .v (verilog source) files, .ise file, .xco files an= d > .ucf file. > > The project synthesizes successfully, however when trying to Implement > design, translate fails with several of the following errors > > (a) NgdBuild 924: input pad net '....' is driving non-buffer primitives > (b) NgdBuild 455: logical net '....' has multiple drivers > (c) NgdBuild 462: input pad net '....' drives multiple buffers > (d) NgdBuild 809: output pad net'....' has an illegal load > > Has anyone encountered these errors in the past while migrating from an > older version of Xilinx ISE to v11.1 ? Why are these caused and how do we > get rid off these errors ? > > Thanks in advance for your help, > Regards. > Vikram. =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com These messages indicate that you have a top level port connected to input of an IBUF and other internal logic at the same time and that you have the a top level port connected to an output of an OBUF and other internal logic at the same time. The likely cause is a mixed use of IO buffer instantiation in the Verilog code and IO insertion in synthesis. This can also happen if you are synthesizing modules that have IO insertion turned on or IP cores that are a black-box in the top level synthesis, but have IO buffers included. Ed McGettigan -- Xilinx Inc.Article: 146892
On Mar 31, 1:51=A0am, luudee <rudolf.usselm...@gmail.com> wrote: > Does anybody else, besides xilinx, make FMC boards for ml605 & sp605 ? > > HW-FMC-XM105-G =A0FMC XM105 DEBUG CARD > HW-FMC-XM104-G =A0FMC CONNECTIVITY MEZZANINE CARD > > Buying Xilinx products now means going through Avnet, which is a > nightmare and HUGE lead times ... > > Thanks, > rudi While the XM104 is listed with a 8 week lead time on the Avnet site, I know that we have these available in inventory and they will ship promptly after the order is placed. The XM105 is listed with a 2 week lead time. There are a number of other companies releasing FMC cards, just be sure that the cards support a VADJ of 2.5V and there shouldn't be a problem. 4DSP recently announced a FMC family http://www.przoom.com/news/66794/ Curtiss-Wright also has a number of boards. http://www.cwcembedded.com/0/62/651.html And Xilinx has a number of other boards in pipeline to be released next quarter. http://www.xilinx.com/fmc Ed McGettigan -- Xilinx Inc.Article: 146893
Hi again, Impatient as I am, I went for testing the variable phase shifter on the existing board. I ran on a xc3s1600e-4 stepping 0, which is not what I'll have in the end, but the results were so encouraging, that I feel pretty safe to jump to another device with no further checks. I wrote a small Verilog module (the "state machine" below), which sends shift commands in order to reach a certain position, which I set through some register interface. Given that I wrote the module right (which it seems like I did), I could arbitrarily jump to any position I liked, just by changing the register. I had the shifted clock and a reference clock wired to a testpoint, and I also had a signal going high whenever my state machine was between PSEN and PSDONE (that is, waiting). The latter turned out very interesting. So I fed the DCM with a 5 MHz clock (minimal frequency) and started playing around. Things went very smooth as long as I remained within the per-spec =B11970 steps boundary. In my case I got around 22.75ps per step (measured by jumping 1000 steps or so) consistently. I thought this number was absurd, but it turned out to be true: The chip allows =B139.4 ns of delay. That's a useful rail of nearly 80 ns. Pretty impressive. But I didn't stop there. I went for larger shifts until things started to break. =B14000 was OK. When I tried 4500 in either direction, hell broke lose. The most interesting thing was that the state machine was waiting for PSDONE. I didn't look deeply into how much time each PSEN- PSDONE cycle took, but it appeared long, random, and sometimes completely stuck. In one occasion, the state machine waited for quite a while, and then suddenly the "waiting" line went low again. On the scope I saw a 2.5 MHz clock on the DCM's output (the original frequency divided by two). This random behavior appears suspiciously similar to reports I've read from people who said that the PSDONE came much later than expected. Which makes me think (or hope?) that their problem was in their own logic, which accidentally pushed the phase shifter beyond its limit. Another interesting thing about this result, is that the region of 4000-4500 steps is where the extra delay gets close to half a clock cycle. On the scope, it was pretty evident that things started to go wrong when the shifted clock got close to a 180 degree shift. And this might explain the rule allowing 10 steps (0.4 ps at most) for each ns of cycle period on the shifted clock. As for those extra 3ns, I suppose there's a reason as well. I tried this again with a 33.3 MHz input clock. The behavior was the same. Hell broke lose when the shifting reached half a clock cycle. In short, all this starts to make sense to me. This looks like "follow the spec and everything will be all right". The bottom line is that the datasheet was right, and the user guide was confusing. Thanks again for your answers. You really were helpful. Bill.Article: 146894
On Mar 31, 12:53=A0pm, Bill Valores <bill.valo...@gmail.com> wrote: > I wrote a small Verilog module (the "state machine" below), which > sends shift commands in order to reach a certain position, which I set > through some register interface. It sounds very much like what I built. > This random behavior appears suspiciously similar to reports I've read > from people who said that the PSDONE came much later than expected. > Which makes me think (or hope?) that their problem was in their own > logic, which accidentally pushed the phase shifter beyond its limit. I didn't try to stress it to breaking, but I never saw any problems, and we did lots of lab work over a couple of months. > In short, all this starts to make sense to me. This looks like "follow > the spec and everything will be all right". The bottom line is that > the datasheet was right, and the user guide was confusing. I think the user guide may have too much leftover S3 DCM info (which is way different than S3E DCM). > Thanks again for your answers. You really were helpful. Glad to hear it! Thanks for letting me know you're up and running. Regards, PatArticle: 146895
On Mar 31, 1:53=A0pm, Bill Valores <bill.valo...@gmail.com> wrote: > > The most interesting thing was that the state machine was > waiting for PSDONE. I didn't look deeply into how much time each PSEN- > PSDONE cycle took, but it appeared long, random, and sometimes > completely stuck. In one occasion, the state machine waited for quite > a while, and then suddenly the "waiting" line went low again. On the > scope I saw a 2.5 MHz clock on the DCM's output (the original > frequency divided by two). > > This random behavior appears suspiciously similar to reports I've read > from people who said that the PSDONE came much later than expected. > Which makes me think (or hope?) that their problem was in their own > logic, which accidentally pushed the phase shifter beyond its limit. You stated earlier that "I understand that clock jitter has been a primary suspect where problems have arisen." That jolted a couple brain cells loose. Jitter on the 50 MHz reference clock was the problem in our system prototype across the country (a problem we never had locally with a different front-end transmitter). When the problem was isolated further down, the clock quality was identified as a strong issue. A couple changes were made on the board providing the 50 MHz reference clock (and three communications links tied to it) to make it a much cleaner version of its earlier self and the problems with PSDONE coming in late (or never) went away. I'm certain the PSDONE detection logic was fine (it was even reworked a few times to try to figure things out) and the limits of the phase shift were not at issue. When I did have the poor quality clock and the PSDONE response was persnickety, I set up a BlockRAM counter to enumerate the number of instances of the PSDONE taking N cycles to report, N being from 1 to 512. I recall the trend being logarithmic. When I plotted the data I used a log scale to deal with the wide range of counts. The plot was roughly a staircase with a linear (on the log graph) trend. Several delay times would be approximately the same count of instances, then markedly fewer for several more similar counts, and so on down the logarithmic staircase. With the jitter problem fixed, the response from the PSDONE was fixed as well. Happy shifting!Article: 146896
On Mar 31, 2:13=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > On Mar 31, 1:53=A0pm, Bill Valores <bill.valo...@gmail.com> wrote: > > > > > The most interesting thing was that the state machine was > > waiting for PSDONE. I didn't look deeply into how much time each PSEN- > > PSDONE cycle took, but it appeared long, random, and sometimes > > completely stuck. In one occasion, the state machine waited for quite > > a while, and then suddenly the "waiting" line went low again. On the > > scope I saw a 2.5 MHz clock on the DCM's output (the original > > frequency divided by two). > > > This random behavior appears suspiciously similar to reports I've read > > from people who said that the PSDONE came much later than expected. > > Which makes me think (or hope?) that their problem was in their own > > logic, which accidentally pushed the phase shifter beyond its limit. > > You stated earlier that "I understand that clock jitter has been a > primary suspect where problems have arisen." > > That jolted a couple brain cells loose. =A0Jitter on the 50 MHz > reference clock was the problem in our system prototype across the > country (a problem we never had locally with a different front-end > transmitter). =A0When the problem was isolated further down, the clock > quality was identified as a strong issue. =A0A couple changes were made > on the board providing the 50 MHz reference clock (and three > communications links tied to it) to make it a much cleaner version of > its earlier self and the problems with PSDONE coming in late (or > never) went away. =A0I'm certain the PSDONE detection logic was fine (it > was even reworked a few times to try to figure things out) and the > limits of the phase shift were not at issue. > > When I did have the poor quality clock and the PSDONE response was > persnickety, I set up a BlockRAM counter to enumerate the number of > instances of the PSDONE taking N cycles to report, N being from 1 to > 512. =A0I recall the trend being logarithmic. =A0When I plotted the data = I > used a log scale to deal with the wide range of counts. =A0The plot was > roughly a staircase with a linear (on the log graph) trend. =A0Several > delay times would be approximately the same count of instances, then > markedly fewer for several more similar counts, and so on down the > logarithmic staircase. =A0With the jitter problem fixed, the response > from the PSDONE was fixed as well. > > Happy shifting! yeah, whether you're using dynamic phase shift or not, experience has shown me that Xilinx DLLs and DCMs can be exceptionally unhappy if you are not giving them a clean clock. If the 1ns max jitter figure bandied about in another thread is any indication, this may still be true even with the new PLL-based architecture. For clocks of unknown provenance, I usually use a PLL in front of the FPGA to clean the clock, and use some separate FPGA logic on a local oscillator to monitor the DCM locked indicator and reset the DCM if there are issues. In the past, I have used Cypress RoboClocks and InstaClocks for pre-FPGA jitter cleanup. On my last design, I actually used one of my own company's (different division's) parts (the ZL30132) which was, admittedly, overkill for what I needed, but was effectively free for me (and it seems to work quite well, to boot). Regards, PatArticle: 146897
On Apr 1, 5:53=A0am, Bill Valores <bill.valo...@gmail.com> wrote: > So I fed the DCM with a 5 MHz clock (minimal frequency) and started > playing around. Things went very smooth as long as I remained within > the per-spec =B11970 steps boundary. In my case I got around 22.75ps per > step (measured by jumping 1000 steps or so) consistently. I thought > this number was absurd, but it turned out to be true: The chip allows > =B139.4 ns of delay. That's a useful rail of nearly 80 ns. Pretty > impressive. > > But I didn't stop there. I went for larger shifts until things started > to break. =B14000 was OK. When I tried 4500 in either direction, hell > broke lose. The most interesting thing was that the state machine was > waiting for PSDONE. Going outside the limits can be very useful. * It confirms the limit is correctly understood * it gives useful insight, into failure modes, and thus a place to look, should issues appear later. * Knowing what something cannot do, often gives more insight, than knowing what it can do :) Vendors should do more of this, and providing a piece of test/example/ exercise code like you have done, is something they should all be encouraged to do. -jgArticle: 146898
On Mar 30, 8:30=A0pm, pallav <pallavgu...@gmail.com> wrote: > Some good CMOS references: > > 1. Principles of CMOS VLSI Design by Weste/Harris > 2. Digital Integrated Circuit Design: From VLSI Architectures to CMOS > Fabrication by Hubert Kaselin > 3. CMOS Digital Integrated Circuits: Analysis and Design S.M. Kang and > Y. Leblebici > 4. Low power design by Chandrakasan/Brodersen. > 5. You can also look at books by John P. Uyemura but they might be > quite old. > > Hope this helps. Hi Pallav, Thank you. I have bought Principles of CMOS VLSI Design, second edition, by Weste, I am very happy to have the 2nd edition. Harris later appended some chapters to the 3rd edition to make it the 4th edition. I think it may be enough for me to have the 2nd edition. Because I need only the basic knowledge about CMOS. I am interested in logic design and computer architecture. With CMOS knowledge it may help get faster designs. WengArticle: 146899
On Mar 31, 4:19=A0pm, -jg <jim.granvi...@gmail.com> wrote:
> Going outside the limits can be very useful.
> * It confirms the limit is correctly understood
> * it gives useful insight, into failure modes, and thus
> =A0 a place to look, should issues appear later.
> * Knowing what something cannot do, often gives more
> insight, than knowing what it can do :)
Absolutely agreed; "play time" is when most learning occurs.
> Vendors should do more of this, and providing a piece of test/example/
> exercise code like you have done, is something they should all be
> encouraged to do.
Xilinx sometimes is reluctant to disclose how or why things work, so
good luck with your campaign of getting them to disclose how or why
things DON'T work. A big company finds it easy to find the downside
in a disclosure ("Altera will figure out our weaknesses and explain
them to customers; patent trolls will notice that we are infringing
their putative IP.") often without noticing the simple upside that an
informed customer is a happy customer.
Pat
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