After the recent "trouble" with VHDL I'd like to propose that we change the
way we do things with respect to VHDL.

The current system is predicated on building the VDHL images using the
script process.

None of the people who build VHDL for Balloon boards use this method and
there is no incentive to do so.

The VHDL still needs to be held in the main tree simply because changes in
the VHDL may well need corresponding code changes and it is important that
these are kept in sync. However the recent problems highlight that this has
not been happening.

Currently trunk still contains VLIO based VHDL but non-vlio based software
which is why it fails to work.

I think this is caused because the current workflow for modifying VHDL
involves too much complexity and as a result has spawned the TCL branch
which is the only place where functional code exists. I would like to get
back to having one VHDL source tree so we don't waste effort again.

I would like to propose that variants are controlled by a variants.vhd file
that holds flags to control all the variants in the source and not to have
the variations held as patches on the main VHDL files. This will make non
script building using the Xilinx tools much easier.

The VHDL compilers are very very good a stripping out redundant bits of
logic so you can easily write VHDL as if a control signal exists to flick
between variants and if that control happens to be a constant the whole
thing flattens.
 (I need to see how practical this is in VHDL terms but I'm guessing an
included set of constants which can be switched on/off will work, I think it
is reasonable to assume all variants will relate to code changes in
balloon3.vhd and that variants in modules can be handled by signal
declarations).

This means that all variant types can be held in one place and documented,
and that the variants file can be patched for a given build target as part
of a checkout and build process but that the main VHDL files will not need
to be patched. It also makes it clear which variant you are building by
simply looking a the variants.vhd file. 

I think this keeps the essential features of keeping VHDL in the source
tree, and patching it to reflect particular builds but minimises the effect
of multiple patches. It will mean the VHDL code will get slightly more
complex but I think that given the small number of people maintaining it
that will not be a problem. 

However I don't think we should release v1.0 with this scheme but instead
should checkin the VHDL so that the VHDL in trunk reflects the software in
trunk.

This means that the VLIO.patch file (which is in fact a NO-VLIO.patch since
it patches a VLIO VHDL source to being no-VLIO) should be removed, and the
trunk files made directly compatible. (I have no idea how to do this and it
needs to be done in synchrony with my checking in to trunk the NON-VLIO
VHDL.

(Note any PCMCIA fixing is still outstanding).

Regards

David






 

__________ Information from ESET Smart Security, version of virus signature
database 5483 (20100927) __________

The message was checked by ESET Smart Security.

http://www.eset.com