<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Heiko Schocher schrieb:
<blockquote cite="mid:47D02BBE.5090703@denx.de" type="cite">
<pre wrap="">Hello Stefan,
Stefan Roese wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Thursday 06 March 2008, Andre Schwarz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Stefan Roese schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">On Wednesday 05 March 2008, Andre Schwarz wrote:
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->[...]
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">There's a include/ACEX1K.h that introduces two interfaces for obviously
the same funtionality.
The first one is specific to ACEX1K and the other one is a general
cyclone implementation as it should be.
</pre>
</blockquote>
<pre wrap="">Please clean it up too.
</pre>
</blockquote>
<pre wrap=""><!---->
Maybe we should do a cyclon2.h ?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">include/ACEX1K.h
Obviously there are some confusions about the various file formats and
sizes that can be output
from Altera's SoPC Builder. Compression is also possible with
de-compression on the fly during load ...
Of course the defined file sizes should match a raw bit file that
represents the true size of the device.
Why is ACEX1K and Cyclone not merged ?
</pre>
</blockquote>
<pre wrap="">No idea. If you have some fixes, please send patches.
</pre>
<blockquote type="cite">
<pre wrap="">Does _any_ real board use the Altera path ? scanning the config files
... no.
</pre>
</blockquote>
<pre wrap="">alpr seems to use the cyclone2.c code.
</pre>
</blockquote>
<pre wrap="">no - it uses common/ACEX1K.c .... and common/cyclon2.c is derived from it.
</pre>
</blockquote>
<pre wrap="">No, it doesn't use common/ACEX1K.c.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, common/ACEX1K.c was the base for me to make the cyclon2.c.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">CYC2_ps_load in common/cyclon2.c the nCONFIG pin is never de-asserted
during preparation. This code can't work.
</pre>
</blockquote>
<pre wrap="">No idea. I have to admit, that I didn't implement the FPGA booting on
this board. But it seems to work fine.
</pre>
</blockquote>
<pre wrap="">yes - because it's a board specific implementation with an "general"
interface.
</pre>
</blockquote>
<pre wrap="">???
</pre>
</blockquote>
<pre wrap=""><!---->
What do you mean with "board specific implementation". Its for a cyclon2
FPGA. I am not a FPGA specialist, but I think there were some differences
between this FPGAs and so I made a new File ...
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Is there any interest in getting this fixed ?
</pre>
</blockquote>
<pre wrap="">Sure.
</pre>
</blockquote>
<pre wrap="">But implementing the Altera path in a clean way means discarding the
ACEX1K and breaking the alpr borad.
I'm quite sure that Wolfgang will reject those changes.
</pre>
</blockquote>
<pre wrap="">Yes, I will reject this too. :)
</pre>
</blockquote>
<pre wrap=""><!---->
Why you break the alpr board. It uses the common/cyclon2.c?
(OK, we should make a include/cyclon2.h and then we can drop the ACEX1K, right?)
</pre>
</blockquote>
I admit that I have not followed the ACEX1K down through the interface.
But since there is an ACEX1K "#define"<br>
in common/altera.c and the serial download of the Cyclone is broken
(missing deassertion of nConfig) it looked like<br>
alpr used the ACEX1K.<br>
<br>
As I see now this is not true. We should fix the programming of nConfig
and verify on alpr.<br>
Then we can remove ACEX1K and prepare for Cyclone-II and -III with a
unified loader, corrected chip <br>
sizes and variable bitstream formats including endianess.<br>
<blockquote cite="mid:47D02BBE.5090703@denx.de" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">How can we solve this ?
</pre>
</blockquote>
<pre wrap="">By trying to solve it in a compatible way. I added Heiko Schocher to CC too,
since he was responsible for the FPGA booting implementation of the alpr
board.
</pre>
</blockquote>
<pre wrap=""><!---->
I have to admit that this was my First and only FPGA Implementation.
Stefan, do you know, if we have somewhere an alpr board, so we can do
tests with it, if we change code?
bye
Heiko
</pre>
</blockquote>
If would be great if you could test the changes on alpr before applying
patches.<br>
It looks like no other Altera boards are in the tree ... I have
different ones and can do excessive testing.<br>
<br>
<br>
regards,<br>
Andre<br>
<br>
<BR>
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
<BR>
</body>
</html>