UNCLASSIFIED
Hi,
I think I may have confused things in the last email by swapping topics
mid email.
The following discussion was in reference to the WCI and properties
transferred over it:
I was attempting to describe the issue of packing/unpacking of non Nx8it
properties.
While on the topic of number of wires.
When the property of a HDL worker does not use all the bits of a
standard type it would be nice to be able to describe in the xml how
many bits are actually used. This would also allow range checking and
automatic register file code (register packing/unpacking) generation.
An example:
We have a frequency tuning word (FTW) for a DDS core implemented in a
HDL worker. The FTW port on the core is 21 bits wide. Thus the FTW
property is ULong but the valid range is only 0 to 2^21-1.
As some properties may be signed, one solution would be max and min
xml attributes.
As for the WSI data width:
Originally:
I wanted to force 8-bit bytes even when the data values are never 8 bits
so I didn't have to deal with MDataInfo.
Then:
After yesterdays discussion, I was happy to just add some code in my
worker to map MData and MDataInfo to an array of 16 bit bytes.
Now:
For maintainability reasons I'd like to be able to force 8 bit bytes so
there is a constant number of bytes enables.
The reasoning goes something like this. Suppose I have a number of
workers which use a protocol where the smallest operation argument is
16bits resulting in a byte width of 16. Also assume that not all workers
use all the operations. E.g. some process samples and simply pass on all
other operations. Now lets say in the future we need to add an operation
that is used only by a few workers and has a byte sized argument thus
doubling the number of byte enables on the WSI. If we don't have a
constant number of byte enables then all workers need updating not just
the ones which use the new operation.
Follow?
Conclusion:
I'd like to be able to force the byte width.
Cheers,
Troy
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of James Kulp
Sent: Tuesday, 13 March 2012 11:42 PM
To: [email protected]
Subject: Re: [opencpi_dev] Mapping of Operation Name to
HDLopcode[SEC=UNCLASSIFIED]
Troy,
I assume we would provide an alias as an array of "bytes" where "byte"
was the byte size of the interface (i.e. input [7:0] MDataIn[3:0] in
verilog for a 32 bit wide data path with 8 bit bytes). But for the
stream_protocol with a DataValueWidth is 16, it would be:
input [15:0] MDataIn[1:0];
Or are you looking to force 8-bit bytes even when the data values are
never 8 bits?
(i.e. when DataValueWidth is> 8?)
Jim
On 3/12/12 6:57 PM, Ziersch, Troy (Contractor) wrote:
UNCLASSIFIED
Hi Jim,
If MDataOut and SDataIn are arrays of bytes rather than a flat vector
then the byte size becomes obvious.
While on the topic of number of wires.
When the property of a HDL worker does not use all the bits of a
standard type it would be nice to be able to describe in the xml how
many bits are actually used. This would also allow range checking and
automatic register file code (register packing/unpacking) generation.
An example:
We have a frequency tuning word (FTW) for a DDS core implemented in a
HDL worker. The FTW port on the core is 21 bits wide. Thus the FTW
property is ULong but the valid range is only 0 to 2^21-1.
As some properties may be signed, one solution would be max and min
attributes.
Cheers,
Troy
________________________________
From: [email protected]
[mailto:[email protected]] On Behalf Of James Kulp
Sent: Saturday, 10 March 2012 1:23 AM
To: [email protected]
Subject: Re: [opencpi_dev] Mapping of Operation Name to HDL
opcode[SEC=UNCLASSIFIED]
Hi Troy,
The opcode mapping has been added for verilog. Still being tested,
but will be pushed later today.
The byte width issue comes up due mostly to a limitation of OCP signal
configuration.
A while ago we chose to use/configure OCP to minimize wires, which
means that when the smallest units of data are, say, 16 bits, then to
use OCP byte enables for 16 bit quanities, we need to split the data
between the MData and MDataInfo fields. The hack you saw was indeed
to force byte enables to correspond to 8 bits of MData and avoid
MDataInfo entirely, in order to accomodate preexisting code.
To make this "better" we should provide/generate aliases to create new
Data signals that appropriately combine MData and MDataInfo, say
MDataOut and SDataIn.
This has the advantage of conveniently dealing with non-power-of-two
packed data while still minimizing wires. It still has the (as now)
disadvantage that implementations dealing with non-8-bit quanities
have to remember that "byte" is whatever the minimal unit of data is
(9 bits,
12 bits, 16 bits, etc.). But there are real use-cases for this.
Does this make sense to you (or anyone else)?
Jim
On 3/9/12 12:43 AM, Ziersch, Troy (Contractor) wrote:
UNCLASSIFIED
Hi,
A couple more xml questions.
Is there a way to define the mapping of operations named in a
protocol to the opcode which appears on the WSI interface.
i.e. map Protocol element / Operation element / Name property to
WSI
opcodes.
Also, I'd also like to set byteWidth=8 on a WSI interface but
that
property does not seem to be settable for streamInterface elements and
defaults to the smallest argument in the protocol used by the
interface. It seems that someone else has used the same work around as
me in opencpi/components/specs/stream_protocol.xml by adding an
operation with a byte sized argument.
Thanks,
Troy
IMPORTANT: This email remains the property of the Department of
Defence and is subject to the jurisdiction of section 70 of the Crimes
Act 1914. If you have received this email in error, you are requested
to contact the sender and delete the email.
_______________________________________________
opencpi_dev mailing list
[email protected]
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
IMPORTANT: This email remains the property of the Department of
Defence and is subject to the jurisdiction of section 70 of the Crimes
Act 1914.
If you have received this email in error, you are requested to contact
the sender and delete the email.
_______________________________________________
opencpi_dev mailing list
[email protected]
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
_______________________________________________
opencpi_dev mailing list
[email protected]
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
IMPORTANT: This email remains the property of the Department of Defence
and is subject to the jurisdiction of section 70 of the Crimes Act 1914.
If you have received this email in error, you are requested to contact
the sender and delete the email.
_______________________________________________
opencpi_dev mailing list
[email protected]
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
