EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

replicating libre-licensed multiplexed tri-state pullup/pull

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - Verilog Language - replicating libre-licensed multiplexed tri-state pullup/pull


Guest

Sun Dec 03, 2017 2:24 pm   



hi,

i'm looking to create a libre-licensed embedded mobile-class risc-v SoC
(documented here) http://rhombus-tech.net/riscv/shakti/m_class/

most of the parts are, surprisingly (more like amazingly)
already available. the part that's missing (as libre source
code) is a pinmux. so i've started - as literally my first
verilog programming ever (yay!) - to create one.

so the goal is basically to implement - in full - slide 13 of
the following PDF:
https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf

however OUTA..D and INA..D will actually be the exact same nets,
therefore i figured that it would be important to have tri-stating
in both the In and Out multiplexers.

starting with one of the building blocks i've put together a
first version tri-stated demultiplexer from various random
tutorials, and i would be most grateful for some review input
from people who know how this stuff actually works when it
comes to not just FPGAs but also ASIC synthesis.

test module not included, here's the code for the demux: is there
anything unreasonable about it? is it appropriate to add in
tri-state bearing in mind that it will be part of a two-way bus line,
multiplexing four separate bus lines (different functions like
Micro-SD, SPI, UART etc.) each of which will be two way, onto
the same two-way IO pad?

bearing in mind that in the proposed design INA=OUTA (same net) INB=OUTB etc.
unlike in the above-referenced slide, my understanding is that for the
multiplexer you would use "!en", that would flip the demuxer to tri-state
when the muxer is not tri-state, and vice-versa.

also do i *actually* need pullup/pulldown here in the actual multiplexer
itself, or should it, as is done in the example slide, actually be on
the pin-pad part?

many thanks in advance for assistance and advice.

l.


// module for tri-state demultiplexing, with:
// - enable (en)
// - pull-up enable and pull-up default value
// - s selector 0-3 will select which of 4 lines (y) that input is routed to

module tridemux (s, I, en,y, enpu, puv);

input[1:0] s;
input I, en, enpu, puv;
output[3:0] y;
wire val;
genvar i;

// prepare value by selecting input if enabled otherwise
// default to pullup if *that* is enabled... otherwise tristate
assign val = en ? I : (enpu ? puv : 'bz);

// now assign value to selected output (s), otherwise tristate
for (i = 0; i < 4; i = i + 1) begin
assign (pull0, pull1) y[i] = (s == i) ? val : 'bz;
end

endmodule


Guest

Tue Dec 05, 2017 10:13 am   



On Sunday, December 3, 2017 at 1:25:03 PM UTC+1, luke.l...@gmail.com wrote:
Quote:
hi,

i'm looking to create a libre-licensed embedded mobile-class risc-v SoC
(documented here) http://rhombus-tech.net/riscv/shakti/m_class/

most of the parts are, surprisingly (more like amazingly)
already available. the part that's missing (as libre source
code) is a pinmux. so i've started - as literally my first
verilog programming ever (yay!) - to create one.

so the goal is basically to implement - in full - slide 13 of
the following PDF:
https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf

however OUTA..D and INA..D will actually be the exact same nets,
therefore i figured that it would be important to have tri-stating
in both the In and Out multiplexers.

starting with one of the building blocks i've put together a
first version tri-stated demultiplexer from various random
tutorials, and i would be most grateful for some review input
from people who know how this stuff actually works when it
comes to not just FPGAs but also ASIC synthesis.

test module not included, here's the code for the demux: is there
anything unreasonable about it? is it appropriate to add in
tri-state bearing in mind that it will be part of a two-way bus line,
multiplexing four separate bus lines (different functions like
Micro-SD, SPI, UART etc.) each of which will be two way, onto
the same two-way IO pad?

bearing in mind that in the proposed design INA=OUTA (same net) INB=OUTB etc.
unlike in the above-referenced slide, my understanding is that for the
multiplexer you would use "!en", that would flip the demuxer to tri-state
when the muxer is not tri-state, and vice-versa.

also do i *actually* need pullup/pulldown here in the actual multiplexer
itself, or should it, as is done in the example slide, actually be on
the pin-pad part?

many thanks in advance for assistance and advice.

l.


// module for tri-state demultiplexing, with:
// - enable (en)
// - pull-up enable and pull-up default value
// - s selector 0-3 will select which of 4 lines (y) that input is routed to

module tridemux (s, I, en,y, enpu, puv);

input[1:0] s;
input I, en, enpu, puv;
output[3:0] y;
wire val;
genvar i;

// prepare value by selecting input if enabled otherwise
// default to pullup if *that* is enabled... otherwise tristate
assign val = en ? I : (enpu ? puv : 'bz);

// now assign value to selected output (s), otherwise tristate
for (i = 0; i < 4; i = i + 1) begin
assign (pull0, pull1) y[i] = (s == i) ? val : 'bz;
end

endmodule


Hi Luke,
I think you have misunderstood. In the block diagram, IN_A/B/C/D and OUT_A/B/C/D are not tri-state - they are digital inputs and outputs respectively, and are connected to standard DEMUX (1:4) and MUX (4:1)
The only tri-state signal connected to I/O pad and pulls.

I am not sure I like the hierarchy that is shown in this diagram - the I/O pad functionality (incl bi-dir buffer and pulls, will typically be outside the digital core and in the pad ring).
Steven


Guest

Wed Dec 06, 2017 2:53 am   



On Tuesday, December 5, 2017 at 8:13:27 AM UTC, moo...@yahoo.co.uk wrote:
Quote:
On Sunday, December 3, 2017 at 1:25:03 PM UTC+1, luke.l...@gmail.com wrote:
hi,

i'm looking to create a libre-licensed embedded mobile-class risc-v SoC
(documented here) http://rhombus-tech.net/riscv/shakti/m_class/

most of the parts are, surprisingly (more like amazingly)
already available. the part that's missing (as libre source
code) is a pinmux. so i've started - as literally my first
verilog programming ever (yay!) - to create one.

so the goal is basically to implement - in full - slide 13 of
the following PDF:
https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf

however OUTA..D and INA..D will actually be the exact same nets,
therefore i figured that it would be important to have tri-stating
in both the In and Out multiplexers.

starting with one of the building blocks i've put together a
first version tri-stated demultiplexer from various random
tutorials, and i would be most grateful for some review input
from people who know how this stuff actually works when it
comes to not just FPGAs but also ASIC synthesis.

test module not included, here's the code for the demux: is there
anything unreasonable about it? is it appropriate to add in
tri-state bearing in mind that it will be part of a two-way bus line,
multiplexing four separate bus lines (different functions like
Micro-SD, SPI, UART etc.) each of which will be two way, onto
the same two-way IO pad?

bearing in mind that in the proposed design INA=OUTA (same net) INB=OUTB etc.
unlike in the above-referenced slide, my understanding is that for the
multiplexer you would use "!en", that would flip the demuxer to tri-state
when the muxer is not tri-state, and vice-versa.

also do i *actually* need pullup/pulldown here in the actual multiplexer
itself, or should it, as is done in the example slide, actually be on
the pin-pad part?

many thanks in advance for assistance and advice.

l.


// module for tri-state demultiplexing, with:
// - enable (en)
// - pull-up enable and pull-up default value
// - s selector 0-3 will select which of 4 lines (y) that input is routed to

module tridemux (s, I, en,y, enpu, puv);

input[1:0] s;
input I, en, enpu, puv;
output[3:0] y;
wire val;
genvar i;

// prepare value by selecting input if enabled otherwise
// default to pullup if *that* is enabled... otherwise tristate
assign val = en ? I : (enpu ? puv : 'bz);

// now assign value to selected output (s), otherwise tristate
for (i = 0; i < 4; i = i + 1) begin
assign (pull0, pull1) y[i] = (s == i) ? val : 'bz;
end

endmodule

Hi Luke,
I think you have misunderstood. In the block diagram, IN_A/B/C/D and OUT_A/B/C/D are not tri-state - they are digital inputs and outputs respectively, and are connected to standard DEMUX (1:4) and MUX (4:1)
The only tri-state signal connected to I/O pad and pulls.

I am not sure I like the hierarchy that is shown in this diagram - the I/O pad functionality (incl bi-dir buffer and pulls, will typically be outside the digital core and in the pad ring).
Steven



On Tuesday, December 5, 2017 at 8:13:27 AM UTC, moo...@yahoo.co.uk wrote:
Quote:
On Sunday, December 3, 2017 at 1:25:03 PM UTC+1, luke.l...@gmail.com wrote:
hi,

i'm looking to create a libre-licensed embedded mobile-class risc-v SoC
(documented here) http://rhombus-tech.net/riscv/shakti/m_class/

most of the parts are, surprisingly (more like amazingly)
already available. the part that's missing (as libre source
code) is a pinmux. so i've started - as literally my first
verilog programming ever (yay!) - to create one.

so the goal is basically to implement - in full - slide 13 of
the following PDF:
https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf

however OUTA..D and INA..D will actually be the exact same nets,
therefore i figured that it would be important to have tri-stating
in both the In and Out multiplexers.

starting with one of the building blocks i've put together a
first version tri-stated demultiplexer from various random
tutorials, and i would be most grateful for some review input
from people who know how this stuff actually works when it
comes to not just FPGAs but also ASIC synthesis.

test module not included, here's the code for the demux: is there
anything unreasonable about it? is it appropriate to add in
tri-state bearing in mind that it will be part of a two-way bus line,
multiplexing four separate bus lines (different functions like
Micro-SD, SPI, UART etc.) each of which will be two way, onto
the same two-way IO pad?

bearing in mind that in the proposed design INA=OUTA (same net) INB=OUTB etc.
unlike in the above-referenced slide, my understanding is that for the
multiplexer you would use "!en", that would flip the demuxer to tri-state
when the muxer is not tri-state, and vice-versa.

also do i *actually* need pullup/pulldown here in the actual multiplexer
itself, or should it, as is done in the example slide, actually be on
the pin-pad part?

many thanks in advance for assistance and advice.

l.


// module for tri-state demultiplexing, with:
// - enable (en)
// - pull-up enable and pull-up default value
// - s selector 0-3 will select which of 4 lines (y) that input is routed to

module tridemux (s, I, en,y, enpu, puv);

input[1:0] s;
input I, en, enpu, puv;
output[3:0] y;
wire val;
genvar i;

// prepare value by selecting input if enabled otherwise
// default to pullup if *that* is enabled... otherwise tristate
assign val = en ? I : (enpu ? puv : 'bz);

// now assign value to selected output (s), otherwise tristate
for (i = 0; i < 4; i = i + 1) begin
assign (pull0, pull1) y[i] = (s == i) ? val : 'bz;
end

endmodule

Hi Luke,
I think you have misunderstood. In the block diagram, IN_A/B/C/D and OUT_A/B/C/D are not tri-state - they are digital inputs and outputs respectively, and are connected to standard DEMUX (1:4) and MUX (4:1)
The only tri-state signal connected to I/O pad and pulls.

I am not sure I like the hierarchy that is shown in this diagram - the I/O pad functionality (incl bi-dir buffer and pulls, will typically be outside the digital core and in the pad ring).
Steven



On Tuesday, December 5, 2017 at 8:13:27 AM UTC, moo...@yahoo.co.uk wrote:
Quote:
On Sunday, December 3, 2017 at 1:25:03 PM UTC+1, luke.l...@gmail.com wrote:
hi,

i'm looking to create a libre-licensed embedded mobile-class risc-v SoC
(documented here) http://rhombus-tech.net/riscv/shakti/m_class/

most of the parts are, surprisingly (more like amazingly)
already available. the part that's missing (as libre source
code) is a pinmux. so i've started - as literally my first
verilog programming ever (yay!) - to create one.

so the goal is basically to implement - in full - slide 13 of
the following PDF:
https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf

however OUTA..D and INA..D will actually be the exact same nets,
therefore i figured that it would be important to have tri-stating
in both the In and Out multiplexers.

starting with one of the building blocks i've put together a
first version tri-stated demultiplexer from various random
tutorials, and i would be most grateful for some review input
from people who know how this stuff actually works when it
comes to not just FPGAs but also ASIC synthesis.

test module not included, here's the code for the demux: is there
anything unreasonable about it? is it appropriate to add in
tri-state bearing in mind that it will be part of a two-way bus line,
multiplexing four separate bus lines (different functions like
Micro-SD, SPI, UART etc.) each of which will be two way, onto
the same two-way IO pad?

bearing in mind that in the proposed design INA=OUTA (same net) INB=OUTB etc.
unlike in the above-referenced slide, my understanding is that for the
multiplexer you would use "!en", that would flip the demuxer to tri-state
when the muxer is not tri-state, and vice-versa.

also do i *actually* need pullup/pulldown here in the actual multiplexer
itself, or should it, as is done in the example slide, actually be on
the pin-pad part?

many thanks in advance for assistance and advice.

l.


// module for tri-state demultiplexing, with:
// - enable (en)
// - pull-up enable and pull-up default value
// - s selector 0-3 will select which of 4 lines (y) that input is routed to

module tridemux (s, I, en,y, enpu, puv);

input[1:0] s;
input I, en, enpu, puv;
output[3:0] y;
wire val;
genvar i;

// prepare value by selecting input if enabled otherwise
// default to pullup if *that* is enabled... otherwise tristate
assign val = en ? I : (enpu ? puv : 'bz);

// now assign value to selected output (s), otherwise tristate
for (i = 0; i < 4; i = i + 1) begin
assign (pull0, pull1) y[i] = (s == i) ? val : 'bz;
end

endmodule

Hi Luke,
I think you have misunderstood. In the block diagram,
IN_A/B/C/D and OUT_A/B/C/D are not tri-state -
they are digital inputs and outputs respectively, and are
connected to standard DEMUX (1:4) and MUX (4:1)


yes. apologies for not being clear: i am not looking to
implement that specific circuit, i am looking to turn it
*into* a 4-way-multiplexed bi-directional bus. i have
since tracked down some verilog which does that:

assign DD = dd_OE ? dd_pad_o : 'bz;
assign dd_pad_i = DD;

a diagram of that would be http://hands.com/~lkcl/io_bidirectional_bus.jpg

that was cut/paste as-is... let me work my head round connecting
the two diagrams together, this is unfamiliar territory to me...

assign DD_A = OEN ? OUT_A : 'bz;
assign IN_A = DD_A;

or something similar which takes OUTA and INA and *makes*
a bi-directional bus out of them.

Quote:
The only tri-state signal connected to I/O pad and pulls.

I am not sure I like the hierarchy that is shown in this
diagram - the I/O pad functionality (incl bi-dir buffer
and pulls, will typically be outside the digital core
and in the pad ring).


ok so this is where my complete lack of first-hand
experience with verilog and ASIC design comes right to the
front (i've designed an ASIC at the gate level, once,
with assistance from someone who knew what they were doing,
it was a lot of fun, but didn't involve external pads).

so let us assume that on that that slide diagram from
Pin_Control_Subsystem_Overview.pdf has been modified
to include, on each of the 4+4 lines OUTX+INX a
suitable bi-directional bus-merging tri-state buffer.

if i am reading you correctly, what you are saying is
that in the (modified) diagram, the multiplexers would,
on an actual ASIC, be placed right next to the pin
pads?

what if the VDD for the pin pads is completely different
from the VDD for the multiplexers? or, more specifically:
what if there is a requirement that the CMOS voltage
levels for the pins is completely different to the
digital CMOS voltage levels required for the operation
of the various hard macros (UART, SPI) connected to
each of the bi-directional buses on IN/OUT-A, IN/OUT-B,
etc.?

would that have any influence or bearing on the design?

i appreciate that this is quite involved, it's an interesting
"first project" for sure Smile one of my next questions to
search for on google is certainly going to be "verilog
bi-directional level shifter"... i know how to do it with
a MOSFET for open-drain scenarios on a PCB... :)

tia,

l.


Guest

Wed Dec 06, 2017 4:03 am   



On Wednesday, December 6, 2017 at 12:53:27 AM UTC, luke.l...@gmail.com wrote:

Quote:
i appreciate that this is quite involved, it's an interesting
"first project" for sure Smile one of my next questions to
search for on google is certainly going to be "verilog
bi-directional level shifter"... i know how to do it with
a MOSFET for open-drain scenarios on a PCB... Smile


(preliminary investigation showed this)

https://www.design-reuse.com/articles/36212/a-high-density-high-performance-low-power-level-shifter.html

which would tend to suggest that the best approach would be "put it in
a module named level_shift_up() and level_shift_down() and let MOSIS
deal with it" :)

l.

elektroda.net NewsGroups Forum Index - Verilog Language - replicating libre-licensed multiplexed tri-state pullup/pull

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map