Author: Slater Wold
Date: 11:59:46 04/10/03
Go up one level in this thread
On April 10, 2003 at 13:54:21, Keith Evans wrote: >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. I'm telling you man, we're dead on the same plane of thought here. If there's a way, we should for sure do it. ;)
This page took 0 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.