Author: Keith Evans
Date: 10:54:21 04/10/03
Go up one level in this thread
On April 10, 2003 at 13:38:58, Vincent Diepeveen wrote: >On April 10, 2003 at 12:30:16, Keith Evans wrote: > >>On April 10, 2003 at 08:07:22, Vincent Diepeveen wrote: >> >>>On April 09, 2003 at 21:02:18, Keith Evans wrote: >>> >> >>>>Some points: >>>> >>>>1 - SDRAM (or whatever) is way cheaper than Xilinx parts. If you cared about >>>>this, you could either offer it as an upgrade option, or let people upgrade >>>>themselves. (The standard practice would be to require a special DIMM so you >>>>could charge extra.) >>> >>>DDR ram is not too slow, but the problem is to interface to it in a cheap way. >>>how are you going to do that? Every interface eats money to license it. >>> >>>Further we do not speak about ASIC here but FPGA. How to interface memory >>>cheaply to FPGA? >> >>Are you worried about IP core licensing fees? It's not difficult to build a >>memory controller. You can even download some app notes from the Xilinx webpage, >>but be prepared to fix bugs if you use those. >> >>We built a digital data recorder (40 mbit/s stream) using a Xilinx SDRAM app >>note as a basis and it worked out fine in an older Virtex part. >> >>I've found that for simple interfaces it's usually easier to do it yourself than >>to license IP cores. I did a lot of work with video RAM early in my career >>(which wass just old async DRAM + shift register), so I know how to read memory >>datasheets. > >needed here is something that gets memory at 6 million times a second and like >32 bytes of it at least. > >Further you need to lookup based upon some value that is in the hardware. > >latency may only be 1 processor clocks (from the fpga) or so to keep it real >interesting. and in case of entire search in fpga like 10 processor clocks at >most. > >then at 6 million nps you fill of course that memory quick. So it has to be at >least 128MB memory or so. > >For what price can you add that to the package? > >price matters. only price matters, remember. these guys do not write such stuff >only for their pleasure. > >>Keith I might just use ordinary SDRAM and clock it at a multiple of the engine clock. Let's guess that the engine will be running at 25 MHz max. So old SDRAM could be clocked at 4X that rate. I would probably put two DIMMs in and have a 128-bit path to memory. So every clock in a burst access would return 16 bytes. Remember that this is the high speed clock, not the engine clock. Once data started coming in you could get your 64-bytes in one or two engine clocks. (I would need to work out the additional time since you would be doing random accesses maybe 1 or 2 additional clocks?) It's hard for me to guesstimate this stuff. There could be additional overhead. Plus working with multiple clock domains is always interesting. You would want certain timing relationships to be maintained so you wouldn't need any synchronizers. You might work out a scheme where you would use a small on-chip hash table with single cycle accesses for 64-bytes. This would be fairly small though and could only have thousands of entries. But you could have both internal and external hash I guess? Anyways I would be happy just to recreate something like Deep Thought for starters.
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.