Re: [phdl-devel] a very modest simplification proposal

[Wesley J. L. <wj...@ic...>]

On Wednesday, January 23, 2013 02:15:27 Peter Dudley wrote:
> ... or we could just use our concatenation syntax and the assignment
> becomes.
> 
> cs = {cs012,cs012,cs012,cs3};  // I'm not sure this is the right
> concatenation syntax but you get the idea.
> 
> Doesn't that eliminate rules 2 and 3.

It does for 1-bit nets, but remember the case I suggested:

On Tuesday, January 22, 2013 19:30:03 Wesley J. Landaker wrote:
> In this proposal, your example only has 1-bit ports. What would happen
> if the instance you want to put in array has a, say, 5-bit port, and you
> instance 7 of them?
> 
> Having the them all concatenate into a 35-bit port would be analogous to
> what you are showing happen with 1-bit ports, but that seems pretty
> obviously awkward. Other options (disallowing this, doing something
> different magically when there is more than 1-bit) are probably even
> worse.

// d_in is a 5-bit net
// d is 5-bit port, but in an 7:0 array is auto-combined to a 35-bit net
d = {d_in,d_in,d_in,d_in,d_in,d_in,d_in};

Is that what you're thinking? That would drive me nuts. =)

On Wednesday, January 23, 2013 02:15:27 Peter Dudley wrote:
> The situation gets complicated when you have something like a memory
> where the address pins all get the same nets but the data pins get
> different nets. If we really want to simplify, we probably have to
> simplify what the language can do.
> 
> Here is what I suggest for memories. There is no guessing about how the
> arrayed nets and pins are hooked up.
> 
> inst mem_array3 of sram_chip {address=address; data=data(31:24)};
> inst mem_array2 of sram_chip {address=address; data=data(23:16)};
> inst mem_array1 of sram_chip {address=address; data=data(15: 8)};
> inst mem_array0 of sram_chip {address=address; data=data( 7: 0)};

Yeah, that's what I'd probably end up writing if there were just 4 chips.

And, like I said above, if there were somehow 128 memories, I'd probably 
have already used hierarchy to combine chips in powers of 2 or 4 so that 
each level is easy to write but still simple and easy to understand.

Anyway, I agree simplification from the current syntax, even if it loses 
some flexibility is not a terrible price to pay; it's likely that if there 
are 100's of things to instance in non-uniform ways, hierarchy is probably a 
better solution than direct instance arrays anyway.

That said, I want to make sure that we don't pick up a syntax that is 
intuitive only when you have 1-bit ports. Here is another (more realistic) 
try. What do you think about this syntax, which has the following single 
rule:

  1. All pins in the array must be assigned via indexing.

// each flip_flop has a 4-bit d and q port
net      d_in0_lsb;
net[3:1] d_in0_msbs;
net[3:0] d_in1;
net[3:0] d_in2;
net[3:0] d_in3;
net[3:0] q_out0;
net[3:0] q_out1;
net[3:0] q_out2;
net[3:0] q_out3;
net clk, cs012, cs3, v33, gnd;
inst(3:0) flip_flops of flip_flop_chip {
   attribute REFDES(:) = {"U13", "U12", "U11", "U10"};
   // common signals
   clk(:) = <clk>; vcc(:) = <v33>; gnd(:) = <gnd>;
   // common signal with an exception
   cs(:) = <cs012>; cs(3) = cs3;
   // signals combined into a bus, with an exception
   // still straightforward and unambiguous
   d(3:1) = {d_in3,d_in2,d_in1};
   d(0) = {d_in0_msbs,d_in0_lsb};
   // ports assigned individually
   // that could could also have been written as:
   //   q(:) = {q_out3,q_out2,q_out1,q_out0};
   // but this way would be more as to read if there were lots of
   // different signals, etc
   q(0) = q_out0;
   q(1) = q_out1;
   q(2) = q_out2;
   q(3) = q_out3;
}

As you can see I've taken the liberty to use the pythonish/matlabish (:) 
mean the entire bounds, but the point is that here you get the advantage of 
combining or not and there is nothing ambiguous anywhere.

Basically the idea is that you have an array of instances, so now you are 
assigning to an array of (possibly multibit) pins. There is no ambiguity as 
there aren't any defaults and there is no automatic magic combining. Yet, 
it's very easy to bus everything up with (:) syntax or expand out signal 
nets with <> syntax. It's an error if you forget to assign any part of any 
port, so there is no danger of missing something.

Come on, you know you like this one. =)