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
Nachiket Kapre wrote: > > elaborating on the RAM implementation furthere what you can do is use > a Xilinx BlockRAM to implement your state machine. > All you need to do is to connect the RAM's data bus back to it's > adderss bus with a single clock cyccle delay. > This reverse feedback path should be routed to two memories actually, > one will be your next state generation logic and the other will be > your output decoder logic. The second memory outputs can be used as > outputs of your state machine. > Durin synthesis you will have to come up with the binary data to store > in the Block RAM . > > for more details refer to the Xcell article by Peter Alfke in some > issue which does not come to my mind right now. > Some more details: The "second" memory can be the other port of the same BlockRAM, if you terminate the MSB address pins of the two ports one High, one Low. That way you have two independent half-size memories. Note also one limitation: Since BlockRAM read is a synchronous operation, the "next-stage" feedback works without any external registers, but the "second" RAM generates its output one clock later, kind of pipelined. It is important to realize that the outputs from the two memories are thus staggered, which I failed to point out in the TechXclusives article... Peter Alfke, presently with Karen Alfke 2nd Nature Design Port Townsend, WA karen@2ndesign.comArticle: 50051
"David Hawke" <dhawke@xilinx.com> wrote in message news:3DE745DB.2E75228D@xilinx.com... > Hi, > > Why not take a look at PicoBlaze on the Xilinx website - alternativly you > could use a RAM for the presentstate nextstate transition table, and then > when you want to change it re-write the contents. > > Dave > > zhengyu wrote: > > > Is anyone aware of any kind of FSM implementation that is programmable? > > > > I am thinking of using scan chain to shift some value onto on-chip > > registers, but maybe > > there is also the option to compile FSM into a binary file and have FPGA > > load the > > binary file and execute it, sort of like a state table. > > > > Where should I go to find reference on those? > I second the PicoBlaze comment. We are currently using it with great success. Thanks to Ken Chapman. Also we are using his UART, again with great success. Together, these saved us countless hours of design headaches. Don't re-invent the wheel when it isn't necessary. TheronArticle: 50052
"A. Karen Alfke" <karen@2ndesign.com> wrote in message news:3DE655F4.8F2FFB91@2ndesign.com... (snip) > > Metastability is very often blamed for completely unrelated sins. > Synchronizing an asynchronous input in more than one flip-flop is the > most common deadly sin. Not being so awake yet, how do you synchronize a whole bus between two different clock domains? My favorite was always the Intel 80286/80287 which had different clocks. (The 80286 used a 50% duty cycle clock, the 80287 used 33%, and they could run at completely different clock rates.) -- glenArticle: 50053
"A. Karen Alfke" <karen@2ndesign.com> wrote in message news:3DE6EF63.D2710848@2ndesign.com... > Michael S wrote: > >" > > When you say, that varying Vcc is the same as varying temperature you > > opinion is based on some theory. The theory may be right or wrong. For > > example, your theory doesn't take into account the influence of > > thermal noise and/or tunneling on metastabilty resolving time. > > Put your circuit into a thermostat and measure. Draw tau over > > temperature curve. Then you would know the answer based on facts. > > Of course it's easier to say than to do, because slack time doesn't > > remain constant too, but I believe you're able to find a solution for > > this problem. > > Nice to get helpful advice from the real experts... Some of those effects will scale differently with device size. Rules that worked 10 years ago may not work today. The temperature vs. Vcc rule I knew about 20 years ago, as far as logic speed went, and is still well known in the overclocking world. (I don't do it, but I read about it sometimes.) Interesting, though, though, that the failure of overclocked processors could be due to metastability problems, or to synchronization (between clock domains) failure. -- glenArticle: 50054
"Martin Brown" <martin.brown@pandora.be> wrote in message news:3DE5E575.95E97C8C@pandora.be... > > > Tim Nicolson wrote: > > > I'm currently implementing an image processing algorithm in hardware. > > > > The ip algorithm requires that I compute logarithms. This can prove quite a computationally expensive > > operation, but I only need accuracy down to around 4/5 significant figures. > > > Significant figures here meaning bits (easy) or decimal digits (harder) > ? > > > Currently, as binary floats are represented as m*2^e, where m is a number between 1-2, I have approximated > > the log function between 1-2 with a cubic polynomial. I then just scale the base2 exponent and add it to the > > result of the poly. > > > > This method is inexpensive but gives limited accuracy. Operations shown below > > > > > > z = a + b*mant + c*mant^2 + d*mant^3; > > > > if (e ~= 0) > > z = z + exp * C1; > > end; > > > > This requires 6* and 4+. > > > Nothing is faster than a lookup table, but if you also need code > compactness... > > Depending on how fast your hardware divide is the Pade approximant isn't > bad > > ln(1+x) ~ x*(6+x)/(6+4*x) > > Tweak the coefficients a bit and it is good to nearly 4 decimal sig fig > for 0 < x < 1 > > > Unfortuately, adding extra terms to the poly increases the accuracy slowly. > > > > So.... Does anyone know of a better way of computing the logarithm of a base2 fp number? > > > But starting from the other classic log polynomial > > ln ( (1+y)/(1-y)) = 2y + 2y^3/3 + 2y^5/5 > > where y = x/(2+x) > > is even better and also gives a very good Pade approximant. > > ln (1 + x ) ~ 2*y * (15 - 4y^2)/(15 - 9y^2) > > That is already close to 5 decimal digits accuracy before any tweaking. > > Maxent might object if the resulting log implementation isn't > continuous in the first derivative. In an FPGA multiply is hard, and divide is much harder. You can get a really big lookup table for the cost of divide logic. -- glenArticle: 50055
glen herrmannsfeldt wrote: > > Not being so awake yet, how do you synchronize a whole bus between > two different clock domains? See my TechXclusive on that very subject. Peter Alfke >Article: 50056
Hi Guy, Knowing why you need to pre-charge a row involves knowing quite a bit about how DRAM cells and sense amplifiers work. Knowing that you must pre-charge all rows before doing a refresh is sufficient for designing a controller. Many years ago, NEC published a book about how SDRAM works. If you can find it, it's a good read. Otherwise, (or in addition) get all the data sheets you can (Micron, Hynix, NEC, Toshiba, etc.) and become very familiar with "command state transitions" in the devices. Intel also published a good paper on the "Requirements of PC100 SDRAM memory" or similar. Worth looking for. It's not that hard. Come back with specific questions, and I (we) will try to help. SH7 On 29 Nov 2002 03:39:40 -0800, geschemann@yahoo.fr (Guy Eschemann) wrote: >Hi, > > I'm looking for an introductory course in SDRAM technology. The >background is that I'm currently working on an FPGA design involving a >SDRAM controller, but I can't find any document describing the >internal operation of these devices. > For example, I know I have to do a PRECHARGE to close a row, but I'd >like to know why I actually have to close a row. > Anyone can recommend any good book and/or link (I'm already aware of >the Xilinx appnotes & the Micron datasheets) ? > >Many thanks, >Guy.Article: 50057
Ray Andraka wrote: > > We tried this route a number of years ago and found the costs to be quite > high and the yield to be in the basement. Unless things have improved > greatly, and/or you have no other alternatives, I'd recommend against it. I would second that vote. I worked on a machine that used an omega layer in a large panel, 18" x 18". Non only did we have a lot of drop outs from manufacturing, we had a very high infant mortality rate, much of which was caught in the factory, but some which made it into cutomer's hands. This panel was like a backplane and had a small maze of wiring off one edge. It was a real b**ch to replace and even worse in the field. Many in our company considered the omega layer to be a mistake, at least for that application. -- 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: 50058
Guy Eschemann wrote: > > Hi, > > I'm looking for an introductory course in SDRAM technology. The > background is that I'm currently working on an FPGA design involving a > SDRAM controller, but I can't find any document describing the > internal operation of these devices. > For example, I know I have to do a PRECHARGE to close a row, but I'd > like to know why I actually have to close a row. > Anyone can recommend any good book and/or link (I'm already aware of > the Xilinx appnotes & the Micron datasheets) ? The information you want comes from the construction of the SDRAM that is common with all DRAMS. If you go to the Micron web site and find information on the old DRAM, either EDO, Fast Page or any other non-synchronous parts, they may still have app notes that tell you how these parts work internally. They are actually pretty amazing in that they are using very small amounts of charge on a very small capacitor to remember the logical value. To read one out they discharge it onto a bit line that has a relatively huge compacitance and so only wiggles a little bit. To make this as detectable as possible, they set the bit line to a mid value prior to connecting the bit capacitor. This is called Precharging. If you can't find any app notes on the older parts, I might be able to answer some of your questions. I am no expert, but I have used some of these parts and likely still have some of the old (paper) data sheets and app notes around. -- 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: 50059
Hi Kevin, > Other than what I just wrote, I don't know anyone else actively selling > a PCI IP core for Xilinx. I have a PCI IP core for sale, and did it before Xilinx even thought about doing theirs. The thing is, I don't sell the core outright, but as part of a "job". Austin Franklin austin@darkroom.comArticle: 50060
Spam Hater wrote: > > Hi Guy, > > Knowing why you need to pre-charge a row involves knowing quite a bit > about how DRAM cells and sense amplifiers work. > > Knowing that you must pre-charge all rows before doing a refresh is > sufficient for designing a controller. > > Many years ago, NEC published a book about how SDRAM works. If you > can find it, it's a good read. > Spam Hater, Thanks for mentioning about NEC's How To Use SDRAM manual. I found it at Elpida Memory's website. http://www.elpida.com/en/products/index.html http://www.elpida.com/pdfs/E0123N50.pdf Kevin Brace (If you want to respond to what I wrote, I prefer if you will do so within the newsgroup.)Article: 50061
Kevin Brace wrote:
>
> Go to their reference design section to download the reference design
> that contains the UCF file.
>
> http://208.129.228.206/solutions/reference/xilinx/reference.shtml
>
The above URL no longer seems to work, but this one works fine.
http://legacy.memec.com/solutions/reference/xilinx/
> > Does anyone know if it is possible or not really to use Xilinx PCI IP?
> > Does other PCI IP exists for this card? Or I put in in the trash...
> > The Insight Support didn't fix this issue in two weeks of calls...and
> > I spent a lot of effort without any progress.
> >
> > Thank you for your attention.
> >
> > Catalin
>
> Other than what I just wrote, I don't know anyone else actively selling
> a PCI IP core for Xilinx.
>
I forgot to mention IP core firms CAST (http://www.cast-inc.com)
and Eureka Technology (http://www.eurekatech.com/) that sell PCI IP
cores.
Other than that, Synopsys and Inventra (Mentor Graphics IP core
division) also have PCI IP cores, but they are probably not intended for
FPGAs.
Kevin Brace (If you want to respond to what I wrote, I prefer if you
will do so within the newsgroup.)
Article: 50062
Uwe Bonnes wrote:
>
>
> Kevin,
>
> you have talked so often about your PCI core.
> What do you do with the core? Is it only for a closed project of yours, do
> you sell it or do you even offer it for free?
>
> I am thinking about to take a plinge into the opencore PCI module...
>
My PCI IP core project is being done by myself only, and I do
plan to charge money for the use of it.
Because of that, it needs to be verified vigorously, and that's where I
am stuck with it now.
I hate to see my work collect dust . . .
Kevin Brace (If you want to respond to what I wrote, I prefer if you
will do so within the newsgroup.)
Article: 50063Austin Franklin wrote: > > Hi Kevin, > > > Other than what I just wrote, I don't know anyone else actively selling > > a PCI IP core for Xilinx. > > I have a PCI IP core for sale, and did it before Xilinx even thought about > doing theirs. The thing is, I don't sell the core outright, but as part of > a "job". > > Austin Franklin > austin@darkroom.com Austin, What I mean by saying "actively selling" is that a firm can sell (license) to someone else. Actually, IP core firms CAST (http://www.cast-inc.com) and Eureka Technology (http://www.eurekatech.com/) do have PCI IP cores for sale. If you have one available, why don't you want to get into the business of selling a PCI IP core? Kevin Brace (If you want to respond to what I wrote, I prefer if you will do so within the newsgroup.)Article: 50064
are you talking of the JTAG cable? if that is what you are lookgin for then xilinx has a schematic on their website for the parallel 3 cable and believe me it is damn easy to build that cable(provided you dont violate those cable length specs). the one we did last year cost us less that 2 dollars(100 indian rupees) and got the job done easily. the original xilinx ones cost a fortune in indian rupees and those commercially available are just trying to hoodwink you off you money. if its the PC3 cable that you are after i suggest you do it yourself from the schematic. good luck. Nachiket Kapre Design Engineer. Paxonet Communications Inc. rfrank1234@aol.com (RFrank1234) wrote in message news:<20021128151758.09022.00000467@mb-fo.aol.com>... > Where can I find low cost 3rd party Xilinx j-tag programmer? I have found low > cost programmers for Altera, but not Xilinx. Does anyone know where I can find > one that is compatible with Xilinx's DLC-7 programmer? > > Thanks, > > Ryan Frnaklin > rfrank1234@aol.comArticle: 50065
what is a good resource for latest RAM and I/O Standards>? I have already been thru Xilinx docs for the same. I need more advacned material. regards, Nachiket Kapre Design Engineer Paxonet Communications Inc.Article: 50066
okay, but that would mean that your combi outputs are not really combi outputs or rather no combi outputs are posible with this implmentation. Alternatively if we decide to use a distributed RAM in place of the "second" memory i guess we will get 'true" combi outputs. With BlockRAM you are limited to flopped outputs then. regards, Nachiket Kapre Design Engineer Paxonet Communications Inc. "A. Karen Alfke" <karen@2ndesign.com> wrote in message news:<3DE79467.D7D48638@2ndesign.com>... > Nachiket Kapre wrote: > > > > elaborating on the RAM implementation furthere what you can do is use > > a Xilinx BlockRAM to implement your state machine. > > All you need to do is to connect the RAM's data bus back to it's > > adderss bus with a single clock cyccle delay. > > This reverse feedback path should be routed to two memories actually, > > one will be your next state generation logic and the other will be > > your output decoder logic. The second memory outputs can be used as > > outputs of your state machine. > > Durin synthesis you will have to come up with the binary data to store > > in the Block RAM . > > > > for more details refer to the Xcell article by Peter Alfke in some > > issue which does not come to my mind right now. > > > Some more details: > The "second" memory can be the other port of the same BlockRAM, if you > terminate the MSB address pins of the two ports one High, one Low. > That way you have two independent half-size memories. Note also one limitation: > Since BlockRAM read is a synchronous operation, the "next-stage" > feedback works without any external registers, but the "second" RAM > generates its output one clock later, kind of pipelined. It is > important to realize that the outputs from the two memories are thus > staggered, which I failed to point out in the TechXclusives article... > > Peter Alfke, presently with > Karen Alfke > 2nd Nature Design > Port Townsend, WA > karen@2ndesign.comArticle: 50067
Hi "A. Karen Alfke" <karen@2ndesign.com> schrieb im Newsbeitrag news:3DE64F32.E13699E7@2ndesign.com... > I just caught up with this long thread... > From a hardware point of view, an asynchronous FIFO with clock rates > up to 150 MHz is quite simple. The basic mechanism uses a dual-ported > BlockRAM with independent addressing of each port, one for writing, > one for reading.(They can even be of different width). I do know how the FIFOs should look like in hardware. The thing I didn't get is how to synthesize them with Celoxica WITHOUT using a single line of HDL. > All the difficulty lies in the generation of FULL and EMPTY, which > requires comparing the two address counters in two different clock domains. Yes, exactly. But there is no easy way in Celoxica to pass an asynchronous signal between two clock boundaries. I have to use multiport rams for that purpose, which is apparently more complex than just connecting the two domains by wires, as you would with a HDL. > That's why these counters must be Grey-coded (only one bit changing at > any time), and I find it easiest to generate the Grey code by XORing > adjacent binary counter bits. That's exactly what I'm doing. The trickier thing is to convert those gray-coded values back in order to calculate the actual fill level of the fifo. There isn't any quick-and-dirty trick for doing this, is it? My method just converts them back (by a XOR chain) and subtracts the read pointer from the write pointer. > The leading edge of FULL ( and the > leading edge of EMPTY) is actually synchronous with respect to the > clock domain where it is relevant. It is the trailing edge of these > signals that must be transferred across the clock domains. But luckily > this does not require the ultimate speed, so it can be > double-synchronized. As far as I understand it, this just means an extra cycle of latency when the fifo is full and you're trying to read and write a word at around the same time (write is stalled until the incremented read pointer is fully synchronized and passed to the writing side). As said before, that doesn't bother me, as long as throughput isn't compromised. > I have published some papers in Xilinx TechXclusives, also about the > related topic of metastability. > > Peter Alfke, Xilinx Applications > presently with > Karen Alfke > 2nd Nature Design > Port Townsend, WA > karen@2ndesign.com Thanks for answering Regards, Bernhard MäderArticle: 50068
> is anybody onthe way/already stopping/afraid of/angry about porting the > java2 jvm to a xc2s fpga for usage in embedded devices - sombody which i may > work together? I'm working on this for some time: JOP - a Java Optimized Processor for FPGAs. http://www.jopdesign.com It's not GPL or free but you can find complete VHDL source on the web site. But don't steal any ideas :-) Martin SchoeberlArticle: 50069
The support cost is high compared to what people are willing for FPGA cores. It
is much easier to support a complete design than it is to support a macro that is
going to be abused by others.
Kevin Brace wrote:
> Austin Franklin wrote:
> >
> > Hi Kevin,
> >
> > > Other than what I just wrote, I don't know anyone else actively selling
> > > a PCI IP core for Xilinx.
> >
> > I have a PCI IP core for sale, and did it before Xilinx even thought about
> > doing theirs. The thing is, I don't sell the core outright, but as part of
> > a "job".
> >
> > Austin Franklin
> > austin@darkroom.com
>
> Austin,
>
> What I mean by saying "actively selling" is that a firm can sell
> (license) to someone else.
> Actually, IP core firms CAST (http://www.cast-inc.com) and Eureka
> Technology (http://www.eurekatech.com/) do have PCI IP cores for sale.
> If you have one available, why don't you want to get into the business
> of selling a PCI IP core?
>
> Kevin Brace (If you want to respond to what I wrote, I prefer if you
> will do so within the newsgroup.)
--
--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: 50070Nachiket Kapre wrote: > > okay, but that would mean that your combi outputs are not really combi > outputs or rather no combi outputs are posible with this > implmentation. Alternatively if we decide to use a distributed RAM in > place of the "second" memory i guess we will get 'true" combi outputs. > With BlockRAM you are limited to flopped outputs then. I agree mostly. But don't forget that you can have more outputs from the"first" memory than just the next address. And those xtra lines then look combinatorial, since they come up at the same time as the next address. The outputs from the "second" RAM=ROM come one clock tick behind. Did I mention that the "second" RAM=ROM might be much wider than the first one? Every output is"flopped" as you say, registered as I would say. In practice this can be either very important, or just a minor difference. Depends on the clock rate etc. Peter Alfke, Xilinx Applications > > aArticle: 50071
"Bernhard Mäder" wrote: > > That's exactly what I'm doing. The trickier thing is to convert those > gray-coded values back in order to calculate the actual fill level of the > fifo. There isn't any quick-and-dirty trick for doing this, is it? My method > just converts them back (by a XOR chain) and subtracts the read pointer from > the write pointer. Watch out! Converting the Grey counter back to binary is counterproductive and a waste of logic, for you again get multiple bits changing. You are back where you started, and might as well use the original binary counter. Binary subtraction of two counters in different clock domains inevitably generates glitches and momentary errors. You can low-pass filter them ( interrogate them several times in a row, then throw out the strange value...) I am a hardware guy, and of no help with your Handel-C problem. Viel Glück ! Peter Alfke > > ¿Article: 50072
Hi Ray, Bingo. As well as the costs involved in writing documentation so others could even use it. Austin "Ray Andraka" <ray@andraka.com> wrote in message news:3DE8F799.FBEFA5F6@andraka.com... > The support cost is high compared to what people are willing for FPGA cores. It > is much easier to support a complete design than it is to support a macro that is > going to be abused by others. > > Kevin Brace wrote: > > > Austin Franklin wrote: > > > > > > Hi Kevin, > > > > > > > Other than what I just wrote, I don't know anyone else actively selling > > > > a PCI IP core for Xilinx. > > > > > > I have a PCI IP core for sale, and did it before Xilinx even thought about > > > doing theirs. The thing is, I don't sell the core outright, but as part of > > > a "job". > > > > > > Austin Franklin > > > austin@darkroom.com > > > > Austin, > > > > What I mean by saying "actively selling" is that a firm can sell > > (license) to someone else. > > Actually, IP core firms CAST (http://www.cast-inc.com) and Eureka > > Technology (http://www.eurekatech.com/) do have PCI IP cores for sale. > > If you have one available, why don't you want to get into the business > > of selling a PCI IP core? > > > > Kevin Brace (If you want to respond to what I wrote, I prefer if you > > will do so within the newsgroup.) > > -- > --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: 50073
"Kevin Brace" <kev3inbrac5eusen7et@ho9tmail.c1om> wrote in message news:as9qev$v2l$1@newsreader.mailgate.org... > My PCI IP core project is being done by myself only, and I do > plan to charge money for the use of it. > Because of that, it needs to be verified vigorously, and that's where I > am stuck with it now. > I hate to see my work collect dust . . . Hi Kevin, If you are interested in having your core PCI-SIG compliance tested, I do that using an Agilent E2928A PCI analyzer for a fixed price for either target only or target/master. Price depends on what you are able to send me. As an example, if you send me a complete machine, software all loaded with your driver etc. and a script that runs the code that will run your board, for a target only, it's $500. AustinArticle: 50074
"Bernhard Mäder" wrote:
>
> > That's why these counters must be Grey-coded (only one bit changing at
> > any time), and I find it easiest to generate the Grey code by XORing
> > adjacent binary counter bits.
>
> That's exactly what I'm doing. The trickier thing is to convert those
> gray-coded values back in order to calculate the actual fill level of the
> fifo. There isn't any quick-and-dirty trick for doing this, is it? My method
> just converts them back (by a XOR chain) and subtracts the read pointer from
> the write pointer.
The conversion to grey is fine, as it is synchronous to the domain it is
generated in. Converting back before you compare defeats the purpose though,
since it maps a single bit change back into multiple bits changing. Unless you
take a latency hit by resynchronizing, you have gained nothing.
--
--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
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