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
