Hi Troy, I've been lurking in on your dialog with Jim and thought I'd add my two cents.
The WIP/HDL specification for "signals on the wire" goes to some length to try to separate a) The width of a data channel b) The data type (or types) conveyed over that channel As an EE, I too often mistakenly focus on a forced-coupling between the two; when in practice there can be adequate degrees of freedom between them. I believe the intent is to empower the application to dictate all of the above: datatypes, throughput/latency (width), and the values/costs. In practice, we have implemented 2^n byte width sizes ( really 2^m DWORD sizes ) first; but with Byte-level fidelity. This was not in any way to punish someone who wishes a 36b data path; simply our own finite development resources. I think it is great that you are advancing a use case that isn't as "neat and packaged" as the rest! Hope that helps. -Shep ps: Also some parallel OpenCPI talk in Google Groups: https://groups.google.com/forum/?hl=en&fromgroups#!forum/opencpi On Mon, Mar 12, 2012 at 6:57 PM, Ziersch, Troy (Contractor) < [email protected]> 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 > -- Shepard Siegel, CTO atomicrules.com blog.atomicrules.com
_______________________________________________ opencpi_dev mailing list [email protected] http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
