From: rickman Newsgroups: comp.arch.fpga Subject: JBITS and modular FPGA configuration Date: Sun, 04 Nov 2001 14:08:29 -0500 Lines: 44 Message-ID: <3BE5922D.12927417@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVbC/AFPXbvdL1oVhYDLpRgXXX5TQ5i9rEEzi1r4ynBA6qfy3Exjpn7E X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 4 Nov 2001 19:08:02 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:11201 We produce DSP modules which support small daughtercards for various types of IO. Each of these daughtercards require a different interface to the DSP module. The obvious way to handle this is to use FPGAs which can be downloaded with the design unique to each daughtercard installed. On our first design we used one FPGA as a main board controller and used a separate FPGA for each daughtercard interface. This allowed us to load the FPGAs at boot up time after determining the identity of the daughtercards installed. The problem with this approach is that we are increasing the number of daughtercards supported from 2 to 4 and we are using a very small form factor main board (PC/104). So we are very cramped for space for two more FPGAs. This becomes a bigger problem as we move to newer FPGA families which do not support the small TQ100 package. Of course there are the uBGA packages, but they make board routing much harder with so many in such a small space. We can get a significant cost and size savings using a single, larger FPGA. But this complicates the download process since the daughtercard interfaces are then all in a single download. If we want to handle all possible configurations, we will have to provide literally thousands of possible bitstreams. Can we achive the same real time configuration as in the multi-FPGA approach or at least allow a user a way to build the appropriate download for the main module FPGA using JBITS? We don't want to require a user to download FPGA tools and perform a place and route just to reconfigure their boards. Can we do that with JBITS, use separate modules for the interfaces and combine them without using the place and route tools? -- 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 FAX ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: JBITS and modular FPGA configuration Date: 04 Nov 2001 23:19:58 +0100 Organization: My own Private Self Lines: 127 Message-ID: <6ubsiifab5.fsf@chonsp.franklin.ch> References: <3BE5922D.12927417@yahoo.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1004912398 1386 10.0.3.2 (4 Nov 2001 22:19:58 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 4 Nov 2001 22:19:58 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:11202 rickman writes: > On our first design we used one FPGA as a main board controller and used > a separate FPGA for each daughtercard interface. This allowed us to load > > The problem with this approach is that we are increasing the number of > daughtercards supported from 2 to 4 and we are using a very small form > factor main board (PC/104). So we are very cramped for space for two > > We can get a significant cost and size savings using a single, larger > FPGA. But this complicates the download process since the daughtercard > > Can we achive the same real time configuration as in the multi-FPGA > approach or at least allow a user a way to build the appropriate > download for the main module FPGA using JBITS? We don't want to require > a user to download FPGA tools and perform a place and route just to > reconfigure their boards. Can we do that with JBITS, use separate > modules for the interfaces and combine them without using the place and > route tools? Should be possible with JBits. Basically take the large FPGA (JBits demands that it must be a Virtex (no -E or -EM !) or an Spartal-II of an size also existing in Virtex) and "cut" the FPGA space into one "master" section and 4 "expansion" sections. Cutting should be preferably vertical, if run-time reloading is needed (because Virtex reloads columns), else use any 4 identical sized sections. Something like this: .-----------------------------------. | .--..--..--..--. | | | || || || | | | | || || || | | | | || || || | | | | || || || | | | | || || || | | | | || || || | | | base |ex||ex||ex||ex| | | | 1|| 2|| 3|| 4| | | | || || || | | | | || || || | | | | || || || | | | | || || || | | | | || || || | | | `--'`--'`--'`--' | `-----------------------------------' or like this (if not run-time reconfig): .-----------------------------------. | .-------. .-------. | | | | | | | | | ex1 | | ex2 | | | | | | | | | `-------' `-------' | | | | | | base | | | | | | .-------. .-------. | | | | | | | | | ex3 | | ex4 | | | | | | | | | `-------' `-------' | `-----------------------------------' Then generate an "base" .bit bitstream for the master stuff. This will have to offer 4 "ports" (basically a set of routing lines and signals on them leading into the master part) for attaching the expansion parts. The "ports" represent a) connection to "base" stuff and b) connection to the appropriate slot. From here on implementation differs on how much you want the user of the board to do: 1. user has to install JBits on their system Simply program the expansions as .java files that use an standard call interface and than have the user edit an small config file that says which of these files is to be "included" onto which port of the master. Then let JBits compile. I suspect you do not want to go this way, as it requires users to install JBits software, but JBits compiles small program in minutes, so it may be OK, if you are just worried about config time. 2. User has JBits, but faster way Use JBits in the base, in a way that an standard "pinout" is made that interfaces the group of expansion CLBs to "base". "Pins" in this sense being actual FPGA routing wires (them 24 north/east/south/west wires). Just for the base->expansion wires you will have to use "raw" jbits.set() functions on both sides of the "divide". Then make one .bit with the base and with 4 "holes" (CLBs left unconfigured) where the expansions would go. Then have JBits load this pre-compiled .bit and expansions in .java files and have just add the expansion parts. This still requires the users to have JBits, but will be below minutes to compile. And no "base" source, if that is relevant to you. 3. user has no JBits at all on their system Take the same .bit with holes in it from above. Same "pins" interface. Then have one precompiled .bitx file each for each expansion modules (made by an module specific .java), containig just the CLBs for one subsection (always fitted to, say, the first hole). Then use the information in XAPP155 to write an own program that "cutouts" the 4 user-selected .bitx sections and "merges" them into the base .bit file. XAPP155 documents the arrangement of the basic 48x18 bits that configure one CLB. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual Robbery