Author: Keith Evans
Date: 10:58:28 04/11/03
Go up one level in this thread
On April 11, 2003 at 08:59:31, Vincent Diepeveen wrote: >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 do not know how to program verilog, so from my viewpoint it is very hard. > >But just parallellize gnuchess and put it on hardware chip and then you have >deep blue if you improve qsearch a bit and add some extensions. > >It plays similar style of games like deep blue. > >Best regards, >Vincent I can take a look at it. It might be difficult to map what it's doing into hardware though. Which version are you referring to? Keith
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.