<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: device trees.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>>> Um.. one thing I'm missing in this discussion of attaching the dtb to<BR>
>> the bitstream: I don't see how the bitstream becomes accessible to<BR>
>> the kernel at runtime. Unless you were exposing the dtb as part of<BR>
>> the fpga programming, but I thought you explicitly weren't doing that<BR>
>> because of limited bram space.<BR>
<BR>
> While I am not sure I grasp all of the nuances why, this is NOT the<BR>
>scheme Stephen recomends.<BR>
> But it looks to be the most promising for me at Pico.<BR>
<BR>
There is not a general way to pass additional information which does not program configuration bits of the FPGA through<BR>
the configuration interface. There is a mechanism to do this in Virtex 4 and Virtex 5, but there is no<BR>
such mechanism for Spartan 3. The best option that works for all Xilinx FPGAs is to use the initial state of a<BR>
BRAM memory block to contain the .dtb, which can then be scavenged and reused in the system, if necessary, although this<BR>
can impact overall system design.<BR>
<BR>
David specifically asked for a mechanism which:<BR>
1) works on Spartan 3, in addition to V4 and V5.<BR>
2) does not require reserving an initialized BRAM, since BRAM information is very expensive in his system.<BR>
<BR>
The solution is highly specific to the configuration mechanism that David's company uses in their systems, and is not generally applicable<BR>
to all board designs.<BR>
<BR>
The main point of all of this is to avoid separating the bitstream from the corresponding .dtb, in order to<BR>
avoid consistency issues. Essentially, the bitstream describes itself using a .dtb.<BR>
<BR>
Steve<BR>
<BR>
</FONT>
</P>
<br clear=all> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
</BODY>
</HTML>