Trying to pass a value from one bus to another conditionally

[John Oyler]

I have two 8bit busses, both bi-directional. When the value on one bus
matches some arbitrary values, I'd like the same value to be output
onto the second bus. So far, I have something like this (simplified
example, removed irrelevant stuff):

module coprocessor(
sync,
clkin,
sysdata,
cpudata,
);

inout[7:0] sysdata, cpudata;

input sync, clkin;

reg [7:0] data;

always @( posedge clkin)
begin

if (sync == 1)begin
case (sysdata)
8'h00 : begin
data <= sysdata;
end
default : begin
data <= sysdata;
end
end
else begin
data <= sysdata;
end
end

assign cpudata = tristate? 8'h00 : data;

endmodule


This is how it was explained to me on this newsgroup just last week.
(whoever that was, not blaming you... obviously, I don't know enough
to even follow your example that well).

I'm assuming that to even use a tristate, there's some include that
needs to be done, but nothing obvious in Xilinx's ISE is there for me
to do it with. Could someone point out what exactly it is that I'm
screwing up?

Thanks,
John O.

 

[Jonathan Bromley]

On Sun, 26 Aug 2007 19:23:00 -0700, John Oyler
<john.m.oyler@gmail.com> wrote:

I have two 8bit busses, both bi-directional. When the value on one bus
matches some arbitrary values, I'd like the same value to be output
onto the second bus. So far, I have something like this (simplified
example, removed irrelevant stuff):

There's somewhat a mismatch between what your words tell us
and what your code is doing.

data;

always @( posedge clkin)
begin

if (sync == 1)begin
case (sysdata)
8'h00 : begin
data <= sysdata;
end
default : begin
data <= sysdata;
end
end
else begin
data <= sysdata;
end
end

OK, so far so good, on every clock you use the value on "sysdata"
(presumably driven from elsewhere, outside your module) to update
your local internal value "data". As you say, there's presumably
a lot more detail in your real design than you've shown us here.

assign cpudata = tristate? 8'h00 : data;

This part I don't follow at all. First off, you have not yet
declared "tristate". I assume you want it to be a signal that
is (de?)asserted whenever "data" matches one of your special values.
Secondly, when "tristate" is asserted, you drive the value 8'h00
on to "cpudata"; but your problem description seems to say that
you want the bus floated (undriven) in that situation - presumably
so that some other external device can drive it instead.

The Verilog idiom for a synthesizable tri-state buffer is
simple and invariable:

assign multi_drop_bus = I_am_driving_it ? data_to_drive : 8'bz;

That's it. Nothing you can do about it. So the problem reduces
to two things:

(1) When should I be driving the bus, and when should I float it?
That is the question that you answer by providing the right
0/1 value (0=float, 1=drive) on signal "I_am_driving_it".

(2) What value should I be trying to drive? That's the value on
"data_to_drive". Obviously, if you are not driving the data out,
then this value is don't-care and you can put any old trash on it.

Based on this, you *probably* want something vaguely like this...

...
reg [7:0] data;
reg drive_it_out;

// Get the internal data value from "sysdata"
always @(posedge clkin)
data <= [some function of sync and sysdata];

// Is this one of the values that I want to drive out?
always @data begin
case (data)
8'h35, 8'h42, 8'hFF:
drive_it_out = 1'b1;
default:
drive_it_out = 1'b0;
endcase
end

// Drive the cpudata bus if it's one of the chosen values,
// otherwise allow cpudata to float
assign cpudata = drive_it_out ? data : 8'bz;

I'm assuming that to even use a tristate, there's some include that
needs to be done, but nothing obvious in Xilinx's ISE is there for me
to do it with.

Nope; you simply need to use the pattern of Verilog code described
above. However, you really MUST question whether you genuinely
want tri-state. If the signals in question are entirely within
your FPGA design, it's probably better NOT to use tri-state but
instead to distribute independent write-data and read-data signals;
there are no physical tri-state drivers in the fabric of modern
FPGAs, so the tools are obliged to re-map any tri-state style design
into some arrangement of enable signals and multiplexers, and
most designers prefer to control that explicitly for themselves.
On the other hand, if this is on the I/O pads because you
really need bidirectional buses on the circuit board, then the
tri-state description is fine and will automatically be mapped
to the appropriate I/O pad arrangements.

There are other questions that really need answering, too. In
particular, the timing of tri-state enable/disable relative to
the clock and the data probably needs some careful thought.
None of this, though, affects the fundamental question of
how to make a tri-state driver.

HTH
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[John Oyler]

On Aug 27, 6:17 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

There's somewhat a mismatch between what your words tell us
and what your code is doing.

That's because I have no clue what I'm doing. I have a cheap fpga
board to play with, the free xilinx tools, and only those tutorials I
can find on the internet. I know several programming languages more or
less well, but neither vhdl nor verilog really compare. I'm not going
to school (even if my questions sound stupid enough that you'd think I
was wanting you to do my homework). I'm just tired of trying to do
everything with pics, and I've found something I want to do that's not
possible any other way.

As for the design, yes both sysdata and cpudata are straight to the
pins, as is sync. (To a 6502, and the system it's in... sync indicates
that it's an opcode fetch... trying to intercept what will be invalid
opcodes, and treat them as extended opcodes to do fancy stuff. For
some strange reason I seem to think this part is harder than when it
comes time to start doing hardware mulitplication and logs. Don't
worry, I'll be disabused of that notion real quick.)

Thanks very much,
John O.

 

[Jonathan Bromley]

On Mon, 27 Aug 2007 12:17:18 -0000, John Oyler
<john.m.oyler@gmail.com> wrote:

As for the design, yes both sysdata and cpudata are straight to the
pins, as is sync. (To a 6502, and the system it's in... sync indicates
that it's an opcode fetch... trying to intercept what will be invalid
opcodes, and treat them as extended opcodes to do fancy stuff. For
some strange reason I seem to think this part is harder than when it
comes time to start doing hardware mulitplication and logs. Don't
worry, I'll be disabused of that notion real quick.)

Sounds fun.

But... if an instruction fetch turns out to be a non-6502 opcode,
what do you then get the 6502 to do? Keep it busy with NOPs while
you do the extended instruction? Stall it with its wait-for-memory
signal (sorry, too long since I looked at 6502s, can't remember
that signal's name)? If the latter, what happens next? You can't
just fetch the *next* instruction and feed it to the 6502, 'coz
its PC would then be wrong... I suspect you've worked all this out,
but it's not obvious to me!
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[John Oyler]

On Aug 27, 10:10 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Mon, 27 Aug 2007 12:17:18 -0000, John Oyler

john.m.oy...@gmail.com> wrote:
As for the design, yes both sysdata and cpudata are straight to the
pins, as is sync. (To a 6502, and the system it's in... sync indicates
that it's an opcode fetch... trying to intercept what will be invalid
opcodes, and treat them as extended opcodes to do fancy stuff. For
some strange reason I seem to think this part is harder than when it
comes time to start doing hardware mulitplication and logs. Don't
worry, I'll be disabused of that notion real quick.)

Sounds fun.

But... if an instruction fetch turns out to be a non-6502 opcode,
what do you then get the 6502 to do? Keep it busy with NOPs while
you do the extended instruction? Stall it with its wait-for-memory
signal (sorry, too long since I looked at 6502s, can't remember
that signal's name)? If the latter, what happens next? You can't
just fetch the *next* instruction and feed it to the 6502, 'coz
its PC would then be wrong... I suspect you've worked all this out,
but it's not obvious to me!

Took us awhile to find out. You have the right idea with feeding it
NOPs... but you also feed it a JMP (at the end) so that the pc ends up
correct. You do have to do a little fiddling, to have the correct
address to feed it... but it should be easy enough to keep track of,
since you're eavesdropping (hell, intercepting and forwarding is more
accurate) on the address bus. In a similar fashion, you can also
eavesdrop for certain JSRs, and intercept software floating point
routines, have the fpu execute them instead, and just feed the cpu a
RTS when finished.

When we just need the thing to wait around, it's probably better to
stall its clock, the 65c02 version can do that indefinitely.

We've got most of it worked out, and while we can explain most of the
behavior in detail in english, neither of us knows much at all about
hdl. Thanks though, you've been really patient with what I suspect are
questions even stupider than I thought they were when I asked.

John O.

 

[Jonathan Bromley]

On Mon, 27 Aug 2007 08:14:34 -0700, John Oyler
<john.m.oyler@gmail.com> wrote:

We've got most of it worked out, and while we can explain most of the
behavior in detail in english, neither of us knows much at all about
hdl. Thanks though, you've been really patient with what I suspect are
questions even stupider than I thought they were when I asked.

Keep coming back. It sounds like an entertaining project, and
folks here and on comp.arch.fpga are likely to be willing to
chip in with ideas and fixes.

Someone, for sure, will tell you to embed the whole 6502 core
in your FPGA. There are some "heritage arcade games" projects
around that have spawned 6502 soft-cores, if I'm not mistaken.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.