On 7/25/2014 5:56 PM, Mark Curry wrote:
In article <lquep6$6cl$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
On 7/25/2014 2:41 PM, Mark Curry wrote:
In article <lqu4v4$upa$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
On 7/25/2014 5:58 AM, Marc Jenkins wrote:
Hello folks,
Verilog supports the net type "wor" to implement a wired or logic.
Is something similar possible in VHDL?
Target plattform is an ASIC.
The question is why would you want that? To use a wired or you would
need to have open collector (or open drain) outputs with a pull up
resistor. Compared to just adding an OR gate this is a very slow method
or very power hungry, take your pick.
Do you really plan to use a wired or? Or do you expect this to be
replaced with a real gate and are using it as shorthand?
Most synthesis tools I'm aware of correctly map multiple drivers on a "wor" net
to a logical 'or' gate. It's perfectly synthesizable, and quite useful.
We've been using this construct for over 10 years on our Xilinx FPGAs
on our CPU register bus. The returned read data (for when the CPU
is issuing a read) is collected on a "wor" bus. All the slaves
drive 0 when NOT addressed. When addressed, and issued a read, the
one slave drives the actual read data on the bus.
Works a charm, and greatly simplifies our code.
Synthesizable yes, useful...?
Very useful. We've got a much cleaner, reusable structure setup for
register configuration. There's nothing to do to add/subtract (sometimes
via the setting of a parameter) more registers on the bus. It just works.
It's a bit hard to describe in a small example. But we've got significant
code size reduction using this structure. Some were uncomfortable at first
with the "multi-driver" implications, or collision problems. But we've found
that neither are a problem at all.
No need for examples. I understand perfectly what you are describing.
But this is a construct that is in some respects the equivalent of a
global variable and creates issues for verifying code depending on your
methods. If it works for you then great.
In article <lqunq3$bq$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
On 7/25/2014 5:56 PM, Mark Curry wrote:
In article <lquep6$6cl$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
On 7/25/2014 2:41 PM, Mark Curry wrote:
In article <lqu4v4$upa$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
On 7/25/2014 5:58 AM, Marc Jenkins wrote:
Hello folks,
Verilog supports the net type "wor" to implement a wired or logic.
Is something similar possible in VHDL?
Target plattform is an ASIC.
The question is why would you want that? To use a wired or you would
need to have open collector (or open drain) outputs with a pull up
resistor. Compared to just adding an OR gate this is a very slow method
or very power hungry, take your pick.
Do you really plan to use a wired or? Or do you expect this to be
replaced with a real gate and are using it as shorthand?
Most synthesis tools I'm aware of correctly map multiple drivers on a "wor" net
to a logical 'or' gate. It's perfectly synthesizable, and quite useful.
We've been using this construct for over 10 years on our Xilinx FPGAs
on our CPU register bus. The returned read data (for when the CPU
is issuing a read) is collected on a "wor" bus. All the slaves
drive 0 when NOT addressed. When addressed, and issued a read, the
one slave drives the actual read data on the bus.
Works a charm, and greatly simplifies our code.
Synthesizable yes, useful...?
Very useful. We've got a much cleaner, reusable structure setup for
register configuration. There's nothing to do to add/subtract (sometimes
via the setting of a parameter) more registers on the bus. It just works.
It's a bit hard to describe in a small example. But we've got significant
code size reduction using this structure. Some were uncomfortable at first
with the "multi-driver" implications, or collision problems. But we've found
that neither are a problem at all.
No need for examples. I understand perfectly what you are describing.
But this is a construct that is in some respects the equivalent of a
global variable and creates issues for verifying code depending on your
methods. If it works for you then great.
Rickman,
I was among those that cast a suspicious eye on the construct when I
first saw it. But it really works fine and is NOT comparable to
a global variable at all IMHO.
I think of it as the same mux as others do by hand to
mux the readdata back - just broken up. i.e. think
of the readmux as a sum of products:
y = ( sel0 & in0 ) | ( sel1 & in1 ) | ( sel2 & in2 ) | ...
Where we force the slave modules themselves to do the "AND" masking.
Then the 'OR' is taken care of automatically with the 'wor' multi-driver.
There's really no verification issues that we have with using this.
It's very straightforward.
On 7/25/2014 8:06 PM, Mark Curry wrote:
In article <lqunq3$bq$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
On 7/25/2014 5:56 PM, Mark Curry wrote:
In article <lquep6$6cl$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
On 7/25/2014 2:41 PM, Mark Curry wrote:
In article <lqu4v4$upa$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
On 7/25/2014 5:58 AM, Marc Jenkins wrote:
Hello folks,
Verilog supports the net type "wor" to implement a wired or logic.
Is something similar possible in VHDL?
Target plattform is an ASIC.
The question is why would you want that? To use a wired or you would
need to have open collector (or open drain) outputs with a pull up
resistor. Compared to just adding an OR gate this is a very slow method
or very power hungry, take your pick.
Do you really plan to use a wired or? Or do you expect this to be
replaced with a real gate and are using it as shorthand?
Most synthesis tools I'm aware of correctly map multiple drivers on a "wor" net
to a logical 'or' gate. It's perfectly synthesizable, and quite useful.
We've been using this construct for over 10 years on our Xilinx FPGAs
on our CPU register bus. The returned read data (for when the CPU
is issuing a read) is collected on a "wor" bus. All the slaves
drive 0 when NOT addressed. When addressed, and issued a read, the
one slave drives the actual read data on the bus.
Works a charm, and greatly simplifies our code.
Synthesizable yes, useful...?
Very useful. We've got a much cleaner, reusable structure setup for
register configuration. There's nothing to do to add/subtract (sometimes
via the setting of a parameter) more registers on the bus. It just works.
It's a bit hard to describe in a small example. But we've got significant
code size reduction using this structure. Some were uncomfortable at first
with the "multi-driver" implications, or collision problems. But we've found
that neither are a problem at all.
No need for examples. I understand perfectly what you are describing.
But this is a construct that is in some respects the equivalent of a
global variable and creates issues for verifying code depending on your
methods. If it works for you then great.
Rickman,
I was among those that cast a suspicious eye on the construct when I
first saw it. But it really works fine and is NOT comparable to
a global variable at all IMHO.
I think of it as the same mux as others do by hand to
mux the readdata back - just broken up. i.e. think
of the readmux as a sum of products:
y = ( sel0 & in0 ) | ( sel1 & in1 ) | ( sel2 & in2 ) | ...
Where we force the slave modules themselves to do the "AND" masking.
Then the 'OR' is taken care of automatically with the 'wor' multi-driver.
There's really no verification issues that we have with using this.
It's very straightforward.
I might not understand this correctly since I am much more the VHDL
programmer (where the wire or is seldom used, in fact, can that be
done?) than a Verilog programmer... So there is one net with multiple
drivers. When *any* of the drivers outputs a 1 the net is a 1, hence
the wire or name.
So if you have a 1 on the net when you aren't expecting a 1, how do you
identify the driver unless you look at the inputs to all the drivers in
all the different modules? To me that is a problem and is one of the
reasons why buses like this are a PITA to debug in real hardware. This
is commonly referred to as "hanging" the bus.
By using an explicit mux the only signal that can drive the output of
the mux is the signal that is selected at that moment. Look at the
select lines, look at the corresponding input and continue to trace back
from there.
This is not an insurmountable problem. As I said this is commonly used
in real hardware, just not inside chips very often. You say it makes
the code easier to read, I think it splits the logic for a simple mux
across multiple modules and makes it harder to debug.
Consider a software technique of encapsulating decisions and functions.
The wire or is the opposite of that since the mux logic is spread
across modules.
Different horses for different courses.
--
Rick
ut resolved_wor std_ulogic); These things can be easily written as custom functions by the designer.Haven't tried resolution functions on Xilinx. But from the sound of it, I
believe your 'wor' can be easily done with a custom resolution function in
VHDL:
entity test is port(d0,d1:in std_ulogic; q
end entity test;
architecture rtl of test is begin
q<=d0;
q<=d1;
end architecture rtl;
Not sure if Vivado supports this though. With a bit of hacking, you can get
Quartus to support this. Last I know, Quartus chokes on custom resolved ports,
so you need to declare an internal signal
that uses the custom resolution function:
signal s:resolved_wor std_ulogic;
and treat s as having multiple drivers from d0 and d1. Then drive the output
q from the internal resolved signal s.
You can write custom resolution functions to resolve outputs on OR, AND, or
anything you want. We prefer not to have special keywords like wor, wand, etc.
that clutter our language.
can be easily written as custom functions by the designer.
ut resolved_wor std_ulogic;On Friday, 1 August 2014 04:58:39 UTC+8, Mark Curry wrote:
I'm not a VHDL person - can you detail more? How's the custom resolution
function written? I.e. How's it support the variable number of inputs to
the function?
Sorry for the multiple posting. Posted too quickly without reading
your entire question. :|
A resolution function accepts as argument, a vector (or array) of
the signal you wish to have multiple drivers on. Say for example
you have a signal (or output) net q as in my previous example, that
you wish to have multiple sources driving it. q is of an unresolved
type std_ulogic, but you can apply the resolution function
"resolved_wor" to resolve q to a deterministic value from multiple
sources driving it.
q
To write a resolution function for q, you create one that accepts a
vector of std_ulogic (we can use the predefined std_ulogic_vector),
and this array contains all the multiple drivers that would be
driving q. The resolution function can then be written to resolve the
output based on any resolution logic you want. This can be a simple OR
or AND, or can as complex as need be. The output (return
value) of a resolution function must therefore be of a resolved type
(such as std_logic).
function resolved_wor(s:std_ulogic_vector) return std_logic is begin
...
end function resolved_wor;
In article <078f85e7-b935-403d-896e-9d8493b63fb9@googlegroups.com>,
Daniel Kho <daniel.kho@gmail.com> wrote:
On Friday, 1 August 2014 04:58:39 UTC+8, Mark Curry wrote:
I'm not a VHDL person - can you detail more? How's the custom resolution
function written? I.e. How's it support the variable number of inputs to
the function?
Sorry for the multiple posting. Posted too quickly without reading
your entire question. :|
A resolution function accepts as argument, a vector (or array) of
the signal you wish to have multiple drivers on. Say for example
you have a signal (or output) net q as in my previous example, that
you wish to have multiple sources driving it. q is of an unresolved
type std_ulogic, but you can apply the resolution function
"resolved_wor" to resolve q to a deterministic value from multiple
sources driving it.
q
To write a resolution function for q, you create one that accepts a
vector of std_ulogic (we can use the predefined std_ulogic_vector),
and this array contains all the multiple drivers that would be
driving q. The resolution function can then be written to resolve the
output based on any resolution logic you want. This can be a simple OR
or AND, or can as complex as need be. The output (return
value) of a resolution function must therefore be of a resolved type
(such as std_logic).
function resolved_wor(s:std_ulogic_vector) return std_logic is begin
...
end function resolved_wor;
Yeah - doesn't solve my problem. There's no "std_ulogic_vector" for the
input to the function. There's only *ONE* net. The one net with multiple
(resolved type) drivers on it.
I don't see how this is "custom resolution function" is different
than any other function? (Again, I'm not VHDL person).
What I'm trying to do (verilog speak, sorry):
cpu_reg cpu_reg1 ( `BUS_CONNECT, .data_o( reg1_val ) );
cpu_reg cpu_reg2 ( `BUS_CONNECT, .data_o( reg2_val ) );
cpu_reg cpu_reg3 ( `BUS_CONNECT, .data_o( reg3_val ) );
....
The `BUS_CONNECT is simple a verilog macro (probably a structure (record?)
in VHDL) that hooks up the CPU bus interface. All the read data, is a
wor net.
Theres only one "read_data" net (an output of this entity) on BUS_CONNECT.
(Think of it as 1 bit to make the testcase easier). "read_data" is 'wor'
resolved for the multiple drivers on it.
Generics/etc will conditionally compile in/out many cpu_regs. So I don't
know how many drivers "read_data" has apriori. Nor could I easily define
the width of the "std_ulogic_vector" input to your function.
ut resolved_wor std_ulogic;