For now I manually create the "wrapper" unit that maps the inputs and outputs to a pair of unified vectors.
In private, Tristan told me there was some sort of Python thing that could do what I need but I'd rather avoid Python and experimental (like, less than 5 years old) features.
But there could be another way to extract the inputs and outputs from the compiled design : with the trace dumps ! GTKwave knows the type and direction of each port so maybe I can parse the trace dump to extract the info I want.
I'll have to test this ASAP, as I am currently contemplating how to make GetVectorsSize better.
Trying to play with GHDL in the LibreGates/tests/test2_INC8 directory:
> PA3="-P../../LibreGates -P../../LibreGates/proasic3"
> ghdl -a $PA3 INC8_ASIC.vhdl
> ghdl -e $PA3 INC8
> ./inc8 --vcd=inc8.vcd
> less inc8.vcd
____________________________
$date
Sat Sep 12 05:18:00 2020
$end
$version
GHDL v0
$end
$timescale
1 fs
$end
$var reg 8 ! a[7:0] $end
$var reg 8 " y[7:0] $end
$var reg 1 # v $end
$var reg 8 $ ab[7:0] $end
$var reg 1 % a012 $end
$var reg 1 & a012a $end
$var reg 1 ' a012b $end
$var reg 1 ( a34 $end
$var reg 1 ) a345 $end
$var reg 1 * a3456 $end
$scope module (0) $end
$scope module x4 $end
$var reg 1 + a $end
$var reg 1 , y $end
$var reg 1 - t $end
$scope module e $end
......
OK....
I get a dump of signals but NO indication of type (which can only be assumed), direction or hierarchy...
From the doc:
"Currently, there is no way to select signals to be dumped: all signals are dumped, which can generate big files."
There could be more hope with the ./inc8 --wave=inc8.ghw command but that would require more efforts because the dump is in binary, undocumented and subject to change...
Another approach uses another underrated feature of GHDL :
ghdl --file-to-xml $PA3 INC8_ASIC.vhdl
The -a command is replaced here with --file-to-xml command which, as you can infer from the name, dumps a XML stream...
Here we find the definitions of the ports. This is contained in the "port_chain" tag :
<port_chain>
<el kind="interface_signal_declaration" identifier="a" mode="in">
<subtype_indication identifier="slv8"></subtype_indication>
</el>
<el kind="interface_signal_declaration" identifier="y" mode="out">
<subtype_indication identifier="slv8"></subtype_indication>
</el>
<el kind="interface_signal_declaration" identifier="v" mode="out">
<subtype_indication identifier="sl"></subtype_indication>
</el>
</port_chain>
I have removed a LOT of text to get only what is required.
This allows the use of the wrapper types SLVx and SL, but now we need XML processing software to list and extract only the needed information...
Well, this is where it's getting interesting : at first I'd thought that using the wrapping types would make thing harder but looking at the XML, it looks like a great way to simplify the parsing because the std_logic_vectors use a complex system to define the bounds. OTOH the type SLV8 makes a static statement about the type and size, which is not flexible or generics-configurable but much more direct to extract.
Well, thanks to some unexpected hack found on StackOverflow, it seems that XML can be crudely parsed with some dirty-as-ever bash script.
#!/bin/bash
ReadTag () {
IFS=\> read -d \< ENTITY
}
GetAttribute () {
LIST=($ATTRIBUTES)
ATTRIBUTE=""
for i in $(seq "${#LIST[@]}") ; do
IFS='"' read -a ATTRIBUTE <<< "${LIST[$i]}"
if [[ $ATTRIBUTE = "$1" ]] ; then
echo -n "${ATTRIBUTE[1]}"
fi
done
}
PORT_TYPE=""
PORTNAME=""
INOUT=""
FlushPort () {
if [[ "$PORT_TYPE" != "" ]] ; then
case "$INOUT" in
"in") ;;
"out") ;;
*) echo "wrong port direction for signal $PORTNAME"
return
esac
echo "$PORTNAME $PORT_TYPE $INOUT...
Read more »
Yann Guidon / YGDES
Al Williams
Mechanical Advantage
